draft-ietf-rmt-pi-alc-revised-02.txt   draft-ietf-rmt-pi-alc-revised-03.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Watson Working Group Watson
Internet-Draft Digital Fountain Internet-Draft Digital Fountain
Expires: September 4, 2006 Vicisano Expires: October 20, 2006 Vicisano
Cisco Systems, Inc. Cisco Systems, Inc.
March 3, 2006 April 18, 2006
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-02 draft-ietf-rmt-pi-alc-revised-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006. This Internet-Draft will expire on October 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Asynchronous Layered Coding (ALC) This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol. protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport Asynchronous Layered Coding combines the Layered Coding Transport
skipping to change at page 2, line 15 skipping to change at page 2, line 15
sender. sender.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5 1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6
2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple rate congestion control building block . . . . . 8 2.2. Multiple rate congestion control building block . . . . . 9
2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9
2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet authentication building block . . . . . . . . . . . 12 2.5. Packet authentication building block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15
4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15
4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 23 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative references . . . . . . . . . . . . . . . . . . . 24 9.1. Normative references . . . . . . . . . . . . . . . . . . . 25
9.2. Informative references . . . . . . . . . . . . . . . . . . 24 9.2. Informative references . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes a massively scalable reliable content This document describes a massively scalable reliable content
delivery protocol, Asynchronous Layered Coding (ALC), for multiple delivery protocol, Asynchronous Layered Coding (ALC), for multiple
rate congestion controlled reliable content delivery. The protocol rate congestion controlled reliable content delivery. The protocol
is specifically designed to provide massive scalability using IP is specifically designed to provide massive scalability using IP
multicast as the underlying network service. Massive scalability in multicast as the underlying network service. Massive scalability in
this context means the number of concurrent receivers for an object this context means the number of concurrent receivers for an object
is potentially in the millions, the aggregate size of objects to be is potentially in the millions, the aggregate size of objects to be
skipping to change at page 8, line 23 skipping to change at page 8, line 23
a different TOI in different sessions. The mapping between TOIs and a different TOI in different sessions. The mapping between TOIs and
objects carried in a session is outside the scope of this document. 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 If only one object is carried within a session then the TOI MAY be
omitted from the LCT header. omitted from the LCT header.
The LCT header from version 1 of the LCT building block [I-D.ietf- The LCT header from version 1 of the LCT building block [I-D.ietf-
rmt-bb-lct-revised] MUST be used. rmt-bb-lct-revised] MUST be used.
The LCT Header includes a two-bit Protocol Specific Indication (PSI) The LCT Header includes a two-bit Protocol Specific Indication (PSI)
field. These two bits are used by ALC as follows: field in bits 6 and 7 of the first word of the LCT header. These two
bits are used by ALC as follows:
PSI bit 0 (LSB) - Source Packet Indicator (SPI) 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|...
+-+-+
PSI bit 1 (MSB) - Reserved Figure 1: PSI bits within LCT Headder
PSI bit A - Source Packet Indicator (SPI)
PSI bit B - Reserved
The Source Packet Indicator is used with systematic FEC Schemes which The Source Packet Indicator is used with systematic FEC Schemes which
define a different FEC Payload ID format for packets containing only define a different FEC Payload ID format for packets containing only
source data compared to the FEC Payload ID format for packets source data compared to the FEC Payload ID format for packets
containing repair data. For such FEC Schemes, then the SPI MUST be 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 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 source data is used and the SPI MUST be set to zero, when the FEC
Payload ID for packerts containing repair data is used. In the case Payload ID for packerts containing repair data is used. In the case
of FEC Schemes which define only a single FEC Payload ID format, then of FEC Schemes which define only a single FEC Payload ID format, then
the SPI MUST be set to zero by the sender and MUST be ignored by the the SPI MUST be set to zero by the sender and MUST be ignored by the
skipping to change at page 14, line 34 skipping to change at page 15, line 34
generated from. Within the scope of an object, encoding symbols generated from. Within the scope of an object, encoding symbols
carried in the payload of the packet are identified by the FEC carried in the payload of the packet are identified by the FEC
Payload ID as described in the FEC building block. Payload ID as described in the FEC building block.
The version number of ALC specified in this document is 1. The 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 of the LCT header MUST be interpreted as the ALC
version number field. This version of ALC implicitly makes use of 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- version 1 of the LCT building block defined in [I-D.ietf-rmt-bb-lct-
revised]. revised].
The overall ALC packet format is depicted in Figure 1. The packet is 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 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 header. The ALC packet format has no dependencies on the IP version
number. number.
0 1 2 3 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 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 | | UDP header |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT header | | LCT header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID | | FEC Payload ID |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) | | Encoding Symbol(s) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall ALC packet format Figure 2: Overall ALC packet format
In some special cases an ALC sender may need to produce ALC packets 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, that do not contain any payload. This may be required, for example,
to signal the end of a session or to convey congestion control to signal the end of a session or to convey congestion control
information. These data-less packets do not contain the FEC Payload information. These data-less packets do not contain the FEC Payload
ID either, but only the LCT header fields. The total datagram ID either, but only the LCT header fields. The total datagram
length, conveyed by outer protocol headers (e.g., the IP or UDP length, conveyed by outer protocol headers (e.g., the IP or UDP
header), enables receivers to detect the absence of the ALC payload header), enables receivers to detect the absence of the ALC payload
and FEC Payload ID. and FEC Payload ID.
skipping to change at page 24, line 11 skipping to change at page 25, line 11
o Definition and IANA registration of the EXT_FTI LCT Header o Definition and IANA registration of the EXT_FTI LCT Header
Extension Extension
9. References 9. References
9.1. Normative references 9.1. Normative references
[I-D.ietf-rmt-bb-lct-revised] [I-D.ietf-rmt-bb-lct-revised]
Luby, M., "Layered Coding Transport (LCT) Building Block", Luby, M., "Layered Coding Transport (LCT) Building Block",
draft-ietf-rmt-bb-lct-revised-01 (work in progress), draft-ietf-rmt-bb-lct-revised-02 (work in progress),
October 2005. March 2006.
[I-D.ietf-rmt-fec-bb-revised] [I-D.ietf-rmt-fec-bb-revised]
Watson, M., "Forward Error Correction (FEC) Building Watson, M., "Forward Error Correction (FEC) Building
Block", draft-ietf-rmt-fec-bb-revised-03 (work in Block", draft-ietf-rmt-fec-bb-revised-03 (work in
progress), January 2006. progress), January 2006.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
 End of changes. 12 change blocks. 
27 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/