doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc5775.txt b/doc/rfc/rfc5775.txt
new file mode 100644
index 0000000..607120b
--- /dev/null
+++ b/doc/rfc/rfc5775.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           M. Luby
+Request for Comments: 5775                                     M. Watson
+Obsoletes: 3450                                              L. Vicisano
+Category: Standards Track                                 Qualcomm, Inc.
+ISSN: 2070-1721                                               April 2010
+
+
+        Asynchronous Layered Coding (ALC) Protocol Instantiation
+
+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.  This document obsoletes RFC 3450.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5775.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Luby, et al.                 Standards Track                    [Page 1]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Delivery Service Models  . . . . . . . . . . . . . . . . .  4
+     1.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Environmental Requirements and Considerations  . . . . . .  5
+   2.  Architecture Definition  . . . . . . . . . . . . . . . . . . .  5
+     2.1.  LCT Building Block . . . . . . . . . . . . . . . . . . . .  7
+     2.2.  Multiple Rate Congestion Control Building Block  . . . . .  9
+     2.3.  FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
+     2.4.  Session Description  . . . . . . . . . . . . . . . . . . . 11
+     2.5.  Packet Authentication Building Block . . . . . . . . . . . 12
+   3.  Conformance Statement  . . . . . . . . . . . . . . . . . . . . 12
+   4.  Functionality Definition . . . . . . . . . . . . . . . . . . . 13
+     4.1.  Packet Format Used by ALC  . . . . . . . . . . . . . . . . 13
+     4.2.  LCT Header Extension Fields  . . . . . . . . . . . . . . . 14
+     4.3.  Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
+     4.4.  Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+     5.1.  Baseline Secure ALC Operation  . . . . . . . . . . . . . . 18
+       5.1.1.  IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
+       5.1.2.  IPsec Requirements . . . . . . . . . . . . . . . . . . 19
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
+   8.  Changes from RFC 3450  . . . . . . . . . . . . . . . . . . . . 21
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+Luby, et al.                 Standards Track                    [Page 2]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+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
+   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 [RFC3269].
+
+
+
+
+
+Luby, et al.                 Standards Track                    [Page 3]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   A previous version of this document was published in the
+   "Experimental" category as [RFC3450] and is obsoleted by this
+   document.
+
+   This Proposed Standard specification is thus based on and backwards
+   compatible with the protocol defined in [RFC3450] updated according
+   to accumulated experience and growing protocol maturity since its
+   original publication.  Said experience applies both to this
+   specification itself and to congestion control strategies related to
+   the use of this specification.
+
+   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, [RFC2119].
+
+1.1.  Delivery Service Models
+
+   ALC can support several different reliable content delivery service
+   models as described in [RFC5651].
+
+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 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 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.
+
+   Thus, ALC provides a massively scalable content delivery transport
+   that is network friendly.
+
+
+
+
+
+Luby, et al.                 Standards Track                    [Page 4]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   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 [RFC5651], the FEC building block
+   [RFC5052], the multiple rate congestion control building block, and
+   to any additional building blocks that ALC uses also apply to ALC.
+
+   The IP multicast model defined in [RFC1112] is commonly known as Any-
+   Source Multicast (ASM), in contrast to Source-Specific Multicast
+   (SSM) which is defined in [RFC3569].  One issue that is 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 use 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 Multicast Source
+   Discovery Protocol (MSDP) [RFC3618] 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 during deployment to ensure 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.
+
+2.  Architecture Definition
+
+   ALC uses the LCT building block [RFC5651] to provide in-band session
+   management functionality.  ALC uses a multiple rate congestion
+   control building block that is compliant with [RFC2357] 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
+   [RFC5052] 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
+
+
+
+Luby, et al.                 Standards Track                    [Page 5]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   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 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 [RFC3048].  This
+   document describes version 1 of ALC, which MUST use version 1 of LCT
+   described in [RFC5651].  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 [RFC0768] that supports the IP
+   multicast delivery of packets.
+
+   The ALC packet format is illustrated in Figure 1.  An ALC packet
+   header immediately follows the IP/UDP header and consists of the
+   default LCT header that is described in [RFC5651] followed by the FEC
+   Payload ID that is described in [RFC5052].  The Congestion Control
+   Information field within the LCT header carries the required
+   Congestion Control Information that is described in the multiple rate
+   congestion control building block specified that is compliant with
+   [RFC2357].  The packet payload that follows the ALC packet header
+   consists of encoding symbols that are identified by the FEC Payload
+   ID as described in [RFC5052].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et al.                 Standards Track                    [Page 6]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+               +----------------------------------------+
+               |               IP Header                |
+               +----------------------------------------+
+               |              UDP Header                |
+               +----------------------------------------+
+               |              LCT Header                |
+               +----------------------------------------+
+               |            FEC Payload Id              |
+               +----------------------------------------+
+               |           Encoding Symbols             |
+               +----------------------------------------+
+
+                        Figure 1: ALC Packet Format
+
+   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
+   [RFC5052] 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
+
+
+
+Luby, et al.                 Standards Track                    [Page 7]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   Information, as specified in the FEC building block [RFC5052], 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.
+
+   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 is not
+   required 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 LCT header from version 1 of the LCT building block [RFC5651]
+   MUST be used.
+
+   The LCT Header includes a two-bit Protocol Specific Indication (PSI)
+   field in bits 6 and 7 of the first word of the LCT header.  These two
+   bits are used by ALC as follows:
+
+       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
+                  +-+-+
+               ...|X|Y|...
+                  +-+-+
+
+                   Figure 2: PSI Bits within LCT Header
+
+      PSI bit X - Source Packet Indicator (SPI)
+
+      PSI bit Y - Reserved
+
+   The Source Packet Indicator is used with systematic FEC Schemes which
+   define a different FEC Payload ID format for packets containing only
+   source data compared to the FEC Payload ID format for packets
+   containing repair data.  For such FEC Schemes, the SPI MUST be set to
+   1 when the FEC Payload ID format for packets containing only source
+   data is used, and the SPI MUST be set to zero when the FEC Payload ID
+   for packets containing repair data is used.  In the case of FEC
+
+
+
+
+Luby, et al.                 Standards Track                    [Page 8]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   Schemes that define only a single FEC Payload ID format, the SPI MUST
+   be set to zero by the sender and MUST be ignored by the receiver.
+
+   Support of two FEC Payload ID formats allows FEC Payload ID
+   information that is only of relevance when FEC decoding is to be
+   performed to be provided in the FEC Payload ID format for packets
+   containing repair data.  This information need not be processed by
+   receivers that do not perform FEC decoding (either because no FEC
+   decoding is required or because the receiver does not support FEC
+   decoding).
+
+2.2.  Multiple Rate Congestion Control Building Block
+
+   At a minimum, implementations of ALC MUST support [RFC3738].  Note
+   that [RFC3738] has been published in the "Experimental" category and
+   thus has lower maturity level than the present document.  Caution
+   should be used since it may be less stable than this document.
+
+   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.  [RFC3738] specifies in-band
+   Congestion Control Information (CCI) that MUST be carried in the CCI
+   field of the LCT header.
+
+   Alternative multiple rate congestion control building blocks MAY be
+   supported, but only a single congestion control building block may be
+   used in a given ALC session.  The congestion control building block
+   to be used in an ALC session is specified in the Session Description
+   (see Section 2.4).  A multiple rate congestion control building block
+   MAY specify more than one format for the CCI field, 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 to which set of channels
+   they are joined at each point in time depending on the available
+   bandwidth between the receiver and the sender, but independent of
+   other receivers.
+
+
+
+Luby, et al.                 Standards Track                    [Page 9]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+2.3.  FEC Building Block
+
+   The FEC building block [RFC5052] provides reliable object delivery
+   within an ALC session.  Each object sent in the session is
+   independently encoded using FEC codes as described in [RFC3453],
+   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 Scheme in use.  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 [RFC5052], a receiver is REQUIRED to obtain the FEC
+   Object Transmission Information for each object for which data
+   packets are received from the session.  In the context of ALC, 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 transfer length of the object
+      in bytes.
+
+   Additional FEC Object Transmission Information may be required
+   depending on the FEC Scheme that is used (identified by the FEC
+   Encoding ID).
+
+   Some of the FEC Object Transmission Information MAY be implicit based
+   on the FEC Scheme and/or 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.
+
+   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
+
+
+
+Luby, et al.                 Standards Track                   [Page 10]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   times, the objects may not know when the session begins, 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 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.
+
+2.4.  Session Description
+
+   Before a receiver can join an ALC session, the receiver needs to
+   obtain a Session Description that contains 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 one 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
+
+
+
+Luby, et al.                 Standards Track                   [Page 11]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   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.
+
+   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 the Session
+   Description Protocol (SDP) as defined in [RFC4566], XML metadata as
+   defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616],
+   etc.  It might be carried in a session announcement protocol such as
+   SAP as defined in [RFC2974], obtained using a proprietary session
+   control protocol, located on a web page with scheduling information,
+   or conveyed via email 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.  Suitable
+   schemes are described in [RFC5776] and [RMT-SIMPLE].
+
+3.  Conformance Statement
+
+   This Protocol Instantiation document, in conjunction with the LCT
+   building block [RFC5651], the FEC building block [RFC5052], and
+   [RFC3738] completely specifies a working reliable multicast transport
+   protocol that conforms to the requirements described in [RFC2357].
+
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 12]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+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.
+
+4.1.  Packet Format Used by ALC
+
+   The packet format used by ALC is the UDP header followed by the LCT
+   header followed by the FEC Payload ID followed by the packet payload.
+   The LCT header is defined in the LCT building block [RFC5651] and the
+   FEC Payload ID is described in the FEC building block [RFC5052].  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 from
+   which object the encoding symbols are generated.  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.  The
+   version number field of the LCT header MUST be interpreted as the ALC
+   version number field.  This version of ALC implicitly makes use of
+   version 1 of the LCT building block defined in [RFC5651].
+
+   The overall ALC packet format is depicted in Figure 3.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 13]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+        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                            |
+       |                                                               |
+       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+       |                         LCT Header                            |
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                       FEC Payload ID                          |
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                     Encoding Symbol(s)                        |
+       |                           ...                                 |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 3: Overall ALC Packet Format
+
+   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.
+
+   For ALC, the length of the TSI field within the LCT header is
+   REQUIRED to be non-zero.  This implies that the sender MUST NOT set
+   both the LCT flags S and H to zero.
+
+4.2.  LCT Header Extension Fields
+
+   This specification defines a new LCT Header Extension, "EXT_FTI", for
+   the purpose of communicating the FEC Object Transmission Information
+   in association with data packets of an object.  The LCT Header
+   Extension Type for EXT_FTI is 64.
+
+   The Header Extension Content (HEC) field of the EXT_FTI LCT Header
+   Extension contains the encoded FEC Object Transmission Information as
+   defined in [RFC5052].  The format of the encoded FEC Object
+   Transmission Information is dependent on the FEC Scheme in use and so
+   is outside the scope of this document.
+
+
+
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 14]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+4.3.  Sender Operation
+
+   The sender operation, when using ALC, includes all the points made
+   about the sender operation when using the LCT building block
+   [RFC5651], the FEC building block [RFC5052], and the multiple rate
+   congestion control building block.
+
+   A sender using ALC should make available the required Session
+   Description as described in Section 2.4.  A sender should also 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 it 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.  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.
+
+   It is RECOMMENDED that packet authentication be used.  If packet
+   authentication is used, then the Header Extensions described in
+   Section 4.2 MAY be used to carry the authentication.
+
+4.4.  Receiver Operation
+
+   The receiver operation, when using ALC, includes all the points made
+   about the receiver operation when using the LCT building block
+   [RFC5651], the FEC building block [RFC5052], and the multiple rate
+   congestion control building block.
+
+   To be able to participate in a session, a receiver needs to obtain
+   the required Session Description as listed in Section 2.4.  How
+   receivers obtain a Session Description is outside the scope of this
+   document.
+
+   As described in Section 2.3, a receiver needs to obtain the required
+   FEC Object Transmission Information for each object for which the
+   receiver receives and processes packets.
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 15]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   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.
+
+   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 to which the receiver is currently joined.  If there is not a
+       match, then the packet MUST be silently discarded without further
+       processing.  The remaining 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.
+
+   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 silently discard the packet.
+
+5.  Security Considerations
+
+   The same security considerations that apply to the LCT, FEC, and the
+   multiple rate congestion control building blocks also apply to ALC.
+
+   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.
+
+
+
+Luby, et al.                 Standards Track                   [Page 16]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   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
+   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 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.
+   [RMT-SIMPLE]and [RFC5776] described packet level authentication
+   schemes that can be used with the ALC protocol.
+
+   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.  Timed Efficient Stream Loss-Tolerant
+   Authentication (TESLA) [RFC5776] 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.
+
+   Some packet authentication schemes such as TESLA [RFC5776] do not
+   allow an immediate authenticity check.  In this case, the receiver
+
+
+
+Luby, et al.                 Standards Track                   [Page 17]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   SHOULD check the authenticity of a packet as soon as possible, and if
+   the packet fails the check, then it MUST be silently discarded before
+   Step 5 above.  It is RECOMMENDED that if receivers detect many
+   packets that fail authentication checks within a session, the above
+   procedure should be modified for this session so that Step 3 is
+   delayed until after the authentication check and only performed if
+   the check succeeds.
+
+   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.
+
+5.1.  Baseline Secure ALC Operation
+
+   This section describes a baseline mode of secure ALC protocol
+   operation based on application of the IPsec security protocol.  This
+   approach is documented here to provide a reference of an
+   interoperable secure mode of operation.  However, additional
+   approaches to ALC security, including other forms of IPsec
+   application, MAY be specified in the future.  For example, the use of
+   the EXT_AUTH Header Extension could enable ALC-specific
+   authentication or security encapsulation headers similar to those of
+   IPsec to be specified and inserted into the ALC/LCT protocol message
+   headers.  This would allow header compression techniques to be
+   applied to IP and ALC protocol headers when needed in a similar
+   fashion to that of RTP [RFC3550] and as preserved in the
+   specification for Secure Real Time Protocol (SRTP) [RFC3711].
+
+   The baseline approach described is applicable to ALC operation
+   configured for SSM (or SSM-like) operation where there is a single
+   sender.  The receiver set would maintain a single IPsec Security
+   Association (SA) for each ALC sender.
+
+5.1.1.  IPsec Approach
+
+   To support this baseline form of secure ALC one-to-many SSM
+   operation, each node SHALL be configured with a transport mode IPsec
+   Security Association and corresponding Security Policy Database (SPD)
+   entry.  This entry will be used for sender-to-group multicast packet
+   authentication and optionally encryption.
+
+   The ALC sender SHALL use an IPsec SA configured for Encapsulating
+   Security Payload (ESP) protocol [RFC4303] operation with the option
+   for data origination authentication enabled.  It is also RECOMMENDED
+   that this IPsec ESP SA be also configured to provide confidentiality
+   protection for IP packets containing ALC protocol messages.  This is
+   suggested to make the realization of complex replay attacks much more
+
+
+
+Luby, et al.                 Standards Track                   [Page 18]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   difficult.  The encryption key for this SA SHALL be preplaced at the
+   sender and receiver(s) prior to ALC protocol operation.  Use of
+   automated key management is RECOMMENDED as a rekey SHALL be required
+   prior to expiration of the sequence space for the SA.  This is
+   necessary so that receivers may use the built-in IPsec replay attack
+   protection possible for an IPsec SA with a single source (the ALC
+   sender).  Thus, the receivers SHALL enable replay attack protection
+   for this SA used to secure ALC sender traffic.  The sender IPsec SPD
+   entry MUST be configured to process outbound packets to the
+   destination address and UDP port number of the applicable ALC
+   session.
+
+   The ALC receiver(s) MUST be configured with the SA and SPD entry to
+   properly process the IPsec-secured packets from the sender.  Note
+   that use of ESP confidentiality, as RECOMMENDED, for secure ALC
+   protocol operation makes it more difficult for adversaries to conduct
+   effective replay attacks that may mislead receivers on content
+   reception.  This baseline approach can be used for ALC protocol
+   sessions with multiple senders if a distinct SA is established for
+   each sender.
+
+   In early deployments of this baseline approach to ALC security, it is
+   anticipated that key management will be conducted out-of-band with
+   respect to ALC protocol operation.  For ALC unidirectional operation,
+   it is possible that receivers may retrieve keying information from a
+   central server via out-of-band (with respect to ALC) communication as
+   needed or otherwise conduct group key updates with a similar
+   centralized approach.  However, it may be possible with some key
+   management schemes for rekey messages to be transmitted to the group
+   as a message or transport object within the ALC reliable transfer
+   session.  An additional specification is necessary to define an in-
+   band key management scheme for ALC sessions perhaps using the
+   mechanisms of the automated group key management specifications cited
+   in this document.
+
+5.1.2.  IPsec Requirements
+
+   In order to implement this secure mode of ALC protocol operation, the
+   following IPsec capabilities are required.
+
+5.1.2.1.  Selectors
+
+   The implementation MUST be able to use the source address,
+   destination address, protocol (UDP), and UDP port numbers as
+   selectors in the SPD.
+
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 19]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+5.1.2.2.  Mode
+
+   IPsec in transport mode MUST be supported.  The use of IPsec
+   [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED
+   such that unauthenticated packets are not received by the ALC
+   protocol implementation.
+
+5.1.2.3.  Key Management
+
+   An automated key management scheme for group key distribution and
+   rekeying such as the Group Domain of Interpretation (GDOI) [RFC3547],
+   Group Secure Association Key Management Protocol (GSAKMP) [RFC4535],
+   or Multimedia Internet KEYing (MIKEY) [RFC3830] SHOULD be used.
+   Relatively short-lived ALC sessions MAY be able to use Manual Keying
+   with a single, preplaced key, particularly if Extended Sequence
+   Numbering (ESN) [RFC4303] is available in the IPsec implementation
+   used.  It should also be noted that it may be possible for key update
+   messages (e.g., the GDOI GROUPKEY-PUSH message) to be included in the
+   ALC application reliable data transmission as transport objects if
+   appropriate interfaces were available between the ALC application and
+   the key management daemon.
+
+5.1.2.4.  Security Policy
+
+   Receivers SHOULD accept connections only from the designated,
+   authorized sender(s).  It is expected that appropriate key management
+   will provide encryption keys only to receivers authorized to
+   participate in a designated session.  The approach outlined here
+   allows receiver sets to be controlled on a per-sender basis.
+
+5.1.2.5.  Authentication and Encryption
+
+   Large ALC group sizes may necessitate some form of key management
+   that does rely upon shared secrets.  The GDOI and GSAKMP protocols
+   mentioned here allow for certificate-based authentication.  These
+   certificates SHOULD use IP addresses for authentication.  However, it
+   is likely that available group key management implementations will
+   not be ALC-specific.
+
+5.1.2.6.  Availability
+
+   The IPsec requirements profile outlined here is commonly available on
+   many potential ALC hosts.  The principal issue is that configuration
+   and operation of IPsec typically requires privileged user
+   authorization.  Automated key management implementations are
+   typically configured with the privileges necessary to allow the
+   needed system IPsec configuration.
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 20]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+6.  IANA Considerations
+
+   This specification registers one value in the LCT Header Extensions
+   Types namespace as follows:
+
+                 +-------+---------+--------------------+
+                 | Value | Name    | Reference          |
+                 +-------+---------+--------------------+
+                 | 64    | EXT_FTI | This specification |
+                 +-------+---------+--------------------+
+
+7.  Acknowledgments
+
+   This specification is substantially based on RFC 3450 [RFC3450] and
+   thus credit for the authorship of this document is primarily due to
+   the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano,
+   Luigi Rizzo, and Jon Crowcroft.  Vincent Roca, Justin Chapweske, and
+   Roger Kermode also contributed to RFC 3450.  Additional thanks are
+   due to Vincent Roca and Rod Walsh for contributions to this update to
+   Proposed Standard.
+
+8.  Changes from RFC 3450
+
+   This section summarizes the changes that were made from the
+   "Experimental" version of this specification published as RFC 3450
+   [RFC3450]:
+
+   o  Updated all references to the obsoleted RFC 2068 to RFC 2616.
+
+   o  Removed the 'Statement of Intent' from the introduction.  (The
+      Statement of Intent was meant to clarify the "Experimental" status
+      of RFC 3450.)
+
+   o  Removed the 'Intellectual Property Issues' Section and replaced
+      with a standard IPR Statement.
+
+   o  Removed material duplicated in LCT.
+
+   o  Updated references in this document to new versions of the LCT
+      Building Block and the FEC Building Block, and aligned this
+      document with changes in the new version of the FEC Building
+      Block.
+
+   o  Split normative and informative references.
+
+   o  Material applicable in a general LCT context, not just for ALC has
+      been moved to LCT.
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 21]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   o  The first bit of the "Protocol-Specific Indication" in the LCT
+      Header is defined as a "Source Packet Indication".  This is used
+      in the case that an FEC Scheme defines two FEC Payload ID formats,
+      one of which is for packets containing only source symbols that
+      can be processed by receivers that do not support FEC Decoding.
+
+   o  Definition and IANA registration of the EXT_FTI LCT Header
+      Extension.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0768]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                 August 1980.
+
+   [RFC1112]     Deering, S., "Host extensions for IP multicasting",
+                 STD 5, RFC 1112, August 1989.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3023]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+                 Types", RFC 3023, January 2001.
+
+   [RFC3738]     Luby, M. and V. Goyal, "Wave and Equation Based Rate
+                 Control (WEBRC) Building Block", RFC 3738, April 2004.
+
+   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
+                 Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
+                 RFC 4303, December 2005.
+
+   [RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
+                 Session Description Protocol", RFC 4566, July 2006.
+
+   [RFC5052]     Watson, M., Luby, M., and L. Vicisano, "Forward Error
+                 Correction (FEC) Building Block", RFC 5052,
+                 August 2007.
+
+   [RFC5651]     Luby, M., Watson, M., and L. Vicisano, "Layered Coding
+                 Transport (LCT) Building Block", RFC 5651,
+                 October 2009.
+
+
+
+Luby, et al.                 Standards Track                   [Page 22]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+9.2.  Informative References
+
+   [RFC2357]     Mankin, A., Romanov, A., Bradner, S., and V. Paxson,
+                 "IETF Criteria for Evaluating Reliable Multicast
+                 Transport and Application Protocols", RFC 2357,
+                 June 1998.
+
+   [RFC2974]     Handley, M., Perkins, C., and E. Whelan, "Session
+                 Announcement Protocol", RFC 2974, October 2000.
+
+   [RFC3048]     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.
+
+   [RFC3269]     Kermode, R. and L. Vicisano, "Author Guidelines for
+                 Reliable Multicast Transport (RMT) Building Blocks and
+                 Protocol Instantiation documents", RFC 3269,
+                 April 2002.
+
+   [RFC3450]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
+                 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
+                 Instantiation", RFC 3450, December 2002.
+
+   [RFC3453]     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.
+
+   [RFC3547]     Baugher, M., Weis, B., Hardjono, T., and H. Harney,
+                 "The Group Domain of Interpretation", RFC 3547,
+                 July 2003.
+
+   [RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and V.
+                 Jacobson, "RTP: A Transport Protocol for Real-Time
+                 Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3569]     Bhattacharyya, S., "An Overview of Source-Specific
+                 Multicast (SSM)", RFC 3569, July 2003.
+
+   [RFC3618]     Fenner, B. and D. Meyer, "Multicast Source Discovery
+                 Protocol (MSDP)", RFC 3618, October 2003.
+
+   [RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
+                 K. Norrman, "The Secure Real-time Transport Protocol
+                 (SRTP)", RFC 3711, March 2004.
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 23]
+
+RFC 5775               ALC Protocol Instantiation             April 2010
+
+
+   [RFC3830]     Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
+                 K. Norrman, "MIKEY: Multimedia Internet KEYing",
+                 RFC 3830, August 2004.
+
+   [RFC4535]     Harney, H., Meth, U., Colegrove, A., and G. Gross,
+                 "GSAKMP: Group Secure Association Key Management
+                 Protocol", RFC 4535, June 2006.
+
+   [RFC5776]     Roca, V., Francillon, A., and S. Faurite, "Use of Timed
+                 Efficient Stream Loss-Tolerant Authentication (TESLA)
+                 in the Asynchronous Layered Coding (ALC) and NACK-
+                 Oriented Reliable Multicast (NORM) Protocols",
+                 RFC 5776, April 2010.
+
+   [RMT-SIMPLE]  Roca, V., "Simple Authentication Schemes for the ALC
+                 and NORM Protocols", Work in Progress, October 2009.
+
+Authors' Addresses
+
+   Michael Luby
+   Qualcomm, Inc.
+   3165 Kifer Road
+   Santa Clara, CA  95051
+   US
+
+   EMail: luby@qualcomm.com
+
+
+   Mark Watson
+   Qualcomm, Inc.
+   3165 Kifer Road
+   Santa Clara, CA  95051
+   US
+
+   EMail: watson@qualcomm.com
+
+
+   Lorenzo Vicisano
+   Qualcomm, Inc.
+   3165 Kifer Road
+   Santa Clara, CA  95051
+   US
+
+   EMail: vicisano@qualcomm.com
+
+
+
+
+
+
+
+Luby, et al.                 Standards Track                   [Page 24]
+