draft-ietf-rmt-pi-alc-revised-00.txt   draft-ietf-rmt-pi-alc-revised-01.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Digital Fountain Working Group Watson
Internet-Draft Gemmell Internet-Draft Digital Fountain
Expires: January 7, 2006 Microsoft Research Expires: April 22, 2006 Gemmell
Microsoft Research
Vicisano Vicisano
Cisco Systems, Inc. Cisco Systems, Inc.
Rizzo Rizzo
Univ. di Pisa Univ. di Pisa
Crowcroft Crowcroft
University of Cambridge University of Cambridge
July 6, 2005 October 19, 2005
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-00 draft-ietf-rmt-pi-alc-revised-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2006. This Internet-Draft will expire on April 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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. sender.
Table of Contents Table of Contents
skipping to change at page 2, line 15 skipping to change at page 2, line 16
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. sender.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Delivery service models . . . . . . . . . . . . . . . . . 4 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4
1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Environmental Requirements and Considerations . . . . . . 6 1.3. Environmental Requirements and Considerations . . . . . . 4
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6
2.1 LCT building block . . . . . . . . . . . . . . . . . . . . 10 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7
2.2 Multiple rate congestion control building block . . . . . 11 2.2. Multiple rate congestion control building block . . . . . 8
2.3 FEC building block . . . . . . . . . . . . . . . . . . . . 11 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9
2.4 Session Description . . . . . . . . . . . . . . . . . . . 13 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5 Packet authentication building block . . . . . . . . . . . 15 2.5. Packet authentication building block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 16 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 17 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14
4.1 Packet format used by ALC . . . . . . . . . . . . . . . . 17 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14
4.2 Detailed Example of Packet format used by ALC . . . . . . 18 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15
4.3 Header-Extension Fields . . . . . . . . . . . . . . . . . 26 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16
4.4 Sender Operation . . . . . . . . . . . . . . . . . . . . . 28 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16
4.5 Receiver Operation . . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. RFC3450 to draft-ietf-rmt-pi-alc-revised-00 . . . . . . . 23
8.1 RFC3450 to draft-ietf-rmt-pi-alc-revised-00 . . . . . . . 36 8.2. draft-ietf-rmt-pi-alc-revised-01 . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 39 9.2. Informative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes a massively scalable reliable content This document describes a massively scalable reliable content
delivery protocol, Asynchronous Layered Coding (ALC), for multiple delivery protocol, Asynchronous Layered Coding (ALC), for multiple
rate congestion controlled reliable content delivery. The protocol rate congestion controlled reliable content delivery. The protocol
is specifically designed to provide massive scalability using IP is specifically designed to provide massive scalability using IP
multicast as the underlying network service. Massive scalability in multicast as the underlying network service. Massive scalability in
this context means the number of concurrent receivers for an object this context means the number of concurrent receivers for an object
is potentially in the millions, the aggregate size of objects to be is potentially in the millions, the aggregate size of objects to be
skipping to change at page 4, line 7 skipping to change at page 4, line 7
instantiation that provides reliable content delivery without instantiation that provides reliable content delivery without
unnecessary limitations to the scalability of the basic protocol. unnecessary limitations to the scalability of the basic protocol.
This document is a product of the IETF RMT WG and follows the general This document is a product of the IETF RMT WG and follows the general
guidelines provided in [RFC3269]. guidelines provided in [RFC3269].
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. Some examples are briefly described here. models as described in [I-D.ietf-rmt-bb-lct-revised].
Push service model
A push model is a sender initiated concurrent delivery of objects
to a selected set of receivers. A push service model can be used
for example for reliable delivery of a large object such as a 100
GB file. The sender could send a Session Description announcement
to a control channel and receivers could monitor this channel and
join a session whenever a Session Description of interest arrives.
Upon receipt of the Session Description, each receiver could join
the session to receive packets until enough packets have arrived
to reconstruct the object, at which point the receiver could
report back to the sender that its reception was completed
successfully. The sender could decide to continue sending packets
for the object to the session until all receivers have reported
successful reconstruction or until some other condition has been
satisfied. In this example, the sender uses ALC to generate
packets based on the object and send packets to channels
associated with the session, and the receivers use ALC to receive
packets from the session and reconstruct the object.
There are several features ALC provides to support the push model.
For example, the sender can optionally include an Expected
Residual Time (ERT) in the packet header that indicates the
expected remaining time of packet transmission for either the
single object carried in the session or for the object identified
by the Transmission Object Identifier (TOI) if there are multiple
objects carried in the session. This can be used by receivers to
determine if there is enough time remaining in the session to
successfully receive enough additional packets to recover the
object. If for example there is not enough time, then the push
application may have receivers report back to the sender to extend
the transmission of packets for the object for enough time to
allow the receivers to obtain enough packets to reconstruct the
object. The sender could then include an ERT based on the
extended object transmission time in each subsequent packet header
for the object. As other examples, the LCT header optionally can
contain a Close Session flag that indicates when the sender is
about to end sending packet to the session and a Close Object flag
that indicates when the sender is about to end sending packets to
the session for the object identified by the Transmission Object
ID. However, these flags are not a completely reliable mechanism
and thus the Close Session flag should only be used as a hint of
when the session is about to close and the Close Object flag
should only be used as a hint of when transmission of packets for
the object is about to end.
The push model is particularly attractive in satellite networks
and wireless networks. In these environments a session may
include one channel and a sender may send packets at a fixed rate
to this channel, but sending at a fixed rate without congestion
control is outside the scope of this document.
On-demand content delivery model
For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to
allow all the intended receivers to join the session and recover a
single object. For example a popular software update might be
transmitted using ALC for several days, even though a receiver may
be able to complete the download in one hour total of connection
time, perhaps spread over several intervals of time. In this case
the receivers join the session at any point in time when it is
active. Receivers leave the session when they have received
enough packets to recover the object. The receivers, for example,
obtain a Session Description by contacting a web server.
Other service models
There may be other reliable content delivery service models that
can be supported by ALC. The description of the potential
applications, the appropriate delivery service model, and the
additional mechanisms to support such functionalities when
combined with ALC is beyond the scope of this document.
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 though there is a dedicated
session from the sender to the receiver, where the reception rate session from the sender to the receiver, where the reception rate
skipping to change at page 6, line 27 skipping to change at page 4, line 47
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 [RFC3451], the FEC building block to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC
[RFC3452], the multiple rate congestion control building block and to building block [I-D.ietf-rmt-fec-bb-revised], the multiple rate
any additional building blocks that ALC uses also apply to ALC. congestion control building block and to any additional building
blocks that ALC uses also apply to ALC.
ALC requires connectivity between a sender and receivers, but does
not require connectivity from receivers to a sender. ALC inherently
works with all types of networks, including LANs, WANs, Intranets,
the Internet, asymmetric networks, wireless networks, and satellite
networks. Thus, the inherent raw scalability of ALC is unlimited.
However, ALC requires receivers to obtain the Session Description
out-of-band before joining a session and some implementations of this
may limit scalability.
If a receiver is joined to multiple ALC sessions then the receiver
MUST be able to uniquely identify and demultiplex packets to the
correct session. The Transmission Session Identifier (TSI) that MUST
appear in each packet header is used for this purpose. The TSI is
scoped by the IP address of the sender, and the IP address of the
sender together with the TSI uniquely identify the session. Thus,
the demultiplexing MUST be done on the basis of the IP address of the
sender and the TSI of the session from that sender.
ALC is presumed to be used with an underlying IP multicast network or
transport service that is a "best effort" service that does not
guarantee packet reception, packet reception order, and which does
not have any support for flow or congestion control. There are
currently two models of multicast delivery, the Any-Source Multicast
(ASM) model as defined in [RFC1112] and the Source-Specific Multicast
(SSM) model as defined in [HOL2001]. ALC works with both multicast
models, but in a slightly different way with somewhat different
environmental concerns. When using ASM, a sender S sends packets to
a multicast group G, and an ALC channel address consists of the pair
(S,G), where S is the IP address of the sender and G is a multicast
group address. When using SSM, a sender S sends packets to an SSM
channel (S,G), and an ALC channel address coincides with the SSM
channel address.
A sender can locally allocate unique SSM channel addresses, and this
makes allocation of ALC channel addresses easy with SSM. To allocate
ALC channel addresses using ASM, the sender must uniquely choose the
ASM multicast group address across the scope of the group, and this
makes allocation of ALC channel addresses more difficult with ASM.
ALC channels and SSM channels coincide, and thus the receiver will
only receive packets sent to the requested ALC channel. With ASM,
the receiver joins an ALC channel by joining a multicast group G, and
all packets sent to G, regardless of the sender, may be received by
the receiver. Thus, SSM has compelling security advantages over ASM
for prevention of denial of service attacks. In either case,
receivers SHOULD use mechanisms to filter out packets from unwanted
sources.
Other issues specific to ALC with respect to ASM is the way the
multiple rate congestion control building block interacts with ASM.
The congestion control 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 arrives in determining the receiver reception
rate. The congestion control building block may also uses packet
sequence numbers per channel to measure losses, and this is also used
to determine the receiver reception rate. These features raise two
concerns with respect to ASM: The time difference between when the
join to a channel is sent and when the first packet arrives can be
significant due to the use of Rendezvous Points (RPs) and the MSDP
protocol, and packets can be lost in the switch over from the (*,G)
join to the RP and the (S,G) join directly to the sender. Both of
these issues could potentially substantially degrade the reception
rate of receivers. To ameliorate these concerns, it is RECOMMENDED
that the RP be as close to the sender as possible. SSM does not
share these same concerns. For a fuller consideration of these
issues, consult the multiple rate congestion control building block.
Some networks are not amenable to some congestion control protocols
that could be used with ALC. In particular, for a satellite or
wireless network, there may be no mechanism for receivers to
effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session.
ALC is compatible with either IPv4 or IPv6 as no part of the packet One issues that is specific to ALC with respect to the Any- Source
is IP version specific. Multicast (ASM) model of IP multicast as defined in RFC 1112
[RFC1112] is the way the multiple rate congestion control building
block interacts with ASM. The congestion control 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 arrives in
determining the receiver reception rate. The congestion control
building block may also uses packet sequence numbers per channel to
measure losses, and this is also used to determine the receiver
reception rate. These features raise two concerns with respect to
ASM: The time difference between when the join to a channel is sent
and when the first packet arrives can be significant due to the use
of Rendezvous Points (RPs) and the MSDP protocol, and packets can be
lost in the switch over from the (*,G) join to the RP and the (S,G)
join directly to the sender. Both of these issues could potentially
substantially degrade the reception rate of receivers. To ameliorate
these concerns, it is RECOMMENDED that the RP be as close to the
sender as possible. SSM does not share these same concerns. For a
fuller consideration of these issues, consult the multiple rate
congestion control building block.
2. Architecture Definition 2. Architecture Definition
ALC uses the LCT building block [RFC3451] to provide in-band session ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to
management functionality. ALC uses a multiple rate congestion provide in-band session management functionality. ALC uses a
control building block that is compliant with [RFC2357] to provide multiple rate congestion control building block that is compliant
congestion control that is feedback free. Receivers adjust their with [RFC2357] to provide congestion control that is feedback free.
reception rates individually by joining and leaving channels Receivers adjust their reception rates individually by joining and
associated with the session. ALC uses the FEC building block leaving channels associated with the session. ALC uses the FEC
[RFC3452] to provide reliability. The sender generates encoding building block [I-D.ietf-rmt-fec-bb-revised] to provide reliability.
symbols based on the object to be delivered using FEC codes and sends The sender generates encoding symbols based on the object to be
them in packets to channels associated with the session. Receivers delivered using FEC codes and sends them in packets to channels
simply wait for enough packets to arrive in order to reliably associated with the session. Receivers simply wait for enough
reconstruct the object. Thus, there is no request for retransmission packets to arrive in order to reliably reconstruct the object. Thus,
of individual packets from receivers that miss packets in order to there is no request for retransmission of individual packets from
assure reliable reception of an object, and the packets and their receivers that miss packets in order to assure reliable reception of
rate of transmission out of the sender can be independent of the an object, and the packets and their rate of transmission out of the
number and the individual reception experiences of the receivers. sender can be independent of the number and the individual reception
experiences of the receivers.
The definition of a session for ALC is the same as it is for LCT. An The definition of a session for ALC is the same as it is for LCT. An
ALC session comprises multiple channels originating at a single ALC session comprises multiple channels originating at a single
sender that are used for some period of time to carry packets sender that are used for some period of time to carry packets
pertaining to the transmission of one or more objects that can be of pertaining to the transmission of one or more objects that can be of
interest to receivers. Congestion control is performed over the interest to receivers. Congestion control is performed over the
aggregate of packets sent to channels belonging to a session. The aggregate of packets sent to channels belonging to a session. The
fact that an ALC session is restricted to a single sender does not fact that an ALC session is restricted to a single sender does not
preclude the possibility of receiving packets for the same objects preclude the possibility of receiving packets for the same objects
from multiple senders. However, each sender would be sending packets from multiple senders. However, each sender would be sending packets
to a a different session to which congestion control is individually to a a different session to which congestion control is individually
applied. Although receiving concurrently from multiple sessions is applied. Although receiving concurrently from multiple sessions is
allowed, how this is done at the application level is outside the allowed, how this is done at the application level is outside the
scope of this document. scope of this document.
ALC is a protocol instantiation as defined in [RFC3048]. This ALC is a protocol instantiation as defined in [RFC3048]. This
document describes version 1 of ALC which MUST use version 1 of LCT document describes version 1 of ALC which MUST use version 1 of LCT
described in [RFC3451]. Like LCT, ALC is designed to be used with described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is
the IP multicast network service. This specification defines ALC as designed to be used with the IP multicast network service. This
payload of the UDP transport protocol [RFC0768] that supports IP specification defines ALC as payload of the UDP transport protocol
multicast delivery of packets. Future versions of this [RFC0768] that supports IP multicast delivery of packets. Future
specification, or companion documents may extend ALC to use the IP versions of this specification, or companion documents may extend ALC
network layer service directly. ALC could be used as the basis for to use the IP network layer service directly. ALC could be used as
designing a protocol that uses a different underlying network service the basis for designing a protocol that uses a different underlying
such as unicast UDP, but the design of such a protocol is outside the network service such as unicast UDP, but the design of such a
scope of this document. protocol is outside the scope of this document.
An ALC packet header immediately follows the UDP header and consists An ALC packet header immediately follows the UDP header and consists
of the default LCT header that is described in [RFC3451] followed by of the default LCT header that is described in [I-D.ietf-rmt-bb-lct-
the FEC Payload ID that is described in [RFC3452]. The Congestion revised] followed by the FEC Payload ID that is described in
Control Information field within the LCT header carries the required [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control Information
Congestion Control Information that is described in the multiple rate field within the LCT header carries the required Congestion Control
congestion control building block specified that is compliant with Information that is described in the multiple rate congestion control
[RFC2357]. The packet payload that follows the ALC packet header building block specified that is compliant with [RFC2357]. The
consists of encoding symbols that are identified by the FEC Payload packet payload that follows the ALC packet header consists of
ID as described in [RFC3452]. encoding symbols that are identified by the FEC Payload ID as
described in [I-D.ietf-rmt-fec-bb-revised].
Each receiver is required to obtain a Session Description before 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
[RFC3452] required for each object to be received by a receiver can [I-D.ietf-rmt-fec-bb-revised] required for each object to be received
be communicated to a receiver either out-of-band or in-band using a by a receiver can be communicated to a receiver either out-of-band or
Header Extension. The means for communicating the Session in-band using a Header Extension. The means for communicating the
Description and the FEC Object Transmission Information to a receiver Session Description and the FEC Object Transmission Information to a
is outside the scope of this document. receiver 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 10, line 44 skipping to change at page 7, line 46
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 [RFC3452] could Information as specified in the FEC building block [I-D.ietf-rmt-fec-
vary for each object carried in the session, and the Codepoint value bb-revised] could vary for each object carried in the session, and
could be used to communicate the FEC Encoding ID to be used for each the Codepoint value could be used to communicate the FEC Encoding ID
object. The mapping between FEC Encoding IDs and Codepoints could to be used for each object. The mapping between FEC Encoding IDs and
be, for example, the identity mapping. Codepoints could 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 MAY for each object is REQUIRED to be unique within a session, but MAY
NOT be unique across sessions. Furthermore, the same object MAY have NOT be unique across sessions. Furthermore, the same object MAY have
a different TOI in different sessions. The mapping between TOIs and a different TOI in different sessions. The mapping between TOIs and
objects carried in a session is outside the scope of this document. objects carried in a session is outside the scope of this document.
If only one object is carried within a session then the TOI MAY be If only one object is carried within a session then the TOI MAY be
omitted from the LCT header. omitted from the LCT header.
The default LCT header from version 1 of the LCT building block The LCT header from version 1 of the LCT building block [I-D.ietf-
[RFC3451] MUST be used. rmt-bb-lct-revised] MUST be used.
2.2 Multiple rate congestion control building block The LCT Header includes a two-bit Protocol Specific Indication (PSI)
field. These two bits are used by ALC as follows:
PSI bit 0 (LSB) - Source Packet Indicator (SPI)
PSI bit 1 (MSB) - Reserved
The Source Packet Indicator is used with systematic FEC Schemes which
define a different FEC Payload ID format for packets containing only
source data compared to the FEC Payload ID format for packets
containing repair data. For such FEC Schemes, then the SPI MUST be
set to 1 when the FEC Payload ID format for packets containing only
source data is used and the SPI MUST be set to zero, when the FEC
Payload ID for packerts containing repair data is used. In the case
of FEC Schemes which define only a single FEC Payload ID format, then
the SPI MUST be set to zero by the sender and MUST be ignored by the
receiver.
Support of two FEC Payload ID formats allows FEC Payload ID
information which is only of relevance when FEC decoding is to be
performed to be provided in the FEC Payload ID format for packets
containing repair data. This information need not be processed by
receivers which do not perform FEC decoding (either because no FEC
decoding is required or because the receiver does not support FEC
decoding).
2.2. Multiple rate congestion control building block
Implementors of ALC MUST implement a multiple rate feedback-free Implementors of ALC MUST implement a multiple rate feedback-free
congestion control building block that is in accordance to [RFC2357]. congestion control building block that is in accordance to [RFC2357].
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. The multiple rate congestion control for reliable content delivery. The multiple rate congestion control
building block MUST specify in-band Congestion Control Information building block MUST specify in-band Congestion Control Information
(CCI) that MUST be carried in the CCI field of the LCT header. The (CCI) that MUST be carried in the CCI field of the LCT header. The
skipping to change at page 11, line 49 skipping to change at page 9, line 29
header. header.
When using a multiple rate congestion control building block a sender When using a multiple rate congestion control building block a sender
sends packets in the session to several channels at potentially sends packets in the session to several channels at potentially
different rates. Then, individual receivers adjust their reception different rates. Then, individual receivers adjust their reception
rate within a session by adjusting which set of channels they are rate within a session by adjusting which set of channels they are
joined to at each point in time depending on the available bandwidth joined to at each point in time depending on the available bandwidth
between the receiver and the sender, but independent of other between the receiver and the sender, but independent of other
receivers. receivers.
2.3 FEC building block 2.3. FEC building block
The FEC building block [RFC3452] provides reliable object delivery The FEC building block [I-D.ietf-rmt-fec-bb-revised] provides
within an ALC session. Each object sent in the session is reliable object delivery within an ALC session. Each object sent in
independently encoded using FEC codes as described in [RFC3453], the session is independently encoded using FEC codes as described in
which provide a more in-depth description of the use of FEC codes in [RFC3453], which provide a more in-depth description of the use of
reliable content delivery protocols. All packets in an ALC session FEC codes in reliable content delivery protocols. All packets in an
MUST contain an FEC Payload ID in a format that is compliant with the ALC session MUST contain an FEC Payload ID in a format that is
FEC building block [RFC3452]. The FEC Payload ID uniquely identifies compliant with the FEC Scheme in use. The FEC Payload ID uniquely
the encoding symbols that constitute the payload of each packet, and identifies the encoding symbols that constitute the payload of each
the receiver MUST use the FEC Payload ID to determine how the packet, and the receiver MUST use the FEC Payload ID to determine how
encoding symbols carried in the payload of the packet were generated the encoding symbols carried in the payload of the packet were
from the object as described in the FEC building block. generated from the object as described in the FEC building block.
As described in [RFC3452], a receiver is REQUIRED to obtain the FEC As described in [I-D.ietf-rmt-fec-bb-revised], a receiver is REQUIRED
Object Transmission Information for each object for which data to obtain the FEC Object Transmission Information for each object for
packets are received from the session. The FEC Object Transmission which data packets are received from the session. In the context of
Information includes: ALC, the 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 length of the object in bytes. o For each object in the session, the transfer length of the object
in bytes.
o The additional required FEC Object Transmission Information for Additional FEC Object Transmission Information may be required
the FEC Encoding ID as prescribed in the FEC building block depending on the FEC Scheme that is used (identified by the FEC
[RFC3452]. For example, when the FEC Encoding ID is 128, the Encoding ID).
required FEC Object Transmission Information is the number of
source blocks that the object is partitioned into and the length
of each source block in bytes.
Some of the FEC Object Transmission Information MAY be implicit based Some of the FEC Object Transmission Information MAY be implicit based
on the implementation. As an example, source block lengths may be on the FEC Scheme and/or implementation. As an example, source block
derived by a fixed algorithm from the object length. As another lengths may be derived by a fixed algorithm from the object length.
example, it may be that all source blocks are the same length and As another example, it may be that all source blocks are the same
this is what is passed out-of-band to the receiver. As another length and this is what is passed out-of-band to the receiver. As
example, it could be that the full sized source block length is another example, it could be that the full sized source block length
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
skipping to change at page 13, line 41 skipping to change at page 11, line 18
FEC Object Transmission Information is communicated out-of-band to FEC Object Transmission Information is communicated out-of-band to
receivers is outside the scope of this document. receivers is outside the scope of this document.
It is also possible that there is a portion of the FEC Object It is also possible that there is a portion of the FEC Object
Transmission Information that may vary from object to object that is Transmission Information that may vary from object to object that is
carried in-band, for example in the CodePoint field or in Header carried in-band, for example in the CodePoint field or in Header
Extensions. How this is done is outside the scope of this document. Extensions. How this is done is outside the scope of this document.
In this case the FEC Object Transmission Information is associated In this case the FEC Object Transmission Information is associated
with the object identified by the TOI carried in the packet. with the object identified by the TOI carried in the packet.
2.4 Session Description 2.4. Session Description
The Session Description that a receiver is REQUIRED to obtain before The Session Description that a receiver is REQUIRED to obtain before
joining an ALC session MUST contain the following information: joining an ALC session MUST contain 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
skipping to change at page 15, line 15 skipping to change at page 12, line 39
The Session Description could be in a form such as SDP as defined in The Session Description could be in a form such as SDP as defined in
[RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime
headers as defined in [RFC2616], etc. It might be carried in a headers as defined in [RFC2616], etc. It might be carried in a
session announcement protocol such as SAP as defined in [RFC2974], session announcement protocol such as SAP as defined in [RFC2974],
obtained using a proprietary session control protocol, located on a obtained using a proprietary session control protocol, located on a
web page with scheduling information, or conveyed via E-mail or other web page with scheduling information, or conveyed via E-mail or other
out-of-band methods. Discussion of Session Description formats and out-of-band methods. Discussion of Session Description formats and
methods for communication of Session Descriptions to receivers is methods for communication of Session Descriptions to receivers is
beyond the scope of this document. beyond the scope of this document.
2.5 Packet authentication building block 2.5. Packet authentication building block
It is RECOMMENDED that implementors of ALC use some packet It is RECOMMENDED that implementors of ALC use some packet
authentication scheme to protect the protocol from attacks. An authentication scheme to protect the protocol from attacks. An
example of a possibly suitable scheme is described in [PER2001]. example of a possibly suitable scheme is described in [PER2001].
Packet authentication in ALC, if used, is to be integrated through Packet authentication in ALC, if used, is to be integrated through
the Header Extension support for packet authentication provided in the Header Extension support for packet authentication provided in
the LCT building block. the LCT building block.
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 [RFC3451], the FEC building block [RFC3452] and with a building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block
multiple rate congestion control building block completely specifies [I-D.ietf-rmt-fec-bb-revised] and with a multiple rate congestion
a working reliable multicast transport protocol that conforms to the control building block completely specifies a working reliable
requirements described in [RFC2357]. multicast transport 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 The packet format used by ALC is the UDP header followed by the LCT
default LCT header followed by the FEC Payload ID followed by the header followed by the FEC Payload ID followed by the packet payload.
packet payload. The default LCT header is described in the LCT The LCT header is defined in the LCT building block [I-D.ietf-rmt-bb-
building block [RFC3451] and the FEC Payload ID is described in the lct-revised] and the FEC Payload ID is described in the FEC building
FEC building block [RFC3452]. The Congestion Control Information block [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control
field in the LCT header contains the REQUIRED Congestion Control Information field in the LCT header contains the REQUIRED Congestion
Information that is described in the multiple rate congestion control Control Information that is described in the multiple rate congestion
building block used. The packet payload contains encoding symbols control building block used. The packet payload contains encoding
generated from an object. If more than one object is carried in the symbols generated from an object. If more than one object is carried
session then the Transmission Object ID (TOI) within the LCT header in the session then the Transmission Object ID (TOI) within the LCT
MUST be used to identify which object the encoding symbols are header MUST be used to identify which object the encoding symbols are
generated from. Within the scope of an object, encoding symbols generated from. Within the scope of an object, encoding symbols
carried in the payload of the packet are identified by the FEC carried in the payload of the packet are identified by the FEC
Payload ID as described in the FEC building block. Payload ID as described in the FEC building block.
The version number of ALC specified in this document is 1. This The version number of ALC specified in this document is 1. The
coincides with version 1 of the LCT building block [RFC3451] used in version number field of the LCT header MUST be interpreted as the ALC
this specification. The LCT version number field should be version number field. This version of ALC implicitly makes use of
interpreted as the ALC version number field. version 1 of the LCT building block defined in [I-D.ietf-rmt-bb-lct-
revised].
The overall ALC packet format is depicted in Figure 1. The packet is The overall ALC packet format is depicted in Figure 1. 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. The default LCT header MUST be used by ALC and this default number.
is described in detail in the LCT building block [RFC3451].
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 |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header | | LCT header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID | | FEC Payload ID |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) | | Encoding Symbol(s) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall ALC packet format Figure 1: 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.
4.2 Detailed Example of Packet format used by ALC For ALC the length of the TSI field within the LCT header is REQUIRED
to be non-zero. This implies that the sender MUST NOT set both the
A detailed example of an ALC packet starting with the LCT header is LCT flags S and H to zero.
shown in Figure 2. In the example, the LCT header is the first 5 32-
bit words, the FEC Payload ID is the next 2 32-bit words, and the
remainder of the packet is the payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 |1| 1 |0|1|0|0|0| 5 | 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: A detailed example of the ALC packet format
The LCT portion of the overall ALC packet header is of variable size,
which is specified by a length field in the third byte of the header.
All integer fields are carried in "big-endian" or "network order"
format, that is, most significant byte (octet) first. Bits
designated as "padding" or "reserved" (r) MUST by set to 0 by senders
and ignored by receivers. Unless otherwise noted, numeric constants
in this specification are in decimal (base 10).
The function and length and particular setting of the value for each
field in this detailed example of the header is the following,
described in the order of their appearance in the header.
ALC version number (V): 4 bits
Indicates the ALC version number. The ALC version number for this
specification is 1 as shown. This is also the LCT version number.
Congestion control flag (C): 2 bits
The Congestion Control Information (CCI) field specified by the
multiple rate congestion control building block is a multiple of
32-bits in length. The multiple rate congestion control building
block MUST specify a format for the CCI. The congestion control
building block MAY specify formats for different CCI lengths,
where the set of possible lengths is 32, 64, 96 or 128 bits. The
value of C MUST match the length of exactly one of the possible
formats for the congestion control building block, and this format
MUST be used for the CCI field. The value of C MUST be the same
for all packets sent to a session.
C=0 indicates the 32-bit CCI field format is to be used.
C=1 indicates the 64-bit CCI field format is to be used.
C=2 indicates the 96-bit CCI field format is to be used.
C=3 indicates the 128-bit CCI field format is to be used.
In the example C=0 indicates that a 32-bit format is to be used.
Reserved (r): 2 bits
Reserved for future use. A sender MUST set these bits to zero and
a receiver MUST ignore these bits.
As required, these bits are set to 0 in the example.
Transport Session Identifier flag (S): 1 bit
This is the number of full 32-bit words in the TSI field. The TSI
field is 32*S + 16*H bits in length. For ALC the length of the
TSI field is REQUIRED to be non-zero. This implies that the
setting S=0 and H=0 MUST NOT be used.
In the example S=1 and H=0, and thus the TSI is 32-bits in length.
Transport Object Identifier flag (O): 2 bits
This is the number of full 32-bit words in the TOI field. The TOI
field is 32*O + 16*H bits in length. If more than one object is
to be delivered in the session then the TOI MUST be used, in which
case the setting O=0 and H=0 MUST NOT be used.
In the example O=1 and H=0, and thus the TOI is 32-bits in length.
Half-word flag (H): 1 bit
The TSI and the TOI fields are both multiples of 32-bits plus 16*H
bits in length. This allows the TSI and TOI field lengths to be
multiples of a half-word (16 bits), while ensuring that the
aggregate length of the TSI and TOI fields is a multiple of 32-
bits.
In the example H=0 which indicates that both TSI and TOI are both
multiples of 32-bits in length.
Sender Current Time present flag (T): 1 bit
T = 0 indicates that the Sender Current Time (SCT) field is not
present.
T = 1 indicates that the SCT field is present. The SCT is
inserted by senders to indicate to receivers how long the session
has been in progress.
In the example T=1, which indicates that the SCT is carried in
this packet.
Expected Residual Time present flag (R): 1 bit
R = 0 indicates that the Expected Residual Time (ERT) field is not
present.
R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how much
longer packets will be sent to the session for either the single
object carried in the session or for the object identified by the
TOI if there are multiple objects carried in the session. Senders
MUST NOT set R = 1 when the ERT for the object is more than 2^32-1
time units (approximately 49 days), where time is measured in
units of milliseconds.
In the example R=0, which indicates that the ERT is not carried in
this packet.
Close Session flag (A): 1 bit
Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet transmitted
for the session, or A MAY be set to 1 in the last few seconds of
packets transmitted for the session. Once the sender sets A to 1
in one packet, the sender SHOULD set A to 1 in all subsequent
packets until termination of transmission of packets for the
session. A received packet with A set to 1 indicates to a
receiver that the sender will immediately stop sending packets for
the session. When a receiver receives a packet with A set to 1
the receiver SHOULD assume that no more packets will be sent to
the session.
In the example A=0, and thus this packet does not indicate the
close of the session.
Close Object flag (B): 1 bit
Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is imminent.
If the TOI field is in use and B is set to 1 then termination of
transmission for the object identified by the TOI field is
imminent. If the TOI field is not in use and B is set to 1 then
termination of transmission for the one object in the session
identified by out-of-band information is imminent. B MAY be set
to 1 in just the last packet transmitted for the object, or B MAY
be set to 1 in the last few seconds packets transmitted for the
object. Once the sender sets B to 1 in one packet for a
particular object, the sender SHOULD set B to 1 in all subsequent
packets for the object until termination of transmission of
packets for the object. A received packet with B set to 1
indicates to a receiver that the sender will immediately stop
sending packets for the object. When a receiver receives a packet
with B set to 1 then it SHOULD assume that no more packets will be
sent for the object to the session.
In the example B=0, and thus this packet does not indicate the end
of sending data packets for the object.
LCT header length (HDR_LEN): 8 bits
Total length of the LCT header in units of 32-bit words. The
length of the LCT header MUST be a multiple of 32-bits. This
field can be used to directly access the portion of the packet
beyond the LCT header, i.e., the FEC Payload ID if the packet
contains a payload, or the end of the packet if the packet
contains no payload.
In the example HDR_LEN=5 to indicate that the length of the LCT
header portion of the overall ALC is 5 32-bit words.
Codepoint (CP): 8 bits
This field is used by ALC to carry the mapping that identifies
settings for portions of the Session Description that can change
within the session. The mapping between Codepoint values and the
settings for portions of the Session Description is to be
communicated out-of-band.
In the example the portion of the Session Description that can
change within the session is the FEC Encoding ID, and the identity
mapping is used between Codepoint values and FEC Encoding IDs.
Thus, CP=128 identifies FEC Encoding ID 128, the "Small Block,
Large Block and Expandable FEC Codes" as described in the FEC
building block [RFC3452]. The FEC Payload ID associated with FEC
Encoding ID 128 is 64-bits in length.
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
This is field contains the Congestion Control Information as
defined by the specified multiple rate congestion control building
block. The format of this field is determined by the multiple
rate congestion control building block.
This field MUST be 32 bits if C=0.
This field MUST be 64 bits if C=1.
This field MUST be 96 bits if C=2.
This field MUST be 128 bits if C=3.
In the example, the CCI is 32-bits in length. The format of the
CCI field for the example MUST correspond to the format for the
32-bit version of the CCI specified in the multiple rate
congestion control building block.
Transport Session Identifier (TSI): 16, 32 or 48 bits
The TSI uniquely identifies a session among all sessions from a
particular sender. The TSI is scoped by the sender IP address,
and thus the (sender IP address, TSI) pair uniquely identify the
session. For ALC, the TSI MUST be included in the LCT header.
The TSI MUST be unique among all sessions served by the sender
during the period when the session is active, and for a large
period of time preceding and following when the session is active.
A primary purpose of the TSI is to prevent receivers from
inadvertently accepting packets from a sender that belong to
sessions other than sessions receivers are subscribed to. For
example, suppose a session is deactivated and then another session
is activated by a sender and the two sessions use an overlapping
set of channels. A receiver that connects and remains connected
to the first session during this sender activity could possibly
accept packets from the second session as belonging to the first
session if the TSI for the two sessions were identical. The
mapping of TSI field values to sessions is outside the scope of
this document and is to be done out-of-band.
The length of the TSI field is 32*S + 16*H bits. Note that the
aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
In the example the TSI is 32 bits in length.
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112
bits.
This field indicates which object within the session this packet
pertains to. For example, a sender might send a number of files
in the same session, using TOI=0 for the first file, TOI=1 for the
second one, etc. As another example, the TOI may be a unique
global identifier of the object that is being transmitted from
several senders concurrently, and the TOI value may be the output
of a hash function applied to the object. The mapping of TOI
field values to objects is outside the scope of this document and
is to be done out-of-band. The TOI field MUST be used in all
packets if more than one object is to be transmitted in a session,
i.e., the TOI field is either present in all the packets of a
session or is never present.
The length of the TOI field is 32*O + 16*H bits. Note that the
aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
In the example the TOI is 32 bits in length.
Sender Current Time (SCT): 0 or 32 bits
This field represents the current clock of the sender at the time
this packet was transmitted, measured in units of 1ms and computed
modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if T=1.
In this example the SCT is present.
Expected Residual Time (ERT): 0 or 32 bits
This field represents the sender expected residual transmission
time of packets for either the single object carried in the
session or for the object identified by the TOI if there are
multiple objects carried in the session.
This field MUST NOT be present if R=0 and MUST be present if R=1.
In this example the ERT is not present.
FEC Payload ID: X bits
The length and format of the FEC Payload ID depends on the FEC
Encoding ID as described in the FEC building block [RFC3452]. The
FEC Payload ID format is determined by the FEC Encoding ID that
MUST be communicated in the Session Description. The Session
Description MAY specify that more than one FEC Encoding ID is used
in the session, in which case the Session Description MUST contain
a mapping that identifies which Codepoint values correspond to
which FEC Encoding IDs. This mapping, if used, is outside the
scope of this document.
The example packet format corresponds to the format for "Small
Block, Large Block and Expandable FEC Codes" as described in the
FEC building block, for which the associated FEC Encoding ID 128.
For FEC Encoding ID 128, the FEC Payload ID consists of the
following two fields that in total are X = 64 bits in length:
Source Block Number (SBN): 32 bits
The Source Block Number identifies from which source block of
the object the encoding symbol(s) in the payload are generated.
These blocks are numbered consecutively from 0 to N-1, where N
is the number of source blocks in the object.
Encoding Symbol ID (ESI): 32 bits
The Encoding Symbol ID identifies which specific encoding
symbol(s) generated from the source block are carried in the
packet payload. The exact details of the correspondence
between Encoding Symbol IDs and the encoding symbol(s) in the
packet payload are dependent on the particular encoding
algorithm used as identified by the FEC Encoding ID and by the
FEC Instance ID.
Encoding Symbol(s): Y bits
The encoding symbols are what the receiver uses to reconstruct an
object. The total length Y of the encoding symbol(s) in the
packet can be determined by the receiver of the packet by
computing the total length of the received packet and subtracting
off the length of the headers.
4.3 Header-Extension Fields
Header Extensions can be used to extend the LCT header portion of the
ALC header to accommodate optional header fields that are not always
used or have variable size. Header Extensions are not used in the
example ALC packet format shown in the previous subsection. Examples
of the use of Header Extensions include:
o Extended-size versions of already existing header fields.
o Sender and Receiver authentication information.
The presence of Header Extensions can be inferred by the LCT header
length (HDR_LEN): if HDR_LEN is larger than the length of the
standard header then the remaining header space is taken by Header
Extension fields.
If present, Header Extensions MUST be processed to ensure that they
are recognized before performing any congestion control procedure or
otherwise accepting a packet. The default action for unrecognized
Header Extensions is to ignore them. This allows the future
introduction of backward-compatible enhancements to ALC without
changing the ALC version number. Non backward-compatible Header
Extensions CANNOT be introduced without changing the ALC version
number.
There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 127. The second format is
used for fixed length (one 32-bit word) extensions, using HET values
from 127 to 255.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of additional headers
The explanation of each sub-field is the following.
Header Extension Type (HET): 8 bits
The type of the Header Extension. This document defines a number
of possible types. Additional types may be defined in future
versions of this specification. HET values from 0 to 127 are used
for variable-length Header Extensions. HET values from 128 to 255
are used for fixed-length 32-bit Header Extensions.
Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT be
present for fixed-length extensions (HET between 128 and 255).
Header Extension Content (HEC): variable length
The content of the Header Extension. The format of this sub-
field depends on the Header Extension type. For fixed-length
Header Extensions, the HEC is 24 bits. For variable-length Header
Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field
MUST be a multiple of 32 bits. Also note that the total size of
the LCT header, including all Header Extensions and all optional
header fields, cannot exceed 255 32-bit words.
Header Extensions are further divided between general LCT extensions
and Protocol Instantiation specific extensions (PI-specific).
General LCT extensions have HET in the ranges 0:63 and 128:191
inclusive. PI-specific extensions have HET in the ranges 64:127 and
192:255 inclusive.
General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT
version number. Non backward-compatible Header Extensions CANNOT be
introduced without changing the LCT version number.
PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the PI.
The following general LCT Header Extension types are defined:
EXT_NOP=0 No-Operation extension. The information present in
this extension field MUST be ignored by receivers.
EXT_AUTH=1 Packet authentication extension Information used to
authenticate the sender of the packet. The format of
this Header Extension and its processing is outside the
scope of this document and is to be communicated out-
of-band as part of the Session Description.
It is RECOMMENDED that senders provide some form of 4.2. LCT Header-Extension Fields
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it.
Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be
postponed by any such full packet authentication.
All senders and receivers implementing ALC MUST support the EXT_NOP All senders and receivers implementing ALC MUST support the EXT_NOP
Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
parse its content. parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions
are defined in [I-D.ietf-rmt-bb-lct-revised]
For this version of ALC, the following PI-specific extension is This specification defines a new LCT Header Extension, "EXT_FTI", for
defined: the purpose of communicating the FEC Object Transmission Information
in association with data packets of an object. The LCT Header
Extension Type for EXT_FTI is 64.
EXT_FTI=64 FEC Object Transmission Information extension The The Header Extension Content (HEC) field of the EXT_FTI LCT Header
purpose of this extension is to carry in-band the FEC Extension contains the encoded FEC Object Transmission Information as
Object Transmission Information for an object. The defined in [I-D.ietf-rmt-fec-bb-revised]. The format of the encoded
format of this Header Extension and its processing is FEC Object Transmission Information is dependent on the FEC Scheme in
outside the scope of this document and is to be use and so is outside the scope of this document.
communicated out-of-band as part of the Session
Description.
4.4 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
[RFC3451], the FEC building block [RFC3452] and the multiple rate [I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt-
congestion control building block. fec-bb-revised] and the multiple rate congestion control building
block.
A sender using ALC MUST make available the required Session A sender using ALC MUST make available the required Session
Description as described in Section 2.4. A sender also MUST make Description as described in Section 2.4. A sender also MUST make
available the required FEC Object Transmission Information as available the required FEC Object Transmission Information as
described in Section 2.3. described in Section 2.3.
Within a session a sender transmits a sequence of packets to the Within a session a sender transmits a sequence of packets to the
channels associated with the session. The ALC sender MUST obey the channels associated with the session. The ALC sender MUST obey the
rules for filling in the CCI field in the packet headers and MUST rules for filling in the CCI field in the packet headers and MUST
send packets at the appropriate rates to the channels associated with send packets at the appropriate rates to the channels associated with
skipping to change at page 29, line 21 skipping to change at page 16, line 35
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 and 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.
Objects MAY be transmitted sequentially within a session, and they
MAY be transmitted concurrently. However, it is good practice to
only send objects concurrently in the same session if the receivers
that participate in that portion of the session have interest in
receiving all the objects. The reason for this is that it wastes
bandwidth and networking resources to have receivers receive data for
objects that they have no interest in. However, there are no rules
with respect to mixing packets for different objects carried within
the session. Although this issue affects the efficiency of the
protocol, it does not affect the correctness nor the inter-
operability of ALC between senders and receivers.
Typically, the sender(s) continues to send packets in a session until
the transmission is considered complete. The transmission may be
considered complete when some time has expired, a certain number of
packets have been sent, or some out-of-band signal (possibly from a
higher level protocol) has indicated completion by a sufficient
number of receivers.
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.3 MUST be used to carry the authentication. Section 4.2 MUST be used to carry the authentication.
This document does not pose any restriction on packet sizes.
However, network efficiency considerations recommend that the sender
uses as large as possible packet payload size, but in such a way that
packets do not exceed the network's maximum transmission unit size
(MTU), or fragmentation coupled with packet loss might introduce
severe inefficiency in the transmission. It is RECOMMENDED that all
packets have the same or very similar sizes, as this can have a
severe impact on the effectiveness of the multiple rate congestion
control building block.
4.5 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
[RFC3451], the FEC building block [RFC3452] and the multiple rate [I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt-
congestion control building block. fec-bb-revised] and the multiple rate congestion control building
block.
To be able to participate in a session, a receiver MUST obtain the To be able to participate in a session, a receiver MUST obtain the
REQUIRED Session Description as listed in Section 2.4. How receivers REQUIRED Session Description as listed in Section 2.4. How receivers
obtain a Session Description is outside the scope of this document. obtain a Session Description is outside the scope of this document.
To be able to be a receiver in a session, the receiver MUST be able To be able to be a receiver in a session, the receiver MUST be able
to process the ALC header. The receiver MUST be able to discard, to process the ALC header. The receiver MUST be able to discard,
forward, store or process the other headers and the packet payload. forward, store or process the other headers and the packet payload.
If a receiver is not able to process the ALC header, it MUST drop If a receiver is not able to process the ALC header, it MUST drop
from the session. from the session.
To be able to participate in a session, a receiver MUST implement the
multiple rate congestion control building block using the Congestion
Control Information field provided in the LCT header. If a receiver
is not able to implement the multiple rate congestion control
building block it MUST NOT join the session.
Several objects can be carried either sequentially or concurrently
within the same session. In this case, each object is identified by
a unique TOI. Note that even if a sender stops sending packets for
an old object before starting to transmit packets for a new object,
both the network and the underlying protocol layers can cause some
reordering of packets, especially when sent over different channels,
and thus receivers SHOULD NOT assume that the reception of a packet
for a new object means that there are no more packets in transit for
the previous one, at least for some amount of time.
As described in Section 2.3, a receiver MUST obtain the required FEC As described in Section 2.3, a receiver MUST obtain the required FEC
Object Transmission Information for each object for which the Object Transmission Information for each object for which the
receiver receives and processes packets. receiver receives and processes packets.
A receiver MAY concurrently join multiple ALC sessions from one or
more senders. The receiver MUST perform congestion control on each
such session. The receiver MAY make choices to optimize the packet
flow performance across multiple sessions, as long as the receiver
still adheres to the multiple rate congestion control building block
for each session individually.
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. If multiple packets are discarded without further processing. If multiple packets are
received that cannot be parsed then the receiver SHOULD leave the received that cannot be parsed then the receiver SHOULD leave the
session. session.
2. The receiver MUST verify that the sender IP address together with 2. The receiver MUST verify that the sender IP address together with
skipping to change at page 33, line 23 skipping to change at page 21, line 5
seconds after it is received, and thus an attack against the seconds after it is received, and thus an attack against the
congestion control protocol can be effective for several seconds congestion control protocol can be effective for several seconds
before the receiver can react to slow down the session reception before the receiver can react to slow down the session reception
rate. rate.
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.
A receiver with an incorrect or corrupted implementation of the
multiple rate congestion control building block may affect health of
the network in the path between the sender and the receiver, and may
also affect the reception rates of other receivers joined to the
session. It is therefore RECOMMENDED that receivers be required to
identify themselves as legitimate before they receive the Session
Description needed to join the session. How receivers identify
themselves as legitimate is outside the scope of this document.
Another vulnerability of ALC is the potential of receivers obtaining
an incorrect Session Description for the session. The consequences
of this could be that legitimate receivers with the wrong Session
Description are unable to correctly receive the session content, or
that receivers inadvertently try to receive at a much higher rate
than they are capable of, thereby disrupting traffic in portions of
the network. To avoid these problems, it is RECOMMENDED that
measures be taken to prevent receivers from accepting incorrect
Session Descriptions, e.g., by using source authentication to ensure
that receivers only accept legitimate Session Descriptions from
authorized senders. How this is done is outside the scope of this
document.
6. IANA Considerations 6. IANA Considerations
No information in this specification is directly subject to IANA This specification registers the following LCT Header Extensions
registration. However, building blocks components used by ALC may Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength:
introduce additional IANA considerations. In particular, the FEC
building block used by ALC does require IANA registration of the FEC +-------+---------+--------------------+
codecs used. | Value | Name | Reference |
+-------+---------+--------------------+
| 64 | EXT_FTI | This specification |
+-------+---------+--------------------+
7. Acknowledgments 7. Acknowledgments
Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their
detailed comments on this document. detailed comments on this document.
8. Change Log 8. Change Log
8.1 RFC3450 to draft-ietf-rmt-pi-alc-revised-00 8.1. RFC3450 to draft-ietf-rmt-pi-alc-revised-00
Update all references to the obsoleted RFC 2068 to RFC 2616 Update all references to the obsoleted RFC 2068 to RFC 2616
Removed the 'Statement of Intent' from the introduction Removed the 'Statement of Intent' from the introduction
The statement of intent was meant to clarify the "Experimental" The statement of intent was meant to clarify the "Experimental"
status of RFC3450. It does not apply to this draft that is status of RFC3450. It does not apply to this draft that is
intended for "Standard Track" submission. intended for "Standard Track" submission.
Removed the 'Intellectual Property Issues' Section and replaced with Removed the 'Intellectual Property Issues' Section and replaced with
a standart IPR Statement a standard IPR Statement
8.2. draft-ietf-rmt-pi-alc-revised-01
Remove material duplicated in LCT
Update references for LCT and FEC Building Block to new versions.
Split normative and informative references
9. References 9. References
[HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 9.1. Normative references
Dissertation, Stanford University, Department of Computer
Science, Stanford, CA , August 2001.
[PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, [I-D.ietf-rmt-bb-lct-revised]
"Efficient and Secure Source Authentication for Luby, M., "Layered Coding Transport (LCT) Building Block",
Multicast", Network and Distributed System Security draft-ietf-rmt-bb-lct-revised-00 (work in progress),
Symposium, NDSS 2001, pp. 35-46 , February 2001. July 2005.
[I-D.ietf-rmt-fec-bb-revised]
Watson, M., "Forward Error Correction (FEC) Building
Block", draft-ietf-rmt-fec-bb-revised-01 (work in
progress), September 2005.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
skipping to change at page 37, line 12 skipping to change at page 24, line 48
[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.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[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.
9.2. Informative references
[HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, CA , August 2001.
[PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar,
"Efficient and Secure Source Authentication for
Multicast", Network and Distributed System Security
Symposium, NDSS 2001, pp. 35-46 , February 2001.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001. RFC 3048, January 2001.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002. Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
M., and J. Crowcroft, "Layered Coding Transport (LCT)
Building Block", RFC 3451, December 2002.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "Forward Error Correction (FEC)
Building Block", RFC 3452, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002. (FEC) in Reliable Multicast", RFC 3453, December 2002.
Authors' Addresses Authors' Addresses
Michael Luby Michael Luby
Digital Fountain Digital Fountain
39141 Civic Center Dr. 39141 Civic Center Dr.
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
US US
Email: luby@digitalfountain.com Email: luby@digitalfountain.com
Mark Watson
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA 94538
US
Email: mark@digitalfountain.com
Jim Gemmell Jim Gemmell
Microsoft Research Microsoft Research
455 Market St. #1690 455 Market St. #1690
San Francisco, CA 94105 San Francisco, CA 94105
US US
Email: jgemmell@microsoft.com Email: jgemmell@microsoft.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 57 change blocks. 
850 lines changed or deleted 262 lines changed or added

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