idnits 2.17.1 draft-xu-mpls-in-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 28, 2012) is 4381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5565' is mentioned on line 102, but not defined == Unused Reference: 'RFC6391' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 259, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-entropy-label-01 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 2 Internet Draft Huawei 3 Category: Standard Track M. Eubanks 4 AmericaFree.TV 5 L. Yong 6 Huawei USA 8 Expires: October 2012 April 28, 2012 10 Encapsulating MPLS in UDP 12 draft-xu-mpls-in-udp-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 28, 2012. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. 49 Abstract 51 This document specifies one additional IP-based encapsulation 52 technology for MPLS packets referred to as MPLS-in-UDP, which is 53 intended to facilitate load-balancing the traffic of various MPLS 54 applications such as MPLS-based L2VPN and L3VPN in the core of IP- 55 enabled packet switch networks. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [RFC2119]. 63 Table of Contents 65 1. Introduction ................................................ 3 66 2. Terminology ................................................. 3 67 3. Encapsulation in UDP ........................................ 4 68 4. Signaling for Encapsulation in UDP .......................... 4 69 5. Processing Functions ........................................ 5 70 6. Applicability ............................................... 5 71 7. Security Considerations ..................................... 5 72 8. IANA Considerations ......................................... 6 73 9. Acknowledgements ............................................ 6 74 10. References ................................................. 6 75 10.1. Normative References .................................. 6 76 10.2. Informative References ................................ 6 77 Authors' Addresses ............................................. 7 79 1. Introduction 81 Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are 82 widely used in the core of IP-enabled Packet Switch Networks (PSN) 83 for load-balancing purposes. Most core routers (i.e., P routers) in 84 the IP-enabled PSN are capable of load-balancing IP traffic flows 85 across ECMP paths and/or LAG based on the hash of the five-tuple of 86 UDP/TCP packets (i.e., source IP address, destination IP address, 87 source port, destination port, and protocol) or some fields in the 88 IP header of non-UDP/TCP packets (e.g., source IP address, 89 destination IP address). However, with existing IP-based 90 encapsulation methods as defined in [RFC4023] such as MPLS-in-IP and 91 MPLS-in-GRE, distinct customer traffic flows of various MPLS 92 applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE 93 pair would be encapsulated with the same IP or GRE tunnel header 94 prior to traversing the core. Since the encapsulating traffic is 95 neither TCP nor UDP traffic, core routers could only perform hash 96 calculation on the fields in the IP header of IP or GRE tunnels. As 97 a result, core routers could not achieve an effective load-balancing 98 for these traffic flows in the network due to the lack of adequate 99 entropy information. 101 [RFC5640] describes a method for improving the load-balancing in 102 Softwire mesh networks [RFC5565]. However, this method requires core 103 routers to be able to perform hash calculation on the fields 104 including the "load-balancing" field contained in the L2TPv3 or GRE 105 tunnel header. [Entropy-Label] proposes to use the "entropy labels" 106 for achieving a better load-balancing for MPLS traffic flows in the 107 core of MPLS-enabled packet switching networks (PSN). Although the 108 entropy label could be inserted in the "Key" field of the GRE header 109 by ingress PE routers in the case where the PSN is IP enabled rather 110 than MPLS enabled, it still requires core routers to be capable of 111 performing hash calculation on the "entropy label" contained in the 112 GRE tunnel header. Any of the above load-balancing methods requires 113 a change to the date plane of core routers. 115 This document describes a new IP-based encapsulation method for MPLS 116 packets referred to as MPLS-in-UDP, which is intended to facilitate 117 load-balancing the traffic of various MPLS applications such as 118 MPLS-based L2VPN and L3VPN in the core of IP-enabled packet switch 119 networks where the core routers could not be upgraded due to some 120 reason. 122 2. Terminology 124 This memo makes use of the terms defined in [RFC4364] and [RFC4664]. 126 3. Encapsulation in UDP 128 MPLS-in-IP messages have the following format: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Source Port = entropy | Dest Port = MPLS | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | UDP Length | UDP Checksum | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 ~ MPLS Packet ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Source Port of UDP 144 This field contains an entropy value that is generated 145 by the ingress PE router. For example, the entropy value 146 can be generated by performing hash calculation on 147 certain fields in the customer packets (e.g., the five 148 tuple of UDP/TCP packets). 150 Destination Port of UDP 152 This field is set to a value (TBD) indicating the MPLS 153 packet encapsulated in the UDP header is a MPLS unicast 154 one or a MPLS multicast one. 156 UDP Length 158 The usage of this field is in accordance with the 159 current UDP specification. 161 UDP Checksum 163 The usage of this field is in accordance with the 164 current UDP specification. To simplify the operation on 165 egress PE router, this field is recommended to be set to 166 zero. 168 4. Signaling for Encapsulation in UDP 170 PE routers could signal the UDP tunnel encapsulation information 171 among them by some means. 173 In the case when BGP is used in the MPLS applications (e.g., 174 BGP/MPLS IP VPN [RFC4364]), the MPLS-in-UDP encapsulation 175 information can be signaled by using the mechanism defined in [RFC 176 5512]. In this case, a new Tunnel Type code for UDP tunnel 177 technology needs to be assigned by IANA. If there is no explicit 178 encapsulation information to signal using the Encapsulation SAFI for 179 the UDP tunneling protocol, a BGP Encapsulation Extended Community 180 with the Tunnel Type set to the value indicating UDP tunneling 181 protocol would be enough. Otherwise, if more detailed information 182 about the UDP tunnel technology (e.g., to specify what MPLS 183 application is allowed to use this MPLS-in-UDP encapsulation) is 184 needed for signaling, a new TLV and a set of sub-TLVs dedicated for 185 UDP tunnel technology contained in the Tunnel Encapsulation 186 attribute needs to be defined. 188 More details about how to signal the MPLS-in-UDP encapsulation 189 information will be described in a separate document. 191 5. Processing Functions 193 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 194 through "IP UDP tunnels". When performing MPLS-in-UDP encapsulation 195 by an ingress PE router, the entropy value would be generated by the 196 ingress PE router and then be filled in the Source Port field of the 197 UDP header. Then the ingress PE router inserts the remote PE's IP 198 address in the destination IP field and its own IP address in the 199 source IP field prior to forwarding the packet. 201 P routers could perform load-balancing for these UDP packets based 202 on the hash of the five-tuple. 204 Upon receiving these UDP packets, egress PE routers would 205 decapsulate them by removing the UDP headers and then process them 206 accordingly. 208 6. Applicability 210 Besides the MPLS-based L2VPN or L3VPN applications, MPLS-in-UDP 211 encapsulation could also be used by other MPLS applications such as 212 6PE [RFC4798]. 214 7. Security Considerations 216 TBD. 218 8. IANA Considerations 220 Two distinct UDP destination port numbers indicating MPLS unicast 221 and MPLS multicast respectively need to be assigned by IANA. 223 9. Acknowledgements 225 Thanks to Shane Amante and Dino Farinacci for their valuable 226 comments on the idea of MPLS-in-UDP encapsulation. 228 10. References 230 10.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 10.2. Informative References 237 [RFC4364] Rosen. E and Y. Rekhter, "BGP/MPLS IP Virtual Private 238 Networks (VPNs)", RFC 4364, February 2006. 240 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 241 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 243 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 244 MPLS in IP or GRE", RFC4023, March 2005. 246 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 247 Balancing for Mesh Softwires", RFC 5640, August 2009. 249 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 250 J., and S. Amante, "Flow Aware Transport of Pseudowires 251 over an MPLS Packet Switched Network", RFC6391, November 252 2011 254 [Entropy-Label] Kompella, K., Drake, J., Amante, S., Henderickx, W., 255 and L. Yong, "The Use of Entropy Labels in MPLS 256 Forwarding", draft-ietf-mpls-entropy-label-01, work in 257 progress, October, 2011. 259 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 260 Subsequent Address Family Identifier (SAFI) and the 261 BGP Tunnel Encapsulation Attribute", RFC 5512, April 262 2009. 264 [RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS 265 using IPv6 Provider Edge Routers (6PE)", RFC4798, February 266 2007. 268 Authors' Addresses 270 Xiaohu Xu 271 Huawei Technologies, 272 Beijing, China 274 Phone: +86-10-60610041 275 Email: xuxiaohu@huawei.com 277 Marshall Eubanks 278 AmericaFree.TV LLC 279 P.O. Box 141 280 Clifton, Virginia 20124 281 USA 283 Phone: +1-703-501-4376 284 Fax: 285 Email: marshall.eubanks@gmail.com 287 Lucy Yong 288 Huawei USA 289 1700 Alma Dr. Suite 500 290 Plano, TX 75075 291 US 293 Email: lucyyong@huawei.com