idnits 2.17.1 draft-kanugovi-intarea-mams-framework-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 : ---------------------------------------------------------------------------- ** There are 150 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1662 has weird spacing: '...isallow use|...' == Line 1698 has weird spacing: '...isallow use|...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The framework MUST leverage commonly available routing and tunneling capabilities to provide user plane interworking functionality. The addition of functional elements in the user plane path between the client and the network MUST not impact the access technology specific procedures. This makes solution easy to deploy and scale when different networks are added and removed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When switching data traffic from one path (connection) to another, packets may be lost or delivered out-of-order, which will have negative impacts on the performance of higher layer protocols, e.g. TCP. The framework SHOULD provide necessary mechanisms to ensure in-order delivery at the receiver, e.g. during path switching. The framework MUST not cause any packet loss beyond that of access network mobility functions may cause. -- The document date (April 11, 2018) is 2207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6455' is mentioned on line 1820, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1820, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6347' is defined on line 1948, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 1952, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-zhu-intarea-mams-user-protocol-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA S. Kanugovi 3 Internet-Draft Nokia 4 Intended status: Informational F. Baboescu 5 Expires: October 13, 2018 Broadcom 6 J. Zhu 7 Intel 8 J. Mueller 9 AT&T 10 S. Seo 11 Korea Telecom 12 April 11, 2018 14 Multiple Access Management Services 15 draft-kanugovi-intarea-mams-framework-01 17 Abstract 19 In multiconnectivity scenarios the end-user devices can 20 simultaneously connect to multiple networks based on different access 21 technologies and network architectures like WiFi, LTE, DSL. Both the 22 quality of experience of the users and the overall network 23 utilization and efficiency may be improved through a smart selection 24 and combination of access and core network paths that can dynamically 25 adapt to changing network conditions. This document presents the 26 problem statement and proposes solution principles. It specifies the 27 requirements and architecture for the multi-access management 28 services framework that can be used to 1) flexibly select the best 29 combination of access and core network paths for uplink and downlink, 30 as well as 2) determining the user plane treatment and traffic 31 distribution over the selected links ensuring better network 32 efficiency and enhanced application performance. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 13, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Access technology agnostic interworking . . . . . . . . . 6 72 4.2. Support common transport deployments . . . . . . . . . . 6 73 4.3. Independent Access path selection for Uplink and Downlink 6 74 4.4. Core selection independent of uplink and downlink access 7 75 4.5. Adaptive network path selection . . . . . . . . . . . . . 7 76 4.6. Multipath support and Aggregation of access link 77 capacities . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.7. Scalable mechanism based on user plane interworking . . . 7 79 4.8. Separate Control and Data plane functions . . . . . . . . 7 80 4.9. Lossless Path (Connection) Switching . . . . . . . . . . 8 81 4.10. Concatenation and Fragmentation to adapt to MTU 82 differences . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.11. Configuring network middleboxes based on negotiated 84 protocols . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.12. Policy based Optimal path selection . . . . . . . . . . . 8 86 4.13. Access Technology Agnostic Control signaling . . . . . . 9 87 4.14. Service discovery and reachability . . . . . . . . . . . 9 88 5. Solution Principles . . . . . . . . . . . . . . . . . . . . . 9 89 6. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 9 90 7. MAMS Protocol Architecture . . . . . . . . . . . . . . . . . 12 91 7.1. MAMS Control-Plane Protocol . . . . . . . . . . . . . . . 12 92 7.2. MAMS User Plane Protocol . . . . . . . . . . . . . . . . 13 93 8. MAMS Control Plane Procedures . . . . . . . . . . . . . . . . 15 94 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 95 8.2. Common fields in MAMS Control Messages . . . . . . . . . 17 96 8.3. Common procedures for MAMS Control Messages . . . . . . . 17 97 8.3.1. Message Timeout . . . . . . . . . . . . . . . . . . . 17 98 8.3.2. Keep Alive Procedure . . . . . . . . . . . . . . . . 17 99 8.4. Discovery & Capability Exchange . . . . . . . . . . . . . 18 100 8.5. User Plane Configuration . . . . . . . . . . . . . . . . 22 101 8.6. MAMS Path Quality Estimation . . . . . . . . . . . . . . 26 102 8.7. MAMS Traffic Steering . . . . . . . . . . . . . . . . . . 27 103 8.8. MAMS Application MADP Association . . . . . . . . . . . . 28 104 8.9. MAMS Network ID Indication . . . . . . . . . . . . . . . 30 105 8.10. MAMS Client Measurement Configuration and Reporting . . . 30 106 8.11. MAMS Session Termination Procedure . . . . . . . . . . . 33 107 9. Generic MAMS Signaling Flow . . . . . . . . . . . . . . . . . 34 108 10. Applying MAMS Control Procedures with MPTCP Proxy as User 109 Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 110 11. Applying MAMS Control Procedures for Network Assisted Traffic 111 Steering when there is no convergence layer . . . . . . . . . 40 112 12. Co-existence of MX Adaptation and MX Convergence Layers . . . 42 113 13. Security Considerations . . . . . . . . . . . . . . . . . . . 42 114 13.1. MAMS Control plane security . . . . . . . . . . . . . . 42 115 13.2. MAMS User plane security . . . . . . . . . . . . . . . . 43 116 14. Implementation considerations . . . . . . . . . . . . . . . . 43 117 15. Applicability to Multi Access Edge Computing . . . . . . . . 43 118 16. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44 119 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 120 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 121 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 122 19.1. Normative References . . . . . . . . . . . . . . . . . . 44 123 19.2. Informative References . . . . . . . . . . . . . . . . . 44 124 Appendix A. MAMS Control Plane Optimization over Secure 125 Connections . . . . . . . . . . . . . . . . . . . . 46 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 128 1. Introduction 130 Multi Access Management Services (MAMS) is a programmable framework 131 that provides mechanisms for flexible selection of network paths in a 132 multi-access communication environment, based on application needs. 133 It leverages network intelligence and policies to dynamically adapt 134 traffic distribution across selected paths and user plane treatment 135 to changing network/link conditions. The network path selection and 136 configuration messages are carried as user plane data between the 137 functional elements in the network and the end-user device, and thus 138 without any impact to the control plane signaling schemes of the 139 individual access network. For example, in a multi-access network 140 with LTE and WiFi technologies, existing LTE and existing WiFi 141 signaling procedures will be used to setup the LTE and WiFi 142 connections, respectively, and MAMS specific control plane messages 143 are carried as LTE or WiFi user plane data. The proposed MAMS 144 framework offers the capabilities of smart selection and flexible 145 combination of access paths and core network paths, as well as the 146 user plane treatment when the traffic is distributed across the 147 selected paths. Thus, it is a broad programmable framework providing 148 functions beyond just sharing network policies, e.g. ANDSF that 149 provides policies/rules for assisting 3GPP devices to discover and 150 select available access networks. Further, it allows choosing and 151 configuring user plane treatment for the traffic over the multiple 152 paths, depending on needs of the application. 154 The document presents the requirements, solution principles, 155 functional architecture, and protocols for realizing the MAMS 156 framework. MAMS mechanisms are not dependent on any specific access 157 network type or user plane protocols like TCP, UDP, GRE, MPTCP etc. 158 It co-exists and complements the existing protocols by providing a 159 way to negotiate and configure these protocols based on client and 160 network capabilities to match the multi-access scenario. Further it 161 allows exchanges of network state information and leveraging network 162 intelligence to optimize the performance of such protocols. 164 An important goal for MAMS is to ensure that it either requires 165 minimum dependency or (better) no dependency on the actual access 166 technologies of the participating links, beyond the fact that MAMS 167 functional elements form an IP-overlay across the multiple paths. 168 This allows the scheme to be future proof by allowing independent 169 technology evolution of the existing access and core networks as well 170 as, seamless integration of new access technologies. 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 "Client": The end-user device supporting connections with multiple 179 access nodes, possibly over different access technologies. 181 "Multiconnectivity Client": A client with multiple network 182 connections. 184 "Access network": The segment in the network that delivers user data 185 packets to the client via an access link like WiFi airlink, LTE 186 airlink, or DSL. 188 "Core": The functional element that anchors the client IP address 189 used for communication with applications via the network. 191 "Network Connection manager"(NCM): A functional entity in the network 192 that handles MAMS control messages from the client and configures 193 distribution of data packets over the multiple available access and 194 core network paths, and user plane treatment of the traffic flows. 196 "Client Connection Manager" (CCM): A functional entity in the client 197 that exchanges MAMS Signaling with the Network Connection Manager and 198 configures the multiple network paths at the client for transport of 199 user data. 201 "Network Multi Access Data Proxy" (N-MADP): This functional entity in 202 the network handles the user data traffic forwarding across multiple 203 network paths. N-MADP is responsible for MAMS related user-plane 204 functionalities in the network. 206 "Client Multi Access Data Proxy" (C-MADP): This functional entity in 207 the client handles the user data traffic forwarding across multiple 208 network paths. C-MADP is responsible for MAMS related user-plane 209 functionalities in the client. 211 "Anchor Connection": Refers to the network path from the N-MADP to 212 the user plane gateway (IP anchor ) that has assigned an IP address 213 to the client. 215 "Delivery Connection": Refers to the network path from the N-MADP to 216 the client. 218 3. Problem Statement 220 Typically, an end-user device has access to multiple communication 221 networks based on different technologies, say LTE, WiFi, DSL, 222 MuLTEfire, for accessing application services. Different 223 technologies exhibit benefits and limitations in different scenarios. 224 For example, WiFi provides high throughput for end users when under 225 good coverage, but the throughput degrades significantly as the user 226 moves closer to the edge of WiFi coverage (typically in the range of 227 few tens of meters) or with large user population (due to contention 228 based WiFi access scheme). In LTE networks, the capacity is often 229 constrained by the limited availability of licensed spectrum. 230 However, the quality of the service is predictable even in multi-user 231 scenarios due to controlled scheduling and licensed spectrum usage. 233 Additionally, the use of a particular access network path is often 234 coupled with the use of its associated core network and the services 235 that are offered by it. For example, in an enterprise that has 236 deployed both WiFi and LTE networks, the enterprise services, like 237 printers, Corporate Audio and Video conferencing, are accessible only 238 via WiFi access connected to the enterprise hosted (WiFi) core, 239 whereas the LTE access can be used to get operator core anchored 240 services including access to public Internet. 242 Thus, application performance in different scenarios becomes 243 dependent on the choice of the access networks (e.g. WiFi, LTE, 244 etc.) because of the coupling of the access and the core network 245 paths. Therefore, to achieve the best possible application 246 performance in a wide range of scenarios, a framework is needed that 247 allows the selection and flexible combination of access and core 248 network paths for uplink and downlink data delivery. 250 For example, to ensure best performance for enterprise applications 251 at all times, in uncongested scenarios, when the user is under good 252 WiFi coverage, it would be beneficial to use WiFi access in both 253 uplink and downlink for connecting to enterprise applications. 254 However in congested scenarios or when the user is getting close to 255 the edge of its WiFi coverage, the use of WiFi in uplink by multiple 256 users can lead to degraded capacity and increased delays due to 257 contention. In this case, it would be beneficial to at least use the 258 LTE access for increased uplink coverage while WiFi may still 259 continue to be used for downlink 261 4. Requirements 263 The requirements set out in this section are for the definition of 264 behavior of the MAMS mechanism and the related functional elements. 266 4.1. Access technology agnostic interworking 268 The access nodes may use different technology types like LTE, WiFi, 269 etc. The framework, however, MUST agnostic to the type of underlying 270 technology used at the access network. 272 4.2. Support common transport deployments 274 The network path selection and user data distribution MUST work 275 transparently across various transport deployments that include e2e 276 IPsec, VPNs, and middleboxes like NATs and proxies. 278 4.3. Independent Access path selection for Uplink and Downlink 280 Client should be able to transmit on the uplink and, receive on the 281 downlink, using one or more accesses. The selection of the access 282 paths for uplink and downlink SHOULD happen independent of each 283 other. 285 4.4. Core selection independent of uplink and downlink access 287 A client SHOULD flexibly select the Core, independent of the access 288 paths used to reach the Core, depending on the application needs, 289 local policies and the result of MAMS control plane negotiation. 291 4.5. Adaptive network path selection 293 The framework MUST have the ability to determine the quality of each 294 of the network paths, e.g. access link delay and capacity. The 295 network path quality information needs to be considered in the logic 296 for selection of the combination of network paths to be used for 297 transporting user data. The path selection algorithm can use network 298 path quality information, in addition to other considerations like 299 network policies, for optimizing network usage and enhancing QoE 300 delivered to the user. 302 4.6. Multipath support and Aggregation of access link capacities 304 The framework MUST support distribution and aggregation of user data 305 across multiple network paths at the IP layer. The client SHOULD be 306 able to leverage the combined capacity of the multiple network 307 connections by enabling simultaneous transport of user data over 308 multiple network paths. If required, packet re-ordering needs to be 309 done at the receiver. The framework MUST allow flexibility to choose 310 the flow steering and aggregation protocols based on capabilities 311 supported by the client and the network data plane entities. The 312 multi-connection aggregation solution MUST support existing transport 313 and network layer protocols like TCP, UDP, GRE. The framework MUST 314 allow use and configuration of existing aggregation protocols such as 315 Multi-Path TCP(MPTCP) and SCTP. 317 4.7. Scalable mechanism based on user plane interworking 319 The framework MUST leverage commonly available routing and tunneling 320 capabilities to provide user plane interworking functionality. The 321 addition of functional elements in the user plane path between the 322 client and the network MUST not impact the access technology specific 323 procedures. This makes solution easy to deploy and scale when 324 different networks are added and removed. 326 4.8. Separate Control and Data plane functions 328 The client MUST use the control plane protocol to negotiate with the 329 network, the choice of access and core network paths for both uplink 330 and downlink, as well as the user plane protocol treatment. The 331 control plane MUST configure the actual user plane data distribution 332 function per this negotiation. A common control protocol SHOULD 333 allow creation of multiple user plane function instance with 334 potentially different user plane (e.g. tunneling) protocol types. 335 This enables maintaining a clear separation between the control and 336 data plane functions, allowing the framework to be scalable and 337 extensible, e.g. using SDN based architecture and implementations. 339 4.9. Lossless Path (Connection) Switching 341 When switching data traffic from one path (connection) to another, 342 packets may be lost or delivered out-of-order, which will have 343 negative impacts on the performance of higher layer protocols, e.g. 344 TCP. The framework SHOULD provide necessary mechanisms to ensure in- 345 order delivery at the receiver, e.g. during path switching. The 346 framework MUST not cause any packet loss beyond that of access 347 network mobility functions may cause. 349 4.10. Concatenation and Fragmentation to adapt to MTU differences 351 Different network paths may have different security and middlebox 352 (e.g NAT) configurations, which will lead to use of different 353 tunneling protocols for transport of data between the network user 354 plane function and the client. As a result, different effective 355 payload sizes (e.g. due to variable encapsulation header overheads) 356 per network path are possible. Hence, MAMS framework SHOULD support 357 fragmentation of a single IP packet payload across MTU sized IP 358 packets to avoid IP fragmentation when aggregating packets from 359 different paths. Further, concatenation of multiple IP packets into 360 a single IP packet to improve efficiency in packing the MTU size 361 should also be supported. 363 4.11. Configuring network middleboxes based on negotiated protocols 365 The framework SHOULD enable identification of the optimal parameters 366 that may be used for configuring the middle-boxes, like radio link 367 dormancy timers, binding expiry times and supported MTUs, for 368 efficient operation of the user plane protocols, based on parameters 369 negotiated between the client and the network, e.g. Configuring 370 longer binding expiry time in NATs when UDP transport is used in 371 contrast to the scenario where TCP is configured at the transport 372 layer. 374 4.12. Policy based Optimal path selection 376 The framework MUST support consideration of policies at the client, 377 in addition to guidance from the network, for network path selection 378 addressing different application requirements. 380 4.13. Access Technology Agnostic Control signaling 382 The control plane signaling MUST NOT be dependent on the underlying 383 access technology procedures, e.g. be carried transparently as user 384 plane. It should support delivery of control plane signaling over 385 the existing Internet protocols, e.g. TCP or UDP. 387 4.14. Service discovery and reachability 389 There can be multiple instances of the control and user plane 390 functional elements of the framework, either collocated or hosted on 391 separate network elements, and reachable via any of the available 392 user plane paths. The client MUST have flexibility to choose the 393 appropriate control plane instance in the network and use the control 394 plane signaling to choose the desired user plane functional element 395 instances. The choice can be based on considerations like, but not 396 limited to, quality of link through which the network function is 397 reachable, client preferences, pre-configuration etc. 399 5. Solution Principles 401 This document proposes the Multiple Access Management Services(MAMS) 402 framework for dynamic selection and flexible combination of access 403 and core network paths independently for the uplink and downlink, as 404 well as the user plane treatment for the traffic spread across the 405 selected links. MAMS framework consists of clearly separated control 406 and user plane functions in the network and the client. The control 407 plane protocol allows configuration of the user plane protocols and 408 desired network paths for transport of application traffic. The 409 control plane messages are carried as user plane data over any of the 410 available network paths between the peer control plane functional 411 elements in the client and the network . The selection of paths and 412 user plane treatment of the traffic, is based on negotiation of 413 capabilities (of device and network) and network link quality between 414 the user plane functional elements at the end-user device/client and 415 the network. The framework enables leveraging network intelligence 416 to setup and dynamically configure the best network path combination 417 based on device and network capabilities, application needs and 418 knowledge of the network state. 420 6. MAMS Reference Architecture 421 +--------------------------------------------------------+ 422 | +---------------+ +---------------+ | 423 | ! ! ! ! | 424 | !Core(IP anchor)! +---+ !Core(IP anchor)! | 425 | !network 1 ! !(network 'n' ! | 426 | ! ! ! ! | 427 | +---------------+ +---------------+ | 428 | \ / | 429 | Anchor \ +---+ Anchor | 430 | Connection 1 Connection 'n' | 431 | \ / | 432 | +---------------+\+---+/+------+ | 433 | | |-----+ +----------+ | | 434 | +----|NCM ! | N-MADP | | | 435 | | | |-----+ +----------+ | | 436 | | +------------------------------+ | 437 | | / \ | 438 | Control Plane Delivery +----+Delivery | 439 | Path (over any Connection 1 Connection 'n' | 440 | access user plane) / \ | 441 | | / \ | 442 | +------------------+ +---------------+ | 443 | | | Access | +---+ | Access | | 444 | | | n/w 1 | | n/w 'n' | | 445 | +------------------+ +---------/-----+ | 446 +-----------------------------\----------------/---------+ 447 | \ / 448 | +---- -\------------/-+ 449 | | +---+ \ |------+ / | 450 +------------+CCM | \|C-MADP|/ | 451 | +---+ +------+ | 452 | Client | 453 +---------------------+ 455 Figure 1: MAMS Reference Architecture 457 Figure 1 illustrates MAMS architecture for the scenario of a client 458 served by multiple (n) networks. It introduces the following 459 functional elements, 461 o Network Connection Manager (NCM) and Client Connection Manager 462 (CCM) in the control plane, and 463 o Network Multi Access Data Proxy (N-MADP) and Client Multi Access 464 Data Proxy (C-MADP) handling the user plane. 466 NCM: It is the functional element in the network that handles the 467 MAMS control plane procedures. It configures the network (N-MADP) 468 and client (C-MADP) user plane functions like negotiating the client 469 on the use of available access network paths, protocols and rules for 470 processing the user plane traffic, as well as link monitoring 471 procedures. The control plane messages between the NCM and CCM are 472 transported as an overlay, without any impact to the underlying 473 access networks. 475 CCM: It is the peer functional element in the client for handling 476 MAMS control plane procedures. It manages multiple network 477 connections at the client. It is responsible for exchange of MAMS 478 signaling messages with the NCM for supporting functions like UL and 479 DL user network path configuration for transporting user data 480 packets, link probing and reporting to support adaptive network path 481 selection by NCM. In the downlink, for the user data received by the 482 client, it configures C-MADP such that application data packet 483 received over any of the accesses to reach the appropriate 484 application on the client. In the uplink, for the data transmitted 485 by the client, it configures the C-MADP to determine the best access 486 links to be used for uplink data based on a combination of local 487 policy and network policy delivered by the NCM. 489 N-MADP: It is the functional element in the network that handles the 490 user data traffic forwarding across multiple network paths, as well 491 as other user-plane functionalities like encapsulation, 492 fragmentation, concatenation, reordering, retransmission, etc. It is 493 the distribution node that routes the uplink user plane traffic to 494 the appropriate anchor connection towards the core network, and the 495 downlink user traffic to the client over the appropriate delivery 496 connection(s). In the downlink, the NCM configures the use of 497 delivery connections, and user plane protocols at the N-MADP for 498 transporting user data traffic. The N-MADP should implement ECMP 499 support for the down link traffic. Or alternatively, it may be 500 connected to a router with ECMP functionality. The load balancing 501 algorithm at the N-MADP is configured by the NCM, based on static 502 and/or dynamic network policies like assigning access and core paths 503 for specific user data traffic type, data volume based percentage 504 distribution, and link availability and feedback information from 505 exchange of MAMS signaling with the CCM at the Client.. N-MADP can be 506 configured with appropriate user plane protocols to support both per- 507 flow and per-packet traffic distribution across the delivery 508 connections. In the uplink, N-MADP selects the appropriate anchor 509 connection over which to forward the user data traffic, received from 510 the client (via the delivery connections). The forwarding rules in 511 the uplink at the N-MADP are configured by the NCM based on 512 application requirements, e.g. Enterprise hosted Application flows 513 via Wi-Fi Anchor, Mobile Operator hosted applications via the 514 Cellular Core. 516 C-MADP: It is the functional element in the client that handles the 517 MAMS user plane data procedures. C-MADP is configured by CCM based 518 on signaling exchange with NCM and local policies at the client. The 519 CCM configures the selection of delivery connections and the user 520 plane protocols to be used for uplink user data traffic based on the 521 signaling exchanged with NCM. The C-MADP entity handles user plane 522 data forwarding across multiple delivery connections and associated 523 user-plane functions like encapsulation, fragmentation, 524 concatenation, reordering, retransmissions, etc. 526 The NCM and N-MADP can be either collocated or instantiated on 527 different network nodes. NCM can setup multiple N-MADP instances in 528 the network. NCM controls the selection of N-MADP instance by the 529 client and the rules for distribution of user traffic across the 530 N-MADP instances., This is beneficial in multple deployment 531 scenarios, like the following examples. 533 o Different N-MADP instances to handle different sets of clients for 534 load balancing across clients 535 o Address deployment topologies e.g. N-MADP hosted at the user 536 plane node at the access edge or in the core network, while the 537 NCM hosted at the access edge node) 538 o Address access network technology architecture. For exanple, 539 N-MADP instance at core network node to manage traffic 540 distribution across LTE and DSL networks, and N-MADP instance at 541 access network node to manage traffic distribution across LTE and 542 Wi-Fi traffic. 543 o A single client can be configured to use multiple N-MADP 544 instances. This is beneficial in addressing different application 545 requirements. For example, separate N-MADP instances to handle 546 TCP and UDP transport based traffic. 548 Thus, MAMS architecture flexibly addresses multiple network 549 deployments. 551 7. MAMS Protocol Architecture 553 This section describes the protocol structure for the MAMS User and 554 Control plane functional elements. 556 7.1. MAMS Control-Plane Protocol 558 Figure 2 shows the default MAMS control plane protocol stack. 559 WebSocket is used for transporting management and control messages 560 between NCM and CCM. 562 +------------------------------------------+ 564 | Multi Access (MX) Control Message | 566 | | 568 +------------------------------------------+ 570 | WebSocket | 572 | | 574 +------------------------------------------+ 576 | TCP/TLS | 578 | | 580 +------------------------------------------+ 582 Figure 2: TCP-based MAMS Control Plane Protocol Stack 584 7.2. MAMS User Plane Protocol 586 Figure 3 shows the MAMS user plane protocol stack. 588 +-----------------------------------------------------+ 590 | User Payload (e.g. IP PDU) | 592 +-----------------------------------------------------+ 594 +-----------------------------------------------------------+ 596 | +-----------------------------------------------------+ | 598 | | Multi Access (MX) Convergence Sublayer | | 600 | +-----------------------------------------------------+ | 602 | +-----------------------------------------------------+ | 604 | | MX Adaptation | MX Adaptation | MX Adaptation | | 606 | | Sublayer | Sublayer | Sublayer | | 608 | | (optional) | (optional) | (optional) | | 610 | +----------------++--------------+-+------------------+ | 612 | | Access #1 IP | Access #2 IP | Access #3 IP | | 614 | +-----------------------------------------------------+ | 616 | MAMS User Plane Protocol Stack| 618 +-----------------------------------------------------------+ 620 Figure 3: MAMS User Plane Protocol Stack 622 It consists of the following two Sublayers: 624 o Multi-Access (MX) Convergence Sublayer: The MAMS framework 625 configures the Convergence sublayer to perform multi-access 626 specific tasks in the user plane. This layer performs functions 627 like access (path) selection, multi-link (path) aggregation, 628 splitting/reordering, lossless switching, fragmentation, 629 concatenation, etc. MX Convergence layer can be implemented using 630 existing user plane protocols like MPTCP or by adapting 631 encapsulating header/trailer schemes (e.g Trailer Based MX 632 Convergence as specified in [I-D.zhu-intarea-mams-user-protocol]). 633 o Multi-Access (MX) Adaptation Sublayer: The MAMS framework 634 configures the Adaptation Sublayer to address transport network 635 related aspects like reachability and security in the user plane. 636 This layer performs functions to handle tunnelling, network layer 637 security, and NAT. MX Adaptation can be implemented using IPsec, 638 DTLS or Client NAT (Source NAT at Client with inverse mapping at 639 N-MADP [I-D.zhu-intarea-mams-user-protocol]). The MX Adaptation 640 Layer is optional and can be independently configured for each of 641 the Access Links. E.g. In a deployment with LTE (assumed secure) 642 and Wi-Fi (assumed not secure), the MX Adaptation Sublayer can be 643 omitted for the LTE link but MX Adaptation Sublayer is configured 644 as IPsec for securing the Wi-Fi link. Further details on the MAMS 645 user plane are described in [I-D.zhu-intarea-mams-user-protocol]. 647 8. MAMS Control Plane Procedures 649 8.1. Overview 651 CCM and NCM exchange signaling messages to configure the user plane 652 functions, C-MADP and N-MADP, at the client and network respectively. 653 The means for CCM to obtain the NCM credentials (FQDN or IP Address) 654 for sending the initial discovery messages are out of the scope of 655 MAMS document. As an example, the client can obtain the NCM 656 credentials using methods like provisioning, DNS query. Once the 657 discovery process is successful, the (initial) NCM can update and 658 assign additional NCM addresses for sending subsequent control plane 659 messages. 661 CCM discovers and exchanges capabilities with the NCM. NCM provides 662 the credentials of the N-MADP end-point and negotiates the parameters 663 for user plane with the CCM. CCM configures C-MADP to setup the user 664 plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based 665 on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, 666 Associated Core Network Path), and the parameters exchanged with the 667 NCM. Further, NCM and CCM exchange link status information to adapt 668 traffic steering and user plane treatment with dynamic network 669 conditions. The key procedures are described in details in the 670 following sub-sections. 672 +-----+ +-----+ 674 | CCM | | NCM | 676 +--+--+ +--+--+ 678 | Discovery and | 680 | Capability | 682 | Exchange | 684 <----------------------> 686 | | 688 | User Plane | 690 | Protocols | 692 | Setup | 694 <----------------------> 696 | Path Quality | 698 | Estimation | 700 <----------------------> 702 | Network capabilities | 704 | e.g. RNIS[ETSIRNIS] | 706 <----------------------+ 708 | | 710 | Network policies | 712 <----------------------+ 714 + + 716 Figure 4: MAMS Control Plane Procedures 718 8.2. Common fields in MAMS Control Messages 720 Each MAMS control message consists of the following common fields: 722 o Version: indicates the version of MAMS control protocol. 723 o Message Type: indicates the type of the message, e.g. MX 724 Discovery, MX Capability REQ/RSP etc. 725 o Sequence Number: auto-incremented integer to uniquely identify a 726 transaction of message exchange, e.g. MX Capability REQ/RSP. 728 8.3. Common procedures for MAMS Control Messages 730 This section describes the common procedures for MAMS Control 731 Messages. 733 8.3.1. Message Timeout 735 MAMS Control plane peer (NCM or CCM) waits for a duration of 736 MAMS_TIMEOUT ms, after sending a MAMS control message, before timing 737 out when expecting a response. The sender of the message will 738 retransmit the message for MAMS_RETRY times before declaring failure. 739 A failure implies that the MAMS peer is dead, and the sender reverts 740 back to native non-multi access/single path mode. CCM may initiate 741 the MAMS discovery procedure for re-establishment of the MAMS 742 session. 744 8.3.2. Keep Alive Procedure 746 MAMS Control plane peers execute the keep alive procedures to ensure 747 that peers are reachable and to recover from dead-peer scenarios. 748 Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer 749 that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE 750 timer is reset whenever the peer receives a MAMS Control message. 751 When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is 752 sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver 753 responds with a MAMS KEEP ALIVE RSP message. If the sender does not 754 receive a MAMS Control message in response to MAMS_RETRY number of 755 retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that 756 the peer is dead. CCM may initiate MAMS Discovery procedure for re- 757 establishment of the MAMS session. 759 CCM shall additionally send MX KEEP ALIVE REQ message immediately to 760 NCM whenever it detects a handover from one base station/access point 761 to another. During this time the user equipment shall stop using 762 MAMS user plane functionality in uplink direction till it receives a 763 MX KEEP ALIVE RSP from NCM. 765 MX KEEP ALIVE REQ includes following information: 767 o Reason: Can be 'Timeout' or 'Handover'. Reason 'Handover' shall 768 be used by CCM only on detection of handover. 769 o Unique Session Identifier: As defined in Section 8.4. 770 o Connection Id: This field shall be mandatorily be included if the 771 reason is 'Handover'. 772 o Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC 773 address in case of WiFi). This field shall be mandatorily be 774 included if the reason is 'Handover'. 776 8.4. Discovery & Capability Exchange 778 Figure 5 shows the MAMS discovery and capability exchange procedure 779 consisting of the following key steps: 781 CCM NCM 783 | | 785 +------- MX Discovery Message ---------------------->| 787 | +-----------------+ 789 | |Learn CCM | 790 | | IP address | 792 | |& port | 794 | +-----------------+ 796 | | 798 |<--------------------------------MX System INFO-----| 800 | | 802 |---------------------------------MX Capability REQ->| 804 |<----- MX Capability RSP----------------------------| 806 |---------------------------------MX Capability ACK->| 807 | | 809 + + 811 Figure 5: MAMS Control Procedure for Discovery & Capability Exchange 813 Step 1 (Discovery): CCM periodically sends out the MX Discovery 814 Message to a pre-defined (NCM) IP Address/port until MX System INFO 815 message is received in acknowledgement. 817 MX Discovery Message includes the following information: 819 o MAMS Version 821 MX System INFO includes the following information: 823 o Number of Anchor Connections 825 For each Anchor Connection, it includes the following parameters: 827 * Connection ID: Unique identifier for the Anchor Connection 828 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 829 LTE) 830 * NCM Endpoint Address (For Control Plane Messages over this 831 connection) 833 + IP Address or FQDN (Fully Qualified Domain Name) 834 + Port Number 836 Step 2 (Capability Exchange): On receiving MX System Info message CCM 837 learns the IP Address and port to start the step 2 of the control 838 plane connection, and sends out the MX Capability REQ message, 839 including the following Parameters: 841 o MX Feature Activation List: Indicates if the corresponding feature 842 is supported or not, e.g. lossless switching, fragmentation, 843 concatenation, Uplink aggregation, Downlink aggregation, 844 Measurement, probing, etc. 845 o Number of Anchor Connections (Core Networks) 847 For each Anchor Connection, it includes the following parameters: 849 * Connection ID 850 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 851 LTE) 852 o Number of Delivery Connections (Access Links) 854 For each Delivery Connection, it includes the following 855 parameters: 857 * Connection ID 858 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 859 LTE) 860 o MX Convergence Method Support List 862 * Trailer-based MX Convergence 863 * MPTCP Proxy 864 * GRE Aggregation Proxy 865 o MX Adaptation Method Support List 867 * UDP Tunnel without DTLS 868 * UDP Tunnel with DTLS 869 * IPsec Tunnel [RFC3948] 870 * Client NAT 872 In response, NCM creates a unique identity for the CCM session, and 873 sends out the MX Capability RSP message, including the following 874 information: 876 o MX Feature Activation List: Indicates if the corresponding feature 877 is enabled or not, e.g. lossless switching, fragmentation, 878 concatenation, Uplink aggregation, Downlink aggregation, 879 Measurement, probing, etc. 880 o Number of Anchor Connections (Core Networks) 882 For each Anchor Connection, it includes the following parameters: 884 * Connection ID 885 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 886 LTE) 887 o Number of Delivery Connections (Access Links) 889 For each Delivery Connection, it includes the following 890 parameters: 892 * Connection ID 893 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3: 894 LTE) 895 o MX Convergence Method Support List 897 * Trailer-based MX Convergence 898 * MPTCP Proxy 899 * GRE Aggregation Proxy 900 o MX Adaptation Method Support List 902 * UDP Tunnel without DTLS 903 * UDP Tunnel with DTLS 904 * IPsec Tunnel [RFC3948] 905 * Client NAT 907 Unique Session Identifier: Unique session identifier for the CCM 908 which has setup the connection. In case the session for the UE 909 already exists then the existing unique session identifier is sent 910 back. 912 o NCM Id: Unique Identity of the NCM in the operator network. 913 o Session Id: Unique identity assigned to the CCM instance by this 914 NCM instance. 916 In response to MX Capability RSP message, the CCM sends confirmation 917 (or reject) in the MX Capability ACK message. MX Capability ACK 918 includes the following parameters 920 o Unique Session Identifier: Same identifier as provided in MX 921 Capability RSP. 922 o Acknowledgement: An indication if the client has accepted or 923 rejected the capability phase. 925 * MX ACCEPT: CCM Accepts the Capability set proposed by the NCM. 926 * MX REJECT: CCM Rejects the Capability set proposed by the NCM. 928 If MX_REJECT is received by the NCM, the current MAMS session will be 929 terminated. 931 If CCM can no longer continue with the current capabilities, it 932 should send an MX SESSION TERMINATE message to terminate the MAMS 933 session. In response, the NCM should send a MX SESSION TERMINATE ACK 934 to confirm the termination. 936 8.5. User Plane Configuration 938 Figure 6 shows the user plane configuration procedure consisting of 939 the following key steps: 941 CCM NCM 943 | | 945 |------MX Reconfiguration REQ (setup)--------------->| 947 |<------------------------+MX Reconfiguration RSP+---| 949 | +-----------+----------------+ 951 | | NCM prepares N+MADP for | 953 | | User Plane|Setup | 955 | +----------------------------+ 957 |<----------------------------- MX UP Setup Config---| 959 |-----| MX UP Setup CNF+---------------------------->| 961 +-------------------+ | 963 |Link "X" is up/down| | 965 +-------------------+ | 967 |-----MX Reconfiguration REQ (update/release)------->| 969 |<------------------------+MX Reconfiguration RSP+---| 971 Figure 6: MAMS Control Procedure for User Plane Configuration 973 Reconfiguration: when the client detects that the link is up/down or 974 the IP address changes (e.g. via APIs provided by the client OS), CCM 975 sends out a MX Reconfiguration REQ Message to setup / release / 976 update the connection, and the message SHOULD include the following 977 information 979 o Unique Session Identifier: Identity of the CCM identity at NCM, 980 created by NCM during the capability exchange phase. 982 o Reconfiguration Action: indicate the reconfiguration action 983 (0:release; 1: setup; 2: update). 984 o Connection ID: identify the connection for reconfiguration 986 If (Reconfiguration Action is setup or update), then include the 987 following parameters 989 o IP address of the connection 990 o SSID (if Connection Type = WiFi) 991 o MTU of the connection: MTU of the delivery path that is calculated 992 at the UE for use by NCM to configure fragmentation and 993 concatenation procedures[I-D.zhu-intarea-mams-user-protocol] at 994 N-MADP. 995 o Delivery Node Identity: Identity of the node to which the client 996 is attached. ECGI in case of LTE and WiFi AP Id or MAC address in 997 case of WiFi. 999 At the beginning of a connection setup, CCM informs the NCM of the 1000 connection status using the MX Reconfiguration REQ message with 1001 Reconfiguration Action type set to "setup". NCM acknowledges the 1002 connection setup status and exchanges parameters with the CCM for 1003 user plane setup, described as follows. 1005 User Plane Protocols Setup: Based on the negotiated capabilities, NCM 1006 sets up the user plane (Adaptation Layer and Convergence Layer) 1007 protocols at the N-MADP, and informs the CCM of the user plane 1008 protocols to setup at the client (C-MADP) and the parameters for 1009 C-MADP to connect to N-MADP. 1011 The MX UP Setup Config is used to create (multiple) MADP instances 1012 with each Anchor Connection having one or more Configurations, namely 1013 MX Configurations. It consists of the following parameters: 1015 o Number of Anchor Connections (Core Networks) 1017 For Each Anchor Connection, it includes the following parameters 1019 * Anchor Connection ID 1020 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 1021 LTE) 1022 * Number of Active MX Configurations (Included only if more than 1023 one MX configurations are active for the anchor connection) 1025 For each active MX configuration, it includes the following 1026 parameters 1028 + MX Configuration ID (included if more than one MX 1029 Configuration is present 1031 + MX Convergence Method, one of the following 1033 - Trailer-based MX Convergence 1034 - MPTCP Proxy 1035 - GRE Aggregation Proxy 1036 + MX Convergence Method Parameters 1038 - Convergence Proxy IP Address 1039 - Convergence Proxy Port 1040 + Number of Delivery Connections 1042 For each Delivery Connection, include the following: 1044 - Delivery Connection ID 1045 - Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 1046 3: LTE) 1047 - MX Adaptation Method, one of the following 1049 o UDP Tunnel without DTLS 1050 o UDP Tunnel with DTLS 1051 o IPSec Tunnel 1052 o Client NAT 1053 - MX Adaptation Method Parameters 1055 o Tunnel Endpoint IP Address 1056 o Tunnel Endpoint Port 1057 o Shared Secret 1058 o Header Optimization (included only if MX Convergence 1059 Method is Trailer-based MX Convergence) 1061 e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys 1062 to CCM that IPsec needs to be setup as the MX Adaptation Layer over 1063 the Wi-Fi Access, using the following parameters - IPsec end-point IP 1064 address, Pre-Shared Key. No Adaptation Layer is needed or Client NAT 1065 may be used over the LTE Access as it is considered secure with no 1066 NAT. 1068 Similarly, as an example of the MX Convergence Method configuration 1069 is to indicate the convergence protocol as MPTCP Proxy along with 1070 parameters for connection to the MPTCP Proxy, namely IP Address and 1071 Port of the MPTCP Proxy for TCP Applications. 1073 Once the user plane protocols are configured, CCM informs the NCM of 1074 the status via the MX UP Setup CNF message. The MX UP Setup CNF 1075 consists of the following parameters: 1077 o Unique Session Identifier: Session identifier provided to the 1078 client in MX Capability RSP. 1080 o MX Probe Parameters (included if probing is supported): 1082 * UDP Port Number for receiving Probes 1083 * MX Configuration ID (if MX Configuration ID is specified in MX 1084 UP Setup Config, indicate the MX Configuration that will be 1085 used for Probing) 1086 o Client Adaptation Layer Parameters: 1088 * Number of Delivery Connections 1089 * For each Delivery Connection, include the following: 1091 + Delivery Connection ID 1092 + UDP port number: If UDP based adaptation is in use, the UDP 1093 port at C-MADP side 1095 8.6. MAMS Path Quality Estimation 1097 Path quality estimations can be done either passively or actively. 1098 Traffic measurements in the network could be performed passively by 1099 comparing the real-time data throughput of the device with the 1100 capacity available in the network. In special deployments where the 1101 NCM has interfaces with access nodes, direct interfaces can be used 1102 to gather path quality information. For example, the utilization of 1103 a cell/eNB attached to a device could be used as an indicator for 1104 path quality estimations without creating an extra traffic overhead. 1105 Active measurements by the device are an alternative for estimating 1106 path quality. 1108 CCM NCM 1109 | | 1110 |<--------------+ MX Path Estimation Configuration+--| 1111 |-----+ MX Path Estimation Results+----------------->| 1112 | | 1114 Figure 7: MAMS Control Plane Procedure for Path Quality Estimation 1116 NCM sends following the configuration parameters in the MX Path 1117 Estimation Configuration message to the CCM 1119 o Connection ID (of Delivery Connection whose path quality needs to 1120 be estimated) 1121 o Init Probe Test Duration (ms) 1122 o Init Probe Test Rate (Mbps) 1123 o Init Probe Size (Bytes) 1124 o Init Probe Ack Required (0 -> No/1 -> Yes) 1125 o Active Probe Frequency (ms) 1126 o Active Probe Size (Bytes) 1127 o Active Probe Test Duration (ms) 1128 o Active Probe Ack Required (0 -> No/1 -> Yes) 1130 CCM configures the C-MADP for probe reception based on these 1131 parameters and for collection of the statistics according to the 1132 following configuration. 1134 o Unique Session Identifier: Session identifier provided to the 1135 client in MX Capability RSP. 1136 o Init Probe Results Configuration 1138 * Lost Probes (%) 1139 * Probe Receiving Rate (packets per second) 1140 o Active Probe Results Configuration 1142 * Average Throughput in the last Probe Duration 1144 The user plane probing is divided into two phases - Initialization 1145 phase and Active phase. 1147 o Initialization phase: A network path that is not included by 1148 N-MADP for transmission of user data is deemed to be in the 1149 Initialization phase. The user data may be transmitted over other 1150 available network paths. 1151 o Active phase: A network path that is included by N-MADP for 1152 transmission of user data is deemed to be in Active phase. 1154 In Initialization phase, NCM configures N-MADP to send an MX Idle 1155 Probe REQ message. CCM collects the Idle probe statistics from 1156 C-MADP and sends the MX Path Estimation Results Message to NCM per 1157 the Initialization Probe Results configuration. 1159 In Active phase, NCM configures N-MADP to send an MX Active Probe REQ 1160 message.. C-MADP calculates the metrics as specified by the Active 1161 Probe Results Configuration. CCM collects the Active probe 1162 statistics from C-MADP and sends the MX Path Estimation Results 1163 Message to NCM per the Active Probe Results configuration. 1165 8.7. MAMS Traffic Steering 1166 CCM NCM 1167 | | 1168 | +------------------------------+ 1169 | |Steer user traffic to Path "X"| 1170 | +------------------------------+ 1171 |<------------------MX Traffic Steering (TS) REQ--| 1172 |----- MX Traffic Steering (TS) RSP ------------->| 1174 Figure 8: MAMS Traffic Steering Procedure 1176 NCM sends out a MX Traffic Steering (TS) REQ message to steer data 1177 traffic. It is also possible to send data traffic over multiple 1178 connections simultaneously, i.e. aggregation. The message includes 1179 the following information: 1181 o Connection ID of the Anchor Connection 1182 o MX Configuration ID (if MX Configuration ID is specified in MX UP 1183 Setup Config) 1184 o Connection ID List of Delivery Connections for DL traffic 1185 o Connection ID of Default UL Delivery Connection 1186 o For the number of Specific UL traffic Templates, include the 1187 following 1189 * Traffic Template for identifying the UL traffic 1190 * Connection ID List of Delivery connections for UL traffic 1191 identified by the traffic template 1192 o MX Feature Activation List: each parameter indicates if the 1193 corresponding feature is enabled or not: lossless switching, 1194 fragmentation, concatenation, Uplink aggregation, Downlink 1195 aggregation, Measurement, probing 1197 In response, CCM sends out a MX Traffic Steering (TS) RSP message, 1198 including the following information: 1200 o Unique Session Identifier: Session identifier provided to the 1201 client in MX Capability RSP. 1202 o MX Feature Activation List: each parameter indicates if the 1203 corresponding feature is enabled or not: lossless switching, 1204 fragmentation, concatenation, Uplink aggregation, Downlink 1205 aggregation, probing 1207 8.8. MAMS Application MADP Association 1208 CCM NCM 1209 | | 1210 | +-------------------------+ 1211 | | Associate MADP instance | 1212 | | with application flow | 1213 | +-------------------------+ 1214 |-------------------MX App MADP ----------->| 1215 | Association(AMA) REQ | 1216 | | 1217 |-------------------MX App MADP ----------->| 1218 | Association(AMA) RSP | 1220 Figure 9: MAMS Application MADP Association Procedure 1222 CCM sends out a MX App MADP Association(AMA) REQ message to request 1223 association of a specific Application flow with a specific MADP 1224 instance ID for the anchor connection with multiple active MX 1225 configurations. MADP Instance ID is a tuple (Anchor Connection ID, 1226 MX Configuration ID). This provides the capability for the client to 1227 indicate the user plane processing that needs to be associated with 1228 different application flows depending on their needs. The 1229 application flow is identified by its associated traffic flow 1230 template. 1232 The message includes the following information: 1234 o Number of Application Flows 1236 For Each Application Flow, identified by the Traffic Flow 1237 Template(s), 1239 * Anchor Connection ID 1240 * MX Configuration ID (if more than one MX Configurations are 1241 associated with an Anchor Connection) 1242 * Traffic Template for identifying the UL traffic 1243 * Traffic Template for identifying the DL traffic 1245 In response, NCM sends out a MX App MADP Association (AMA) RSP 1246 message, including the following information: 1248 o Number of Application Flows 1250 For Each Application Flow, identified by the Traffic Flow 1251 Template(s), 1253 * Status (Success or Failure) 1255 8.9. MAMS Network ID Indication 1257 CCM NCM 1258 | | 1259 | +---------------------------------+ 1260 | |NCM determines preferred Networks| 1261 | +---------------------------------+ 1262 |<------------------MX SSID Indication------------| 1264 Figure 10: MAMS Network ID Indication Procedure 1266 NCM indicates the preferred network list to the CCM to guide client 1267 on networks that it should connect to. To indicate preferred Wi-Fi 1268 Networks, the NCM sends the list of WLAN networks, represented by 1269 SSID/BSSID/HESSID, available in the MX SSID Indication. 1271 8.10. MAMS Client Measurement Configuration and Reporting 1273 CCM NCM 1274 | | 1275 |<------------------MX MEAS CONFIG----------------| 1276 | | 1277 +---------------------------------+ | 1278 |Client Ready to send measurements| | 1279 +---------------------------------+ | 1280 | | 1281 |----- MX MEAS REPORT---------------------------->| 1283 Figure 11: MAMS Client Measurement Configuration and Reporting 1284 Procedure 1286 NCM configures the CCM with the different parameters (e.g. radio link 1287 information), with the associated thresholds to be reported by the 1288 client. The MX MEAS CONFIG message contains the following 1289 parameters. For each Delivery Connection, include the following: 1291 o Delivery Connection ID 1292 o Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) 1293 o If Connection Type is Wi-Fi 1295 * WLAN_RSSI_THRESH: High and Low Thresholds for sending Average 1296 RSSI of the Wi-Fi Link. 1298 * WLAN_RSSI_PERIOD: Periodicity in ms for sending Average RSSI of 1299 the Wi-Fi Link. 1300 * WLAN_LOAD_THRESH: High and Low Thresholds for sending Loading 1301 of the WLAN system. 1302 * WLAN_LOAD_PERIOD: Periodicity in ms for sending Loading of the 1303 WLAN system. 1304 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1305 Link Throughput on the Wi-Fi link. 1306 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1307 Throughput on the Wi-Fi link. 1308 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1309 Link Throughput on the Wi-Fi link. 1310 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1311 Throughput on the Wi-Fi link. 1312 * EST_UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1313 Link Throughput (EstimatedThroughputOutbound as defined in 1314 [IEEE]) on the Wi-Fi link. 1315 * EST_UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1316 Throughput (EstimatedThroughputOutbound as defined in [IEEE]) 1317 on the Wi-Fi link. 1318 * EST_DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1319 Link Throughput (EstimatedThroughputInbound as defined in 1320 [IEEE]) on the Wi-Fi link. 1321 * EST_DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1322 Throughput (EstimatedThroughputInbound as defined in [IEEE]) on 1323 the Wi-Fi link. 1324 o If Connection Type is LTE 1326 * LTE_RSRP_THRESH: High and Low Thresholds for sending RSRP of 1327 Serving LTE link. 1328 * LTE_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving 1329 LTE link. 1330 * LTE_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of 1331 the serving LTE link. 1332 * LTE_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving 1333 LTE link. 1334 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1335 Link Throughput on the serving LTE link. 1336 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1337 Throughput on the serving LTE link. 1338 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1339 Link Throughput on the serving LTE link. 1340 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1341 Throughput on the serving LTE link. 1342 o If Connection Type is 5G NR 1344 * NR_RSRP_THRESH: High and Low Thresholds for sending RSRP of 1345 Serving NR link. 1347 * NR_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving 1348 NR link. 1349 * NR_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of the 1350 serving NR link. 1351 * NR_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving 1352 NR link. 1353 * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse 1354 Link Throughput on the serving NR link. 1355 * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link 1356 Throughput on the serving NR link. 1357 * DL_TPUT_THRESH: High and Low Thresholds for sending Forward 1358 Link Throughput on the serving NR link. 1359 * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link 1360 Throughput on the serving NR link. 1362 The MX MEAS REPORT message contains the following parameters 1364 o Unique Session Identifier: Session identifier provided to the 1365 client in MX Capability RSP. 1366 o For each Delivery Connection, include the following: 1368 * Delivery Connection ID 1369 * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: 1370 LTE) 1371 * Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or 1372 MAC address in case of WiFi) 1373 * If Connection Type is Wi-Fi 1375 + WLAN_RSSI: Average RSSI of the Wi-Fi Link. 1376 + WLAN_LOAD: Loading of the WLAN system. 1377 + UL_TPUT: Reverse Link Throughput on the Wi-Fi link. 1378 + DL_TPUT: Forward Link Throughput on the Wi-Fi link. 1379 + EST_UL_TPUT: Estimated Reverse Link Throughput on the Wi-Fi 1380 link (EstimatedThroughputOutbound as defined in [IEEE]). 1381 + EST_DL_TPUT: Estimated Forward Link Throughput on the Wi-Fi 1382 link (EstimatedThroughputInbound as defined in [IEEE]). 1383 * If Connection Type is LTE 1385 + LTE_RSRP: RSRP of Serving LTE link. 1386 + LTE_RSRQ: RSRQ of the serving LTE link. 1387 + UL_TPUT: Reverse Link Throughput on the serving LTE link. 1388 + DL_TPUT: Forward Link Throughput on the serving LTE link. 1389 * If Connection Type is 5G NR 1391 + NR_RSRP: RSRP of Serving NR link. 1392 + NR_RSRQ: RSRQ of the serving NR link. 1393 + UL_TPUT: Reverse Link Throughput on the serving NR link. 1394 + DL_TPUT: Forward Link Throughput on the serving NR link. 1396 8.11. MAMS Session Termination Procedure 1398 CCM NCM 1399 | | 1400 |+----MX Session Terminate--------->| 1401 | | 1402 | | 1403 |<---MX Session Terminate Ack-------| 1404 | +---------------+ 1405 | Remove Resources 1406 | +---------------+ 1407 | | 1409 Figure 12: MAMS Session Termination Procedure - Client Initiated 1411 CCM NCM 1412 | | 1413 |<----------MX Session Terminate--------| 1414 | | 1415 | | 1416 | | 1417 +--------MX Session Terminate Ack-------> 1418 | | 1419 | | 1420 +-----------+-----------+ | 1421 | Remove Resources | | 1422 +-----------+-----------+ | 1423 | | 1425 Figure 13: MAMS Session Termination Procedure - Network Initiated 1427 At any point in MAMS functioning if CCM or NCM is unable to support 1428 the MAMS functions anymore, then either of them can initiate a 1429 termination procedure by sending MX Session Terminate to the peer, 1430 the peer shall acknowledge the termination by sending MX Session 1431 Terminate ACK message. After the session is disconnected the CCM 1432 shall start a new procedure with MX Discover Message. MX Session 1433 Terminate message shall contain Unique Session Identifier and reason 1434 for termination in Request. Possible reasons for termination can be: 1436 o Normal Release 1437 o No Response from Peer 1438 o Internal Error 1440 9. Generic MAMS Signaling Flow 1442 +----------------------------------------+ 1443 | MAMS enabled Network of Networks | 1444 | +-----+ +-----+ +-----+ +------+ 1445 +-----------------+ | | | | | | | | || 1446 | Client | | |Netwo| |Netwo| | | | || 1447 | +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP|| 1448 | C-MADP |CCM | | | |(LTE)| |(WiFi) | | | || 1449 | +-----+ +-----+ | | +-----+ +-----+ +-----+ +------| 1450 -+----------------+ +----------------------------------------+ 1451 | | | | | | | 1452 | | | | | | | 1453 | | 1.SETUP CONNECTION| | | | 1454 |<-----------+------------>| | | | 1455 | | | + + | | 1456 | | | 2. MAMS Capabilities Exchange | | 1457 | | |<-------------+----------+-------->| | 1458 | | | | | | | 1459 | | + | | | | 1460 | | 3. SETUP CONNECTION | | | 1461 |<--+-------------------------------->| | | 1462 | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| 1463 | C-MADP | PROTOCOL AND PARAMETERS | |N-MADP | 1464 | |<----->|<-------------+----------+-------->|<-------->| 1465 | | | + + | | 1466 | | |5. ESTABLISH USER PLANE PATH ACCORDING TO | 1467 | | | SELECTED FLOW PROTOCOL | | | 1468 | |<---------------------+----------+------------------->| 1469 | | | | | | | 1470 + + + + + + + 1472 Figure 14: MAMS call flow 1474 Figure 14 illustrates the MAMS signaling mechanism for negotiation of 1475 network paths and flow protocols between the client and the network. 1476 In this example scenario, the client is connected to two networks 1477 (say LTE and WiFi). 1479 1. UE connects to network 1 and gets an IP address assigned by 1480 network 1. 1481 2. CCM communicates with NCM functional element via the network 1 1482 connection and exchanges capabilities and parameters for MAMS 1483 operation. Note: The NCM credentials (e.g. NCM IP Address) can 1484 be made known to the UE by pre-provisioning. 1486 3. Client sets up connection with network 2 and gets an IP address 1487 assigned by network 2. 1488 4. CCM and NCM negotiate capabilities and parameters for 1489 establishment of network paths, which are then used to configure 1490 user plane functions N-MADP at the network and C-MADP at the 1491 client. 1493 4a. CCM and NCM negotiate network paths, flow routing and 1494 aggregation protocols, and related parameters. 1496 4b. NCM communicates with the N-MADP to exchange and configure 1497 flow aggregation protocols, policies and parameters in alignment 1498 with those negotiated with the CCM. 1500 4c. CCM communicates with the C-MADP to exchange and configure 1501 flow aggregation protocols, policies and parameters in alignment 1502 with those negotiated with the NCM. 1504 5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE 1505 [RFC7296] signaling, based on the negotiated flow aggregation 1506 protocols and parameters specified by NCM. 1508 CCM and NCM can further exchange messages containing access link 1509 measurements for link maintenance by the NCM. NCM evaluates the link 1510 conditions in the UL and DL across LTE and WiFi, based on link 1511 measurements reported by CCM and/or link probing techniques and 1512 determines the UL and DL user data distribution policy. NCM and CCM 1513 also negotiate application level policies for categorizing 1514 applications, e.g. based on DSCP, Destination IP address, and 1515 determining which of the available network paths, needs to be used 1516 for transporting data of that category of applications. NCM 1517 configures N-MADP, and CCM configures C-MADP, based on the negotiated 1518 application policies. CCM may apply local application policies, in 1519 addition to the application policy conveyed by the NCM. 1521 10. Applying MAMS Control Procedures with MPTCP Proxy as User Plane 1523 If NCM determines that N-MADP is to be instantiated with MPTCP as the 1524 MX Convergence Protocol, it exchanges the MPTCP capability support in 1525 discovery and capability exchange procedures. NCM then exchanges the 1526 credentials of the N-MADP instance, setup as MPTCP Proxy, along with 1527 related parameters to the CCM. CCM configures C-MADP with these 1528 parameters to connect with the N-MADP, MPTCP proxy (e.g. 1529 [I-D.wei-mptcp-proxy-mechanism], [I-D.boucadair-mptcp-plain-mode]) 1530 instance, on the available network path (Access). 1532 Figure 15 shows the call flow describing MAMS control procedures 1533 applied to configure user plane and dynamic optimal path selection in 1534 a scenario with MPTCP Proxy as the convergence protocol in the user 1535 plane. 1537 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1538 | | | | | | | | | | | | 1539 |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| 1540 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1541 +------------------------------------------------------------------------+ 1542 | 1. LTE Session Setup and IP Add. Allocation | 1543 -------------------------------------------+-------------+-------------+-+ 1544 |2. MAMS Discovery Message (MAMS Version) | | | 1545 +-----------------------------------------+-------------> | 1546 | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | 1547 <-------------+-------------+-------------+-------------+ | 1548 | | | | | | 1549 |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | 1550 +-----------------------------------------------------+-> | 1551 |5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)| | 1552 <-----------------------------------------+-------------+ | 1553 | 6. MX CAPABILITY ACK(ACCEPT) | | | 1554 +-------------+-------------+---------------------------> | 1555 | | | | | | 1556 |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | 1557 <-------------------------------------------------------+ | 1558 |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | 1559 +-----------------------------------------+-------------> | 1560 |9. MAMS SSID IND(List of SSIDs) | | | 1561 <-------------+-------------+---------------------------+ | 1562 | | | | | | 1563 |10. MX RECONFIGURATION REQ (LTE IP) | | | 1564 +-------------------------------------------------------> | 1565 |11. MX RECONFONFIGURATION RSP | | | 1566 <-----------------------------------------+-------------+ | 1567 |12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | 1568 <---------------------------+-------------+-------------+ | 1569 |13. MX UP SETUP RSP | | | | 1570 +-------------+-------------+-------------+-------------> + 1571 | | 14. MPTCP Connection with designated MPTCP Proxy over LTE 1572 | +-------------+-------------+-------------+-------------> 1573 | | | | | | 1574 + + + + + + 1576 Figure 15: MAMS-assisted MPTCP Proxy as User Plane - Initial Setup 1577 with LTE leg 1579 Following are the salient steps described in the call flow. The 1580 client connects to the LTE network and obtains an IP address (assume 1581 LTE is the first connection), and initiates the NCM discovery 1582 procedures and exchange capabilities, including the support for MPTCP 1583 as the convergence protocol at both the network and the client. 1585 The CCM informs the LTE connection parameters to the NCM. NCM 1586 provides the parameters like MPTCP Proxy IP address/Port for 1587 configuring the convergence layer. This is useful if N-MADP is 1588 reachable via different IP address or/and port, from different access 1589 networks. The current MPTCP signaling can't identify or 1590 differentiate the MPTCP proxy IP address and port among multiple 1591 access networks. Since LTE is the only connection, the user plane 1592 traffic flows over the single TCP subflow over the LTE connection. 1593 Optionally, NCM can provide assistance to the device on the 1594 neighboring/preferred Wi-Fi networks that it can associate with. 1596 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1597 | | | | | | | | | | | | 1598 |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| 1599 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1600 +------------------------------------------------------------------------+ 1601 | Traffic over LTE in UL and DL over MPTCP Connection | 1602 +------------------------------------------------------------------------+ 1603 +------------------------------------------------------------------------+ 1604 | Wi-Fi Connection Establishment and IP Address Allocation | 1605 +---------------------------------------------------------------------+--+ 1606 |15. MX RECONFIGURATION REQ (Wi-Fi IP) | | | 1607 +-------------------------------------------------------> | 1608 |16. MX RECONFONFIGURATION RSP | | | 1609 <-----------------------------------------+-------------+ | 1610 |17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | 1611 <---------------------------+-------------+-------------+ | 1612 |18. MX UP SETUP RSP | | | | 1613 +-------------+-------------+-------------+-------------> | 1614 | | 19. IPsec Tunnel Establishment over WLAN path | 1615 | <-----------------------------------------|-------------> 1616 | 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+ 1617 +-------------+-------------+-------------+------------->+Wait for | 1618 | | | | |+good reports | 1619 | | | | |+-------------+ 1620 | 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+ 1621 <-----------------------------------------+-------------+ |Allow Use of| 1622 | 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link | 1623 +-------------+-------------+---------------------------> +-----------++ 1624 | | | | | | 1625 | Add TCP subflow to the MPTCP connection over the WiFi link 1626 | |<----------------------------------------------------->| 1627 +-----------------------------------------------------------------------+ 1628 || Aggregated Wi-Fi and LTE capacity for UL and DL || 1629 +-----------------------------------------------------------------------+ 1630 | | 1631 | | 1633 Figure 16: MAMS-assisted MPTCP Proxy as User Plane - Add Wi-Fi leg 1635 Figure 16 describes the steps, when the client establishes a Wi-Fi 1636 connection. CCM informs the NCM of the Wi-Fi connection along with 1637 parameters like the Wi-Fi IP address, SSID. NCM determines that the 1638 Wi-Fi connection needs to be secured and configures the Adaptation 1639 Layer to be IPsec and provides the required parameters to the CCM. 1640 In addition, NCM provides the information to configure the 1641 convergence layer, (e.g. MPTCP Proxy IP Address), and provides the 1642 Traffic Steering Request to indicate that client should use only the 1643 LTE access. NCM may do this, for example, on determination from the 1644 measurements that the Wi-Fi link is not consistently good enough. As 1645 the Wi-Fi link conditions improve, NCM sends a Traffic Steering 1646 Request to use Wi-Fi access as well. This triggers the client to 1647 establish the TCP subflow over the Wi-Fi link with the MPTCP proxy 1649 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1650 | | | | | | | | | | | | 1651 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 1652 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1653 +------------------------------------------------------------------------+ 1654 | Traffic over LTE and Wi Fi in UL And DL over MPTCP | 1655 +-------------+-------------+-------------+-------------+------------+---+ 1656 | | | | | | 1657 | 23. MX MEAS REPORT (WLAN RSSI, LTE RSRP ,UL/DL TPUT) |+-----------+---+ 1658 +-------------+-------------+-------------+------------>|| Reports of bad| 1659 | | | | |+ Wi-Fi UL tput| 1660 | + + + ++---------------+ 1661 | 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ 1662 |<-----------------------------------------+------------+ |Disallow use| 1663 | 25. MX TRAFFIC STEERING RSP (...) | | |of Wi-Fi UL | 1664 |-------------+-------------+-------------------------->| +----------+--+ 1665 | | | | | | 1666 ++-------------+-------------+-------------+-------------+------------+-+ 1667 | UL data to use TCP subflow over LTE link only, | 1668 | Aggregated Wi-Fi+LTE capacity for DL | 1669 ++-------------+-------------+-------------+-------------+-------------++ 1670 | | | | | | 1671 + + + + + + 1673 Figure 17: MAMS-assisted MPTCP Proxy as User Plane - Wi-Fi UL 1674 degrades 1676 Figure 17 describes the steps, when the client reports that Wi-Fi 1677 link conditions degrade in UL. MAMS control plane is used to 1678 continuously monitor the access link conditions on Wi-Fi and LTE 1679 connections. The NCM may at some point determine increase in UL 1680 traffic on Wi-Fi, and trigger the client to only LTE in the UL via 1681 Traffic Steering Request to improve UL performance. 1683 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1684 | | | | | | | | | | | | 1685 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 1686 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1687 +-----------------------------------------------------------------------+ 1688 | UL data to use TCP subflow over LTE link only, | 1689 | Aggregated Wi+Fi+LTE capacity for DL | 1690 ++-------------+-------------+-------------+-------------+------------+-+ 1691 | | | | | | 1692 | + + + | | 1693 | 23. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) +------------+---+ 1694 +-------------+-------------+-------------+------------>|| Reports of bad+ 1695 | | | | || Wi+Fi UL/DL tput 1696 | + + + +----------------+ 1697 | 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ 1698 +<----------------------------------------+-------------+ |Disallow use| 1699 | 25. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi | 1700 +-----------------------------------------+------------>+ +-------------+ 1701 | |Delete TCP subflow from MPTCP conn. over Wi-Fi link | 1702 | +<---------------------------------------------------->| 1703 +-----------------------------------------------------------------------+ 1704 || Traffic over LTE link only for DL and UL | | | 1705 || (until Client reports better Wi-Fi link conditions) | | | 1706 +-----------------------------------------------------------------------+ 1707 | | | | | | 1708 + + + + + + 1710 Figure 18: MAMS-assisted MPTCP Proxy as User Plane - Part 4 1712 Figure 18 describes the steps, when the client reports that Wi-Fi 1713 link conditions degrade in both UL and DL. As the Wi-Fi link 1714 conditions deteriorate further, the NCM may determine to send Traffic 1715 Steering Request guiding the client to stop using Wi-Fi, and to use 1716 only LTE access in both UL and DL. This condition may be maintained 1717 until NCM determines, based on reported measurements that Wi-Fi link 1718 has become usable. 1720 11. Applying MAMS Control Procedures for Network Assisted Traffic 1721 Steering when there is no convergence layer 1723 Figure 19 shows the call flow describing MAMS control procedures 1724 applied for dynamic optimal path selection in a scenario convergence 1725 and Adaptation layer protocols are not omitted. This scenario 1726 indicates the applicability of a MAMS Control Plane only solution. 1728 In the capability exchange messages, NCM and CCM negotiate that 1729 Convergence and Adaptation layer protocols are not needed (or 1730 supported). CCM informs the NCM of the availability of the LTE and 1731 Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be 1732 used dynamically based on the reported link quality measurements. 1734 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1735 | | | | | | | | | | | | 1736 |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| 1737 +------+ +---------+ +---------+ +---------+ +---------+ +------+ 1738 +------------------------------------------------------------------------+ 1739 | 1. LTE Session Setup and IP Add. Allocation | 1740 +------------------------------------------+-------------+-------------+-+ 1741 |2. MAMS Discovery Message (MAMS Version) | | | 1742 +-----------------------------------------+------------>| | 1743 | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | 1744 <-------------+-------------+-------------+-------------+ | 1745 | + + + + | 1746 |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | 1747 +------------------------------------------------------>| | 1748 |5. MX CAPABILITY RSP(No Convergence/Adpatation parameters) | 1749 |<-----------------------------------------+------------+ | 1750 | 6. MX CAPABILITY ACK(ACCEPT) | | | 1751 +-------------+-------------+-------------------------->| | 1752 | + + + + | 1753 |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | 1754 |<------------------------------------------------------| | 1755 |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | 1756 |-----------------------------------------+------------>| | 1757 |9. MAMS SSID IND(List of SSIDs) | | | 1758 |<------------------------------------------------------| | 1759 +-----------------------------------------------------------------------++ 1760 | 10. Wi|Fi connection setup and IP Address allocation | 1761 +-+-------------+-------------+-------------+-------------+-------------++ 1762 | + + | | | 1763 |10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | | 1764 +-----------------------------------------+------------>| | 1765 |11. MX RECONFONFIGURATION RSP | | | 1766 <------------------------------------------------------+| | 1767 +-----------------------------------------------------------------------++ 1768 | Initial Condition, Data over LTE link only, WLAN link is poor | 1769 +---------------------------------------------------------+-------------++ 1770 |12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+ 1771 |------------------------------------------------------>||Wi-Fi Link | 1772 | | | | ||conditions | 1773 | | | | ||reported good| 1774 | | | | |+-------------+ 1775 | | | | | | 1776 |13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+ 1777 |<-------------+-------------+-------------+------------||Steer traffic | 1778 |14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi | 1779 |<-------------+-------------+-------------+------------||link | 1780 | | | | |+--------------+ 1781 +-----------------------------------------------------------------------++ 1782 | Use Wi-Fi link for Data | 1783 +---------------------------------------------------------+-------------++ 1784 | | | | | | 1785 + + + + + + 1787 Figure 19: MAMS With No Convergence Layer 1789 12. Co-existence of MX Adaptation and MX Convergence Layers 1791 MAMS user plane supports multiple instances and combinations of 1792 protocols to be used at the MX Adaptation and the Convergence layer. 1794 For example, one instance of the MX Convergence Layer can be MPTCP 1795 Proxy and another instance can be Trailer based. The MX Adaptation 1796 for each can be either UDP tunnel or IPsec. IPSec may be set up when 1797 network path needs to be secured, e.g. to protect the TCP subflow 1798 traversing the network path between the client and MPTCP proxy. 1800 Each of the instances of MAMS user plane, i.e. combination of MX 1801 Convergence and MX Adaptation layer protocols, can coexist 1802 simultaneously and independently handle different traffic types. 1804 13. Security Considerations 1806 13.1. MAMS Control plane security 1808 The NCM functional element is hosted on a network node which is 1809 assumed to be within a secure network, e.g. within the operator's 1810 network, and is assumed to be protected against hijack attacks. 1812 For deployment scenarios, where the client is configured (e.g. by the 1813 network operator) to use a specific network path for exchanging 1814 control plane messages and if the network path is assumed to be 1815 secure, MAMS control messages will rely on security provided by the 1816 underlying network. 1818 For deployment scenarios where the security of the network path 1819 cannot be assumed, NCM and CCM implementations MUST support the "wss" 1820 URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to 1821 secure control plane message exchange between the NCM and CCM. 1823 For deployment scenarios where client authentication is desired, the 1824 WebSocket server can use any client authentication mechanisms 1825 available to a generic HTTP server, such as cookies, HTTP 1826 authentication, or TLS authentication. 1828 13.2. MAMS User plane security 1830 User data in MAMS framework relies on the security of the underlying 1831 network transport paths. When this cannot be assumed, NCM configures 1832 use of protocols, like IPsec [RFC4301] [RFC3948] in the MX Adaptation 1833 Layer, for security. 1835 14. Implementation considerations 1837 MAMS builds on commonly available functions available on terminal 1838 devices that can be delivered as a software update over the popular 1839 end-user device operating systems, enabling rapid deployment and 1840 addressing the large deployed device base. 1842 15. Applicability to Multi Access Edge Computing 1844 Multi Access Edge Computing (MEC), earlier known as Mobile edge 1845 computing, is an access-edge cloud platform being standardized at 1846 ETSI, whose initial focus was to improve quality of experience by 1847 leveraging intelligence at cellular (e.g. 3GPP technologies like LTE) 1848 access edge, and the scope is now being extended to support access 1849 technologies beyond 3GPP. This applicability of the framework 1850 described in this document to the MEC platform has been evaluated and 1851 tested in different network configurations. 1853 The NCM is hosted on the MEC cloud server that is located in the user 1854 plane path at the edge of multi-technology access networks. The NCM 1855 and CCM negotiate the network path combinations based on application 1856 needs and the necessary user plane protocols to be used across the 1857 multiple paths. The network conditions reported by the CCM to the 1858 NCM is complemented by Radio Analytics application[ETSIRNIS] residing 1859 at the MEC to configure the uplink and downlink access paths 1860 according to changing radio and congestion conditions. 1862 The user plane functional element, N-MADP, can either be collocated 1863 with the NCM at the MEC cloud server (e.g. MEC hosted applications), 1864 or placed at a separate network element like a common user plane 1865 gateway across the multiple networks. 1867 Also, even in scenarios where N-MADP is not deployed, NCM can be used 1868 to augment the traffic steering decisions at the device. 1870 The aim of these enhancements is to improve the end-user's quality of 1871 experience by leveraging the best network path based on application 1872 needs and network conditions, and building on the advantages of 1873 significantly reduced latency and the dynamic and real-time exposure 1874 of radio network information available at the MEC. 1876 16. Contributing Authors 1878 The editors gratefully acknowledge the following additional 1879 contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu 1880 Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia, Shuping 1881 Peng/Huawei, Vasudevan Subramanian/Nokia. Vasudevan Subramanian has 1882 been instrumental in conceptualization and development of solution 1883 principles for the MAMS framework. Shuping Peng has been a key 1884 contributor in refining the framework and control plane protocol 1885 aspects. 1887 17. Acknowledgments 1889 This protocol is the outcome of work by many engineers, not just the 1890 authors of this document. In alphabetical order, the contributors to 1891 the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru 1892 Calin, Jonathan Ling, Lohith Nayak, Michael Scharf. 1894 18. IANA Considerations 1896 This draft makes no requests of IANA 1898 19. References 1900 19.1. Normative References 1902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1903 Requirement Levels", BCP 14, RFC 2119, 1904 DOI 10.17487/RFC2119, March 1997, 1905 . 1907 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1908 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1909 December 2005, . 1911 19.2. Informative References 1913 [ETSIRNIS] 1914 "Mobile Edge Computing (MEC) Radio Network Information 1915 API", . 1917 [I-D.boucadair-mptcp-plain-mode] 1918 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1919 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1920 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1921 Contreras, L., and B. Peirens, "Extensions for Network- 1922 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 1923 plain-mode-10 (work in progress), March 2017. 1925 [I-D.wei-mptcp-proxy-mechanism] 1926 Wei, X., Xiong, C., and E. Ed, "MPTCP proxy mechanisms", 1927 draft-wei-mptcp-proxy-mechanism-02 (work in progress), 1928 June 2015. 1930 [I-D.zhu-intarea-mams-user-protocol] 1931 Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane 1932 Protocols for Multiple Access Management Service", draft- 1933 zhu-intarea-mams-user-protocol-04 (work in progress), 1934 January 2018. 1936 [IEEE] "IEEE Standard for Information technology: 1937 Telecommunications and information exchange between 1938 systems Local and metropolitan area networks:Specific 1939 requirements - Part 11: Wireless LAN Medium Access Control 1940 (MAC) and Physical Layer (PHY) Specifications.", . 1943 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1944 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1945 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1946 . 1948 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1949 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1950 January 2012, . 1952 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1953 "TCP Extensions for Multipath Operation with Multiple 1954 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1955 . 1957 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1958 Kivinen, "Internet Key Exchange Protocol Version 2 1959 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1960 2014, . 1962 Appendix A. MAMS Control Plane Optimization over Secure Connections 1964 If the connection between CCM and NCM over which the MAMS control 1965 plane messages are transported is assumed to be secure, UDP is used 1966 as the transport for management & control messages between NCM and 1967 UCM (see Figure 20). 1969 +-----------------------------------------------------+ 1970 | Multi-Access (MX) Control Message | 1971 |-----------------------------------------------------| 1972 | UDP | 1973 |-----------------------------------------------------| 1975 Figure 20: UDP-based MAMS Control plane Protocol Stack 1977 Authors' Addresses 1979 Satish Kanugovi 1980 Nokia 1982 Email: satish.k@nokia.com 1984 Florin Baboescu 1985 Broadcom 1987 Email: florin.baboescu@broadcom.com 1989 Jing Zhu 1990 Intel 1992 Email: jing.z.zhu@intel.com 1994 Julius Mueller 1995 AT&T 1997 Email: jm169k@att.com 1999 SungHoon Seo 2000 Korea Telecom 2002 Email: sh.seo@kt.com