--- 1/draft-ietf-rmt-pi-alc-revised-03.txt 2007-02-23 22:12:33.000000000 +0100 +++ 2/draft-ietf-rmt-pi-alc-revised-04.txt 2007-02-23 22:12:33.000000000 +0100 @@ -1,20 +1,20 @@ Reliable Multicast Transport (RMT) Luby Working Group Watson -Internet-Draft Digital Fountain -Expires: October 20, 2006 Vicisano - Cisco Systems, Inc. - April 18, 2006 +Internet-Draft Vicisano +Obsoletes: 3450 (if approved) Digital Fountain +Intended status: Standards Track February 22, 2007 +Expires: August 26, 2007 Asynchronous Layered Coding (ALC) Protocol Instantiation - draft-ietf-rmt-pi-alc-revised-03 + draft-ietf-rmt-pi-alc-revised-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,36 +25,36 @@ 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 October 20, 2006. + This Internet-Draft will expire on August 26, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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. + sender. This document obsoletes RFC3450. 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 . . . . . . . . . . . . . . . . . . . 6 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 2.2. Multiple rate congestion control building block . . . . . 9 @@ -117,22 +117,22 @@ 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 [RFC3450] contained a previous versions of the protocol - defined in this specification. RFC3450 was published in the + RFC3450 [RFC3450], which is obsoleted by this document, contained a + previous versions of the protocol. RFC3450 was published in the "Experimental" category. It was the stated intent of the RMT working group to re-submit these specifications as an IETF Proposed Standard in due course. This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in RFC3450 [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. @@ -249,29 +249,29 @@ 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. 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 [I-D.ietf-rmt-bb-lct- - revised] followed by the FEC Payload ID that is described in - [I-D.ietf-rmt-fec-bb-revised]. 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 [I-D.ietf-rmt-fec-bb-revised]. + 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 [I-D.ietf-rmt-fec-bb-revised]. 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 [I-D.ietf-rmt-fec-bb-revised]. 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 [I-D.ietf-rmt-fec-bb-revised] 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 @@ -293,42 +293,43 @@ 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 [I-D.ietf-rmt-fec- - bb-revised] 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. + Information as specified in the FEC building block + [I-D.ietf-rmt-fec-bb-revised] 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 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 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 + [I-D.ietf-rmt-bb-lct-revised] 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 +-+-+ ...|A|B|... +-+-+ @@ -564,38 +565,38 @@ 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 [I-D.ietf-rmt-fec-bb-revised]. 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 + [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in + the FEC building block [I-D.ietf-rmt-fec-bb-revised]. 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 + [I-D.ietf-rmt-bb-lct-revised]. The overall ALC packet format is depicted in Figure 2. 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 | @@ -641,23 +642,23 @@ The Header Extension Content (HEC) field of the EXT_FTI LCT Header Extension contains the encoded FEC Object Transmission Information as defined in [I-D.ietf-rmt-fec-bb-revised]. 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 [I-D.ietf-rmt- - fec-bb-revised] and the multiple rate congestion control building - block. + [I-D.ietf-rmt-bb-lct-revised], the FEC building block + [I-D.ietf-rmt-fec-bb-revised] 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 @@ -674,23 +675,23 @@ 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 MUST 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 [I-D.ietf-rmt- - fec-bb-revised] and the multiple rate congestion control building - block. + [I-D.ietf-rmt-bb-lct-revised], the FEC building block + [I-D.ietf-rmt-fec-bb-revised] 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. @@ -869,27 +870,27 @@ 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., "Layered Coding Transport (LCT) Building Block", - draft-ietf-rmt-bb-lct-revised-02 (work in progress), - March 2006. + draft-ietf-rmt-bb-lct-revised-04 (work in progress), + June 2006. [I-D.ietf-rmt-fec-bb-revised] Watson, M., "Forward Error Correction (FEC) Building - Block", draft-ietf-rmt-fec-bb-revised-03 (work in - progress), January 2006. + Block", draft-ietf-rmt-fec-bb-revised-04 (work in + progress), September 2006. [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. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. @@ -955,28 +956,45 @@ Mark Watson Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 US Email: mark@digitalfountain.com Lorenzo Vicisano - Cisco Systems, Inc. - 510 McCarthy Blvd. - Milpitas, CA 95035 + Digital Fountain + 39141 Civic Center Dr. + Suite 300 + Fremont, CA 94538 US - Email: lorenzo@cisco.com + Email: lorenzo@digitalfountain.com -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -986,30 +1004,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).