< draft-ash-avt-ecrtp-over-mpls-reqs-00.txt		draft-ash-avt-ecrtp-over-mpls-reqs-01.txt >
	Network Working Group Jerry Ash		Network Working Group Jerry Ash
	Internet Draft Bur Goode		Internet Draft Bur Goode
	<draft-ash-avt-ecrtp-over-mpls-reqs-00.txt> Jim Hand		<draft-ash-avt-ecrtp-over-mpls-reqs-01.txt> Jim Hand
	Expiration Date: July 2004 AT&T		Expiration Date: July 2004 AT&T
	Raymond Zhang		Raymond Zhang
	Infonet Services Corporation		Infonet Services Corporation
	January, 2004		January, 2004
	Requirements for ECRTP over MPLS		Requirements for ECRTP over MPLS
	<draft-ash-avt-ecrtp-over-mpls-reqs-00.txt>		<draft-ash-avt-ecrtp-over-mpls-reqs-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at line 42 ¶		skipping to change at line 42 ¶
	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.
	ABSTRACT:		ABSTRACT:
	VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS		VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS
	labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an		labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an
	MPLS VPN, the packet header is at least 48 bytes, while the voice		MPLS VPN, the packet header is at least 48 bytes, while the voice
	payload is often no more than 30 bytes, for example. VoIP header		payload is often no more than 30 bytes, for example. VoIP header
	compression can significantly reduce the VoIP overhead through various		compression can significantly reduce the VoIP overhead through various
	compression mechanisms, such as enhanced compressed RTP (ECRTP). This		compression mechanisms, such as enhanced compressed RTP (ECRTP). We
	is important on access links where bandwidth is scarce, and can be		consider using MPLS to route ECRTP compressed packets over an MPLS LSP
	important on backbone facilities, especially where costs are high (e.g.,		without compression/decompression cycles at each router. Such an ECRTP
	some global cross-sections). We consider using MPLS to route ECRTP		over MPLS capability can increase the bandwidth efficiency as well as
	compressed packets over multiple router hops without
	compression/decompression cycles at each router. Such an ECRTP over
	MPLS capability can increase the bandwidth efficiency as well as
	processing scalability of the maximum number of simultaneous VoIP flows		processing scalability of the maximum number of simultaneous VoIP flows
	which use header compression at each router. This draft gives a problem		that use header compression at each router.
	statement, goals, requirements, and an example scenario for ECRTP over
	MPLS.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Problem Statement		2. Problem Statement
	3. Goals & Requirements		3. Goals & Requirements
	4. Example Scenario		4. Example Scenario
	5. Security Considerations		5. Security Considerations
	6. References		6. IANA Considerations
	7. Authors' Addresses		7. References
	8. Full Copyright Statement		8. Intellectual Property Statement
			9. Authors' Addresses
			10. Full Copyright Statement
			Specification of Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC 2119].
	1. Introduction		1. Introduction
	Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.		Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.
	When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.		When MPLS labels [MPLS-ARCH] are added, this becomes
	For an MPLS VPN (e.g., [MPLS-VPN], the packet header is at least 48		voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [MPLS-VPN], the
	bytes, while the voice payload is often no more than 30 bytes, for		packet header is at least 48 bytes, while the voice payload is often no
	example. The interest in VoIP header compression is to exploit the		more than 30 bytes, for example. The interest in VoIP header
	possibility of significantly reducing the VoIP overhead through various		compression is to exploit the possibility of significantly reducing the
	compression mechanisms, such as with enhanced compressed RTP [ECRTP],		VoIP overhead through various compression mechanisms, such as with
	and also to increase scalability of VoIP header compression. We consider		enhanced compressed RTP [ECRTP], and also to increase scalability of
	using MPLS to route ECRTP compressed packets over multiple router hops		VoIP header compression. We consider using MPLS to route ECRTP
	without compression/decompression cycles at each router. Such an ECRTP		compressed packets over an MPLS LSP (label switched path) without
	over MPLS capability can increase bandwidth efficiency as well as the		compression/decompression cycles at each router. Such an ECRTP over
			MPLS capability can increase bandwidth efficiency as well as the
	processing scalability of the maximum number of simultaneous VoIP flows		processing scalability of the maximum number of simultaneous VoIP flows
	which use header compression at each router.		which use header compression at each router.
	To implement ECRTP over MPLS, the ingress router/gateway would have to		To implement ECRTP over MPLS, the ingress router/gateway would have to
	apply the ECRTP algorithm to the IP packet, the compressed packet routed		apply the ECRTP algorithm to the IP packet, the compressed packet routed
	over multiple hops on an MPLS label switched path (LSP) using MPLS		on an MPLS LSP using MPLS labels, and the compressed header would be
	labels, and the compressed header would be decompressed at the egress		decompressed at the egress router/gateway where the ECRTP session
	router/gateway where the ECRTP session terminates. Figure 1 illustrates		terminates. Figure 1 illustrates an ECRTP over MPLS session established
	an ECRTP over MPLS session established on an LSP that crosses several		on an LSP that crosses several routers, from R1/HC --> R2 --> R3 -->
	routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress		R4/HD, where R1/HC is the ingress router where header compression (HC)
	router where header compression (HC) is performed, and R4/HD is the		is performed, and R4/HD is the egress router where header decompression
	egress router where header decompression (HD) is done. ECRTP		(HD) is done. ECRTP compression of the RTP/UDP/IP header is performed
	compression of the RTP/UDP/IP header is performed at R1/HC, and the		at R1/HC, and the compressed packets are routed using MPLS labels from
	compressed packets are routed using MPLS labels from R1/HC to R2, to R3,		R1/HC to R2, to R3, and finally to R4/HD, without further
	and finally to R4/HD, without further decompression/recompression		decompression/recompression cycles. The RTP/UDP/IP header is
	cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be		decompressed at R4/HD and can be forwarded to other routers, as needed.
	forwarded to other routers, as needed.
	_____		_____
	| |		| |
	|R1/HC| ECRTP Header Compression (HC) Performed		|R1/HC| ECRTP Header Compression (HC) Performed
	|_____|		|_____|
	|		|
	| voice/ECRTP/MPLS-labels		| voice/ECRTP/MPLS-labels
	V		V
	_____		_____
	| |		| |
	| R2 |		| R2 |
	skipping to change at line 129 ¶		skipping to change at line 132 ¶
	|_____|		|_____|
	Figure 1. Example of ECRTP over MPLS over Routers R1 --> R4		Figure 1. Example of ECRTP over MPLS over Routers R1 --> R4
	In the example scenario, ECRTP header compression therefore takes place		In the example scenario, ECRTP header compression therefore takes place
	between R1 and R4, and the MPLS path transports voice/ECRTP/MPLS-labels		between R1 and R4, and the MPLS path transports voice/ECRTP/MPLS-labels
	instead of voice/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.		instead of voice/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.
	The MPLS label stack and link-layer headers are not compressed. A method		The MPLS label stack and link-layer headers are not compressed. A method
	is needed to set up a correspondence between the header compression		is needed to set up a correspondence between the header compression
	tables at the ingress and egress routers of the ECRTP over MPLS session.		tables at the ingress and egress routers of the ECRTP over MPLS session.
	Therefore additional signaling is needed to map the context for the		Therefore additional signaling is needed to map the context for the
	compressed packets.		compressed packets.
	In Section 2 we give a problem statement, in Section 3 we give goals and		In Section 2 we give a problem statement, in Section 3 we give goals and
	requirements, and in Section 4 we give an example scenario.		requirements, and in Section 4 we give an example scenario.
	2. Problem Statement		2. Problem Statement
	As described in the introduction, ECRTP over MPLS can significantly		As described in the introduction, ECRTP over MPLS can significantly
	reduce the VoIP header overhead through compression mechanisms. The		reduce the VoIP header overhead through compression mechanisms. The
	need for compression may be important on access links where bandwidth is		need for compression may be important on low-speed links where bandwidth
	more scarce, but it could also be important on backbone facilities,		is more scarce, but it could also be important on backbone facilities,
	especially where costs are high (e.g., some global cross-sections).		especially where costs are high (e.g., some global cross-sections).
	VoIP typically will use voice compression mechanisms (e.g., G.729) on		VoIP typically will use voice compression mechanisms (e.g., G.729) on
	access and international routes, in order to conserve bandwidth. With		low-speed and international routes, in order to conserve bandwidth. With
	VoIP header compression, significantly more bandwidth could be saved.		VoIP header compression, significantly more bandwidth could be saved.
	For example, carrying VoIP headers for the entire voice load of a large		For example, carrying VoIP headers for the entire voice load of a large
	domestic network with 300 million or more calls per day could consume on		domestic network with 300 million or more calls per day could consume on
	the order of about 20-40 gigabits-per-second on the backbone network for		the order of about 20-40 gigabits-per-second on the backbone network for
	headers alone. This overhead could translate into considerable bandwidth		headers alone. This overhead could translate into considerable bandwidth
	capacity.		capacity.
	The claim is often made that once fiber is in place, increasing the		The claim is often made that once fiber is in place, increasing the
	bandwidth capacity is inexpensive, nearly 'free'. This may be true in		bandwidth capacity is inexpensive, nearly 'free'. This may be true in
	some cases, however, on some international cross-sections, especially,		some cases, however, on some international cross-sections, especially,
	facility/transport costs are very high and saving bandwidth on such		facility/transport costs are very high and saving bandwidth on such
	backbone links is very worthwhile. Decreasing the backbone bandwidth is		backbone links is very worthwhile. Decreasing the backbone bandwidth is
	needed in some areas of the world where bandwidth is very expensive. It		needed in some areas of the world where bandwidth is very expensive. It
	is also important in almost all locations to decrease the access		is also important in almost all locations to decrease the bandwidth
	bandwidth. While ECRTP over MPLS clearly helps decrease bandwidth		consumption on low-speed links. So although bandwidth is getting
	requirements, it also avoids compression-decompression cycles at every		cheaper, the value of compression does not go away. It should be
	router hop. So although bandwidth is getting cheaper, the value of		further noted that IPv6 will increase the size of headers, and therefore
	compression does not go away. In addition, IPv6 will increase the size		increase the importance of header compression for VoIP flows.
	of headers and therefore increase the importance of header compression
	for VoIP flows.
	In principle, we could use existing header compression techniques, such		While hop-by-hop header compression could be applied to decrease
	as those described in [ECRTP, cRTP], together with MPLS labels to make		bandwidth requirements, that implies a processing requirement for
			compression-decompression cycles at every router hop, which does not
			scale well for large voice traffic loads. The maximum number of cRTP
			flows is about 30-50 for a typical customer premise router, depending
			upon its uplink speed and processing power, while the need may exceed
			300-500 for a high-end case. Therefore, ECRTP over MPLS seems to be a
			viable alternative to get the compression benefits without introducing
			costly processing demands on the intermediate nodes. By using ECRTP
			over MPLS, routers merely forward compressed packets without doing a
			decompression/recompression cycle, thereby increasing the maximum number
			of simultaneous VoIP compressed flows that routers can handle.
			Therefore the proposal is to use existing header compression techniques,
			such as those described in [ECRTP], together with MPLS labels, to make
	the transport of the RTP/UDP/IP headers more efficient over an MPLS		the transport of the RTP/UDP/IP headers more efficient over an MPLS
	network. However, at this time, there are no standards for ECRTP over		network. However, at this time, there are no standards for ECRTP over
	MPLS, and vendors have not implemented such techniques.		MPLS, and vendors have not implemented such techniques.
	[cRTP] header compression is often used on access links to conserve
	bandwidth. However, cRTP header compression must be implemented on a
	hop-by-hop basis, and does not scale well for large voice traffic loads.
	The maximum number of cRTP flows is about 30-50 for a typical customer
	premise router, depending upon its uplink speed and processing power.
	However, the need, for example, can exceed 300-500 for a high-end case.
	By using ECRTP over MPLS, routers merely forward compressed packets
	without doing a decompression/recompression cycle, thereby increasing
	the maximum number of simultaneous VoIP compressed flows that routers
	can handle.
	3. Goals & Requirements		3. Goals & Requirements
	The goals of ECRTP over MPLS are as follows:		The goals of ECRTP over MPLS are as follows:
	a. provide more efficient voice transport,		a. provide more efficient voice transport over MPLS networks,
	b. increase the scalability of VoIP header compression to a large number		b. increase the scalability of VoIP header compression to a large number
	of flows, and		of flows, and
	c. not significantly degrade packet delay, delay variation, or loss		c. not significantly increase packet delay, delay variation, or loss
	probability.		probability.
	Therefore the requirements for ECRTP over MPLS are that it:		Therefore the requirements for ECRTP over MPLS are that it must:
	a. MUST allow ECRTP over MPLS, and thereby avoid hop-by-hop		a. Use existing protocols such as ECRTP and/or ROHC to compress
			RTP/UDP/IP headers, in order to provide for efficient voice transport,
			tolerance to packet loss, and resistance to loss of session context.
			b. Allow ECRTP over an MPLS LSP, and thereby avoid hop-by-hop
	compression/decompression cycles [e.g., VoMPLS].		compression/decompression cycles [e.g., VoMPLS].
	b. SHOULD use [ECRTP] to compress RTP/UDP/IP headers, in order to		c. Minimize incremental performance degradation due to increased delay,
	provide for efficient voice transport, tolerance to packet loss, and		packet loss, and jitter.
	resistance to loss of session context.		d. Use standard protocols to signal context identification and control
	c. MUST minimize incremental performance degradation due to increased		information (e.g., [RSVP], [RSVP-TE], [LDP]).
	delay, packet loss, and jitter.
	d. SHOULD allow use of standard protocols to signal context		[ECRTP] should be used to make ECRTP over MPLS more tolerant of packet
	identification and control information (e.g., [RSVP], [RSVP-TE], [LDP]).		loss, to guard against frequent resynchronizations, and to minimize the
			need for error recovery. [ROHC] can also be considered, however [ROHC]
			does not accommodate packet reordering to protect against
			out-of-sequence packets, which can occur on MPLS LSPs.
	Protocol extensions may be required for [ECRTP] in that a packet type		Protocol extensions may be required for [ECRTP] in that a packet type
	field is needed to identify FULL_HEADER, CONTEXT_STATE, and compressed		field is needed to identify FULL_HEADER, CONTEXT_STATE, and compressed
	packets. New objects need to be defined for [RSVP-TE]. It is also		packets. For example, [cRTP-ENCAP] specifies a separate link-layer
	desirable to signal ECRTP over MPLS tunnels with the label distribution		packet type defined for header compression. Using a separate link-layer
	protocol [LDP], since many RFC2547 VPN [MPLS-VPN] implementations use		packet type for every packet type used in header compression avoids the
	LDP as the underlying LSP signaling mechanism, and LDP is very scalable.		need to add extra bits to the compression header to identify the packet
	However, extensions to LDP may be needed to signal ECRTP over MPLS.		type. However, this practice does not extend well to MPLS encapsulation
	These protocol extensions need coordination with other working groups		conventions [MPLS-ENCAP], in which a separate link-layer packet type
	(e.g., MPLS).		translates into a separate LSP for each packet type. In order to extend
			ECRTP to ECRTP over MPLS, each packet type defined in [ECRTP] would need
			to be identified in an appended packet type field in the ECRTP header.
			Extensions to MPLS signaling are needed to signal the session context
			IDs (SCIDs) between the ingress and egress routers on the MPLS LSP. For
			example, new objects need to be defined for [RSVP-TE] to signal the
			SCIDs between the ingress and egress routers, and [ECRTP] used to
			determine the FULL_HEADER packets for the context identification; these
			FULL HEADER packets then contain the SCID identified by using the
			RSVP-TE objects. It is also desirable to signal ECRTP over MPLS tunnels
			with the label distribution protocol [LDP], since many RFC2547 VPN
			[MPLS-VPN] implementations use LDP as the underlying LSP signaling
			mechanism, and LDP is very scalable. However, extensions to LDP would
			be needed to signal SCIDs between ingress and egress routers on ECRTP
			over MPLS LSPs. For example, 'targeted LDP sessions' might be
			established for signaling SCIDs, or perhaps methods described in
			[LDP-PWE3] and [GVPLS] to signal pseudo-wires and multipoint-to-point
			LSPs might be extended to support signaling of SCIDs for ECRTP over MPLS
			LSPs. These protocol extensions need coordination with other working
			groups (e.g., MPLS).
	Resynchronization and performance of ECRTP over MPLS needs to be		Resynchronization and performance of ECRTP over MPLS needs to be
	considered. cRTP performs best with very low packet error rates on all		considered. cRTP performs best with very low packet error rates on all
	hops of the path. Tunneling a cRTP session through multiple hops will		hops of the path. Tunneling a cRTP session over an MPLS LSP with
	increase the round trip delay and the chance of packet loss, and cRTP		multiple routers in the path will increase the round trip delay and the
	contexts are invalidated due to packet loss. The cRTP error recovery		chance of packet loss, and cRTP contexts are invalidated due to packet
	mechanism using CONTEXT_STATE packets can compound the problem when long		loss. The cRTP error recovery mechanism using CONTEXT_STATE packets can
	round trip delays are involved. When the cRTP decompressor context state		compound the problem when long round trip delays are involved. When the
	gets out of synch with the compressor, it will drop packets associated		cRTP decompressor context state gets out of synch with the compressor,
	with the context until the two states are resynchronized. To		it will drop packets associated with the context until the two states
	resynchronize context state at the two ends, the decompressor transmits		are resynchronized. To resynchronize context state at the two ends, the
	the CONTEXT_STATE packet to the compressor, and the compressor transmits		decompressor transmits the CONTEXT_STATE packet to the compressor, and
	a FULL_HEADER packet to the decompressor. [ECRTP] minimizes feedback		the compressor transmits a FULL_HEADER packet to the decompressor.
	based error recovery using CONTEXT_STATE packets to make cRTP more		[ECRTP] minimizes feedback based error recovery using CONTEXT_STATE
	tolerant of packet loss, and minimize the need to use the cRTP error		packets to make cRTP more tolerant of packet loss, and minimize the need
	recovery mechanism. [ECRTP] should be used to make cRTP more tolerant of		to use the cRTP error recovery mechanism. [ECRTP] should be used to make
	packet loss and to guard against frequent resynchronizations.		ECRTP over MPLS more tolerant of packet loss and to guard against
			frequent resynchronizations.
	Scalability of ECRTP over MPLS needs to be considered. This may require		Scalability of ECRTP over MPLS needs to be considered. This may require
	that LSPs be established with RSVP-TE between many router pairs, raising		that LSPs be established with RSVP-TE between many router pairs, raising
	possible scalability issues. RSVP-TE has advantages in that it allows		possible scalability issues. RSVP-TE has advantages in that it allows
	VoIP bandwidth assignment on LSPs and has QoS mechanisms. LDP is more		VoIP bandwidth assignment on LSPs and has QoS mechanisms. LDP is more
	scalable, but lacks QoS mechanisms.		scalable, but lacks QoS mechanisms.
	4. Example Scenario		4. Example Scenario
	As illustrated in Figure 2, many VoIP flows are originated from customer		As illustrated in Figure 2, many VoIP flows are originated from customer
	sites such as R1, R2, and R3 to several large customer call centers		sites such as R1, R2, and R3 to several large customer call centers
	served by R4, which include R5, R6, and R7. It is essential that the		served by R4, which include R5, R6, and R7. It is essential that the
	R4-R5, R4-R6, and R4-R7 access links all use header compression to allow		R4-R5, R4-R6, and R4-R7 low-speed links all use header compression to
	a maximum number of simultaneous VoIP flows. To allow processing at R4		allow a maximum number of simultaneous VoIP flows. To allow processing
	to handle the volume of simultaneous VoIP flows, it is desired to use		at R4 to handle the volume of simultaneous VoIP flows, it is desired to
	ECRTP over MPLS for these flows. With ECRTP over MPLS, R4 does not need		use ECRTP over MPLS for these flows. With ECRTP over MPLS, R4 does not
	to do header compression/decompression for the flows to the call		need to do header compression/decompression for the flows to the call
	centers, enabling more scalability of the number of simultaneous VoIP		centers, enabling more scalability of the number of simultaneous VoIP
	flows with header compression at R4.		flows with header compression at R4.
	voice/ECRTP/MPLS-labels ______ voice/ECRTP/MPLS-labels		voice/ECRTP/MPLS-labels ______ voice/ECRTP/MPLS-labels
	R1/HC---------------------->| |-----------------------> R5/HD		R1/HC---------------------->| |-----------------------> R5/HD
	| |		| |
	voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels		voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels
	R2/HC---------------------->| R4 |-----------------------> R6/HD		R2/HC---------------------->| R4 |-----------------------> R6/HD
	| |		| |
	voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels		voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels
	R3/HC---------------------->|______|-----------------------> R7/HD		R3/HC---------------------->|______|-----------------------> R7/HD
			[Note: HC 3D header compression; HD 3D header decompression]
	Figure 2. Example Scenario for Application of ECRTP over MPLS		Figure 2. Example Scenario for Application of ECRTP over MPLS
	5. Security Considerations		5. Security Considerations
	No new requirements.		The high processing load of header compression makes header compression
			a target for denial-of-service attacks. For example, an attacker could
			send a high bandwidth data stream through a network, with the headers in
			the data stream marked appropriately to cause header compression to be
			applied. This would use large amounts of processing resources on the
			routers performing compression and decompression, and these processing
			resources might then be unavailable for other important functions on the
			router. This threat is not a new threat for cRTP/ECRTP header
			compression, but is addressed and mitigated by ECRTP over MPLS. That
			is, by reducing the need for performing compression and decompression
			cycles, as proposed in this draft, the risk of this type of
			denial-of-service attack is reduced.
	6. References		6. IANA Considerations
			No IANA actions are required.
			7. References
	[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for		[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for
	Low-Speed Serial Links", RFC 2508, February 1999.		Low-Speed Serial Links", RFC 2508, February 1999.
	[VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header		[cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression
	Compression", work in progress.		over PPP", RFC 2509, February 1999.
	[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links		[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links
	with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.		with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
			[GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution
			based on LPE Framework," work in progress.
	[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January		[LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January
	2001.		2001.
			[LDP-PWE3] Martini, L., et. al., "Pseudowire Setup and Maintenance using
			LDP", work in progress.
			[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching
			Architecture," RFC 3031, January 2001.
			[MPLS-ENCAP] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032,
			January 2001.
	[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March		[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
	1999.		1999.
			[ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC
			3091, July 2001.
	[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --		[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
	Version 1, Functional Specification", RFC 2205, September 1997.		Version 1, Functional Specification", RFC 2205, September 1997.
	[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP		[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	7. Authors' Addresses		[VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header
			Compression", work in progress.
			8. Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in RFC 2028. Copies of
			claims of rights made available for publication 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 implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
			9. 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
	E-mail: bgoode@att.com		E-mail: bgoode@att.com
	Jim Hand		Jim Hand
	AT&T		AT&T
	Room MT A2-4F36		E-mail: hand17@earthlink.net
	200 Laurel Avenue
	Middletown, NJ 07748, USA
	Phone: +1 732-420-6179
	E-mail: jameshand@att.com
	Raymond Zhang		Raymond Zhang
	Infonet Services Corporation		Infonet Services Corporation
	2160 E. Grand Ave. El Segundo, CA 90025 USA		2160 E. Grand Ave. El Segundo, CA 90025 USA
	Email: raymond_zhangr@info.net		Email: raymond_zhangr@info.net
	8. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included		provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works.		on all such copies and derivative works.
End of changes. 31 change blocks.
	109 lines changed or deleted		192 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/