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