idnits 2.17.1 draft-kanugovi-intarea-mams-protocol-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 27, 2017) is 2577 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA S. Kanugovi 3 Internet-Draft S. Vasudevan 4 Intended status: Standards Track Nokia 5 Expires: September 28, 2017 F. Baboescu 6 Broadcom 7 J. Zhu 8 Intel 9 S. Peng 10 Huawei 11 J. Mueller 12 AT&T 13 S. Seo 14 Korea Telecom 15 March 27, 2017 17 Multiple Access Management Services 18 draft-kanugovi-intarea-mams-protocol-04 20 Abstract 22 A communication network includes an access network segment that 23 delivers data to/from the users and an associated core network 24 segment providing connectivity with the application servers. 25 Multiconnectivity scenarios are common where an end-user device can 26 simultaneously connect to multiple communication networks based on 27 different technology implementations and network architectures like 28 WiFi, LTE, DSL. A smart selection and combination of access and core 29 network paths that can dynamically adapt to changing network 30 conditions can improve quality of experience for a user in such a 31 Multiconnectivity scenario and improve overall network utilization 32 and efficiency. This document presents the problem statement and 33 proposes solution principles. It specifies the requirements and 34 reference architecture for a multi-access management services 35 framework that can be used to flexibly select the best combination of 36 access and core network paths for uplink and downlink, as well as the 37 flexible usage of uplink and downlink, ensuring better network 38 efficiency and enhanced application performance. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 28, 2017. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Conventions used in this document . . . . . . . . . . . . . . 3 75 2. Contributing Authors . . . . . . . . . . . . . . . . . . . . 3 76 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 79 6. Solution Principles . . . . . . . . . . . . . . . . . . . . . 6 80 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 81 7.1. Access technology agnostic interworking . . . . . . . . . 6 82 7.2. Support common transport deployments . . . . . . . . . . 6 83 7.3. Independent Access path selection for Uplink and Downlink 6 84 7.4. Core selection independent of uplink and downlink access 7 85 7.5. Adaptive network path selection . . . . . . . . . . . . . 7 86 7.6. Multipath support and Aggregation of access link 87 capacities . . . . . . . . . . . . . . . . . . . . . . . 7 88 7.7. Scalable mechanism based on user plane interworking . . . 7 89 7.8. Separate Control and Data plane functions . . . . . . . . 8 90 7.9. Lossless Path (Connection) Switching . . . . . . . . . . 8 91 7.10. Concatenation and Fragmentation to adapt to MTU 92 differences . . . . . . . . . . . . . . . . . . . . . . . 8 93 7.11. Configuring network middleboxes based on negotiated 94 protocols . . . . . . . . . . . . . . . . . . . . . . . . 8 95 7.12. Policy based Optimal path selection . . . . . . . . . . . 8 96 7.13. MAMS Control signaling . . . . . . . . . . . . . . . . . 9 97 7.14. Service discovery and reachability . . . . . . . . . . . 9 99 8. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 9 100 9. Solution Principles . . . . . . . . . . . . . . . . . . . . . 12 101 10. Implementation considerations . . . . . . . . . . . . . . . . 13 102 11. Applicability to Mobile Edge Computing . . . . . . . . . . . 14 103 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 104 12.1. Data and Control plane security . . . . . . . . . . . . 14 105 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 106 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 108 14.2. Informative References . . . . . . . . . . . . . . . . . 15 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 111 1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Contributing Authors 119 The editors gratefully acknowledge the following additional 120 Contributors in alphabetical order: Hannu Flinck/Nokia, Nurit 121 Sprecher/Nokia 123 3. Introduction 125 Multi Access Management Services (MAMS) is a programmable framework 126 that provides mechanisms for flexible selection of network paths in a 127 multi-access communication environment, based on application needs, 128 which can leverage network intelligence and policies to dynamically 129 adapt to changing network/link conditions. The network path 130 selection and configuration procedures use the user plane to exchange 131 data between the functional elements in the network and the end-user 132 device without any impact to the control plane signaling schemes of 133 each individual access network. For example, in a multi-access 134 network with LTE and WiFi technologies, existing LTE and existing 135 WiFi signaling procedures will be used to setup the LTE and WiFi 136 connections, respectively. The proposed MAMS framework offers the 137 capabilities of smart selection and flexible combination of access 138 paths and core network paths. It is a broad programmable framework 139 providing functions beyond just sharing network policies, e.g. in 140 comparison to ANDSF that provides policies/rules for assisting 3GPP 141 devices to discover and select available access networks, that allows 142 choosing and configuring user plane protocols and treatment depending 143 on needs of the application. 145 The document presents the requirements, solution principles and 146 functional architecture for the MAMS framework. MAMS mechanisms are 147 not dependent on any specific network and transport protocols like 148 TCP, UDP, GRE, MPTCP etc. It co-exists and complements the existing 149 protocols by providing a way to negotiate and configure the protocols 150 based on client and network capabilities. Further it allows 151 exchanges of network state information and leveraging network 152 intelligence to optimize the performance of such protocols. 154 An important goal for MAMS is to ensure that there is minimal or no 155 dependency on the actual access technologies of the participating 156 links, beyond the fact that the MAMS functional elements can be 157 placed in the user plane. This allows the scheme to be future proof, 158 for addition of new access technologies and for independent 159 technology evolution of the existing access and core networks. 161 4. Terminology 163 "Client": The end-user device supporting connections with multiple 164 access nodes, possibly over different access technologies. 166 "Multiconnectivity Client": A client with multiple network 167 connections. 169 "Access network": The segment in the network that delivers user data 170 packets to the client via an access link like WiFi airlink, LTE 171 airlink, or DSL. 173 "Core": The functional element that anchors the client's IP address 174 used for communication with applications via the network. 176 "User Plane Gateway": The functional element that can intercept and 177 route user data packets. 179 "Network Connection manager"(NCM): A functional entity in the network 180 that oversees distribution of data packets over the multiple 181 available access and core network paths. 183 "Client Connection Manager" (CCM): A functional entity in the client 184 that exchanges MAMS Signaling with the Network Connection Manager and 185 configures the multiple network paths for transport of user data. 187 "Network Multi Access Data Proxy" (N-MADP): This functional entity in 188 the network handles the user data traffic forwarding across multiple 189 network paths. N-MADP is responsible for MAMS related user-plane 190 functionalities in the network. 192 "Client Multi Access Data Proxy" (C-MADP): This functional entity in 193 the client handles the user data traffic forwarding across multiple 194 network paths. C-MADP is responsible for MAMS related user-plane 195 functionalities in the client. 197 5. Problem Statement 199 Typically, an end-user device has access to multiple communication 200 networks based on different technologies, say LTE, WiFi, DSL, 201 MuLTEfire, for accessing application services. Different 202 technologies exhibit benefits and limitations in different scenarios. 203 For example, WiFi leverages the large spectrum available in 204 unlicensed spectrum to deliver high capacities at low cost in 205 uncongested scenarios with small user population, but can show 206 significant degradation in application performance in congested 207 scenarios with large user population. Another example is LTE 208 network, the capacity of which is often constrained by high cost and 209 limited availability of the licensed spectrum, but offers predictable 210 service even in multi-user scenarios due to controlled scheduling and 211 licensed spectrum usage. 213 Additionally, the use of a particular access network path is often 214 coupled with the use of its associated core network. For example, in 215 an enterprise that has deployed WiFi and LTE communications network, 216 enterprise applications, like printers, Corporate Audio and Video 217 conferencing, are accessible only via WiFi access connected to the 218 enterprise hosted WiFi core, whereas the LTE access can be used to 219 get LTE operator core anchored services including access to public 220 Internet. 222 Application performance in different scenarios, therefore becomes 223 dependent on the choice of the communication networks based on 224 different technologies (e.g. WiFi and LTE) due to the tight coupling 225 of the access and the core network paths. Therefore to achieve the 226 best possible application performance in a wide range of possible 227 scenarios, a framework is needed that allows the selection and 228 flexible combination of access and core network paths for uplink and 229 downlink data delivery. 231 For example, in uncongested scenarios, it would be beneficial to use 232 WiFi access in both uplink and downlink for connecting to enterprise 233 applications. Whereas in congested scenarios, where use of WiFi in 234 uplink by multiple users can lead to degraded capacity and increased 235 delays due to contention, it would be beneficial to use scheduled LTE 236 as uplink combined with WiFi as downlink. 238 6. Solution Principles 240 This document proposes a Multiple Access Management Services(MAMS) 241 framework for dynamic selection and flexible combination of access 242 and core network paths as uplink and downlink for a device connected 243 to multiple communication networks. The multiple communication 244 networks interwork at the user plane. The selection of paths is 245 based on negotiation of capabilities (of device and network) and 246 network link quality between the user plane functional elements at 247 the end-user device/client (C-MADP) and the network (N-MADP).NCM has 248 the intelligence to setup and offer the best network path based on 249 device and network capabilities, application needs and knowledge of 250 the network state. 252 The NCM communicates with the Client Connection Manager (CCM), a 253 functional element in the device, for negotiation, sharing 254 information on the network path conditions, and configuring usage of 255 the network paths. The messages between the NCM and CCM are carried 256 as user plane data over any of the available network paths between 257 the NCM and CCM. 259 7. Requirements 261 The requirements set out in this section are for the definition of 262 behavior of the MAMS mechanism and the related functional elements. 264 7.1. Access technology agnostic interworking 266 The access nodes can be of different technology types like LTE, WiFi 267 etc. Since MAMS routes user plane data packets at the IP layer, 268 which makes it agnostic to the type of underlying technology used at 269 the access nodes. 271 7.2. Support common transport deployments 273 The network path selection and user data distribution should work 274 transparently across transport deployments that include e2e IPsec, 275 VPNs, and middleboxes like NATs and proxies. 277 7.3. Independent Access path selection for Uplink and Downlink 279 IP layer routing enables the client to transmit on uplink using one 280 access and receive data on downlink using another access, allowing 281 client and network connection manager to select the access paths for 282 uplink and downlink independent of each other. 284 7.4. Core selection independent of uplink and downlink access 286 A client is able to flexibly select the Core, independent of the 287 access paths used to reach the Core, depending on the application 288 needs. 290 7.5. Adaptive network path selection 292 The MAMS functional elements have the ability to determine the 293 quality of each of the network paths, e.g. access link delay and 294 capacity. The network path quality information is fed into the logic 295 for selection of combination of network paths to be used for 296 transporting user data. The path selection algorithm can use network 297 path quality information, in addition to other considerations like 298 network policies, for optimizing network usage and enhancing QoE 299 delivered to the user. 301 7.6. Multipath support and Aggregation of access link capacities 303 MAMS supports distribution and aggregation of user data across 304 multiple network paths at the IP layer. MAMS allows the client to 305 leverage the combined capacity of the multiple network connections by 306 enabling simultaneous transport of user data over multiple network 307 paths. If required, packet re-ordering is done at the receiver, 308 client(C-MADP) and/or the network (N-MADP), when user data packets 309 are received out of order. MAMS allows flexibility to choose the 310 flow steering and aggregation protocol based on capabilities 311 supported by the client and the network data plane entities, C-MADP 312 and N-MADP respectively. A MAMS multi-connection aggregation 313 solution should support existing transport and network layer 314 protocols like TCP, UDP, GRE. If flow aggregation functions are 315 realized using existing protocols such as Multi-Path TCP(MPTCP) and 316 SCTP, MAMS framework should allow use and configuration of these 317 aggregation protocols. 319 7.7. Scalable mechanism based on user plane interworking 321 The mechanism is based on user plane interworking, requiring only 322 that the MAMS functional elements (NCM and N-MADP) should be added in 323 the user plane path between the client and the network. The 324 interworking functionality is based on generically available routing 325 and tunneling capabilities. This makes solution easy to deploy and 326 scale when different networks are added and removed. 328 7.8. Separate Control and Data plane functions 330 The client negotiates with a network connection manager on the choice 331 of access for both uplink and downlink, as well as the Core. The 332 network connection manager configures the actual user plane data 333 distribution function. This allows common control protocol to be 334 used with multiple and potentially different user plane (e.g. 335 tunneling) protocols, thus maintaining a clear separation between the 336 control and data plane functions. This makes the MAMS framework 337 scalable and extensible, e.g. by being amenable to SDN based 338 architecture and implementations. 340 7.9. Lossless Path (Connection) Switching 342 When switching data traffic from one path (connection) to another, 343 packets may be lost or delivered out-of-order, which will have 344 negative impacts on the performance of higher layer protocols, e.g. 345 TCP. MAMS should provide necessary mechanisms to ensure in-order 346 delivery at the receiver, as well as support retransmissions at the 347 transmitter during path switching. 349 7.10. Concatenation and Fragmentation to adapt to MTU differences 351 MAMS should support heterogeneous access networks, which may have 352 different MTU sizes. Moreover, tunneling protocols also have a big 353 impact on the MTU size. Hence, MAMS should support concatenation 354 such that multiple IP packets may be encapsulated into a single 355 packet to improve efficiency. MAMS should also support fragmentation 356 such that a single IP packet may be fragmented and encapsulated into 357 multiple ones to avoid IP fragmentation. 359 7.11. Configuring network middleboxes based on negotiated protocols 361 MAMS enables identification of the optimal parameters that may be 362 used for configuring the middle-boxes, like binding expiry times and 363 supported MTUs, for efficient operation of the user plane protocols, 364 depending on the data plane related parameters negotiated between the 365 client and the network, e.g. Configuring longer binding expiry time 366 in NATs when UDP transport is used in contrast to the scenario where 367 TCP is configured at the transport layer. 369 7.12. Policy based Optimal path selection 371 MAMS framework should support consideration of policies at the 372 client, in addition to guidance from the network in determination of 373 network paths selected for different application services. 375 7.13. MAMS Control signaling 377 MAMS control signaling is carried over the user plane and is 378 transparent to the transport protocols. MAMS should support delivery 379 of control signaling over the existing Internet protocols, e.g. TCP 380 or UDP. 382 7.14. Service discovery and reachability 384 MAMS offers the flexibility for the functional entity NCM to be 385 collocated with any of the network elements and reachable via any of 386 the available user plane paths. MAMS framework allows the 387 flexibility for the CCM to choose one of the available NCMs and 388 exchange control plane signaling over any of the available user plane 389 paths. The choice of NCM can be based on considerations like, but 390 not limited to, quality of link through which the NCM is reachable, 391 Client preference, or pre-configuration etc. 393 8. MAMS Reference Architecture 394 +---------------------------------------------------+ 395 ! +---------------+ +---------------+ ! 396 ! ! ! ! ! ! 397 ! !Core(IP anchor)! !Core(IP anchor)! ! 398 ! !(network n) ! !(network 1) ! ! 399 ! ! ! ! ! ! 400 ! +---------------+ +---------------+ ! 401 ! +-----------------------+ ! 402 ! ! +-----+ +------+ ! ! 403 ! ! ! NCM ! !N-MADP| ! ! 404 ! ! +-----+ +------+ ! ! 405 ! +-----------------------+ ! 406 ! ! 407 ! +-----------+ +---------------+ ! 408 ! ! ! ! ! ! 409 ! ! ! ! ! ! 410 ! !access ! !access ! ! 411 ! !(network n)! !(network 1) ! ! 412 ! ! ! ! ! ! 413 ! +-----------+ +---------------+ ! 414 +---------------------------------------------------+ 416 +-----------------+ 417 ! +------+ +-----+! 418 ! |C-MADP| ! CCM !! 419 ! +------+ +-----+! 420 ! Client ! 421 +-----------------+ 423 Figure 1: MAMS Reference Architecture 425 Figure 1 illustrates MAMS architecture for the scenario of a client 426 served by multiple (n) networks. The NCM and N-MADP, functional 427 elements, are introduced for supporting MAMS mechanisms. The 428 architecture is extendable to combine any number of networks, as well 429 as any choice of participating network types (e.g. LTE, WLAN, 430 MuLTEfire, DSL) and deployment architectures (e.g. with user plane 431 gateway function at the access edge). 433 The N-MADP entity, at the network, handles the user data traffic 434 forwarding across multiple network paths, as well as other user-plane 435 functionalities, e.g. encapsulation, fragmentation, concatenation, 436 reordering, retransmission, etc. N-MADP is the distribution node for 437 uplink and downlink data delivery with visibility of packets at the 438 IP layer. There can be multiple N-MADP entities in the network, e.g. 439 to load balance across clients. A single client can also be served 440 by multiple N-MADP instances, e.g to address different user plane 441 requirements of multiple applications running on the client. 442 Identification and distribution rules for different user data traffic 443 types at the N-MADP are configured by the NCM. The NCM configures 444 the data delivery paths, access links, and user plane protocols to be 445 used by N-MADP for downlink user data traffic. The CCM configures 446 the data delivery paths, access links, and user plane protocols to be 447 used by C-MADP for uplink user data traffic based on the signaling 448 exchanged with NCM. In the UL, NCM allows selection of the core 449 network path to be used by N-MADP to route uplink user data. 451 The scheduling and load balancing algorithm at the N-MADP is 452 configured by the NCM, based on static and/or dynamic network 453 policies like assigning access and core paths for specific user data 454 traffic type, data volume based percentage distribution, and link 455 availability and feedback information from exchange of MAMS signaling 456 with the CCM at the Client. 458 At the client, the Client Connection Manager (CCM) manages the 459 multiple network connections. CCM is responsible for exchange of 460 MAMS signaling messages with the NCM for supporting functions like UL 461 and DL user network path configuration for transporting user data 462 packets, link probing and reporting to support adaptive network path 463 selection by NCM. In the downlink, for the user data received by the 464 client, it configures C-MADP such that application data packet 465 received over any of the accesses to reach the appropriate 466 application on the client. In the uplink, for the data transmitted 467 by the client, it configures the C-MADP to determine the best access 468 links to be used for uplink data based on a combination of local 469 policy and network policy delivered by the NCM. The C-MADP entity 470 handles all MAMS-specific user-plane functionalities at the client, 471 e.g. encapsulation, fragmentation, concatenation, reordering, 472 retransmissions, etc. C-MADP is configured by CCM based on signaling 473 exchange with NCM and local policies at the client. 475 A user plane tunnel, e.g. IPsec, may be needed for transporting user 476 data packets between the N-MADP at the network and the C-MADP at the 477 client. The user plane tunnel is needed to ensure security and 478 routability of the user plane packets between the N-MADP and the 479 C-MADP. The most common implementation of the user plane tunnel is 480 the IPsec. C-MADP receives the configuration from CCM indicates, to 481 C-MADP, the access network interfaces over which the IPsec tunnel 482 needs to be established, and for each of the indicated interfaces, 483 the parameters (e.g. N-MADP IPsec endpoint IP address reachable via 484 the indicated access network interface) for setting up the IPsec 485 tunnel. C-MADP sets up the IPsec tunnel with the N-MADP via each of 486 the indicated access network interfaces, using appropriate signaling, 487 say IKEv2 and parameters provided by the CCM. In deployments where 488 N-MADP and the client are connected via a secure and direct IP path, 489 user plane tunnel may not be needed. Note that the method for 490 transporting user data packets between the N-MADP and the C-MADP 491 should be general, based on the existing protocols, and consider 492 minimizing overhead. 494 9. Solution Principles 496 +----------------------------------------+ 497 | MAMS enabled Network of Networks | 498 | +-----+ +-----+ +-----+ +------+ 499 +-----------------+ | | | | | | | | || 500 | Client | | |Netwo| |Netwo| | | | || 501 | +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP|| 502 | C-MADP |CCM | | | |(LTE)| |(WiFi) | | | || 503 | +-----+ +-----+ | | +-----+ +-----+ +-----+ +------| 504 -+----------------+ +----------------------------------------+ 505 | | | | | | | 506 | | | | | | | 507 | | 1.SETUP CONNECTION| | | | 508 |<-----------+------------>| | | | 509 | | | + + | | 510 | | | 2. MAMS Capabilities Exchange | | 511 | | |<-------------+----------+-------->| | 512 | | | | | | | 513 | | + | | | | 514 | | 3. SETUP CONNECTION | | | 515 |<--+-------------------------------->| | | 516 | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| 517 | C-MADP | PROTOCOL AND PARAMETERS | |N-MADP | 518 | |<----->|<-------------+----------+-------->|<-------->| 519 | | | + + | | 520 | | |5. ESTABLISH USER PLANE PATH ACCORDING TO | 521 | | | SELECTED FLOW PROTOCOL | | | 522 | |<---------------------+----------+------------------->| 523 | | | | | | | 524 + + + + + + + 526 Figure 2: MAMS call flow 528 Figure 2 illustrates the MAMS signaling mechanism for negotiation of 529 network paths and flow protocols between the client and the network. 530 In this example scenario, the client is connected to two networks 531 (say LTE and WiFi). 533 1. UE connects to network 1 and gets an IP address assigned by 534 network 1. 535 2. CCM communicates with NCM functional element via the network 1 536 connection and exchanges capabilities and parameters for MAMS 537 operation. Note: The NCM credentials (e.g. NCM IP Address) can 538 be made known to the UE by pre-provisioning. 539 3. Client sets up connection with network 2 and gets an IP address 540 assigned by network 2. 541 4. CCM and NCM negotiate capabilities and parameters for 542 establishment of network paths, which are then used to configure 543 user plane functions N-MADP at the network and C-MADP at the 544 client. 546 4a. CCM and NCM negotiate network paths, flow routing and 547 aggregation protocols, and related parameters. 549 4b. NCM communicates with the N-MADP to exchange and configure 550 flow aggregation protocols, policies and parameters in alignment 551 with those negotiated with the CCM. 553 4c. CCM communicates with the C-MADP to exchange and configure 554 flow aggregation protocols, policies and parameters in alignment 555 with those negotiated with the NCM. 557 5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE 558 [RFC7296] signaling, based on the negotiated flow aggregation 559 protocols and parameters specified by NCM. 561 CCM and NCM can further exchange messages containing access link 562 measurements for link maintenance by the NCM. NCM evaluates the link 563 conditions in the UL and DL across LTE and WiFi, based on link 564 measurements reported by CCM and/or link probing techniques and 565 determines the UL and DL user data distribution policy. NCM and CCM 566 also negotiate application level policies for categorizing 567 applications, e.g. based on DSCP, Destination IP address, and 568 determining which of the available network paths, needs to be used 569 for transporting data of that category of applications. NCM 570 configures N-MADP and CCM configures C-MADP based on the negotiated 571 application policies. CCM may apply local application policies, in 572 addition to the application policy conveyed by the NCM. 574 10. Implementation considerations 576 MAMS builds on commonly available functions available on terminal 577 devices that can be delivered as a software update over the popular 578 end-user device operating systems, enabling rapid deployment and 579 addressing the large deployed device base. 581 11. Applicability to Mobile Edge Computing 583 Mobile edge computing (MEC) is an access-edge cloud platform being 584 standardized at ETSI, whose initial focus was to improve quality of 585 experience by leveraging intelligence at cellular (e.g. 3GPP 586 technologies like LTE) access edge, and the scope is now being 587 extended to support access technologies beyond 3GPP. This 588 applicability of the framework described in this document to the MEC 589 platform has been evaluated and tested in different network 590 configurations. 592 The NCM and N-MADP are hosted on the MEC cloud server that is located 593 in the user plane path at the edge of multi-technology access 594 networks, and in a particular large venue use case at the edge of LTE 595 and Wi-Fi access networks. The NCM and CCM negotiate the network 596 path combinations based on application needs and the necessary user 597 plane protocols to manage the multiple paths. The network conditions 598 reported by the CCM to the NCM is used in addition to Radio Analytics 599 application residing at the MEC to configure the uplink and downlink 600 access paths according to changing radio and congestion conditions. 602 The aim of these enhancements is to improve the end-user's quality of 603 experience by leveraging the best network path based on application 604 needs and network conditions, and building on the advantages of 605 significantly reduced latency and the dynamic and real-time exposure 606 of radio network information available at the MEC. 608 12. Security Considerations 610 This section details the security considerations for the MAMS 611 framework. 613 12.1. Data and Control plane security 615 Signaling messages and the user data in MAMS framework rely on the 616 security of the underlying network transport paths. When this cannot 617 be assumed, network connection manager configures use of protocols, 618 like IPsec [RFC4301] [RFC3948], for securing user data and MAMS 619 signaling messages. 621 13. Contributors 623 This protocol is the outcome of work by many engineers, not just the 624 authors of this document. In alphabetical order, the contributors to 625 the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru 626 Calin, Jonathan Ling, Krishna Pramod A., Lohith Nayak, Michael 627 Scharf. 629 14. References 631 14.1. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 639 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 640 December 2005, . 642 14.2. Informative References 644 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 645 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 646 RFC 3948, DOI 10.17487/RFC3948, January 2005, 647 . 649 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 650 Kivinen, "Internet Key Exchange Protocol Version 2 651 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 652 2014, . 654 Authors' Addresses 656 Satish Kanugovi 657 Nokia 659 Email: satish.k@nokia.com 661 Subramanian Vasudevan 662 Nokia 664 Email: vasu.vasudevan@nokia.com 666 Florin Baboescu 667 Broadcom 669 Email: florin.baboescu@broadcom.com 670 Jing Zhu 671 Intel 673 Email: jing.z.zhu@intel.com 675 Shuping Peng 676 Huawei 678 Email: pengshuping@huawei.com 680 Julius Mueller 681 AT&T 683 Email: jm169k@att.com 685 SungHoon Seo 686 Korea Telecom 688 Email: sh.seo@kt.com