idnits 2.17.1 draft-nam-mptcp-deployment-considerations-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 (December 7, 2016) is 2668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-boucadair-mptcp-plain-mode-09 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-08) exists of draft-boucadair-mptcp-dhc-06 == Outdated reference: A later version (-05) exists of draft-boucadair-mptcp-radius-03 == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft C. Jacquenet, Ed. 4 Intended status: Informational Orange 5 Expires: June 10, 2017 O. Bonaventure, Ed. 6 Tessares 7 W. Henderickx, Ed. 8 Nokia/Alcatel-Lucent 9 R. Skog, Ed. 10 Ericsson 11 December 7, 2016 13 Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational 14 Considerations 15 draft-nam-mptcp-deployment-considerations-01 17 Abstract 19 Network-Assisted MPTCP deployment models are designed to facilitate 20 the adoption of MPTCP for the establishment of multi-path 21 communications without making any assumption about the support of 22 MPTCP by the communicating peers. MPTCP Conversion Points (MCPs) 23 located in the network are responsible for establishing multi-path 24 communications on behalf of endpoints, thereby taking advantage of 25 MPTCP capabilities to achieve different goals that include (but are 26 not limited to) optimization of resource usage (e.g., bandwidth 27 aggregation), of resiliency (e.g., primary/backup communication 28 paths), and traffic offload management. 30 This document describes Network-Assisted MPTCP uses cases, deployment 31 scenarios, and operational considerations. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on June 10, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Network-Assisted MPTCP Use Cases . . . . . . . . . . . . . . 4 76 4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 5 77 4.1. LTE/WLAN Aggregation . . . . . . . . . . . . . . . . . . 6 78 4.2. Fixed/Wireless Access Aggregation . . . . . . . . . . . . 6 79 4.3. Data Center . . . . . . . . . . . . . . . . . . . . . . . 7 80 5. Deployment & Operational Considerations . . . . . . . . . . . 7 81 5.1. MCP Location . . . . . . . . . . . . . . . . . . . . . . 8 82 5.2. MCP Insertion in a Multipath Communication . . . . . . . 8 83 5.2.1. Explicit Mode (Off-path) . . . . . . . . . . . . . . 8 84 5.2.2. Implicit Mode (On-path) . . . . . . . . . . . . . . . 10 85 5.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 86 5.4. MCP Behaviors . . . . . . . . . . . . . . . . . . . . . . 15 87 5.4.1. Transparent MCP . . . . . . . . . . . . . . . . . . . 15 88 5.4.2. Non-Transparent MCP . . . . . . . . . . . . . . . . . 17 89 5.5. Address Family Considerations . . . . . . . . . . . . . . 19 90 5.6. Policies & Configuration Parameters . . . . . . . . . . . 19 91 5.6.1. Towards End-to-End MPTCP Connections . . . . . . . . 19 92 5.6.2. Traffic Distribution Scheme . . . . . . . . . . . . . 22 93 5.6.3. Flows Eligible to Multipath Service . . . . . . . . . 22 94 5.6.4. TCP Fragmentation . . . . . . . . . . . . . . . . . . 23 95 5.6.5. DSCP Preservation . . . . . . . . . . . . . . . . . . 23 96 5.6.6. Supported Transport Protocols . . . . . . . . . . . . 23 97 5.6.7. Logging . . . . . . . . . . . . . . . . . . . . . . . 23 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 100 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 7.2. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . 24 102 7.3. Illegitimate MCP . . . . . . . . . . . . . . . . . . . . 24 103 7.4. High Rate Reassembly . . . . . . . . . . . . . . . . . . 24 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 108 10.2. Informative References . . . . . . . . . . . . . . . . . 26 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 111 1. Introduction 113 The overall quality of connectivity services can be enhanced by 114 combining several access network links for various purposes - 115 resource optimization, better resiliency, etc. Some transport 116 protocols, such as Multipath TCP, can help achieve such better 117 quality, but failed to be massively deployed so far. 119 The support of multipath transport capabilities by communicating 120 hosts remains a privileged target design so that such hosts can 121 directly use the available resources provided by a variety of access 122 networks they can connect to. Nevertheless, network operators do not 123 control end hosts while the support of MPTCP by content servers 124 remains close to zero. 126 Network-Assisted MPTCP deployment models are designed to facilitate 127 the adoption of MPTCP for the establishment of multi-path 128 communications without making any assumption about the support of 129 MPTCP capabilities by communicating peers. Network-Assisted MPTCP 130 deployment models rely upon MPTCP Conversion Points (MCPs) that act 131 on behalf of hosts so that they can take advantage of establishing 132 communications over multiple paths. 134 Such MCPs can be deployed in CPEs (Customer Premises Equipment), as 135 well in the network side. MCPs are responsible for establishing 136 multi-path communications on behalf of endpoints. 138 This document describes Network-Assisted MPTCP uses cases 139 (Section 3), deployment scenarios (Section 4), and operational 140 considerations (Section 5). 142 2. Terminology 144 The reader should be familiar with the terminology defined in 145 [RFC6824]. 147 This document makes use of the following terms: 149 o Client: an endhost that initiates transport flows forwarded along 150 a single path. Such endhost is not assumed to support multipath 151 transport capabilities. 153 o Server: an endhost that communicates with a client. Such endhost 154 is not assumed to support multipath transport capabilities. 156 o Multipath Client: a Client that supports multipath transport 157 capabilities. 159 o Multipath Server: a Server that supports multipath transport 160 capabilities. Both the client and the server can be single-homed 161 or multi-homed. However, for the use cases discussed in this 162 document, the number of interfaces on the endhosts is not 163 relevant. 165 o Transport flow: a sequence of packets that belong to a 166 unidirectional transport flow and which share at least one common 167 characteristic (e.g., the same destination address). TCP and SCTP 168 flows are composed of packets that have the same source and 169 destination addresses, the same protocol number and the same 170 source and destination ports. 172 o Multipath Conversion Point (MCP): a function that terminates a 173 transport flow and relays all data received over it over another 174 transport flow. 176 MCP is a function provided by the network operator that converts a 177 multipath transport flow and relays it over a single path 178 transport flow and vice versa. 180 3. Network-Assisted MPTCP Use Cases 182 The first use case is a Multipath Client that interacts with a 183 Server. To benefit from the capabilities of its multipath transport 184 protocol, the Multipath Client will interact with a Multipath 185 Conversion Point (MCP) located in the network as illustrated in 186 Figure 1. 188 C <===========>MCP <------------> S 189 +<============>+ 191 Legend: 192 <===>: MPTCP leg 194 Figure 1: A Multipath Client interacts with a Server through a 195 Multipath Conversion Point 197 A similar approach consists of a Multipath Server that leverages its 198 multipath capabilities when interacting with a Client as shown in 199 Figure 2. 201 C <---------> MCP <===========> S 202 +<=============>+ 204 Figure 2: A Client interacts with a Multipath Server through a 205 Multipath Conversion Point 207 The third use case is when a Client interacts with a Server and the 208 corresponding communication is deemed eligible to multi-path 209 forwarding. In this case, two Multipath Conversion Points are used. 210 The upstream MCP converts the (single path) transport flow initiated 211 by the Client into a multipath transport flow towards a downstream 212 MCP (called, network-located MCP). This downstream MCP converts the 213 multipath transport flow received from the upstream MCP in a single 214 path transport flow forwarded to the destination Server. The end-to- 215 end transport flow between the Client and the Server is thus 216 decomposed into three flows as shown in Figure 3: A (single path) 217 transport flow between the Client and the upstream MCP, a multipath 218 transport flow between the upstream and the downstream MCPs, and a 219 single path transport flow between the downstream MCP and the Server. 221 Upstream Downstream 222 C <---> MCP <===========> MCP <------------> S 223 +<=============>+ 225 Figure 3: A Client interacts with a Server through two Multipath 226 Conversion Points 228 4. Deployment Scenarios 230 This section discusses some deployment scenarios related to Network- 231 Assisted MPTCP designs. 233 4.1. LTE/WLAN Aggregation 235 This deployment scenario is considered by mobile operators so that 236 they can propose their customers to aggregate LTE resources with WLAN 237 resources. 239 As depicted in Figure 4, the mobile terminal (UE, User Equipment) is 240 MPTCP-capable. The MCP function is enabled in the network to 241 terminate MPTCP connections (e.g., in the PDN Gateway, a dedicated 242 service function located at the (S)Gi interface, co-located with a 243 TCP proxy, etc.). 245 This deployment scenario is an implementation of the use case 246 depicted in Figure 1. 248 +------------+ _--------_ +----------------+ 249 | | ( LTE ) | | 250 | UE +=======+ +===+ Backbone | 251 | (MPTCP | (_ _) | Network | 252 | Client) | (_______) |+--------------+| 253 | | IP Network #1 || Concentrator ||------> Internet 254 | | || (MCP) || 255 | | |+--------------+| 256 | | IP Network #2 | | 257 | | _--------_ | | 258 | | ( ) | | 259 | +=======+ WLAN +==+ | 260 | | (_ _) | | 261 +------------+ (_______) +----------------+ 263 Figure 4: Network-Assisted MPTCP LTE/WLAN Aggregation (Host-based 264 model) 266 4.2. Fixed/Wireless Access Aggregation 268 One of the promising deployment scenarios for Multipath TCP is to 269 enable a CPE that is connected to multiple access networks (e.g., 270 DSL, LTE, WLAN) to optimize the usage of such resources. This 271 deployment scenario, called Hybrid Access, relies upon MCPs located 272 in both the CPE and the network (Figure 5). The latter plays the 273 role of an MPTCP concentrator. Such concentrator terminates the 274 MPTCP sessions established from CPEs, before redirecting traffic into 275 legacy TCP sessions. 277 This deployment scenario is an implementation of the use case 278 depicted in Figure 2. 280 +------------+ _--------_ +----------------+ 281 | | ( LTE ) | | 282 | CPE +=======+ +===+ Backbone | 283 | (MCP) | (_ _) | Network | 284 | | (_______) |+--------------+| 285 | | IP Network #1 || Concentrator ||------> Internet 286 | | || (MCP) || 287 | | |+--------------+| 288 | | IP Network #2 | | 289 | | _--------_ | | 290 | | ( DSL ) | | 291 | +=======+ +==+ | 292 | | (_ _) | | 293 +-----+------+ (_______) +----------------+ 294 | 295 ---- LAN ---- 296 | 297 end-nodes 299 Figure 5: Network-Assisted MPTCP Fixed/Wireless Access Aggregation 301 For mobile operators that provide CPE-based mobile broadband 302 services, LTE and WLAN resources can be aggregated by means of MPTCP. 303 In such deployment scenario, the MCP function is enabled in the CPE 304 and in the network. 306 4.3. Data Center 308 As discussed in Section 2.1 of [I-D.ietf-mptcp-experience], MPTCP is 309 being contemplated for deployment within data centers. Such 310 deployments may adhere to the use cases defined in Figure 2 or 311 Figure 3. One or two MCPs may be enabled at the data center segment. 312 The objective is to optimize the resources usage within the data 313 center infrastructure. 315 The presence of an MCP is transparent to the client side, 316 nevertheless the origin client's IP address may be hidden to the 317 ultimate server. Enforcing per-host policies at the server's side 318 may be problematic if all connections are bound to an MCP's IP 319 address. To mitigate this problem, MCPs may insert the TCP Option 320 for Host Identification [RFC7974]. 322 5. Deployment & Operational Considerations 323 5.1. MCP Location 325 The location of MCPs is deployment-specific. Network Providers may 326 choose to adopt centralized or distributed designs. Nevertheless, in 327 order to take advantage of MPTCP, the location of an MCP should not 328 jeopardize packet forwarding performance overall. 330 5.2. MCP Insertion in a Multipath Communication 332 Two deployment scenarios can be considered for involving an MCP in 333 the communication path. These scenarios are described below. 335 5.2.1. Explicit Mode (Off-path) 337 This scenario assumes that the IP reachability information of an MCP 338 is explicitly configured on a device, e.g., by means of a specific 339 DHCP option [I-D.boucadair-mptcp-dhc]. A device can be a CPE or a 340 host. 342 MPTCP connections are established explicitly using the address(es) of 343 the MCP (Figure 6). In order to forward packets to their ultimate 344 destination, the MCP is provided during the connection establishment 345 with the destination IP address (and optionally destination port 346 numbers). Typically, this is achieved thanks to the use of the 347 MP_CONVERT Information Element (IE) defined in 348 [I-D.boucadair-mptcp-plain-mode]. Figure 6 illustrates the flow 349 exchange to established a communication with a legacy server (RM). 351 ___________________ 352 / Host-based Model \ 353 \___________________/ 355 +---+ +-----+ +--+ 356 |H1 | | MCP | |RM| 357 +---+ +-----+ +--+ 358 h1@h2@ mcp@ rm@ 359 | | | | 360 | |src:hi@ dst:mcp@| dst:rm@| 361 | |<=================MPTCP Leg=============>|<---TCP -->| 362 | | | | 364 ___________________ 365 / CPE-based Model \ 366 \___________________/ 368 Upstream Downstream 369 +--+ +-----+ +-----+ +--+ 370 |H1| | MCP | | MCP | |RM| 371 +--+ +-----+ +-----+ +--+ 372 h1@ uMCP@1 uMCP@2 dMCP@ rm@ 373 | | | | | 374 |src:h1@ |src:uMCP@1 dst:dmcp@| | 375 |<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->| 376 | dst:rm@| | | dst:rm@| 377 | | | | | 378 | | |src:uMCP@2 dst:dmcp@| | 379 | | |<===Secondary MPTCP subflow==>|<---TCP -->| 380 | | | ... | dst:rm@| 381 | | | | | 383 Legend: 384 RM: A remote machine. 386 Figure 6: Sample Connection Establishment (Explicit Mode) 388 This scenario aims to avoid any adherence of the Network-Assisted 389 MPTCP procedure and the underlying routing and forwarding policies. 390 Furthermore, this scenario allows for more flexibility in terms of 391 mounting MPTCP subflows as it does not require any specific order in 392 the establishment of subflows among available interfaces. 394 Because the MCP's reachability information is explicitly configured 395 on the device, means to guarantee successful inbound MPTCP 396 connections can be enabled in the device to instruct the MCP to 397 maintain active bindings so that incoming packets can be successfully 398 redirected towards the appropriate device. 400 5.2.2. Implicit Mode (On-path) 402 Unlike the explicit mode, the implicit mode assumes that the MCP is 403 located on a default forwarding path (primary path). As such, the 404 first subflow must always be placed over that primary path so that 405 the MCP can intercept MPTCP flows. Once intercepted, the MCP 406 advertises its reachability information by means of MPTCP signals 407 (MP_JOIN or ADD_ADDR). Figure 7 illustrates the flow exchange to 408 establish a communication with a legacy server (RM). 410 Note that a standard MPTCP implementation will try to establish other 411 subflows using rm@. In order to prevent such behavior, H1 is 412 instructed by some means to prevent establishing additional subflows 413 to rm@. For example, the MCP may set the C-bit in MP_CAPABLE option 414 ([I-D.ietf-mptcp-rfc6824bis]) it returns to H1. 416 ___________________ 417 / Host-based Model \ 418 \___________________/ 420 +----+ +-----+ +--+ 421 | H1 | | MCP | |RM| 422 +----+ +-----+ +--+ 423 h1@h2@ mcp@ rm@ 424 | | | | 425 |src:h1@ dst:rm@| dst:rm@| 426 |<============Initial MPTCP subflow========>|<---TCP -->| 427 | | ... | | 428 | |src:h2@ dst:mcp@| dst:rm@| 429 | |<=========Secondary MPTCP subflow=======>|<---TCP -->| 430 | | ... | | 432 ___________________ 433 / CPE-based Model \ 434 \___________________/ 436 Upstream Downstream 437 +--+ +-----+ +-----+ +--+ 438 |H1| | MCP | | MCP | |RM| 439 +--+ +-----+ +-----+ +--+ 440 h1@ uMCP@1 uMCP@2 dMCP@ rm@ 441 | | | | | 442 |src:h1@ |src:uMCP@1 dst:rm@|src:uMCP@1 | 443 |<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->| 444 | dst:rm@| | | dst:rm@| 445 | | | | | 446 | | |src:uMCP@2 dst:mcp@|src:uMCP@1 | 447 | | |<===Secondary MPTCP subflow==>|<---TCP -->| 448 | | | ... | dst:rm@| 449 | | | | | 451 Figure 7: Sample Connection Establishment (Implicit Mode) 453 Subsequent subflows are then sent directly to the MCP (Figure 7). 454 The handling of these subsequent subflows is identical to the one of 455 the explicit mode; only the establishment of the initial subflow 456 differs. Concretely, in reference to Figure 8, once the upstream MCP 457 intercepts an initial subflow, it adds itself to the MPTCP connection 458 by sending ADD_ADDR on the primary subflow. Then, MP_JOIN is sent to 459 the IP address conveyed in ADD_ADDR to create the secondary subflow. 461 +----+ +-----+ +--+ 462 | H1 | | MCP | |RM| 463 +----+ +-----+ +--+ 464 h1@h2@ mcp@ rm@ 465 | | | | 466 |<==============ADD_ADDR====================| | 467 | | _______________________________________ | | 468 | |/ Secondary subflow \| | 469 | |================SYN+MP_JOIN=============>| | 470 | |<============SYN/ACK(MPJOIN)=============| | 471 | |============ACK(MP_JOIN)================>| | 472 | | ... | | 474 Figure 8: Secondary Subflow Creation (Host-based Implicit Mode) 476 5.2.2.1. Demux Native MPTCP Flows from Proxied MPTCP Flows 478 If no explicit signal is included in the initial SYN message, the MCP 479 cannot distinguish "native" MPTCP connections from "proxied" ones. 480 An operator that deploys MCP resources would like to control the 481 MPTCP connections it terminate. For example, an operator may want to 482 enforce a policy that consists in assisting only MPTCP connections 483 that are established by an upstream MCP, not those that are 484 established by an MPTCP host located behind a CPE. 486 Because MPTCP connections are not destined explicitly to an MCP, an 487 on-path MCP instance will need extra means to distinguish "native" 488 MPTCP connections from "proxied" ones. The subsequent risk is that 489 native MPTCP communications will be reverted to TCP connections as 490 shown in Figure 9 if the MCP is instructed to always relay MPTCP 491 connections to TCP ones. In this example, we suppose that C2 and S2 492 are MPTCP-capable, but C1 and S1 are not. 494 Upstream Downstream 495 +--+ +-----+ +-----+ +--+ 496 |C1| | MCP | | MCP | |S1| 497 +--+ +-----+ +-----+ +--+ 498 | | | | 499 |src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 | 500 |<-TCP Leg->|<========MPTCP Leg===========>|<-TCP Leg->| 501 | dst:s1@| | dst:s1@| 502 | | | | 504 \_________________SINGLE PATH CLIENT/SERVER_____________/ 505 _________________MULTIPLE PATH CLIENT/SERVER___________ 506 / \ 507 | | 508 | | | | 509 |src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 | 510 |<=MPTCP====|=============================>|<-TCP Leg->| 511 | dst:s2@| | dst:s2@| 512 | | | | 513 +--+ +-----+ +-----+ +--+ 514 |C2| | MCP | | MCP | |S2| 515 +--+ +-----+ +-----+ +--+ 516 Upstream Downstream 518 Figure 9: Example of a Broken E2E MPTCP Connection (On-path) 520 To mitigate this, the upstream MCP may be instructed to insert a 521 MP_PREFER_PROXY option only for the MPTCP connections it establishes 522 [I-D.boucadair-mptcp-plain-mode]. The absence of MP_PREFER_PROXY 523 option instances is an explicit indication that this MPTCP connection 524 is a native one. As such, an on-path MCP will not revert this 525 connection into a TCP connection, but will forward packets without 526 any modification to the next hop. 528 Figure 10 illustrates the results of such procedure: native MPTCP 529 connections are established between MPTCP-capable client and server, 530 while Network-Assisted MPTCP connections are established with the 531 help of MCPs. 533 Concretely, if the upstream MCP receives a SYN that includes the 534 MP_PREFER_PROXY option, it MAY decide to forward it towards its final 535 destination without modifying it. When the downstream MCP receives a 536 SYN that does not include an MP_PREFER_PROXY, it forwards it towards 537 its final destination. 539 Upstream Downstream 540 +--+ +-----+ +-----+ +--+ 541 |C1| | MCP | | MCP | |S1| 542 +--+ +-----+ +-----+ +--+ 543 | | | | 544 |src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 | 545 |<-TCP Leg->|<========MPTCP Leg(PP)=======>|<-TCP Leg->| 546 | dst:s1@| | dst:s1@| 547 | | | | 549 \_________________SINGLE PATH CLIENT/SERVER_____________/ 550 _________________MULTIPLE PATH CLIENT/SERVER___________ 551 / \ 552 | | 553 | | | | 554 |src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 | 555 |<==========|============MPTCP========================>| 556 | dst:s2@| | dst:s2@| 557 | | | | 558 +--+ +-----+ +-----+ +--+ 559 |C2| | MCP | | MCP | |S2| 560 +--+ +-----+ +-----+ +--+ 561 Upstream Downstream 563 Legend: 564 PP: MP_PREFER_PROXY 566 Figure 10: Example of a Successful E2E MPTCP Connection (On-path) 568 5.3. Authorization 570 The Network Provider that manages the various network attachments 571 (including the MCPs) may enforce authentication and authorization 572 policies using appropriate mechanisms. For example, a non-exhaustive 573 list of methods to achieve authorization is provided hereafter: 575 o The network provider may enforce a policy based on the 576 International Mobile Subscriber Identity (IMSI) to verify that a 577 user is allowed to benefit from the aggregation service. If that 578 authorization fails, the Packet Data Protocol (PDP) context 579 /bearer will not be mounted. This method does not require any 580 interaction with the MCP. 582 o The network provider may enforce a policy based upon Access 583 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 584 to control the CPEs that are authorized to communicate with an 585 MCP. These ACLs may be installed as a result of RADIUS exchanges, 586 for instance ([I-D.boucadair-mptcp-radius]). This method does not 587 require any interaction with the MCP. 589 o The MCP may implement an Ident interface [RFC1413] to retrieve an 590 identifier that will be used to assess whether that client is 591 entitled to make use of the aggregation service. Ident exchanges 592 will take place only when receiving the first subflow from a given 593 source IP address. 595 o The device that embeds the MCP may also host a RADIUS client that 596 will solicit an AAA server to check whether connections received 597 from a given source IP address are authorized or not 598 ([I-D.boucadair-mptcp-radius]). 600 A first safeguard against the misuse of MCP resources by illegitimate 601 users (e.g., users with access networks that are not managed by the 602 same service provider that operates the MCP) is to reject MPTCP 603 connections received on the Internet-facing interfaces. Only MPTCP 604 connections received on the customer-facing interfaces of an MCP will 605 be accepted. 607 Because only the CPE is entitled to establish MPTCP connections with 608 an MCP, ACLs may be installed on the CPE to avoid that internal 609 terminals issue MPTCP connections towards one of the MCPs. 611 5.4. MCP Behaviors 613 The MCP MUST be provided with instructions about the behavior to 614 adopt with regards to the processing of source addresses. The 615 following sub-sections elaborate on various schemes. 617 5.4.1. Transparent MCP 619 Transparent Network-Assisted MPTCP deployment is a deployment where 620 the visible source address of a packet forwarded by an MCP to a 621 remote machine located in the Internet is the IP address of the 622 endhost, not an address that is provisioned to the MCP. In order to 623 intercept incoming traffic, specific IPv4/IPv6 routes are injected so 624 that traffic is redirected towards the MCP. 626 No dedicated IP address pool is required to the MCP for the Network- 627 Assisted MPTCP service. 629 5.4.1.1. IPv4 Address Preservation 631 The MCP can be tweaked to behave in the IPv4 address preservation 632 mode. This is the IPv4 address assigned to the endhost (typically, 633 within a mobile deployment context as discussed in Section 4.1) or a 634 WAN address of the CPE for the wired case (Section 4.2). 636 5.4.1.2. Source IPv6 Prefix Preservation at Network-located MCP 638 Some IPv6 deployments may require the preservation of the source IPv6 639 prefix (Figure 11). 641 This model requires the MCP to support ALGs to accommodate 642 applications with IPv6 address referrals. 644 +--+ +-----+ +---+ +--+ 645 |H1| | MCP | |MCP| |RM| 646 +--+ +--+--+ +---+ +--+ 647 IP@s IP@1, IP@2 IP@mcf IP@d 648 | || | | 649 |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@1 | 650 |---------->||------------------------------------>|---------->| 651 | Dst:IP@d|| | dst:IP@d| 652 | || | | 653 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 654 |---ACK---->||----------------ACK----------------->|---ACK---->| 655 | || | | 657 Legend: 658 mcf: MCP Customer-facing Interface 660 Figure 11: Example of Source IPv6 Prefix Preservation at Network- 661 located MCP (Initial subflow) 663 5.4.1.3. Source IPv6 Address Preservation at Network-located MCP 665 Some IPv6 deployments may require the preservation of the source IPv6 666 address (Figure 12). 668 This model avoids the need for the MCP to support ALGs to accommodate 669 applications with IPv6 address referrals. 671 +--+ +-----+ +---+ +--+ 672 |H1| | MCP | |MCP| |RM| 673 +--+ +--++-+ +---+ +--+ 674 IP@s IP@1, IP@2 IP@mcf IP@d 675 | || | | 676 |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@s | 677 |---------->||------------------------------------>|---------->| 678 | Dst:IP@d|| | dst:IP@d| 679 | || | | 680 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 681 |---ACK---->||----------------ACK----------------->|---ACK---->| 682 | || | | 683 | || | | 685 Figure 12: Example of Outgoing SYN with Source Address Preservation 687 5.4.2. Non-Transparent MCP 689 Unlike the transport mode, this section focuses on deployments where 690 a dedicated IP address pool is provisioned to the MCP for the 691 Network-Assisted MPTCP service. 693 5.4.2.1. IPv4 Address Sharing at the at the Network-located MCP 695 Because of global IPv4 address depletion, optimization of the IPv4 696 address usage is mandatory. This obviously includes the IPv4 697 addresses that are assigned by the MCP at its Internet-facing 698 interfaces (Figure 13 and Figure 14). A pool of global IPv4 699 addresses is provisioned to the MCP along with possible instructions 700 about the address sharing ratio to apply (see Appendix B of 701 [RFC6269]). Adequate forwarding policies are enforced so that 702 traffic destined to an address of such pool is intercepted by the 703 appropriate MCP. 705 +--+ +---+ +--+ 706 |H1| |MCP| |RM| 707 +--+ +---+ +--+ 708 || | | 709 ||src:IP@s MP_CONVERT(D=0,IP@d) dst:IP@mcf|src:IP@mif | 710 ||-----------------------SYN--------------------->|---SYN---->| 711 || | dst:IP@d| 712 || | | 713 ||<--------------------SYN/ACK--------------------|<-SYN/ACK--| 714 ||-----------------------ACK--------------------->|---ACK---->| 715 || | | 717 Legend: 718 mcf: MCP Customer-facing Interface 719 mif: MCP Internet-facing Interface 721 Figure 13: Example of Outgoing SYN without Source Address 722 Preservation (Single-ended MCP) 724 +--+ +-----+ +---+ +--+ 725 |H1| | MCP | |MCP| |RM| 726 +--+ +--++-+ +---+ +--+ 727 | || | | 728 |src:IP@s ||src:IP@1 MP_CONVERT(D=0,IP@d) |src:IP@mif | 729 |---SYN---->||----------------SYN----------------->|---SYN---->| 730 | dst:IP@d|| dst:IP@mcf| dst:IP@d| 731 | || | | 732 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 733 |---ACK---->||----------------ACK----------------->|---ACK---->| 734 | || | | 736 Figure 14: Example of Outgoing SYN without Source Address 737 Preservation (Dual-ended MCPs) 739 5.4.2.2. IPv4 Address 1:1 Translation at the MCP 741 For networks that do not face global IPv4 address depletion yet, the 742 MCP can be configured so that source IPv4 addresses of the CPE are 743 replaced with other (public) IPv4 addresses. A pool of global IPv4 744 addresses is then provisioned to the MCP for this purpose. Rewriting 745 source IPv4 addresses may be used as a means to redirect incoming 746 traffic towards the appropriate MCP. 748 5.4.2.3. IPv6 Prefix Sharing (NPTv6) at the Network-located MCP 750 Rewriting the source IPv6 prefix ([RFC6296]) may be needed to 751 redirect incoming traffic towards the appropriate MCP. A pool of 752 IPv6 prefixes is then provisioned to the MCP for this purpose. 754 5.5. Address Family Considerations 756 Subflows of a given MPTCP connection can be associated to the same 757 address family or may be established with different address families. 758 Also, the Network-Assisted MPTCP using MP_CONVERT IE, regardless of 759 the addressing scheme enforced by each CPE network attachment. In 760 particular, the plain transport mode indifferently accommodates the 761 following combinations. 763 LAN Leg MPTCP Legs TCP Leg towards RM 764 ------- ----------- ------------------ 765 IPv4 IPv4 IPv4 766 IPv4 IPv6 IPv4 767 IPv4 IPv6 & IPv4 IPv4 768 IPv6 IPv6 IPv6 769 IPv6 IPv4 IPv6 770 IPv6 IPv6 & IPv4 IPv6 772 5.6. Policies & Configuration Parameters 774 5.6.1. Towards End-to-End MPTCP Connections 776 In order to promote the use of MPTCP end-to-end, the MCP MUST NOT 777 strip MP_CPABALE from the SYN segments it forwards to their final 778 destination (i.e., server). The communication leg between an MCP and 779 the server may be placed using MPTCP if that server is MPTCP-capable, 780 or falls back to TCP otherwise. 782 There may be cases where remote servers will not respond to SYN 783 segments with the MP_CAPABLE option, and therefore it is desirable to 784 provide a mechanism to disable relaying MP_CAPABLE to some or all 785 remote hosts. 787 Also, an MCP SHOULD maintain a cache to record the servers that are 788 known to cause excessive delays. Any subsequent connection to a 789 server that is present in this cache MUST be placed using TCP. Cache 790 entries MUST be flushed out after the expiry of a configurable timer; 791 this timer is set by default to 24h. 793 This default behavior would lead to the establishment of end-to-end 794 MPTCP connections if the client and servers are both MPTCP-capable 795 with or without the withdrawal of MCPs from the communication. 797 Whether an MCP must be maintained in the processing of an MPTCP 798 connection that involve MPTCP-capable clients and server is a 799 configurable parameter. The default mode MUST be to maintain the MCP 800 because its presence may solve several complications that may arise 801 in some deployments, such: 803 1. The use of private IPv4 addresses in some access networks. 804 Typically, additional subflows can not be added to the MPTCP 805 connection without the help of an MCP. 807 2. The assignment of IPv6 prefix only by some networks. If the 808 server is IPv4-only, subflows that are placed over IPv6 cannot be 809 added to an MPTCP connection towards that server. 811 3. Some of the access networks are subject to subscription with 812 volume quota. 814 Figure 15 shows an example of a communication with MCP withdrawal. 815 In this example, the MCP tracks the initial subflow. Upon receipt of 816 MP_CAPABLE in the SYN/ACK from the server, this connection is not 817 tracked any more by the proxy. Subsequent subflows are handled 818 directly by the endhost and the server. 820 For cases where some access networks are subject to a volume quota, 821 it is desirable to support a signal to indicate to a remote peer how 822 it must place data into available subflows. 824 ___________________ 825 / Host-based Model \ 826 \___________________/ 828 +----+ +-----+ +--+ 829 | H1 | | MCP | |RM| 830 +----+ +-----+ +--+ 831 h1@h2@ mcp@ rm@ 832 | | | | 833 | |src:h1 dst:rm@|src:h1 dst:rm@| 834 | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>| 835 | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===| 836 | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>| 837 | | __________________________________________________ | 838 | |/ Secondary subflow \| 839 | |=====================SYN+MP_JOIN====================>| 840 | |<===================SYN/ACK(MPJOIN)==================| 841 | |=====================ACK(MP_JOIN)===================>| 842 | | ... | 844 Figure 15: Sample Connection Establishment with MCP Withdrawal 845 (Implicit Mode) 847 If the MCP is instructed to be involved in the communication even if 848 the server is MPTCP-capable, the flow exchange depicted in Figure 16 849 will be observed. 851 ___________________ 852 / Host-based Model \ 853 \___________________/ 855 +----+ +-----+ +--+ 856 | H1 | | MCP | |RM| 857 +----+ +-----+ +--+ 858 h1@h2@ mcp@ rm@ 859 | | | | 860 |src:h1 dst:rm@|src:h1 dst:rm@| 861 |=======SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>| 862 |<=======SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===| 863 |=======ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>| 864 |<==============ADD_ADDR=====| | 865 | | ________________________ | | 866 | |/ Secondary subflow \| | 867 | |src:h2 dst=mcp@| | 868 | |========SYN+MP_JOIN======>| .... | 869 | |<======SYN/ACK(MPJOIN)====| | 870 | |======ACK(MP_JOIN)=======>| | 871 | | ... | | 873 Figure 16: Sample Connection Establishment with MCP Withdrawal 874 (Implicit Mode) 876 5.6.2. Traffic Distribution Scheme 878 The logic of traffic distribution over multiple paths is deployment- 879 specific. This document does not require nor preclude any particular 880 traffic distribution scheme. Nevertheless, MCPs MUST be configurable 881 with a parameter to indicate which traffic distribution scheme to 882 enable. Indeed, policies can be enforced by an MCP instance operated 883 by the Network Provider to manage both upstream and downstream 884 traffic. These policies may be subscriber-specific, connection- 885 specific, system-wise, or else. 887 5.6.3. Flows Eligible to Multipath Service 889 The Multipath Client and MCPs may be provided with a set of 890 classification policies to help electing flows for the MPTCP service. 891 These policies may be provisioned either statically and dynamically 892 (or a combination thereof). 894 Also, multiple MCPs may serve a given end-user, as a function of the 895 nature of the service or the traffic to be forwarded over MPTCP 896 connections. For example, an MCP may be used by a service provider 897 to proceed with CPE-targeted maintenance operations, whereas another 898 MCP may be configured to service multi-path communications initiated 899 by a set of end-users. 901 5.6.4. TCP Fragmentation 903 Methods to avoid TCP fragmentation, such as rewriting the TCP Maximum 904 Segment Size (MSS) option, must be supported by MCPs. 906 5.6.5. DSCP Preservation 908 The MCP MAY be configured to preserve the same DSCP marking or 909 enforce DSCP re-marking policies. DSCP preservation MUST be enabled 910 by default. 912 5.6.6. Supported Transport Protocols 914 The MCP supports TCP by design. Additional transport protocols 915 SHOULD be supported. A configuration parameter MUST be supported by 916 the MCP to indicate which transport protocols can be relayed into an 917 MPTCP connection. 919 5.6.7. Logging 921 If the MCP is used in global IPv4 address sharing environments, the 922 logging recommendations discussed in Section 4 of [RFC6888] need to 923 be considered. Security-related issues encountered in address 924 sharing environments are documented in Section 13 of [RFC6269]. A 925 configuration parameter should be supported to enable/disable the 926 logging function. 928 6. IANA Considerations 930 This document does not request any action from IANA. 932 7. Security Considerations 934 MPTCP-related security threats are discussed in [RFC6181] and 935 [RFC6824]. Additional considerations are discussed in the following 936 sub-sections. 938 7.1. Privacy 940 The MCP may have access to privacy-related information (e.g., IMSI, 941 link identifier, subscriber credentials, etc.). The MCP MUST NOT 942 leak such sensitive information outside a local domain. 944 7.2. Denial-of-Service (DoS) 946 Means to protect the MCP against Denial-of-Service (DoS) attacks MUST 947 be enabled. Such means include the enforcement of ingress filtering 948 policies at the network boundaries [RFC2827]. 950 In order to prevent the exhaustion of MCP's resources by establishing 951 a large number of simultaneous subflows for each MPTCP connection, 952 the MCP administrator SHOULD limit the number of allowed subflows per 953 CPE for a given connection. Means to protect against SYN flooding 954 attacks MUST also be enabled ([RFC4987]). 956 Attacks that originate outside of the domain can be prevented if 957 ingress filtering policies are enforced. Nevertheless, attacks from 958 within the network between a host and an MCP instance are yet another 959 actual threat. Means to ensure that illegitimate nodes cannot 960 connect to a network should be implemented. 962 7.3. Illegitimate MCP 964 Traffic theft is a risk if an illegitimate MCP is inserted in the 965 path. Indeed, inserting an illegitimate MCP in the forwarding path 966 allows traffic intercept and can therefore provide access to 967 sensitive data issued by or destined to a host. To mitigate this 968 threat, secure means to discover an MCP should be enabled. 970 7.4. High Rate Reassembly 972 The MCP may perform packet reassembly. Some security-related issues 973 are discussed in [RFC4963][RFC1858][RFC3128]. 975 8. Contributors 977 The following individuals contributed to this document: 979 Denis Behaghel 980 OneAccess 982 Email: Denis.Behaghel@oneaccess-net.com 984 Stefano Secci 985 Universite Pierre et Marie Curie 986 Paris 987 France 989 Email: stefano.secci@lip6.fr 990 Suresh Vinapamula 991 Juniper 992 1137 Innovation Way 993 Sunnyvale, CA 94089 994 USA 996 Email: Sureshk@juniper.net 998 SungHoon Seo 999 Korea Telecom 1000 Seoul 1001 Korea 1003 Email: sh.seo@kt.com 1005 Wouter Cloetens 1006 SoftAtHome 1007 Vaartdijk 3 701 1008 3018 Wijgmaal 1009 Belgium 1011 Email: wouter.cloetens@softathome.com 1013 Ullrich Meyer 1014 Vodafone 1015 Germany 1017 Email: ullrich.meyer@vodafone.com 1019 Luis M. Contreras 1020 Telefonica 1021 Spain 1023 Email: luismiguel.contrerasmurillo@telefonica.com 1025 Bart Peirens 1026 Proximus 1028 Email: bart.peirens@proximus.com 1030 9. Acknowledgements 1032 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 1033 Nishida, and Christoph Paasch for the comments. 1035 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 1036 Sri Gundavelli for the fruitful discussions held during the IETF#95 1037 meeting. 1039 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 1040 Xavier Grall for their valuable comments. 1042 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 1043 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 1044 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 1045 Srinivasan, and Raghavendra Mallya for the discussion. 1047 10. References 1049 10.1. Normative References 1051 [I-D.boucadair-mptcp-plain-mode] 1052 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1053 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1054 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1055 Contreras, L., and B. Peirens, "An MPTCP Option for 1056 Network-Assisted MPTCP", draft-boucadair-mptcp-plain- 1057 mode-09 (work in progress), October 2016. 1059 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1060 Requirement Levels", BCP 14, RFC 2119, 1061 DOI 10.17487/RFC2119, March 1997, 1062 . 1064 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1065 "TCP Extensions for Multipath Operation with Multiple 1066 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1067 . 1069 10.2. Informative References 1071 [I-D.boucadair-mptcp-dhc] 1072 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 1073 for Network-Assisted Multipath TCP (MPTCP)", draft- 1074 boucadair-mptcp-dhc-06 (work in progress), October 2016. 1076 [I-D.boucadair-mptcp-radius] 1077 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 1078 Network-Assisted Multipath TCP (MPTCP)", draft-boucadair- 1079 mptcp-radius-03 (work in progress), October 2016. 1081 [I-D.ietf-mptcp-experience] 1082 Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1083 Operational Experience with Multipath TCP", draft-ietf- 1084 mptcp-experience-07 (work in progress), October 2016. 1086 [I-D.ietf-mptcp-rfc6824bis] 1087 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1088 Paasch, "TCP Extensions for Multipath Operation with 1089 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-07 (work 1090 in progress), October 2016. 1092 [RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, 1093 DOI 10.17487/RFC1413, February 1993, 1094 . 1096 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1097 Considerations for IP Fragment Filtering", RFC 1858, 1098 DOI 10.17487/RFC1858, October 1995, 1099 . 1101 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1102 Defeating Denial of Service Attacks which employ IP Source 1103 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1104 May 2000, . 1106 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1107 Fragment Attack (RFC 1858)", RFC 3128, 1108 DOI 10.17487/RFC3128, June 2001, 1109 . 1111 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1112 Errors at High Data Rates", RFC 4963, 1113 DOI 10.17487/RFC4963, July 2007, 1114 . 1116 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1117 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1118 . 1120 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1121 Multipath Operation with Multiple Addresses", RFC 6181, 1122 DOI 10.17487/RFC6181, March 2011, 1123 . 1125 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1126 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1127 DOI 10.17487/RFC6269, June 2011, 1128 . 1130 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1131 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1132 . 1134 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 1135 A., and H. Ashida, "Common Requirements for Carrier-Grade 1136 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 1137 April 2013, . 1139 [RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental 1140 TCP Option for Host Identification", RFC 7974, 1141 DOI 10.17487/RFC7974, October 2016, 1142 . 1144 Authors' Addresses 1146 Mohamed Boucadair (editor) 1147 Orange 1148 Rennes 35000 1149 France 1151 Email: mohamed.boucadair@orange.com 1153 Christian Jacquenet (editor) 1154 Orange 1155 Rennes 1156 France 1158 Email: christian.jacquenet@orange.com 1160 Olivier Bonaventure (editor) 1161 Tessares 1162 Belgium 1164 Email: olivier.bonaventure@tessares.net 1165 Wim Henderickx (editor) 1166 Nokia/Alcatel-Lucent 1167 Belgium 1169 Email: wim.henderickx@alcatel-lucent.com 1171 Robert Skog (editor) 1172 Ericsson 1174 Email: robert.skog@ericsson.com