draft-ietf-rmt-pi-alc-revised-04.txt   draft-ietf-rmt-pi-alc-revised-05.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Watson Working Group Watson
Internet-Draft Vicisano Internet-Draft Vicisano
Obsoletes: 3450 (if approved) Digital Fountain Obsoletes: 3450 (if approved) Digital Fountain
Intended status: Standards Track February 22, 2007 Intended status: Standards Track November 16, 2007
Expires: August 26, 2007 Expires: May 19, 2008
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-04 draft-ietf-rmt-pi-alc-revised-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2007. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the Asynchronous Layered Coding (ALC) This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol. protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport Asynchronous Layered Coding combines the Layered Coding Transport
skipping to change at page 5, line 16 skipping to change at page 5, line 16
potentially limit its scalability. By doing so, ALC provides a potentially limit its scalability. By doing so, ALC provides a
minimal protocol that is massively scalable. Applications may be minimal protocol that is massively scalable. Applications may be
built on top of ALC to provide additional features that may limit the built on top of ALC to provide additional features that may limit the
scalability of the application. Such applications are outside the scalability of the application. Such applications are outside the
scope of this document. scope of this document.
1.3. Environmental Requirements and Considerations 1.3. Environmental Requirements and Considerations
All of the environmental requirements and considerations that apply All of the environmental requirements and considerations that apply
to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC
building block [I-D.ietf-rmt-fec-bb-revised], the multiple rate building block [RFC5052], the multiple rate congestion control
congestion control building block and to any additional building building block and to any additional building blocks that ALC uses
blocks that ALC uses also apply to ALC. also apply to ALC.
One issues that is specific to ALC with respect to the Any- Source One issues that is specific to ALC with respect to the Any- Source
Multicast (ASM) model of IP multicast as defined in RFC 1112 Multicast (ASM) model of IP multicast as defined in RFC 1112
[RFC1112] is the way the multiple rate congestion control building [RFC1112] is the way the multiple rate congestion control building
block interacts with ASM. The congestion control building block may block interacts with ASM. The congestion control building block may
use the measured difference in time between when a join to a channel 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 is sent and when the first packet from the channel arrives in
determining the receiver reception rate. The congestion control determining the receiver reception rate. The congestion control
building block may also uses packet sequence numbers per channel to building block may also uses packet sequence numbers per channel to
measure losses, and this is also used to determine the receiver measure losses, and this is also used to determine the receiver
skipping to change at page 6, line 13 skipping to change at page 6, line 13
congestion control building block. congestion control building block.
2. Architecture Definition 2. Architecture Definition
ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to
provide in-band session management functionality. ALC uses a provide in-band session management functionality. ALC uses a
multiple rate congestion control building block that is compliant multiple rate congestion control building block that is compliant
with [RFC2357] to provide congestion control that is feedback free. with [RFC2357] to provide congestion control that is feedback free.
Receivers adjust their reception rates individually by joining and Receivers adjust their reception rates individually by joining and
leaving channels associated with the session. ALC uses the FEC leaving channels associated with the session. ALC uses the FEC
building block [I-D.ietf-rmt-fec-bb-revised] to provide reliability. building block [RFC5052] to provide reliability. The sender
The sender generates encoding symbols based on the object to be generates encoding symbols based on the object to be delivered using
delivered using FEC codes and sends them in packets to channels FEC codes and sends them in packets to channels associated with the
associated with the session. Receivers simply wait for enough session. Receivers simply wait for enough packets to arrive in order
packets to arrive in order to reliably reconstruct the object. Thus, to reliably reconstruct the object. Thus, there is no request for
there is no request for retransmission of individual packets from retransmission of individual packets from receivers that miss packets
receivers that miss packets in order to assure reliable reception of in order to assure reliable reception of an object, and the packets
an object, and the packets and their rate of transmission out of the and their rate of transmission out of the sender can be independent
sender can be independent of the number and the individual reception of the number and the individual reception experiences of the
experiences of the receivers. receivers.
The definition of a session for ALC is the same as it is for LCT. An The definition of a session for ALC is the same as it is for LCT. An
ALC session comprises multiple channels originating at a single ALC session comprises multiple channels originating at a single
sender that are used for some period of time to carry packets sender that are used for some period of time to carry packets
pertaining to the transmission of one or more objects that can be of pertaining to the transmission of one or more objects that can be of
interest to receivers. Congestion control is performed over the interest to receivers. Congestion control is performed over the
aggregate of packets sent to channels belonging to a session. The aggregate of packets sent to channels belonging to a session. The
fact that an ALC session is restricted to a single sender does not fact that an ALC session is restricted to a single sender does not
preclude the possibility of receiving packets for the same objects preclude the possibility of receiving packets for the same objects
from multiple senders. However, each sender would be sending packets from multiple senders. However, each sender would be sending packets
skipping to change at page 7, line 4 skipping to change at page 7, line 4
[RFC0768] that supports IP multicast delivery of packets. Future [RFC0768] that supports IP multicast delivery of packets. Future
versions of this specification, or companion documents may extend ALC versions of this specification, or companion documents may extend ALC
to use the IP network layer service directly. ALC could be used as to use the IP network layer service directly. ALC could be used as
the basis for designing a protocol that uses a different underlying the basis for designing a protocol that uses a different underlying
network service such as unicast UDP, but the design of such a network service such as unicast UDP, but the design of such a
protocol is outside the 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 of the default LCT header that is described in
[I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is
described in [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control described in [RFC5052]. The Congestion Control Information field
Information field within the LCT header carries the required within the LCT header carries the required Congestion Control
Congestion Control Information that is described in the multiple rate Information that is described in the multiple rate congestion control
congestion control building block specified that is compliant with building block specified that is compliant with [RFC2357]. The
[RFC2357]. The packet payload that follows the ALC packet header packet payload that follows the ALC packet header consists of
consists of encoding symbols that are identified by the FEC Payload encoding symbols that are identified by the FEC Payload ID as
ID as described in [I-D.ietf-rmt-fec-bb-revised]. described in [RFC5052].
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
[I-D.ietf-rmt-fec-bb-revised] required for each object to be received [RFC5052] required for each object to be received by a receiver can
by a receiver can be communicated to a receiver either out-of-band or be communicated to a receiver either out-of-band or in-band using a
in-band using a Header Extension. The means for communicating the Header Extension. The means for communicating the Session
Session Description and the FEC Object Transmission Information to a Description and the FEC Object Transmission Information to a receiver
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.
skipping to change at page 7, line 46 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 Information as specified in the FEC building block [RFC5052] could
[I-D.ietf-rmt-fec-bb-revised] could vary for each object carried in vary for each object carried in the session, and the Codepoint value
the session, and the Codepoint value could be used to communicate the could be used to communicate the FEC Encoding ID to be used for each
FEC Encoding ID to be used for each object. The mapping between FEC object. The mapping between FEC Encoding IDs and Codepoints could
Encoding IDs and Codepoints could be, for example, the identity be, for example, the identity mapping.
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
skipping to change at page 9, line 40 skipping to change at page 9, line 40
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 [I-D.ietf-rmt-fec-bb-revised] provides The FEC building block [RFC5052] provides reliable object delivery
reliable object delivery within an ALC session. Each object sent in within an ALC session. Each object sent in the session is
the session is independently encoded using FEC codes as described in independently encoded using FEC codes as described in [RFC3453],
[RFC3453], which provide a more in-depth description of the use of which provide a more in-depth description of the use of FEC codes in
FEC codes in reliable content delivery protocols. All packets in an reliable content delivery protocols. All packets in an ALC session
ALC session MUST contain an FEC Payload ID in a format that is MUST contain an FEC Payload ID in a format that is compliant with the
compliant with the FEC Scheme in use. The FEC Payload ID uniquely FEC Scheme in use. The FEC Payload ID uniquely identifies the
identifies the encoding symbols that constitute the payload of each encoding symbols that constitute the payload of each packet, and the
packet, and the receiver MUST use the FEC Payload ID to determine how receiver MUST use the FEC Payload ID to determine how the encoding
the encoding symbols carried in the payload of the packet were symbols carried in the payload of the packet were generated from the
generated from the object as described in the FEC building block. object as described in the FEC building block.
As described in [I-D.ietf-rmt-fec-bb-revised], a receiver is REQUIRED As described in [RFC5052], a receiver is REQUIRED to obtain the FEC
to obtain the FEC Object Transmission Information for each object for Object Transmission Information for each object for which data
which data packets are received from the session. In the context of packets are received from the session. In the context of ALC, the
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
skipping to change at page 14, line 9 skipping to change at page 14, line 9
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 [I-D.ietf-rmt-bb-lct-revised], the FEC building block building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block
[I-D.ietf-rmt-fec-bb-revised] and with a multiple rate congestion [RFC5052] and with a multiple rate congestion control building block
control building block completely specifies a working reliable completely specifies a working reliable multicast transport protocol
multicast transport protocol that conforms to the requirements that conforms to the requirements described in [RFC2357].
described in [RFC2357].
4. Functionality Definition 4. Functionality Definition
This section describes the format and functionality of the data This section describes the format and functionality of the data
packets carried in an ALC session as well as the sender and receiver packets carried in an ALC session as well as the sender and receiver
operations for a session. operations for a session.
4.1. Packet format used by ALC 4.1. Packet format used by ALC
The packet format used by ALC is the UDP header followed by the LCT The packet format used by ALC is the UDP header followed by the LCT
header followed by the FEC Payload ID followed by the packet payload. header followed by the FEC Payload ID followed by the packet payload.
The LCT header is defined in the LCT building block The LCT header is defined in the LCT building block
[I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in
the FEC building block [I-D.ietf-rmt-fec-bb-revised]. The Congestion the FEC building block [RFC5052]. The Congestion Control Information
Control Information field in the LCT header contains the REQUIRED field in the LCT header contains the REQUIRED Congestion Control
Congestion Control Information that is described in the multiple rate Information that is described in the multiple rate congestion control
congestion control building block used. The packet payload contains building block used. The packet payload contains encoding symbols
encoding symbols generated from an object. If more than one object generated from an object. If more than one object is carried in the
is carried in the session then the Transmission Object ID (TOI) session then the Transmission Object ID (TOI) within the LCT header
within the LCT header MUST be used to identify which object the MUST be used to identify which object the encoding symbols are
encoding symbols are generated from. Within the scope of an object, generated from. Within the scope of an object, encoding symbols
encoding symbols carried in the payload of the packet are identified carried in the payload of the packet are identified by the FEC
by the FEC Payload ID as described in the FEC building block. Payload ID as described in the FEC building block.
The version number of ALC specified in this document is 1. The The version number of ALC specified in this document is 1. The
version number field of the LCT header MUST be interpreted as the ALC version number field of the LCT header MUST be interpreted as the ALC
version number field. This version of ALC implicitly makes use of version number field. This version of ALC implicitly makes use of
version 1 of the LCT building block defined in version 1 of the LCT building block defined in
[I-D.ietf-rmt-bb-lct-revised]. [I-D.ietf-rmt-bb-lct-revised].
The overall ALC packet format is depicted in Figure 2. The packet is The overall ALC packet format is depicted in Figure 2. The packet is
an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP
header. The ALC packet format has no dependencies on the IP version header. The ALC packet format has no dependencies on the IP version
skipping to change at page 16, line 50 skipping to change at page 16, line 50
parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions
are defined in [I-D.ietf-rmt-bb-lct-revised] are defined in [I-D.ietf-rmt-bb-lct-revised]
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 [I-D.ietf-rmt-fec-bb-revised]. The format of the encoded defined in [RFC5052]. The format of the encoded FEC Object
FEC Object Transmission Information is dependent on the FEC Scheme in Transmission Information is dependent on the FEC Scheme in use and so
use and so is outside the scope of this document. is outside the scope of this document.
4.3. Sender Operation 4.3. Sender Operation
The sender operation when using ALC includes all the points made The sender operation when using ALC includes all the points made
about the sender operation when using the LCT building block about the sender operation when using the LCT building block
[I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and
[I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion the multiple rate congestion control building block.
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 17, line 43 skipping to change at page 17, line 42
in the payload of the packet. in the payload of the packet.
It is RECOMMENDED that packet authentication be used. If packet It is RECOMMENDED that packet authentication be used. If packet
authentication is used then the Header Extensions described in authentication is used then the Header Extensions described in
Section 4.2 MUST be used to carry the authentication. Section 4.2 MUST be used to carry the authentication.
4.4. Receiver Operation 4.4. Receiver Operation
The receiver operation when using ALC includes all the points made The receiver operation when using ALC includes all the points made
about the receiver operation when using the LCT building block about the receiver operation when using the LCT building block
[I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and
[I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion the multiple rate congestion control building block.
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.
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.
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.
skipping to change at page 25, line 11 skipping to change at page 25, line 11
o Definition and IANA registration of the EXT_FTI LCT Header o Definition and IANA registration of the EXT_FTI LCT Header
Extension Extension
9. References 9. References
9.1. Normative references 9.1. Normative references
[I-D.ietf-rmt-bb-lct-revised] [I-D.ietf-rmt-bb-lct-revised]
Luby, M., "Layered Coding Transport (LCT) Building Block", Luby, M., "Layered Coding Transport (LCT) Building Block",
draft-ietf-rmt-bb-lct-revised-04 (work in progress), draft-ietf-rmt-bb-lct-revised-05 (work in progress),
June 2006. February 2007.
[I-D.ietf-rmt-fec-bb-revised]
Watson, M., "Forward Error Correction (FEC) Building
Block", draft-ietf-rmt-fec-bb-revised-04 (work in
progress), September 2006.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[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.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998. Application Protocols", RFC 2357, June 1998.
[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 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 9.2. Informative references
Dissertation, Stanford University, Department of Computer
Science, Stanford, CA , August 2001.
[PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar,
"Efficient and Secure Source Authentication for "Efficient and Secure Source Authentication for
Multicast", Network and Distributed System Security Multicast", Network and Distributed System Security
Symposium, NDSS 2001, pp. 35-46 , February 2001. 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.
 End of changes. 20 change blocks. 
87 lines changed or deleted 75 lines changed or added

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