idnits 2.17.1 draft-ietf-mpls-in-udp-02.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2013) is 3974 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 298, but no explicit reference was found in the text == Unused Reference: 'IP-in-UDP' is defined on line 328, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-xu-softwire-ip-in-udp-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: December 2013 June 9, 2013 14 Encapsulating MPLS in UDP 16 draft-ietf-mpls-in-udp-02 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 December 9, 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 the 92 hash of the five-tuple of User Datagram Protocol (UDP)[RFC768] and 93 Transmission Control Protocol (TCP) packets (i.e., source IP address, 94 destination IP address, source port, destination port, and protocol). 96 In practice, there are some scenarios for Multi-Protocol Label 97 Switching (MPLS) applications (e.g., MPLS-based Layer2 Virtual 98 Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN)) 99 where the MPLS application traffic needs to be transported through 100 IP-based tunnels, rather than MPLS tunnels. For example, MPLS-based 101 L2VPN or L3VPN technologies may be used for interconnecting 102 geographically dispersed enterprise data centers or branch offices 103 across IP Wide Area Networks (WAN) where enterprise own router 104 devices are deployed as L2VPN or L3VPN Provider Edge (PE) routers. In 105 this case, efficient load balancing of the MPLS application traffic 106 across IP networks is very desirable. 108 1.1. Existing Technologies 110 With existing IP-based encapsulation methods for MPLS applications, 111 such as MPLS-in-IP and MPLS-in-Generic Routing Encapsulation (GRE) 112 [RFC4023] or even MPLS-in-Layer Two Tunneling Protocol - Version 3 113 (L2TPv3)[RFC4817], distinct customer traffic flows between a given PE 114 router pair would be encapsulated with the same IP-based tunnel 115 headers prior to traversing the core of the IP WAN. Since the 116 encapsulated traffic is neither TCP nor UDP traffic, for many 117 existing core routers which could only perform hash calculation on 118 fields in the IP headers of those tunnels (i.e., source IP address, 119 destination IP address), it would be hard to achieve a fine-grained 120 load balancing of these traffic flows across the network core due to 121 the lack of adequate entropy information. 123 [RFC5640] describes a method for improving the load balancing 124 efficiency in a network carrying Softwire Mesh service over L2TPv3 125 and GRE encapsulation. However, this method requires core routers to 126 be capable of performing hash calculation on the "load-balancing" 127 field contained in the tunnel encapsulation headers (i.e., the 128 Session ID field in the L2TPv3 header or the Key field in the GRE 129 header), which means a non-trivial change to the date plane of many 130 existing core routers. 132 1.2. Motivations for MPLS-in-UDP Encapsulation 134 On basis of the fact that most existing core routers (i.e., P routers 135 in the context of MPLS-based L2VPN or L3VPN) are already capable of 136 balancing IP traffic flows over the IP networks based on the hash of 137 the five-tuple of UDP packets, it would be advantageous to use MPLS- 138 in-UDP encapsulation instead of MPLS-in-GRE or MPLS-in-L2TPv3 in the 139 environments where the load balancing of MPLS application traffic 140 across IP networks is much desired but the load balancing mechanisms 141 defined in [RFC5640] have not yet been widely supported by most 142 existing core routers. In this way, the default load balancing 143 capability of most existing core routers as mentioned above can be 144 utilized directly without requiring any change to them. 146 2. Terminology 148 This memo makes use of the terms defined in [RFC4364] and [RFC4664]. 150 3. Encapsulation in UDP 152 MPLS-in-UDP encapsulation format is shown as follows: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Source Port = Entropy | Dest Port = MPLS | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | UDP Length | UDP Checksum | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 ~ MPLS Label Stack ~ 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 ~ Message Body ~ 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Source Port of UDP 172 This field contains an entropy value that is generated by 173 the ingress PE router. For example, the entropy value can 174 be generated by performing hash calculation on certain 175 fields in the customer packets (e.g., the five tuple of 176 UDP/TCP packets). 178 Destination Port of UDP 180 This field is set to a value (TBD) indicating that the 181 UDP tunnel payload is a MPLS packet. As for whether the 182 top label in the MPLS label stack is downstream-assigned 183 or upstream-assigned, it SHOULD be determined based on 184 the tunnel destination IP address. That is to say, if the 185 destination IP address is a multicast address, the top 186 label SHOULD be upstream-assigned, otherwise if the 187 destination IP address is a unicast address, it SHOULD be 188 downstream-assigned. 190 UDP Length 192 The usage of this field is in accordance with the current 193 UDP specification. 195 UDP Checksum 197 The usage of this field is in accordance with the current 198 UDP specification. To simplify the operation on egress PE 199 routers, this field is RECOMMENDED to be set to zero in 200 IPv4 UDP encapsulation case, and even in IPv6 UDP 201 encapsulation case if appropriate[RFC6935][RFC6936]. 203 MPLS Label Stack 205 This field contains an MPLS Label Stack as defined in 206 [RFC3032]. 208 Message Body 210 This field contains one MPLS message body. 212 4. Processing Procedures 214 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 215 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 216 an ingress PE router, the entropy value would be generated by the 217 ingress PE router and then be filled in the Source Port field of the 218 UDP header. As such, P routers, upon receiving these UDP encapsulated 219 packets, could balance these packets based on the hash of the five- 220 tuple of UDP packets. 222 Upon receiving these UDP encapsulated packets, egress PE routers 223 would decapsulate them by removing the UDP headers and then process 224 them accordingly. 226 As for other common processing procedures associated with tunneling 227 encapsulation technologies including but not limited to Maximum 228 Transmission Unit (MTU) and preventing fragmentation and reassembly, 229 Time to Live (TTL) and differentiated services, the corresponding 230 procedures defined in [RFC4023] which are applicable for MPLS-in-IP 231 and MPLS-in-GRE encapsulation formats SHOULD be followed. 233 5. Applicability 235 Besides the MPLS-based L3VPN [RFC4364] and L2VPN [RFC4761, RFC4762] 236 applications, MPLS-in-UDP encapsulation could apply to other MPLS 237 applications including but not limited to 6PE [RFC4798] and PWE3 238 services. 240 6. Security Considerations 242 Just like MPLS-in-GRE and MPLS-in-IP encapsulation formats, the MPLS- 243 in-UDP encapsulation format defined in this document by itself cannot 244 ensure the integrity and privacy of data packets being transported 245 through the MPLS-in-UDP tunnels and cannot enable the tunnel 246 decapsulators to authenticate the tunnel encapsulator. In the case 247 where any of the above security issues is concerned, the MPLS-in-UDP 248 tunnels SHOULD be secured with IPsec in transport mode. In this way, 249 the UDP header would not be visible to P routers anymore. As a result, 250 the meaning of adopting MPLS-in-UDP encapsulation format as an 251 alternative to MPLS-in-GRE and MPLS-in-IP encapsulation formats is 252 lost. Hence, MPLS-in-UDP encapsulation format SHOULD be used only in 253 the scenarios where all the security issues as mentioned above are 254 not significant concerns. For example, in a data center environment, 255 the whole network including P routers and PE routers are under the 256 control of a single administrative entity and therefore there is no 257 need to worry about the above security issues. 259 7. IANA Considerations 261 One UDP destination port number indicating MPLS needs to be allocated 262 by IANA. 264 8. Acknowledgements 266 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 267 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 268 George Swallow, Loa Andersson, Ross Callon, Vivek Kumar, Weiguo Hao, 269 Zhenxiao Liu and Xing Tong for their valuable comments and 270 suggestions on this document. Thanks to Daniel King, Gregory Mirsky 271 and Eric Osborne for their valuable reviews on this document. 273 9. References 275 9.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 9.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 MPLS 289 in IP or GRE", RFC4023, March 2005. 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 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 299 Multicast Encapsulations", RFC 5332, August 2008. 301 [RFC4798] J Declerq et al., "Connecting IPv6 Islands over IPv4 MPLS 302 using IPv6 Provider Edge Routers (6PE)", RFC4798, February 303 2007. 305 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 306 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 307 4761, January 2007. 309 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 310 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 311 RFC 4762, January 2007. 313 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 314 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 315 Encoding", RFC 3032, January 2001. 317 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 318 August 1980. 320 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP 321 Checksums for Tunneled Packets", RFC6935, 322 Feburary 2013. 324 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 325 for the use of IPv6 UDP Datagrams with Zero Checksums", 326 RFC6936, Feburary 2013. 328 [IP-in-UDP] Xu, etc, "Encapsulating IP in UDP", draft-xu-softwire-ip- 329 in-udp-01 (work in progress), February 2013. 331 Authors' Addresses 333 Xiaohu Xu 334 Huawei Technologies 335 Beijing, China 336 Phone: +86-10-60610041 337 Email: xuxiaohu@huawei.com 339 Nischal Sheth 340 Juniper Networks 341 1194 N. Mathilda Ave 342 Sunnyvale, CA 94089 343 Email: nsheth@juniper.net 345 Lucy Yong 346 Huawei USA 347 5340 Legacy Dr. 348 Plano TX75025 349 Phone: 469-277-5837 350 Email: Lucy.yong@huawei.com 352 Carlos Pignataro 353 Cisco Systems 354 7200-12 Kit Creek Road 355 Research Triangle Park, NC 27709 356 USA 357 EMail: cpignata@cisco.com 359 Yongbing Fan 360 China Telecom 361 Guangzhou, China. 362 Phone: +86 20 38639121 363 Email: fanyb@gsta.com 364 Zhenbin Li 365 Huawei Technologies, 366 Beijing, China 367 Phone: +86-10-60613676 368 Email: lizhenbin@huawei.com