draft-ietf-rmt-pi-alc-revised-08.txt   draft-ietf-rmt-pi-alc-revised-09.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 September 3, 2009 Intended status: Standards Track October 20, 2009
Expires: March 7, 2010 Expires: April 23, 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-08 draft-ietf-rmt-pi-alc-revised-09
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 March 7, 2010. This Internet-Draft will expire on April 23, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 25 skipping to change at page 3, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Delivery service models . . . . . . . . . . . . . . . . . 5 1.1. Delivery service models . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Environmental Requirements and Considerations . . . . . . 6 1.3. Environmental Requirements and Considerations . . . . . . 6
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7
2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8
2.2. Multiple rate congestion control building block . . . . . 10 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.4. Session Description . . . . . . . . . . . . . . . . . . . 12
2.5. Packet authentication building block . . . . . . . . . . . 13 2.5. Packet authentication building block . . . . . . . . . . . 14
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16
4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16
4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28
9.2. Informative references . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
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 4, line 52 skipping to change at page 4, line 52
application that uses ALC may require that receivers report application that uses ALC may require that receivers report
statistics on their reception experience back to the sender, but the statistics on their reception experience back to the sender, but the
mechanisms by which receivers report back statistics is outside the mechanisms by which receivers report back statistics is outside the
scope of ALC. In general, ALC is designed to be a minimal protocol scope of ALC. In general, ALC is designed to be a minimal protocol
instantiation that provides reliable content delivery without instantiation that provides reliable content delivery without
unnecessary limitations to the scalability of the basic protocol. unnecessary limitations to the scalability of the basic protocol.
This document is a product of the IETF RMT WG and follows the general This document is a product of the IETF RMT WG and follows the general
guidelines provided in [RFC3269]. guidelines provided in [RFC3269].
[RFC3450], which was published in the "Experimental" category and A previous version of this document was published in the
which is obsoleted by this document, contained a previous versions of "Experimental" category as [RFC3450] and is obsoleted by this
the protocol. document.
This Proposed Standard specification is thus based on and backwards This Proposed Standard specification is thus based on and backwards
compatible with the protocol defined in [RFC3450] updated according compatible with the protocol defined in [RFC3450] updated according
to accumulated experience and growing protocol maturity since its to accumulated experience and growing protocol maturity since its
original publication. Said experience applies both to this original publication. Said experience applies both to this
specification itself and to congestion control strategies related to specification itself and to congestion control strategies related to
the use of this specification. the use of this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]. document are to be interpreted as described in BCP 14, [RFC2119].
1.1. Delivery service models 1.1. Delivery service models
ALC can support several different reliable content delivery service 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 1.2. Scalability
Massive scalability is a primary design goal for ALC. IP multicast Massive scalability is a primary design goal for ALC. IP multicast
is inherently massively scalable, but the best effort service that it is inherently massively scalable, but the best effort service that it
provides does not provide session management functionality, provides does not provide session management functionality,
congestion control or reliability. ALC provides all of this on top congestion control or reliability. ALC provides all of this on top
of IP multicast without sacrificing any of the inherent scalability of IP multicast without sacrificing any of the inherent scalability
of IP multicast. ALC has the following properties: of IP multicast. ALC has the following properties:
skipping to change at page 6, line 13 skipping to change at page 6, line 13
ALC intentionally omits any application specific features that could ALC intentionally omits any application specific features that could
potentially limit its scalability. By doing so, ALC provides a potentially limit its scalability. By doing so, ALC provides a
minimal protocol that is massively scalable. Applications may be minimal protocol that is massively scalable. Applications may be
built on top of ALC to provide additional features that may limit the built on top of ALC to provide additional features that may limit the
scalability of the application. Such applications are outside the scalability of the application. Such applications are outside the
scope of this document. scope of this document.
1.3. Environmental Requirements and Considerations 1.3. Environmental Requirements and Considerations
All of the environmental requirements and considerations that apply All of the environmental requirements and considerations that apply
to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC to the LCT building block [RFC5651], the FEC building block
building block [RFC5052], the multiple rate congestion control [RFC5052], the multiple rate congestion control building block and to
building block and to any additional building blocks that ALC uses any additional building blocks that ALC uses also apply to ALC.
also apply to ALC.
One issues that is specific to ALC with respect to the Any- Source The IP multicast model defined in [RFC1112] is commonly known as Any-
Multicast (ASM) model of IP multicast as defined in RFC 1112 Source Multicast (ASM), in contrast to Source-Specific Multicast
[RFC1112] is the way the multiple rate congestion control building (SSM) which is defined in [RFC3569]. One issues that is specific to
block interacts with ASM. The congestion control building block may ALC with respect to ASM is the way the multiple rate congestion
use the measured difference in time between when a join to a channel control building block interacts with ASM. The congestion control
is sent and when the first packet from the channel arrives in building block may use the measured difference in time between when a
determining the receiver reception rate. The congestion control join to a channel is sent and when the first packet from the channel
building block may also uses packet sequence numbers per channel to arrives in determining the receiver reception rate. The congestion
measure losses, and this is also used to determine the receiver control building block may also use packet sequence numbers per
reception rate. These features raise two concerns with respect to channel to measure losses, and this is also used to determine the
ASM: The time difference between when the join to a channel is sent receiver reception rate. These features raise two concerns with
and when the first packet arrives can be significant due to the use respect to ASM: The time difference between when the join to a
of Rendezvous Points (RPs) and the MSDP protocol, and packets can be channel is sent and when the first packet arrives can be significant
lost in the switch over from the (*,G) join to the RP and the (S,G) due to the use of Rendezvous Points (RPs) and the Multicast Source
join directly to the sender. Both of these issues could potentially 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 substantially degrade the reception rate of receivers. To ameliorate
these concerns, it is RECOMMENDED that the RP be as close to the these concerns, it is recommended during deployment to ensure that
sender as possible. SSM does not share these same concerns. For a the RP be as close to the sender as possible. SSM does not share
fuller consideration of these issues, consult the multiple rate these same concerns. For a fuller consideration of these issues,
congestion control building block. consult the multiple rate congestion control building block.
2. Architecture Definition 2. Architecture Definition
ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to ALC uses the LCT building block [RFC5651] to provide in-band session
provide in-band session management functionality. ALC uses a management functionality. ALC uses a multiple rate congestion
multiple rate congestion control building block that is compliant control building block that is compliant with [RFC2357] to provide
with [RFC2357] to provide congestion control that is feedback free. congestion control that is feedback free. Receivers adjust their
Receivers adjust their reception rates individually by joining and reception rates individually by joining and leaving channels
leaving channels associated with the session. ALC uses the FEC associated with the session. ALC uses the FEC building block
building block [RFC5052] to provide reliability. The sender [RFC5052] to provide reliability. The sender generates encoding
generates encoding symbols based on the object to be delivered using symbols based on the object to be delivered using FEC codes and sends
FEC codes and sends them in packets to channels associated with the them in packets to channels associated with the session. Receivers
session. Receivers simply wait for enough packets to arrive in order simply wait for enough packets to arrive in order to reliably
to reliably reconstruct the object. Thus, there is no request for reconstruct the object. Thus, there is no request for retransmission
retransmission of individual packets from receivers that miss packets of individual packets from receivers that miss packets in order to
in order to assure reliable reception of an object, and the packets assure reliable reception of an object, and the packets and their
and their rate of transmission out of the sender can be independent rate of transmission out of the sender can be independent of the
of the number and the individual reception experiences of the number and the individual reception experiences of the receivers.
receivers.
The definition of a session for ALC is the same as it is for LCT. An 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 ALC session comprises multiple channels originating at a single
sender that are used for some period of time to carry packets 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 pertaining to the transmission of one or more objects that can be of
interest to receivers. Congestion control is performed over the interest to receivers. Congestion control is performed over the
aggregate of packets sent to channels belonging to a session. 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 fact that an ALC session is restricted to a single sender does not
preclude the possibility of receiving packets for the same objects preclude the possibility of receiving packets for the same objects
from multiple senders. However, each sender would be sending packets from multiple senders. However, each sender would be sending packets
to a a different session to which congestion control is individually to a a different session to which congestion control is individually
applied. Although receiving concurrently from multiple sessions is applied. Although receiving concurrently from multiple sessions is
allowed, how this is done at the application level is outside the allowed, how this is done at the application level is outside the
scope of this document. scope of this document.
ALC is a protocol instantiation as defined in [RFC3048]. This ALC is a protocol instantiation as defined in [RFC3048]. This
document describes version 1 of ALC which MUST use version 1 of LCT 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 described in [RFC5651]. Like LCT, ALC is designed to be used with
designed to be used with the IP multicast network service. This the IP multicast network service. This specification defines ALC as
specification defines ALC as payload of the UDP transport protocol payload of the UDP transport protocol [RFC0768] that supports IP
[RFC0768] that supports IP multicast delivery of packets. multicast delivery of packets.
An ALC packet header immediately follows the UDP header and consists The ALC packet format is illustrated in Figure 1. An ALC packet
of the default LCT header that is described in header immediately follows the IP/UDP header and consists of the
[I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is default LCT header that is described in [RFC5651] followed by the FEC
described in [RFC5052]. The Congestion Control Information field Payload ID that is described in [RFC5052]. The Congestion Control
within the LCT header carries the required Congestion Control Information field within the LCT header carries the required
Information that is described in the multiple rate congestion control Congestion Control Information that is described in the multiple rate
building block specified that is compliant with [RFC2357]. The congestion control building block specified that is compliant with
packet payload that follows the ALC packet header consists of [RFC2357]. The packet payload that follows the ALC packet header
encoding symbols that are identified by the FEC Payload ID as consists of encoding symbols that are identified by the FEC Payload
described in [RFC5052]. 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 Each receiver is required to obtain a Session Description before
joining an ALC session. As described later, the Session Description joining an ALC session. As described later, the Session Description
includes out-of-band information required for the LCT, FEC and the includes out-of-band information required for the LCT, FEC and the
multiple rate congestion control building blocks. The FEC Object multiple rate congestion control building blocks. The FEC Object
Transmission Information specified in the FEC building block Transmission Information specified in the FEC building block
[RFC5052] required for each object to be received by a receiver can [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 be communicated to a receiver either out-of-band or in-band using a
Header Extension. The means for communicating the Session Header Extension. The means for communicating the Session
Description and the FEC Object Transmission Information to a receiver Description and the FEC Object Transmission Information to a receiver
skipping to change at page 9, line 14 skipping to change at page 9, line 29
sender and the TSI, i.e., the TOI is scoped by the session. The TOI 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 for each object is REQUIRED to be unique within a session, but is not
required be unique across sessions. Furthermore, the same object MAY required be unique across sessions. Furthermore, the same object MAY
have a different TOI in different sessions. The mapping between TOIs have a different TOI in different sessions. The mapping between TOIs
and objects carried in a session is outside the scope of this and objects carried in a session is outside the scope of this
document. 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 The LCT header from version 1 of the LCT building block [RFC5651]
[I-D.ietf-rmt-bb-lct-revised] MUST be used. 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 in bits 6 and 7 of the first word of the LCT header. These two field in bits 6 and 7 of the first word of the LCT header. These two
bits are used by ALC as follows: bits are used by ALC as follows:
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
+-+-+ +-+-+
...|X|Y|... ...|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 X - Source Packet Indicator (SPI)
PSI bit Y - Reserved PSI bit Y - 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
skipping to change at page 10, line 7 skipping to change at page 10, line 21
Support of two FEC Payload ID formats allows FEC Payload ID Support of two FEC Payload ID formats allows FEC Payload ID
information which is only of relevance when FEC decoding is to be information which is only of relevance when FEC decoding is to be
performed to be provided in the FEC Payload ID format for packets performed to be provided in the FEC Payload ID format for packets
containing repair data. This information need not be processed by containing repair data. This information need not be processed by
receivers which do not perform FEC decoding (either because no FEC receivers which do not perform FEC decoding (either because no FEC
decoding is required or because the receiver does not support FEC decoding is required or because the receiver does not support FEC
decoding). decoding).
2.2. Multiple rate congestion control building block 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 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
skipping to change at page 12, line 28 skipping to change at page 12, line 46
It is also possible that there is a portion of the FEC Object It is also possible that there is a portion of the FEC Object
Transmission Information that may vary from object to object that is Transmission Information that may vary from object to object that is
carried in-band, for example in the CodePoint field or in Header carried in-band, for example in the CodePoint field or in Header
Extensions. How this is done is outside the scope of this document. Extensions. How this is done is outside the scope of this document.
In this case the FEC Object Transmission Information is associated In this case the FEC Object Transmission Information is associated
with the object identified by the TOI carried in the packet. with the object identified by the TOI carried in the packet.
2.4. Session Description 2.4. Session Description
The Session Description that a receiver is REQUIRED to obtain before Before a receiver can join an ALC session, the receiver needs to
joining an ALC session MUST contain 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;
o The number of channels in the session; o The number of channels in the session;
o The address and port number used for each channel in the session; o The address and port number used for each channel in the session;
skipping to change at page 14, line 4 skipping to change at page 14, line 23
web page with scheduling information, or conveyed via E-mail or other web page with scheduling information, or conveyed via E-mail or other
out-of-band methods. Discussion of Session Description formats and out-of-band methods. Discussion of Session Description formats and
methods for communication of Session Descriptions to receivers is methods for communication of Session Descriptions to receivers is
beyond the scope of this document. beyond the scope of this document.
2.5. Packet authentication building block 2.5. Packet authentication building block
It is RECOMMENDED that implementors of ALC use some packet It is RECOMMENDED that implementors of ALC use some packet
authentication scheme to protect the protocol from attacks. Suitable authentication scheme to protect the protocol from attacks. Suitable
schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and
[I-D.ietf-rmt-simple-auth-for-alc-norm]. [I-D.ietf-rmt-simple-auth-for-alc-norm].
3. Conformance Statement 3. Conformance Statement
This Protocol Instantiation document, in conjunction with the LCT This Protocol Instantiation document, in conjunction with the LCT
building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block building block [RFC5651], the FEC building block [RFC5052] and
[RFC5052] and [RFC3738] completely specifies a working reliable [RFC3738] completely specifies a working reliable multicast transport
multicast transport protocol that conforms to the requirements protocol that conforms to the requirements described in [RFC2357].
described in [RFC2357].
4. Functionality Definition 4. Functionality Definition
This section describes the format and functionality of the data This section describes the format and functionality of the data
packets carried in an ALC session as well as the sender and receiver packets carried in an ALC session as well as the sender and receiver
operations for a session. operations for a session.
4.1. Packet format used by ALC 4.1. Packet format used by ALC
The packet format used by ALC is the UDP header followed by the LCT 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. header followed by the FEC Payload ID followed by the packet payload.
The LCT header is defined in the LCT building block The LCT header is defined in the LCT building block [RFC5651] and the
[I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in FEC Payload ID is described in the FEC building block [RFC5052]. The
the FEC building block [RFC5052]. The Congestion Control Information Congestion Control Information field in the LCT header contains the
field in the LCT header contains the REQUIRED Congestion Control required Congestion Control Information that is described in the
Information that is described in the multiple rate congestion control multiple rate congestion control building block used. The packet
building block used. The packet payload contains encoding symbols payload contains encoding symbols generated from an object. If more
generated from an object. If more than one object is carried in the than one object is carried in the session then the Transmission
session then the Transmission Object ID (TOI) within the LCT header Object ID (TOI) within the LCT header MUST be used to identify which
MUST be used to identify which object the encoding symbols are object the encoding symbols are generated from. Within the scope of
generated from. Within the scope of an object, encoding symbols an object, encoding symbols carried in the payload of the packet are
carried in the payload of the packet are identified by the FEC identified by the FEC Payload ID as described in the FEC building
Payload ID as described in the FEC building block. 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 version 1 of the LCT building block defined in [RFC5651].
[I-D.ietf-rmt-bb-lct-revised].
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 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 2: Overall ALC packet format Figure 3: 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.
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 All senders and receivers implementing ALC MUST support the EXT_NOP
Header Extension and MUST recognize EXT_AUTH, but are not required be 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 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 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.
4.3. Sender Operation 4.3. Sender Operation
The sender operation when using ALC includes all the points made The sender operation when using ALC includes all the points made
about the sender operation when using the LCT building block about the sender operation when using the LCT building block
[I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and [RFC5651], the FEC building block [RFC5052] and the multiple rate
the multiple rate congestion control building block. congestion control building block.
A sender using ALC MUST make available the required Session A sender using ALC should make available the required Session
Description as described in Section 2.4. A sender also MUST make Description as described in Section 2.4. A sender should also make
available the required FEC Object Transmission Information as available the required FEC Object Transmission Information as
described in Section 2.3. described in Section 2.3.
Within a session a sender transmits a sequence of packets to the Within a session a sender transmits a sequence of packets to the
channels associated with the session. The ALC sender MUST obey 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 rules for filling in the CCI field in the packet headers and MUST
send packets at the appropriate rates to the channels associated with send packets at the appropriate rates to the channels associated with
the session as dictated by the multiple rate congestion control the session as dictated by the multiple rate congestion control
building block. building block.
skipping to change at page 18, line 42 skipping to change at page 18, line 42
in the payload of the packet. in the payload of the packet.
It is RECOMMENDED that packet authentication be used. If packet It is RECOMMENDED that packet authentication be used. If packet
authentication is used then the Header Extensions described in authentication is used then the Header Extensions described in
Section 4.2 MAY be used to carry the authentication. Section 4.2 MAY be used to carry the authentication.
4.4. Receiver Operation 4.4. Receiver Operation
The receiver operation when using ALC includes all the points made The receiver operation when using ALC includes all the points made
about the receiver operation when using the LCT building block about the receiver operation when using the LCT building block
[I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and [RFC5651], the FEC building block [RFC5052] and the multiple rate
the multiple rate congestion control building block. congestion control building block.
To be able to participate in a session, a receiver MUST obtain the To be able to participate in a session, a receiver needs to obtain
REQUIRED Session Description as listed in Section 2.4. How receivers the required Session Description as listed in Section 2.4. How
obtain a Session Description is outside the scope of this document. 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 As described in Section 2.3, a receiver needs to obtain the required
Object Transmission Information for each object for which the FEC Object Transmission Information for each object for which the
receiver receives and processes packets. receiver receives and processes packets.
Upon receipt of each packet the receiver proceeds with the following Upon receipt of each packet the receiver proceeds with the following
steps in the order listed. steps in the order listed.
1. The receiver MUST parse the packet header and verify that it is a 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 valid header. If it is not valid then the packet MUST be
discarded without further processing. discarded without further processing.
2. The receiver MUST verify that the sender IP address together with 2. The receiver MUST verify that the sender IP address together with
skipping to change at page 23, line 16 skipping to change at page 23, line 16
The implementation MUST be able to use the source address, The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD. selectors in the SPD.
5.1.2.2. Mode 5.1.2.2. Mode
IPsec in transport mode MUST be supported. The use of IPsec IPsec in transport mode MUST be supported. The use of IPsec
[RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED
such that unauthenticated packets are not received by the ALC such that unauthenticated packets are not received by the ALC
protocol implementation . protocol implementation.
5.1.2.3. Key Management 5.1.2.3. Key Management
An automated key management scheme for group key distribution and An automated key management scheme for group key distribution and
rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830]
SHOULD be used. Relatively short-lived ALC sessions MAY be able to SHOULD be used. Relatively short-lived ALC sessions MAY be able to
use Manual Keying with a single, preplaced key, particularly if use Manual Keying with a single, preplaced key, particularly if
Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec
implementation used. It should also be noted that it may be possible 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 for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be
skipping to change at page 28, line 9 skipping to change at page 28, line 9
one of which is for packets containing only source symbols which one of which is for packets containing only source symbols which
can be processed by receivers that do not support FEC Decoding. can be processed by receivers that do not support FEC Decoding.
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]
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, [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,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 28, line 46 skipping to change at page 28, line 40
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
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
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-07 (work in progress), draft-ietf-msec-tesla-for-alc-norm-08 (work in progress),
December 2008. September 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-01 (work in
progress), March 2009. progress), March 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.
skipping to change at page 29, line 42 skipping to change at page 29, line 39
M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002. (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. 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. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
 End of changes. 35 change blocks. 
112 lines changed or deleted 130 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/