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/ |