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/