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

The information below is for an old version of the document
Document Type Active Internet-Draft (mpls WG)
Last updated 2014-01-16 (latest revision 2013-12-11)
Replaces draft-xu-mpls-in-udp
Stream IETF
Intended RFC status Proposed Standard
Formats pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Ross Callon
Shepherd write-up Show (last changed 2013-10-10)
IESG IESG state Waiting for AD Go-Ahead::Revised I-D Needed
Consensus Boilerplate Unknown
Telechat date
Responsible AD Adrian Farrel
Send notices to mpls-chairs@tools.ietf.org, draft-ietf-mpls-in-udp@tools.ietf.org
IANA IANA review state IANA - Not OK
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: June 2014                                   December 12, 2013 
                                                                                
                                      
                         Encapsulating MPLS in UDP  
                                      
                         draft-ietf-mpls-in-udp-04 

Abstract 

   This document specifies an IP-based encapsulation for MPLS, called 
   MPLS-in-UDP (User Datagram Protocol). 

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 June 12, 2014. 

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

 

Xu, et al.              Expires June 12, 2014                 [Page 1] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   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 ....................................... 6 
   5. Congestion Considerations ................................... 6 
   6. Security Considerations ..................................... 7 
   7. IANA Considerations ......................................... 8 
   8. Contributors ................................................ 8 
   9. Acknowledgements ............................................ 9 
   10. References ................................................. 9 
      10.1. Normative References .................................. 9 
      10.2. Informative References ................................ 9 
   Authors' Addresses ............................................ 10 

 
 

Xu, et al.              Expires June 12, 2014                 [Page 2] 


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

   This document specifies an IP-based encapsulation for MPLS, i.e. 
   MPLS-in-UDP (User Datagram Protocol), which is applicable in some 
   circumstances where IP-based encapsulation for MPLS is required and 
   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. 

   Like other IP-based encapsulation methods 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. 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. 

   Similarly, 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. Therefore, in the case where any of the above 
   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 

   Currently, there are several IP-based encapsulations for MPLS such 
   as 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 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 3] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   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 
   Key and the L2TPv3 Session ID respectively) can be used as the 
   load-balancing key as described in [RFC5640]. For this, core 
   routers need to understand these fields in the context of being 
   used as load-balancing keys.  

1.2. Motivations for MPLS-in-UDP Encapsulation 

   Currently, most existing routers in IP networks are already capable 
   of distributing IP traffic "microflows" [RFC2474] over ECMPs 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). By encapsulating the MPLS packets into an UDP 
   tunnel and using the source port of the UDP header as an entropy 
   field, the existing load-balancing capability as mentioned above 
   can be leveraged to provide fine-grained 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                          ~ 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 4] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

            Source Port of UDP 

                This field contains a 16-bit entropy value that is 
                generated by the ingress PE router. What algorithm is 
                actually used by the ingress PE router to generate an 
                entropy value is outside the scope of this doc. In the 
                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 

                This field is set to a value allocated by  
                IANA) indicating that the UDP tunnel payload is an MPLS 
                packet using MPLS-in-UDP (TBD1).  

            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 [RFC768]. To simplify the 
                operation on egress PE routers, this field is 
                RECOMMENDED to be set to zero in IPv4 UDP encapsulation 
                case. In the IPv6 UDP encapsulation case, if 
                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 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 5] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
                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. The Destination Port field is set to a value (TBD1 
   for MPLS-in-UDP or TBD2 for MPLS-in-UDP with DTLS) allocated by 
   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 
   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 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 6] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   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. 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 

   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 or DTLS. If the tunnel is 
   secured with IPsec, 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. If DTLS is used, the destination 
   port of the UDP header will be filled with a value (TBD2) 
   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. 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 7] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
7. IANA Considerations 

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

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

   Zhenbin Li 
   Huawei Technologies, 
   Beijing, China 
   Phone: +86-10-60613676 
   Email: lizhenbin@huawei.com 
    

 
 
Xu, et al.              Expires June 12, 2014                 [Page 8] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
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 and suggestions on this document. Thanks to Daniel King, 
   Gregory Mirsky and Eric Osborne for their valuable reviews on this 
   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.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. 

   [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 
             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. 
             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. 

 
 
Xu, et al.              Expires June 12, 2014                 [Page 9] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   [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. 

   [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The           
             Locator/ID Separation Protocol (LISP)", RFC 6830,               
             January 2013. 

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

 
 
Xu, et al.              Expires June 12, 2014                [Page 10] 


Internet-Draft          Encapsulating MPLS in UDP         December 2013 
 
   Email: cpignata@cisco.com 

   Yongbing Fan  
   China Telecom  
   Guangzhou, China.  
   Phone: +86 20 38639121  
   Email: fanyb@gsta.com 

Xu, et al.              Expires June 12, 2014                [Page 11]