idnits 2.17.1 draft-xu-mpls-in-udp-03.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 date (October 8, 2012) is 4211 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 119, but not defined == Unused Reference: 'RFC6391' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 304, 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) == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-00 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 Z. Li 7 Huawei 8 N. Sheth 9 Juniper 10 Y. Fan 11 China Telecom 13 Expires: April 2013 October 8, 2012 15 Encapsulating MPLS in UDP 17 draft-xu-mpls-in-udp-03 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 8, 2013. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Abstract 56 This document specifies one additional IP-based encapsulation 57 technology for MPLS packets referred to as MPLS-in-UDP, which is 58 intended to facilitate load-balancing the traffic of various MPLS 59 applications such as MPLS-based L2VPN and L3VPN in the core of IP- 60 enabled packet switch networks. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119 [RFC2119]. 68 Table of Contents 70 1. Introduction ................................................ 3 71 2. Terminology ................................................. 4 72 3. Encapsulation in UDP ........................................ 4 73 4. Signaling for Encapsulation in UDP .......................... 5 74 5. Processing Functions ........................................ 5 75 6. Applicability ............................................... 6 76 7. Security Considerations ..................................... 6 77 8. IANA Considerations ......................................... 6 78 9. Acknowledgements ............................................ 7 79 10. References ................................................. 7 80 10.1. Normative References .................................. 7 81 10.2. Informative References ................................ 7 82 Authors' Addresses ............................................. 8 84 1. Introduction 86 Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are 87 widely used in the core of IP-enabled Packet Switch Networks (PSN) 88 for load-balancing purposes. Most core routers (i.e., P routers) in 89 the IP-enabled PSN are capable of load-balancing IP traffic flows 90 across ECMP paths and/or LAG based on the hash of the five-tuple of 91 UDP/TCP packets (i.e., source IP address, destination IP address, 92 source port, destination port, and protocol) or some fields in the 93 IP header of non-UDP/TCP packets (e.g., source IP address, 94 destination IP address). However, with existing IP-based 95 encapsulation methods as defined in [RFC4023] (e.g., MPLS-in-IP and 96 MPLS-in-GRE), distinct customer traffic flows of various MPLS 97 applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE 98 pair would be encapsulated with the same IP or GRE tunnel header 99 prior to traversing the IP core. Since the encapsulating traffic is 100 neither TCP nor UDP traffic, core routers could only perform hash 101 calculation on the fields in the IP header of IP or GRE tunnels. As 102 a result, core routers could not achieve an effective load-balancing 103 for these traffic flows in the network due to the lack of adequate 104 entropy information. In most service providers' backbones, MPLS 105 forwarding capability is enabled by default and therefore the 106 deployment of IP-based encapsulation method for MPLS packets (e.g., 107 MPLS-in-IP and MPLS-in-GRE) is not popular. As a result, the above 108 load-balancing issue is unweighted. However, in most cloud data 109 center network environments, data center operators tend to enable IP 110 forwarding capability, rather than MPLS forwarding capability in the 111 underlying data center networks due to certain reasons. In case 112 MPLS-based L2VPN or L3VPN technology are adopted as a scalable data 113 center network solution to support multi-tenancy in such 114 environments, IP-based encapsulation method for MPLS packets would 115 have to be used and therefore the above load-balancing issue would 116 become significant. 118 [RFC5640] describes a method for improving the load-balancing in 119 Softwire mesh networks [RFC5565]. However, this method requires core 120 routers to be able to perform hash calculation on the fields 121 including the "load-balancing" field contained in the L2TPv3 or GRE 122 tunnel header. [Entropy-Label] proposes to use the "entropy labels" 123 for achieving a better load-balancing for MPLS traffic flows in the 124 core of MPLS-enabled PSN. Although the entropy label could be 125 inserted in the "Key" field of the GRE header by ingress PE routers 126 in the case where the PSN is IP enabled rather than MPLS enabled, it 127 still requires core routers to be capable of performing hash 128 calculation on the "entropy label" contained in the GRE tunnel 129 header. Any of the above load-balancing methods requires a change to 130 the date plane of core routers. 132 This document describes a new IP-based encapsulation method for MPLS 133 packets referred to as MPLS-in-UDP, which is intended to facilitate 134 load-balancing the traffic of various MPLS applications such as 135 MPLS-based L2VPN and L3VPN in the core of IP-enabled packet switch 136 networks where the core routers could not be upgraded due to some 137 reason. 139 2. Terminology 141 This memo makes use of the terms defined in [RFC4364] and [RFC4664]. 143 3. Encapsulation in UDP 145 MPLS-in-IP messages have the following format: 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Source Port = entropy | Dest Port = MPLS | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | UDP Length | UDP Checksum | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 ~ MPLS Packet ~ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Source Port of UDP 161 This field contains an entropy value that is generated 162 by the ingress PE router. For example, the entropy value 163 can be generated by performing hash calculation on 164 certain fields in the customer packets (e.g., the five 165 tuple of UDP/TCP packets). To ensure that the source 166 port number is always in the range 49152 to 65535 which 167 may be required in some cases, instead of calculating a 168 16-bit hash, the ingress PE router could calculate a 14- 169 bit hash and use those 14 bits as the least significant 170 bits of the source port field while the most significant 171 two bits would be set to binary 11. That still conveys 172 14 bits of entropy information which would be enough as 173 well in practice. 175 Destination Port of UDP 176 This field is set to a value (TBD) indicating the MPLS 177 packet encapsulated in the UDP header is a MPLS unicast 178 one or a MPLS multicast one. 180 UDP Length 182 The usage of this field is in accordance with the 183 current UDP specification. 185 UDP Checksum 187 The usage of this field is in accordance with the 188 current UDP specification. To simplify the operation on 189 egress PE router, this field is recommended to be set to 190 zero. 192 4. Signaling for Encapsulation in UDP 194 PE routers could signal the UDP tunnel encapsulation information 195 among them by some means. 197 In the case when BGP is used in the MPLS applications (e.g., 198 BGP/MPLS IP VPN [RFC4364]), the MPLS-in-UDP encapsulation 199 information can be signaled by using the mechanism defined in [RFC 200 5512]. In this case, a new Tunnel Type code for UDP tunnel 201 technology needs to be assigned by IANA. If there is no explicit 202 encapsulation information to signal using the Encapsulation SAFI for 203 the UDP tunneling protocol, a BGP Encapsulation Extended Community 204 with the Tunnel Type set to the value indicating UDP tunneling 205 protocol would be enough. For example, such extended community could 206 be attached to the update messages for NLRI announcement in the 207 BGP/MPLS IP VPN case, or be attached to the update messages 208 dedicated for auto-discovery in the VPLS [RFC4761, RFC4762] case 209 where BGP-based auto-discovery is used. Otherwise, if more detailed 210 information about the UDP tunnel technology is needed for signaling 211 (e.g., to specify what MPLS application is allowed to use this MPLS- 212 in-UDP encapsulation), a new TLV and even a set of sub-TLVs 213 dedicated for UDP tunnel encapsulation technology that would be 214 contained in the Tunnel Encapsulation attribute needs to be defined. 216 More details about how to signal the MPLS-in-UDP encapsulation 217 information will be described in a separate document. 219 5. Processing Functions 221 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 222 through "IP UDP tunnels". When performing MPLS-in-UDP encapsulation 223 by an ingress PE router, the entropy value would be generated by the 224 ingress PE router and then be filled in the Source Port field of the 225 UDP header. 227 P routers, upon receiving these UDP encapsulated packets, could 228 balance these packets based on the hash of the five-tuple of UDP 229 packets. 231 Upon receiving these UDP encapsulated packets, egress PE routers 232 would decapsulate them by removing the UDP headers and then process 233 them accordingly. 235 6. Applicability 237 Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762] 238 [E-VPN] applications, MPLS-in-UDP encapsulation could also be used 239 in other MPLS applications including but not limited to 6PE [RFC4798] 240 and PWE3 services. 242 7. Security Considerations 244 Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the 245 MPLS-in-UDP encapsulation format defined in this document by itself 246 cannot ensure the integrity and privacy of data packets being 247 transported through the MPLS-in-UDP tunnels and cannot enable the 248 tunnel decapsulators to authenticate the tunnel encapsulator. In the 249 case where any of the above security issues is concerned, the MPLS- 250 in-UDP tunnels SHOULD be secured with IPsec in transport mode. In 251 this way, the UDP header would not be seeable to P routers anymore. 252 As a result, the meaning of adopting MPLS-in-UDP encapsulation 253 format as an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation 254 formats is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be 255 used only in the scenarios where all the security issues as 256 mentioned above are not significant concerns. For example, in a data 257 center environment, the whole network including P routers and PE 258 routers are under the control of a single administrative entity and 259 therefore there is no need to worry about the above security issues. 261 8. IANA Considerations 263 Two distinct UDP destination port numbers indicating MPLS and MPLS 264 with upstream-assigned label respectively need to be assigned by 265 IANA. 267 9. Acknowledgements 269 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 270 Eric Rosen, Kireeti Kompella, Weiguo Hao, Zhenxiao Liu and Xing Tong 271 for their valuable comments on the idea of MPLS-in-UDP encapsulation. 273 10. References 275 10.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 10.2. Informative References 282 [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private 283 Networks (VPNs)", RFC 4364, February 2006. 285 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 286 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 288 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 289 MPLS in IP or GRE", RFC4023, March 2005. 291 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 292 Balancing for Mesh Softwires", RFC 5640, August 2009. 294 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 295 J., and S. Amante, "Flow Aware Transport of Pseudowires 296 over an MPLS Packet Switched Network", RFC6391, November 297 2011 299 [Entropy-Label] Kompella, K., Drake, J., Amante, S., Henderickx, W., 300 and L. Yong, "The Use of Entropy Labels in MPLS 301 Forwarding", draft-ietf-mpls-entropy-label-01, work in 302 progress, October, 2011. 304 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 305 Subsequent Address Family Identifier (SAFI) and the 306 BGP Tunnel Encapsulation Attribute", RFC 5512, April 307 2009. 309 [RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS 310 using IPv6 Provider Edge Routers (6PE)", RFC4798, February 311 2007. 313 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 314 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 315 4761, January 2007. 317 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 318 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 319 RFC 4762, January 2007. 321 [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 322 l2vpn-evpn-00.txt, work in progress, February, 2012. 324 Authors' Addresses 326 Xiaohu Xu 327 Huawei Technologies, 328 Beijing, China 330 Phone: +86-10-60610041 331 Email: xuxiaohu@huawei.com 333 Marshall Eubanks 334 AmericaFree.TV LLC 335 P.O. Box 141 336 Clifton, Virginia 20124 337 USA 339 Phone: +1-703-501-4376 340 Email: marshall.eubanks@gmail.com 342 Lucy Yong 343 Huawei USA 344 1700 Alma Dr. Suite 500 345 Plano, TX 75075 346 US 348 Email: lucyyong@huawei.com 350 Nischal Sheth 351 Juniper Networks 352 1194 North Mathilda Avenue 353 Sunnyvale, CA 94089 USA 355 Email: nsheth@juniper.net 356 Zhenbin Li 357 Huawei Technologies, 358 Beijing, China 360 Phone: +86-10-60613676 361 Email: lizhenbin@huawei.com 363 Yongbing Fan 364 China Telecom 365 Guangzhou, China. 367 Phone: +86 20 38639121 368 Email: fanyb@gsta.com