draft-ietf-rmt-pi-alc-revised-10.txt   rfc5775.txt 
Reliable Multicast Transport (RMT) Luby Internet Engineering Task Force (IETF) M. Luby
Working Group Watson Request for Comments: 5775 M. Watson
Internet-Draft Vicisano Obsoletes: 3450 L. Vicisano
Obsoletes: 3450 (if approved) Qualcomm Inc. Category: Standards Track Qualcomm, Inc.
Intended status: Standards Track November 9, 2009 ISSN: 2070-1721 April 2010
Expires: May 13, 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-10
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
(LCT) building block, a multiple rate congestion control building (LCT) building block, a multiple rate congestion control building
block and the Forward Error Correction (FEC) building block to block and the Forward Error Correction (FEC) building block to
provide congestion controlled reliable asynchronous delivery of provide congestion controlled reliable asynchronous delivery of
content to an unlimited number of concurrent receivers from a single content to an unlimited number of concurrent receivers from a single
sender. This document obsoletes RFC3450. sender. This document obsoletes RFC 3450.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 13, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5775.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . . . . 5
2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 2.1. LCT Building Block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple rate congestion control building block . . . . . 9 2.2. Multiple Rate Congestion Control Building Block . . . . . 9
2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 10 2.3. FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 12
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 13
4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14 4.1. Packet Format Used by ALC . . . . . . . . . . . . . . . . 13
4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15 4.2. LCT Header Extension Fields . . . . . . . . . . . . . . . 14
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 19 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 18
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 20 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 21 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 25 8. Changes from RFC 3450 . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative references . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
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 5, line 18 skipping to change at page 4, line 20
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 [RFC5651]. 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:
o To each receiver, it appears as if though there is a dedicated o To each receiver, it appears as if there is a dedicated session
session from the sender to the receiver, where the reception rate from the sender to the receiver, where the reception rate adjusts
adjusts to congestion along the path from sender to receiver. to congestion along the path from sender to receiver.
o To the sender, there is no difference in load or outgoing rate if o To the sender, there is no difference in load or outgoing rate if
one receiver is joined to the session or a million (or any number one receiver or a million (or any number of) receivers are joined
of) receivers are joined to the session, independent of when the to the session, independent of when the receivers join and leave.
receivers join and leave.
o No feedback packets are required from receivers to the sender. o No feedback packets are required from receivers to the sender.
o Almost all packets in the session that pass through a bottleneck o Almost all packets in the session that pass through a bottleneck
link are utilized by downstream receivers, and the session shares link are utilized by downstream receivers, and the session shares
the link with competing flows fairly in proportion to their the link with competing flows fairly in proportion to their
utility. utility.
Thus, ALC provides a massively scalable content delivery transport Thus, ALC provides a massively scalable content delivery transport
that is network friendly. that is network friendly.
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 [RFC5651], the FEC building block to the LCT building block [RFC5651], the FEC building block
[RFC5052], the multiple rate congestion control building block and to [RFC5052], the multiple rate congestion control building block, and
any additional building blocks that ALC uses also apply to ALC. to any additional building blocks that ALC uses also apply to ALC.
The IP multicast model defined in [RFC1112] is commonly known as Any- The IP multicast model defined in [RFC1112] is commonly known as Any-
Source Multicast (ASM), in contrast to Source-Specific Multicast Source Multicast (ASM), in contrast to Source-Specific Multicast
(SSM) which is defined in [RFC3569]. One issues that is specific to (SSM) which is defined in [RFC3569]. One issue that is specific to
ALC with respect to ASM is the way the multiple rate congestion ALC with respect to ASM is the way the multiple rate congestion
control building block interacts with ASM. The congestion control control building block interacts with ASM. The congestion control
building block may use the measured difference in time between when a building block may use the measured difference in time between when a
join to a channel is sent and when the first packet from the channel join to a channel is sent and when the first packet from the channel
arrives in determining the receiver reception rate. The congestion arrives in determining the receiver reception rate. The congestion
control building block may also use packet sequence numbers per control building block may also use packet sequence numbers per
channel to measure losses, and this is also used to determine the channel to measure losses, and this is also used to determine the
receiver reception rate. These features raise two concerns with receiver reception rate. These features raise two concerns with
respect to ASM: The time difference between when the join to a respect to ASM: The time difference between when the join to a
channel is sent and when the first packet arrives can be significant channel is sent and when the first packet arrives can be significant
skipping to change at page 7, line 32 skipping to change at page 6, line 20
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 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 [RFC5651]. Like LCT, ALC is designed to be used with described in [RFC5651]. Like LCT, ALC is designed to be used with
the IP multicast network service. This specification defines ALC as the IP multicast network service. This specification defines ALC as
payload of the UDP transport protocol [RFC0768] that supports IP payload of the UDP transport protocol [RFC0768] that supports the IP
multicast delivery of packets. multicast delivery of packets.
The ALC packet format is illustrated in Figure 1. An ALC packet The ALC packet format is illustrated in Figure 1. An ALC packet
header immediately follows the IP/UDP header and consists of the header immediately follows the IP/UDP header and consists of the
default LCT header that is described in [RFC5651] followed by the FEC default LCT header that is described in [RFC5651] followed by the FEC
Payload ID that is described in [RFC5052]. The Congestion Control Payload ID that is described in [RFC5052]. The Congestion Control
Information field within the LCT header carries the required Information field within the LCT header carries the required
Congestion Control Information that is described in the multiple rate Congestion Control Information that is described in the multiple rate
congestion control building block specified that is compliant with congestion control building block specified that is compliant with
[RFC2357]. The packet payload that follows the ALC packet header [RFC2357]. The packet payload that follows the ALC packet header
consists of encoding symbols that are identified by the FEC Payload consists of encoding symbols that are identified by the FEC Payload
ID as described in [RFC5052]. ID as described in [RFC5052].
+----------------------------------------+ +----------------------------------------+
| IP Header | | IP Header |
+----------------------------------------+ +----------------------------------------+
| UDP Header | | UDP Header |
+----------------------------------------+ +----------------------------------------+
| LCT Header | | LCT Header |
+----------------------------------------+ +----------------------------------------+
| FEC Payload Id | | FEC Payload Id |
+----------------------------------------+ +----------------------------------------+
| Encoding Symbols | | Encoding Symbols |
+----------------------------------------+ +----------------------------------------+
Figure 1: ALC Packet Format 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
is outside the scope of this document. is outside the scope of this document.
2.1. LCT building block 2.1. LCT Building Block
LCT requires receivers to be able to uniquely identify and LCT requires receivers to be able to uniquely identify and
demultiplex packets associated with an LCT session, and ALC inherits demultiplex packets associated with an LCT session, and ALC inherits
and strengthens this requirement. A Transport Session Identifier and strengthens this requirement. A Transport Session Identifier
(TSI) MUST be associated with each session and MUST be carried in the (TSI) MUST be associated with each session and MUST be carried in the
LCT header of each ALC packet. The TSI is scoped by the sender IP LCT header of each ALC packet. The TSI is scoped by the sender IP
address, and the (sender IP address, TSI) pair MUST uniquely identify address, and the (sender IP address, TSI) pair MUST uniquely identify
the session. the session.
The LCT header contains a Congestion Control Information (CCI) field The LCT header contains a Congestion Control Information (CCI) field
skipping to change at page 9, line 8 skipping to change at page 8, line 4
field in the LCT header that specifies the length of the CCI field, field in the LCT header that specifies the length of the CCI field,
and the multiple rate congestion control building block MUST uniquely and the multiple rate congestion control building block MUST uniquely
identify a format of the CCI field that corresponds to this length. identify a format of the CCI field that corresponds to this length.
The LCT header contains a Codepoint field that MAY be used to The LCT header contains a Codepoint field that MAY be used to
communicate to a receiver the settings for information that may vary communicate to a receiver the settings for information that may vary
during a session. If used, the mapping between settings and during a session. If used, the mapping between settings and
Codepoint values is to be communicated in the Session Description, Codepoint values is to be communicated in the Session Description,
and this mapping is outside the scope of this document. For example, and this mapping is outside the scope of this document. For example,
the FEC Encoding ID that is part of the FEC Object Transmission the FEC Encoding ID that is part of the FEC Object Transmission
Information as specified in the FEC building block [RFC5052] could Information, as specified in the FEC building block [RFC5052], could
vary for each object carried in the session, and the Codepoint value 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 could be used to communicate the FEC Encoding ID to be used for each
object. The mapping between FEC Encoding IDs and Codepoints could object. The mapping between FEC Encoding IDs and Codepoints could
be, for example, the identity mapping. be, for example, the identity mapping.
If more than one object is to be carried within a session then the 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 Transmission Object Identifier (TOI) MUST be used in the LCT header
to identify which packets are to be associated with which objects. to identify which packets are to be associated with which objects.
In this case the receiver MUST use the TOI to associate received 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 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 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 [RFC5651] The LCT header from version 1 of the LCT building block [RFC5651]
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 2: PSI bits within LCT Headder Figure 2: PSI Bits within LCT Header
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, the SPI MUST be set to
set to 1 when the FEC Payload ID format for packets containing only 1 when the FEC Payload ID format for packets containing only source
source data is used and the SPI MUST be set to zero, when the FEC data is used, and the SPI MUST be set to zero when the FEC Payload ID
Payload ID for packerts containing repair data is used. In the case for packets containing repair data is used. In the case of FEC
of FEC Schemes which define only a single FEC Payload ID format, then Schemes that define only a single FEC Payload ID format, the SPI MUST
the SPI MUST be set to zero by the sender and MUST be ignored by the be set to zero by the sender and MUST be ignored by the receiver.
receiver.
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 that 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 that 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]. Note that At a minimum, implementations of ALC MUST support [RFC3738]. Note
[RFC3738] has been published in the "Experimental" category and thus that [RFC3738] has been published in the "Experimental" category and
has lower maturity level than the present document. Caution should thus has lower maturity level than the present document. Caution
be used since it may be less stable than this document. 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
supported, but only a single congestion control building block may be supported, but only a single congestion control building block may be
used in a given ALC session. The congestion control building block used in a given ALC session. The congestion control building block
to be used in an ALC session is specified in the Session Description to be used in an ALC session is specified in the Session Description
(see Section 2.4). A multiple rate congestion control building block (see Section 2.4). A multiple rate congestion control building block
MAY specify more than one format for the CCI field, but it MUST MAY specify more than one format for the CCI field, but it MUST
specify at most one format for each of the possible lengths 32, 64, specify at most one format for each of the possible lengths 32, 64,
96 or 128 bits. The value of C in the LCT header that determines the 96, or 128 bits. The value of C in the LCT header that determines
length of the CCI field MUST correspond to one of the lengths for the the length of the CCI field MUST correspond to one of the lengths for
CCI defined in the multiple rate congestion control building block, the CCI defined in the multiple rate congestion control building
this length MUST be the same for all packets sent to a session, and block; this length MUST be the same for all packets sent to a
the CCI format that corresponds to the length as specified in the session, and the CCI format that corresponds to the length as
multiple rate congestion control building block MUST be the format specified in the multiple rate congestion control building block MUST
used for the CCI field in the LCT header. be the format 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
sends packets in the session to several channels at potentially sender sends packets in the session to several channels at
different rates. Then, individual receivers adjust their reception potentially different rates. Then, individual receivers adjust their
rate within a session by adjusting which set of channels they are reception rate within a session by adjusting to which set of channels
joined to at each point in time depending on the available bandwidth they are joined at each point in time depending on the available
between the receiver and the sender, but independent of other bandwidth between the receiver and the sender, but independent of
receivers. other receivers.
2.3. FEC building block 2.3. FEC Building Block
The FEC building block [RFC5052] provides reliable object delivery The FEC building block [RFC5052] provides reliable object delivery
within an ALC session. Each object sent in the session is within an ALC session. Each object sent in the session is
independently encoded using FEC codes as described in [RFC3453], independently encoded using FEC codes as described in [RFC3453],
which provide a more in-depth description of the use of FEC codes in which provide a more in-depth description of the use of FEC codes in
reliable content delivery protocols. All packets in an ALC session reliable content delivery protocols. All packets in an ALC session
MUST contain an FEC Payload ID in a format that is compliant with the MUST contain an FEC Payload ID in a format that is compliant with the
FEC Scheme in use. The FEC Payload ID uniquely identifies the FEC Scheme in use. The FEC Payload ID uniquely identifies the
encoding symbols that constitute the payload of each packet, and the encoding symbols that constitute the payload of each packet, and the
receiver MUST use the FEC Payload ID to determine how the encoding receiver MUST use the FEC Payload ID to determine how the encoding
symbols carried in the payload of the packet were generated from the symbols carried in the payload of the packet were generated from the
object as described in the FEC building block. object as described in the FEC building block.
As described in [RFC5052], a receiver is REQUIRED to obtain the FEC As described in [RFC5052], a receiver is REQUIRED to obtain the FEC
Object Transmission Information for each object for which data Object Transmission Information for each object for which data
packets are received from the session. In the context of ALC, the packets are received from the session. In the context of ALC, the
FEC Object Transmission Information includes: FEC Object Transmission Information includes:
o The FEC Encoding ID. o The FEC Encoding ID.
o If an Under-Specified FEC Encoding ID is used then the FEC o If an Under-Specified FEC Encoding ID is used, then the FEC
Instance ID associated with the FEC Encoding ID. Instance ID associated with the FEC Encoding ID.
o For each object in the session, the transfer length of the object o For each object in the session, the transfer length of the object
in bytes. in bytes.
Additional FEC Object Transmission Information may be required Additional FEC Object Transmission Information may be required
depending on the FEC Scheme that is used (identified by the FEC depending on the FEC Scheme that is used (identified by the FEC
Encoding ID). Encoding ID).
Some of the FEC Object Transmission Information MAY be implicit based Some of the FEC Object Transmission Information MAY be implicit based
on the FEC Scheme and/or implementation. As an example, source block on the FEC Scheme and/or implementation. As an example, source block
lengths may be derived by a fixed algorithm from the object length. lengths may be derived by a fixed algorithm from the object length.
As another example, it may be that all source blocks are the same As another example, it may be that all source blocks are the same
length and this is what is passed out-of-band to the receiver. As length and this is what is passed out-of-band to the receiver. As
another example, it could be that the full sized source block length another example, it could be that the full-sized source block length
is provided and this is the length used for all but the last source is provided, and this is the length used for all but the last source
block, which is calculated based on the full source block length and block, which is calculated based on the full source block length and
the object length. As another example, it could be that the same FEC the object length. As another example, it could be that the same FEC
Encoding ID and FEC Instance ID are always used for a particular Encoding ID and FEC Instance ID are always used for a particular
application and thus the FEC Encoding ID and FEC Instance ID are application, and thus the FEC Encoding ID and FEC Instance ID are
implicitly defined. implicitly defined.
Sometimes the objects that will be sent in a session are completely Sometimes the objects that will be sent in a session are completely
known before the receiver joins the session, in which case the FEC known before the receiver joins the session, in which case the FEC
Object Transmission Information for all objects in the session can be Object Transmission Information for all objects in the session can be
communicated to receivers before they join the session. At other communicated to receivers before they join the session. At other
times the objects may not know when the session begins, or receivers times, the objects may not know when the session begins, receivers
may join a session in progress and may not be interested in some may join a session in progress and may not be interested in some
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 an out-of-band mechanism, in-band using the
the Codepoint field or a Header Extension, or any combination of Codepoint field or a Header Extension, or any combination of these
these methods. How the FEC Object Transmission Information is methods. How the FEC Object Transmission Information is communicated
communicated to receivers is outside the scope of this document. to receivers is outside the scope of this document.
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;
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;
o The Transport Session ID (TSI) to be used for the session; o The Transport Session ID (TSI) to be used for the session;
o An indication of whether or not the session carries packets for o An indication of whether or not the session carries packets for
more than one object; more than one object;
o If Header Extensions are to be used, the format of these Header o If Header Extensions are to be used, the format of these Header
Extensions. Extensions.
o Enough information to determine the packet authentication scheme o Enough information to determine the packet authentication scheme
being used, if it is being used. being used, if one is being used.
How the Session Description is communicated to receivers is outside How the Session Description is communicated to receivers is outside
the scope of this document. the scope of this document.
The Codepoint field within the LCT portion of the header CAN be used The Codepoint field within the LCT portion of the header CAN be used
to communicate in-band some of the dynamically changing information to communicate in-band some of the dynamically changing information
within a session. To do this, a mapping between Codepoint values and within a session. To do this, a mapping between Codepoint values and
the different dynamic settings MUST be included within the Session the different dynamic settings MUST be included within the Session
Description, and then settings to be used are communicated via the Description, and then settings to be used are communicated via the
Codepoint value placed into each packet. For example, it is possible Codepoint value placed into each packet. For example, it is possible
skipping to change at page 13, line 29 skipping to change at page 12, line 25
o The mappings between combinations of settings and Codepoint o The mappings between combinations of settings and Codepoint
values; values;
o The data rates used for each channel; o The data rates used for each channel;
o The length of the packet payload; o The length of the packet payload;
o Any information that is relevant to each object being transported, o Any information that is relevant to each object being transported,
such as the Object Transmission Information for each object, when such as the Object Transmission Information for each object, when
the object will be available within the session and for how long. the object will be available within the session, and for how long.
The Session Description could be in a form such as SDP as defined in The Session Description could be in a form such as the Session
[RFC4566], or XML metadata as defined in [RFC3023], or HTTP/Mime Description Protocol (SDP) as defined in [RFC4566], XML metadata as
headers as defined in [RFC2616], etc. It might be carried in a defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616],
session announcement protocol such as SAP as defined in [RFC2974], etc. It might be carried in a session announcement protocol such as
obtained using a proprietary session control protocol, located on a SAP as defined in [RFC2974], obtained using a proprietary session
web page with scheduling information, or conveyed via E-mail or other control protocol, located on a web page with scheduling information,
out-of-band methods. Discussion of Session Description formats and or conveyed via email or other out-of-band methods. Discussion of
methods for communication of Session Descriptions to receivers is Session Description formats and methods for communication of Session
beyond the scope of this document. Descriptions to receivers is 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 [RFC5776] and [RMT-SIMPLE].
[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 [RFC5651], the FEC building block [RFC5052] and building block [RFC5651], the FEC building block [RFC5052], and
[RFC3738] completely specifies a working reliable multicast transport [RFC3738] completely specifies a working reliable multicast transport
protocol that conforms to the requirements described in [RFC2357]. protocol that conforms to the requirements 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 [RFC5651] and the The LCT header is defined in the LCT building block [RFC5651] and the
FEC Payload ID is described in the FEC building block [RFC5052]. The FEC Payload ID is described in the FEC building block [RFC5052]. The
Congestion Control Information field in the LCT header contains the Congestion Control Information field in the LCT header contains the
required Congestion Control Information that is described in the required Congestion Control Information that is described in the
multiple rate congestion control building block used. The packet multiple rate congestion control building block used. The packet
payload contains encoding symbols generated from an object. If more payload contains encoding symbols generated from an object. If more
than one object is carried in the session then the Transmission 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 ID (TOI) within the LCT header MUST be used to identify from
object the encoding symbols are generated from. Within the scope of which object the encoding symbols are generated. Within the scope of
an object, encoding symbols carried in the payload of the packet are an object, encoding symbols carried in the payload of the packet are
identified by the FEC Payload ID as described in the FEC building identified by the FEC 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 [RFC5651]. version 1 of the LCT building block defined in [RFC5651].
The overall ALC packet format is depicted in Figure 3. 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 3: 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
to be non-zero. This implies that the sender MUST NOT set both the REQUIRED to be non-zero. This implies that the sender MUST NOT set
LCT flags S and H to zero. both the LCT flags S and H to zero.
4.2. LCT Header-Extension Fields 4.2. LCT Header Extension Fields
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
[RFC5651], the FEC building block [RFC5052] and the multiple rate [RFC5651], the FEC building block [RFC5052], and the multiple rate
congestion control building block. congestion control building block.
A sender using ALC should make available the required Session A sender using ALC should make available the required Session
Description as described in Section 2.4. A sender should also 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 it 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.
The ALC sender MUST use the same TSI for all packets in the session. The ALC sender MUST use the same TSI for all packets in the session.
Several objects MAY be delivered within the same ALC session. If Several objects MAY be delivered within the same ALC session. If
more than one object is to be delivered within a session then the more than one object is to be delivered within a session, then the
sender MUST use the TOI field and each object MUST be identified by a sender MUST use the TOI field. Each object MUST be identified by a
unique TOI within the session, and the sender MUST use corresponding unique TOI within the session, and the sender MUST use corresponding
TOI for all packets pertaining to the same object. The FEC Payload TOI for all packets pertaining to the same object. The FEC Payload
ID MUST correspond to the encoding symbol(s) for the object carried ID MUST correspond to the encoding symbol(s) for the object carried
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
[RFC5651], the FEC building block [RFC5052] and the multiple rate [RFC5651], the FEC building block [RFC5052], and the multiple rate
congestion control building block. congestion control building block.
To be able to participate in a session, a receiver needs to obtain To be able to participate in a session, a receiver needs to obtain
the required Session Description as listed in Section 2.4. How the required Session Description as listed in Section 2.4. How
receivers obtain a Session Description is outside the scope of this receivers obtain a Session Description is outside the scope of this
document. document.
As described in Section 2.3, a receiver needs to obtain the required As described in Section 2.3, a receiver needs to obtain the required
FEC 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
the TSI carried in the header matches one of the (sender IP the TSI carried in the header matches one of the (sender IP
address, TSI) pairs that was received in a Session Description address, TSI) pairs that was received in a Session Description
and that the receiver is currently joined to. If there is not a and to which the receiver is currently joined. If there is not a
match then the packet MUST be silently discarded without further match, then the packet MUST be silently discarded without further
processing. The remaining steps are performed within the scope processing. The remaining steps are performed within the scope
of the (sender IP address, TSI) session of the received packet. of the (sender IP address, TSI) session of the received packet.
3. The receiver MUST process and act on the CCI field in accordance 3. The receiver MUST process and act on the CCI field in accordance
with the multiple rate congestion control building block. with the multiple rate congestion control building block.
4. If more than one object is carried in the session, the receiver 4. If more than one object is carried in the session, the receiver
MUST verify that the TOI carried in the LCT header is valid. If MUST verify that the TOI carried in the LCT header is valid. If
the TOI is not valid, the packet MUST be discarded without the TOI is not valid, the packet MUST be discarded without
further processing. further processing.
5. The receiver SHOULD process the remainder of the packet, 5. The receiver SHOULD process the remainder of the packet,
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.
5. Security Considerations 5. Security Considerations
The same security consideration that apply to the LCT, FEC and the The same security considerations 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
receive the same forged packet. There are two ways to protect receive the same forged packet. There are two ways to protect
against such attacks, one at the application level and one at the against such attacks, one at the application level and one at the
packet level. It is RECOMMENDED that prevention be provided at both packet level. It is RECOMMENDED that prevention be provided at both
levels. levels.
At the application level, it is RECOMMENDED that an integrity check At the application level, it is RECOMMENDED that an integrity check
on the entire received object be done once the object is on the entire received object be done once the object is
reconstructed to ensure it is the same as the sent object. Moreover, reconstructed to ensure it is the same as the sent object. Moreover,
in order to obtain strong cryptographic integrity protection a in order to obtain strong cryptographic integrity protection, a
digital signature verifiable by the receiver SHOULD be used to digital signature verifiable by the receiver SHOULD be used to
provide this application level integrity check. However, if even one provide this application-level integrity check. However, if even one
corrupted or forged packet is used to reconstruct the object, it is corrupted or forged packet is used to reconstruct the object, it is
likely that the received object will be reconstructed incorrectly. likely that the received object will be reconstructed incorrectly.
This will appropriately cause the integrity check to fail and in this This will appropriately cause the integrity check to fail and in this
case the inaccurately reconstructed object SHOULD be discarded. case, the inaccurately reconstructed object SHOULD be discarded.
Thus, the acceptance of a single forged packet can be an effective Thus, the acceptance of a single forged packet can be an effective
denial of service attack for distributing objects, but an object denial-of-service attack for distributing objects, but an object
integrity check at least prevents inadvertent use of inaccurately integrity check at least prevents inadvertent use of inaccurately
reconstructed objects. The specification of an application level reconstructed objects. The specification of an application-level
integrity check of the received object is outside the scope of this integrity check of the received object is outside the scope of this
document. document.
At the packet level, it is RECOMMENDED that a packet level At the packet level, it is RECOMMENDED that a packet-level
authentication be used to ensure that each received packet is an authentication be used to ensure that each received packet is an
authentic and uncorrupted packet containing data for the object authentic and uncorrupted packet containing data for the object
arriving from the specified sender. Packet level authentication has arriving from the specified sender. Packet-level authentication has
the advantage that corrupt or forged packets can be discarded the advantage that corrupt or forged packets can be discarded
individually and the received authenticated packets can be used to individually and the received authenticated packets can be used to
accurately reconstruct the object. Thus, the effect of a denial of accurately reconstruct the object. Thus, the effect of a denial-of-
service attack that injects forged packets is proportional only to service attack that injects forged packets is proportional only to
the number of forged packets, and not to the object size. the number of forged packets, and not to the object size.
[I-D.ietf-rmt-simple-auth-for-alc-norm]and [RMT-SIMPLE]and [RFC5776] described packet level authentication
[I-D.ietf-msec-tesla-for-alc-norm] described packet level schemes that can be used with the ALC protocol.
authentication schemes which can be used with the ALC protocol.
In addition to providing protection against reconstruction of In addition to providing protection against reconstruction of
inaccurate objects, packet level authentication can also provide some inaccurate objects, packet-level authentication can also provide some
protection against denial of service attacks on the multiple rate protection against denial-of-service attacks on the multiple rate
congestion control. Attackers can try to inject forged packets with congestion control. Attackers can try to inject forged packets with
incorrect congestion control information into the multicast stream, incorrect congestion control information into the multicast stream,
thereby potentially adversely affecting network elements and thereby potentially adversely affecting network elements and
receivers downstream of the attack, and much less significantly the receivers downstream of the attack, and much less significantly the
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. Timed Efficient Stream Loss-Tolerant
also be used to some extent to limit the damage caused by such Authentication (TESLA) [RFC5776] can also be used to some extent to
attacks. However, with TESLA a receiver can only determine if a limit the damage caused by such attacks. However, with TESLA, a
packet is authentic several seconds after it is received, and thus an receiver can only determine if a packet is authentic several seconds
attack against the congestion control protocol can be effective for after it is received, and thus an attack against the congestion
several seconds before the receiver can react to slow down the control protocol can be effective for several seconds before the
session reception rate. receiver can react to slow down the session reception rate.
Some packet authentication schemes such as TESLA Some packet authentication schemes such as TESLA [RFC5776] do not
[I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate allow an immediate authenticity check. In this case, the receiver
authenticity check. In this case the receiver SHOULD check the SHOULD check the authenticity of a packet as soon as possible, and if
authenticity of a packet as soon as possible, and if the packet fails the packet fails the check, then it MUST be silently discarded before
the check then it MUST be silently discarded before step (5) above. Step 5 above. It is RECOMMENDED that if receivers detect many
It is RECOMMENDED that if receivers detect many packets which fail packets that fail authentication checks within a session, the above
authentication checks within a session then the above procedure procedure should be modified for this session so that Step 3 is
should be modified for this session so that Step 3 is delayed until delayed until after the authentication check and only performed if
after the authentication check and only performed if the check the check succeeds.
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 of an
secure mode of operation. However, additional approaches to ALC interoperable secure mode of operation. However, additional
security, including other forms of IPsec application, MAY be approaches to ALC security, including other forms of IPsec
specified in the future. For example, the use of the EXT_AUTH header application, MAY be specified in the future. For example, the use of
extension could enable ALC-specific authentication or security the EXT_AUTH Header Extension could enable ALC-specific
encapsulation headers similar to those of IPsec to be specified and authentication or security encapsulation headers similar to those of
inserted into the ALC/LCT protocol message headers. This would allow IPsec to be specified and inserted into the ALC/LCT protocol message
header compression techniques to be applied to IP and ALC protocol headers. This would allow header compression techniques to be
headers when needed in a similar fashion to that of RTP [RFC3550] and applied to IP and ALC protocol headers when needed in a similar
as preserved in the specification for Secure Real Time Protocol fashion to that of RTP [RFC3550] and as preserved in the
(SRTP) [RFC3711]. specification for Secure Real Time Protocol (SRTP) [RFC3711].
The baseline approach described is applicable to ALC operation The baseline approach described is applicable to ALC operation
configured for SSM (or SSM-like) operation where there is a single configured for SSM (or SSM-like) operation where there is a single
sender. The receiver set would maintain a single IPSec Security sender. The receiver set would maintain a single IPsec Security
Association (SA) for each ALC sender. Association (SA) for each ALC sender.
5.1.1. IPsec Approach 5.1.1. IPsec Approach
To support this baseline form of secure ALC one-to-many SSM To support this baseline form of secure ALC one-to-many SSM
operation, each node SHALL be configured with a transport mode IPsec operation, each node SHALL be configured with a transport mode IPsec
Security Association and corresponding Security Policy Database (SPD) Security Association and corresponding Security Policy Database (SPD)
entry. This entry will be used for sender-to-group multicast packet entry. This entry will be used for sender-to-group multicast packet
authentication and optionally encryption. authentication and optionally encryption.
The ALC sender SHALL use an IPsec SA configured for ESP protocol The ALC sender SHALL use an IPsec SA configured for Encapsulating
[RFC4303] operation with the option for data origination Security Payload (ESP) protocol [RFC4303] operation with the option
authentication enabled. It is also RECOMMENDED that this IPsec ESP for data origination authentication enabled. It is also RECOMMENDED
SA be also configured to provide confidentiality protection for IP that this IPsec ESP SA be also configured to provide confidentiality
packets containing ALC protocol messages. This is suggested to make protection for IP packets containing ALC protocol messages. This is
the realization of complex replay attacks much more difficult. The suggested to make the realization of complex replay attacks much more
encryption key for this SA SHALL be preplaced at the sender and difficult. The encryption key for this SA SHALL be preplaced at the
receiver(s) prior to ALC protocol operation. Use of automated key sender and receiver(s) prior to ALC protocol operation. Use of
management is RECOMMENDED as a rekey SHALL be required prior to automated key management is RECOMMENDED as a rekey SHALL be required
expiration of the sequence space for the SA. This is necessary so prior to expiration of the sequence space for the SA. This is
that receivers may use the built-in IPsec replay attack protection necessary so that receivers may use the built-in IPsec replay attack
possible for an IPsec SA with a single source (the ALC sender). Thus protection possible for an IPsec SA with a single source (the ALC
the receivers SHALL enable replay attack protection for this SA used sender). Thus, the receivers SHALL enable replay attack protection
to secure ALC sender traffic. The sender IPsec SPD entry MUST be for this SA used to secure ALC sender traffic. The sender IPsec SPD
configured to process outbound packets to the destination address and entry MUST be configured to process outbound packets to the
UDP port number of the applicable ALC session. destination address and UDP port number of the applicable ALC
session.
The ALC receiver(s) MUST be configured with the SA and SPD entry to The ALC receiver(s) MUST be configured with the SA and SPD entry to
properly process the IPsec-secured packets from the sender. Note properly process the IPsec-secured packets from the sender. Note
that use of ESP confidentiality, as RECOMMENDED, for secure ALC that use of ESP confidentiality, as RECOMMENDED, for secure ALC
protocol operation makes it more difficult for adversaries to conduct protocol operation makes it more difficult for adversaries to conduct
effective replay attacks that may mislead receivers on content effective replay attacks that may mislead receivers on content
reception. This baseline approach can be used for ALC protocol reception. This baseline approach can be used for ALC protocol
sessions with multiple senders if a distinct SA is established for sessions with multiple senders if a distinct SA is established for
each sender. each sender.
It is anticipated in early deployments of this baseline approach to In early deployments of this baseline approach to ALC security, it is
ALC security that key management will be conducted out-of-band with anticipated that key management will be conducted out-of-band with
respect to ALC protocol operation. For ALC unidirectional operation, respect to ALC protocol operation. For ALC unidirectional operation,
it is possible that receivers may retrieve keying information from a it is possible that receivers may retrieve keying information from a
central server via out-of-band (with respect to ALC) communication as central server via out-of-band (with respect to ALC) communication as
needed or otherwise conduct group key updates with a similar needed or otherwise conduct group key updates with a similar
centralized approach. However, it may be possible with some key centralized approach. However, it may be possible with some key
management schemes for rekey messages to be transmitted to the group management schemes for rekey messages to be transmitted to the group
as a message or transport object within the ALC reliable transfer as a message or transport object within the ALC reliable transfer
session. Additional specification is necessary to define an in-band session. An additional specification is necessary to define an in-
key management scheme for ALC sessions perhaps using the mechanisms band key management scheme for ALC sessions perhaps using the
of the automated group key management specifications cited in this mechanisms of the automated group key management specifications cited
document. in this document.
5.1.2. IPsec Requirements 5.1.2. IPsec Requirements
In order to implement this secure mode of ALC protocol operation, the In order to implement this secure mode of ALC protocol operation, the
following IPsec capabilities are required. following IPsec capabilities are required.
5.1.2.1. Selectors 5.1.2.1. Selectors
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
skipping to change at page 22, line 28 skipping to change at page 20, line 15
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 the Group Domain of Interpretation (GDOI) [RFC3547],
SHOULD be used. Relatively short-lived ALC sessions MAY be able to Group Secure Association Key Management Protocol (GSAKMP) [RFC4535],
use Manual Keying with a single, preplaced key, particularly if or Multimedia Internet KEYing (MIKEY) [RFC3830] SHOULD be used.
Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec Relatively short-lived ALC sessions MAY be able to use Manual Keying
implementation used. It should also be noted that it may be possible with a single, preplaced key, particularly if Extended Sequence
for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be Numbering (ESN) [RFC4303] is available in the IPsec implementation
included in the ALC application reliable data transmission as used. It should also be noted that it may be possible for key update
transport objects if appropriate interfaces were available between messages (e.g., the GDOI GROUPKEY-PUSH message) to be included in the
the ALC application and the key management daemon. ALC application reliable data transmission as transport objects if
appropriate interfaces were available between the ALC application and
the key management daemon.
5.1.2.4. Security Policy 5.1.2.4. Security Policy
Receivers SHOULD accept connections only from the designated, Receivers SHOULD accept connections only from the designated,
authorized sender(s). It is expected that appropriate key management authorized sender(s). It is expected that appropriate key management
will provide encryption keys only to receivers authorized to will provide encryption keys only to receivers authorized to
participate in a designated session. The approach outlined here participate in a designated session. The approach outlined here
allows receiver sets to be controlled on a per-sender basis. allows receiver sets to be controlled on a per-sender basis.
5.1.2.5. Authentication and Encryption 5.1.2.5. Authentication and Encryption
skipping to change at page 23, line 13 skipping to change at page 20, line 50
certificates SHOULD use IP addresses for authentication. However, it certificates SHOULD use IP addresses for authentication. However, it
is likely that available group key management implementations will is likely that available group key management implementations will
not be ALC-specific. not be ALC-specific.
5.1.2.6. Availability 5.1.2.6. Availability
The IPsec requirements profile outlined here is commonly available on The IPsec requirements profile outlined here is commonly available on
many potential ALC hosts. The principal issue is that configuration many potential ALC hosts. The principal issue is that configuration
and operation of IPsec typically requires privileged user and operation of IPsec typically requires privileged user
authorization. Automated key management implementations are authorization. Automated key management implementations are
typically configured with the privileges necessary to effect system typically configured with the privileges necessary to allow the
IPsec configuration needed. needed system IPsec configuration.
6. IANA Considerations 6. IANA Considerations
This specification registers the following LCT Header Extensions This specification registers one value in the LCT Header Extensions
Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: Types namespace as follows:
+-------+---------+--------------------+ +-------+---------+--------------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+---------+--------------------+ +-------+---------+--------------------+
| 64 | EXT_FTI | This specification | | 64 | EXT_FTI | This specification |
+-------+---------+--------------------+ +-------+---------+--------------------+
7. Acknowledgments 7. Acknowledgments
This specification is substantially based on RFC3450 [RFC3450] and This specification is substantially based on RFC 3450 [RFC3450] and
thus credit for the authorship of this document is primarily due to thus credit for the authorship of this document is primarily due to
the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano,
Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and Luigi Rizzo, and Jon Crowcroft. Vincent Roca, Justin Chapweske, and
Roger Kermode also contributed to RFC3450. Additional thanks are due Roger Kermode also contributed to RFC 3450. Additional thanks are
to Vincent Roca and Rod Walsh for contributions to this update to due to Vincent Roca and Rod Walsh for contributions to this update to
Proposed Standard. Proposed Standard.
8. Changes from RFC3450 8. Changes from RFC 3450
This section summarises the changes that were made from the This section summarizes the changes that were made from the
Experimental version of this specification published as RFC3450 "Experimental" version of this specification published as RFC 3450
[RFC3450]: [RFC3450]:
o Update all references to the obsoleted RFC 2068 to RFC 2616 o Updated all references to the obsoleted RFC 2068 to RFC 2616.
o Removed the 'Statement of Intent' from the introduction (The o Removed the 'Statement of Intent' from the introduction. (The
statement of intent was meant to clarify the "Experimental" status Statement of Intent was meant to clarify the "Experimental" status
of RFC3450.) of RFC 3450.)
o Removed the 'Intellectual Property Issues' Section and replaced o Removed the 'Intellectual Property Issues' Section and replaced
with a standard IPR Statement with a standard IPR Statement.
o Remove material duplicated in LCT o Removed material duplicated in LCT.
o Update references for LCT and FEC Building Block to new versions o Updated references in this document to new versions of the LCT
and align with changes in the FEC Building Block. Building Block and the FEC Building Block, and aligned this
document with changes in the new version of the FEC Building
Block.
o Split normative and informative references o Split normative and informative references.
o Material applicable in a general LCT context, not just for ALC has o Material applicable in a general LCT context, not just for ALC has
been moved to LCT been moved to LCT.
o The first bit of the "Protocol Specific Indication" in the LCT o The first bit of the "Protocol-Specific Indication" in the LCT
Header is defined as a "Source Packet Indication". This is used Header is defined as a "Source Packet Indication". This is used
in the case that an FEC Scheme defines two FEC Payload ID formats, in the case that an FEC Scheme defines two FEC Payload ID formats,
one of which is for packets containing only source symbols which one of which is for packets containing only source symbols that
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
[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",
RFC 1112, August 1989. STD 5, 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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004. Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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:
Description Protocol", RFC 4566, July 2006. Session 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 [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] [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson,
Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in "IETF Criteria for Evaluating Reliable Multicast
the ALC and NORM Protocols", Transport and Application Protocols", RFC 2357,
draft-ietf-msec-tesla-for-alc-norm-10 (work in progress), June 1998.
October 2009.
[I-D.ietf-rmt-simple-auth-for-alc-norm] [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Roca, V., "Simple Authentication Schemes for the ALC and Announcement Protocol", RFC 2974, October 2000.
NORM Protocols",
draft-ietf-rmt-simple-auth-for-alc-norm-02 (work in
progress), October 2009.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Criteria for Evaluating Reliable Multicast Transport and Floyd, S., and M. Luby, "Reliable Multicast Transport
Application Protocols", RFC 2357, June 1998. Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Announcement Protocol", RFC 2974, October 2000. Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269,
April 2002.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Floyd, S., and M. Luby, "Reliable Multicast Transport Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Building Blocks for One-to-Many Bulk-Data Transfer", Instantiation", RFC 3450, December 2002.
RFC 3048, January 2001.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Reliable Multicast Transport (RMT) Building Blocks and Handley, M., and J. Crowcroft, "The Use of Forward
Protocol Instantiation documents", RFC 3269, April 2002. Error Correction (FEC) in Reliable Multicast",
RFC 3453, December 2002.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol "The Group Domain of Interpretation", RFC 3547,
Instantiation", RFC 3450, December 2002. July 2003.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
M., and J. Crowcroft, "The Use of Forward Error Correction Jacobson, "RTP: A Transport Protocol for Real-Time
(FEC) in Reliable Multicast", RFC 3453, December 2002. Applications", STD 64, RFC 3550, July 2003.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Group Domain of Interpretation", RFC 3547, July 2003. Multicast (SSM)", RFC 3569, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Jacobson, "RTP: A Transport Protocol for Real-Time Protocol (MSDP)", RFC 3618, October 2003.
Applications", STD 64, RFC 3550, July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
Multicast (SSM)", RFC 3569, July 2003. K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Protocol (MSDP)", RFC 3618, October 2003. K. Norrman, "MIKEY: Multimedia Internet KEYing",
RFC 3830, August 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
Norrman, "The Secure Real-time Transport Protocol (SRTP)", "GSAKMP: Group Secure Association Key Management
RFC 3711, March 2004. Protocol", RFC 4535, June 2006.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Efficient Stream Loss-Tolerant Authentication (TESLA)
August 2004. in the Asynchronous Layered Coding (ALC) and NACK-
Oriented Reliable Multicast (NORM) Protocols",
RFC 5776, April 2010.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RMT-SIMPLE] Roca, V., "Simple Authentication Schemes for the ALC
"GSAKMP: Group Secure Association Key Management and NORM Protocols", Work in Progress, October 2009.
Protocol", RFC 4535, June 2006.
Authors' Addresses Authors' Addresses
Michael Luby Michael Luby
Qualcomm Inc. Qualcomm, Inc.
3165 Kifer Road 3165 Kifer Road
Santa Clara, CA 95051 Santa Clara, CA 95051
US US
Email: luby@qualcomm.com EMail: luby@qualcomm.com
Mark Watson Mark Watson
Qualcomm Inc. Qualcomm, Inc.
3165 Kifer Road 3165 Kifer Road
Santa Clara, CA 95051 Santa Clara, CA 95051
US US
Email: watson@qualcomm.com EMail: watson@qualcomm.com
Lorenzo Vicisano Lorenzo Vicisano
Qualcomm Inc. Qualcomm, Inc.
3165 Kifer Road 3165 Kifer Road
Santa Clara, CA 95051 Santa Clara, CA 95051
US US
Email: vicisano@qualcomm.com EMail: vicisano@qualcomm.com
 End of changes. 141 change blocks. 
348 lines changed or deleted 339 lines changed or added

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