idnits 2.17.1 draft-deng-mptcp-proxy-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 (Oct 24, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6888' is mentioned on line 453, but not defined ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group L. Deng 3 INTERNET-DRAFT D. Liu 4 Intended Status: Informational T. Sun 5 Expires: May 25, 2014 China Mobile 6 M. Boucadair 7 France Telecom 8 G. Cauchie 9 Bouygues Telecom 10 Oct 24, 2014 12 Use-cases and Requirements for MPTCP Proxy in ISP Networks 13 draft-deng-mptcp-proxy-01 15 Abstract 17 This document presents the use-cases and identifies requirements for 18 ISP deployed MPTCP proxies for both Fixed and Mobile networks. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3 Use-cases for ISP MPTCP Proxy . . . . . . . . . . . . . . . . . 6 61 3.1 Boosting MPTCP Utilization for M-UEs and Multi-Interface 62 CPEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 Resource Pooling from Multiple Networks . . . . . . . . . . 7 64 3.3 Multiple Connections and Seamless Handover between 65 Multiple Networks . . . . . . . . . . . . . . . . . . . . . 7 66 3.4 Assist MTPCP Connection Establishment . . . . . . . . . . . 8 67 4 Deployment Considerations . . . . . . . . . . . . . . . . . . . 8 68 4.1 On-path MPTCP Proxy . . . . . . . . . . . . . . . . . . . . 9 69 4.2 Off-Path Proxy . . . . . . . . . . . . . . . . . . . . . . . 9 70 5 Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1 MPTCP Proxy at the ISP IP Gateway . . . . . . . . . . . . . 10 72 5.2 On-Path MPTCP Proxy at the ISP Data Center . . . . . . . . . 11 73 5.3 On-Path MPTCP Proxy at SmallCell Gateway . . . . . . . . . . 11 74 5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks . . . . . . 11 75 6 Requirements for MPTCP Proxy . . . . . . . . . . . . . . . . . 12 76 6.1 Protocol Proxying between MPTCP and TCP . . . . . . . . . . 12 77 6.2 Explicit Traffic Steering for Off-Path Proxying . . . . . . 12 78 6.3 Flexible Resource Policy within a Single ISP . . . . . . . 13 79 6.4 Protection against third-party traffic . . . . . . . . . . . 13 80 6.5 MPTCP Proxy Selection from Multiple Candidates . . . . . . . 14 81 6.6 Load Balancing Algorithm for Multiple Networks . . . . . . . 14 82 6.7 Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 84 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 85 9 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16 86 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 88 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1 Introduction 93 Internet Service Providers (ISPs) are challenged by the data 94 explosion occurring in their Fixed and/or Mobile networks. This data 95 explosion is triggered by new usages with the advent for resource- 96 demanding services. The emergence of these services is facilitated by 97 the emergence of new access technologies (FTTx in the Fixed or LTE in 98 the Mobile networks). Typical resource-demanding services are (HD) 99 video streaming or catchup IP-TV which are boosting more and more 100 every day the customers appetite for more IP bandwidth. 102 This pressure on continuous increase of network capacity poses a 103 challenge on the ISPs to appropriately plan, dimension and 104 dynamically provision their networks to satisfy customers 105 expectations. This problem is encountered by both Fixed and Mobile 106 Providers that have to cope with the scarcity of the radio frequency 107 resources, the limits of the already widely deployed DSL 108 infrastructure, or any in-place access technology. 110 The traditional trend that consist in upgrading the access technology 111 to a new generation technology may show some limits because of the 112 required upgrade cycles. Alternate deployment options to satisfy 113 customers' expectations and react rapidly to competition are of 114 interest of ISPs. A promising track, discussed in this document, is 115 to aggregate several connectivity links while eliminating risks to 116 experience application failures. 118 Indeed, a direction to answer to this problem is to make use of the 119 multiple interfaces that one terminal host maintains. For smartphones 120 or mobile dongles, these interfaces are typically a 3G/4G radio 121 access and a WLAN access, while for a residential CPE these 122 interfaces are typically a DSL line and a 3G/4G radio access. 124 3GPP initiated an effort to aggregate several radio resources for the 125 sake of increasing bit-rates (denoted as Carrier Aggregation (CA)). 126 Aggregation is achieved at the radio level by combining the set of 127 allocated contiguous or non-contiguous component carriers. This 128 extension requires modification at the radio interface level of the 129 UE (User Equipment), as well as some tuning on the network side. 130 Carrier Aggregation is specific to radio-based environments and, as 131 such, it is not convenient for other deployment cases, such as wired 132 networks. 134 Both 3GPP and IETF standard bodies have investigated different 135 solutions to make the best interface used for one application, with 136 potential use of multiple interfaces at the same time by 137 multitasking-enable terminals. As of today, none of them really did 138 meet a wide deployment and successful adoption. 140 The IETF released MPTCP specification [RFC6824], an experimental set 141 of TCP options allowing the use of parallel TCP connections, each 142 with different set of IP addresses and/or port numbers, to serve at 143 least one application. MPTCP is already available on some widely 144 adopted mobile handsets and on some Linux implementations. However, 145 MPTCP connections are pretty rare since the servers hosting the 146 applications are too few to offer MPTCP capability. 148 Because resources are scarce at the access segment, a solution to 149 enhance the quality of experience is to enable MPTCP at the access 150 segment without requiring MPTCP support at the server side (i.e., the 151 end-to-end MPTCP support is not required). Concretely, this can be 152 implemented owing to the deployment a dedicated function called MPTCP 153 Proxy at the ISP network side and/or in the CPE device. Note that 154 enabling an MPTCP Proxy in the CPE has the advantage to not require 155 MPTCP stack at the terminal side. 157 By this mean, an ISP can offer a higher bandwidth to its customers 158 when possible while not waiting for massive MPTCP adoption by the 159 Internet ecosystem. Furthermore, this technique would allow the ISP 160 and the customer to control the parts of the networks where potential 161 QoE degradation may be experienced and where the traffic can be 162 handled appropriately by means of traffic engineering tweaking for 163 instance. Since MPTCP requires a load-sharing algorithm to schedule 164 the TCP subflow to which the traffic is forwarded, the selection of 165 the proper algorithm could help for instance to offload the IP 166 traffic towards the legacy Fixed networks while taking advantage of 167 the complementary bandwidth only when needed/selected by the 168 customers, application, or the ISP. 170 Note that the use of MPTCP at customer side can be of different 171 natures as defined in MTPCP base specification: 173 o Native MPTCP: Two MPTCP endpoints establish and make use of all 174 subflows that correspond to the available addresses/port numbers. 175 This mode is enabled to optimize data throughput. 177 o Active/Backup MPTCP: Two MPTCP endpoints enable multiple 178 subflows, but only a subset of these subflows is actually in use for 179 data transfer. MPTCP endpoints can use the MP_PRIO signal to change 180 the priority for each subflow. 182 o Single subflow MPTCP: Two MPTCP endpoints use one single subflow 183 and when a failure is observed, an additional subflow is enabled so 184 that traffic is forwarded along the newly established subflow. 186 Based on the basic capabilities of an MPTCP-enabled host, various 187 deployment use cases can be considered by an ISP. Examples of such 188 use cases include: traffic handover among multiple WLAN hotspots, 189 traffic offload from a mobile network to WLAN or vice visa, and 190 access link aggregation. 192 In general, two flavors of MPTCP Proxy can be envisaged , see Figure 193 1: 195 o A MPTCP Proxy that maps a UE originated TCP connection into an 196 MPTCP connection. An example would be an MPTCP-enabled CPE, which 197 makes use of its own multiple local interfaces to maximize the 198 experience of bandwidth consuming applications for Non-MPTCP UEs. 200 o A MPTCP Proxy that maps an UE originated MPTCP connection into a 201 TCP connection. This is the case for most mobile terminals with 202 multiple interfaces and built-in MPTCP capability. 204 +----+ +------------+ +------------+ +------+ 205 |Host| <=TCP=>| MPTCP Proxy|<=MPTCP=>| MPTCP Proxy|<=TCP=>|Server| 206 +----+ +------------+ +------------+ +------+ 208 +----+ +------------+ +------+ 209 |Host|<=MPTCP=>| MPTCP Proxy|<=TCP=>|Server| 210 +----+ +------------+ +------+ 212 Figure 1: MPTCP Behaviors. 214 This documents details these use-cases and derived requirements for 215 MPTCP proxy deployment in ISP networks. 217 The use cases discussed in this document can also be valid for 218 Enterprise networks. 220 2 Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [RFC2119]. 226 This document makes use of the following terms: (For definitions of 227 other terms such as "(MPTCP) Connection", "Host" and "Subflow", refer 228 to [RFC6824].) 230 M-session: a MPTCP connection between a M-UE and a M-Server. 232 M-Server: a server with MPTCP capability enabled for the current TCP 233 session, or simply a serving MPTCP host. M-Server may be connected 234 to the network using one or multiple network interfaces. 236 M-UE: a user equipment with MPTCP capability enabled for the current 237 TCP session, or simply a requesting MPTCP host. Unless it is 238 explicated, an M-UE can be a host or a CPE. 240 N-Server: a server without MPTCP capability enabled for the current 241 TCP session. 243 N-UE: a user equipment without MP-TCP capability enabled for the 244 current TCP session. 246 MPTCP Proxy: proxy located between a M-UE and a N-Server, which 247 enables a M-session with the M-UE and maps it into a legacy TCP 248 connection with the N-Server. 250 Natural Path: a "natural path" of a subflow is the original path it 251 would traverse end-to-end if there is no explicit traffic steering 252 function is enabled for MPTCP Proxy. 254 Small Cell: generally refers to the cells with less than 1 watt 255 output power, e.g. picocell, femtocell, etc. 257 Nanocell: a type of base station integrated with both a small cell 258 and a WLAN access point. 260 3 Use-cases for ISP MPTCP Proxy 262 3.1 Boosting MPTCP Utilization for M-UEs and Multi-Interface CPEs 264 On the one hand, user equipment (esp. mobile terminals) nowadays have 265 multiple interfaces and could benefit from these interfaces if they 266 were using MPTCP. 268 On the other hand, servers often only support regular TCP and 269 upgrading them to support MPTCP will take more time than on the 270 clients. 272 Therefore, it is expected that an ISP deployed MPTCP Proxy would 273 benefit the M-UEs with better user-experience for almost all the 274 legacy applications by exploiting MPTCP capability at least for the 275 most resource-limited channel on the air, without relying on 276 pervasive MPTCP deployment at the server side. 278 The same approach can be followed for CPE-based deployment models. 279 These models can be refreshed to integrate CPEs that are able to 280 mount multiple interfaces. 282 3.2 Resource Pooling from Multiple Networks 284 For an ISP providing multiple access networks to its subscribers, a 285 locally deployed MPTCP Proxy would enable use-cases where the M- 286 UE/ISP is trying to pool access network resources from multiple 287 networks concurrently, e.g., among multiple WLAN hotspots, a fixed 288 and a WLAN connection, a cellular and a WLAN, a cellular and a Fixed 289 access, etc. 291 However, the specific pooling strategy can differ for various 292 scenarios, depending on the type of subscriber and the current status 293 of different networks, etc. 295 For example, from the user's perspective, business customers would 296 have perfect pooling while other users would get the cheaper network 297 whenever possible. 299 On the other hand, from the ISP's perspective, it would encourage 300 more efficient usage of network resource by dynamic charging policy 301 for rush hours, has a static preference for a specific network over 302 another one, or even desires traffic offloading to proactively 303 migrate less sensitive or more demanding traffic between multiple 304 networks it controls. 306 Criteria to invoke an MPTCP Proxy in a communication paths will be 307 the results of these policies (i.e., subscribers, applications, and 308 ISPs). 310 3.3 Multiple Connections and Seamless Handover between Multiple Networks 312 For cellular ISPs, the radio access networks are the dominating part 313 of their network construction investment. With the rapid development 314 of cellular technology and the imbalance of subscriber/traffic 315 distribution geographically, it is common practice to deploy leading- 316 edge technology in traffic boosting hot spots (e.g., downtown areas 317 in big cities) first while enabling seamless handover for legacy 318 cellular/wireless networks to guarantee service continuity for a 319 moving terminal. 321 A device can discover multiple networks, including multiple 322 attachment points to the same ISPs. This is the typical example of a 323 device that can be serviced with multiple WLAN hotspots. Instead of 324 selecting only one attachment point, the device can select multiple 325 ones when more resources are required. Maintaining simultaneous 326 attachment to these attachment points will also allow for seamless 327 handover and, therefore, allow for session continuity. 329 Implementing this feature may require an explicit signal to the 330 connecting device to drive its network attachment procedure. It is 331 out of scope of this document to discuss such signals nor elaborate 332 on potential impact on battery consumption on mobile devices mounting 333 multiple interfaces in parallel. 335 3.4 Assist MTPCP Connection Establishment 337 The MPTCP Proxy does not know in advance whether a remote server is 338 MPTCP-enabled. As such, the MPTCP Proxy can be provided with various 339 policies such as (but not limited to): 341 o TAKE-OVER Mode: Strip any MPTCP signal systematically in all TCP 342 messages to a remote server: This mode might be useful for two 343 scenarios: For the scenario where servers are not widely MPTCP- 344 enabled, it has the advantage to not suffer from MPTCP fallback delay 345 when the remote server is not MPTCP-enabled. For the scenario where 346 the ISP would like to limit the MPTCP traffic to its local network to 347 avoid unexpected blocking by third-party middle-boxes. 349 o TRANSPARENT Mode: Allow MPTCP signals to be passed to 350 systematically to remote servers: This mode has the advantage to 351 optimize MPTCP Proxy resources and favor direct communications 352 between an MPTCP-enabled UE and an MTPCP-enabled server without 353 invoking the MPTCP Proxy when both the server and client are MPTCP- 354 enabled. 356 o HYBRID Mode: The combination of the above two modes, according to 357 the proxy's local policy. 359 4 Deployment Considerations 361 For an MPTCP Proxy to correctly manage an M-session with the M-UE, it 362 is necessary for it to receive each subflow coming from the M-UE and 363 heading for the N-Server it is acting on behalf of. It is hence 364 straightforward to consider an on-path deployment strategy, where the 365 MPTCP Proxy is directly located on the common link of every subflow 366 from the M-UE. 368 However, for other cases where a common link is absent within the 369 local ISP's domain or resource pooling is desired from networks of 370 different ISP domains, the MPTCP Proxy has to steer off-path subflow 371 to traverse the selected MPTCP Proxy explicitly. Note that steering 372 functions should work for both directions over all the subflows, i.e. 373 including both uplink and downlink traffic from/to the M-UE. 375 Therefore, two types of MPTCP Proxy are considered in this document: 376 on-path MPTCP Proxy and off-path MPTCP Proxy. 378 4.1 On-path MPTCP Proxy 380 For different access networks provided by a single ISP, it is fairly 381 easy to locate a common link and deploy an on-path MPTCP Proxy 382 accordingly. 384 As depicted in Figure 2, the on-path MPTCP Proxy is located on each 385 potential path from a M-UE for both MPTCP traffic and legacy TCP 386 traffic. 388 ( ) 389 ( Access Net #1 ) 390 +--->(e.g. Cellular Network)<--+ 391 +----+ | ....>( )<. | +-------+ +--------+ 392 | |<--+ . ( ) . +->| |<==>| | 393 | |<..... ......>|On-Path|<..>| | 394 |M-UE| +----->| MPTCP | |N-Server| 395 | |<----+ | ....>| Proxy |<..>| | 396 | |<... | ( ) | . +-------+ +--------+ 397 +----+ . +--->( Access Net #2 )<+ . 398 ....>( e.g. WLAN Network )<. 399 ( ) 400 ( ) 402 -----subflow of an M-session 403 .....legacy TCP flow 404 =====merged TCP flow for an M-session 406 Figure 2. The On-Path MPTCP Proxy 408 4.2 Off-Path Proxy 410 On the one hand, it is not viable to assume for instance a common 411 link from a cellular ISP to deploy an on-path proxy on each potential 412 MPTCP subflow originating from its M-UE via third-party WLAN networks 413 for instance. 415 On the other hand, even for resource pooling from a single ISP's own 416 WLAN networks, it is not always feasible to find such a common link 417 for on-path MPTCP Proxy before corresponding traffic hitting the 418 public Internet. 420 ( ) 422 ( Access Net #1 ) 423 +--->(e.g. Cellular Network)<--+ 424 +----+ | ....>( )<. | +--------+ +--------+ 425 | |<--+ . ( ) . +->|off-Path|<==>| | 426 | |<..... ......>| MPTCP |<..>| | 427 |M-UE| ******>| Proxy | |N-Server| 428 | |<***** * +--------+ | | 429 | |<... * ( ) * ..................>| | 430 +----+ . *****>( Access Net #2 )<* . +--------+ 431 ....>( e.g WLAN Network )<. 432 ( ) 433 ( ) 435 -----subflow following its natural path 436 *****explicitly redirected subflow 437 .....legacy TCP flow 438 =====merged TCP flow for a M-session 440 Figure 3. The Off-Path MPTCP Proxy 442 As depicted in Figure 3, the off-path MPTCP Proxy is located on the 443 "natural path" of only a partial subset of potential subflow of a 444 given M-session, and relies on extra mechanism to explicitly steering 445 other subflows to deviate from their "natural path" and go through 446 it. 448 5 Deployment Scenarios 450 5.1 MPTCP Proxy at the ISP IP Gateway 452 For Fixed networks, MPTCP Proxy can be located in various segments 453 with a network (e.g., co-located with a CGN [RFC6888], a DS-Lite AFTR 454 [RFC6333], or a NAT64 device [RFC6146] if already present in the 455 network, co-located with a TCP acceleration and optimizer if any, 456 etc.). 458 As the anchoring point for 3GPP mobile UE originated IP traffic 459 within the cellular network, the IP gateway of 3GPP network (e.g., 460 GGSN (Gateway GPRS Support Node) or PDN Gateway (PGW) [RFC7066]) 461 would be a natural spot for MPTCP Proxy deployment. It is also 462 possible for the gateway to reuse existing interfaces with other 3GPP 463 network elements for information/policy acquisition. Alternatively, 464 another location for MPTCP Proxy deployment would be the (s)Gi 465 Interface(i.e., between the GGSN/PGW and an external PDN (Packet 466 Domain Network)). 468 5.2 On-Path MPTCP Proxy at the ISP Data Center 470 It is common practice for local ISPs to build up local data center 471 facilities within its domain for large Internet content providers in 472 order to feed user's requests locally, resulting in both enhanced 473 user experience for cut-short end-to-end delay and reduced expenses 474 for unnecessary cross-ISP peering traffic. 476 It is believed that by deploying an on-path MPTCP Proxy at the 477 entrance of the ISP's local data center, it would help various 478 Internet Content Provider residing within the data center to gain 479 enhanced user-experience for local subscribers with M-UEs without the 480 need to upgrade their servers manually. 482 5.3 On-Path MPTCP Proxy at SmallCell Gateway 484 Some ISPs are deploying small cells (low-powered radio access nodes) 485 with both cellular and carrier WLAN access. Small cells is expected 486 to be a cost-effective and green way for cellular network deployment 487 for both home and enterprise subscribers. For instance, it can be 488 integrated with the home gateway for a broadband subscriber. 490 Figure 4 outlines the Nanocell system architecture. 492 ( ) 493 +--+ +-(Cellular)-+ +--------+ Cellular 494 | |-+ ( ) +-|Nanocell| +-( Core )---( ) 495 |UE| |(local |-(IP Backhaul)+ (Internet) 496 | |-+ ( ) +-|Gateway)| +-( WLAN AC )---( ) 497 +--+ +-( WLAN )-+ +--------+ 498 ( ) 500 Figure 4. Nanocell System Architecture 502 As a combined access node for both cellular and WLAN traffic, small 503 cell Gateway represents a spot for an on-path MPTCP Proxy at the 504 network edge. 506 Note that by applying local breakout scheme, where the small cell 507 doing IP-layer forwarding itself rather than relying on other 3GPP 508 routing devices, it is expected that no extensions to existing 3GPP 509 specs are needed for its integration with an MPTCP Proxy. 511 5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks 513 A first deployment model assumes MPTCP Proxy is enabled in a CPE. 514 This proxy aims to offer MPTCP service to non-MPTCP hosts located 515 behind the CPE. This model can be deployed with or without an MPTCP 516 Proxy at the ISP's network. 518 In early deployment stages, this model is likely to require an MPTCP 519 Proxy be also deployed at the ISP's network side. This is mainly to 520 shorten delays induced by TCP fall back when the remote server is not 521 MPTCP compliant. 523 Hosts located behind the CPE are not aware of the activation of the 524 MPTCP at the CPE side. MPTCP can be used for both bandwidth 525 aggregation and also ensure session continuity during failure 526 events. 528 6 Requirements for MPTCP Proxy 530 This section identifies requirements derived from the above use-cases 531 for an ISP MPTCP Proxy. 533 6.1 Protocol Proxying between MPTCP and TCP 535 In the on-path MPTCP Proxy use-case, the proxy is assured to be 536 deployed on the path of each potential subflow of a given MPTCP 537 session from the M-UE to the N-Server. 539 To allow a MPCTP-enabled UE to make full use of the multiple 540 interfaces even if it is interacting with an N-server, the on-path 541 MPTCP Proxy MUST satisfy the following requirements. 543 (a) Compatibility: An on-path MPTCP Proxy supports detection of M- 544 UE/N-server combinations for further proxying while leaving M-UE/M- 545 server and N-UE/N-server sessions intact. 547 (b) Transparency: An on-path MPTCP Proxy supports negotiation with 548 and acting towards the M-UE like a M-server on behalf of N-Server, 549 while acting towards the N-Server like a N-UE on behalf of the M-UE. 551 6.2 Explicit Traffic Steering for Off-Path Proxying 553 As we discussed earlier in the off-path MPTCP Proxy use-case, it is 554 required that subflows whose "natural path" does not include the 555 MPTCP Proxy be redirected explicitly to go through the proxy. 557 (c) Explicit Traffic Steering: an off-path MPTCP Proxy that enables 558 resource pooling from third-party WLAN networks MUST support explicit 559 traffic steering, to allow all the subsequent subflow traffic go 560 through the exactly the same MPTCP Proxy used in the correspondent M- 561 session establishment for both directions (including uplink and 562 downlink traffic from/to the M-UE). 564 (d) Globally Routable Address: an off-path MPTCP Proxy that enables 565 resource pooling from the same ISP's networks SHOULD expose a 566 globally routable address to allow explicit steering of subsequent 567 subflow traffic after they hit the public Internet. 569 6.3 Flexible Resource Policy within a Single ISP 571 Different from the end-to-end MPTCP solution, ISP deployed MPTCP 572 Proxy is a potential point for centralized cross-network flow control 573 over service/RAT preference for a given subscriber's M-UEs, which is 574 considered to be essential for better operation and service provision 575 in 3GPP networks. 577 However, to enable such fine-grained resource pooling policy from the 578 network side, it is essential that the MPTCP proxy knows for each 579 subflow its specific Network Access Type information. 581 (e) Network Access Type Information: an MPTCP proxy SHOULD be able to 582 make use of a reliable information sharing/reporting mechanism to 583 acquire a subflow's Network Access Type information/update on a real- 584 time basis. 586 (f) Resource Policy: an MPTCP Proxy MUST support flexible control to 587 set limits to both the number of concurrent subflows running in a M- 588 session and the number of concurrent M-sessions from an M-UE/to an N- 589 Server, according to the type and/or identity of relevant subscriber 590 and/or application. 592 6.4 Protection against third-party traffic 594 Apart from the traditional private network deployment practice, an 595 off-path MPTCP proxy exposes itself as publicly accessible from any 596 third-party traffic, where traditional access authorization or 597 admission control mechanisms from 3GPP network would not work. It is 598 therefore envisioned that an off-path MPTCP Proxy open for third- 599 party WiFi resource pooling MUST support minimal protection/policy 600 against potentially malicious traffic from third-party network. 602 (g) Provision Negotiation: an MPTCP Proxy SHOULD support both 603 subscriber/M-session/subflow level resource reservation negotiation 604 with a M-UE. 606 (h) Origin Authentication: an off-path MPTCP Proxy MUST support 607 subflow authentication for traffic from an unauthorized third-party 608 WiFi, in order to serve subflows belong to its intended M-sessions 609 coming from authorized subscribers or NAT, while turning down others 610 with least overhead. 612 (i) Admission Control: an off-path MPTCP Proxy MUST support admission 613 control to set limits to both the number of concurrent subflows on a 614 given M-session and the number of concurrent M-sessions for a given 615 subscriber/application. 617 6.5 MPTCP Proxy Selection from Multiple Candidates 619 When multiple MPTCP Proxies exist on an end-to-end path from the M-UE 620 to the N-Server, a natural question arises that "which MPTCP Proxy 621 should be chosen and how". There may be different considerations 622 depending on the location and types of MPTCP Proxy involved in 623 addition to the expectation of the application. 625 For example, assume an ISP deploys on-path MPTCP Proxy at smallcell 626 Gateway as well as an off-path MPTCP Proxy at the IP gateway of its 627 cellular network. The following considerations may apply. 629 On one hand, a straightforward policy would be to choose the nearest 630 MPTCP Proxy to the M-UE, i.e. the on-path MPTCP Proxy at smallcell 631 gateway which would lead to more efficiency from less traffic 632 convergence pressure. Another policy would be to prefer the on-path 633 MPTCP Proxy to the off-path one, which would cause unnecessary 634 traffic roundabout. 636 However, on the other hand, if a M-session is established with the 637 on-path MPTCP Proxy at smallcell gateway and when the M-UE moves out 638 of the coverage of the cell, the connection will be broken. 639 Therefore, it is reasonable to choose off-path MPTCP Proxy for 640 applications with strict service continuity expectations, while favor 641 on-path MPTCP Proxy for bulk data transfer with application-level re- 642 connection mechanisms. 644 In summary, regarding the MPTCP Proxy selection from multiple 645 candidates, the following requirement apply. 647 (j) Flexible Selection: when multiple M-Proxies are deployed on the 648 end-to-end path for a M-session establishment within the domain a 649 single ISP, it SHOULD be possible for the ISP to enforce flexible 650 selection policy regarding which MPTCP Proxy to serve which M- 651 session, based on the MPTCP Proxy's location, the MPTCP Proxy's type 652 (on-path/off-path) in addition to the application's expectation. 654 6.6 Load Balancing Algorithm for Multiple Networks 656 When multiple networks are available to service a subscriber, the 657 traffic may be balanced among those available paths for the sake of 658 QoE. The logic for balancing the traffic among those multiple paths 659 can be driven by application needs, customer's preferences, and/or 660 ISP traffic engineering guidelines. 662 From a traffic engineering perspective, the ISP may enforce policies 663 that would optimize various parameters such as: 665 o Network resources usage as a whole. 667 o Optimized invocation of available MPTCP Proxies (i.e., MPTCP Proxy 668 selection). 670 o Optimized MPTCP Proxy local performances (e.g., avoid overload 671 phenomena). 673 o Enhanced QoE (including increase both upstream and downstream 674 throughputs) 676 In summary, regarding the load balancing algorithm for multiple 677 networks, the following requirement apply. 679 (k) The MPTCP Proxy SHOULD be configurable with the load balancing 680 ratio per each available path. 682 6.7 Misc 684 Below are listed some additional requirements: 686 o Including an MPTCP Proxy in the communication may be seen as a 687 single point of failure. Means to protect against such failures 688 should be enabled. 690 o If TCP flows handled by the MPTCP Proxy are sourced with the 691 external IP address(es) that belong to the MPTCP Proxy, all hosts 692 serviced by the same MPTCP Proxy will be seen with the same IP 693 address(es). Means to mitigate the side effects documented in 694 [RFC6269] SHOULD be enabled in such deployment case. 696 o The MPTCP Proxy SHOULD NOT alter non-MPTCP signals included in a 697 TCP segment. 699 o The MPTCP Proxy MUST NOT inject MPTCP signals if the TCP option 700 size is consumed. 702 o The MPTCP Proxy SHOULD NOT inject MPTCP signals if this leads to 703 local fragmentation. MTU tuning may be required to avoid 704 fragmentation. MPTCP Proxy SHOULD be configurable to enable/disable 705 this feature. 707 o The MPTCP Proxy MUST take proper measure to avoid errors caused by 708 careless MPTCP signal modification to segments with other TCP 709 options. For instance, TCP-AO (TCP Authentication Option) [RFC5925], 710 which includes TCP options in the MAC computation, when present, MUST 711 be the first processed by the MPTCP Proxy. 713 o The MPTCP Proxy SHOULD be easy to scale to cope with growing 714 demand. 716 7 Security Considerations 718 As an MPTCP Proxy is playing N-UE and M-Server at the same time, the 719 security considerations that concerns a TCP client and a MPTCP- 720 enabled server are applicable to a MPTCP Proxy in general [RFC6181]. 722 Forcing the traffic to cross an MPTCP Proxy that would not be 723 involved if legacy routing and forwarding actions are enforced raises 724 some security concerns. In particular, inserting an illegitimate 725 MPTCP Proxy can be used to hijack connections. Traffic inspected by 726 third party MPTCP Proxy may be used as a vector to reveal privacy- 727 related information. 729 These security concerns can be mitigated if the MPTCP Proxy is 730 managed by the same ISP offering connectivity to a customer. 731 Otherwise, specific mechanisms to be used are expected to be an 732 integral part of an MPTCP Proxy design and out of scope of this 733 document. 735 8 IANA Considerations 737 There is no IANA action in this document. 739 9 Acknowledgement 741 The authors would like to thank Olivier Bonaventure, Jordan Melzer, 742 Preethi Natarajan, Marc Portoles, Chunshan Xiong, Alper Yegin, Zhen 743 Cao and Hui Deng for their valuable comments and input to this 744 document. 746 10 References 748 10.1 Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 754 "TCP Extensions for Multipath Operation with Multiple 755 Addresses", RFC 6824, January 2013. 757 10.2 Informative References 759 [RFC6181] M. Bagnulo, "Threat Analysis for TCP Extensions for 760 Multipath Operation", RFC 6181, March 2011. 762 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 763 Stack Lite Broadband Deployments Following IPv4 764 Exhaustion", RFC6333, August 2011. 766 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 767 NAT64: Network Address and Protocol Translation from IPv6 768 Clients to IPv4 Servers", RFC 6146, April 2011. 770 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 771 Roberts, "Issues with IP Address Sharing", RFC 6269, June 772 2011. 774 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 775 Roberts, "Issues with IP Address Sharing", RFC 6269, June 776 2011. 778 [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 779 "IPv6 for Third Generation Partnership Project (3GPP) 780 Cellular Hosts", RFC 7066, November 2013. 782 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 783 Authentication Option", RFC 5925, June 2010. 785 Authors' Addresses 787 Lingli Deng 788 China Mobile 790 Email: denglingli@chinamobile.com 792 Dapeng Liu 793 China Mobile 795 Email: liudapeng@chinamobile.com 797 Tao Sun 798 China Mobile 800 Email: suntao@chinamobile.com 802 Mohamed Boucadair 803 France Telecom 805 Email: mohamed.boucadair@orange.com 807 Gregory Cauchie 808 Bouygues Telecom 810 Email: GCAUCHIE@bouyguestelecom.fr