< draft-ash-avt-hc-over-mpls-protocol-00.txt		draft-ash-avt-hc-over-mpls-protocol-01.txt >
	Network Working Group Jerry Ash		Network Working Group Jerry Ash
	Internet Draft Bur Goode		Internet Draft Bur Goode
	<draft-ash-avt-hc-over-mpls-protocol-00.txt> AT&T		<draft-ash-avt-hc-over-mpls-protocol-01.txt> AT&T
	Expiration Date: October 2005 Jim Hand		Expiration Date: January 2006 Jim Hand
	Consultant		Consultant
			L-E. Jonsson
			Ericsson
	Andrew Malis		Andrew Malis
	Tellabs		Tellabs
	Raymond Zhang		Raymond Zhang
	Infonet		Infonet
	April, 2005		July, 2005
	Protocol Extensions for Header Compression over MPLS		Protocol Extensions for Header Compression over MPLS
	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 have		applicable patent or other IPR claims of which he or she is aware
	been or will be disclosed, and any of which he or she becomes aware will		have been or will be disclosed, and any of which he or she becomes
	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 Task		Internet-Drafts are working documents of the Internet Engineering
	Force (IETF), its areas, and its working groups. Note that other groups		Task Force (IETF), its areas, and its working groups. Note that
	may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 material		time. It is inappropriate to use Internet-Drafts as reference
	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/1id-abstracts.html.		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 November 26, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels		VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS
	are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN,		Labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an
	the packet header is at least 48 bytes, while the voice payload is often		MPLS VPN, the packet header is typically 48 bytes, while the voice
	no more than 30 bytes, for example. Header compression can significantly		payload is often no more than 30 bytes, for example. Header
	reduce the overhead through various compression mechanisms. MPLS is		compression can significantly reduce the overhead through various
	used to route header-compressed (HC) packets over an MPLS LSP without		compression mechanisms. MPLS is used to route header-compressed (HC)
	compression/decompression cycles at each router. Such an HC over MPLS		packets over an MPLS LSP without compression/decompression cycles at
	capability increases the bandwidth efficiency as well as processing		each router. Such an HC over MPLS capability increases the bandwidth
	scalability of the maximum number of simultaneous compressed flows that		efficiency as well as processing scalability of the maximum number of
	use HC at each router. MPLS pseudowires are used to transport the HC		simultaneous compressed flows that use HC at each router. MPLS
	context and other control messages between the ingress and egress MPLS		pseudowires are used to transport the HC context and other control
	label switched router (LSR), and the pseudowires define a point to point		messages between the ingress and egress MPLS label switched router
	instance of each HC session at the header decompressor. Standard HC		(LSR), and the pseudowires define a point to point instance of each
	methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context.		HC session at the header decompressor. Standard HC methods (e.g.,
			ECRTP, ROHC, etc.) are re-used to determine the context.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1 MPLS Pseudowire Establishment & Processing . . . . . . . . . . 6		3. Header Compression over MPLS Protocol Overview . . . . . . . . 6
	2.2 Link Layer Packet Type Field . . . . . . . . . . . . . . . . . 7		3.1 PW Setup & HC Session Configuration . . . . . . . . . . . 7
	3. HC over MPLS Procedures . . . . . . . . . . . . . . . . . . . . . . 8		3.2 HC over MPLS . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9		4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 9
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1 MPLS Pseudowire & Header Compression Scheme
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9		Setup/Negotiation/Signaling . . . . . . . . . . . . . . . 9
	7. Normative References . . . . . . . . . . . . . . . . . . . . . . . 9		4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12
	8. Informative References . . . . . . . . . . . . . . . . . . . . . . 9		4.2.1 FULL_HEADER Packet Format . . . . . . . . . . . . . 13
	9. Intellectual Property Considerations . . . . . . . . . . . . . . .10		4.2.2 CONTEXT_STATE Packet Format . . . . . . . . . . . . 13
	10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
			6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	Specification of Requirements		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
			8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		9. Informative References . . . . . . . . . . . . . . . . . . . . 15
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
	document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.		Voice over IP (VoIP) typically uses the encapsulation
	When MPLS labels [RFC3031] are added, this becomes		voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes
	voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [RFC2547], the		voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label
	packet header is at least 48 bytes, while the voice payload is often no		stacking, and in the simplest case of IPv4 the total packet header is
	more than 30 bytes, for example. The interest in header compression is		at least 48 bytes, while the voice payload is often no more than 30
	to exploit the possibility of significantly reducing the overhead		bytes, for example. When IPv6 is used, the relative size of the
	through various compression mechanisms, such as with enhanced compressed		header in comparison to the payload is even greater. The interest in
	RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095],		header compression is to exploit the possibility of significantly
	and also to increase scalability of header compression. MPLS is used to		reducing the overhead through various compression mechanisms, such as
	route header-compressed (HC) packets over an MPLS label switched path		with enhanced compressed RTP (ECRTP) [RFC3545] and robust header
	(LSP) without compression/decompression cycles at each router. Such an		compression (ROHC) [RFC3095], and also to increase scalability of
	HC over MPLS capability can increase bandwidth efficiency as well as the		header compression. MPLS is used to route header-compressed (HC)
	processing scalability of the maximum number of simultaneous compressed		packets over an MPLS label switched path (LSP) without
	flows that use header compression at each router.		compression/decompression cycles at each router. Such an HC over
			MPLS capability can increase bandwidth efficiency as well as the
			processing scalability of the maximum number of simultaneous
			compressed flows that use header compression at each router.
	To implement HC over MPLS, the ingress router would have to apply the HC		To implement HC over MPLS, after the ingress router applies the HC
	algorithm to the IP packet, the compressed packet routed on an MPLS LSP		algorithm to the IP packet, the compressed packet is forwarded on an
	using MPLS labels, and the compressed header would be decompressed at		MPLS LSP using MPLS labels, and then the egress router restores the
	the egress router where the HC session terminates. Figure 1 illustrates		uncompressed header. Figure 1 illustrates an HC over MPLS session
	an HC over MPLS session established on an LSP that crosses several		established on an LSP that traverses several label switch routers,
	routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress		from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router
	router where header compression (HC) is performed, and R4/HD is the		performing header compression (HC), and R4/HD is the egress router
	egress router where header decompression (HD) is done. Compression of		performing header decompression (HD). Compression of the RTP/UDP/IP
	the RTP/UDP/IP header is performed at R1/HC, and the compressed packets		header is performed at R1/HC, and the compressed packets are routed
	are routed using MPLS labels from R1/HC to R2, to R3, and finally to		using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD,
	R4/HD, without further decompression/recompression cycles. The		without further decompression/recompression cycles. The RTP/UDP/IP
	RTP/UDP/IP header is decompressed at R4/HD and can be forwarded to other		header is decompressed at R4/HD and can be forwarded to other
	routers, as needed.		routers, as needed.
	_____		_____
	| |		| |
	|R1/HC| Header Compression (HC) Performed		|R1/HC| Header Compression (HC) Performed
	|_____|		|_____|
	|		|
	| data (e.g. voice)/compressed-header/MPLS-labels		| data (e.g. voice)/compressed-header/MPLS-labels
	V		V
	_____		_____
	| |		| |
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	| R3 |		| R3 |
	|_____|		|_____|
	|		|
	| data (e.g. voice)/compressed-header/MPLS-labels		| data (e.g. voice)/compressed-header/MPLS-labels
	V		V
	_____		_____
	| |		| |
	|R4/HD| Header Decompression (HD) Performed		|R4/HD| Header Decompression (HD) Performed
	|_____|		|_____|
	Figure 1. Example of HC over MPLS over Routers R1 --> R4		Figure 1. Example of HC over MPLS over Routers R1 --> R4
	In the example scenario, header compression therefore takes place		In the example scenario, header compression therefore takes place
	between R1 and R4, and the MPLS path transports		between R1 and R4, and the MPLS path transports
	data/compressed-header/MPLS-labels instead of		data/compressed-header/MPLS-labels instead of
	data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS		data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS
	label stack and link-layer headers are not compressed. Therefore HC		label stack and link-layer headers are not compressed. Therefore HC
	over MPLS can significantly reduce the header overhead through		over MPLS can significantly reduce the header overhead through
	compression mechanisms.		compression mechanisms.
	Goals and requirements for header compression over MPLS are discussed in		MPLS is used to route HC packets over an MPLS LSP without
	[MPLS-HC-REQ]. The solution put forth in this document meets these		compression/decompression cycles at each intermediate router. MPLS
	requirements. In particular, the HC over MPLS solution:		pseudowires (PWs) are used to transport the header compressed packets
			between the ingress and egress MPLS label switched router (LSR), and
			the PWs define a point to point instance of each HC session at the
			header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
			are used to determine the context.
	a. uses existing protocols [e.g., ECRTP, ROHC] to compress RTP/UDP/IP		HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets.
	headers,		Half of the reduction in header size comes from the observation that
	b. allows HC over an MPLS LSP, and thereby avoids hop-by-hop		half of the bytes in the IP/UDP/RTP headers remain constant over the
	compression/decompression cycles,		life of the connection. After sending the uncompressed header
	c. minimizes incremental performance degradation due to increased delay,		template once, these fields may be removed from the compressed
	packet loss, and jitter, by leveraging a compression scheme [e.g.,		headers that follow. The remaining compression comes from the
	ECRTP] that is less sensitive to delay, packet loss, and jitter, as well		observation that although several fields change in every packet, the
	as by eliminating multiple compression/decompression cycles as a source		difference from packet to packet is often constant and therefore the
	of performance degradation, over a range of network path		second-order difference is zero.
	characteristics,
	d. uses standard protocols to signal context identification and control
	information,
	e. packet reordering does not cause incorrectly decompressed packets
	to be forwarded from the decompressor.
	Section 2 presents the proposed protocol extensions, and Section 3		By maintaining both the uncompressed header and the first-order
	presents the procedures.		differences in the session state shared between the compressor and
			decompressor, all that must be communicated is an indication that the
			second-order difference was zero. In that case, the decompressor can
			reconstruct the original header without any loss of information
			simply by adding the first-order differences to the saved
			uncompressed header as each compressed packet is received. The
			compressed packet carries the context identification (CID), to
			indicate in which session context that packet should be interpreted.
			Compressed data is routed on a separate MPLS LSP/PW from compressor
			to decompressor, where the PW is set up by MPLS PW signaling
			[PW-SIG]. The decompressor uses the incoming MPLS PW Label and the
			CID to locate the proper decompression context.
	2. Protocol Extensions		Goals and requirements for header compression over MPLS are discussed
			In [MPLS-HC-REQ]. The solution put forth in this document has been
			Designed to address these goals and requirements.
	MPLS is used to route HC packets over an MPLS LSP without		2. Terminology
	compression/decompression cycles at each intermediate router. MPLS
	pseudowires (PWs) are used to transport the HC context and other control
	messages between the ingress and egress MPLS label switched router
	(LSR), and the PWs define a point to point instance of each HC session
	at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC,
	etc.) are used to determine the context.
	HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. Half		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	of the reduction in header size comes from the observation that half of		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	the bytes in the IP/UDP/RTP headers remain constant over the life of		document are to be interpreted as described in [RFC2119].
	the connection. After sending the uncompressed header template once,
	these fields may be removed from the compressed headers that follow.
	The remaining compression comes from the observation that although
	several fields change in every packet, the difference from packet to
	packet is often constant and therefore the second-order difference is
	zero.
	By maintaining both the uncompressed header and the first-order		Forwarding Equivalence Class (FEC): a group of IP packets which are
	differences in the session state shared between the compressor and		forwarded in the same manner (e.g., over the same LSP, with the same
	decompressor, all that must be communicated is an indication that the		forwarding treatment)
	second-order difference was zero. In that case, the decompressor can
	reconstruct the original header without any loss of information simply
	by adding the first-order differences to the saved uncompressed header
	as each compressed packet is received. The compressed packet carries the
	context identification (CID), to indicate in which session context that
	packet should be interpreted. Compressed packets and HC control packets
	are routed on a separate MPLS LSP/PW, where the PW is set up by MPLS PW
	signaling [PW-SIG]. The decompressor uses the incoming MPLS PW label
	and the CID to locate the proper decompression context.
	In Figure 1 we assume an example data flow set up from R1/HC --> R2 -->		Label: a short fixed length physically contiguous identifier which is
	R3 --> R4/HD, where R1/HC is the ingress router where header compression		used to identify a FEC, usually of local significance
	is performed, and R4/HD is the egress router where header decompression
	is done. Each router functions as an LSR and supports signaling of
	LSP/PWs. A summary of the flow setup is as follows (ECRTP is assumed in
	this example):
	1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows R1 -->		Label Switched Path (LSP): the path through one or more LSRs at one
	R2 --> R3 --> R4.		level of the hierarchy followed by a packets in a particular
			forwarding equivalence class (FEC)
	2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows R4 -->		Label Switching Router (LSR): an MPLS node which is capable of
	R3 --> R2 --> R1.		forwarding native L3 packets label stack an ordered set of labels
	3. [RFC3544] and [RFC3409] are used to negotiate HC scheme parameters,
	which is extended in this specification to negotiating over an MPLS
	LSP/PW (as specified in Section 3).
	4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to send
	FULL_HEADER packets, compressed packets, and CONTEXT_STATE packets to
	R4/HC, with LSP and PW labels.
	5. R4/HD uses the incoming MPLS PW label and CID to locate the proper
	decompression context to decompress the compressed packets sent by
	R1/HC.
	6. R4/HC uses the CID assigned by R1/HC and the R4 --> R1 LSP/PW to send
	FULL_HEADER packets, compressed packets, and CONTEXT_STATE packets to
	R1/HD, with LSP and PW labels.
	7. if needed to resync, R4/HD sends a CONTEXT_STATE packet to R1/HC;
	R1/HC resends the FULL_HEADER packet to R4/HD.
	8. if needed to resync, R1/HD sends a CONTEXT_STATE packet to R4/HC;
	R4/HC resends the FULL_HEADER packet to R1/HD.
	9. R1/HC and R4/HD free up the CID when the flow terminates.
	2.1 MPLS Pseudowire Establishment & Processing		MPLS domain: a contiguous set of nodes which operate MPLS routing
			and forwarding and which are also in one Routing or Administrative
			Domain
	An MPLS pseudowire (PW) allows protocol data units for various		MPLS label: a label which is carried in a packet header, and which
	link-layer protocols to be encapsulated and carried over an MPLS		represents the packet's FEC
	network. The PW is set up by a PW signaling protocol [PW-SIG]. Figure
	2 illustrates header-compressed /RTP/UDP/IP carried over a PW through
	|<------- Pseudowire -------->|		MPLS node: a node that is running MPLS. An MPLS node will be aware
	| |		of MPLS control protocols, will operate one or more L3 routing
	| |<-- MPLS Tunnel -->| |		protocols, and will be capable of forwarding packets based on labels.
	V V V V
	+----+ +----+
	| HC |===================| HD |
	|............PW...............|
	| |===================| |
	+----+ +----+
	Figure 2: Pseudowire (PW) Reference Configuration		An MPLS node may optionally be also capable of forwarding native L3
			packets.
	an MPLS LSP tunnel. The 'PW label' is used as the demultiplexer field		MultiProtocol Label Switching (MPLS): an IETF working group and the
	by the HD, where the PW label appears at the bottom label of an MPLS		effort associated with the working group
	label stack. See [PW-SIG] for an explanation of PW signaling, and
	[PW-HDLC-PPP] for a PW type that can be modeled for the application in
	this document.
	In Figure 2, many simultaneous compressed flows (could be 100's or		Packet Switched Network (PSN): Within the context of PWE3, this is a
	1000's) need to be established between HC and HD. These multiple		network using IP or MPLS as the mechanism for packet forwarding.
	simultaneous compressed flows are carried on one HC-HD PW, and HD uses
	the CID to identify the compressed flow-context and the PW (inner) label
	to identify the HC source. That is, each HC-HD compressed session would
	be identified by the PW label. The CIDs are assigned by the HC as
	normal, and there would be no problem if duplicate CIDs are received at
	the HD for different compressed sessions. For example, if HC-a and HC-b
	assign the same CID to a flow, the HD can distinguish these since it
	knows the source by means of the PW label. That is, HD has a separate
	decompression context for the two flows based on the PW label and CID
	mapping.
	It is also possible for multiple PWs to be established in case different		Protocol Data Unit (PDU): The unit of data output to, or received
	QoS requirements are needed for different compressed streams. The QoS		from, the network by a protocol layer.
	received by the flow would be determined by the EXP bit marking in the
	PW label. Normally, all the RTP packets would get the same EXP marking,
	equivalent to EF treatment in DiffServ. However, the protocol specified
	in this document applies to other than RTP streams, and QoS treatment
	other than EF may be required for those streams.
	This document requires the allocation of a new PW type to support the PW		Pseudo Wire (PW): A mechanism that carries the essential elements of
	signaling defined in Section 5.1 of [PW-SIG]. The PW type is a 15-bit		an emulated service from one provider edge router to one or more
	parameter assigned by IANA, as specified in the [IANA] registry. The C		other provider edge routers over a PSN
	bit is set equal to 1 for this signaling.
	2.2 Link Layer Packet Type Field		Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates
			the essential attributes of service (such as a T1 leased line or
			Frame Relay) over a PSN
	Since it is necessary to identify packet types for HC over MPLS (e.g.,		Pseudo Wire PDU (PW-PDU): A PDU sent on the PW that contains all of
	HC control packets, compressed packets, etc.), a 4-bit packet type field		the data and control information necessary to emulate the desired
	is defined in the layer 2 header to encode the different packet types.		service
	Each HC over MPLS packet MUST have prepended to it a packet type field,
	which adds 1 octet to the layer-2 header, and is encoded as follows (see
	[RFC3544], [RFC3545], [RFC3095], [IPCP]):
	0 1 2 3 4 5 6 7 8		PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can
	+-+-+-+-+-+-+-+-+		be carried
	|0 0 0 0|Pkt Typ|
	+-+-+-+-+-+-+-+-+
	where:		PSN Tunnel Signaling: Used to set up, maintain, and tear down the
			underlying PSN tunnel
	CID_Packet_Type designation:		PW Demultiplexer: Data-plane method of identifying a PW terminating
	0000 (first nibble)		at a provider edge router
	"Packet Type" encoding:		Tunnel: A method of transparently carrying information over a network
	0: Reserved
	1: FULL_HEADER
	2: COMPRESSED_TCP
	3: COMPRESSED_TCP_NODELTA
	4: COMPRESSED_NON_TCP
	5: COMPRESSED_RTP_8
	6: COMPRESSED_RTP_16
	7: COMPRESSED_UDP_8
	8: COMPRESSED_UDP_16
	9: CONTEXT_STATE
	10: ROHC
	11: IPCP
	12-15: RESERVED
	As discussed in [ECMP-AVOID], since this MPLS payload type in not IP,		3. Header Compression over MPLS Protocol Overview
	the first nibble is set to 0000 to avoid being mistaken for IP. This
	is also consistent with the proposed encoding of the PWE3 control word
	[PWE3-CNTL-WORD].
	3. HC over MPLS Procedures		MPLS is used to route HC packets over an MPLS LSP without
			compression/decompression cycles at each intermediate router. MPLS
			pseudowires (PWs) are used to transport the header compressed packets
			between the ingress and egress MPLS label switched router (LSR), and
			the PWs define a point to point instance of each HC session at the
			header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
			are used to determine the context.
	The MPLS control plane establishes LSPs, PWs, and label bindings between		Traditionally, the use of HC over a particular link is a function of
	each HC-HD pair. Compressed packets and HC control packets are routed		the link-layer protocol, PPP, HDLC, FR, etc. Native procedures could
	on LSP/PWs, which are set up as described in Section 2.1.		be used to carry compressed packets over a PW. That is, the
			link-layer protocol could be emulated over the PW, which would then
			behave like a serial link running encapsulated link-layer PDUs across
			the MPLS network. The drawback of this approach is that the
			compressed packet needs to be carried in a layer-2 PDU, which
			requires extra overhead.
	[RFC3544] and [RFC3409] are used to negotiate HC scheme parameters.		Alternatively, compressed packets are directly encapsulated over a
	These RFCs are oriented toward negotiating over a single PPP link, which		PW, and are routed across the MPLS network using MPLS labels, which
	is extended in this specification to negotiating over an MPLS LSP/PW.		include the packet switched network (PSN) label and PW label. In
	[RFC3544] uses the IP control protocol (IPCP) [RFC1332] to		this approach, a PW control word is used to identify the type of
	signal/negotiate HC parameters. For HC over MPLS, objects MUST be sent		packet, a unique PW Type is defined for each HC scheme, and, as
	between the HC and HD over the MPLS LSP/PW, in which the IPCP packets		normal, a context identification (CID) is used to identify each
	are identified, as specified in Section 2.2. For example, to enable		compressed packet context and payload. Each HC scheme is applied
	ECRTP [RFC3545], sub-option 2 is negotiated, this object MUST be sent		directly over its own PW type, and the principles of HC-over-PPP
	between the HC and HD over the MPLS LSP/PW:		[RFC3241, RFC3544] are re-used. This more efficient approach is
			taken in this document, and is now summarized.
	0 1		An MPLS PW allows protocol data units for various link-layer
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		protocols to be encapsulated and carried over an MPLS network. The
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		PW is set up by a PW signaling protocol [PW-SIG], and the Interface
	| Type=2 | Length=2 |		Parameters Sub-TLV [IANA, PW-SIG] is used to convey HC configuration
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		information including HC session setup and HC parameter negotiation.
			Mechanisms and principles for HC session setup and HC parameter
			negotiation, as described for HC-over-PPP mechanisms [RFC3241,
			RFC3544], are reused to enable HC session configuration.
	For HC over MPLS, the compressor and decompressor follow the procedures		MPLS PWs directly encapsulate compressed packets and HC control
	in the HC protocol, as specified in [RFC2507] for IP header compression		packets, etc., for each HC scheme as identified by the PW type.
	(IPHC), [RFC2508] for compressed RTP (CRTP), [RFC3545] for ECRTP, and		Mechanisms and principles described in each HC scheme: cTCP
	[RFC3095] for ROHC. The HC source node compresses the header by		[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
	removing the header and forming the compressed header, which is		[RFC3545], are then directly reused to enable compressed packet
	prepended to the remainder of the packet. The CID and the MPLS header		transport.
	are then prepended and the packet is sent. The HD destination node
	removes the MPLS PW label and the compressed header. The node prepends
	the header template to the packet and then uses the operands to populate
	the variable fields of the header with the values sent in the compressed
	header. The compressor and decompressor follow the procedures in the
	applicable RFC, including the sending of control packets, compressed
	packets, etc.
	Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER]		3.1 PW Setup & HC Session Configuration
	and [ECRTP-REORDER], which are a useful source of information. An
	evaluation and simulation of ECRTP and ROHC reordering is given in
	[REORDER-EVAL].
	4. Security Considerations		From the signaling procedures from [PW-SIG], a PW is established
			between the header compressor (HC) and header decompressor (HD) for
			the transport of the media stream between the HC and HD endpoints.
			Figure 2 illustrates header-compressed packets carried over a PW
			through an MPLS LSP tunnel. The 'PW label' is used as the
			demultiplexer field by the HD, where the PW label appears at the
			bottom of an MPLS label stack.
	MPLS pseudowire security considerations in general are discussed in		|<------- Pseudowire -------->|
	[RFC3985] and [PW-SIG], and those considerations also apply to this		| |
	document. This document specifies an encapsulation and not the		| |<-- MPLS Tunnel -->| |
	protocols that may be used to carry the encapsulated packets across the		V V V V
	PSN, or the protocols being encapsulated. Each such protocol may have		+----+ +----+
	its own set of security issues, but those issues are not affected by		| HC |===================| HD |
	the encapsulations specified herein.		|............PW...............|
			| |===================| |
			+----+ +----+
	5. Acknowledgements		Figure 2: Pseudowire (PW) Reference Configuration
	Thanks to Stewart Bryant, George Swallow, and Curtis Villamizar for		PWs are set up for the transport of media streams based on [PW-SIG]
	helpful suggestions.		control messages exchanged by the endpoints. PWs for media streams
			are established at the edges of the MPLS network. Furthermore, a PW
			type indicates the HC scheme being used on the PW, as specified in
			[IANA].
	6. IANA Considerations		The PW HC approach in this document relies on the PW/MPLS layer to
			convey HC session configuration information. As detailed in Section
			4.1, the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to
			signal HC session setup and HC parameter negotiation, such as
			described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
			principles and IPCP messages described in [RFC3241, RFC3544] are
			reused to enable PW/MPLS HC session configuration, as the PPP layer
			does for each of the HC mechanisms.
	As discussed in Section 2.1, a new PW types needs to be assigned for HC		3.2 HC over MPLS
	over MPLS LSP/PWs.
	7. Normative References		Since a PW in an MPLS network looks similar to a point-to-point link,
			the same HC approaches used on point-to-point links may be used in
			PW-MPLS networks, for example, when shipping IP/UDP/RTP traffic over
			MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP
			[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
			[RFC3545], to maintain contexts as per each HC scheme and route each
			stream over the appropriate PW. This section describes how to carry
			HC packets in a PW-MPLS network for real-time media streams.
	[MPLS-HC-REQ] Ash, G., Goode, B., Hand, J., "Requirements for Header		Figure 3 shows the HC over MPLS protocol stack. The uncompressed
	Compression over MPLS", work in progress.		stack would be:
	[IANA] Martini, L., et. al., "IANA Allocations for pseudo Wire Edge to		Media stream
	Edge Emulation (PWE3)," work in progress.		RTP
			UDP
			IP
			PW control octet
			MPLS label stack (at least 2 labels for this application)
			Link layer under MPLS (PPP, PoS, Ethernet)
			Physical layer (SONET/SDH, fiber, copper)
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		Then we do compression on the IP/UDP/RTP headers before transmission,
	Requirement Levels", RFC 2119, March 1997.		leaving the rest of the stack alone, as shown in Figure 3:
	8. Informative References		+--------------+
			| Media stream |
			+--------------+
			\_______ ______/
			2-4 octets V
			+------+--------------+
			Compressed /RTP/UDP/IP/ |header| |
			+------+--------------+
			\__________ __________/
			1 octet V
			+------+---------------------+
			PW Control Octet |header| |
			+------+---------------------+
			\______________ _____________/
			8 octets V
			+------+----------------------------+
			MPLS Labels |header| |
			+------+----------------------------+
			\_________________ _________________/
			V
			+------+-----------------------------------+
			Link Layer under MPLS |header| |
			+------+-----------------------------------+
			\____________________ _____________________/
			V
			+------+------------------------------------------+
			Physical Layer |header| |
			+------+------------------------------------------+
	[ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath		Figure 3 - Header Compression over MPLS Media Stream Transport
	Treatment in MPLS Networks," work in progress.
	[ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended CRTP		The PW control octet is used to identify the packet types for certain
	(ECRTP)," work in progress.		HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508],
			and ECRTP [RFC3545], as detailed in Section 4.2. Note that ROHC
			[RFC3095] provides its own packet type within the protocol, and does
			not require use of the PW control octet. We illustrate formats of
			the FULL_HEADER and CONTEXT_STATE packets in Section 4.2, Figures 6
			and 7, respectively. The formats of other HC-control packets are
			similarly encapsulated, and the PW control octet is set to the
			appropriate value indicating the packet format.
	[PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over an		4. Protocol Specifications
	MPLS PSN," work in progress.
	[PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport of		4.1 MPLS Pseudowire & Header Compression Scheme
	PPP/HDLC Over IP and MPLS Networks," work in progress.		Setup/Negotiation/Signaling
	[PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance using		From the signaling procedures from [PW-SIG], a PW is established
	LDP," work in progress.		between the header compressor (HC) and header decompressor (HD) for
			the transport of the media stream between the HC and HD endpoints.
	[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header		Figure 2 illustrates header-compressed packets carried over a PW
	Compression Algorithm ECRTP,"		through an MPLS LSP tunnel. The 'PW label' is used as the
	http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf		demultiplexer field by the HD, where the PW label appears at the
	[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol		bottom label of an MPLS label stack. See [PW-SIG] for an explanation
	(IPCP)," May 1992.		of PW signaling, and [PW-HDLC-PPP] for a PW type that can be modeled
			for the application in this document.
	[RFC1661] Simpson, W., et. al., "The Point-to-Point Protocol (PPP)," RFC		In Figure 2, many simultaneous compressed flows (could be 100's or
	1661, July 1994.		1000's) need to be established between HC and HD. These multiple
			simultaneous compressed flows are carried on one HC-HD PW, and HD
			uses the CID to identify the compressed flow-context and the PW
			(inner) label to identify the HC source. That is, each HC-HD
			compressed session would be identified by the PW label. The CIDs are
			assigned by the HC as normal, and there would be no problem if
			duplicate CIDs are received at the HD for different compressed
			sessions. For example, if HC-a and HC-b assign the same CID to a
			flow, each PW had a logically separate HD instance, in this case,
			HD-a and HD-b, independent of all other PWs. That is, HD-a and HD-b
			have a separate decompression context for the two flows based on the
			PW label and CID mapping.
	[RFC2021] Rosen, E., et. al., "Multiprotocol Label Switching		It is also possible for multiple PWs to be established in case
	Architecture," RFC 3031, January 2001.		Different QoS requirements are needed for different compressed
			streams. The QoS received by the flow would be determined by the EXP
			bit marking in the PW label. Normally, all the RTP packets would get
			the same EXP marking, equivalent to EF treatment in DiffServ.
			However, the protocol specified in this document applies to other
			than RTP streams, and QoS treatment other than EF may be required for
			those streams.
	[RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507,		PWs are set up for the transport of media streams based on [PW-SIG]
	February 1999.		control messages exchanged by the endpoints. PWs for media streams
			are established at the edges of the MPLS network. Furthermore, a PW
			type indicates the HC scheme being used on the PW [IANA], as follows:
	[RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for		0x001B cTCP [RFC1144] Transport Header-compressed Packets
	Low-Speed Serial Links", RFC 2508, February 1999.		0x001C IPHC [RFC2507] Transport Header-compressed Packets
			0x001D cRTP [RFC2508] Transport Header-compressed Packets
			0x001E ROHC [RFC3095] Transport Header-compressed Packets
			0x001F ECRTP [RFC3545] Transport Header-compressed Packets
	[RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March		In Figure 1 we assume an example data flow set up from R1/HC -->
	1999.		R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header
			Compression is performed, and R4/HD is the egress router where header
			Decompression is done. Each router functions as an LSR and supports
			signaling of LSP/PWs. A summary of the procedures is as follows:
	[RFC3032] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032,		1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows
	January 2001.		R1 --> R2 --> R3 --> R4.
			2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows
			R4 --> R3 --> R2 --> R1.
	[RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC):		3. [RFC3544] and [RFC3241] are used to negotiate HC scheme
	Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC 3095,		parameters, which is extended in this specification to negotiating
	July 2001.		during PW setup, as specified in Section 4.1.
			4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to
			send HC scheme control packets and compressed packets to R4/HC, with
			LSP and PW labels.
			5. R4/HD uses the incoming MPLS PW label and CID to locate the proper
			decompression context to decompress the compressed packets sent by
			R1/HC.
			6. R4/HC assigns a CID to the flow and uses the R4 --> R1 LSP/PW to
			send HC scheme control packets and compressed packets to R1/HD, with
			LSP and PW labels.
			7. R1/HD uses the incoming MPLS PW label and CID to locate the proper
			decompression context to decompress the compressed packets sent by
			R4/HC.
			8. if needed to resync, R4/HD sends an appropriate HC scheme control
			packet to R1/HC; R1/HC resends the appropriate HC scheme control
			packet to R4/HD.
			9. if needed to resync, R1/HD sends an appropriate HC scheme control
			packet to R4/HC; R4/HC resends the HC scheme control packet to R1/HD.
			10. Existing HC scheme procedures are used to assign and free up the
			CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE].
	[RFC3409] Svanbro, K., "Lower Layer Guidelines for Robust RTP/UDP/IP		The PW HC approach in this document relies on the PW/MPLS layer to
	Header Compression," December 2002.		convey HC session configuration information. The Interface
			Parameters Sub-TLV [IANA, PW-SIG], illustrated in Figure 4, is used
			to signal HC session setup and HC parameter negotiation, such as
			described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
			principles and IPCP messages described in [RFC3241, RFC3544] are
			reused to enable PW/MPLS HC session configuration, as the PPP layer
			does for each of the HC mechanisms. This sub-TLV specifies interface
			specific parameters, and is used to configure the HC and HD ports at
			the edges of the PW, have the necessary capabilities to interoperate
			with each other.
	[RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression		0 1 2 3
	over PPP", RFC 3544, July 2003.		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sub-TLV Type | Length | Variable Length Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Variable Length Value |
			| " |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	[RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links		Figure 4 - PW Interface Parameters Sub-TLV
	with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
	[RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge		The interface parameter sub-TLV type values are specified in [IANA].
	(PWE3) Architecture," RFC 3985, March 2005.		Type values are specified for both the network control protocol for
			IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. IPCP and
			IPV6CP TLVs may then be encapsulated in the PW Interface Parameters
			Sub-TLV and used to negotiate HC parameters for their respective
			protocols. The IPCP and IPV6CP TLVs supported in this manner include
			the following:
	[ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression		o Configuration Option Format, RTP-Compression Suboption, Enhanced
	(ROHC): ROHC over Channels that can Reorder Packets," work in progress.		RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as
			specified in [RFC3544]
			o Configuration Option Format, PROFILES Suboption, as specified in
			[RFC3241]
	9. Intellectual Property Considerations		4.2 Encapsulation of Header Compressed Packets
	The IETF takes no position regarding the validity or scope of any		Since a PW in an MPLS network looks similar to a point-to-point link,
	Intellectual Property Rights or other rights that might be claimed to		the same HC approaches used on point-to-point links may be used in
	pertain to the implementation or use of the technology described in this		PW-MPLS networks, for example, when transmitting IP/UDP/RTP traffic
	document or the extent to which any license under such rights might or		over MPLS PWs. Existing HC algorithms are re-used, as specified in
	might not be available; nor does it represent that it has made any		cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and
	independent effort to identify any such rights. Information on the		ECRTP [RFC3545], to maintain contexts as per each HC scheme and route
	procedures with respect to rights in RFC documents can be found in BCP		each stream over the appropriate PW. This section describes how to
	78 and BCP 79.		carry HC packets in a PW-MPLS network for real-time media streams.
	Copies of IPR disclosures made to the IETF Secretariat and any		Figure 3 shows the HC over MPLS protocol stack. The PW control octet
	assurances of licenses to be made available, or the result of an		is used to identify the packet types for certain HC schemes,
	attempt made to obtain a general license or permission for the use of		including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP
	such proprietary rights by implementers or users of this specification		[RFC3545], as shown in Figure 5:
	can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		0 1 2 3 4 5 6 7 8
	copyrights, patents or patent applications, or other proprietary rights		+-+-+-+-+-+-+-+-+
	that may cover technology that may be required to implement this		|0 0 0 0|Pkt Typ|
	standard. Please address the information to the IETF at		+-+-+-+-+-+-+-+-+
	ietf-ipr@ietf.org.
			Figure 5 - PW Control Octet
			where:
			"Packet Type" encoding:
			0: Reserved
			1: FULL_HEADER
			2: COMPRESSED_TCP
			3: COMPRESSED_TCP_NODELTA
			4: COMPRESSED_NON_TCP
			5: COMPRESSED_RTP_8
			6: COMPRESSED_RTP_16
			7: COMPRESSED_UDP_8
			8: COMPRESSED_UDP_16
			9: CONTEXT_STATE
			10-15: MUST NOT BE ASSIGNED
			As discussed in [ECMP-AVOID], since this MPLS payload type is not IP,
			the first nibble is set to 0000 to avoid being mistaken for IP. This
			is also consistent with the proposed encoding of the PWE3 control
			word [PW-CNTL-WORD].
			Note that ROHC [RFC3095] provides its own packet type within the
			protocol, and does not require use of the PW control octet. We
			illustrate the exchange of packet formats for the case of [RFC2508],
			the other HC approaches are similar.
			FULL_HEADER - communicates a full IP/UDP/RTP header to establish or
			synchronize the state in the de-compressor for a call context.
			Similar to IP/UDP/RTP HC over PPP links [RFC2508], HC over MPLS PWs
			requires a CID. Namely, the HC/HDs on both ends need to maintain
			context for many IP flows traversing the same link and the CIDs are
			used to determine the context in which a packet has to be considered.
			CONTEXT_STATE - is a special packet sent from the HD to the HC
			indicating that the context associated with the flow may have been
			invalidated. The compressor is expected to send the next packet as a
			FULL_HEADER packet.
			We now illustrate the formats of the FULL_HEADER and CONTEXT_STATE
			packets.
			4.2.1 FULL_HEADER Packet Format
			The format of a FULL_HEADER packet is illustrated in Figure 6, where
			the PW control octet is set to '00000001' indicating a FULL_HEADER
			packet format.
			PW Control Octet
			\_____ ________/
			V
			+----------+--------------------+--------------+
			| 00000001 | /RTP/UDP/IP Header | Data |
			+----------+--------------------+--------------+
			\______________________ _______________________/
			V
			+----------------+----------------------------------------------+
			| MPLS/PW Labels | MPLS-PDU |
			+----------------+----------------------------------------------+
			Figure 6 - FULL_HEADER Packet
			4.2.2 CONTEXT_STATE Packet Format
			The format of a CONTEXT_STATE packet is illustrated in Figure 7,
			where the PW control octet is set to '00001001' indicating a
			CONTEXT_STATE packet format.
			PW Control Octet
			\_____ ________/
			V
			+----------+--------------------+--------------+
			| 00001001 | /RTP/UDP/IP Header | Data |
			+----------+--------------------+--------------+
			\______________________ _______________________/
			V
			+----------------+----------------------------------------------+
			| MPLS/PW Labels | MPLS-PDU |
			+----------------+----------------------------------------------+
			Figure 7 - CONTEXT_STATE Packet
			The formats of other HC-control packets are similarly encapsulated,
			and the PW control octet is set to the appropriate value indicating
			the packet format.
			Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER]
			and [ECRTP-REORDER], which are a useful source of information. An
			evaluation and simulation of ECRTP and ROHC reordering is given in
			[REORDER-EVAL].
			5. Security Considerations
			MPLS pseudowire security considerations in general are discussed in
			[RFC3985] and [PW-SIG], and those considerations also apply to this
			document. This document specifies an encapsulation and not the
			protocols that may be used to carry the encapsulated packets across
			the PSN, or the protocols being encapsulated. Each such protocol may
			have its own set of security issues, but those issues are not
			affected by the encapsulations specified herein.
			6. Acknowledgements
			The authors appreciate valuable inputs and suggestions from Loa
			Andersson, Stewart Bryant, Adrian Farrel, Victoria Fineberg, Colin
			Perkins, George Swallow, Curtis Villamizar, and Magnus Westerlund.
			7. IANA Considerations
			As discussed in Section 4.1, new PW type values are assigned in
			[IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1,
			interface parameter sub-TLV type values are specified in [IANA] for
			both the network control protocol for IPv4, IPCP [RFC1332] and the
			IPv6 NCP, IPV6CP [RFC2472].
			8. Normative References
			[IANA] Martini, L., et. al., "IANA Allocations for Pseudo Wire Edge
			To Edge Emulation (PWE3)," work in progress.
			[MPLS-HC-REQS] Ash, G., Goode, B., Hand, J., "Requirements for Header
			Compression over MPLS", work in progress.
			[PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport
			of PPP/HDLC Over IP and MPLS Networks," work in progress.
			[PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance
			Using LDP," work in progress.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, March 1997.
			[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP,"
			RFC 3241, April 2002.
			[RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression
			over PPP", RFC 3544, July 2003.
			9. Informative References
			[ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath
			Treatment in MPLS Networks," work in progress.
			[ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended
			CRTP (ECRTP)," work in progress.
			[PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over
			an MPLS PSN," work in progress.
			[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header
			Compression Algorithm ECRTP,"
			http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf.
			[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
			(IPCP)," May 1992.
			[RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507,
			February 1999.
			[RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers
			for Low-Speed Serial Links", RFC 2508, February 1999.
			[RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
			1999.
			[RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC):
			Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC
			3095, July 2001.
			[RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on
			Links with High Delay, Packet Loss, and Reordering," RFC 3545, July
			2003.
			[RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge
			(PWE3) Architecture," RFC 3985, March 2005.
			[ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "ROHC Implementer's
			Guide," work in progress.
			[ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression
			(ROHC): ROHC over Channels that can Reorder Packets," work in
			progress.
	10. Authors' Addresses		10. Authors' Addresses
	Jerry Ash		Jerry Ash
	AT&T		AT&T
	Room MT D5-2A01		Room MT D5-2A01
	200 Laurel Avenue		200 Laurel Avenue
	Middletown, NJ 07748, USA		Middletown, NJ 07748, USA
	Phone: +1 732-420-4578		Phone: +1 732-420-4578
	Email: gash@att.com		Email: gash@att.com
	Bur Goode		Bur Goode
	AT&T		AT&T
	Phone: +1 203-341-8705		Phone: +1 203-341-8705
	Email: bgoode@att.com		Email: bgoode@att.com
	Jim Hand		Jim Hand
	Consultant		Consultant
	Phone : +1 732-532-3020		Phone : +1 732-532-3020
	Email: James.Hand@mail1.monmouth.army.mil		Email: James.Hand@mail1.monmouth.army.mil
	Andrew G. Malis		Lars-Erik Jonsson
	Tellabs		Ericsson AB
	90 Rio Robles Dr.		Box 920
	San Jose, CA 95134		SE-971 28 Lulea, Sweden
	Email: Andy.Malis@tellabs.com		Phone: +46 8 404 29 61
			EMail: lars-erik.jonsson@ericsson.com
	Raymond Zhang		Andrew G. Malis
	Infonet Services Corporation		Tellabs
	2160 E. Grand Ave. El Segundo, CA 90025 USA		90 Rio Robles Dr.
	Email: zhangr@sa.infonet.com		San Jose, CA 95134
			Email: Andy.Malis@tellabs.com
	Full Copyright Statement		Raymond Zhang
			Infonet Services Corporation
			2160 E. Grand Ave. El Segundo, CA 90025 USA
			Email: zhangr@bt.infonet.com
	Copyright (C) The Internet Society (2005). This document is subject to		Intellectual Property Statement
	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		The IETF takes no position regarding the validity or scope of any
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR		Intellectual Property Rights or other rights that might be claimed to
	IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		pertain to the implementation or use of the technology described in
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		this document or the extent to which any license under such rights
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		might or might not be available; nor does it represent that it has
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		made any independent effort to identify any such rights. Information
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2005). 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.
End of changes. 88 change blocks.
	388 lines changed or deleted		659 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/