draft-ietf-rmt-pi-alc-revised-03.txt   draft-ietf-rmt-pi-alc-revised-04.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Watson Working Group Watson
Internet-Draft Digital Fountain Internet-Draft Vicisano
Expires: October 20, 2006 Vicisano Obsoletes: 3450 (if approved) Digital Fountain
Cisco Systems, Inc. Intended status: Standards Track February 22, 2007
April 18, 2006 Expires: August 26, 2007
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-03 draft-ietf-rmt-pi-alc-revised-04
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 October 20, 2006. This Internet-Draft will expire on August 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
(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. This document obsoletes RFC3450.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5 1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6
2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple rate congestion control building block . . . . . 9 2.2. Multiple rate congestion control building block . . . . . 9
skipping to change at page 3, line 52 skipping to change at page 3, line 52
application that uses ALC may require that receivers report application that uses ALC may require that receivers report
statistics on their reception experience back to the sender, but the statistics on their reception experience back to the sender, but the
mechanisms by which receivers report back statistics is outside the mechanisms by which receivers report back statistics is outside the
scope of ALC. In general, ALC is designed to be a minimal protocol scope of ALC. In general, ALC is designed to be a minimal protocol
instantiation that provides reliable content delivery without instantiation that provides reliable content delivery without
unnecessary limitations to the scalability of the basic protocol. unnecessary limitations to the scalability of the basic protocol.
This document is a product of the IETF RMT WG and follows the general This document is a product of the IETF RMT WG and follows the general
guidelines provided in [RFC3269]. guidelines provided in [RFC3269].
RFC3450 [RFC3450] contained a previous versions of the protocol RFC3450 [RFC3450], which is obsoleted by this document, contained a
defined in this specification. RFC3450 was published in the previous versions of the protocol. RFC3450 was published in the
"Experimental" category. It was the stated intent of the RMT working "Experimental" category. It was the stated intent of the RMT working
group to re-submit these specifications as an IETF Proposed Standard group to re-submit these specifications as an IETF Proposed Standard
in due course. in due course.
This Proposed Standard specification is thus based on and backwards This Proposed Standard specification is thus based on and backwards
compatible with the protocol defined in RFC3450 [RFC3450] updated compatible with the protocol defined in RFC3450 [RFC3450] updated
according to accumulated experience and growing protocol maturity according to accumulated experience and growing protocol maturity
since its original publication. Said experience applies both to this since its original publication. Said experience applies both to this
specification itself and to congestion control strategies related to specification itself and to congestion control strategies related to
the use of this specification. the use of this specification.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
designed to be used with the IP multicast network service. This designed to be used with the IP multicast network service. This
specification defines ALC as payload of the UDP transport protocol specification defines ALC as payload of the UDP transport protocol
[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 [I-D.ietf-rmt-bb-lct- of the default LCT header that is described in
revised] followed by the FEC Payload ID that is described in [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is
[I-D.ietf-rmt-fec-bb-revised]. The Congestion Control Information described in [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control
field within the LCT header carries the required Congestion Control Information field within the LCT header carries the required
Information that is described in the multiple rate congestion control Congestion Control Information that is described in the multiple rate
building block specified that is compliant with [RFC2357]. The congestion control building block specified that is compliant with
packet payload that follows the ALC packet header consists of [RFC2357]. The packet payload that follows the ALC packet header
encoding symbols that are identified by the FEC Payload ID as consists of encoding symbols that are identified by the FEC Payload
described in [I-D.ietf-rmt-fec-bb-revised]. 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
[I-D.ietf-rmt-fec-bb-revised] required for each object to be received [I-D.ietf-rmt-fec-bb-revised] required for each object to be received
by a receiver can be communicated to a receiver either out-of-band or by a receiver can be communicated to a receiver either out-of-band or
in-band using a Header Extension. The means for communicating the in-band using a Header Extension. The means for communicating the
Session Description and the FEC Object Transmission Information to a Session Description and the FEC Object Transmission Information to a
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 [I-D.ietf-rmt-fec- Information as specified in the FEC building block
bb-revised] could vary for each object carried in the session, and [I-D.ietf-rmt-fec-bb-revised] could vary for each object carried in
the Codepoint value could be used to communicate the FEC Encoding ID the session, and the Codepoint value could be used to communicate the
to be used for each object. The mapping between FEC Encoding IDs and FEC Encoding ID to be used for each object. The mapping between FEC
Codepoints could be, for example, the identity mapping. Encoding IDs and 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 LCT header from version 1 of the LCT building block [I-D.ietf- The LCT header from version 1 of the LCT building block
rmt-bb-lct-revised] MUST be used. [I-D.ietf-rmt-bb-lct-revised] MUST be used.
The LCT Header includes a two-bit Protocol Specific Indication (PSI) The LCT Header includes a two-bit Protocol Specific Indication (PSI)
field in bits 6 and 7 of the first word of the LCT header. These two field in bits 6 and 7 of the first word of the LCT header. These two
bits are used by ALC as follows: bits are used by ALC as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+ +-+-+
...|A|B|... ...|A|B|...
+-+-+ +-+-+
skipping to change at page 15, line 15 skipping to change at page 15, line 15
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 [I-D.ietf-rmt-bb- The LCT header is defined in the LCT building block
lct-revised] and the FEC Payload ID is described in the FEC building [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in
block [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control the FEC building block [I-D.ietf-rmt-fec-bb-revised]. The Congestion
Information field in the LCT header contains the REQUIRED Congestion Control Information field in the LCT header contains the REQUIRED
Control Information that is described in the multiple rate congestion Congestion Control Information that is described in the multiple rate
control building block used. The packet payload contains encoding congestion control building block used. The packet payload contains
symbols generated from an object. If more than one object is carried encoding symbols generated from an object. If more than one object
in the session then the Transmission Object ID (TOI) within the LCT is carried in the session then the Transmission Object ID (TOI)
header MUST be used to identify which object the encoding symbols are within the LCT header MUST be used to identify which object the
generated from. Within the scope of an object, encoding symbols encoding symbols are generated from. Within the scope of an object,
carried in the payload of the packet are identified by the FEC encoding symbols carried in the payload of the packet are identified
Payload ID as described in the FEC building block. by the FEC 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 [I-D.ietf-rmt-bb-lct- version 1 of the LCT building block defined in
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
number. number.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header | | UDP header |
skipping to change at page 17, line 10 skipping to change at page 17, line 10
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 [I-D.ietf-rmt-fec-bb-revised]. The format of the encoded
FEC Object Transmission Information is dependent on the FEC Scheme in FEC Object Transmission Information is dependent on the FEC Scheme in
use and so is outside the scope of this document. use and so 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- [I-D.ietf-rmt-bb-lct-revised], the FEC building block
fec-bb-revised] and the multiple rate congestion control building [I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion
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 43
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- [I-D.ietf-rmt-bb-lct-revised], the FEC building block
fec-bb-revised] and the multiple rate congestion control building [I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion
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.
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-02 (work in progress), draft-ietf-rmt-bb-lct-revised-04 (work in progress),
March 2006. June 2006.
[I-D.ietf-rmt-fec-bb-revised] [I-D.ietf-rmt-fec-bb-revised]
Watson, M., "Forward Error Correction (FEC) Building Watson, M., "Forward Error Correction (FEC) Building
Block", draft-ietf-rmt-fec-bb-revised-03 (work in Block", draft-ietf-rmt-fec-bb-revised-04 (work in
progress), January 2006. 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 [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 27, line 26 skipping to change at page 27, line 26
Mark Watson Mark Watson
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: mark@digitalfountain.com Email: mark@digitalfountain.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems, Inc. Digital Fountain
510 McCarthy Blvd. 39141 Civic Center Dr.
Milpitas, CA 95035 Suite 300
Fremont, CA 94538
US US
Email: lorenzo@cisco.com Email: lorenzo@digitalfountain.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 29 skipping to change at page 28, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 20 change blocks. 
71 lines changed or deleted 73 lines changed or added

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