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/