Skip to main content

Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7510.
Authors Xiaohu Xu , Nischal Sheth , Lucy Yong , Carlos Pignataro , Fan Yongbing
Last updated 2013-10-12 (Latest revision 2013-09-08)
Replaces draft-xu-mpls-in-udp
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestone
Jun 2015
++ Progress draft-ietf-mpls-in-udp to publication
Document shepherd Ross Callon
Shepherd write-up Show Last changed 2013-10-10
IESG IESG state Became RFC 7510 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Adrian Farrel
Send notices to mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org
draft-ietf-mpls-in-udp-03
Network working group                                            X. Xu 
Internet Draft                                                  Huawei 
Category: Standard Track                                      N. Sheth 
                                                               Juniper          
                                                               L. Yong 
                                                                Huawei 
                                                          C. Pignataro 
                                                                 Cisco 
                                                                Y. Fan 
                                                         China Telecom  
                                                                               
Expires: March 2014                                  September 9, 2013 
                                                                                
                                      
                         Encapsulating MPLS in UDP  
                                      
                         draft-ietf-mpls-in-udp-03 

Abstract 

   This document specifies an additional IP-based encapsulation for 
   MPLS, referred to as MPLS-in-UDP (User Datagram Protocol), which is 
   applicable in some circumstances. This document only describes the 
   MPLS-in-UDP encapsulation. 

Status of this Memo 

   This Internet-Draft is submitted in full conformance with the   
   provisions of BCP 78 and BCP 79.  

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF).  Note that other groups may also distribute   
   working documents as Internet-Drafts.  The list of current Internet-   
   Drafts is at http://datatracker.ietf.org/drafts/current/. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   This Internet-Draft will expire on March 9, 2014. 

 
 
 
Xu, et al.              Expires March 9, 2014                 [Page 1] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
Copyright Notice 

   Copyright (c) 2013 IETF Trust and the persons identified as the   
   document authors.  All rights reserved.  

   This document is subject to BCP 78 and the IETF Trust's Legal   
   Provisions Relating to IETF Documents   
   (http://trustee.ietf.org/license-info) in effect on the date of   
   publication of this document.  Please review these documents   
   carefully, as they describe your rights and restrictions with respect 
   to this document.  Code Components extracted from this document must 
   include Simplified BSD License text as described in Section 4.e of 
   the Trust Legal Provisions and are provided without warranty as 
   described in the Simplified BSD License.

Table of Contents 

   1. Introduction ................................................ 3 
      1.1. Existing Encapsulations ................................ 3 
      1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4 
   2. Terminology ................................................. 4 
   3. Encapsulation in UDP......................................... 4 
   4. Processing Procedures ....................................... 5 
   5. Congestion Considerations ................................... 6 
   6. Security Considerations ..................................... 6 
   7. IANA Considerations ......................................... 6 
   8. Contributors ................................................ 7 
   9. Acknowledgements ............................................ 7 
   10. References ................................................. 7 
      10.1. Normative References .................................. 7 
      10.2. Informative References ................................ 8 
   Authors' Addresses ............................................. 8 

 
 
Xu, et al.              Expires March 9, 2014                 [Page 2] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
    
1. Introduction 

   This document specifies an additional IP-based encapsulation for 
   MPLS, referred to as MPLS-in-UDP (User Datagram Protocol). It also 
   describes the applicability of this encapsulation in presence of 
   other IP-based encapsulations for MPLS. 

   This encapsulation allows for two Label Switching Routers (LSR) to 
   be adjacent on a Label Switched Path (LSP), while separated by an 
   IP network. In order to support this encapsulation, each LSR needs 
   to know the capability to decapsulate MPLS-in-UDP by the remote 
   LSRs. This specification defines only the data plane encapsulation 
   and does not concern itself with how the knowledge to use this 
   encapsulation is conveyed. 

   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). 

1.1. Existing Encapsulations 

   Currently, there are a number of IP-based encapsulations for MPLS. 
   These include MPLS-in-IP, MPLS-in- GRE (Generic Routing 
   Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling 
   Protocol - Version 3)[RFC4817]. In all these methods, the IP 
   addresses can be varied to achieve load-balancing. 

   All these IP-based encapsulations for MPLS are specified for both 
   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].  

 
 
Xu, et al.              Expires March 9, 2014                 [Page 3] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
1.2. Motivations for MPLS-in-UDP Encapsulation 

   Currently, many existing routers in IP networks are already capable 
   of distributing IP traffic "microflows" [RFC2474] 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). 

   The motivation of MPLS-in-UDP is to leverage this existing 
   capability to provide load-balancing of MPLS traffic over IP 
   networks. 

2. Terminology 

   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 

   MPLS-in-UDP encapsulation format is shown as follows: 

   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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Source Port = Entropy      |       Dest Port = MPLS        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           UDP Length          |        UDP Checksum           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~                       MPLS Label Stack                        ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
   |                                                               | 
   ~                         Message Body                          ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

            Source Port of UDP 

                This field contains a 16-bit entropy value that is 
                generated by the ingress PE router. For example, the 
                entropy value can be generated by performing hash 
                calculation on certain fields in the customer packets 
                (e.g., the five tuple of UDP/TCP packets).         

 
 
Xu, et al.              Expires March 9, 2014                 [Page 4] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
            Destination Port of UDP 

                This field is set to a value (TBD) indicating that the 
                UDP tunnel payload is a 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. 

            UDP Length 

                The usage of this field is in accordance with the 
                current UDP specification [RFC768]. 

            UDP Checksum  

                The usage of this field is in accordance with the 
                current UDP specification. To simplify the operation on 
                egress PE routers, this field is RECOMMENDED to be set 
                to zero in IPv4 UDP encapsulation case, and also in 
                IPv6 UDP encapsulation case if appropriate [RFC6935] 
                [RFC6936].  

            MPLS Label Stack 

                This field contains an MPLS Label Stack as defined in            
                [RFC3032]. 

            Message Body 

                This field contains one MPLS message body. 

4. Processing Procedures   

   This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 
   through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 
   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 UDP header. 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.  

 
 
Xu, et al.              Expires March 9, 2014                 [Page 5] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
   Upon receiving these UDP encapsulated packets, egress PE routers 
   would decapsulate them by removing the UDP headers and then process 
   them accordingly. 

   As for other common processing procedures associated with tunneling 
   encapsulation technologies including but not limited to Maximum 
   Transmission Unit (MTU) and preventing fragmentation and reassembly, 
   Time to Live (TTL) and differentiated services, the corresponding 
   "Common Procedures" defined in [RFC4023] which are applicable for 
   MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed.  

5. Congestion Considerations 

   MPLS can carry a number of different protocols as payloads. When an 
   MPLS/UDP flow carries IP-based traffic, the aggregate traffic is 
   assumed to be TCP friendly due to the congestion control mechanisms 
   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 

   Just like other IP-based encapsulations of MPLS, the MPLS-in-UDP 
   encapsulation format defined in this document by itself cannot 
   ensure the integrity and privacy of data packets being transported 
   through the MPLS-in-UDP tunnels and cannot enable the tunnel 
   decapsulators to authenticate the tunnel encapsulator. In the case 
   where any of the above security issues is concerned, the MPLS-in-
   UDP tunnels SHOULD be secured with IPsec in transport mode. In this 
   way, the UDP header would not be visible to P routers anymore. As a 
   result, the meaning of adopting MPLS-in-UDP encapsulation format as 
   an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats 
   is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be used 
   only in the scenarios where all the security issues as mentioned 
   above are not significant concerns.  

7. IANA Considerations 

   One UDP destination port number indicating MPLS needs to be 
   allocated by IANA. 

     Service Name : MPLS-in-UDP 

 
 
Xu, et al.              Expires March 9, 2014                 [Page 6] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
     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, 
   Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 
   George Swallow, Loa Andersson, Ross Callon, Vivek Kumar, Weiguo Hao, 
   Mark Szczesniak, Zhenxiao Liu and Xing Tong for their valuable  
   comments andsuggestions on this document. Thanks to Daniel King,  
   Gregory Mirsky and Eric Osborne for their valuable reviews on this
   document. 
    
10. References 

10.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate               
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,              
             August 1980.

   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,             
             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack             
             Encoding", RFC 3032, January 2001.   

 
 

Xu, et al.              Expires March 9, 2014                 [Page 7] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
10.2. Informative References 

   [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 
             MPLS in IP or GRE", RFC4023, March 2005. 
   
   [RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J. 
             Young, "Encapsulation of MPLS over Layer 2 Tunneling 
             Protocol Version 3, March 2007. 

   [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
             Balancing for Mesh Softwires", RFC 5640, August 2009. 

   [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP 
             Checksums for Tunneled Packets", RFC6935,              
             Feburary 2013. 

   [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 
             for the use of IPv6 UDP Datagrams with Zero Checksums", 
             RFC6936, Feburary 2013. 

   [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 
             "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 

   Xiaohu Xu 
   Huawei Technologies 
   Beijing, China 
   Phone: +86-10-60610041 
   Email: xuxiaohu@huawei.com 
    
   Nischal Sheth 
   Juniper Networks 
   1194 N. Mathilda Ave 
   Sunnyvale, CA 94089 
   Email: nsheth@juniper.net 

 
Xu, et al.              Expires March 9, 2014                 [Page 8] 


Internet-Draft          Encapsulating MPLS in UDP        September 2013 
 
   Lucy Yong
   Huawei USA 
   5340 Legacy Dr. 
   Plano TX75025 
   Phone: 469-277-5837 
   Email: Lucy.yong@huawei.com 
    
   Carlos Pignataro 
   Cisco Systems 7200-12 Kit Creek Road 
   Research Triangle Park, NC 27709 
   USA 
   Email: cpignata@cisco.com 
    
   Yongbing Fan  
   China Telecom  
   Guangzhou, China.  
   Phone: +86 20 38639121  
   Email: fanyb@gsta.com 

Xu, et al.              Expires March 9, 2014                 [Page 9]