Encapsulating MPLS in UDP
draft-xu-mpls-in-udp-01

Network working group                                             X. Xu 
Internet Draft                                                   Huawei 
Category: Standard Track                                     M. Eubanks         
                                                         AmericaFree.TV 
                                                                L. Yong 
                                                             Huawei USA 
                                                          Nischal Sheth 
                                                                Juniper 
                                                                  Z. Li 
                                                                 Huawei        
Expires: November 2012                                     May 24, 2012 
                                                                                
                                      
                         Encapsulating MPLS in UDP  
                                      
                          draft-xu-mpls-in-udp-01 

Status of this Memo 

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

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

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

   The list of current Internet-Drafts can be accessed at   
   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 November 24, 2012. 

Copyright Notice 

   Copyright (c) 2009 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 

 
 
 
Xu, et al.            Expires November 24, 2012               [Page 1] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
   (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.  

Abstract 

   This document specifies one additional IP-based encapsulation 
   technology for MPLS packets referred to as MPLS-in-UDP, which is 
   intended to facilitate load-balancing the traffic of various MPLS 
   applications such as MPLS-based L2VPN and L3VPN in the core of IP-
   enabled packet switch networks.  

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 

    
   1. Introduction ................................................ 3 
   2. Terminology ................................................. 3 
   3. Encapsulation in UDP ........................................ 4 
   4. Signaling for Encapsulation in UDP .......................... 5 
   5. Processing Functions......................................... 5 
   6. Applicability ............................................... 6 
   7. Security Considerations ..................................... 6 
   8. IANA Considerations ......................................... 6 
   9. Acknowledgements ............................................ 6 
   10. References ................................................. 6 
      10.1. Normative References .................................. 6 
      10.2. Informative References ................................ 6 
   Authors' Addresses ............................................. 7 

 
 
Xu, et al.            Expires November 24 2012                [Page 2] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
    
1. Introduction 

   Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are 
   widely used in the core of IP-enabled Packet Switch Networks (PSN) 
   for load-balancing purposes. Most core routers (i.e., P routers) in 
   the IP-enabled PSN are capable of load-balancing IP traffic flows 
   across ECMP paths and/or LAG based on the hash of the five-tuple of 
   UDP/TCP packets (i.e., source IP address, destination IP address, 
   source port, destination port, and protocol) or some fields in the 
   IP header of non-UDP/TCP packets (e.g., source IP address, 
   destination IP address). However, with existing IP-based 
   encapsulation methods as defined in [RFC4023] such as MPLS-in-IP and 
   MPLS-in-GRE, distinct customer traffic flows of various MPLS 
   applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE 
   pair would be encapsulated with the same IP or GRE tunnel header 
   prior to traversing the core. Since the encapsulating traffic is 
   neither TCP nor UDP traffic, core routers could only perform hash 
   calculation on the fields in the IP header of IP or GRE tunnels. As 
   a result, core routers could not achieve an effective load-balancing 
   for these traffic flows in the network due to the lack of adequate 
   entropy information.  

   [RFC5640] describes a method for improving the load-balancing in 
   Softwire mesh networks [RFC5565]. However, this method requires core 
   routers to be able to perform hash calculation on the fields 
   including the "load-balancing" field contained in the L2TPv3 or GRE 
   tunnel header. [Entropy-Label] proposes to use the "entropy labels" 
   for achieving a better load-balancing for MPLS traffic flows in the 
   core of MPLS-enabled PSN. Although the entropy label could be 
   inserted in the "Key" field of the GRE header by ingress PE routers 
   in the case where the PSN is IP enabled rather than MPLS enabled, it 
   still requires core routers to be capable of performing hash 
   calculation on the "entropy label" contained in the GRE tunnel 
   header. Any of the above load-balancing methods requires a change to 
   the date plane of core routers.  

   This document describes a new IP-based encapsulation method for MPLS 
   packets referred to as MPLS-in-UDP, which is intended to facilitate 
   load-balancing the traffic of various MPLS applications such as 
   MPLS-based L2VPN and L3VPN in the core of IP-enabled packet switch 
   networks where the core routers could not be upgraded due to some 
   reason.  

2. Terminology 

   This memo makes use of the terms defined in [RFC4364] and [RFC4664].  

 
 
Xu, et al.            Expires November 24 2012                [Page 3] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
3. Encapsulation in UDP 

   MPLS-in-IP messages have the following format: 

   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 Packet                           ~ 
   |                                                               |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           

            Source Port of UDP 

                This field contains an 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).  To ensure that the source 
                port number is always in the range 49152 to 65535 which 
                is required in some cases, instead of calculating a 16-
                bit hash, the ingress PE router would calculate a 14-bit 
                hash and use those 14 bits as the least significant bits 
                of the source port field while the most significant two 
                bits would be set to binary 11. That would still convey 
                14 bits of entropy information which is also enough in 
                practice.       

            Destination Port of UDP 

                This field is set to a value (TBD) indicating the MPLS 
                packet encapsulated in the UDP header is a MPLS unicast 
                one or a MPLS multicast one. 

            UDP Length 

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

            UDP Checksum        

                The usage of this field is in accordance with the 
                current UDP specification. To simplify the operation on 

 
 
Xu, et al.            Expires November 24 2012                [Page 4] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
                egress PE router, this field is recommended to be set to 
                zero.     

4. Signaling for Encapsulation in UDP 

   PE routers could signal the UDP tunnel encapsulation information 
   among them by some means.  

   In the case when BGP is used in the MPLS applications (e.g., 
   BGP/MPLS IP VPN [RFC4364]), the MPLS-in-UDP encapsulation 
   information can be signaled by using the mechanism defined in [RFC 
   5512]. In this case, a new Tunnel Type code for UDP tunnel 
   technology needs to be assigned by IANA. If there is no explicit 
   encapsulation information to signal using the Encapsulation SAFI for 
   the UDP tunneling protocol, a BGP Encapsulation Extended Community 
   with the Tunnel Type set to the value indicating UDP tunneling 
   protocol would be enough. For example, such extended community could 
   be attached to the update messages for NLRI announcement in the 
   BGP/MPLS IP VPN case, or be attached to the update messages 
   dedicated for auto-discovery in the VPLS [RFC4761, RFC4762] case 
   where BGP-based auto-discovery is used. Otherwise, if more detailed 
   information about the UDP tunnel technology (e.g., to specify what 
   MPLS application is allowed to use this MPLS-in-UDP encapsulation) 
   is needed for signaling or such tunnel encapsulation technology is 
   applicable to any MPLS applications, a new TLV and even a set of 
   sub-TLVs dedicated for UDP tunnel encapsulation technology contained 
   in the Tunnel Encapsulation attribute needs to be defined.  

   More details about how to signal the MPLS-in-UDP encapsulation 
   information will be described in a separate document. 

5. Processing Functions  

   This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 
   through "IP 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. Then the ingress PE router inserts the remote PE's IP 
   address in the destination IP field and its own IP address in the 
   source IP field prior to forwarding the packet. 

   P routers could perform load-balancing for these UDP packets based 
   on the hash of the five-tuple.  

   Upon receiving these UDP packets, egress PE routers would 
   decapsulate them by removing the UDP headers and then process them 
   accordingly. 

 
 
Xu, et al.            Expires November 24 2012                [Page 5] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
6. Applicability 

   Besides the MPLS-based L3VPN and L2VPN applications including VPLS 
   [RFC4761, RFC4762] and E-VPN[E-VPN], MPLS-in-UDP encapsulation could 
   also be used in other MPLS applications including but not limited to 
   6PE [RFC4798] and PWE3 services. 

7. Security Considerations 

   TBD. 

8. IANA Considerations 

   Two distinct UDP destination port numbers indicating MPLS unicast 
   and MPLS multicast respectively need to be assigned by IANA.  

9. Acknowledgements 

   Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 
   Weiguo Hao, Zhenxiao Liu and Xing Tong for their valuable comments 
   on the idea of MPLS-in-UDP encapsulation.  

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. 

   10.2. Informative References 

   [RFC4364] Rosen. E and Y. Rekhter, "BGP/MPLS IP Virtual Private              
             Networks (VPNs)", RFC 4364, February 2006. 

   [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer         
             2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 

   [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 
             MPLS in IP or GRE", RFC4023, March 2005. 

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

   [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,          
             J., and S. Amante, "Flow Aware Transport of Pseudowires            
             over an MPLS Packet Switched Network", RFC6391, November 
             2011 

 
 
Xu, et al.            Expires November 24 2012                [Page 6] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
   [Entropy-Label] Kompella, K., Drake, J., Amante, S., Henderickx, W., 
             and L. Yong, "The Use of Entropy Labels in MPLS 
             Forwarding", draft-ietf-mpls-entropy-label-01, work in 
             progress, October, 2011. 

   [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation                 
             Subsequent Address Family Identifier (SAFI) and the                
             BGP Tunnel Encapsulation Attribute", RFC 5512, April               
             2009. 

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

   [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-          
             l2vpn-evpn-00.txt, work in progress, February, 2012. 

Authors' Addresses 

   Xiaohu Xu 
   Huawei Technologies, 
   Beijing, China 
    
   Phone: +86-10-60610041 
   Email: xuxiaohu@huawei.com 
    
    
   Marshall Eubanks 
   AmericaFree.TV LLC 
   P.O. Box 141 
   Clifton, Virginia  20124 
   USA 
    
   Phone: +1-703-501-4376 
   Email: marshall.eubanks@gmail.com 
    
    
   Lucy Yong 
   Huawei USA 

 
 
Xu, et al.            Expires November 24 2012                [Page 7] 


Internet-Draft          Encapsulating MPLS in UDP              May 2012 
 
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   US

   Email: lucyyong@huawei.com

   Nischal Sheth
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA

   Email: nsheth@juniper.net

   Zhenbin Li
   Huawei Technologies,
   Beijing, China

   Phone: +86-10-60613676
   Email: lizhenbin@huawei.com

Xu, et al.            Expires November 24 2012                [Page 8]