idnits 2.17.1 draft-ietf-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 date (March 30, 2013) is 4044 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) == Unused Reference: 'RFC5332' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC6391' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'IP-in-UDP' is defined on line 341, 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 (-03) exists of draft-xu-softwire-ip-in-udp-01 Summary: 0 errors (**), 0 flaws (~~), 8 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 N. Sheth 4 Juniper 5 L. Yong 6 Huawei 7 C. Pignataro 8 Cisco 9 Y. Fan 10 China Telecom 12 Expires: September 2013 March 30, 2013 14 Encapsulating MPLS in UDP 16 draft-ietf-mpls-in-udp-01 18 Abstract 20 Existing technologies to encapsulate Multi-Protocol Label Switching 21 (MPLS) over IP are not adequate for efficient load balancing of MPLS 22 application traffic, such as MPLS-based Layer2 Virtual Private 23 Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic 24 across IP networks. This document specifies additional IP-based 25 encapsulation technology, referred to as MPLS-in-User Datagram 26 Protocol (UDP), which can facilitate the load balancing of MPLS 27 application traffic across IP networks. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 30, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [RFC2119]. 67 Table of Contents 69 1. Introduction ................................................ 3 70 1.1. Existing Technologies .................................. 3 71 1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4 72 2. Terminology ................................................. 4 73 3. Encapsulation in UDP......................................... 4 74 4. Processing Procedures ....................................... 5 75 5. Applicability ............................................... 6 76 6. Security Considerations ..................................... 6 77 7. IANA Considerations ......................................... 6 78 8. Acknowledgements ............................................ 6 79 9. References .................................................. 7 80 9.1. Normative References ................................... 7 81 9.2. Informative References ................................. 7 82 Authors' Addresses ............................................. 8 84 1. Introduction 86 To fully utilize the bandwidth available in IP networks and/or 87 facilitate recovery from a link or node failure, load balancing of 88 traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation 89 Group (LAG) across IP networks is widely used. In effect, most 90 existing core routers in IP networks are already capable of 91 distributing IP traffic flows over ECMP paths and/or LAG based on 92 the hash of the five-tuple of User Datagram Protocol (UDP)[RFC768] 93 and Transmission Control Protocol (TCP) packets (i.e., source IP 94 address, destination IP address, source port, destination port, and 95 protocol). 97 In practice, there are some scenarios for Multi-Protocol Label 98 Switching (MPLS) applications (e.g., MPLS-based Layer2 Virtual 99 Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN)) 100 where the MPLS application traffic needs to be transported through 101 IP-based tunnels, rather than MPLS tunnels. For example, MPLS-based 102 L2VPN or L3VPN technologies may be used for interconnecting 103 geographically dispersed enterprise data centers or branch offices 104 across IP Wide Area Networks (WAN) where enterprise own router 105 devices are deployed as L2VPN or L3VPN Provider Edge (PE) routers. 106 In this case, efficient load balancing of the MPLS application 107 traffic across IP networks is much desirable. 109 1.1. Existing Technologies 111 With existing IP-based encapsulation methods for MPLS applications, 112 such as MPLS-in-IP and MPLS-in-Generic Routing Encapsulation (GRE) 113 [RFC4023] or even MPLS-in-Layer Two Tunneling Protocol - Version 3 114 (L2TPv3)[RFC4817], distinct customer traffic flows between a given 115 PE router pair would be encapsulated with the same IP-based tunnel 116 headers prior to traversing the core of the IP WAN. Since the 117 encapsulated traffic is neither TCP nor UDP traffic, for many 118 existing core routers which could only perform hash calculation on 119 fields in the IP headers of those tunnels (i.e., source IP address, 120 destination IP address), it would be hard to achieve a fine-grained 121 load balancing of these traffic flows across the network core due to 122 the lack of adequate entropy information. 124 [RFC5640] describes a method for improving the load balancing 125 efficiency in a network carrying Softwire Mesh service over L2TPv3 126 and GRE encapsulation. However, this method requires core routers to 127 be capable of performing hash calculation on the "load-balancing" 128 field contained in the tunnel encapsulation headers (i.e., the 129 Session ID field in the L2TPv3 header or the Key field in the GRE 130 header), which means a non-trivial change to the date plane of many 131 existing core routers. 133 1.2. Motivations for MPLS-in-UDP Encapsulation 135 On basis of the fact that most existing core routers (i.e., P 136 routers in the context of MPLS-based L2VPN or L3VPN) are already 137 capable of balancing IP traffic flows over the IP networks based on 138 the hash of the five-tuple of UDP packets, it would be advantageous 139 to use MPLS-in-UDP encapsulation instead of MPLS-in-GRE or MPLS-in- 140 L2TPv3 in the environments where the load balancing of MPLS 141 application traffic across IP networks is much desired but the load 142 balancing mechanisms defined in [RFC5640] have not yet been widely 143 supported by most existing core routers. In this way, the default 144 load balancing capability of most existing core routers as mentioned 145 above can be utilized directly without requiring any change to them. 147 2. Terminology 149 This memo makes use of the terms defined in [RFC4364] and [RFC4664]. 151 3. Encapsulation in UDP 153 MPLS-in-UDP encapsulation format is shown as follows: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Source Port = entropy | Dest Port = MPLS | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | UDP Length | UDP Checksum | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ~ MPLS Label Stack ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 ~ Message Body ~ 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Source Port of UDP 173 This field contains an entropy value that is generated 174 by the ingress PE router. For example, the entropy value 175 can be generated by performing hash calculation on 176 certain fields in the customer packets (e.g., the five 177 tuple of UDP/TCP packets). 179 Destination Port of UDP 181 This field is set to a value (TBD) indicating the top 182 label of the MPLS label stack encapsulated in the UDP 183 header is MPLS or MPLS with upstream-assigned label. 185 UDP Length 187 The usage of this field is in accordance with the 188 current UDP specification. 190 UDP Checksum 192 The usage of this field is in accordance with the 193 current UDP specification. To simplify the operation on 194 egress PE routers, this field is RECOMMENDED to be set 195 to zero in IPv4 UDP encapsulation case, and even in IPv6 196 UDP encapsulation case if appropriate[UDPCHECKSUMS] 197 [UDPZERO]. 199 MPLS Label Stack 201 This field contains an MPLS Label Stack as defined in 202 [RFC3032]. 204 Message Body 206 This field contains one MPLS message body. 208 4. Processing Procedures 210 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 211 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 212 an ingress PE router, the entropy value would be generated by the 213 ingress PE router and then be filled in the Source Port field of the 214 UDP header. As such, P routers, upon receiving these UDP 215 encapsulated packets, could balance these packets based on the hash 216 of the five-tuple of UDP packets. 218 Upon receiving these UDP encapsulated packets, egress PE routers 219 would decapsulate them by removing the UDP headers and then process 220 them accordingly. 222 As for other common processing procedures associated with tunneling 223 encapsulation technologies including but not limited to Maximum 224 Transmission Unit (MTU) and preventing fragmentation and reassembly, 225 Time to Live (TTL) and differentiated services, the corresponding 226 procedures defined in [RFC4023] which are applicable for MPLS-in-IP 227 and MPLS-in-GRE encapsulation formats SHOULD be followed. 229 5. Applicability 231 Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762] 232 applications, MPLS-in-UDP encapsulation could apply to other MPLS 233 applications including but not limited to 6PE [RFC4798] and PWE3 234 services. 236 6. Security Considerations 238 Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the 239 MPLS-in-UDP encapsulation format defined in this document by itself 240 cannot ensure the integrity and privacy of data packets being 241 transported through the MPLS-in-UDP tunnels and cannot enable the 242 tunnel decapsulators to authenticate the tunnel encapsulator. In the 243 case where any of the above security issues is concerned, the MPLS- 244 in-UDP tunnels SHOULD be secured with IPsec in transport mode. In 245 this way, the UDP header would not be seeable to P routers anymore. 246 As a result, the meaning of adopting MPLS-in-UDP encapsulation 247 format as an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation 248 formats is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be 249 used only in the scenarios where all the security issues as 250 mentioned above are not significant concerns. For example, in a data 251 center environment, the whole network including P routers and PE 252 routers are under the control of a single administrative entity and 253 therefore there is no need to worry about the above security issues. 255 7. IANA Considerations 257 Two distinct UDP destination port numbers indicating MPLS and MPLS 258 with upstream-assigned label respectively need to be assigned by 259 IANA. 261 8. Acknowledgements 263 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 264 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 265 Vivek Kumar, Weiguo Hao, Zhenxiao Liu and Xing Tong for their 266 valuable comments on the idea of MPLS-in-UDP encapsulation. Thanks 267 to Daniel King, Gregory Mirsky and Eric Osborne for their valuable 268 reviews on this draft. 270 9. References 272 9.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 9.2. Informative References 279 [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private 280 Networks (VPNs)", RFC 4364, February 2006. 282 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 283 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 285 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 286 MPLS in IP or GRE", RFC4023, March 2005. 288 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 289 Multicast Encapsulations", RFC 5332, August 2008. 291 [RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J. 292 Young, "Encapsulation of MPLS over Layer 2 Tunneling 293 Protocol Version 3, March 2007. 295 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 296 Balancing for Mesh Softwires", RFC 5640, August 2009. 298 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 299 J., and S. Amante, "Flow Aware Transport of Pseudowires 300 over an MPLS Packet Switched Network", RFC6391, November 301 2011 303 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 304 Yong, "The Use of Entropy Labels in MPLS Forwarding", 305 draft-ietf-mpls-entropy-label-01, work in progress, 306 October, 2011. 308 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 309 Subsequent Address Family Identifier (SAFI) and the 310 BGP Tunnel Encapsulation Attribute", RFC 5512, April 311 2009. 313 [RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS 314 using IPv6 Provider Edge Routers (6PE)", RFC4798, February 315 2007. 317 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 318 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 319 4761, January 2007. 321 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 322 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 323 RFC 4762, January 2007. 325 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 326 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 327 Encoding", RFC 3032, January 2001. 329 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 330 August 1980. 332 [UDPCHECKSUMS] Eubanks, M., Chimento, P., and M. Westerlund, "UDP 333 Checksums for Tunneled Packets", draft-ietf-6man- 334 udpchecksums-08 (work in progress), February 2013. 336 [UDPZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement 337 for the use of IPv6 UDP Datagrams with Zero Checksums", 338 draft-ietf-6man-udpzero-12 (work in progress), February 339 2013. 341 [IP-in-UDP] Xu, etc, "Encapsulating IP in UDP", draft-xu-softwire- 342 ip-in-udp-01 (work in progress), February 2013. 344 Authors' Addresses 346 Xiaohu Xu 347 Huawei Technologies, 348 Beijing, China 349 Phone: +86-10-60610041 350 Email: xuxiaohu@huawei.com 352 Nischal Sheth 353 Juniper Networks 354 1194 N. Mathilda Ave 355 Sunnyvale, CA 94089 356 Email: nsheth@juniper.net 358 Lucy Yong 359 Huawei USA 360 5340 Legacy Dr. 361 Plano TX75025 362 Phone: 469-277-5837 363 Email: Lucy.yong@huawei.com 364 Carlos Pignataro 365 Cisco Systems 366 7200-12 Kit Creek Road 367 Research Triangle Park, NC 27709 368 USA 369 EMail: cpignata@cisco.com 371 Yongbing Fan 372 China Telecom 373 Guangzhou, China. 374 Phone: +86 20 38639121 375 Email: fanyb@gsta.com 377 Zhenbin Li 378 Huawei Technologies, 379 Beijing, China 380 Phone: +86-10-60613676 381 Email: lizhenbin@huawei.com