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