idnits 2.17.1 draft-wr-mptcp-single-homed-07.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 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 199: '... the client SHOULD create up to n vi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Winter 3 Internet-Draft NEC Laboratories Europe 4 Intended status: Informational M. Faath 5 Expires: September 22, 2016 University of Applied Sciences Augsburg 6 A. Ripke 7 NEC Laboratories Europe 8 March 21, 2016 10 Multipath TCP Support for Single-homed End-systems 11 draft-wr-mptcp-single-homed-07 13 Abstract 15 Multipath TCP relies on the existence of multiple paths between end- 16 systems. These are typically provided by using different IP 17 addresses obtained by different ISPs at the end-systems. While this 18 scenario is certainly becoming increasingly a reality (e.g. mobile 19 devices), currently most end-systems are single-homed (e.g. desktop 20 PCs in an enterprise). It seems also likely that a lot of network 21 sites will insist on having all traffic pass a single network element 22 (e.g. for security reasons) before traffic is split across multiple 23 paths. This memo therefore describes mechanisms to make multiple 24 paths available to multipath TCP-capable end-systems that are not 25 available directly at the end-systems but somewhere within the 26 network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 22, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Approaches to Use Multiple Paths in the Network . . . . . . . 3 64 2.1. Exposing Multiple Paths Through End-host Auto- 65 configuration . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Heuristic Use of Multiple Paths . . . . . . . . . . . . . 5 67 3. Other scenarios and extensions . . . . . . . . . . . . . . . 6 68 4. Alternative approaches . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The IETF has specified a multipath TCP (MPTCP) architecture and 80 protocol where end-systems operate a modified standard TCP stack 81 which allows packets of the same TCP connection to be sent via 82 different paths to an MPTCP-capable destination ([RFC6824], 83 [RFC6182]). Paths are defined by sets of source and destination IP 84 addresses. Using multiple paths has a number of benefits such as an 85 increased reliability of the transport connection and an effect known 86 as resource pooling [resource_pooling]. Most end-systems today do 87 not have multiple paths/interfaces available in order to make use of 88 multipath TCP, however further within the network multiple paths are 89 the norm rather than the exception. This memo therefore describes 90 ways how these multiple paths in the network could potentially be 91 made available to multipath TCP-capable hosts that are single-homed. 93 In order to illustrate the general mechanism we make use of a simple 94 reference scenario shown in Figure 1. 96 +-------+ 97 | DHCP | 98 +-------+ +----------+ Server| 99 | | | | | 100 | Host +------+ +-------+ 101 | | | +-------+ ISP 1 102 +-------+ +------+ |---------- 103 | Gatew.| 104 | |---------- 105 +-------+ ISP 2 107 Figure 1: Reference Scenario 109 The scenario in Figure 1 depicts e.g. a possible SOHO or enterprise 110 setup where a gateway/router is connected to two ISPs and a DHCP 111 server gives out leases to hosts connected to the local network. 112 Note that both, the gateway and the DHCP server could be on the same 113 device (similar to current home gateway implementations). Also, the 114 two ISPs could really be two different access technologies (e.g. LTE 115 and DSL) provided by a single ISP. 117 The host is running a multipath-capable IP stack, however it only has 118 a single interface. The methods described in the following sections 119 will let the host make use of the gateway's two interfaces without 120 requiring modifications to the MPTCP implementation. 122 2. Approaches to Use Multiple Paths in the Network 124 All approaches in this document do not require changes to the wire 125 format of MPTCP and both communicating hosts need to be MPTCP- 126 capable. The benefit this approach has is that a) it has no 127 implications on MPTCP standards, b) it will hopefully encourage the 128 deployment of MPTCP as the number of scenarios where MPTCP brings 129 benefits vastly increases and c) these approaches do not require 130 complex middle-boxes to implement MPTCP-like functionality in the 131 network as other approaches have suggested before. 133 2.1. Exposing Multiple Paths Through End-host Auto-configuration 135 Multipath TCP distinguishes paths by their source and destination IP 136 addresses. Assuming a certain level of path diversity in the 137 Internet, using different source and destination IP addresses for a 138 given subflow of a multipath TCP connection will, with a certain 139 probability, result in different paths taken by packets of different 140 subflows. Even in case subflows share a common bottleneck, the 141 proposed multipath congestion control algorithm [RFC6356] will make 142 sure that multipath TCP will play nicely with regular TCP flows. 144 In order to not require changes to the TCP implementation, we keep 145 the above assumptions multipath TCP makes, i.e. working with 146 different IP addresses to use different paths. Since the end-system 147 is single-homed, all IP addresses are bound to the same physical 148 interface. In our reference scenario in Figure 1, the host would 149 e.g. receive more than one RFC1918 [RFC1918] private IP address from 150 the DHCP server as depicted in Figure 2. 152 Host Gateway 154 +-----------------+ ISP1 155 +--------+ | src. | 156 | virt. | 10.1.2.5 | 10.1.0.0/16 __.+---------- 157 | +---+ | __.--' | 158 | phys. | | | __.--' N | 159 | +----------+.:_ A | 160 | | 10.2.2.6 | `-.._ T | 161 +--------+ | src. `-.._ | ISP2 162 | 10.2.0.0/16 `-..+---------- 163 | | 164 +-----------------+ 166 Figure 2: Gateway internals 168 The gateway that is shown in Figure 2 has received two IP addresses, 169 one from each ISP that it is connected to (ISP1 and ISP2). The NAT 170 that the gateway is implementing needs to "map" each private IP 171 address of the host consistently to a one of the addresses received 172 by the ISPs, i.e. each private IP to a different public IP. Packets 173 sent by the host to the gateway are then routed based on the source 174 address found in the packets as illustrated in the figure. In other 175 words, depending on the source address of the host, the packets will 176 either go through ISP 1 or ISP 2 and TCP will balance the traffic 177 across those two links using its built-in congestion control 178 mechanism. 180 The way the gateway has received its public IP addresses is not 181 relevant. It could be via DHCP, IPCP or static configuration. In 182 order to configure the hosts behind the gateway, we propose to make 183 use of provisioning domains [RFC7556], more specifically one 184 provisioning domain per external gateway interface (the two 185 interfaces to ISP1 and ISP2 in Figure 2). The DHCPv6 specification 186 for encoding provisioning domains can be found in 187 [I-D.ietf-mif-mpvd-dhcp-support]. 189 In order to signal to the host, that each provisioning domain will 190 result in a different path towards the Internet, this memo introduces 191 a new DHCP option called EXT_ROUTE, which will be included in each 192 provisioning domain sent by the server. The option value will 193 determine which external interface is used to sent the traffic when 194 using the configuration information present in the respective 195 provisioning domain. 197 Upon receipt of a DHCP offer including multiple provisioning domains, 198 or multiple offers each including one or more provisioning domains, 199 the client SHOULD create up to n virtual interfaces, where n is one 200 less than the number of different EXT_ROUTE option values found in 201 all received provisioning domains. Each virtual interface will 202 contact the DHCP server and will request configuration information 203 for the respective provisioning domains, excluding the configuration 204 of the physical interface. 206 2.2. Heuristic Use of Multiple Paths 208 The auto-configuration mechanism above has the advantage that 209 available paths and information on how to use them are directly sent 210 to the end-host. In other words, there is an explicit signalling of 211 the availability of multiple paths to the end-host. This has the 212 advantage that the host can efficiently use these paths. 214 This method works well when multiple paths are available close to the 215 end-host and means for auto-configuration are available. But that is 216 not always the case. Another method to use different paths in the 217 network without prior knowledge of their existence is to apply 218 heuristics in order to exploit setups where Equal Cost Multi-path 219 [RFC2991], a widely deployed technology [ECMP_DEPLOYMENT], or similar 220 per-flow load-balancing algorithms are employed. 222 The ADD_ADDR option defined in [RFC6824] can be used to advertise the 223 same address but a different port to open another subflow. 224 Additionally, the MP_JOIN option can also be used to open another 225 subflow with the same IP address and e.g. a different source port 226 given that a different address ID is used. This means there are 227 multiple scenarios possible (e.g. either sender-initated or receiver- 228 initiated) where single-homed end-hosts can influence the 5-tuple 229 (source and destination IP addresses and port numbers plus protocol 230 number) which is often used as the basis for per-flow load balancing. 231 Changing the 5-tuple will only with a certain probability result in 232 using a different path unless the load-balancing algorithm that is 233 used is known to the MPTCP implementation (an assumption we cannot 234 generally make). This means that a number of subflows might end up 235 on the same path. Fortunately, the MPTCP congestion control 236 algorithm will make sure that the collection of subflows on that path 237 will not be more agressive than a single TPC flow. 239 3. Other scenarios and extensions 241 The reference scenario is only one conceivable setting. Other 242 scenarios such as DSL broadband customers or mobile phones are 243 conceivable as well. As an example, take the DSL scenario. The home 244 gateway could be provided with multiple IP addresses using extensions 245 to IPCP. The home gateway in turn can then implement the DHCP server 246 and gateway functionality as described before. More scenarios will 247 be described in future versions of this document. 249 4. Alternative approaches 251 One alternative is that a DHCP server always sends n offers, where n 252 is the number of interfaces at the gateway to different ISPs. The 253 client could then accept all or a subset of these offers. This 254 approach seems interesting in environments where there are multiple 255 DHCP servers, one for each ISP connection (think multiple home 256 gateways). However, accepting multiple offers based on a single DHCP 257 request is not standard's compliant behavior (at least for the DHCPv4 258 case). Also, to cater for a scenario that only contains a single 259 DHCP server, server changes are needed in any case. Finally, correct 260 routing is not always guaranteed in these scenarios. 262 An interesting alternative is the use of ECMP at the gateway for load 263 distribution and let MPTCP use different port numbers for subflows. 264 Assuming that ECMP is available at the gateway, this approach would 265 work fine today. The only drawback of the approach is that it 266 involves a little trial and error to find port numbers that actually 267 hash to different paths used by ECMP [RFC2991]. 269 5. Acknowledgements 271 Part of this work was supported by Trilogy (http://www.trilogy- 272 project.org), a research project (ICT-216372) partially funded by the 273 European Community under its Seventh Framework Program. The views 274 expressed here are those of the author(s) only. The European 275 Commission is not liable for any use that may be made of the 276 information in this document. 278 6. IANA Considerations 280 One new DHCP options is required by this version of this document. 282 7. Security Considerations 284 TBD. 286 8. References 288 8.1. Normative References 290 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 291 and E. Lear, "Address Allocation for Private Internets", 292 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 293 . 295 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 296 Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/ 297 RFC2991, November 2000, 298 . 300 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 301 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 302 . 304 8.2. Informative References 306 [ECMP_DEPLOYMENT] 307 Augustin, B., Friedman, T., and R. Teixeira, "Measuring 308 Multipath Routing in the Internet", October 2011, 309 . 311 [I-D.ietf-mif-mpvd-dhcp-support] 312 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 313 multiple provisioning domains in DHCPv6", draft-ietf-mif- 314 mpvd-dhcp-support-02 (work in progress), October 2015. 316 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 317 Iyengar, "Architectural Guidelines for Multipath TCP 318 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 319 . 321 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 322 Congestion Control for Multipath Transport Protocols", RFC 323 6356, DOI 10.17487/RFC6356, October 2011, 324 . 326 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 327 "TCP Extensions for Multipath Operation with Multiple 328 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 329 . 331 [resource_pooling] 332 Wischik, D., Handley, M., and M. Bagnulo Braun, "The 333 Resource Pooling Principle", October 2008, 334 . 336 Authors' Addresses 338 Rolf Winter 339 NEC Laboratories Europe 340 Kurfuersten-Anlage 36 341 Heidelberg 69115 342 Germany 344 Email: rolf.winter@neclab.eu 346 Michael Faath 347 University of Applied Sciences Augsburg 348 An der Hochschule 1 349 Augsburg 86161 350 Germany 352 Email: michael.faath@hs-augsburg.de 354 Andreas Ripke 355 NEC Laboratories Europe 356 Kurfuersten-Anlage 36 357 Heidelberg 69115 358 Germany 360 Email: andreas.ripke@neclab.eu