doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc3451.txt b/doc/rfc/rfc3451.txt
new file mode 100644
index 0000000..b1bd75e
--- /dev/null
+++ b/doc/rfc/rfc3451.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                            M. Luby
+Request for Comments: 3451                              Digital Fountain
+Category: Experimental                                        J. Gemmell
+                                                               Microsoft
+                                                             L. Vicisano
+                                                                   Cisco
+                                                                L. Rizzo
+                                                              Univ. Pisa
+                                                              M. Handley
+                                                                    ICIR
+                                                            J. Crowcroft
+                                                         Cambridge Univ.
+                                                           December 2002
+
+
+             Layered Coding Transport (LCT) Building Block
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   Layered Coding Transport (LCT) provides transport level support for
+   reliable content delivery and stream delivery protocols.  LCT is
+   specifically designed to support protocols using IP multicast, but
+   also provides support to protocols that use unicast.  LCT is
+   compatible with congestion control that provides multiple rate
+   delivery to receivers and is also compatible with coding techniques
+   that provide reliable delivery of content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 1]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+Table of Contents
+
+   1. Introduction...................................................2
+   2. Rationale......................................................3
+   3. Functionality..................................................4
+   4. Applicability..................................................7
+     4.1 Environmental Requirements and Considerations...............8
+     4.2 Delivery service models....................................10
+     4.3 Congestion Control.........................................11
+   5. Packet Header Fields..........................................12
+     5.1 Default LCT header format..................................12
+     5.2 Header-Extension Fields....................................17
+   6. Operations....................................................20
+     6.1 Sender Operation...........................................20
+     6.2 Receiver Operation.........................................22
+   7. Requirements from Other Building Blocks.......................23
+   8. Security Considerations.......................................24
+   9. IANA Considerations...........................................25
+   10. Acknowledgments..............................................25
+   11. References...................................................25
+   Authors' Addresses...............................................28
+   Full Copyright Statement.........................................29
+
+1.  Introduction
+
+   Layered Coding Transport provides transport level support for
+   reliable content delivery and stream delivery protocols.  Layered
+   Coding Transport is specifically designed to support protocols using
+   IP multicast, but also provides support to protocols that use
+   unicast.  Layered Coding Transport is compatible with congestion
+   control that provides multiple rate delivery to receivers and is also
+   compatible with coding techniques that provide reliable delivery of
+   content.
+
+   This document describes a building block as defined in RFC 3048 [26].
+   This document is a product of the IETF RMT WG  and follows the
+   general guidelines provided in RFC 3269 [24].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [2].
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 2]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   Statement of Intent
+
+      This memo contains part of the definitions necessary to fully
+      specify a Reliable Multicast Transport protocol in accordance with
+      RFC 2357.  As per RFC 2357, the use of any reliable multicast
+      protocol in the Internet requires an adequate congestion control
+      scheme.
+
+      While waiting for such a scheme to be available, or for an
+      existing scheme to be proven adequate, the Reliable Multicast
+      Transport working group (RMT) publishes this Request for Comments
+      in the "Experimental" category.
+
+      It is the intent of RMT to re-submit this specification as an IETF
+      Proposed Standard as soon as the above condition is met.
+
+2.  Rationale
+
+   LCT provides transport level support for massively scalable protocols
+   using the IP multicast network service.  The support that LCT
+   provides is common to a variety of very important applications,
+   including reliable content delivery and streaming applications.
+
+   An LCT session comprises multiple channels originating at a single
+   sender that are used for some period of time to carry packets
+   pertaining to the transmission of one or more objects that can be of
+   interest to receivers.  The logic behind defining a session as
+   originating from a single sender is that this is the right
+   granularity to regulate packet traffic via congestion control.  One
+   rationale for using multiple channels within the same session is that
+   there are massively scalable congestion control protocols that use
+   multiple channels per session.  These congestion control protocols
+   are considered to be layered because a receiver joins and leaves
+   channels in a layered order during its participation in the session.
+   The use of layered channels is also useful for streaming
+   applications.
+
+   There are coding techniques that provide massively scalable
+   reliability and asynchronous delivery which are compatible with both
+   layered congestion control and with LCT.  When all are combined the
+   result is a massively scalable reliable asynchronous content delivery
+   protocol that is network friendly.  LCT also provides functionality
+   that can be used for other applications as well, e.g., layered
+   streaming applications.
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 3]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   LCT avoids providing functionality that is not massively scalable.
+   For example, LCT does not provide any mechanisms for sending
+   information from receivers to senders, although this does not rule
+   out protocols that both use LCT and do require sending information
+   from receivers to senders.
+
+   LCT includes general support for congestion control that must be
+   used.  It does not, however, specify which congestion control should
+   be used.  The rationale for this is that congestion control must be
+   provided by any protocol that is network friendly, and yet the
+   different applications that can use LCT will not have the same
+   requirements for congestion control.  For example, a content delivery
+   protocol may strive to use all available bandwidth between receivers
+   and the sender.  It must, therefore, drastically back off its rate
+   when there is competing traffic.  On the other hand, a streaming
+   delivery protocol may strive to maintain a constant rate instead of
+   trying to use all available bandwidth, and it may not back off its
+   rate as fast when there is competing traffic.
+
+   Beyond support for congestion control, LCT provides a number of
+   fields and supports functionality commonly required by many
+   protocols.  For example, LCT provides a Transmission Session ID that
+   can be used to identify which session each received packet belongs
+   to.  This is important because a receiver may be joined to many
+   sessions concurrently, and thus it is very useful to be able to
+   demultiplex packets as they arrive according to which session they
+   belong to.  As another example, LCT provides optional support for
+   identifying which object each packet is carrying information about.
+   Therefore, LCT provides many of the commonly used fields and support
+   for functionality required by many protocols.
+
+3.  Functionality
+
+   An LCT session consists of a set of logically grouped LCT channels
+   associated with a single sender carrying packets with LCT headers for
+   one or more objects.  An LCT channel is defined by the combination of
+   a sender and an address associated with the channel by the sender.  A
+   receiver joins a channel to start receiving the data packets sent to
+   the channel by the sender, and a receiver leaves a channel to stop
+   receiving data packets from the channel.
+
+   LCT is meant to be combined with other building blocks so that the
+   resulting overall protocol is massively scalable.  Scalability refers
+   to the behavior of the protocol in relation to the number of
+   receivers and network paths, their heterogeneity, and the ability to
+   accommodate dynamically variable sets of receivers.  Scalability
+   limitations can come from memory or processing requirements, or from
+   the amount of feedback control and redundant data packet traffic
+
+
+
+Luby, et. al.                 Experimental                      [Page 4]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   generated by the protocol.  In turn, such limitations may be a
+   consequence of the features that a complete reliable content delivery
+   or stream delivery protocol is expected to provide.
+
+   The LCT header provides a number of fields that are useful for
+   conveying in-band session information to receivers.  One of the
+   required fields is the Transmission Session ID (TSI), which allows
+   the receiver of a session to uniquely identify received packets as
+   part of the session.  Another required field is the Congestion
+   Control Information (CCI), which allows the receiver to perform the
+   required congestion control on the packets received within the
+   session.  Other LCT fields provide optional but often very useful
+   additional information for the session.  For example, the Transport
+   Object Identifier (TOI) identifies which object the packet contains
+   data for.  As other examples, the Sender Current Time (SCT) conveys
+   the time when the packet was sent from the sender to the receiver,
+   the Expected Residual Time (ERT) conveys the amount of time the
+   session will be continued for, flags for indicating the close of the
+   session and the close of sending packets for an object, and header
+   extensions for fields that for example can be used for packet
+   authentication.
+
+   LCT provides support for congestion control.  Congestion control MUST
+   be used that conforms to RFC 2357 [13] between receivers and the
+   sender for each LCT session.  Congestion control refers to the
+   ability to adapt throughput to the available bandwidth on the path
+   from the sender to a receiver, and to share bandwidth fairly with
+   competing flows such as TCP. Thus, the total flow of packets flowing
+   to each receiver participating in an LCT session MUST NOT compete
+   unfairly with existing flow adaptive protocols such as TCP.
+
+   A multiple rate or a single rate congestion control protocol can be
+   used with LCT.  For multiple rate protocols, a session typically
+   consists of more than one channel and the sender sends packets to the
+   channels in the session at rates that do not depend on the receivers.
+   Each receiver adjusts its reception rate during its participation in
+   the session by joining and leaving channels dynamically depending on
+   the available bandwidth to the sender independent of all other
+   receivers.  Thus, for multiple rate protocols, the reception rate of
+   each receiver may vary dynamically independent of the other
+   receivers.
+
+   For single rate protocols, a session typically consists of one
+   channel and the sender sends packets to the channel at variable rates
+   over time depending on feedback from receivers.  Each receiver
+   remains joined to the channel during its participation in the
+   session.  Thus, for single rate protocols, the reception rate of each
+   receiver may vary dynamically but in coordination with all receivers.
+
+
+
+Luby, et. al.                 Experimental                      [Page 5]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   Generally, a multiple rate protocol is preferable to a single rate
+   protocol in a heterogeneous receiver environment, since generally it
+   more easily achieves scalability to many receivers and provides
+   higher throughput to each individual receiver.  Some possible
+   multiple rate congestion control protocols are described in [22],
+   [3], and [25].  A possible single rate congestion control protocol is
+   described in [19].
+
+   Layered coding refers to the ability to produce a coded stream of
+   packets that can be partitioned into an ordered set of layers.  The
+   coding is meant to provide some form of reliability, and the layering
+   is meant to allow the receiver experience (in terms of quality of
+   playout, or overall transfer speed) to vary in a predictable way
+   depending on how many consecutive layers of packets the receiver is
+   receiving.
+
+   The concept of layered coding was first introduced with reference to
+   audio and video streams.  For example, the information associated
+   with a TV broadcast could be partitioned into three layers,
+   corresponding to black and white, color, and HDTV quality.  Receivers
+   can experience different quality without the need for the sender to
+   replicate information in the different layers.
+
+   The concept of layered coding can be naturally extended to reliable
+   content delivery protocols when Forward Error Correction (FEC)
+   techniques are used for coding the data stream.  Descriptions of this
+   can be found in [20], [18], [7], [22] and [4].  By using FEC, the
+   data stream is transformed in such a way that reconstruction of a
+   data object does not depend on the reception of specific data
+   packets, but only on the number of different packets received.  As a
+   result, by increasing the number of layers a receiver is receiving
+   from, the receiver can reduce the transfer time accordingly.  Using
+   FEC to provide reliability can increase scalability dramatically in
+   comparison to other methods for providing reliability.  More details
+   on the use of FEC for reliable content delivery can be found in [11].
+
+   Reliable protocols aim at giving guarantees on the reliable delivery
+   of data from the sender to the intended recipients.  Guarantees vary
+   from simple packet data integrity to reliable delivery of a precise
+   copy of an object to all intended recipients.  Several reliable
+   content delivery protocols have been built on top of IP multicast
+   using methods other than FEC, but scalability was not the primary
+   design goal for many of them.
+
+   Two of the key difficulties in scaling reliable content delivery
+   using IP multicast are dealing with the amount of data that flows
+   from receivers back to the sender, and the associated response
+   (generally data retransmissions) from the sender.  Protocols that
+
+
+
+Luby, et. al.                 Experimental                      [Page 6]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   avoid any such feedback, and minimize the amount of retransmissions,
+   can be massively scalable.  LCT can be used in conjunction with FEC
+   codes or a layered codec to achieve reliability with little or no
+   feedback.
+
+   Protocol instantiations MAY be built by combining the LCT framework
+   with other components.  A complete protocol instantiation that uses
+   LCT MUST include a congestion control protocol that is compatible
+   with LCT and that conforms to RFC 2357 [13].  A complete protocol
+   instantiation that uses LCT MAY include a scalable reliability
+   protocol that is compatible with LCT, it MAY include an session
+   control protocol that is compatible with LCT, and it MAY include
+   other protocols such as security protocols.
+
+4.  Applicability
+
+   An LCT session comprises a logically related set of one or more LCT
+   channels originating at a single sender.  The channels are used for
+   some period of time to carry packets containing LCT headers, and
+   these headers pertain to the transmission of one or more objects that
+   can be of interest to receivers.
+
+   LCT is most applicable for delivery of objects or streams in a
+   session of substantial length, i.e., objects or streams that range in
+   aggregate length from hundreds of kilobytes to many gigabytes, and
+   where the duration of the session is on the order of tens of seconds
+   or more.
+
+   As an example, an LCT session could be used to deliver a TV program
+   using three LCT channels.  Receiving packets from the first LCT
+   channel could allow black and white reception.  Receiving the first
+   two LCT channels could also permit color reception.  Receiving all
+   three channels could allow HDTV quality reception.  Objects in this
+   example could correspond to individual TV programs being transmitted.
+
+   As another example, a reliable LCT session could be used to reliably
+   deliver hourly-updated weather maps (objects) using ten LCT channels
+   at different rates, using FEC coding.  A receiver may join and
+   concurrently receive packets from subsets of these channels, until it
+   has enough packets in total to recover the object, then leave the
+   session (or remain connected listening for session description
+   information only) until it is time to receive the next object.  In
+   this case, the quality metric is the time required to receive each
+   object.
+
+   Before joining a session, the receivers MUST obtain enough of the
+   session description to start the session.  This MUST include the
+   relevant session parameters needed by a receiver to participate in
+
+
+
+Luby, et. al.                 Experimental                      [Page 7]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   the session, including all information relevant to congestion
+   control.  The session description is determined by the sender, and is
+   typically communicated to the receivers out-of-band.  In some cases,
+   as described later, parts of the session description that are not
+   required to initiate a session MAY be included in the LCT header or
+   communicated to a receiver out-of-band after the receiver has joined
+   the session.
+
+   An encoder MAY be used to generate the data that is placed in the
+   packet payload in order to provide reliability.  A suitable decoder
+   is used to reproduce the original information from the packet
+   payload.  There MAY be a reliability header that follows the LCT
+   header if such an encoder and decoder is used.  The reliability
+   header helps to describe the encoding data carried in the payload of
+   the packet.  The format of the reliability header depends on the
+   coding used, and this is negotiated out-of-band.  As an example, one
+   of the FEC headers described in [12] could be used.
+
+   For LCT, when multiple rate congestion control is used, congestion
+   control is achieved by sending packets associated with a given
+   session to several LCT channels.  Individual receivers dynamically
+   join one or more of these channels, according to the network
+   congestion as seen by the receiver.  LCT headers include an opaque
+   field which MUST be used to convey congestion control information to
+   the receivers.  The actual congestion control scheme to use with LCT
+   is negotiated out-of-band.  Some examples of congestion control
+   protocols that may be suitable for content delivery are described in
+   [22], [3], and [25].  Other congestion controls may be suitable when
+   LCT is used for a streaming application.
+
+   This document does not specify and restrict the type of exchanges
+   between LCT (or any PI built on top of LCT) and an upper application.
+   Some upper APIs may use an object-oriented approach, where the only
+   possible unit of data exchanged between LCT (or any PI built on top
+   of LCT) and an application, either at a source or at a receiver, is
+   an object.  Other APIs may enable a sending or receiving application
+   to exchange a subset of an object with LCT (or any PI built on top of
+   LCT), or may even follow a streaming model.  These considerations are
+   outside the scope of this document.
+
+4.1  Environmental Requirements and Considerations
+
+   LCT is intended for congestion controlled delivery of objects and
+   streams (both reliable content delivery and streaming of multimedia
+   information).
+
+
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 8]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   LCT can be used with both multicast and unicast delivery.  LCT
+   requires connectivity between a sender and receivers but does not
+   require connectivity from receivers to a sender.  LCT inherently
+   works with all types of networks, including LANs, WANs, Intranets,
+   the Internet, asymmetric networks, wireless networks, and satellite
+   networks.  Thus, the inherent raw scalability of LCT is unlimited.
+   However, when other specific applications are built on top of LCT,
+   then these applications by their very nature may limit scalability.
+   For example, if an application requires receivers to retrieve out of
+   band information in order to join a session, or an application allows
+   receivers to send requests back to the sender to report reception
+   statistics, then the scalability of the application is limited by the
+   ability to send, receive, and process this additional data.
+
+   LCT requires receivers to be able to uniquely identify and
+   demultiplex packets associated with an LCT session.  In particular,
+   there MUST be a Transport Session Identifier (TSI) associated with
+   each LCT session.  The TSI is scoped by the IP address of the sender,
+   and the IP address of the sender together with the TSI MUST uniquely
+   identify the session.  If the underlying transport is UDP as
+   described in RFC 768 [16], then the 16 bit UDP source port number MAY
+   serve as the TSI for the session.  The TSI value MUST be the same in
+   all places it occurs within a packet.  If there is no underlying TSI
+   provided by the network, transport or any other layer, then the TSI
+   MUST be included in the LCT header.
+
+   LCT is presumed to be used with an underlying network or transport
+   service that is a "best effort" service that does not guarantee
+   packet reception or packet reception order, and which does not have
+   any support for flow or congestion control.  For example, the Any-
+   Source Multicast (ASM) model of IP multicast as defined in RFC 1112
+   [5] is such a "best effort" network service.  While the basic service
+   provided by RFC 1112 is largely scalable, providing congestion
+   control or reliability should be done carefully to avoid severe
+   scalability limitations, especially in presence of heterogeneous sets
+   of receivers.
+
+   There are currently two models of multicast delivery, the Any-Source
+   Multicast (ASM) model as defined in RFC 1112 [5] and the Source-
+   Specific Multicast (SSM) model as defined in [10].  LCT works with
+   both multicast models, but in a slightly different way with somewhat
+   different environmental concerns.  When using ASM, a sender S sends
+   packets to a multicast group G, and the LCT channel address consists
+   of the pair (S,G), where S is the IP address of the sender and G is a
+   multicast group address.  When using SSM, a sender S sends packets to
+   an SSM channel (S,G), and the LCT channel address coincides with the
+   SSM channel address.
+
+
+
+
+Luby, et. al.                 Experimental                      [Page 9]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   A sender can locally allocate unique SSM channel addresses, and this
+   makes allocation of LCT channel addresses easy with SSM.  To allocate
+   LCT channel addresses using ASM, the sender must uniquely chose the
+   ASM multicast group address across the scope of the group, and this
+   makes allocation of LCT channel addresses more difficult with ASM.
+
+   LCT channels and SSM channels coincide, and thus the receiver will
+   only receive packets sent to the requested LCT channel.  With ASM,
+   the receiver joins an LCT channel by joining a multicast group G, and
+   all packets sent to G, regardless of the sender, may be received by
+   the receiver.  Thus, SSM has compelling security advantages over ASM
+   for prevention of denial of service attacks.  In either case,
+   receivers SHOULD use mechanisms to filter out packets from unwanted
+   sources.
+
+   Some networks are not amenable to some congestion control protocols
+   that could be used with LCT.  In particular, for a satellite or
+   wireless network, there may be no mechanism for receivers to
+   effectively reduce their reception rate since there may be a fixed
+   transmission rate allocated to the session.
+
+4.2  Delivery service models
+
+   LCT can support several different delivery service models.  Two
+   examples are briefly described here.
+
+   Push service model.
+
+   One way a push service model can be used for reliable content
+   delivery is to deliver a series of objects.  For example, a receiver
+   could join the session and dynamically adapt the number of LCT
+   channels the receiver is joined to until enough packets have been
+   received to reconstruct an object.  After reconstructing the object
+   the receiver may stay in the session and wait for the transmission of
+   the next object.
+
+   The push model is particularly attractive in satellite networks and
+   wireless networks.  In these cases, a session may consist of one
+   fixed rate LCT channel.
+
+   On-demand content delivery model.
+
+   For an on-demand content delivery service model, senders typically
+   transmit for some given time period selected to be long enough to
+   allow all the intended receivers to join the session and recover the
+   object.  For example a popular software update might be transmitted
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 10]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   using LCT for several days, even though a receiver may be able to
+   complete the download in one hour total of connection time, perhaps
+   spread over several intervals of time.
+
+   In this case the receivers join the session, and dynamically adapt
+   the number of LCT channels they subscribe to according to the
+   available bandwidth.  Receivers then drop from the session when they
+   have received enough packets to recover the object.
+
+   As an example, assume that an object is 50 MB.  The sender could send
+   1 KB packets to the first LCT channel at 50 packets per second, so
+   that receivers using just this LCT channel could complete reception
+   of the object in 1,000 seconds in absence of loss, and would be able
+   to complete reception even in presence of some substantial amount of
+   losses with the use of coding for reliability.  Furthermore, the
+   sender could use a number of LCT channels such that the aggregate
+   rate of 1 KB packets to all LCT channels is 1,000 packets per second,
+   so that a receiver could be able to complete reception of the object
+   in as little 50 seconds (assuming no loss and that the congestion
+   control mechanism immediately converges to the use of all LCT
+   channels).
+
+   Other service models.
+
+   There are many other delivery service models that LCT can be used for
+   that are not covered above.  As examples, a live streaming or an on-
+   demand archival content streaming service model.  A description of
+   the many potential applications, the appropriate delivery service
+   model, and the additional mechanisms to support such functionalities
+   when combined with LCT is beyond the scope of this document.  This
+   document only attempts to describe the minimal common scalable
+   elements to these diverse applications using LCT as the delivery
+   transport.
+
+4.3  Congestion Control
+
+   The specific congestion control protocol to be used for LCT sessions
+   depends on the type of content to be delivered.  While the general
+   behavior of the congestion control protocol is to reduce the
+   throughput in presence of congestion and gradually increase it in the
+   absence of congestion, the actual dynamic behavior (e.g. response to
+   single losses) can vary.
+
+   Some possible congestion control protocols for reliable content
+   delivery using LCT are described in [22], [3], and [25].  Different
+   delivery service models might require different congestion control
+   protocols.
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 11]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+5.  Packet Header Fields
+
+   Packets sent to an LCT session MUST include an "LCT header".  The LCT
+   header format described below is the default format, and this is the
+   format that is recommended for use by protocol instantiations to
+   ensure a uniform format across different protocol instantiations.
+   Other LCT header formats MAY be used by protocol instantiations, but
+   if the default LCT header format is not used by a protocol
+   instantiation that uses LCT, then the protocol instantiation MUST
+   specify the lengths and positions within the LCT header it uses of
+   all fields described in the default LCT header.
+
+   Other building blocks MAY describe some of the same fields as
+   described for the LCT header.  It is RECOMMENDED that protocol
+   instantiations using multiple building blocks include shared fields
+   at most once in each packet.  Thus, for example, if another building
+   block is used with LCT that includes the optional Expected Residual
+   Time field, then the Expected Residual Time field SHOULD be carried
+   in each packet at most once.
+
+   The position of the LCT header within a packet MUST be specified by
+   any protocol instantiation that uses LCT.
+
+5.1  Default LCT header format
+
+   The default LCT header is of variable size, which is specified by a
+   length field in the third byte of the header.  In the LCT header, all
+   integer fields are carried in "big-endian" or "network order" format,
+   that is, most significant byte (octet) first.  Bits designated as
+   "padding" or "reserved" (r) MUST by set to 0 by senders and ignored
+   by receivers.  Unless otherwise noted, numeric constants in this
+   specification are in decimal (base 10).
+
+   The format of the default LCT header is depicted in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 12]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   V   | C | r |S| O |H|T|R|A|B|   HDR_LEN     | Codepoint (CP)|
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Congestion Control Information (CCI, length = 32*(C+1) bits)  |
+    |                          ...                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  Transport Session Identifier (TSI, length = 32*S+16*H bits)  |
+    |                          ...                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Transport Object Identifier (TOI, length = 32*O+16*H bits)  |
+    |                          ...                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               Sender Current Time (SCT, if T = 1)             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |              Expected Residual Time (ERT, if R = 1)           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                Header Extensions (if applicable)              |
+    |                          ...                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 1 - Default LCT header format
+
+   The function and length of each field in the default LCT header is
+   the following.  Fields marked as "1" mean that the corresponding bits
+   MUST be set to "1" by the sender.  Fields marked as "r" or "0" mean
+   that the corresponding bits MUST be set to "0" by the sender.
+
+     LCT version number (V): 4 bits
+
+         Indicates the LCT version number.  The LCT version number for
+         this specification is 1.
+
+     Congestion control flag (C): 2 bits
+
+         C=0 indicates the Congestion Control Information (CCI) field is
+         32-bits in length.  C=1 indicates the CCI field is 64-bits in
+         length.  C=2 indicates the CCI field is 96-bits in length.  C=3
+         indicates the CCI field is 128-bits in length.
+
+     Reserved (r): 2 bits
+
+         Reserved for future use.  A sender MUST set these bits to zero
+         and a receiver MUST ignore these bits.
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 13]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     Transport Session Identifier flag (S): 1 bit
+
+         This is the number of full 32-bit words in the TSI field.  The
+         TSI field is 32*S + 16*H bits in length, i.e. the length is
+         either 0 bits, 16 bits, 32 bits, or 48 bits.
+
+     Transport Object Identifier flag (O): 2 bits
+
+         This is the number of full 32-bit words in the TOI field.  The
+         TOI field is 32*O + 16*H bits in length, i.e., the length is
+         either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96
+         bits, or 112 bits.
+
+     Half-word flag (H): 1 bit
+
+         The TSI and the TOI fields are both multiples of 32-bits plus
+         16*H bits in length.  This allows the TSI and TOI field lengths
+         to be multiples of a half-word (16 bits), while ensuring that
+         the aggregate length of the TSI and TOI fields is a multiple of
+         32-bits.
+
+     Sender Current Time present flag (T): 1 bit
+
+         T = 0 indicates that the Sender Current Time (SCT) field is not
+         present.  T = 1 indicates that the SCT field is present.  The
+         SCT is inserted by senders to indicate to receivers how long
+         the session has been in progress.
+
+     Expected Residual Time present flag (R): 1 bit
+
+         R = 0 indicates that the Expected Residual Time (ERT) field is
+         not present.  R = 1 indicates that the ERT field is present.
+         The ERT is inserted by senders to indicate to receivers how
+         much longer the session / object transmission will continue.
+
+         Senders MUST NOT set R = 1 when the ERT for the session is more
+         than 2^32-1 time units (approximately 49 days), where time is
+         measured in units of milliseconds.
+
+     Close Session flag (A): 1 bit
+
+         Normally, A is set to 0.  The sender MAY set A to 1 when
+         termination of transmission of packets for the session is
+         imminent.  A MAY be set to 1 in just the last packet
+         transmitted for the session, or A MAY be set to 1 in the last
+         few seconds of packets transmitted for the session.  Once the
+         sender sets A to 1 in one packet, the sender SHOULD set A to 1
+         in all subsequent packets until termination of transmission of
+
+
+
+Luby, et. al.                 Experimental                     [Page 14]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+         packets for the session.  A received packet with A set to 1
+         indicates to a receiver that the sender will immediately stop
+         sending packets for the session.  When a receiver receives a
+         packet with A set to 1 the receiver SHOULD assume that no more
+         packets will be sent to the session.
+
+     Close Object flag (B): 1 bit
+
+         Normally, B is set to 0.  The sender MAY set B to 1 when
+         termination of transmission of packets for an object is
+         imminent.  If the TOI field is in use and B is set to 1 then
+         termination of transmission for the object identified by the
+         TOI field is imminent.  If the TOI field is not in use and B is
+         set to 1 then termination of transmission for the one object in
+         the session identified by out-of-band information is imminent.
+         B MAY be set to 1 in just the last packet transmitted for the
+         object, or B MAY be set to 1 in the last few seconds packets
+         transmitted for the object.  Once the sender sets B to 1 in one
+         packet for a particular object, the sender SHOULD set B to 1 in
+         all subsequent packets for the object until termination of
+         transmission of packets for the object.  A received packet with
+         B set to 1 indicates to a receiver that the sender will
+         immediately stop sending packets for the object.  When a
+         receiver receives a packet with B set to 1 then it SHOULD
+         assume that no more packets will be sent for the object to the
+         session.
+
+     LCT header length (HDR_LEN): 8 bits
+
+         Total length of the LCT header in units of 32-bit words.  The
+         length of the LCT header MUST be a multiple of 32-bits.  This
+         field can be used to directly access the portion of the packet
+         beyond the LCT header, i.e., to the first other header if it
+         exists, or to the packet payload if it exists and there is no
+         other header, or to the end of the packet if there are no other
+         headers or packet payload.
+
+     Codepoint (CP): 8 bits
+
+         An opaque identifier which is passed to the packet payload
+         decoder to convey information on the codec being used for the
+         packet payload.  The mapping between the codepoint and the
+         actual codec is defined on a per session basis and communicated
+         out-of-band as part of the session description information.
+         The use of the CP field is similar to the Payload Type (PT)
+         field in RTP headers as described in RFC 1889 [21].
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 15]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     Congestion Control Information (CCI): 32, 64, 96 or 128 bits
+
+         Used to carry congestion control information.  For example, the
+         congestion control information could include layer numbers,
+         logical channel numbers, and sequence numbers.  This field is
+         opaque for the purpose of this specification.
+
+         This field MUST be 32 bits if C=0.
+         This field MUST be 64 bits if C=1.
+         This field MUST be 96 bits if C=2.
+         This field MUST be 128 bits if C=3.
+
+     Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
+
+         The TSI uniquely identifies a session among all sessions from a
+         particular sender.  The TSI is scoped by the IP address of the
+         sender, and thus the IP address of the sender and the TSI
+         together uniquely identify the session.  Although a TSI in
+         conjunction with the IP address of the sender always uniquely
+         identifies a session, whether or not the TSI is included in the
+         LCT header depends on what is used as the TSI value.  If the
+         underlying transport is UDP, then the 16 bit UDP source port
+         number MAY serve as the TSI for the session.  If the TSI value
+         appears multiple times in a packet then all occurrences MUST be
+         the same value.  If there is no underlying TSI provided by the
+         network, transport or any other layer, then the TSI MUST be
+         included in the LCT header.
+
+         The TSI MUST be unique among all sessions served by the sender
+         during the period when the session is active, and for a large
+         period of time preceding and following when the session is
+         active.  A primary purpose of the TSI is to prevent receivers
+         from inadvertently accepting packets from a sender that belong
+         to sessions other than the sessions receivers are subscribed
+         to.  For example, suppose a session is deactivated and then
+         another session is activated by a sender and the two sessions
+         use an overlapping set of channels.  A receiver that connects
+         and remains connected to the first session during this sender
+         activity could possibly accept packets from the second session
+         as belonging to the first session if the TSI for the two
+         sessions were identical.  The mapping of TSI field values to
+         sessions is outside the scope of this document and is to be
+         done out-of-band.
+
+         The length of the TSI field is 32*S + 16*H bits.  Note that the
+         aggregate lengths of the TSI field plus the TOI field is a
+         multiple of 32 bits.
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 16]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
+         bits.
+
+         This field indicates which object within the session this
+         packet pertains to.  For example, a sender might send a number
+         of files in the same session, using TOI=0 for the first file,
+         TOI=1 for the second one, etc. As another example, the TOI may
+         be a unique global identifier of the object that is being
+         transmitted from several senders concurrently, and the TOI
+         value may be the output of a hash function applied to the
+         object.  The mapping of TOI field values to objects is outside
+         the scope of this document and is to be done out-of-band.  The
+         TOI field MUST be used in all packets if more than one object
+         is to be transmitted in a session, i.e. the TOI field is either
+         present in all the packets of a session or is never present.
+
+         The length of the TOI field is 32*O + 16*H bits.  Note that the
+         aggregate lengths of the TSI field plus the TOI field is a
+         multiple of 32 bits.
+
+     Sender Current Time (SCT): 0 or 32 bits
+
+         This field represents the current clock at the sender and at
+         the time this packet was transmitted, measured in units of 1ms
+         and computed modulo 2^32 units from the start of the session.
+
+         This field MUST NOT be present if T=0 and MUST be present if
+         T=1.
+
+     Expected Residual Time (ERT): 0 or 32 bits
+
+         This field represents the sender expected residual transmission
+         time for the current session or for the transmission of the
+         current object, measured in units of 1ms.  If the packet
+         containing the ERT field also contains the TOI field, then ERT
+         refers to the object corresponding to the TOI field, otherwise
+         it refers to the session.
+
+         This field MUST NOT be present if R=0 and MUST be present if
+         R=1.
+
+5.2  Header-Extension Fields
+
+   Header Extensions are used in LCT to accommodate optional header
+   fields that are not always used or have variable size.  Examples of
+   the use of Header Extensions include:
+
+     o Extended-size versions of already existing header fields.
+
+
+
+Luby, et. al.                 Experimental                     [Page 17]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     o Sender and Receiver authentication information.
+
+   The presence of Header Extensions can be inferred by the LCT header
+   length (HDR_LEN): if HDR_LEN is larger than the length of the
+   standard header then the remaining header space is taken by Header
+   Extension fields.
+
+   If present, Header Extensions MUST be processed to ensure that they
+   are recognized before performing any congestion control procedure or
+   otherwise accepting a packet.  The default action for unrecognized
+   header extensions is to ignore them.  This allows the future
+   introduction of backward-compatible enhancements to LCT without
+   changing the LCT version number.  Non backward-compatible header
+   extensions CANNOT be introduced without changing the LCT version
+   number.
+
+   Protocol instantiation MAY override this default behavior for PI-
+   specific extensions (see below).
+
+   There are two formats for Header Extension fields, as depicted below.
+   The first format is used for variable-length extensions, with Header
+   Extension Type (HET) values between 0 and 127.  The second format is
+   used for fixed length (one 32-bit word) extensions, using HET values
+   from 127 to 255.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  HET (<=127)  |       HEL     |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+    .                                                               .
+    .              Header Extension Content (HEC)                   .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  HET (>=128)  |       Header Extension Content (HEC)          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 2 - Format of additional headers
+
+   The explanation of each sub-field is the following:
+
+     Header Extension Type (HET): 8 bits
+
+         The type of the Header Extension.  This document defines a
+         number of possible types.  Additional types may be defined in
+
+
+
+Luby, et. al.                 Experimental                     [Page 18]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+         future versions of this specification.  HET values from 0 to
+         127 are used for variable-length Header Extensions.  HET values
+         from 128 to 255 are used for fixed-length 32-bit Header
+         Extensions.
+
+     Header Extension Length (HEL): 8 bits
+
+         The length of the whole Header Extension field, expressed in
+         multiples of 32-bit words.  This field MUST be present for
+         variable-length extensions (HET between 0 and 127) and MUST NOT
+         be present for fixed-length extensions (HET between 128 and
+         255).
+
+     Header Extension Content (HEC): variable length
+
+         The content of the Header Extension.  The format of this sub-
+         field depends on the Header Extension type.  For fixed-length
+         Header Extensions, the HEC is 24 bits.  For variable-length
+         Header Extensions, the HEC field has variable size, as
+         specified by the HEL field.  Note that the length of each
+         Header Extension field MUST be a multiple of 32 bits.  Also
+         note that the total size of the LCT header, including all
+         Header Extensions and all optional header fields, cannot exceed
+         255 32-bit words.
+
+   Header Extensions are further divided between general LCT extensions
+   and Protocol Instantiation specific extensions (PI-specific).
+   General LCT extensions have HET in the ranges 0:63 and 128:191
+   inclusive.  PI-specific extensions have HET in the ranges 64:127 and
+   192:255 inclusive.
+
+   General LCT extensions are intended to allow the introduction of
+   backward-compatible enhancements to LCT without changing the LCT
+   version number.  Non backward-compatible header extensions CANNOT be
+   introduced without changing the LCT version number.
+
+   PI-specific extensions are reserved for PI-specific use with semantic
+   and default parsing actions defined by the PI.
+
+   The following general LCT Header Extension types are defined:
+
+   EXT_NOP=0     No-Operation extension.
+                 The information present in this extension field MUST be
+                 ignored by receivers.
+
+   EXT_AUTH=1    Packet authentication extension
+                 Information used to authenticate the sender of the
+                 packet.  The format of this Header Extension and its
+
+
+
+Luby, et. al.                 Experimental                     [Page 19]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+                 processing is outside the scope of this document and is
+                 to be communicated out-of-band as part of the session
+                 description.
+
+                 It is RECOMMENDED that senders provide some form of
+                 packet authentication.  If EXT_AUTH is present,
+                 whatever packet authentication checks that can be
+                 performed immediately upon reception of the packet
+                 SHOULD be performed before accepting the packet and
+                 performing any congestion control-related action on it.
+
+                 Some packet authentication schemes impose a delay of
+                 several seconds between when a packet is received and
+                 when the packet is fully authenticated.  Any congestion
+                 control related action that is appropriate MUST NOT be
+                 postponed by any such full packet authentication.
+
+   All senders and receivers implementing LCT MUST support the EXT_NOP
+   Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
+   parse its content.
+
+6.  Operations
+
+6.1  Sender Operation
+
+   Before joining an LCT session a receiver MUST obtain a session
+   description.  The session description MUST include:
+
+     o The sender IP address;
+
+     o The number of LCT channels;
+
+     o The addresses and port numbers used for each LCT channel;
+
+     o The Transport Session ID (TSI) to be used for the session;
+
+     o Enough information to determine the congestion control protocol
+       being used;
+
+     o Enough information to determine the packet authentication scheme
+       being used if it is being used.
+
+   The session description could also include, but is not limited to:
+
+     o The data rates used for each LCT channel;
+
+     o The length of the packet payload;
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 20]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+     o The mapping of TOI value(s) to objects for the session;
+
+     o Any information that is relevant to each object being
+       transported, such as when it will be available within the
+       session, for how long, and the length of the object;
+
+   Protocol instantiations using LCT MAY place additional requirements
+   on what must be included in the session description.  For example, a
+   protocol instantiation might require that the data rates for each
+   channel, or the mapping of TOI value(s) to objects for the session,
+   or other information related to other headers that might be required
+   to be included in the session description.
+
+   The session description could be in a form such as SDP as defined in
+   RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or
+   HTTP/Mime headers as defined in RFC 2068 [6], etc.  It might be
+   carried in a session announcement protocol such as SAP as defined in
+   RFC 2974 [9], obtained using a proprietary session control protocol,
+   located on a Web page with scheduling information, or conveyed via
+   E-mail or other out-of-band methods.  Discussion of session
+   description format, and distribution of session descriptions is
+   beyond the scope of this document.
+
+   Within an LCT session, a sender using LCT transmits a sequence of
+   packets, each in the format defined above.  Packets are sent from a
+   sender using one or more LCT channels which together constitute a
+   session.  Transmission rates may be different in different channels
+   and may vary over time.  The specification of the other building
+   block headers and the packet payload used by a complete protocol
+   instantiation using LCT is beyond the scope of this document.  This
+   document does not specify the order in which packets are transmitted,
+   nor the organization of a session into multiple channels.  Although
+   these issues affect the efficiency of the protocol, they do not
+   affect the correctness nor the inter-operability of LCT between
+   senders and receivers.
+
+   Several objects can be carried within the same LCT session.  In this
+   case, each object MUST be identified by a unique TOI.  Objects MAY be
+   transmitted sequentially, or they MAY be transmitted concurrently.
+   It is good practice to only send objects concurrently in the same
+   session if the receivers that participate in that portion of the
+   session have interest in receiving all the objects.  The reason for
+   this is that it wastes bandwidth and networking resources to have
+   receivers receive data for objects that they have no interest in.
+
+   Typically, the sender(s) continues to send packets in a session until
+   the transmission is considered complete.  The transmission may be
+   considered complete when some time has expired, a certain number of
+
+
+
+Luby, et. al.                 Experimental                     [Page 21]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   packets have been sent, or some out-of-band signal (possibly from a
+   higher level protocol) has indicated completion by a sufficient
+   number of receivers.
+
+   For the reasons mentioned above, this document does not pose any
+   restriction on packet sizes.  However, network efficiency
+   considerations recommend that the sender uses an as large as possible
+   packet payload size, but in such a way that packets do not exceed the
+   network's maximum transmission unit size (MTU), or when fragmentation
+   coupled with packet loss might introduce severe inefficiency in the
+   transmission.
+
+   It is recommended that all packets have the same or very similar
+   sizes, as this can have a severe impact on the effectiveness of
+   congestion control schemes such as the ones described in [22], [3],
+   and [25].  A sender of packets using LCT MUST implement the sender-
+   side part of one of the congestion control schemes that is in
+   accordance with RFC 2357 [13] using the Congestion Control
+   Information field provided in the LCT header, and the corresponding
+   receiver congestion control scheme is to be communicated out-of-band
+   and MUST be implemented by any receivers participating in the
+   session.
+
+6.2  Receiver Operation
+
+   Receivers can operate differently depending on the delivery service
+   model.  For example, for an on demand service model, receivers may
+   join a session, obtain the necessary packets to reproduce the object,
+   and then leave the session.  As another example, for a streaming
+   service model, a receiver may be continuously joined to a set of LCT
+   channels to download all objects in a session.
+
+   To be able to participate in a session, a receiver MUST obtain the
+   relevant session description information as listed in Section 6.1.
+
+   If packet authentication information is present in an LCT header, it
+   SHOULD be used as specified in Section 5.2.  To be able to be a
+   receiver in a session, the receiver MUST be able to process the LCT
+   header.  The receiver MUST be able to discard, forward, store or
+   process the other headers and the packet payload.  If a receiver is
+   not able to process a LCT header, it MUST drop from the session.
+
+   To be able to participate in a session, a receiver MUST implement the
+   congestion control protocol specified in the session description
+   using the Congestion Control Information field provided in the LCT
+   header. If a receiver is not able to implement the congestion control
+   protocol used in the session, it MUST NOT join the session.  When the
+   session is transmitted on multiple LCT channels, receivers MUST
+
+
+
+Luby, et. al.                 Experimental                     [Page 22]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   initially join channels according to the specified startup behavior
+   of the congestion control protocol.  For a multiple rate congestion
+   control protocol that uses multiple channels, this typically means
+   that a receiver will initially join only a minimal set of LCT
+   channels, possibly a single one, that in aggregate are carrying
+   packets at a low rate.  This rule has the purpose of preventing
+   receivers from starting at high data rates.
+
+   Several objects can be carried either sequentially or concurrently
+   within the same LCT session.  In this case, each object is identified
+   by a unique TOI.  Note that even if a server stops sending packets
+   for an old object before starting to transmit packets for a new
+   object, both the network and the underlying protocol layers can cause
+   some reordering of packets, especially when sent over different LCT
+   channels, and thus receivers SHOULD NOT assume that the reception of
+   a packet for a new object means that there are no more packets in
+   transit for the previous one, at least for some amount of time.
+
+   A receiver MAY be concurrently joined to multiple LCT sessions from
+   one or more senders.  The receiver MUST perform congestion control on
+   each such LCT session.  If the congestion control protocol allows the
+   receiver some flexibility in terms of its actions within a session
+   then the receiver MAY make choices to optimize the packet flow
+   performance across the multiple LCT sessions, as long as the receiver
+   still adheres to the congestion control rules for each LCT session
+   individually.
+
+7.  Requirements from Other Building Blocks
+
+   As described in RFC 3048 [23], LCT is a building block that is
+   intended to be used, in conjunction with other building blocks, to
+   help specify a protocol instantiation.  A congestion control building
+   block that uses the Congestion Control information field within the
+   LCT header MUST be used by any protocol instantiation that uses LCT,
+   and other building blocks MAY also be used, such as a reliability
+   building block.
+
+   The congestion control MUST be applied to the LCT session as an
+   entity, i.e., over the aggregate of the traffic carried by all of the
+   LCT channels associated with the LCT session.  Some possible schemes
+   are specified in [22], [3], and [25].  The Congestion Control
+   Information field in the LCT header is an opaque field that is
+   reserved to carry information related to congestion control.  There
+   MAY also be congestion control Header Extension fields that carry
+   additional information related to congestion control.
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 23]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   The particular layered encoder and congestion control protocols used
+   with LCT have an impact on the performance and applicability of LCT.
+   For example, some layered encoders used for video and audio streams
+   can produce a very limited number of layers, thus providing a very
+   coarse control in the reception rate of packets by receivers in a
+   session.  When LCT is used for reliable data transfer, some FEC
+   codecs are inherently limited in the size of the object they can
+   encode, and for objects larger than this size the reception overhead
+   on the receivers can grow substantially.
+
+   A more in-depth description of the use of FEC in Reliable Multicast
+   Transport (RMT) protocols is given in [11].  Some of the FEC codecs
+   that MAY be used in conjunction with LCT for reliable content
+   delivery are specified in [12].  The Codepoint field in the LCT
+   header is an opaque field that can be used to carry information
+   related to the encoding of the packet payload.
+
+   LCT also requires receivers to obtain a session description, as
+   described in Section 6.1.  The session description could be in a form
+   such as SDP as defined in RFC 2327 [8], or XML metadata as defined in
+   RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and
+   distributed with SAP as defined in RFC 2974 [9], using HTTP, or in
+   other ways.  It is RECOMMENDED that an authentication protocol such
+   as IPSEC [11] be used to deliver the session description to receivers
+   to ensure the correct session description arrives.
+
+   It is recommended that LCT implementors use some packet
+   authentication scheme to protect the protocol from attacks.  An
+   example of a possibly suitable scheme is described in [15].
+
+   Some protocol instantiations that use LCT MAY use building blocks
+   that require the generation of feedback from the receivers to the
+   sender.  However, the mechanism for doing this is outside the scope
+   of LCT.
+
+8.  Security Considerations
+
+   LCT can be subject to denial-of-service attacks by attackers which
+   try to confuse the congestion control mechanism, or send forged
+   packets to the session which would prevent successful reconstruction
+   or cause inaccurate reconstruction of large portions of an object by
+   receivers.  LCT is particularly affected by such an attack since many
+   receivers may receive the same forged packet.  It is therefore
+   RECOMMENDED that an integrity check be made on received objects
+   before delivery to an application, e.g., by appending an MD5 hash
+   [17] to an object before it is sent and then computing the MD5 hash
+   once the object is reconstructed to ensure it is the same as the sent
+   object.  Moreover, in order to obtain strong cryptographic integrity
+
+
+
+Luby, et. al.                 Experimental                     [Page 24]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   protection a digital signature verifiable by the receiver SHOULD be
+   computed on top of such a hash value.  It is also RECOMMENDED that
+   protocol instantiations that use LCT implement some form of packet
+   authentication such as TESLA [15] to protect against such attacks.
+   Finally, it is RECOMMENDED that Reverse Path Forwarding checks be
+   enabled in all network routers and switches along the path from the
+   sender to receivers to limit the possibility of a bad agent injecting
+   forged packets into the multicast tree data path.
+
+   Another vulnerability of LCT is the potential of receivers obtaining
+   an incorrect session description for the session.  The consequences
+   of this could be that legitimate receivers with the wrong session
+   description are unable to correctly receive the session content, or
+   that receivers inadvertently try to receive at a much higher rate
+   than they are capable of, thereby disrupting traffic in portions of
+   the network.  To avoid these problems, it is RECOMMENDED that
+   measures be taken to prevent receivers from accepting incorrect
+   Session Descriptions, e.g., by using source authentication to ensure
+   that receivers only accept legitimate Session Descriptions from
+   authorized senders.
+
+   A receiver with an incorrect or corrupted implementation of the
+   multiple rate congestion control building block may affect health of
+   the network in the path between the sender and the receiver, and may
+   also affect the reception rates of other receivers joined to the
+   session.  It is therefore RECOMMENDED that receivers be required to
+   identify themselves as legitimate before they receive the Session
+   Description needed to join the session.  How receivers identify
+   themselves as legitimate is outside the scope of this document.
+
+9.  IANA Considerations
+
+   No information in this specification is subject to IANA registration.
+
+   Building blocks used in conjunction with LCT MAY introduce additional
+   IANA considerations.
+
+10.  Acknowledgments
+
+   Thanks to Vincent Roca and Roger Kermode for detailed comments and
+   contributions to this document.  Thanks also to Bruce Lueckenhoff,
+   Hayder Radha and Justin Chapweske for detailed comments on this
+   document.
+
+11.  References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+
+
+Luby, et. al.                 Experimental                     [Page 25]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
+        Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for
+        Layered Multicast", Proceedings of Second International Workshop
+        on Networked Group Communications (NGC 2000), Palo Alto, CA,
+        November 2000.
+
+   [4]  Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital
+        Fountain Approach to Reliable Distribution of Bulk Data",
+        Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
+
+   [5]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+        1112, August 1989.
+
+   [6]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2616, January 1997.
+
+   [7]  Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File
+        Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January
+        2000.
+
+   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327, April 1998.
+
+   [9]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
+        Protocol", RFC 2974, October 2000.
+
+   [10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
+        Dissertation, Stanford University, Department of Computer
+        Science, Stanford, California, August 2001.
+
+   [11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
+        J. Crowcroft, "The Use of Forward Error Correction (FEC) in
+        Reliable Multicast", RFC 3453, December 2002.
+
+   [12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
+        J. Crowcroft, "Forward Error Correction (FEC) Building Block",
+        RFC 3452, December 2002.
+
+   [13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
+        Criteria for Evaluating Reliable Multicast Transport and
+        Application Protocols", RFC 2357, June 1998.
+
+   [14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
+        3023, January 2001.
+
+
+
+Luby, et. al.                 Experimental                     [Page 26]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+   [15] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and
+        Secure Source Authentication for Multicast", Network and
+        Distributed System Security Symposium, NDSS 2001, pp. 35-46,
+        February 2001.
+
+   [16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+        1980.
+
+   [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+        1992.
+
+   [18] Rizzo, L., "Effective Erasure Codes for Reliable Computer
+        Communication Protocols", ACM SIGCOMM Computer Communication
+        Review, Vol.27, No.2, pp.24-36, Apr 1997.
+
+   [19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast
+        congestion control scheme", Proceedings of SIGCOMM 2000,
+        Stockholm Sweden, August 2000.
+
+   [20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution
+        protocol based on software FEC techniques", Proceedings of the
+        Fourth IEEES Workshop on the Architecture and Implementation of
+        High Performance Communication Systems, HPCS'97, Chalkidiki
+        Greece, June 1997.
+
+   [21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP: A Transport Protocol for Real-Time Applications", RFC
+        1889, January 1996.
+
+   [22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion
+        Control for Layered Multicast Data Transfer", IEEE Infocom'98,
+        San Francisco, CA, Mar.28-Apr.1 1998.
+
+   [23] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
+        and M. Luby, "Reliable Multicast Transport Building Blocks for
+        One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
+
+   [24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable
+        Multicast Transport (RMT) Building Blocks and Protocol
+        Instantiation documents", RFC 3269, April 2002.
+
+   [25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation
+        Based Rate Control using Multicast Round-trip Time", Proceedings
+        of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 27]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+Authors' Addresses
+
+   Michael Luby
+   Digital Fountain
+   39141 Civic Center Dr.
+   Suite 300
+   Fremont, CA, USA, 94538
+
+   EMail: luby@digitalfountain.com
+
+   Jim Gemmell
+   Microsoft Research
+   455 Market St. #1690
+   San Francisco, CA, 94105
+
+   EMail: jgemmell@microsoft.com
+
+   Lorenzo Vicisano
+   cisco Systems, Inc.
+   170 West Tasman Dr.
+   San Jose, CA, USA, 95134
+
+   EMail: lorenzo@cisco.com
+
+   Luigi Rizzo
+   Dip. Ing. dell'Informazione,
+   Univ. di Pisa
+   via Diotisalvi 2, 56126 Pisa, Italy
+
+   EMail: luigi@iet.unipi.it
+
+   Mark Handley
+   ICIR
+   1947 Center St.
+   Berkeley, CA, USA, 94704
+
+   EMail: mjh@icir.org
+
+   Jon Crowcroft
+   Marconi Professor of Communications Systems
+   University of Cambridge
+   Computer Laboratory
+   William Gates Building
+   J J Thomson Avenue
+   Cambridge CB3 0FD, UK
+
+   EMail: Jon.Crowcroft@cl.cam.ac.uk
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 28]
+
+RFC 3451                   LCT Building Block              December 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.                 Experimental                     [Page 29]
+