idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 7) being 108 lines 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 11, 2013) is 4120 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 441, but no explicit reference was found in the text == Unused Reference: 'RFC6391' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-udpchecksums' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-udpzero' is defined on line 519, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) -- No information found for draft-ietf- - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 3 Internet Draft Huawei 5 Category: Standard Track N. Sheth 7 Contrail Systems 9 L. Yong 11 Huawei 13 C Pignataro 15 Cisco 17 Y. Fan 19 China Telecom 21 Expires: July 2013 January 11, 2013 23 Encapsulating MPLS in UDP 25 draft-ietf-mpls-in-udp-00 27 Abstract 29 Existing technologies to encapsulate Multi-Protocol Label Switching 31 (MPLS) over IP are not adequate for efficient load balancing of MPLS 33 application traffic, such as MPLS-based Layer2 Virtual Private 35 Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic 37 across IP networks. This document specifies additional IP-based 39 encapsulation technology, referred to as MPLS-in-User Datagram 41 Protocol (UDP), which can facilitate the load balancing of MPLS 43 application traffic across IP networks. 45 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt. 64 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 This Internet-Draft will expire on July 11, 2013. 70 Copyright Notice 72 Copyright (c) 2013 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [RFC2119]. 93 Table of Contents 95 1. Introduction ................................................ 3 97 1.1. Existing Technologies .................................. 3 99 1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4 101 2. Terminology ................................................. 4 103 3. Encapsulation in UDP......................................... 4 105 4. Processing Procedures ....................................... 5 107 5. Applicability ............................................... 6 109 6. Security Considerations ..................................... 6 111 7. IANA Considerations ......................................... 6 113 8. Acknowledgements ............................................ 6 115 9. References .................................................. 7 117 9.1. Normative References ................................... 7 119 9.2. Informative References ................................. 7 121 Authors' Addresses ............................................. 8 123 1. Introduction 125 To fully utilize the bandwidth available in IP networks and/or 127 facilitate recovery from a link or node failure, load balancing of 129 traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation 131 Group (LAG) across IP networks is widely used. In effect, most 133 existing core routers in IP networks are already capable of 135 distributing IP traffic flows over ECMP paths and/or LAG based on 137 the hash of the five-tuple of User Datagram Protocol (UDP)[RFC768] 139 and Transmission Control Protocol (TCP) packets (i.e., source IP 141 address, destination IP address, source port, destination port, and 143 protocol). 145 In practice, there are some scenarios for Multi-Protocol Label 147 Switching (MPLS) applications (e.g., MPLS-based Layer2 Virtual 149 Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN)) 151 where the MPLS application traffic needs to be transported through 153 IP-based tunnels, rather than MPLS tunnels. For example, MPLS-based 155 L2VPN or L3VPN technologies may be used for interconnecting 157 geographically dispersed enterprise data centers or branch offices 159 across IP Wide Area Networks (WAN) where enterprise own router 161 devices are deployed as L2VPN or L3VPN Provider Edge (PE) routers. 163 In this case, efficient load balancing of the MPLS application 165 traffic across IP networks is much desirable. 167 1.1. Existing Technologies 169 With existing IP-based encapsulation methods for MPLS applications, 171 such as MPLS-in-IP and MPLS-in-Generic Routing Encapsulation (GRE) 173 [RFC4023] or even MPLS-in-Layer Two Tunneling Protocol - Version 3 175 (L2TPv3)[RFC4817], distinct customer traffic flows between a given 177 PE router pair would be encapsulated with the same IP-based tunnel 179 headers prior to traversing the core of the IP WAN. Since the 181 encapsulated traffic is neither TCP nor UDP traffic, for many 183 existing core routers which could only perform hash calculation on 185 fields in the IP headers of those tunnels (i.e., source IP address, 187 destination IP address), it would be hard to achieve a fine-grained 189 load balancing of these traffic flows across the network core due to 191 the lack of adequate entropy information. 193 [RFC5640] describes a method for improving the load balancing 195 efficiency in a network carrying Softwire Mesh service over L2TPv3 197 and GRE encapsulation. However, this method requires core routers to 199 be capable of performing hash calculation on the "load-balancing" 201 field contained in the tunnel encapsulation headers (i.e., the 203 Session ID field in the L2TPv3 header or the Key field in the GRE 204 header), which means a non-trivial change to the date plane of many 206 existing core routers. 208 1.2. Motivations for MPLS-in-UDP Encapsulation 210 On basis of the fact that most existing core routers (i.e., P 212 routers in the context of MPLS-based L2VPN or L3VPN) are already 214 capable of balancing IP traffic flows over the IP networks based on 216 the hash of the five-tuple of UDP packets, it would be advantageous 218 to use MPLS-in-UDP encapsulation instead of MPLS-in-GRE or MPLS-in- 220 L2TPv3 in the environments where the load balancing of MPLS 222 application traffic across IP networks is much desired but the load 224 balancing mechanisms defined in [RFC5640] have not yet been widely 226 supported by most existing core routers. In this way, the default 228 load balancing capability of most existing core routers as mentioned 230 above can be utilized directly without requiring any change to them. 232 2. Terminology 234 This memo makes use of the terms defined in [RFC4364] and [RFC4664]. 236 3. Encapsulation in UDP 238 MPLS-in-UDP encapsulation format is shown as follows: 240 0 1 2 242 3 244 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Source Port = entropy | Dest Port = MPLS | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | UDP Length | UDP Checksum | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 258 ~ MPLS Label Stack ~ 260 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 266 ~ Message Body ~ 268 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Source Port of UDP 274 This field contains an entropy value that is generated 276 by the ingress PE router. For example, the entropy value 278 can be generated by performing hash calculation on 279 certain fields in the customer packets (e.g., the five 281 tuple of UDP/TCP packets). 283 Destination Port of UDP 285 This field is set to a value (TBD) indicating the MPLS 287 packet encapsulated in the UDP header is a MPLS one or a 289 MPLS one with upstream-assigned label. 291 UDP Length 293 The usage of this field is in accordance with the 295 current UDP specification. 297 UDP Checksum 299 The usage of this field is in accordance with the 301 current UDP specification. To simplify the operation on 303 egress PE routers, this field is recommended to be set 305 to zero. 307 MPLS Label Stack 309 This field contains an MPLS Label Stack as defined in 311 [RFC3032]. 313 Message Body 315 This field contains one MPLS message body. 317 4. Processing Procedures 319 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 321 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 323 an ingress PE router, the entropy value would be generated by the 325 ingress PE router and then be filled in the Source Port field of the 327 UDP header. 329 P routers, upon receiving these UDP encapsulated packets, could 331 balance these packets based on the hash of the five-tuple of UDP 333 packets. 335 Upon receiving these UDP encapsulated packets, egress PE routers 337 would decapsulate them by removing the UDP headers and then process 339 them accordingly. 341 As for other common processing procedures associated with tunneling 343 encapsulation technologies including but not limited to Maximum 345 Transmission Unit (MTU) and preventing fragmentation and reassembly, 347 Time to Live (TTL) and differentiated services, the corresponding 349 procedures defined in [RFC4023] which are applicable for MPLS-in-IP 351 and MPLS-in-GRE encapsulation formats SHOULD be followed. 353 5. Applicability 355 Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762] 357 [E-VPN] applications, MPLS-in-UDP encapsulation could apply to other 359 MPLS applications including but not limited to 6PE [RFC4798] and 361 PWE3 services. 363 6. Security Considerations 365 Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the 367 MPLS-in-UDP encapsulation format defined in this document by itself 369 cannot ensure the integrity and privacy of data packets being 371 transported through the MPLS-in-UDP tunnels and cannot enable the 373 tunnel decapsulators to authenticate the tunnel encapsulator. In the 375 case where any of the above security issues is concerned, the MPLS- 377 in-UDP tunnels SHOULD be secured with IPsec in transport mode. In 379 this way, the UDP header would not be seeable to P routers anymore. 381 As a result, the meaning of adopting MPLS-in-UDP encapsulation 383 format as an alternative to MPLS-in-GRE and MPLS-in-IP encapsulation 385 formats is lost. Hence, MPLS-in-UDP encapsulation format SHOULD be 387 used only in the scenarios where all the security issues as 389 mentioned above are not significant concerns. For example, in a data 391 center environment, the whole network including P routers and PE 393 routers are under the control of a single administrative entity and 395 therefore there is no need to worry about the above security issues. 397 7. IANA Considerations 399 Two distinct UDP destination port numbers indicating MPLS and MPLS 401 with upstream-assigned label respectively need to be assigned by 403 IANA. 405 8. Acknowledgements 407 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 409 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 411 Vivek Kumar, Weiguo Hao, Zhenxiao Liu and Xing Tong for their 413 valuable comments on the idea of MPLS-in-UDP encapsulation. Thanks 415 to Daniel King, Gregory Mirsky and Eric Osborne for their valuable 417 reviews on this draft. 419 9. References 421 9.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 9.2. Informative References 429 [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private 431 Networks (VPNs)", RFC 4364, February 2006. 433 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 435 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 437 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 439 MPLS in IP or GRE", RFC4023, March 2005. 441 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 443 Multicast Encapsulations", RFC 5332, August 2008. 445 [RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J. 447 Young, "Encapsulation of MPLS over Layer 2 Tunneling 449 Protocol Version 3, March 2007. 451 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 453 Balancing for Mesh Softwires", RFC 5640, August 2009. 455 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 457 J., and S. Amante, "Flow Aware Transport of Pseudowires 459 over an MPLS Packet Switched Network", RFC6391, November 461 2011 463 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 465 Yong, "The Use of Entropy Labels in MPLS Forwarding", 467 draft-ietf-mpls-entropy-label-01, work in progress, 469 October, 2011. 471 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 473 Subsequent Address Family Identifier (SAFI) and the 475 BGP Tunnel Encapsulation Attribute", RFC 5512, April 477 2009. 479 [RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS 481 using IPv6 Provider Edge Routers (6PE)", RFC4798, February 483 2007. 485 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 487 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 489 4761, January 2007. 491 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 493 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 495 RFC 4762, January 2007. 497 [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 499 l2vpn-evpn-00.txt, work in progress, February, 2012. 501 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 503 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 505 Encoding", RFC 3032, January 2001. 507 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 509 August 1980. 511 [I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. 513 Westerlund, "UDP Checksums for Tunneled Packets", 515 draft-ietf-6man-udpchecksums-04 (work in progress), 517 September 2012. 519 [I-D.ietf-6man-udpzero] Fairhurst, G. and M. Westerlund, 521 "Applicability Statement for the use of IPv6 UDP Datagrams 523 with Zero Checksums", draft-ietf-6man-udpzero-07 (work in 525 progress), October 2012. 527 Authors' Addresses 529 Xiaohu Xu 531 Huawei Technologies, 533 Beijing, China 535 Phone: +86-10-60610041 537 Email: xuxiaohu@huawei.com 539 Nischal Sheth 541 Contrail Systems 543 Email: nsheth@contrailsystems.com 545 Lucy Yong 547 Huawei USA 549 5340 Legacy Dr. 551 Plano TX75025 553 Phone: 469-277-5837 555 Email: Lucy.yong@huawei.com 556 Carlos Pignataro 558 Cisco Systems 560 7200-12 Kit Creek Road 562 Research Triangle Park, NC 27709 564 USA 566 EMail: cpignata@cisco.com 568 Yongbing Fan 570 China Telecom 572 Guangzhou, China. 574 Phone: +86 20 38639121 576 Email: fanyb@gsta.com 578 Zhenbin Li 580 Huawei Technologies, 582 Beijing, China 584 Phone: +86-10-60613676 586 Email: lizhenbin@huawei.com