draft-ietf-mpls-in-udp-02.txt		draft-ietf-mpls-in-udp-03.txt
	Network working group X. Xu		Network working group X. Xu
	Internet Draft Huawei		Internet Draft Huawei
	Category: Standard Track N. Sheth		Category: Standard Track N. Sheth
	Juniper		Juniper
	L. Yong		L. Yong
	Huawei		Huawei
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	Y. Fan		Y. Fan
	China Telecom		China Telecom
	Expires: December 2013 June 9, 2013		Expires: March 2014 September 9, 2013
	Encapsulating MPLS in UDP		Encapsulating MPLS in UDP
	draft-ietf-mpls-in-udp-02		draft-ietf-mpls-in-udp-03
	Abstract		Abstract
	Existing technologies to encapsulate Multi-Protocol Label Switching		This document specifies an additional IP-based encapsulation for
	(MPLS) over IP are not adequate for efficient load balancing of MPLS		MPLS, referred to as MPLS-in-UDP (User Datagram Protocol), which is
	application traffic, such as MPLS-based Layer2 Virtual Private		applicable in some circumstances. This document only describes the
	Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic		MPLS-in-UDP encapsulation.
	across IP networks. This document specifies additional IP-based
	encapsulation technology, referred to as MPLS-in-User Datagram
	Protocol (UDP), which can facilitate the load balancing of MPLS
	application traffic across IP networks.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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		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."
	This Internet-Draft will expire on December 9, 2013.		This Internet-Draft will expire on March 9, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Conventions used in this document
	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 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction ................................................ 3		1. Introduction ................................................ 3
	1.1. Existing Technologies .................................. 3		1.1. Existing Encapsulations ................................ 3
	1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4		1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4
	2. Terminology ................................................. 4		2. Terminology ................................................. 4
	3. Encapsulation in UDP ........................................ 4		3. Encapsulation in UDP......................................... 4
	4. Processing Procedures ....................................... 5		4. Processing Procedures ....................................... 5
	5. Applicability ............................................... 6		5. Congestion Considerations ................................... 6
	6. Security Considerations ..................................... 6		6. Security Considerations ..................................... 6
	7. IANA Considerations ......................................... 6		7. IANA Considerations ......................................... 6
	8. Acknowledgements ............................................ 6		8. Contributors ................................................ 7
	9. References .................................................. 7		9. Acknowledgements ............................................ 7
	9.1. Normative References ................................... 7		10. References ................................................. 7
	9.2. Informative References ................................. 7		10.1. Normative References .................................. 7
			10.2. Informative References ................................ 8
	Authors' Addresses ............................................. 8		Authors' Addresses ............................................. 8
	1. Introduction		1. Introduction
	To fully utilize the bandwidth available in IP networks and/or		This document specifies an additional IP-based encapsulation for
	facilitate recovery from a link or node failure, load balancing of		MPLS, referred to as MPLS-in-UDP (User Datagram Protocol). It also
	traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation		describes the applicability of this encapsulation in presence of
	Group (LAG) across IP networks is widely used. In effect, most		other IP-based encapsulations for MPLS.
	existing core routers in IP networks are already capable of
	distributing IP traffic flows over ECMP paths and/or LAG based on the
	hash of the five-tuple of User Datagram Protocol (UDP)[RFC768] and
	Transmission Control Protocol (TCP) packets (i.e., source IP address,
	destination IP address, source port, destination port, and protocol).
	In practice, there are some scenarios for Multi-Protocol Label		This encapsulation allows for two Label Switching Routers (LSR) to
	Switching (MPLS) applications (e.g., MPLS-based Layer2 Virtual		be adjacent on a Label Switched Path (LSP), while separated by an
	Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN))		IP network. In order to support this encapsulation, each LSR needs
	where the MPLS application traffic needs to be transported through		to know the capability to decapsulate MPLS-in-UDP by the remote
	IP-based tunnels, rather than MPLS tunnels. For example, MPLS-based		LSRs. This specification defines only the data plane encapsulation
	L2VPN or L3VPN technologies may be used for interconnecting		and does not concern itself with how the knowledge to use this
	geographically dispersed enterprise data centers or branch offices		encapsulation is conveyed.
	across IP Wide Area Networks (WAN) where enterprise own router
	devices are deployed as L2VPN or L3VPN Provider Edge (PE) routers. In
	this case, efficient load balancing of the MPLS application traffic
	across IP networks is very desirable.
	1.1. Existing Technologies		An applicability statement will compare situations in which using
			the MPLS-in-UDP encapsulation might be advantageous over other IP-
			based encapsulations for MPLS. One of the key considerations in
			this respect is how to achieve efficient load-balance of traffic
			over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group
			(LAG).
	With existing IP-based encapsulation methods for MPLS applications,		1.1. Existing Encapsulations
	such as MPLS-in-IP and MPLS-in-Generic Routing Encapsulation (GRE)
	[RFC4023] or even MPLS-in-Layer Two Tunneling Protocol - Version 3
	(L2TPv3)[RFC4817], distinct customer traffic flows between a given PE
	router pair would be encapsulated with the same IP-based tunnel
	headers prior to traversing the core of the IP WAN. Since the
	encapsulated traffic is neither TCP nor UDP traffic, for many
	existing core routers which could only perform hash calculation on
	fields in the IP headers of those tunnels (i.e., source IP address,
	destination IP address), it would be hard to achieve a fine-grained
	load balancing of these traffic flows across the network core due to
	the lack of adequate entropy information.
	[RFC5640] describes a method for improving the load balancing		Currently, there are a number of IP-based encapsulations for MPLS.
	efficiency in a network carrying Softwire Mesh service over L2TPv3		These include MPLS-in-IP, MPLS-in- GRE (Generic Routing
	and GRE encapsulation. However, this method requires core routers to		Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling
	be capable of performing hash calculation on the "load-balancing"		Protocol - Version 3)[RFC4817]. In all these methods, the IP
	field contained in the tunnel encapsulation headers (i.e., the		addresses can be varied to achieve load-balancing.
	Session ID field in the L2TPv3 header or the Key field in the GRE
	header), which means a non-trivial change to the date plane of many		All these IP-based encapsulations for MPLS are specified for both
	existing core routers.		IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6
			Flow Label can be used for ECMP and LAGs [RFC6438].
			For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE
			Key and the L2TPv3 Session ID respectively) can be used as the
			load-balancing key. This method is described in [RFC5640]. For this,
			however, core routers need to understand these fields in the
			context of being used as load-balancing keys.
			In terms of MPLS-based encapsulations, load-balancing is achieved
			with the introduction of the Entropy Label [RFC6790].
	1.2. Motivations for MPLS-in-UDP Encapsulation		1.2. Motivations for MPLS-in-UDP Encapsulation
	On basis of the fact that most existing core routers (i.e., P routers		Currently, many existing routers in IP networks are already capable
	in the context of MPLS-based L2VPN or L3VPN) are already capable of		of distributing IP traffic "microflows" [RFC2474] over ECMP paths
	balancing IP traffic flows over the IP networks based on the hash of		and/or LAG based on the hash of the five-tuple of User Datagram
	the five-tuple of UDP packets, it would be advantageous to use MPLS-		Protocol (UDP)[RFC768] and Transmission Control Protocol (TCP)
	in-UDP encapsulation instead of MPLS-in-GRE or MPLS-in-L2TPv3 in the		packets (i.e., source IP address, destination IP address, source
	environments where the load balancing of MPLS application traffic		port, destination port, and protocol).
	across IP networks is much desired but the load balancing mechanisms
	defined in [RFC5640] have not yet been widely supported by most		The motivation of MPLS-in-UDP is to leverage this existing
	existing core routers. In this way, the default load balancing		capability to provide load-balancing of MPLS traffic over IP
	capability of most existing core routers as mentioned above can be		networks.
	utilized directly without requiring any change to them.
	2. Terminology		2. Terminology
	This memo makes use of the terms defined in [RFC4364] and [RFC4664].		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
			[RFC2119].
	3. Encapsulation in UDP		3. Encapsulation in UDP
	MPLS-in-UDP encapsulation format is shown as follows:		MPLS-in-UDP encapsulation format is shown as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port = Entropy | Dest Port = MPLS |		| Source Port = Entropy | Dest Port = MPLS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	~ MPLS Label Stack ~		~ MPLS Label Stack ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Message Body ~		~ Message Body ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Source Port of UDP		Source Port of UDP
	This field contains an entropy value that is generated by		This field contains a 16-bit entropy value that is
	the ingress PE router. For example, the entropy value can		generated by the ingress PE router. For example, the
	be generated by performing hash calculation on certain		entropy value can be generated by performing hash
	fields in the customer packets (e.g., the five tuple of		calculation on certain fields in the customer packets
	UDP/TCP packets).		(e.g., the five tuple of UDP/TCP packets).
	Destination Port of UDP		Destination Port of UDP
	This field is set to a value (TBD) indicating that the		This field is set to a value (TBD) indicating that the
	UDP tunnel payload is a MPLS packet. As for whether the		UDP tunnel payload is a MPLS packet. As for whether the
	top label in the MPLS label stack is downstream-assigned		top label in the MPLS label stack is downstream-
	or upstream-assigned, it SHOULD be determined based on		assigned or upstream-assigned, it SHOULD be determined
	the tunnel destination IP address. That is to say, if the		based on the tunnel destination IP address. That is to
	destination IP address is a multicast address, the top		say, if the destination IP address is a multicast
	label SHOULD be upstream-assigned, otherwise if the		address, the top label SHOULD be upstream-assigned,
	destination IP address is a unicast address, it SHOULD be		otherwise if the destination IP address is a unicast
	downstream-assigned.		address, it SHOULD be downstream-assigned.
	UDP Length		UDP Length
	The usage of this field is in accordance with the current		The usage of this field is in accordance with the
	UDP specification.		current UDP specification [RFC768].
	UDP Checksum		UDP Checksum
	The usage of this field is in accordance with the current		The usage of this field is in accordance with the
	UDP specification. To simplify the operation on egress PE		current UDP specification. To simplify the operation on
	routers, this field is RECOMMENDED to be set to zero in		egress PE routers, this field is RECOMMENDED to be set
	IPv4 UDP encapsulation case, and even in IPv6 UDP		to zero in IPv4 UDP encapsulation case, and also in
	encapsulation case if appropriate[RFC6935][RFC6936].		IPv6 UDP encapsulation case if appropriate [RFC6935]
			[RFC6936].
	MPLS Label Stack		MPLS Label Stack
	This field contains an MPLS Label Stack as defined in		This field contains an MPLS Label Stack as defined in
	[RFC3032].		[RFC3032].
	Message Body		Message Body
	This field contains one MPLS message body.		This field contains one MPLS message body.
	4. Processing Procedures		4. Processing Procedures
	This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded		This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded
	through "UDP tunnels". When performing MPLS-in-UDP encapsulation by		through "UDP tunnels". When performing MPLS-in-UDP encapsulation by
	an ingress PE router, the entropy value would be generated by the		an ingress PE router, the entropy value would be generated by the
	ingress PE router and then be filled in the Source Port field of the		ingress PE router and then be filled in the Source Port field of
	UDP header. As such, P routers, upon receiving these UDP encapsulated		the UDP header. As such, P routers, upon receiving these UDP
	packets, could balance these packets based on the hash of the five-		encapsulated packets, could balance these packets based on the hash
	tuple of UDP packets.		of the five-tuple of UDP packets.
	Upon receiving these UDP encapsulated packets, egress PE routers		Upon receiving these UDP encapsulated packets, egress PE routers
	would decapsulate them by removing the UDP headers and then process		would decapsulate them by removing the UDP headers and then process
	them accordingly.		them accordingly.
	As for other common processing procedures associated with tunneling		As for other common processing procedures associated with tunneling
	encapsulation technologies including but not limited to Maximum		encapsulation technologies including but not limited to Maximum
	Transmission Unit (MTU) and preventing fragmentation and reassembly,		Transmission Unit (MTU) and preventing fragmentation and reassembly,
	Time to Live (TTL) and differentiated services, the corresponding		Time to Live (TTL) and differentiated services, the corresponding
	procedures defined in [RFC4023] which are applicable for MPLS-in-IP		"Common Procedures" defined in [RFC4023] which are applicable for
	and MPLS-in-GRE encapsulation formats SHOULD be followed.		MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed.
	5. Applicability		5. Congestion Considerations
	Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762]		MPLS can carry a number of different protocols as payloads. When an
	applications, MPLS-in-UDP encapsulation could apply to other MPLS		MPLS/UDP flow carries IP-based traffic, the aggregate traffic is
	applications including but not limited to 6PE [RFC4798] and PWE3		assumed to be TCP friendly due to the congestion control mechanisms
	services.		used by the payload traffic. Packet loss will trigger the necessary
			reduction in offered load, and no additional congestion avoidance
			action is necessary. When an MPLS/UDP flow carries payload traffic
			that is not known to be TCP friendly and the flow runs across an
			unprovisioned path that could potentially become congested, the
			application that uses the encapsulation specified in this document
			MUST employ additional mechanisms to ensure that the offered load
			is reduced appropriately during periods of congestion.
	6. Security Considerations		6. Security Considerations
	Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the MPLS-		Just like other IP-based encapsulations of MPLS, the MPLS-in-UDP
	in-UDP encapsulation format defined in this document by itself cannot		encapsulation format defined in this document by itself cannot
	ensure the integrity and privacy of data packets being transported		ensure the integrity and privacy of data packets being transported
	through the MPLS-in-UDP tunnels and cannot enable the tunnel		through the MPLS-in-UDP tunnels and cannot enable the tunnel
	decapsulators to authenticate the tunnel encapsulator. In the case		decapsulators to authenticate the tunnel encapsulator. In the case
	where any of the above security issues is concerned, the MPLS-in-UDP		where any of the above security issues is concerned, the MPLS-in-
	tunnels SHOULD be secured with IPsec in transport mode. In this way,		UDP tunnels SHOULD be secured with IPsec in transport mode. In this
	the UDP header would not be visible to P routers anymore. As a result,		way, the UDP header would not be visible to P routers anymore. As a
	the meaning of adopting MPLS-in-UDP encapsulation format as an		result, the meaning of adopting MPLS-in-UDP encapsulation format as
	alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats is		an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats
	lost. Hence, MPLS-in-UDP encapsulation format SHOULD be used only in		is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be used
	the scenarios where all the security issues as mentioned above are		only in the scenarios where all the security issues as mentioned
	not significant concerns. For example, in a data center environment,		above are not significant concerns.
	the whole network including P routers and PE routers are under the
	control of a single administrative entity and therefore there is no
	need to worry about the above security issues.
	7. IANA Considerations		7. IANA Considerations
	One UDP destination port number indicating MPLS needs to be allocated		One UDP destination port number indicating MPLS needs to be
	by IANA.		allocated by IANA.
	8. Acknowledgements		Service Name : MPLS-in-UDP
			Transport Protocol(s) : UDP
			Assignee : IESG <iesg@ietf.org>
			Contact : IETF Chair <chair@ietf.org>.
			Description : Encapsulate MPLS packets in UDP tunnels.
			Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG
			document).
			Port Number : To be assigned by IANA.
			8. Contributors
			Zhenbin Li
			Huawei Technologies,
			Beijing, China
			Phone: +86-10-60613676
			Email: lizhenbin@huawei.com
			9. Acknowledgements
	Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak,		Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak,
	Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks,		Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks,
	George Swallow, Loa Andersson, Ross Callon, Vivek Kumar, Weiguo Hao,		George Swallow, Loa Andersson, Ross Callon, Vivek Kumar, Weiguo Hao,
	Zhenxiao Liu and Xing Tong for their valuable comments and		Mark Szczesniak, Zhenxiao Liu and Xing Tong for their valuable
	suggestions on this document. Thanks to Daniel King, Gregory Mirsky		comments andsuggestions on this document. Thanks to Daniel King,
	and Eric Osborne for their valuable reviews on this document.		Gregory Mirsky and Eric Osborne for their valuable reviews on this
			document.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[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.
	9.2. Informative References		[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
			August 1980.
	[RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Networks (VPNs)", RFC 4364, February 2006.		Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
			Encoding", RFC 3032, January 2001.
	[RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer		10.2. Informative References
	2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006.
	[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS		[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
	in IP or GRE", RFC4023, March 2005.		MPLS in IP or GRE", RFC4023, March 2005.
	[RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J.		[RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J.
	Young, "Encapsulation of MPLS over Layer 2 Tunneling		Young, "Encapsulation of MPLS over Layer 2 Tunneling
	Protocol Version 3, March 2007.		Protocol Version 3, March 2007.
	[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-		[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
	Balancing for Mesh Softwires", RFC 5640, August 2009.		Balancing for Mesh Softwires", RFC 5640, August 2009.
	[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
	Multicast Encapsulations", RFC 5332, August 2008.
	[RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS
	using IPv6 Provider Edge Routers (6PE)", RFC4798, February
	2007.
	[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
	(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
	4761, January 2007.
	[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
	(VPLS) Using Label Distribution Protocol (LDP) Signaling",
	RFC 4762, January 2007.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, January 2001.
	[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.
	[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP		[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP
	Checksums for Tunneled Packets", RFC6935,		Checksums for Tunneled Packets", RFC6935,
	Feburary 2013.		Feburary 2013.
	[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement		[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
	for the use of IPv6 UDP Datagrams with Zero Checksums",		for the use of IPv6 UDP Datagrams with Zero Checksums",
	RFC6936, Feburary 2013.		RFC6936, Feburary 2013.
	[IP-in-UDP] Xu, etc, "Encapsulating IP in UDP", draft-xu-softwire-ip-		[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
	in-udp-01 (work in progress), February 2013.		"Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers", RFC2474, December
			1998.
			[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
			for Equal Cost Multipath Routing and Link Aggregation in
			Tunnels", RFC 6438, November 2011.
			[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
			L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
			RFC 6790, November 2012.
	Authors' Addresses		Authors' Addresses
	Xiaohu Xu		Xiaohu Xu
	Huawei Technologies		Huawei Technologies
	Beijing, China		Beijing, China
	Phone: +86-10-60610041		Phone: +86-10-60610041
	Email: xuxiaohu@huawei.com		Email: xuxiaohu@huawei.com
	Nischal Sheth		Nischal Sheth
	skipping to change at page 8, line 32		skipping to change at page 9, line 4
	Huawei Technologies		Huawei Technologies
	Beijing, China		Beijing, China
	Phone: +86-10-60610041		Phone: +86-10-60610041
	Email: xuxiaohu@huawei.com		Email: xuxiaohu@huawei.com
	Nischal Sheth		Nischal Sheth
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave		1194 N. Mathilda Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: nsheth@juniper.net		Email: nsheth@juniper.net
	Lucy Yong		Lucy Yong
	Huawei USA		Huawei USA
	5340 Legacy Dr.		5340 Legacy Dr.
	Plano TX75025		Plano TX75025
	Phone: 469-277-5837		Phone: 469-277-5837
	Email: Lucy.yong@huawei.com		Email: Lucy.yong@huawei.com
	Carlos Pignataro		Carlos Pignataro
	Cisco Systems		Cisco Systems 7200-12 Kit Creek Road
	7200-12 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	USA		USA
	EMail: cpignata@cisco.com		Email: cpignata@cisco.com
	Yongbing Fan		Yongbing Fan
	China Telecom		China Telecom
	Guangzhou, China.		Guangzhou, China.
	Phone: +86 20 38639121		Phone: +86 20 38639121
	Email: fanyb@gsta.com		Email: fanyb@gsta.com
	Zhenbin Li
	Huawei Technologies,
	Beijing, China
	Phone: +86-10-60613676
	Email: lizhenbin@huawei.com
End of changes. 42 change blocks.
	173 lines changed or deleted		176 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/