--- 1/draft-ietf-rmt-pi-alc-revised-08.txt 2009-10-21 08:12:32.000000000 +0200 +++ 2/draft-ietf-rmt-pi-alc-revised-09.txt 2009-10-21 08:12:32.000000000 +0200 @@ -1,20 +1,20 @@ Reliable Multicast Transport (RMT) Luby Working Group Watson Internet-Draft Vicisano Obsoletes: 3450 (if approved) Qualcomm Inc. -Intended status: Standards Track September 3, 2009 -Expires: March 7, 2010 +Intended status: Standards Track October 20, 2009 +Expires: April 23, 2010 Asynchronous Layered Coding (ALC) Protocol Instantiation - draft-ietf-rmt-pi-alc-revised-08 + draft-ietf-rmt-pi-alc-revised-09 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 @@ -33,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 7, 2010. + This Internet-Draft will expire on April 23, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -66,40 +66,40 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Delivery service models . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Environmental Requirements and Considerations . . . . . . 6 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8 2.2. Multiple rate congestion control building block . . . . . 10 - 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 10 + 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 11 2.4. Session Description . . . . . . . . . . . . . . . . . . . 12 - 2.5. Packet authentication building block . . . . . . . . . . . 13 + 2.5. Packet authentication building block . . . . . . . . . . . 14 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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 @@ -134,39 +134,39 @@ 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]. - [RFC3450], which was published in the "Experimental" category and - which is obsoleted by this document, contained a previous versions of - the protocol. + 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 [I-D.ietf-rmt-bb-lct-revised]. + 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: @@ -192,96 +192,110 @@ 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 [I-D.ietf-rmt-bb-lct-revised], 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. + 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. - One issues that is specific to ALC with respect to the Any- Source - Multicast (ASM) model of IP multicast as defined in RFC 1112 - [RFC1112] 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 + 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 issues 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 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. + 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 [I-D.ietf-rmt-bb-lct-revised] 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 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. + 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 + 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 [RFC3048]. This document describes version 1 of ALC which MUST use version 1 of LCT - described in [I-D.ietf-rmt-bb-lct-revised]. 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 IP multicast delivery of packets. + 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 IP + multicast delivery of packets. - An ALC packet header immediately follows the UDP header and consists - of the default LCT header that is described in - [I-D.ietf-rmt-bb-lct-revised] 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]. + 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]. + + +----------------------------------------+ + | 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 @@ -324,34 +338,34 @@ 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 - [I-D.ietf-rmt-bb-lct-revised] MUST be used. + 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 1: PSI bits within LCT Headder + Figure 2: PSI bits within LCT Headder 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, then the SPI MUST be set to 1 when the FEC Payload ID format for packets containing only @@ -364,21 +378,24 @@ Support of two FEC Payload ID formats allows FEC Payload ID information which 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 which 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, implementions of ALC MUST support [RFC3738]. + At a minimum, implementions 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 @@ -482,22 +499,22 @@ 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. 2.4. Session Description - The Session Description that a receiver is REQUIRED to obtain before - joining an ALC session MUST contain the following information: + 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; @@ -554,123 +570,120 @@ 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. Suitable schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and - [I-D.ietf-rmt-simple-auth-for-alc-norm]. 3. Conformance Statement This Protocol Instantiation document, in conjunction with the LCT - building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block - [RFC5052] and [RFC3738] completely specifies a working reliable - multicast transport protocol that conforms to the requirements - described in [RFC2357]. + 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]. 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 - [I-D.ietf-rmt-bb-lct-revised] 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 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 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 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. 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 - [I-D.ietf-rmt-bb-lct-revised]. + version 1 of the LCT building block defined in [RFC5651]. - The overall ALC packet format is depicted in Figure 2. The packet is + 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. 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 2: Overall ALC packet format + 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 All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but are not required be able to parse its content. The EXT_NOP and EXT_AUTH LCT Header - Extensions are defined in [I-D.ietf-rmt-bb-lct-revised] + Extensions are defined in [RFC5651] 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. 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 - [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and - the multiple rate congestion control building block. + [RFC5651], the FEC building block [RFC5052] 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 + 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 MUST send packets at the appropriate rates to the channels associated with the session as dictated by the multiple rate congestion control building block. @@ -684,29 +697,30 @@ 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 - [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and - the multiple rate congestion control 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 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 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 MUST obtain the required FEC - Object Transmission Information for each object for which the + 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. 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 @@ -992,26 +1006,20 @@ one of which is for packets containing only source symbols which 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 - [I-D.ietf-rmt-bb-lct-revised] - Luby, M., Watson, M., and L. Vicisano, "Layered Coding - Transport (LCT) Building Block", - draft-ietf-rmt-bb-lct-revised-11 (work in progress), - August 2009. - [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., @@ -1029,27 +1037,30 @@ [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. + 9.2. Informative references [I-D.ietf-msec-tesla-for-alc-norm] Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in the ALC and NORM Protocols", - draft-ietf-msec-tesla-for-alc-norm-07 (work in progress), - December 2008. + draft-ietf-msec-tesla-for-alc-norm-08 (work in progress), + September 2009. [I-D.ietf-rmt-simple-auth-for-alc-norm] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in progress), March 2009. [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. @@ -1074,20 +1085,26 @@ 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. [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