doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc/rfc3450.txt b/doc/rfc/rfc3450.txt
new file mode 100644
index 0000000..2d9104d
--- /dev/null
+++ b/doc/rfc/rfc3450.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                            M. Luby
+Request for Comments: 3450                              Digital Fountain
+Category: Experimental                                        J. Gemmell
+                                                               Microsoft
+                                                             L. Vicisano
+                                                                   Cisco
+                                                                L. Rizzo
+                                                              Univ. Pisa
+                                                            J. Crowcroft
+                                                         Cambridge Univ.
+                                                           December 2002
+
+
+        Asynchronous Layered Coding (ALC) Protocol Instantiation
+
+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
+
+   This document describes the Asynchronous Layered Coding (ALC)
+   protocol, a massively scalable reliable content delivery protocol.
+   Asynchronous Layered Coding combines the Layered Coding Transport
+   (LCT) building block, a multiple rate congestion control building
+   block and the Forward Error Correction (FEC) building block to
+   provide congestion controlled reliable asynchronous delivery of
+   content to an unlimited number of concurrent receivers from a single
+   sender.
+
+Table of Contents
+
+   1. Introduction.................................................2
+     1.1 Delivery service models...................................3
+     1.2 Scalability...............................................5
+     1.3 Environmental Requirements and Considerations.............6
+   2. Architecture Definition......................................8
+     2.1 LCT building block........................................9
+     2.2 Multiple rate congestion control building block..........10
+     2.3 FEC building block.......................................11
+     2.4 Session Description......................................13
+
+
+
+Luby, et. al.               Experimental                        [Page 1]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+     2.5 Packet authentication building block.....................14
+   3. Conformance Statement.......................................14
+   4. Functionality Definition....................................14
+     4.1 Packet format used by ALC................................15
+     4.2 Detailed Example of Packet format used by ALC............16
+     4.3 Header-Extension Fields..................................23
+     4.4 Sender Operation.........................................26
+     4.5 Receiver Operation.......................................27
+   5. Security Considerations.....................................29
+   6. IANA Considerations.........................................31
+   7. Intellectual Property Issues................................31
+   8. Acknowledgments.............................................31
+   9. References..................................................31
+   Authors' Addresses.............................................33
+   Full Copyright Statement.......................................34
+
+1. Introduction
+
+   This document describes a massively scalable reliable content
+   delivery protocol, Asynchronous Layered Coding (ALC), for multiple
+   rate congestion controlled reliable content delivery.  The protocol
+   is specifically designed to provide massive scalability using IP
+   multicast as the underlying network service.  Massive scalability in
+   this context means the number of concurrent receivers for an object
+   is potentially in the millions, the aggregate size of objects to be
+   delivered in a session ranges from hundreds of kilobytes to hundreds
+   of gigabytes, each receiver can initiate reception of an object
+   asynchronously, the reception rate of each receiver in the session is
+   the maximum fair bandwidth available between that receiver and the
+   sender, and all of this can be supported using a single sender.
+
+   Because ALC is focused on reliable content delivery, the goal is to
+   deliver objects as quickly as possible to each receiver while at the
+   same time remaining network friendly to competing traffic.  Thus, the
+   congestion control used in conjunction with ALC should strive to
+   maximize use of available bandwidth between receivers and the sender
+   while at the same time backing off aggressively in the face of
+   competing traffic.
+
+   The sender side of ALC consists of generating packets based on
+   objects to be delivered within the session and sending the
+   appropriately formatted packets at the appropriate rates to the
+   channels associated with the session.  The receiver side of ALC
+   consists of joining appropriate channels associated with the session,
+   performing congestion control by adjusting the set of joined channels
+   associated with the session in response to detected congestion, and
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 2]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   using the packets to reliably reconstruct objects.  All information
+   flow in an ALC session is in the form of data packets sent by a
+   single sender to channels that receivers join to receive data.
+
+   ALC does specify the Session Description needed by receivers before
+   they join a session, but the mechanisms by which receivers obtain
+   this required information is outside the scope of ALC.  An
+   application that uses ALC may require that receivers report
+   statistics on their reception experience back to the sender, but the
+   mechanisms by which receivers report back statistics is outside the
+   scope of ALC.  In general, ALC is designed to be a minimal protocol
+   instantiation that provides reliable content delivery without
+   unnecessary limitations to the scalability of the basic protocol.
+
+   This document is a product of the IETF RMT WG and follows the general
+   guidelines provided in RFC 3269 [8].
+
+   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].
+
+   Statement of Intent
+
+      This memo contains part of the definitions necessary to fully
+      specify a Reliable Multicast Transport protocol in accordance with
+      RFC2357.  As per RFC2357, 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.
+
+1.1 Delivery service models
+
+   ALC can support several different reliable content delivery service
+   models.  Some examples are briefly described here.
+
+   Push service model.
+
+   A push model is a sender initiated concurrent delivery of objects to
+   a selected set of receivers.  A push service model can be used for
+   example for reliable delivery of a large object such as a 100 GB
+   file.  The sender could send a Session Description announcement to a
+
+
+
+Luby, et. al.               Experimental                        [Page 3]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   control channel and receivers could monitor this channel and join a
+   session whenever a Session Description of interest arrives.  Upon
+   receipt of the Session Description, each receiver could join the
+   session to receive packets until enough packets have arrived to
+   reconstruct the object, at which point the receiver could report back
+   to the sender that its reception was completed successfully.  The
+   sender could decide to continue sending packets for the object to the
+   session until all receivers have reported successful reconstruction
+   or until some other condition has been satisfied.  In this example,
+   the sender uses ALC to generate packets based on the object and send
+   packets to channels associated with the session, and the receivers
+   use ALC to receive packets from the session and reconstruct the
+   object.
+
+   There are several features ALC provides to support the push model.
+   For example, the sender can optionally include an Expected Residual
+   Time (ERT) in the packet header that indicates the expected remaining
+   time of packet transmission for either the single object carried in
+   the session or for the object identified by the Transmission Object
+   Identifier (TOI) if there are multiple objects carried in the
+   session.  This can be used by receivers to determine if there is
+   enough time remaining in the session to successfully receive enough
+   additional packets to recover the object.  If for example there is
+   not enough time, then the push application may have receivers report
+   back to the sender to extend the transmission of packets for the
+   object for enough time to allow the receivers to obtain enough
+   packets to reconstruct the object.  The sender could then include an
+   ERT based on the extended object transmission time in each subsequent
+   packet header for the object.  As other examples, the LCT header
+   optionally can contain a Close Session flag that indicates when the
+   sender is about to end sending packet to the session and a Close
+   Object flag that indicates when the sender is about to end sending
+   packets to the session for the object identified by the Transmission
+   Object ID.  However, these flags are not a completely reliable
+   mechanism and thus the Close Session flag should only be used as a
+   hint of when the session is about to close and the Close Object flag
+   should only be used as a hint of when transmission of packets for the
+   object is about to end.
+
+   The push model is particularly attractive in satellite networks and
+   wireless networks.  In these environments a session may include one
+   channel and a sender may send packets at a fixed rate to this
+   channel, but sending at a fixed rate without congestion control is
+   outside the scope of this document.
+
+
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 4]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   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 a
+   single object.  For example a popular software update might be
+   transmitted using ALC 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 at any point in time when it is active.
+   Receivers leave the session when they have received enough packets to
+   recover the object.  The receivers, for example, obtain a Session
+   Description by contacting a web server.
+
+   Other service models.
+
+   There may be other reliable content delivery service models that can
+   be supported by ALC.  The description of the potential applications,
+   the appropriate delivery service model, and the additional mechanisms
+   to support such functionalities when combined with ALC is beyond the
+   scope of this document.
+
+1.2 Scalability
+
+   Massive scalability is a primary design goal for ALC.  IP multicast
+   is inherently massively scalable, but the best effort service that it
+   provides does not provide session management functionality,
+   congestion control or reliability.  ALC provides all of this on top
+   of IP multicast without sacrificing any of the inherent scalability
+   of IP multicast.  ALC has the following properties:
+
+   o To each receiver, it appears as if though there is a dedicated
+     session from the sender to the receiver, where the reception rate
+     adjusts to congestion along the path from sender to receiver.
+
+   o To the sender, there is no difference in load or outgoing rate if
+     one receiver is joined to the session or a million (or any number
+     of) receivers are joined to the session, independent of when the
+     receivers join and leave.
+
+   o No feedback packets are required from receivers to the sender.
+
+   o Almost all packets in the session that pass through a bottleneck
+     link are utilized by downstream receivers, and the session shares
+     the link with competing flows fairly in proportion to their
+     utility.
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 5]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   Thus, ALC provides a massively scalable content delivery transport
+   that is network friendly.
+
+   ALC intentionally omits any application specific features that could
+   potentially limit its scalability.  By doing so, ALC provides a
+   minimal protocol that is massively scalable.  Applications may be
+   built on top of ALC to provide additional features that may limit the
+   scalability of the application.  Such applications are outside the
+   scope of this document.
+
+1.3  Environmental Requirements and Considerations
+
+   All of the environmental requirements and considerations that apply
+   to the LCT building block [11], the FEC building block [10], the
+   multiple rate congestion control building block and to any additional
+   building blocks that ALC uses also apply to ALC.
+
+   ALC requires connectivity between a sender and receivers, but does
+   not require connectivity from receivers to a sender.  ALC 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 ALC is unlimited.
+   However, ALC requires receivers to obtain the Session Description
+   out-of-band before joining a session and some implementations of this
+   may limit scalability.
+
+   If a receiver is joined to multiple ALC sessions then the receiver
+   MUST be able to uniquely identify and demultiplex packets to the
+   correct session.  The Transmission Session Identifier (TSI) that MUST
+   appear in each packet header is used for this purpose.  The TSI is
+   scoped by the IP address of the sender, and the IP address of the
+   sender together with the TSI uniquely identify the session.  Thus,
+   the demultiplexing MUST be done on the basis of the IP address of the
+   sender and the TSI of the session from that sender.
+
+   ALC is presumed to be used with an underlying IP multicast network or
+   transport service that is a "best effort" service that does not
+   guarantee packet reception, packet reception order, and which does
+   not have any support for flow or congestion control.  There are
+   currently two models of multicast delivery, the Any-Source Multicast
+   (ASM) model as defined in RFC 1112 [3] and the Source-Specific
+   Multicast (SSM) model as defined in [7].  ALC 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 an ALC channel address consists
+   of the pair (S,G), where S is the IP address of the sender and G is a
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 6]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   multicast group address.  When using SSM, a sender S sends packets to
+   an SSM channel (S,G), and an ALC channel address coincides with the
+   SSM channel address.
+
+   A sender can locally allocate unique SSM channel addresses, and this
+   makes allocation of ALC channel addresses easy with SSM.  To allocate
+   ALC channel addresses using ASM, the sender must uniquely choose the
+   ASM multicast group address across the scope of the group, and this
+   makes allocation of ALC channel addresses more difficult with ASM.
+
+   ALC channels and SSM channels coincide, and thus the receiver will
+   only receive packets sent to the requested ALC channel.  With ASM,
+   the receiver joins an ALC 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.
+
+   Other issues specific to ALC with respect to ASM is the way the
+   multiple rate congestion control building block interacts with ASM.
+   The congestion control building block may use the measured difference
+   in time between when a join to a channel is sent and when the first
+   packet from the channel arrives in determining the receiver reception
+   rate.  The congestion control building block may also uses packet
+   sequence numbers per channel to measure losses, and this is also used
+   to determine the receiver reception rate.  These features raise two
+   concerns with respect to ASM: The time difference between when the
+   join to a channel is sent and when the first packet arrives can be
+   significant due to the use of Rendezvous Points (RPs) and the MSDP
+   protocol, and packets can be lost in the switch over from the (*,G)
+   join to the RP and the (S,G) join directly to the sender.  Both of
+   these issues could potentially substantially degrade the reception
+   rate of receivers.  To ameliorate these concerns, it is RECOMMENDED
+   that the RP be as close to the sender as possible.  SSM does not
+   share these same concerns.  For a fuller consideration of these
+   issues, consult the multiple rate congestion control building block.
+
+   Some networks are not amenable to some congestion control protocols
+   that could be used with ALC.  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.
+
+   ALC is compatible with either IPv4 or IPv6 as no part of the packet
+   is IP version specific.
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 7]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+2.  Architecture Definition
+
+   ALC uses the LCT building block [11] to provide in-band session
+   management functionality.  ALC uses a multiple rate congestion
+   control building block that is compliant with RFC 2357 [12] to
+   provide congestion control that is feedback free.  Receivers adjust
+   their reception rates individually by joining and leaving channels
+   associated with the session.  ALC uses the FEC building block [10] to
+   provide reliability.  The sender generates encoding symbols based on
+   the object to be delivered using FEC codes and sends them in packets
+   to channels associated with the session.  Receivers simply wait for
+   enough packets to arrive in order to reliably reconstruct the object.
+   Thus, there is no request for retransmission of individual packets
+   from receivers that miss packets in order to assure reliable
+   reception of an object, and the packets and their rate of
+   transmission out of the sender can be independent of the number and
+   the individual reception experiences of the receivers.
+
+   The definition of a session for ALC is the same as it is for LCT.  An
+   ALC 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.  Congestion control is performed over the
+   aggregate of packets sent to channels belonging to a session.  The
+   fact that an ALC session is restricted to a single sender does not
+   preclude the possibility of receiving packets for the same objects
+   from multiple senders.  However, each sender would be sending packets
+   to a a different session to which congestion control is individually
+   applied.  Although receiving concurrently from multiple sessions is
+   allowed, how this is done at the application level is outside the
+   scope of this document.
+
+   ALC is a protocol instantiation as defined in RFC 3048 [16].  This
+   document describes version 1 of ALC which MUST use version 1 of LCT
+   described in [11].  Like LCT, ALC is designed to be used with the IP
+   multicast network service.  This specification defines ALC as payload
+   of the UDP transport protocol [15] that supports IP multicast
+   delivery of packets.  Future versions of this specification, or
+   companion documents may extend ALC to use the IP network layer
+   service directly.  ALC could be used as the basis for designing a
+   protocol that uses a different underlying network service such as
+   unicast UDP, but the design of such a protocol is outside the scope
+   of this document.
+
+   An ALC packet header immediately follows the UDP header and consists
+   of the default LCT header that is described in [11] followed by the
+   FEC Payload ID that is described in [10].  The Congestion Control
+   Information field within the LCT header carries the required
+
+
+
+Luby, et. al.               Experimental                        [Page 8]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   Congestion Control Information that is described in the multiple rate
+   congestion control building block specified that is compliant with
+   RFC 2357 [12].  The packet payload that follows the ALC packet header
+   consists of encoding symbols that are identified by the FEC Payload
+   ID as described in [10].
+
+   Each receiver is required to obtain a Session Description before
+   joining an ALC session.  As described later, the Session Description
+   includes out-of-band information required for the LCT, FEC and the
+   multiple rate congestion control building blocks.  The FEC Object
+   Transmission Information specified in the FEC building block [10]
+   required for each object to be received by a receiver can be
+   communicated to a receiver either out-of-band or in-band using a
+   Header Extension.  The means for communicating the Session
+   Description and the FEC Object Transmission Information to a receiver
+   is outside the scope of this document.
+
+2.1  LCT building block
+
+   LCT requires receivers to be able to uniquely identify and
+   demultiplex packets associated with an LCT session, and ALC inherits
+   and strengthens this requirement.  A Transport Session Identifier
+   (TSI) MUST be associated with each session and MUST be carried in the
+   LCT header of each ALC packet.  The TSI is scoped by the sender IP
+   address, and the (sender IP address, TSI) pair MUST uniquely identify
+   the session.
+
+   The LCT header contains a Congestion Control Information (CCI) field
+   that MUST be used to carry the Congestion Control Information from
+   the specified multiple rate congestion control protocol.  There is a
+   field in the LCT header that specifies the length of the CCI field,
+   and the multiple rate congestion control building block MUST uniquely
+   identify a format of the CCI field that corresponds to this length.
+
+   The LCT header contains a Codepoint field that MAY be used to
+   communicate to a receiver the settings for information that may vary
+   during a session.  If used, the mapping between settings and
+   Codepoint values is to be communicated in the Session Description,
+   and this mapping is outside the scope of this document.  For example,
+   the FEC Encoding ID that is part of the FEC Object Transmission
+   Information as specified in the FEC building block [10] could vary
+   for each object carried in the session, and the Codepoint value could
+   be used to communicate the FEC Encoding ID to be used for each
+   object.  The mapping between FEC Encoding IDs and Codepoints could
+   be, for example, the identity mapping.
+
+
+
+
+
+
+Luby, et. al.               Experimental                        [Page 9]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   If more than one object is to be carried within a session then the
+   Transmission Object Identifier (TOI) MUST be used in the LCT header
+   to identify which packets are to be associated with which objects.
+   In this case the receiver MUST use the TOI to associate received
+   packets with objects.  The TOI is scoped by the IP address of the
+   sender and the TSI, i.e., the TOI is scoped by the session.  The TOI
+   for each object is REQUIRED to be unique within a session, but MAY
+   NOT be unique across sessions.  Furthermore, the same object MAY have
+   a different TOI in different sessions.  The mapping between TOIs and
+   objects carried in a session is outside the scope of this document.
+
+   If only one object is carried within a session then the TOI MAY be
+   omitted from the LCT header.
+
+   The default LCT header from version 1 of the LCT building block [11]
+   MUST be used.
+
+2.2  Multiple rate congestion control building block
+
+   Implementors of ALC MUST implement a multiple rate feedback-free
+   congestion control building block that is in accordance to RFC 2357
+   [12].  Congestion control MUST be applied to all packets within a
+   session independently of which information about which object is
+   carried in each packet.  Multiple rate congestion control is
+   specified because of its suitability to scale massively and because
+   of its suitability for reliable content delivery.  The multiple rate
+   congestion control building block MUST specify in-band Congestion
+   Control Information (CCI) that MUST be carried in the CCI field of
+   the LCT header.  The multiple rate congestion control building block
+   MAY specify more than one format, but it MUST specify at most one
+   format for each of the possible lengths 32, 64, 96 or 128 bits.  The
+   value of C in the LCT header that determines the length of the CCI
+   field MUST correspond to one of the lengths for the CCI defined in
+   the multiple rate congestion control building block, this length MUST
+   be the same for all packets sent to a session, and the CCI format
+   that corresponds to the length as specified in the multiple rate
+   congestion control building block MUST be the format used for the CCI
+   field in the LCT header.
+
+   When using a multiple rate congestion control building block a sender
+   sends packets in the session to several channels at potentially
+   different rates.  Then, individual receivers adjust their reception
+   rate within a session by adjusting which set of channels they are
+   joined to at each point in time depending on the available bandwidth
+   between the receiver and the sender, but independent of other
+   receivers.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 10]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+2.3  FEC building block
+
+   The FEC building block [10] provides reliable object delivery within
+   an ALC session.  Each object sent in the session is independently
+   encoded using FEC codes as described in [9], which provide a more
+   in-depth description of the use of FEC codes in reliable content
+   delivery protocols.  All packets in an ALC session MUST contain an
+   FEC Payload ID in a format that is compliant with the FEC building
+   block [10].  The FEC Payload ID uniquely identifies the encoding
+   symbols that constitute the payload of each packet, and the receiver
+   MUST use the FEC Payload ID to determine how the encoding symbols
+   carried in the payload of the packet were generated from the object
+   as described in the FEC building block.
+
+   As described in [10], a receiver is REQUIRED to obtain the FEC Object
+   Transmission Information for each object for which data packets are
+   received from the session.  The FEC Object Transmission Information
+   includes:
+
+     o The FEC Encoding ID.
+
+     o If an Under-Specified FEC Encoding ID is used then the FEC
+       Instance ID associated with the FEC Encoding ID.
+
+     o For each object in the session, the length of the object in
+       bytes.
+
+     o The additional required FEC Object Transmission Information for
+       the FEC Encoding ID as prescribed in the FEC building block [10].
+       For example, when the FEC Encoding ID is 128, the required FEC
+       Object Transmission Information is the number of source blocks
+       that the object is partitioned into and the length of each source
+       block in bytes.
+
+   Some of the FEC Object Transmission Information MAY be implicit based
+   on the implementation.  As an example, source block lengths may be
+   derived by a fixed algorithm from the object length.  As another
+   example, it may be that all source blocks are the same length and
+   this is what is passed out-of-band to the receiver.  As another
+   example, it could be that the full sized source block length is
+   provided and this is the length used for all but the last source
+   block, which is calculated based on the full source block length and
+   the object length.  As another example, it could be that the same FEC
+   Encoding ID and FEC Instance ID are always used for a particular
+   application and thus the FEC Encoding ID and FEC Instance ID are
+   implicitly defined.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 11]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   Sometimes the objects that will be sent in a session are completely
+   known before the receiver joins the session, in which case the FEC
+   Object Transmission Information for all objects in the session can be
+   communicated to receivers before they join the session.  At other
+   times the objects may not know when the session begins, or receivers
+   may join a session in progress and may not be interested in some
+   objects for which transmission has finished, or receivers may leave a
+   session before some objects are even available within the session.
+   In these cases, the FEC Object Transmission Information for each
+   object may be dynamically communicated to receivers at or before the
+   time packets for the object are received from the session.  This may
+   be accomplished using either an out-of-band mechanism, in-band using
+   the Codepoint field or a Header Extension, or any combination of
+   these methods.  How the FEC Object Transmission Information is
+   communicated to receivers is outside the scope of this document.
+
+   If packets for more than one object are transmitted within a session
+   then a Transmission Object Identifier (TOI) that uniquely identifies
+   objects within a session MUST appear in each packet header.  Portions
+   of the FEC Object Transmission Information could be the same for all
+   objects in the session, in which case these portions can be
+   communicated to the receiver with an indication that this applies to
+   all objects in the session.  These portions may be implicitly
+   determined based on the application, e.g., an application may use the
+   same FEC Encoding ID for all objects in all sessions.  If there is a
+   portion of the FEC Object Transmission Information that may vary from
+   object to object and if this FEC Object Transmission Information is
+   communicated to a receiver out-of-band then the TOI for the object
+   MUST also be communicated to the receiver together with the
+   corresponding FEC Object Transmission Information, and the receiver
+   MUST use the corresponding FEC Object Transmission Information for
+   all packets received with that TOI.  How the TOI and corresponding
+   FEC Object Transmission Information is communicated out-of-band to
+   receivers is outside the scope of this document.
+
+   It is also possible that there is a portion of the FEC Object
+   Transmission Information that may vary from object to object that is
+   carried in-band, for example in the CodePoint field or in Header
+   Extensions.  How this is done is outside the scope of this document.
+   In this case the FEC Object Transmission Information is associated
+   with the object identified by the TOI carried in the packet.
+
+
+
+
+
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 12]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+2.4  Session Description
+
+   The Session Description that a receiver is REQUIRED to obtain before
+   joining an ALC session MUST contain the following information:
+
+     o The multiple rate congestion control building block to be used
+       for the session;
+
+     o The sender IP address;
+
+     o The number of channels in the session;
+
+     o The address and port number used for each channel in the session;
+
+     o The Transport Session ID (TSI) to be used for the session;
+
+     o An indication of whether or not the session carries packets for
+       more than one object;
+
+     o If Header Extensions are to be used, the format of these Header
+       Extensions.
+
+     o Enough information to determine the packet authentication scheme
+       being used, if it is being used.
+
+   How the Session Description is communicated to receivers is outside
+   the scope of this document.
+
+   The Codepoint field within the LCT portion of the header CAN be used
+   to communicate in-band some of the dynamically changing information
+   within a session.  To do this, a mapping between Codepoint values and
+   the different dynamic settings MUST be included within the Session
+   Description, and then settings to be used are communicated via the
+   Codepoint value placed into each packet.  For example, it is possible
+   that multiple objects are delivered within the same session and that
+   a different FEC encoding algorithm is used for different types of
+   objects.  Then the Session Description could contain the mapping
+   between Codepoint values and FEC Encoding IDs.  As another example,
+   it is possible that a different packet authentication scheme is used
+   for different packets sent to the session.  In this case, the mapping
+   between the packet authentication scheme and Codepoint values could
+   be provided in the Session Description.  Combinations of settings can
+   be mapped to Codepoint values as well.  For example, a particular
+   combination of a FEC Encoding ID and a packet authentication scheme
+   could be associated with a Codepoint value.
+
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 13]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   The Session Description could also include, but is not limited to:
+
+     o The mappings between combinations of settings and Codepoint
+       values;
+
+     o The data rates used for each channel;
+
+     o The length of the packet payload;
+
+     o Any information that is relevant to each object being
+       transported, such as the Object Transmission Information for each
+       object, when the object will be available within the session and
+       for how long.
+
+   The Session Description could be in a form such as SDP as defined in
+   RFC 2327 [5], or XML metadata as defined in RFC 3023 [13], or
+   HTTP/Mime headers as defined in RFC 2068 [4], etc.  It might be
+   carried in a session announcement protocol such as SAP as defined in
+   RFC 2974 [6], 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 formats and methods for communication of Session
+   Descriptions to receivers is beyond the scope of this document.
+
+2.5  Packet authentication building block
+
+   It is RECOMMENDED that implementors of ALC use some packet
+   authentication scheme to protect the protocol from attacks.  An
+   example of a possibly suitable scheme is described in [14].  Packet
+   authentication in ALC, if used, is to be integrated through the
+   Header Extension support for packet authentication provided in the
+   LCT building block.
+
+3.  Conformance Statement
+
+   This Protocol Instantiation document, in conjunction with the LCT
+   building block [11], the FEC building block [10] and with a multiple
+   rate congestion control building block completely specifies a working
+   reliable multicast transport protocol that conforms to the
+   requirements described in RFC 2357 [12].
+
+4.  Functionality Definition
+
+   This section describes the format and functionality of the data
+   packets carried in an ALC session as well as the sender and receiver
+   operations for a session.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 14]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+4.1  Packet format used by ALC
+
+   The packet format used by ALC is the UDP header followed by the
+   default LCT header followed by the FEC Payload ID followed by the
+   packet payload.  The default LCT header is described in the LCT
+   building block [11] and the FEC Payload ID is described in the FEC
+   building block [10].  The Congestion Control Information field in the
+   LCT header contains the REQUIRED Congestion Control Information that
+   is described in the multiple rate congestion control building block
+   used.  The packet payload contains encoding symbols generated from an
+   object.  If more than one object is carried in the session then the
+   Transmission Object ID (TOI) within the LCT header MUST be used to
+   identify which object the encoding symbols are generated from.
+   Within the scope of an object, encoding symbols carried in the
+   payload of the packet are identified by the FEC Payload ID as
+   described in the FEC building block.
+
+   The version number of ALC specified in this document is 1.  This
+   coincides with version 1 of the LCT building block [11] used in this
+   specification.  The LCT version number field should be interpreted as
+   the ALC version number field.
+
+   The overall ALC packet format is depicted in Figure 1.  The packet is
+   an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP
+   header.  The ALC packet format has no dependencies on the IP version
+   number.  The default LCT header MUST be used by ALC and this default
+   is described in detail in the LCT building block [11].
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         UDP header                            |
+    |                                                               |
+    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+    |                     Default LCT header                        |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       FEC Payload ID                          |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Encoding Symbol(s)                        |
+    |                           ...                                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 1 - Overall ALC packet format
+
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 15]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   In some special cases an ALC sender may need to produce ALC packets
+   that do not contain any payload.  This may be required, for example,
+   to signal the end of a session or to convey congestion control
+   information.  These data-less packets do not contain the FEC Payload
+   ID either, but only the LCT header fields.  The total datagram
+   length, conveyed by outer protocol headers (e.g., the IP or UDP
+   header), enables receivers to detect the absence of the ALC payload
+   and FEC Payload ID.
+
+4.2  Detailed Example of Packet format used by ALC
+
+   A detailed example of an ALC packet starting with the LCT header is
+   shown in Figure 2.  In the example, the LCT header is the first 5
+   32-bit words, the FEC Payload ID is the next 2 32-bit words, and the
+   remainder of the packet is the payload.
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   1   | 0 | 0 |1| 1 |0|1|0|0|0|       5       |      128      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Congestion Control Information (CCI, length = 32 bits)     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |  Transport Session Identifier (TSI, length = 32 bits)         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Transport Object Identifier (TOI, length = 32 bits)         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Sender Current Time                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Source Block Number                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Encoding Symbol ID                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Encoding Symbol(s)                         |
+    |                          ...                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 2 - A detailed example of the ALC packet format
+
+   The LCT portion of the overall ALC packet header is of variable size,
+   which is specified by a length field in the third byte of the 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).
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 16]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   The function and length and particular setting of the value for each
+   field in this detailed example of the header is the following,
+   described in the order of their appearance in the header.
+
+     ALC version number (V): 4 bits
+
+         Indicates the ALC version number.
+         The ALC version number for this specification is 1 as shown.
+         This is also the LCT version number.
+
+     Congestion control flag (C): 2 bits
+
+         The Congestion Control Information (CCI) field specified by the
+         multiple rate congestion control building block is a multiple
+         of 32-bits in length.  The multiple rate congestion control
+         building block MUST specify a format for the CCI.  The
+         congestion control building block MAY specify formats for
+         different CCI lengths, where the set of possible lengths is 32,
+         64, 96 or 128 bits.  The value of C MUST match the length of
+         exactly one of the possible formats for the congestion control
+         building block, and this format MUST be used for the CCI field.
+         The value of C MUST be the same for all packets sent to a
+         session.
+
+         C=0 indicates the 32-bit CCI field format is to be used.
+         C=1 indicates the 64-bit CCI field format is to be used.
+         C=2 indicates the 96-bit CCI field format is to be used.
+         C=3 indicates the 128-bit CCI field format is to be used.
+
+         In the example C=0 indicates that a 32-bit format is to be
+         used.
+
+     Reserved (r): 2 bits
+
+         Reserved for future use.  A sender MUST set these bits to zero
+         and a receiver MUST ignore these bits.
+
+         As required, these bits are set to 0 in the example.
+
+     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.  For ALC the length of
+         the TSI field is REQUIRED to be non-zero.  This implies that
+         the setting S=0 and H=0 MUST NOT be used.
+
+         In the example S=1 and H=0, and thus the TSI is 32-bits in
+         length.
+
+
+
+Luby, et. al.               Experimental                       [Page 17]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+     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.  If more than one
+         object is to be delivered in the session then the TOI MUST be
+         used, in which case the setting O=0 and H=0 MUST NOT be used.
+
+         In the example O=1 and H=0, and thus the TOI is 32-bits in
+         length.
+
+     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.
+
+         In the example H=0 which indicates that both TSI and TOI are
+         both multiples of 32-bits in length.
+
+     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.
+
+         In the example T=1, which indicates that the SCT is carried in
+         this packet.
+
+     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 packets will be sent to the session for either the
+         single object carried in the session or for the object
+         identified by the TOI if there are multiple objects carried in
+         the session.  Senders MUST NOT set R = 1 when the ERT for the
+         object is more than 2^32-1 time units (approximately 49 days),
+         where time is measured in units of milliseconds.
+
+         In the example R=0, which indicates that the ERT is not carried
+         in this packet.
+
+
+
+Luby, et. al.               Experimental                       [Page 18]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+     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
+         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.
+
+         In the example A=0, and thus this packet does not indicate the
+         close of 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.
+
+         In the example B=0, and thus this packet does not indicate the
+         end of sending data packets for the object.
+
+     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., the FEC Payload ID if the packet
+
+
+
+Luby, et. al.               Experimental                       [Page 19]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+         contains a payload, or the end of the packet if the packet
+         contains no payload.
+
+         In the example HDR_LEN=5 to indicate that the length of the LCT
+         header portion of the overall ALC is 5 32-bit words.
+
+     Codepoint (CP): 8 bits
+
+         This field is used by ALC to carry the mapping that identifies
+         settings for portions of the Session Description that can
+         change within the session.  The mapping between Codepoint
+         values and the settings for portions of the Session Description
+         is to be communicated out-of-band.
+
+         In the example the portion of the Session Description that can
+         change within the session is the FEC Encoding ID, and the
+         identity mapping is used between Codepoint values and FEC
+         Encoding IDs.  Thus, CP=128 identifies FEC Encoding ID 128, the
+         "Small Block, Large Block and Expandable FEC Codes" as
+         described in the FEC building block [10].  The FEC Payload ID
+         associated with FEC Encoding ID 128 is 64-bits in length.
+
+     Congestion Control Information (CCI): 32, 64, 96 or 128 bits
+
+         This is field contains the Congestion Control Information as
+         defined by the specified multiple rate congestion control
+         building block.  The format of this field is determined by the
+         multiple rate congestion control building block.
+
+         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.
+
+         In the example, the CCI is 32-bits in length.  The format of
+         the CCI field for the example MUST correspond to the format for
+         the 32-bit version of the CCI specified in the multiple rate
+         congestion control building block.
+
+     Transport Session Identifier (TSI): 16, 32 or 48 bits
+
+         The TSI uniquely identifies a session among all sessions from a
+         particular sender.  The TSI is scoped by the sender IP address,
+         and thus the (sender IP address, TSI) pair uniquely identify
+         the session.  For ALC, the TSI MUST be included in the LCT
+         header.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 20]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+         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 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.
+
+         In the example the TSI is 32 bits in length.
+
+     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.
+
+         In the example the TOI is 32 bits in length.
+
+
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 21]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+     Sender Current Time (SCT): 0 or 32 bits
+
+         This field represents the current clock of the sender 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.
+
+         In this example the SCT is present.
+
+     Expected Residual Time (ERT): 0 or 32 bits
+
+         This field represents the sender expected residual transmission
+         time of packets for either the single object carried in the
+         session or for the object identified by the TOI if there are
+         multiple objects carried in the session.
+
+         This field MUST NOT be present if R=0 and MUST be present if
+         R=1.
+
+         In this example the ERT is not present.
+
+     FEC Payload ID: X bits
+
+         The length and format of the FEC Payload ID depends on the FEC
+         Encoding ID as described in the FEC building block [10].  The
+         FEC Payload ID format is determined by the FEC Encoding ID that
+         MUST be communicated in the Session Description.  The Session
+         Description MAY specify that more than one FEC Encoding ID is
+         used in the session, in which case the Session Description MUST
+         contain a mapping that identifies which Codepoint values
+         correspond to which FEC Encoding IDs.  This mapping, if used,
+         is outside the scope of this document.
+
+         The example packet format corresponds to the format for "Small
+         Block, Large Block and Expandable FEC Codes" as described in
+         the FEC building block, for which the associated FEC Encoding
+         ID 128.  For FEC Encoding ID 128, the FEC Payload ID consists
+         of the following two fields that in total are X = 64 bits in
+         length:
+
+         Source Block Number (SBN): 32 bits
+
+            The Source Block Number identifies from which source block
+            of the object the encoding symbol(s) in the payload are
+            generated.  These blocks are numbered consecutively from
+
+
+
+
+Luby, et. al.               Experimental                       [Page 22]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+            0 to N-1, where N is the number of source blocks in the
+            object.
+
+         Encoding Symbol ID (ESI): 32 bits
+
+            The Encoding Symbol ID identifies which specific encoding
+            symbol(s) generated from the source block are carried in the
+            packet payload.  The exact details of the correspondence
+            between Encoding Symbol IDs and the encoding symbol(s) in
+            the packet payload are dependent on the particular encoding
+            algorithm used as identified by the FEC Encoding ID and by
+            the FEC Instance ID.
+
+   Encoding Symbol(s): Y bits
+
+         The encoding symbols are what the receiver uses to reconstruct
+         an object.  The total length Y of the encoding symbol(s) in the
+         packet can be determined by the receiver of the packet by
+         computing the total length of the received packet and
+         subtracting off the length of the headers.
+
+4.3  Header-Extension Fields
+
+   Header Extensions can be used to extend the LCT header portion of the
+   ALC header to accommodate optional header fields that are not always
+   used or have variable size.  Header Extensions are not used in the
+   example ALC packet format shown in the previous subsection.  Examples
+   of the use of Header Extensions include:
+
+     o Extended-size versions of already existing header fields.
+
+     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 ALC without
+   changing the ALC version number.  Non backward-compatible Header
+   Extensions CANNOT be introduced without changing the ALC version
+   number.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 23]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   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 3 - 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
+         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
+
+
+
+Luby, et. al.               Experimental                       [Page 24]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+         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
+                 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 ALC MUST support the EXT_NOP
+   Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
+   parse its content.
+
+
+
+Luby, et. al.               Experimental                       [Page 25]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   For this version of ALC, the following PI-specific extension is
+   defined:
+
+   EXT_FTI=64    FEC Object Transmission Information extension
+                 The purpose of this extension is to carry in-band the
+                 FEC Object Transmission Information for an object.  The
+                 format of this Header Extension and its processing is
+                 outside the scope of this document and is to be
+                 communicated out-of-band as part of the Session
+                 Description.
+
+4.4  Sender Operation
+
+   The sender operation when using ALC includes all the points made
+   about the sender operation when using the LCT building block [11],
+   the FEC building block [10] and the multiple rate congestion control
+   building block.
+
+   A sender using ALC MUST make available the required Session
+   Description as described in Section 2.4.  A sender also MUST make
+   available the required FEC Object Transmission Information as
+   described in Section 2.3.
+
+   Within a session a sender transmits a sequence of packets to the
+   channels associated with the session.  The ALC sender MUST obey the
+   rules for filling in the CCI field in the packet headers and MUST
+   send packets at the appropriate rates to the channels associated with
+   the session as dictated by the multiple rate congestion control
+   building block.
+
+   The ALC sender MUST use the same TSI for all packets in the session.
+   Several objects MAY be delivered within the same ALC session.  If
+   more than one object is to be delivered within a session then the
+   sender MUST use the TOI field and each object MUST be identified by a
+   unique TOI within the session, and the sender MUST use corresponding
+   TOI for all packets pertaining to the same object.  The FEC Payload
+   ID MUST correspond to the encoding symbol(s) for the object carried
+   in the payload of the packet.
+
+   Objects MAY be transmitted sequentially within a session, and they
+   MAY be transmitted concurrently.  However, 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.  However, there are no rules
+   with respect to mixing packets for different objects carried within
+   the session.  Although this issue affects the efficiency of the
+
+
+
+Luby, et. al.               Experimental                       [Page 26]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   protocol, it does not affect the correctness nor the inter-
+   operability of ALC between senders and receivers.
+
+   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
+   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.
+
+   It is RECOMMENDED that packet authentication be used.  If packet
+   authentication is used then the Header Extensions described in
+   Section 4.3 MUST be used to carry the authentication.
+
+   This document does not pose any restriction on packet sizes.
+   However, network efficiency considerations recommend that the sender
+   uses 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 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 the multiple rate congestion
+   control building block.
+
+4.5  Receiver Operation
+
+   The receiver operation when using ALC includes all the points made
+   about the receiver operation when using the LCT building block [11],
+   the FEC building block [10] and the multiple rate congestion control
+   building block.
+
+   To be able to participate in a session, a receiver MUST obtain the
+   REQUIRED Session Description as listed in Section 2.4.  How receivers
+   obtain a Session Description is outside the scope of this document.
+
+   To be able to be a receiver in a session, the receiver MUST be able
+   to process the ALC 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 the ALC header, it MUST drop
+   from the session.
+
+   To be able to participate in a session, a receiver MUST implement the
+   multiple rate congestion control building block using the Congestion
+   Control Information field provided in the LCT header.  If a receiver
+   is not able to implement the multiple rate congestion control
+   building block it MUST NOT join the session.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 27]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   Several objects can be carried either sequentially or concurrently
+   within the same session.  In this case, each object is identified by
+   a unique TOI.  Note that even if a sender 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 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.
+
+   As described in Section 2.3, a receiver MUST obtain the required FEC
+   Object Transmission Information for each object for which the
+   receiver receives and processes packets.
+
+   A receiver MAY concurrently join multiple ALC sessions from one or
+   more senders.  The receiver MUST perform congestion control on each
+   such session.  The receiver MAY make choices to optimize the packet
+   flow performance across multiple sessions, as long as the receiver
+   still adheres to the multiple rate congestion control building block
+   for each session individually.
+
+   Upon receipt of each packet the receiver proceeds with the following
+   steps in the order listed.
+
+   (1) The receiver MUST parse the packet header and verify that it is a
+       valid header.  If it is not valid then the packet MUST be
+       discarded without further processing.  If multiple packets are
+       received that cannot be parsed then the receiver SHOULD leave the
+       session.
+
+   (2) The receiver MUST verify that the sender IP address together with
+       the TSI carried in the header matches one of the (sender IP
+       address, TSI) pairs that was received in a Session Description
+       and that the receiver is currently joined to.  If there is not a
+       match then the packet MUST be discarded without further
+       processing.  If multiple packets are received with non-matching
+       (sender IP address, TSI) values then the receiver SHOULD leave
+       the session.  If the receiver is joined to multiple ALC sessions
+       then the remainder of the steps are performed within the scope of
+       the (sender IP address, TSI) session of the received packet.
+
+   (3) The receiver MUST process and act on the CCI field in accordance
+       with the multiple rate congestion control building block.
+
+   (4) If more than one object is carried in the session, the receiver
+       MUST verify that the TOI carried in the LCT header is valid.  If
+       the TOI is not valid, the packet MUST be discarded without
+       further processing.
+
+
+
+Luby, et. al.               Experimental                       [Page 28]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   (5) The receiver SHOULD process the remainder of the packet,
+       including interpreting the other header fields appropriately, and
+       using the FEC Payload ID and the encoding symbol(s) in the
+       payload to reconstruct the corresponding object.
+
+   It is RECOMMENDED that packet authentication be used.  If packet
+   authentication is used then it is RECOMMENDED that the receiver
+   immediately check the authenticity of a packet before proceeding with
+   step (3) above.  If immediate checking is possible and if the packet
+   fails the check then the receiver MUST discard the packet and reduce
+   its reception rate to a minimum before continuing to regulate its
+   reception rate using the multiple rate congestion control.
+
+   Some packet authentication schemes such as TESLA [14] do not allow an
+   immediate authenticity check.  In this case the receiver SHOULD check
+   the authenticity of a packet as soon as possible, and if the packet
+   fails the check then it MUST be discarded before step (5) above and
+   reduce its reception rate to a minimum before continuing to regulate
+   its reception rate using the multiple rate congestion control.
+
+5.  Security Considerations
+
+   The same security consideration that apply to the LCT, FEC and the
+   multiple rate congestion control building blocks also apply to ALC.
+
+   Because of the use of FEC, ALC is especially vulnerable to denial-
+   of-service attacks by attackers that try to send forged packets to
+   the session which would prevent successful reconstruction or cause
+   inaccurate reconstruction of large portions of the object by
+   receivers.  ALC is also particularly affected by such an attack
+   because many receivers may receive the same forged packet.  There are
+   two ways to protect against such attacks, one at the application
+   level and one at the packet level.  It is RECOMMENDED that prevention
+   be provided at both levels.
+
+   At the application level, it is RECOMMENDED that an integrity check
+   on the entire received object be done once the object is
+   reconstructed to ensure it is the same as the sent object.  Moreover,
+   in order to obtain strong cryptographic integrity protection a
+   digital signature verifiable by the receiver SHOULD be used to
+   provide this application level integrity check.  However, if even one
+   corrupted or forged packet is used to reconstruct the object, it is
+   likely that the received object will be reconstructed incorrectly.
+   This will appropriately cause the integrity check to fail and in this
+   case the inaccurately reconstructed object SHOULD be discarded.
+   Thus, the acceptance of a single forged packet can be an effective
+   denial of service attack for distributing objects, but an object
+   integrity check at least prevents inadvertent use of inaccurately
+
+
+
+Luby, et. al.               Experimental                       [Page 29]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   reconstructed objects.  The specification of an application level
+   integrity check of the received object is outside the scope of this
+   document.
+
+   At the packet level, it is RECOMMENDED that a packet level
+   authentication be used to ensure that each received packet is an
+   authentic and uncorrupted packet containing FEC data for the object
+   arriving from the specified sender.  Packet level authentication has
+   the advantage that corrupt or forged packets can be discarded
+   individually and the received authenticated packets can be used to
+   accurately reconstruct the object.  Thus, the effect of a denial of
+   service attack that injects forged packets is proportional only to
+   the number of forged packets, and not to the object size.  Although
+   there is currently no IETF standard that specifies how to do
+   multicast packet level authentication, TESLA [14] is a known
+   multicast packet authentication scheme that would work.
+
+   In addition to providing protection against reconstruction of
+   inaccurate objects, packet level authentication can also provide some
+   protection against denial of service attacks on the multiple rate
+   congestion control.  Attackers can try to inject forged packets with
+   incorrect congestion control information into the multicast stream,
+   thereby potentially adversely affecting network elements and
+   receivers downstream of the attack, and much less significantly the
+   rest of the network and other receivers.  Thus, it is also
+   RECOMMENDED that packet level authentication be used to protect
+   against such attacks.  TESLA [14] can also be used to some extent to
+   limit the damage caused by such attacks.  However, with TESLA a
+   receiver can only determine if a packet is authentic several seconds
+   after it is received, and thus an attack against the congestion
+   control protocol can be effective for several seconds before the
+   receiver can react to slow down the session reception rate.
+
+   Reverse Path Forwarding checks SHOULD 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.
+
+   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.
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 30]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   Another vulnerability of ALC 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.  How this is done is outside the scope of this
+   document.
+
+6.  IANA Considerations
+
+   No information in this specification is directly subject to IANA
+   registration.  However, building blocks components used by ALC may
+   introduce additional IANA considerations.  In particular, the FEC
+   building block used by ALC does require IANA registration of the FEC
+   codecs used.
+
+7.  Intellectual Property Issues
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+8.  Acknowledgments
+
+   Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their
+   detailed comments on this document.
+
+9.  References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+        1112, August 1989.
+
+   [4]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2616, January 1997.
+
+
+
+
+Luby, et. al.               Experimental                       [Page 31]
+
+RFC 3450               ALC protocol instantiation          December 2002
+
+
+   [5]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327, April 1998.
+
+   [6]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
+        Protocol", RFC 2974, October 2000.
+
+   [7]  Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
+        Dissertation, Stanford University, Department of Computer
+        Science, Stanford, California, August 2001.
+
+   [8]  Kermode, R., Vicisano, L., "Author Guidelines for Reliable
+        Multicast Transport (RMT) Building Blocks and Protocol
+        Instantiation documents", RFC 3269, April 2002.
+
+   [9]  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.
+
+   [10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
+        J.  Crowcroft, "Forward Error Correction (FEC) Building Block",
+        RFC 3452, December 2002.
+
+   [11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
+        J.  Crowcroft, "Layered Coding Transport (LCT) Building Block",
+        RFC 3451 December 2002.
+
+   [12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
+        Criteria for Evaluating Reliable Multicast Transport and
+        Application Protocols", RFC 2357, June 1998.
+
+   [13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
+        3023, January 2001.
+
+   [14] 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.
+
+   [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+        1980.
+
+   [16] 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.
+
+
+
+
+
+
+
+Luby, et. al.               Experimental                       [Page 32]
+
+RFC 3450               ALC protocol instantiation          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
+
+
+   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 33]
+
+RFC 3450               ALC protocol instantiation          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 34]
+