draft-ietf-mpls-in-udp-03.txt | draft-ietf-mpls-in-udp-04.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: March 2014 September 9, 2013 | Expires: June 2014 December 12, 2013 | |||
Encapsulating MPLS in UDP | Encapsulating MPLS in UDP | |||
draft-ietf-mpls-in-udp-03 | draft-ietf-mpls-in-udp-04 | |||
Abstract | Abstract | |||
This document specifies an additional IP-based encapsulation for | This document specifies an IP-based encapsulation for MPLS, called | |||
MPLS, referred to as MPLS-in-UDP (User Datagram Protocol), which is | MPLS-in-UDP (User Datagram Protocol). | |||
applicable in some circumstances. This document only describes the | ||||
MPLS-in-UDP encapsulation. | ||||
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 March 9, 2014. | This Internet-Draft will expire on June 12, 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 | |||
skipping to change at page 2, line 27 | skipping to change at page 2, line 18 | |||
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. | |||
Table of Contents | Table of Contents | |||
1. Introduction ................................................ 3 | 1. Introduction ................................................ 3 | |||
1.1. Existing Encapsulations ................................ 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 ....................................... 6 | |||
5. Congestion Considerations ................................... 6 | 5. Congestion Considerations ................................... 6 | |||
6. Security Considerations ..................................... 6 | 6. Security Considerations ..................................... 7 | |||
7. IANA Considerations ......................................... 6 | 7. IANA Considerations ......................................... 8 | |||
8. Contributors ................................................ 7 | 8. Contributors ................................................ 8 | |||
9. Acknowledgements ............................................ 7 | 9. Acknowledgements ............................................ 9 | |||
10. References ................................................. 7 | 10. References ................................................. 9 | |||
10.1. Normative References .................................. 7 | 10.1. Normative References .................................. 9 | |||
10.2. Informative References ................................ 8 | 10.2. Informative References ................................ 9 | |||
Authors' Addresses ............................................. 8 | Authors' Addresses ............................................ 10 | |||
1. Introduction | 1. Introduction | |||
This document specifies an additional IP-based encapsulation for | This document specifies an IP-based encapsulation for MPLS, i.e. | |||
MPLS, referred to as MPLS-in-UDP (User Datagram Protocol). It also | MPLS-in-UDP (User Datagram Protocol), which is applicable in some | |||
describes the applicability of this encapsulation in presence of | circumstances where IP-based encapsulation for MPLS is required and | |||
other IP-based encapsulations for MPLS. | further fine-grained load balancing of MPLS packets over IP | |||
networks over Equal Cost Multi-Path (ECMP) and/or Link Aggregation | ||||
Groups (LAG) is required as well. There are already IP-based | ||||
encapsulations for MPLS that allow for fine-grained load balancing | ||||
by using some special field in the encapsulation header as an | ||||
entropy field. However, MPLS-in-UDP can be advantageous since some | ||||
networks have used the UDP port number fields as a basis for load- | ||||
balancing solutions for some time. This is similar to why LISP [RFC | ||||
6830] uses UDP encapsulation. | ||||
This encapsulation allows for two Label Switching Routers (LSR) to | Like other IP-based encapsulation methods for MPLS, this | |||
be adjacent on a Label Switched Path (LSP), while separated by an | encapsulation allows for two Label Switching Routers (LSR) to be | |||
IP network. In order to support this encapsulation, each LSR needs | adjacent on a Label Switched Path (LSP), while separated by an IP | |||
to know the capability to decapsulate MPLS-in-UDP by the remote | network. In order to support this encapsulation, each LSR needs to | |||
LSRs. This specification defines only the data plane encapsulation | know the capability to decapsulate MPLS-in-UDP by the remote LSRs. | |||
and does not concern itself with how the knowledge to use this | This specification defines only the data plane encapsulation and | |||
encapsulation is conveyed. | does not concern itself with how the knowledge to use this | |||
encapsulation is conveyed. Specifically, this capability can be | ||||
either manually configured on each LSR or be dynamically advertised | ||||
in manners that are outside the scope of this document. | ||||
An applicability statement will compare situations in which using | Similarly, the MPLS-in-UDP encapsulation format defined in this | |||
the MPLS-in-UDP encapsulation might be advantageous over other IP- | document by itself cannot ensure the integrity and privacy of data | |||
based encapsulations for MPLS. One of the key considerations in | packets being transported through the MPLS-in-UDP tunnels and | |||
this respect is how to achieve efficient load-balance of traffic | cannot enable the tunnel decapsulators to authenticate the tunnel | |||
over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group | encapsulator. Therefore, in the case where any of the above | |||
(LAG). | security issues is concerned, the MPLS-in-UDP SHOULD be secured | |||
with IPsec [RFC4301] or DTLS [RFC6347]. For more details, please | ||||
see section 6 of Security Considerations. | ||||
1.1. Existing Encapsulations | 1.1. Existing Encapsulations | |||
Currently, there are a number of IP-based encapsulations for MPLS. | Currently, there are several IP-based encapsulations for MPLS such | |||
These include MPLS-in-IP, MPLS-in- GRE (Generic Routing | as MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) | |||
Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling | [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling Protocol - | |||
Protocol - Version 3)[RFC4817]. In all these methods, the IP | Version 3) [RFC4817]. In all these methods, the IP addresses can be | |||
addresses can be varied to achieve load-balancing. | varied to achieve load-balancing. | |||
All these IP-based encapsulations for MPLS are specified for both | All these IP-based encapsulations for MPLS are specified for both | |||
IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 | IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 | |||
Flow Label can be used for ECMP and LAGs [RFC6438]. | Flow Label can be used for ECMP and LAGs [RFC6438]. However, there | |||
is no such entropy field in the IPv4 header. | ||||
For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE | 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 | Key and the L2TPv3 Session ID respectively) can be used as the | |||
load-balancing key. This method is described in [RFC5640]. For this, | load-balancing key as described in [RFC5640]. For this, core | |||
however, core routers need to understand these fields in the | routers need to understand these fields in the context of being | |||
context of being used as load-balancing keys. | 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 | |||
Currently, many existing routers in IP networks are already capable | Currently, most existing routers in IP networks are already capable | |||
of distributing IP traffic "microflows" [RFC2474] over ECMP paths | of distributing IP traffic "microflows" [RFC2474] over ECMPs and/or | |||
and/or LAG based on the hash of the five-tuple of User Datagram | LAG based on the hash of the five-tuple of User Datagram Protocol | |||
Protocol (UDP)[RFC768] and Transmission Control Protocol (TCP) | (UDP)[RFC768] and Transmission Control Protocol (TCP) packets (i.e., | |||
packets (i.e., source IP address, destination IP address, source | source IP address, destination IP address, source port, destination | |||
port, destination port, and protocol). | port, and protocol). By encapsulating the MPLS packets into an UDP | |||
tunnel and using the source port of the UDP header as an entropy | ||||
The motivation of MPLS-in-UDP is to leverage this existing | field, the existing load-balancing capability as mentioned above | |||
capability to provide load-balancing of MPLS traffic over IP | can be leveraged to provide fine-grained load-balancing of MPLS | |||
networks. | traffic over IP networks. | |||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
this document are to be interpreted as described in RFC-2119 | this document are to be interpreted as described in RFC-2119 | |||
[RFC2119]. | [RFC2119]. | |||
3. Encapsulation in UDP | 3. Encapsulation in UDP | |||
skipping to change at page 4, line 48 | skipping to change at page 5, line 10 | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ Message Body ~ | ~ Message Body ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Source Port of UDP | Source Port of UDP | |||
This field contains a 16-bit entropy value that is | This field contains a 16-bit entropy value that is | |||
generated by the ingress PE router. For example, the | generated by the ingress PE router. What algorithm is | |||
entropy value can be generated by performing hash | actually used by the ingress PE router to generate an | |||
calculation on certain fields in the customer packets | entropy value is outside the scope of this doc. In the | |||
(e.g., the five tuple of UDP/TCP packets). | case where the flow does not need entropy, this field | |||
SHOULD be set to a randomly selected constant value to | ||||
avoid packet reordering. | ||||
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 allocated by | |||
UDP tunnel payload is a MPLS packet. As for whether the | IANA) indicating that the UDP tunnel payload is an MPLS | |||
top label in the MPLS label stack is downstream- | packet using MPLS-in-UDP (TBD1). | |||
assigned or upstream-assigned, it SHOULD be determined | ||||
based on the tunnel destination IP address. That is to | ||||
say, if the destination IP address is a multicast | ||||
address, the top label SHOULD be upstream-assigned, | ||||
otherwise if the destination IP address is a unicast | ||||
address, it SHOULD be downstream-assigned. | ||||
UDP Length | UDP Length | |||
The usage of this field is in accordance with the | The usage of this field is in accordance with the | |||
current UDP specification [RFC768]. | current UDP specification [RFC768]. | |||
UDP Checksum | UDP Checksum | |||
The usage of this field is in accordance with the | The usage of this field is in accordance with the | |||
current UDP specification. To simplify the operation on | current UDP specification [RFC768]. To simplify the | |||
egress PE routers, this field is RECOMMENDED to be set | operation on egress PE routers, this field is | |||
to zero in IPv4 UDP encapsulation case, and also in | RECOMMENDED to be set to zero in IPv4 UDP encapsulation | |||
IPv6 UDP encapsulation case if appropriate [RFC6935] | case. In the IPv6 UDP encapsulation case, if | |||
[RFC6936]. | appropriate according to the requirements defined in | |||
[RFC6935] [RFC6936], this field is also RECOMMENDED to | ||||
be set to zero. Specifically, if the MPLS payload is | ||||
Internet Protocol (IPv4 or IPv6) packets, it is | ||||
RECOMMENDED to be set to zero when the inner packet | ||||
integrity checks is available. In addition, if the MPLS | ||||
payload is non-IP packet which is specifically designed | ||||
for transmission over a lower layer that does not | ||||
provide a packet integrity guarantee, it is RECOMMENDED | ||||
to be set to zero as well. Otherwise, using zero | ||||
checksum is NOT RECOMMENDED. Note that other IP | ||||
encapsulations for MPLS do not have a checksum in the | ||||
transport header. | ||||
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 | |||
skipping to change at page 5, line 46 | skipping to change at page 6, line 17 | |||
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 | ingress PE router and then be filled in the Source Port field of | |||
the UDP header. As such, P routers, upon receiving these UDP | the UDP header. The Destination Port field is set to a value (TBD1 | |||
encapsulated packets, could balance these packets based on the hash | for MPLS-in-UDP or TBD2 for MPLS-in-UDP with DTLS) allocated by | |||
of the five-tuple of UDP packets. | IANA to indicate that the UDP tunnel payload is an MPLS packet. As | |||
for whether the top label in the MPLS label stack is downstream- | ||||
assigned or upstream-assigned, it SHOULD be determined based on the | ||||
tunnel destination IP address. That is to say, if the destination | ||||
IP address is a multicast address, the top label SHOULD be | ||||
upstream-assigned, otherwise if the destination IP address is a | ||||
unicast address, it SHOULD be downstream-assigned. | ||||
As such, P routers, upon receiving these UDP encapsulated packets, | ||||
could balance these packets based on the hash 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 | |||
"Common Procedures" defined in [RFC4023] which are applicable for | "Common Procedures" defined in [RFC4023] which are applicable for | |||
skipping to change at page 6, line 28 | skipping to change at page 7, line 7 | |||
MPLS can carry a number of different protocols as payloads. When an | MPLS can carry a number of different protocols as payloads. When an | |||
MPLS/UDP flow carries IP-based traffic, the aggregate traffic is | MPLS/UDP flow carries IP-based traffic, the aggregate traffic is | |||
assumed to be TCP friendly due to the congestion control mechanisms | assumed to be TCP friendly due to the congestion control mechanisms | |||
used by the payload traffic. Packet loss will trigger the necessary | used by the payload traffic. Packet loss will trigger the necessary | |||
reduction in offered load, and no additional congestion avoidance | reduction in offered load, and no additional congestion avoidance | |||
action is necessary. When an MPLS/UDP flow carries payload traffic | 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 | that is not known to be TCP friendly and the flow runs across an | |||
unprovisioned path that could potentially become congested, the | unprovisioned path that could potentially become congested, the | |||
application that uses the encapsulation specified in this document | application that uses the encapsulation specified in this document | |||
MUST employ additional mechanisms to ensure that the offered load | MUST employ additional mechanisms to ensure that the offered load | |||
is reduced appropriately during periods of congestion. | is reduced appropriately during periods of congestion. This is not | |||
necessary in the case of an unprovisioned path through an over- | ||||
provisioned network, where the potential for congestion is avoided | ||||
through the over-provisioning of the network. | ||||
6. Security Considerations | 6. Security Considerations | |||
Just like other IP-based encapsulations of MPLS, the MPLS-in-UDP | Just like other IP-based encapsulations of MPLS, the MPLS-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- | where any of the above security issues is concerned, the MPLS-in- | |||
UDP tunnels SHOULD be secured with IPsec in transport mode. In this | UDP tunnels SHOULD be secured with IPsec or DTLS. If the tunnel is | |||
way, the UDP header would not be visible to P routers anymore. As a | secured with IPsec, the UDP header would not be visible to P | |||
result, the meaning of adopting MPLS-in-UDP encapsulation format as | routers anymore. As a result, the meaning of adopting MPLS-in-UDP | |||
an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats | encapsulation format as an alternative to MPLS-in-GRE and MPLS-in- | |||
is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be used | IP encapsulation formats is lost. If DTLS is used, the destination | |||
only in the scenarios where all the security issues as mentioned | port of the UDP header will be filled with a value (TBD2) | |||
above are not significant concerns. | indicating MPLS with DTLS and the source port can still be used as | |||
an entropy field. | ||||
If the tunnels are not secured with IPsec or DTLS, some other | ||||
method should be used to ensure that packets are decapsulated and | ||||
forwarded by the tunnel tail only if those packets were | ||||
encapsulated by the tunnel head. If the tunnel lies entirely within | ||||
a single administrative domain, address filtering at the boundaries | ||||
can be used to ensure that no packet with the IP source address of | ||||
a tunnel endpoint or with the IP destination address of a tunnel | ||||
endpoint can enter the domain from outside. However, when the | ||||
tunnel head and the tunnel tail are not in the same administrative | ||||
domain, this may become difficult, and filtering based on the | ||||
destination address can even become impossible if the packets must | ||||
traverse the public Internet. Sometimes only source address | ||||
filtering (but not destination address filtering) is done at the | ||||
boundaries of an administrative domain. If this is the case, the | ||||
filtering does not provide effective protection at all unless the | ||||
decapsulator of an MPLS-in-UDP validates the IP source address of | ||||
the packet. This document does not require that the decapsulator | ||||
validate the IP source address of the tunneled packets, but it | ||||
should be understood that failure to do so presupposes that there | ||||
is effective destination-based (or a combination of source-based | ||||
and destination-based) filtering at the boundaries. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
One UDP destination port number indicating MPLS needs to be | One UDP destination port number indicating MPLS needs to be | |||
allocated by IANA. | allocated by IANA. | |||
Service Name : MPLS-in-UDP | Service Name : MPLS-in-UDP | |||
Transport Protocol(s) : UDP | Transport Protocol(s) : UDP | |||
Assignee : IESG <iesg@ietf.org> | Assignee: IESG <iesg@ietf.org> | |||
Contact : IETF Chair <chair@ietf.org>. | Contact : IETF Chair <chair@ietf.org>. | |||
Description : Encapsulate MPLS packets in UDP tunnels. | Description : Encapsulate MPLS packets in UDP tunnels. | |||
Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG | Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG | |||
document). | document). | |||
Port Number : To be assigned by IANA. | Port Number : TBD1 -- To be assigned by IANA. | |||
One UDP destination port number indicating MPLS with DTLS needs to | ||||
be allocated by IANA. | ||||
Service Name : MPLS-in-UDP with DTLS | ||||
Transport Protocol(s) : UDP | ||||
Assignee: IESG <iesg@ietf.org> | ||||
Contact : IETF Chair <chair@ietf.org>. | ||||
Description : Encapsulate MPLS packets in UDP tunnels with DTLS. | ||||
Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG | ||||
document). | ||||
Port Number : TBD2 -- To be assigned by IANA. | ||||
8. Contributors | 8. Contributors | |||
Zhenbin Li | Zhenbin Li | |||
Huawei Technologies, | Huawei Technologies, | |||
Beijing, China | Beijing, China | |||
Phone: +86-10-60613676 | Phone: +86-10-60613676 | |||
Email: lizhenbin@huawei.com | Email: lizhenbin@huawei.com | |||
9. Acknowledgements | 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, | |||
Mark Szczesniak, Zhenxiao Liu and Xing Tong for their valuable | Mark Szczesniak, Zhenxiao Liu and Xing Tong for their valuable | |||
comments andsuggestions on this document. Thanks to Daniel King, | comments and suggestions on this document. Thanks to Daniel King, | |||
Gregory Mirsky and Eric Osborne for their valuable reviews on this | Gregory Mirsky and Eric Osborne for their valuable reviews on this | |||
document. | document. Special thanks to Adrian Farrel for his conscientious AD | |||
review and insightful suggestion of using DTLS for securing the | ||||
MPLS-in-UDP tunnels. Thanks to Charlie Kaufman for his Secdir | ||||
review of this document. | ||||
10. References | 10. References | |||
10.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. | |||
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | |||
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | |||
Encoding", RFC 3032, January 2001. | Encoding", RFC 3032, January 2001. | |||
10.2. Informative References | ||||
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating | [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating | |||
MPLS in IP or GRE", RFC4023, March 2005. | MPLS in IP or GRE", RFC4023, March 2005. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | ||||
Internet Protocol", RFC 4301, December 2005. | ||||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
Security Version 1.2", RFC 6347, January 2012. | ||||
10.2. Informative References | ||||
[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. | |||
[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. | |||
skipping to change at page 8, line 31 | skipping to change at page 10, line 19 | |||
[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. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC2474, December | Field) in the IPv4 and IPv6 Headers", RFC2474, December | |||
1998. | 1998. | |||
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label | |||
for Equal Cost Multipath Routing and Link Aggregation in | for Equal Cost Multipath Routing and Link Aggregation | |||
Tunnels", RFC 6438, November 2011. | in Tunnels", RFC 6438, November 2011. | |||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | Locator/ID Separation Protocol (LISP)", RFC 6830, | |||
RFC 6790, November 2012. | January 2013. | |||
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 9, line 4 | skipping to change at page 10, line 39 | |||
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 7200-12 Kit Creek Road | Cisco Systems | |||
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 | |||
End of changes. 32 change blocks. | ||||
98 lines changed or deleted | 180 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/ |