draft-ietf-mpls-in-udp-00.txt   draft-ietf-mpls-in-udp-01.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
Contrail Systems Juniper
L. Yong L. Yong
Huawei Huawei
C Pignataro C. Pignataro
Cisco Cisco
Y. Fan Y. Fan
China Telecom China Telecom
Expires: July 2013 January 11, 2013 Expires: September 2013 March 30, 2013
Encapsulating MPLS in UDP Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-00 draft-ietf-mpls-in-udp-01
Abstract Abstract
Existing technologies to encapsulate Multi-Protocol Label Switching Existing technologies to encapsulate Multi-Protocol Label Switching
(MPLS) over IP are not adequate for efficient load balancing of MPLS (MPLS) over IP are not adequate for efficient load balancing of MPLS
application traffic, such as MPLS-based Layer2 Virtual Private application traffic, such as MPLS-based Layer2 Virtual Private
Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic
across IP networks. This document specifies additional IP-based across IP networks. This document specifies additional IP-based
encapsulation technology, referred to as MPLS-in-User Datagram encapsulation technology, referred to as MPLS-in-User Datagram
Protocol (UDP), which can facilitate the load balancing of MPLS Protocol (UDP), which can facilitate the load balancing of MPLS
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 30, 2013.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 11, 2013.
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 4, line 29 skipping to change at page 4, line 29
above can be utilized directly without requiring any change to them. above can be utilized directly without requiring any change to them.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4364] and [RFC4664]. This memo makes use of the terms defined in [RFC4364] and [RFC4664].
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 0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum | | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MPLS Label Stack ~ ~ MPLS Label Stack ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 9 skipping to change at page 5, line 9
Source Port of UDP Source Port of UDP
This field contains an entropy value that is generated This field contains an entropy value that is generated
by the ingress PE router. For example, the entropy value by the ingress PE router. For example, the entropy value
can be generated by performing hash calculation on can be generated by performing hash calculation on
certain fields in the customer packets (e.g., the five certain fields in the customer packets (e.g., the five
tuple of UDP/TCP packets). tuple of UDP/TCP packets).
Destination Port of UDP Destination Port of UDP
This field is set to a value (TBD) indicating the MPLS This field is set to a value (TBD) indicating the top
packet encapsulated in the UDP header is a MPLS one or a label of the MPLS label stack encapsulated in the UDP
MPLS one with upstream-assigned label. header is MPLS or MPLS with upstream-assigned label.
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. current UDP specification.
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. To simplify the operation on
egress PE routers, this field is recommended to be set egress PE routers, this field is RECOMMENDED to be set
to zero. to zero in IPv4 UDP encapsulation case, and even in IPv6
UDP encapsulation case if appropriate[UDPCHECKSUMS]
[UDPZERO].
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 the
UDP header. UDP header. As such, P routers, upon receiving these UDP
encapsulated packets, could balance these packets based on the hash
P routers, upon receiving these UDP encapsulated packets, could of the five-tuple of UDP packets.
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
procedures defined in [RFC4023] which are applicable for MPLS-in-IP procedures defined in [RFC4023] which are applicable for MPLS-in-IP
and MPLS-in-GRE encapsulation formats SHOULD be followed. and MPLS-in-GRE encapsulation formats SHOULD be followed.
5. Applicability 5. Applicability
Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762] Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762]
[E-VPN] applications, MPLS-in-UDP encapsulation could apply to other applications, MPLS-in-UDP encapsulation could apply to other MPLS
MPLS applications including but not limited to 6PE [RFC4798] and applications including but not limited to 6PE [RFC4798] and PWE3
PWE3 services. services.
6. Security Considerations 6. Security Considerations
Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the
MPLS-in-UDP encapsulation format defined in this document by itself MPLS-in-UDP encapsulation format defined in this document by itself
cannot ensure the integrity and privacy of data packets being cannot ensure the integrity and privacy of data packets being
transported through the MPLS-in-UDP tunnels and cannot enable the transported through the MPLS-in-UDP tunnels and cannot enable the
tunnel decapsulators to authenticate the tunnel encapsulator. In the tunnel decapsulators to authenticate the tunnel encapsulator. In the
case where any of the above security issues is concerned, the MPLS- case where any of the above security issues is concerned, the MPLS-
in-UDP tunnels SHOULD be secured with IPsec in transport mode. In in-UDP tunnels SHOULD be secured with IPsec in transport mode. In
skipping to change at page 8, line 13 skipping to change at page 8, line 13
2007. 2007.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007. 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-00.txt, work in progress, February, 2012.
[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.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. [UDPCHECKSUMS] Eubanks, M., Chimento, P., and M. Westerlund, "UDP
Westerlund, "UDP Checksums for Tunneled Packets", Checksums for Tunneled Packets", draft-ietf-6man-
draft-ietf-6man-udpchecksums-04 (work in progress), udpchecksums-08 (work in progress), February 2013.
September 2012.
[I-D.ietf-6man-udpzero] Fairhurst, G. and M. Westerlund, [UDPZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement
"Applicability Statement for the use of IPv6 UDP Datagrams for the use of IPv6 UDP Datagrams with Zero Checksums",
with Zero Checksums", draft-ietf-6man-udpzero-07 (work in draft-ietf-6man-udpzero-12 (work in progress), February
progress), October 2012. 2013.
[IP-in-UDP] Xu, etc, "Encapsulating IP in UDP", draft-xu-softwire-
ip-in-udp-01 (work in progress), February 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
Contrail Systems Juniper Networks
Email: nsheth@contrailsystems.com 1194 N. Mathilda Ave
Sunnyvale, CA 94089
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
 End of changes. 14 change blocks. 
39 lines changed or deleted 33 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/