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/