idnits 2.17.1 draft-deng-mptcp-proxy-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 1 longer page, the longest (page 9) being 63 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 date (May 29, 2014) is 3614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6888' is mentioned on line 442, but not defined ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 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: December 29, 2014 China Mobile 6 M. Boucadair 7 France Telecom 8 G. Cauchie 9 Bouygues Telecom 10 May 29, 2014 12 Use-cases and Requirements for MPTCP Proxy in ISP Networks 13 draft-deng-mptcp-proxy-00 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 . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 10 73 5.3 On-Path MPTCP Proxy at Nanocell . . . . . . . . . . . . . . 10 74 5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks . . . . . . 11 75 6 Requirements for MPTCP Proxy . . . . . . . . . . . . . . . . . 11 76 6.1 Protocol Proxying between MPTCP and TCP . . . . . . . . . . 11 77 6.2 Explicit Traffic Steering for Off-Path Proxying . . . . . . 12 78 6.3 Flexible Resource Policy within a Single ISP . . . . . . . 12 79 6.4 Protection against third-party traffic . . . . . . . . . . . 13 80 6.5 MPTCP Proxy Selection from Multiple Candidates . . . . . . . 13 81 6.6 Load Balancing Algorithm for Multiple Networks . . . . . . . 14 82 6.7 Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 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 bitrates (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 relays 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 relays an UE originated MPTCP connection into 201 a 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 283 For an ISP providing multiple access networks to its subscribers, a 284 locally deployed MPTCP Proxy would enable use-cases where the M- 285 UE/ISP is trying to pool access network resources from multiple 286 networks concurrently, e.g., among multiple WLAN hotspots, a fixed 287 and a WLAN connection, a cellular and a WLAN, a cellular and a Fixed 288 access, etc. 290 However, the specific pooling strategy can differ for various 291 scenarios, depending on the type of subscriber and the current status 292 of different networks, etc. 294 For example, from the user's perspective, business customers would 295 have perfect pooling while other users would get the cheaper network 296 whenever possible. 298 On the other hand, from the ISP's perspective, it would encourage 299 more efficient usage of network resource by dynamic charging policy 300 for rush hours, has a static preference for a specific network over 301 another one, or even desires traffic offloading to proactively 302 migrate less sensitive or more demanding traffic between multiple 303 networks it controls. 305 Criteria to invoke an MPTCP Proxy in a communication paths will be 306 the results of these policies (i.e., subscribers, applications, and 307 ISPs). 309 3.3 Multiple Connections and Seamless Handover between Multiple Networks 311 For cellular ISPs, the radio access networks are the dominating part 312 of their network construction investment. With the rapid development 313 of cellular technology and the imbalance of subscriber/traffic 314 distribution geographically, it is common practice to deploy leading- 315 edge technology in traffic boosting hot spots (e.g., downtown areas 316 in big cities) first while enabling seamless handover for legacy 317 cellular/wireless networks to guarantee service continuity for a 318 moving terminal. 320 A device can discover multiple networks, including multiple 321 attachment points to the same ISPs. This is the typical example of a 322 device that can be serviced with multiple WLAN hotspots. Instead of 323 selecting only one attachment point, the device can select multiple 324 ones when more resources are required. Maintaining simultaneous 325 attachment to these attachment points will also allow for seamless 326 handover and, therefore, allow for session continuity. 328 Implementing this feature may require an explicit signal to the 329 connecting device to drive its network attachment procedure. It is 330 out of scope of this document to discuss such signals nor elaborate 331 on potential impact on battery consumption on mobile devices mounting 332 multiple interfaces in parallel. 334 3.4 Assist MTPCP Connection Establishment 336 The MPTCP Proxy does not know in advance whether a remote server is 337 MPTCP-enabled. As such, the MPTCP Proxy can be provided with various 338 policies such as (but not limited to): 340 o Strip any MPTCP signal systematically when relaying TCP messages to 341 a remote server: This mode assumes servers are not widely MPTCP- 342 enabled. It has the advantage to not suffer from MPTCP fallback delay 343 when the remote server is not MPTCP-enabled. 345 o Allow MPTCP signals to be passed to systematically to remote 346 servers: This mode has the advantage to optimize MPTCP Proxy 347 resources and favor direct communications between an MPTCP-enabled UE 348 and an MTPCP-enabled server without invoking the MPTCP Proxy when 349 both the server and client are MPTCP-enabled. 351 4 Deployment Considerations 353 For a MPTCP Proxy to correctly manage a M-session with the M-UE, it 354 is necessary for it to receive each subflow coming from the M-UE and 355 heading for the N-Server it is acting on behalf of. It is hence 356 straightforward to consider an on-path deployment strategy, where the 357 MPTCP Proxy is directly located on the common link of every subflow 358 from the M-UE. 360 However, for other cases where a common link is absent within the 361 local ISP's domain or resource pooling is desired from networks of 362 different ISP domains, the MPTCP Proxy has to steer off-path subflow 363 to traverse the selected MPTCP Proxy explicitly. Note that steering 364 functions should work for both directions over all the subflows, i.e. 365 including both uplink and downlink traffic from/to the M-UE. 367 Therefore, two types of MPTCP Proxy are considered in this document: 368 on-path MPTCP Proxy and off-path MPTCP Proxy. 370 4.1 On-path MPTCP Proxy 372 For different access networks provided by a single ISP, it is fairly 373 easy to locate a common link and deploy an on-path MPTCP Proxy 374 accordingly. 376 As depicted in Figure 2, the on-path MPTCP Proxy is located on each 377 potential path from a M-UE for both MPTCP traffic and legacy TCP 378 traffic. 380 ( ) 381 ( Access Net #1 ) 382 +--->(e.g. Cellular Network)<--+ 383 +----+ | ....>( )<. | +-------+ +--------+ 384 | |<--+ . ( ) . +->| |<==>| | 385 | |<..... ......>|On-Path|<..>| | 386 |M-UE| +----->| MPTCP | |N-Server| 387 | |<----+ | ....>| Proxy |<..>| | 388 | |<... | ( ) | . +-------+ +--------+ 389 +----+ . +--->( Access Net #2 )<+ . 390 ....>( e.g. WLAN Network )<. 391 ( ) 392 ( ) 394 -----subflow of an M-session 395 .....legacy TCP flow 396 =====merged TCP flow for an M-session 397 Figure 2. The On-Path MPTCP Proxy 399 4.2 Off-Path Proxy 401 On the one hand, it is not viable to assume for instance a common 402 link from a cellular ISP to deploy an on-path proxy on each potential 403 MPTCP subflow originating from its M-UE via third-party WLAN networks 404 for instance. 406 On the other hand, even for resource pooling from a single ISP's own 407 WLAN networks, it is not always feasible to find such a common link 408 for on-path MPTCP Proxy before corresponding traffic hitting the 409 public Internet. 411 ( ) 412 ( Access Net #1 ) 413 +--->(e.g. Cellular Network)<--+ 414 +----+ | ....>( )<. | +--------+ +--------+ 415 | |<--+ . ( ) . +->|off-Path|<==>| | 416 | |<..... ......>| MPTCP |<..>| | 417 |M-UE| ******>| Proxy | |N-Server| 418 | |<***** * +--------+ | | 419 | |<... * ( ) * ..................>| | 420 +----+ . *****>( Access Net #2 )<* . +--------+ 421 ....>( e.g WLAN Network )<. 422 ( ) 423 ( ) 425 -----subflow following its natural path 426 *****explicitly redirected subflow 427 .....legacy TCP flow 428 =====merged TCP flow for a M-session 430 Figure 3. The Off-Path MPTCP Proxy 431 As depicted in Figure 3, the off-path MPTCP Proxy is located on the 432 "natural path" of only a partial subset of potential subflow of a 433 given M-session, and relies on extra mechanism to explicitly steering 434 other subflows to deviate from their "natural path" and go through 435 it. 437 5 Deployment Scenarios 439 5.1 MPTCP Proxy at the ISP IP Gateway 441 For Fixed networks, MPTCP Proxy can be located in various segments 442 with a network (e.g., co-located with a CGN [RFC6888], a DS-Lite AFTR 443 [RFC6333], or a NAT64 device [RFC6146] if already present in the 444 network, co-located with a TCP acceleration and optimizer if any, 445 etc.). 447 As the anchoring point for 3GPP mobile UE originated IP traffic 448 within the cellular network, the IP gateway of 3GPP network (e.g., 449 GGSN (Gateway GPRS Support Node) or PDN Gateway (PGW) [RFC7066]) 450 would be a natural spot for MPTCP Proxy deployment. It is also 451 possible for the gateway to reuse existing interfaces with other 3GPP 452 network elements for information/policy acquisition. Alternatively, 453 another location for MPTCP Proxy deployment would be the (s)Gi 454 Interface(i.e., between the GGSN/PGW and an external PDN (Packet 455 Domain Network)). 457 5.2 On-Path MPTCP Proxy at the ISP Data Center 459 It is common practice for local ISPs to build up local data center 460 facilities within its domain for large Internet content providers in 461 order to feed user's requests locally, resulting in both enhanced 462 user experience for cut-short end-to-end delay and reduced expenses 463 for unnecessary cross-ISP peering traffic. 465 It is believed that by deploying an on-path MPTCP Proxy at the 466 entrance of the ISP's local data center, it would help various 467 Internet Content Provider residing within the data center to gain 468 enhanced user-experience for local subscribers with M-UEs without the 469 need to upgrade their servers manually. 471 5.3 On-Path MPTCP Proxy at Nanocell 473 Nanocell is a box integrating small cell (low-powered radio access 474 nodes) and carrier WLAN. Nanocell is expected to be a cost-effective 475 and green way for cellular network deployment for both home and 476 enterprise subscribers. For instance, it can be integrated with the 477 home gateway for a broadband subscriber. 479 Figure 4 outlines the Nanocell system architecture. 481 ( ) 482 +--+ +-(Cellular)-+ +--------+ Cellular 483 | |-+ ( ) +-|Nanocell| +-( Core )---( ) 484 |UE| |(local |-(IP Backhaul)+ ( Internet ) 485 | |-+ ( ) +-|Gateway)| +-( WLAN AC )---( ) 486 +--+ +-( WLAN )-+ +--------+ 487 ( ) 489 Figure 4. Nanocell System Architecture 491 As a combined access node for both cellular and WLAN traffic, 492 nanocell represents a spot for an on-path MPTCP Proxy. 494 Note that by applying local breakout scheme, where the small cell 495 doing IP-layer forwarding itself rather than relying on other 3GPP 496 routing devices, it is expected that no extensions to existing 3GPP 497 specs are needed for its integration with an MPTCP Proxy. 499 5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks 501 A first deployment model assumes MPTCP Proxy is enabled in a CPE. 502 This proxy aims to offer MPTCP service to non-MPTCP hosts located 503 behind the CPE. This model can be deployed with or without an MPTCP 504 Proxy at the ISP's network. 506 In early deployment stages, this model is likely to require an MPTCP 507 Proxy be also deployed at the ISP's network side. This is mainly to 508 shorten delays induced by TCP fall back when the remote server is not 509 MPTCP compliant. 511 Hosts located behind the CPE are not aware of the activation of the 512 MPTCP at the CPE side. MPTCP can be used for both bandwidth 513 aggregation and also ensure session continuity during failure 514 events. 516 6 Requirements for MPTCP Proxy 518 This section identifies requirements derived from the above use-cases 519 for an ISP MPTCP Proxy. 521 6.1 Protocol Proxying between MPTCP and TCP 523 In the on-path MPTCP Proxy use-case, the proxy is assured to be 524 deployed on the path of each potential subflow of a given MPTCP 525 session from the M-UE to the N-Server. 527 To allow a MPCTP-enabled UE to make full use of the multiple 528 interfaces even if it is interacting with an N-server, the on-path 529 MPTCP Proxy MUST satisfy the following requirements. 531 (a) Compatibility: An on-path MPTCP Proxy supports detection of M- 532 UE/N-server combinations for further proxying while leaving M-UE/M- 533 server and N-UE/N-server sessions intact. 535 (b) Transparency: An on-path MPTCP Proxy supports negotiation with 536 and acting towards the M-UE like a M-server on behalf of N-Server, 537 while acting towards the N-Server like a N-UE on behalf of the M-UE. 539 6.2 Explicit Traffic Steering for Off-Path Proxying 541 As we discussed earlier in the off-path MPTCP Proxy use-case, it is 542 required that subflows whose "natural path" does not include the 543 MPTCP Proxy be redirected explicitly to go through the proxy. 545 (c) Explicit Traffic Steering: an off-path MPTCP Proxy that enables 546 resource pooling from third-party WLAN networks MUST support explicit 547 traffic steering, to allow all the subsequent subflow traffic go 548 through the exactly the same MPTCP Proxy used in the correspondent M- 549 session establishment for both directions (including uplink and 550 downlink traffic from/to the M-UE). 552 (d) Globally Routable Address: an off-path MPTCP Proxy that enables 553 resource pooling from the same ISP's networks SHOULD expose a 554 globally routable address to allow explicit steering of subsequent 555 subflow traffic after they hit the public Internet. 557 6.3 Flexible Resource Policy within a Single ISP 559 Different from the end-to-end MPTCP solution, ISP deployed MPTCP 560 Proxy is a potential point for centralized cross-network flow control 561 over service/RAT preference for a given subscriber's M-UEs, which is 562 considered to be essential for better operation and service provision 563 in 3GPP networks. 565 However, to enable such fine-grained resource pooling policy from the 566 network side, it is essential that the MPTCP proxy knows for each 567 subflow its specific Network Access Type information. 569 (e) Network Access Type Information: an MPTCP proxy SHOULD be able to 570 make use of a reliable information sharing/reporting mechanism to 571 acquire a subflow's Network Access Type information/update on a real- 572 time basis. 574 (f) Resource Policy: an MPTCP Proxy MUST support flexible control to 575 set limits to both the number of concurrent subflows running in a M- 576 session and the number of concurrent M-sessions from an M-UE/to an N- 577 Server, according to the type and/or identity of relevant subscriber 578 and/or application. 580 6.4 Protection against third-party traffic 582 Apart from the traditional private network deployment practice, an 583 off-path MPTCP proxy exposes itself as publicly accessible from any 584 third-party traffic, where traditional access authorization or 585 admission control mechanisms from 3GPP network would not work. It is 586 therefore envisioned that an off-path MPTCP Proxy open for third- 587 party WiFi resource pooling MUST support minimal protection/policy 588 against potentially malicious traffic from third-party network. 590 (g) Provision Negotiation: an MPTCP Proxy SHOULD support both 591 subscriber/M-session/subflow level resource reservation negotiation 592 with a M-UE. 594 (h) Origin Authentication: an off-path MPTCP Proxy MUST support 595 subflow authentication for traffic from an unauthorized third-party 596 WiFi, in order to serve subflows belong to its intended M-sessions 597 coming from authorized subscribers or NAT, while turning down others 598 with least overhead. 600 (i) Admission Control: an off-path MPTCP Proxy MUST support admission 601 control to set limits to both the number of concurrent subflows on a 602 given M-session and the number of concurrent M-sessions for a given 603 subscriber/application. 605 6.5 MPTCP Proxy Selection from Multiple Candidates 607 When multiple MPTCP Proxies exist on an end-to-end path from the M-UE 608 to the N-Server, a natural question arises that "which MPTCP Proxy 609 should be chosen and how". There may be different considerations 610 depending on the location and types of MPTCP Proxy involved in 611 addition to the expectation of the application. 613 For example, assume an ISP deploys on-path MPTCP Proxy at nanocell as 614 well as an off-path MPTCP Proxy at the IP gateway of its cellular 615 network. The following considerations may apply. 617 On one hand, a straightforward policy would be to choose the nearest 618 MPTCP Proxy to the M-UE, i.e. the on-path MPTCP Proxy at nanocell 619 which would lead to more efficiency from less traffic convergence 620 pressure. Another policy would be to prefer the on-path MPTCP Proxy 621 to the off-path one, which would cause unnecessary traffic 622 roundabout. 624 However, on the other hand, if a M-session is established with the 625 on-path MPTCP Proxy at nanocell and when the M-UE moves out of the 626 coverage of the cell, the connection will be broken. Therefore, it is 627 reasonable to choose off-path MPTCP Proxy for applications with 628 strict service continuity expectations, while favor on-path MPTCP 629 Proxy for bulk data transfer with application-level re-connection 630 mechanisms. 632 In summary, regarding the MPTCP Proxy selection from multiple 633 candidates, the following requirement apply. 635 (j) Flexible Selection: when multiple M-Proxies are deployed on the 636 end-to-end path for a M-session establishment within the domain a 637 single ISP, it SHOULD be possible for the ISP to enforce flexible 638 selection policy regarding which MPTCP Proxy to serve which M- 639 session, based on the MPTCP Proxy's location, the MPTCP Proxy's type 640 (on-path/off-path) in addition to the application's expectation. 642 6.6 Load Balancing Algorithm for Multiple Networks 644 When multiple networks are available to service a subscriber, the 645 traffic may be balanced among those available paths for the sake of 646 QoE. The logic for balancing the traffic among those multiple paths 647 can be driven by application needs, customer's preferences, and/or 648 ISP traffic engineering guidelines. 650 From a traffic engineering perspective, the ISP may enforce policies 651 that would optimize various parameters such as: 653 o Network resources usage as a whole. 655 o Optimized invocation of available MPTCP Proxies (i.e., MPTCP Proxy 656 selection). 658 o Optimized MPTCP Proxy local performances (e.g., avoid overload 659 phenomena). 661 o Enhanced QoE (including increase both upstream and downstream 662 throughputs) 664 In summary, regarding the load balancing algorithm for multiple 665 networks, the following requirement apply. 667 (k) The MPTCP Proxy SHOULD be configurable with the load balancing 668 ratio per each available path. 670 6.7 Misc 671 Below are listed some additional requirements: 673 o Including an MPTCP Proxy in the communication may be seen as a 674 single point of failure. Means to protect against such failures 675 should be enabled. 677 o If TCP flows handled by the MPTCP Proxy are sourced with the 678 external IP address(es) that belong to the MPTCP Proxy, all hosts 679 serviced by the same MPTCP Proxy will be seen with the same IP 680 address(es). Means to mitigate the side effects documented in 681 [RFC6269] SHOULD be enabled in such deployment case. 683 o The MPTCP Proxy SHOULD NOT alter non-MPTCP signals included in a 684 TCP segment. 686 o The MPTCP Proxy MUST NOT inject MPTCP signals if the TCP option 687 size is consumed. 689 o The MPTCP Proxy SHOULD NOT inject MPTCP signals if this leads to 690 local fragmentation. MTU tuning may be required to avoid 691 fragmentation. MPTCP Proxy SHOULD be configurable to enable/disable 692 this feature. 694 o The MPTCP Proxy MUST take proper measure to avoid errors caused by 695 careless MPTCP signal modification to segments with other TCP 696 options. For instance, TCP-AO (TCP Authentication Option) [RFC5925], 697 which includes TCP options in the MAC computation, when present, MUST 698 be the first processed by the MPTCP Proxy. 700 o The MPTCP Proxy SHOULD be easy to scale to cope with growing 701 demand. 703 7 Security Considerations 705 As an MPTCP Proxy is playing N-UE and M-Server at the same time, the 706 security considerations that concerns a TCP client and a MPTCP- 707 enabled server are applicable to a MPTCP Proxy in general [RFC6181]. 709 Forcing the traffic to cross an MPTCP Proxy that would not be 710 involved if legacy routing and forwarding actions are enforced raises 711 some security concerns. In particular, inserting an illegitimate 712 MPTCP Proxy can be used to hijack connections. Traffic inspected by 713 third party MPTCP Proxy may be used as a vector to reveal privacy- 714 related information. 716 These security concerns can be mitigated if the MPTCP Proxy is 717 managed by the same ISP offering connectivity to a customer. 718 Otherwise, specific mechanisms to be used are expected to be an 719 integral part of an MPTCP Proxy design and out of scope of this 720 document. 722 8 IANA Considerations 724 There is no IANA action in this document. 726 9 Acknowledgement 728 The authors would like to thank Olivier Bonaventure, Preethi 729 Natarajan, Marc Portoles, Chunshan Xiong, Zhen Cao and Hui Deng for 730 their valuable comments and input to this document. 732 10 References 734 10.1 Normative References 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 740 "TCP Extensions for Multipath Operation with Multiple 741 Addresses", RFC 6824, January 2013. 743 10.2 Informative References 745 [RFC6181] M. Bagnulo, "Threat Analysis for TCP Extensions for 746 Multipath Operation", RFC 6181, March 2011. 748 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 749 Stack Lite Broadband Deployments Following IPv4 750 Exhaustion", RFC6333, August 2011. 752 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 753 NAT64: Network Address and Protocol Translation from IPv6 754 Clients to IPv4 Servers", RFC 6146, April 2011. 756 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 757 Roberts, "Issues with IP Address Sharing", RFC 6269, June 758 2011. 760 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 761 Roberts, "Issues with IP Address Sharing", RFC 6269, June 762 2011. 764 [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 765 "IPv6 for Third Generation Partnership Project (3GPP) 766 Cellular Hosts", RFC 7066, November 2013. 768 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 769 Authentication Option", RFC 5925, June 2010. 771 Authors' Addresses 773 Lingli Deng 774 China Mobile 776 Email: denglingli@chinamobile.com 778 Dapeng Liu 779 China Mobile 781 Email: liudapeng@chinamobile.com 783 Tao Sun 784 China Mobile 786 Email: suntao@chinamobile.com 788 Mohamed Boucadair 789 France Telecom 791 Email: mohamed.boucadair@orange.com 793 Gregory Cauchie 794 Bouygues Telecom 796 Email: GCAUCHIE@bouyguestelecom.fr