draft-ietf-rmt-pi-alc-revised-09.txt   draft-ietf-rmt-pi-alc-revised-10.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Watson Working Group Watson
Internet-Draft Vicisano Internet-Draft Vicisano
Obsoletes: 3450 (if approved) Qualcomm Inc. Obsoletes: 3450 (if approved) Qualcomm Inc.
Intended status: Standards Track October 20, 2009 Intended status: Standards Track November 9, 2009
Expires: April 23, 2010 Expires: May 13, 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-09 draft-ietf-rmt-pi-alc-revised-10
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 RFC3450.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 23, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 BSD License.
This document describes the Asynchronous Layered Coding (ALC) This document may contain material from IETF Documents or IETF
protocol, a massively scalable reliable content delivery protocol. Contributions published or made publicly available before November
Asynchronous Layered Coding combines the Layered Coding Transport 10, 2008. The person(s) controlling the copyright in some of this
(LCT) building block, a multiple rate congestion control building material may not have granted the IETF Trust the right to allow
block and the Forward Error Correction (FEC) building block to modifications of such material outside the IETF Standards Process.
provide congestion controlled reliable asynchronous delivery of Without obtaining an adequate license from the person(s) controlling
content to an unlimited number of concurrent receivers from a single the copyright in such materials, this document may not be modified
sender. This document obsoletes RFC3450. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery service models . . . . . . . . . . . . . . . . . 5 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 6 1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6
2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple rate congestion control building block . . . . . 10 2.2. Multiple rate congestion control building block . . . . . 9
2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 11 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 10
2.4. Session Description . . . . . . . . . . . . . . . . . . . 12 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet authentication building block . . . . . . . . . . . 14 2.5. Packet authentication building block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14
4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14
4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 19
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 20
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26
9.2. Informative references . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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 10, line 35 skipping to change at page 10, line 35
Congestion control MUST be applied to all packets within a session Congestion control MUST be applied to all packets within a session
independently of which information about which object is carried in independently of which information about which object is carried in
each packet. Multiple rate congestion control is specified because each packet. Multiple rate congestion control is specified because
of its suitability to scale massively and because of its suitability of its suitability to scale massively and because of its suitability
for reliable content delivery. [RFC3738] specifies in-band for reliable content delivery. [RFC3738] specifies in-band
Congestion Control Information (CCI) that MUST be carried in the CCI Congestion Control Information (CCI) that MUST be carried in the CCI
field of the LCT header. field of the LCT header.
Alternative multiple rate congestion control building blocks MAY be Alternative multiple rate congestion control building blocks MAY be
supported. The multiple rate congestion control building block MAY supported, but only a single congestion control building block may be
specify more than one format for the CCI field, but it MUST specify used in a given ALC session. The congestion control building block
at most one format for each of the possible lengths 32, 64, 96 or 128 to be used in an ALC session is specified in the Session Description
bits. The value of C in the LCT header that determines the length of (see Section 2.4). A multiple rate congestion control building block
the CCI field MUST correspond to one of the lengths for the CCI MAY specify more than one format for the CCI field, but it MUST
defined in the multiple rate congestion control building block, this specify at most one format for each of the possible lengths 32, 64,
length MUST be the same for all packets sent to a session, and the 96 or 128 bits. The value of C in the LCT header that determines the
CCI format that corresponds to the length as specified in 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 multiple rate congestion control building block MUST be the format
used for the CCI field in the LCT header. used for the CCI field in the LCT header.
When using a multiple rate congestion control building block a sender When using a multiple rate congestion control building block a sender
sends packets in the session to several channels at potentially sends packets in the session to several channels at potentially
different rates. Then, individual receivers adjust their reception different rates. Then, individual receivers adjust their reception
rate within a session by adjusting which set of channels they are rate within a session by adjusting which set of channels they are
joined to at each point in time depending on the available bandwidth joined to at each point in time depending on the available bandwidth
between the receiver and the sender, but independent of other between the receiver and the sender, but independent of other
receivers. receivers.
skipping to change at page 12, line 18 skipping to change at page 12, line 21
objects for which transmission has finished, or receivers may leave a objects for which transmission has finished, or receivers may leave a
session before some objects are even available within the session. session before some objects are even available within the session.
In these cases, the FEC Object Transmission Information for each In these cases, the FEC Object Transmission Information for each
object may be dynamically communicated to receivers at or before the object may be dynamically communicated to receivers at or before the
time packets for the object are received from the session. This may time packets for the object are received from the session. This may
be accomplished using either an out-of-band mechanism, in-band using be accomplished using either an out-of-band mechanism, in-band using
the Codepoint field or a Header Extension, or any combination of the Codepoint field or a Header Extension, or any combination of
these methods. How the FEC Object Transmission Information is these methods. How the FEC Object Transmission Information is
communicated to receivers is outside the scope of this document. communicated to receivers is outside the scope of this document.
If packets for more than one object are transmitted within a session
then a Transmission Object Identifier (TOI) that uniquely identifies
objects within a session MUST appear in each packet header. Portions
of the FEC Object Transmission Information could be the same for all
objects in the session, in which case these portions can be
communicated to the receiver with an indication that this applies to
all objects in the session. These portions may be implicitly
determined based on the application, e.g., an application may use the
same FEC Encoding ID for all objects in all sessions. If there is a
portion of the FEC Object Transmission Information that may vary from
object to object and if this FEC Object Transmission Information is
communicated to a receiver out-of-band then the TOI for the object
MUST also be communicated to the receiver together with the
corresponding FEC Object Transmission Information, and the receiver
MUST use the corresponding FEC Object Transmission Information for
all packets received with that TOI. How the TOI and corresponding
FEC Object Transmission Information is communicated out-of-band to
receivers is outside the scope of this document.
It is also possible that there is a portion of the FEC Object
Transmission Information that may vary from object to object that is
carried in-band, for example in the CodePoint field or in Header
Extensions. How this is done is outside the scope of this document.
In this case the FEC Object Transmission Information is associated
with the object identified by the TOI carried in the packet.
2.4. Session Description 2.4. Session Description
Before a receiver can join an ALC session, the receiver needs to Before a receiver can join an ALC session, the receiver needs to
obtain a session description that contains the following information: obtain a session description that contains the following information:
o The multiple rate congestion control building block to be used for o The multiple rate congestion control building block to be used for
the session; the session;
o The sender IP address; o The sender IP address;
skipping to change at page 17, line 38 skipping to change at page 16, line 38
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.
For ALC the length of the TSI field within the LCT header is REQUIRED 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 to be non-zero. This implies that the sender MUST NOT set both the
LCT flags S and H to zero. LCT flags S and H to zero.
4.2. LCT Header-Extension Fields 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 [RFC5651]
This specification defines a new LCT Header Extension, "EXT_FTI", for This specification defines a new LCT Header Extension, "EXT_FTI", for
the purpose of communicating the FEC Object Transmission Information the purpose of communicating the FEC Object Transmission Information
in association with data packets of an object. The LCT Header in association with data packets of an object. The LCT Header
Extension Type for EXT_FTI is 64. Extension Type for EXT_FTI is 64.
The Header Extension Content (HEC) field of the EXT_FTI LCT Header The Header Extension Content (HEC) field of the EXT_FTI LCT Header
Extension contains the encoded FEC Object Transmission Information as Extension contains the encoded FEC Object Transmission Information as
defined in [RFC5052]. The format of the encoded FEC Object defined in [RFC5052]. The format of the encoded FEC Object
Transmission Information is dependent on the FEC Scheme in use and so Transmission Information is dependent on the FEC Scheme in use and so
is outside the scope of this document. is outside the scope of this document.
skipping to change at page 19, line 40 skipping to change at page 19, line 5
including interpreting the other header fields appropriately, and including interpreting the other header fields appropriately, and
using the FEC Payload ID and the encoding symbol(s) in the using the FEC Payload ID and the encoding symbol(s) in the
payload to reconstruct the corresponding object. payload to reconstruct the corresponding object.
It is RECOMMENDED that packet authentication be used. If packet It is RECOMMENDED that packet authentication be used. If packet
authentication is used then it is RECOMMENDED that the receiver authentication is used then it is RECOMMENDED that the receiver
immediately check the authenticity of a packet before proceeding with immediately check the authenticity of a packet before proceeding with
step (3) above. If immediate checking is possible and if the packet step (3) above. If immediate checking is possible and if the packet
fails the check then the receiver MUST silently discard the packet. fails the check then the receiver MUST silently discard the packet.
Some packet authentication schemes such as TESLA
[I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate
authenticity check. In this case the receiver SHOULD check the
authenticity of a packet as soon as possible, and if the packet fails
the check then it MUST be silently discarded before step (5) above.
It is RECOMMENDED that if receivers detect many packets which fail
authentication checks within a session then 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.
5. Security Considerations 5. Security Considerations
The same security consideration that apply to the LCT, FEC and the The same security consideration that apply to the LCT, FEC and the
multiple rate congestion control building blocks also apply to ALC. multiple rate congestion control building blocks also apply to ALC.
ALC is especially vulnerable to denial- of-service attacks by ALC is especially vulnerable to denial- of-service attacks by
attackers that try to send forged packets to the session which would attackers that try to send forged packets to the session which would
prevent successful reconstruction or cause inaccurate reconstruction prevent successful reconstruction or cause inaccurate reconstruction
of large portions of the object by receivers. ALC is also of large portions of the object by receivers. ALC is also
particularly affected by such an attack because many receivers may particularly affected by such an attack because many receivers may
skipping to change at page 21, line 18 skipping to change at page 20, line 18
rest of the network and other receivers. Thus, it is also rest of the network and other receivers. Thus, it is also
RECOMMENDED that packet level authentication be used to protect RECOMMENDED that packet level authentication be used to protect
against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can
also be used to some extent to limit the damage caused by such also be used to some extent to limit the damage caused by such
attacks. However, with TESLA a receiver can only determine if a attacks. However, with TESLA a receiver can only determine if a
packet is authentic several seconds after it is received, and thus an packet is authentic several seconds after it is received, and thus an
attack against the congestion control protocol can be effective for attack against the congestion control protocol can be effective for
several seconds before the receiver can react to slow down the several seconds before the receiver can react to slow down the
session reception rate. session reception rate.
Some packet authentication schemes such as TESLA
[I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate
authenticity check. In this case the receiver SHOULD check the
authenticity of a packet as soon as possible, and if the packet fails
the check then it MUST be silently discarded before step (5) above.
It is RECOMMENDED that if receivers detect many packets which fail
authentication checks within a session then 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 Reverse Path Forwarding checks SHOULD be enabled in all network
routers and switches along the path from the sender to receivers to routers and switches along the path from the sender to receivers to
limit the possibility of a bad agent injecting forged packets into limit the possibility of a bad agent injecting forged packets into
the multicast tree data path. the multicast tree data path.
5.1. Baseline Secure ALC Operation 5.1. Baseline Secure ALC Operation
This section describes a baseline mode of secure ALC protocol This section describes a baseline mode of secure ALC protocol
operation based on application of the IPsec security protocol. This operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable approach is documented here to provide a reference, interoperable
skipping to change at page 28, line 48 skipping to change at page 27, line 48
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009. Transport (LCT) Building Block", RFC 5651, October 2009.
9.2. Informative references 9.2. Informative references
[I-D.ietf-msec-tesla-for-alc-norm] [I-D.ietf-msec-tesla-for-alc-norm]
Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in
the ALC and NORM Protocols", the ALC and NORM Protocols",
draft-ietf-msec-tesla-for-alc-norm-08 (work in progress), draft-ietf-msec-tesla-for-alc-norm-10 (work in progress),
September 2009. October 2009.
[I-D.ietf-rmt-simple-auth-for-alc-norm] [I-D.ietf-rmt-simple-auth-for-alc-norm]
Roca, V., "Simple Authentication Schemes for the ALC and Roca, V., "Simple Authentication Schemes for the ALC and
NORM Protocols", NORM Protocols",
draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in draft-ietf-rmt-simple-auth-for-alc-norm-02 (work in
progress), March 2009. progress), October 2009.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998. Application Protocols", RFC 2357, June 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
 End of changes. 14 change blocks. 
110 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/