idnits 2.17.1 draft-kanugovi-intarea-mams-protocol-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 : ---------------------------------------------------------------------------- ** 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 (October 21, 2016) is 2734 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: April 24, 2017 F. Baboescu 6 Broadcom 7 J. Zhu 8 Intel 9 October 21, 2016 11 Multiple Access Management Protocol 12 draft-kanugovi-intarea-mams-protocol-01 14 Abstract 16 A communication network includes an access network element that 17 delivers data to/from the user and an associated core network element 18 providing connectivity with the application servers. 19 Multiconnectivity scenarios are common where a device can be 20 simultaneously connected to multiple communication networks based on 21 different technology implementations and network architectures like 22 WiFi, LTE, DSL. A smart combination and selection of access and core 23 network paths that can dynamically adapt to changing network 24 conditions can improve quality of experience for a user in a 25 multiconnectivity scenario and improve overall network utilization 26 and efficiency. This document presents the problem statement and 27 proposes solution principles. It specifies the requirements and 28 reference architecture for a multi access management services 29 framework that can be used to flexibly select the best combination of 30 uplink and downlink access and core network paths, ensuring better 31 network efficiency and enhanced application performance. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 24, 2017. 50 Copyright Notice 52 Copyright (c) 2016 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 (http://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. Conventions used in this document . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Solution Principles . . . . . . . . . . . . . . . . . . . . . 5 72 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6.1. Access technology agnostic interworking . . . . . . . . . 6 74 6.2. Support common transport deployments . . . . . . . . . . 6 75 6.3. Independent Access path selection for Uplink and Downlink 6 76 6.4. IP anchor selection independent of uplink and downlink 77 access . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.5. Adaptive network path selection . . . . . . . . . . . . . 6 79 6.6. Multipath support and Aggregation of access link 80 capacities . . . . . . . . . . . . . . . . . . . . . . . 6 81 6.7. Scalable mechanism based on IP interworking . . . . . . . 7 82 6.8. Separate Control and Data plane functions . . . . . . . . 7 83 6.9. Lossless Path (Connection) Switching . . . . . . . . . . 7 84 6.10. Concatenation and Fragmentation to adapt to MTU 85 differences . . . . . . . . . . . . . . . . . . . . . . . 7 86 6.11. Configuring network middleboxes based on negotiated 87 protocols . . . . . . . . . . . . . . . . . . . . . . . . 8 88 6.12. Client policy . . . . . . . . . . . . . . . . . . . . . . 8 89 6.13. Control plane signaling . . . . . . . . . . . . . . . . . 8 90 6.14. Service discovery and reachability . . . . . . . . . . . 8 91 7. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 8 92 8. MAMS call flow . . . . . . . . . . . . . . . . . . . . . . . 11 93 9. Implementation considerations . . . . . . . . . . . . . . . . 12 94 10. Applicability to Mobile Edge Computing . . . . . . . . . . . 12 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 11.1. Data and Control plane security . . . . . . . . . . . . 13 97 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 100 13.2. Informative References . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 103 1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Introduction 111 Multi Access Management Signaling (MAMS) is a programmable framework 112 that allows to select and configure network paths, as well as adapt 113 to dynamic network conditions, when multiple network connections can 114 serve a client device. It is based on principles of user plane 115 interworking that enables the solution to be deployed as an overlay 116 without impacting the underlying networks. The framework provides 117 for mechanisms for flexible selection of network paths based on 118 application needs that can be leverage network intelligence and 119 policies to dynamically adapt to changing conditions. 121 The document presents the requirements, solution principles and 122 functional architecture for the MAMS framework. MAMS mechanisms are 123 not dependent on any specific network and transport protocols like 124 TCP, UDP, GRE, MPTCP etc. It co-exists and complements the existing 125 protocols by providing a way to negotiate and configure the protocols 126 based on client and network capabilities. Further it allows exchange 127 of network state information and leveraging network intelligence to 128 optimize the performance of such protocols. 130 An important goal for MAMS is to ensure that there is minimal or no 131 dependency on the actual access technology of the participating 132 links, beyond the fact that there is IP connectivity between the 133 access nodes. This allows the scheme to be scalable for addition of 134 newer accesses and for independent technology evolution of the 135 existing accesses. 137 3. Terminology 139 "Client": The end-user device supporting connections with multiple 140 access nodes, possibly over different access technologies. 142 "Multiconnectivity Client": A client with multiple network 143 connections. 145 "Access network functional element": The functional element in the 146 network that delivers user data packets to the client via an access 147 link like WiFi airlink, LTE airlink, DSL. 149 "Core": The functional element that anchors the client's IP address 150 used for communication with applications via the network. 152 "User Plane Gateway": The functional element that can intercept and 153 route user data packets. 155 "Network Connection manager"(NCM): A functional entity in the network 156 that oversees distribution of data packets over the multiple 157 available access and core network paths. 159 "Client Connection Manager" (CCM): A functional entity in the client 160 that exchanges MAMS Signaling with the Network Connection Manager and 161 configures the multiple network paths for transport of user data. 163 "Network Multi Access Data Proxy" (N-MADP): This functional entity in 164 the network handles the user data traffic forwarding across multiple 165 network paths. N-MADP is responsible for MAMS-specific u-plane 166 functionalities in the network. 168 "Client Multi Access Data Proxy" (C-MADP): This functional entity in 169 the client handles the user data traffic forwarding across multiple 170 network paths. C-MADP is responsible for MAMS-specific u-plane 171 functionalities in the client. 173 4. Problem Statement 175 Typically, a device has access to multiple communication networks 176 based on different technologies, say LTE, WiFi, DSL, MuLTEfire, for 177 accessing application services. Different technologies exhibit 178 benefits and limitations in different scenarios. For example, WiFi 179 leverages the large spectrum available in unlicensed spectrum to 180 deliver high capacities at low cost in uncongested scenarios with 181 small user population, but can show significant degradation in 182 application performance in congested scenarios with large user 183 population. Another example is LTE network, the capacity of which is 184 often constrained by high cost and limited availability of the 185 licensed spectrum, but offers predictable service even in multi-user 186 scenarios due to controlled scheduling and licensed spectrum usage. 188 Additionally, the use of a particular access network path is often 189 coupled with the use of the associated core network. For example, in 190 an enterprise that has deployed WiFi and LTE communications network, 191 enterprise applications, like printers, Corporate Audio and Video 192 conferencing, are accessible only via WiFi access connected to the 193 enterprise hosted WiFi core, whereas the LTE access can be used to 194 get LTE operator core anchored services including access to public 195 internet. 197 Application performance in different scenarios, therefore becomes 198 dependent on the choice of the communication networks due to the 199 tight coupling of the access and the core network paths. Therefore 200 to leverage the best possible application performance in the widest 201 possible scenarios, a framework is needed that allows flexible 202 selection of the combination of access and core network paths for 203 application data delivery. 205 For example, in uncongested scenarios, it would be beneficial to use 206 WiFi access in the uplink and downlink for connecting to enterprise 207 applications. Whereas in congested scenarios, where use of WiFi in 208 uplink by multiple users can lead to degraded capacity and increased 209 delays due to contention, it would be beneficial to use scheduled LTE 210 uplink access combined with WiFi downlink. 212 5. Solution Principles 214 This document proposes a Multiple Access Management Services(MAMS) 215 framework for dynamic selection of uplink and downlink access and 216 core network paths for a device connected to multiple communication 217 networks. The multiple communication networks interwork at the user 218 plane. The selection of paths is based on negotiation of 219 capabilities and network link quality between the device and a 220 functional element in the network, namely the network connection 221 manager (NCM). NCM has the intelligence to setup and offer the best 222 network path based on device and network capabilities, application 223 needs and knowledge of the network state. 225 The NCM communicates with the Client Connection Manager (CCM), a 226 functional element in the device, for negotiation, sharing 227 information on the network path conditions, and configuring usage of 228 the network paths. The messages between the NCM and CCM are carried 229 as user plane data over any of the available network paths between 230 the NCM and CCM. 232 6. Requirements 234 The requirements set out in this section are for the behavior of the 235 MAMS mechanism and the related functional elements. 237 6.1. Access technology agnostic interworking 239 The access nodes can be of different technology types like LTE, WiFi 240 etc. Since MAMS routes user plane data packets at the IP layer, 241 which makes it agnostic to the type of underlying technology used at 242 the access nodes. 244 6.2. Support common transport deployments 246 The network path selection and user plane distribution should work 247 transparently across transport deployments that include e2e IPsec, 248 VPNs, and middleboxes like NATs and proxies. 250 6.3. Independent Access path selection for Uplink and Downlink 252 IP layer routing enables the client to transmit on uplink using one 253 access and receive data on downlink using another access, allowing 254 client and network connection manager to select the access paths for 255 uplink and downlink independent of each other. 257 6.4. IP anchor selection independent of uplink and downlink access 259 A client is able to flexibly negotiate the IP anchor, core network, 260 independent of the access paths used to reach the IP anchor depending 261 on the application needs. 263 6.5. Adaptive network path selection 265 The NCM node has the ability to determine the quality of each of the 266 network paths, e.g. access link delay and capacity. The network path 267 quality information is fed into the logic for selection of 268 combination of network paths to be used for transporting user data. 269 The path selection algorithm can use network path quality 270 information, in addition to other considerations like network 271 policies, for optimizing network usage and enhancing QoE delivered to 272 the user. 274 6.6. Multipath support and Aggregation of access link capacities 276 MAMS supports distribution and aggregation of user data across 277 multiple network paths at the IP layer. MAMS allows the client to 278 leverage the combined capacity of the multiple network connections by 279 enabling simultaneous transport of user data over multiple network 280 paths. If required, packet re-ordering is done at the receiver, 281 client(C-MADP) and/or the network (N-MADP), when user data packets 282 are received out of order. MAMS allows flexibility to choose the 283 flow steering and aggregation protocol based on capabilities 284 supported by the client and the network data plane entities, C-MADP 285 and N-MADP respectively. A MAMS multi-connection aggregation 286 solution should support existing transport and network layer 287 protocols like TCP, UDP, GRE. If flow aggregation functions are 288 realized using existing protocols such as Multi-Path TCP(MPTCP) and 289 SCTP, MAMS framework should allow use and configuration of these 290 aggregation protocols. 292 6.7. Scalable mechanism based on IP interworking 294 The mechanism is based on IP interworking, requiring only the IP 295 connectivity between the access nodes and the interworking 296 functionality is based on generically available IP routing and 297 tunneling capabilities. This makes solution easy to deploy and scale 298 easily when different networks are added and removed. 300 6.8. Separate Control and Data plane functions 302 The client negotiates with a network connection manager the choice of 303 access for both uplink and downlink accesses and the IP anchor(core). 304 The network connection manager configures the actual user data 305 distribution function residing in the Anchor element, thus 306 maintaining a clear separation between the control and data plane 307 functions. This makes the MAMS framework amenable to SDN based 308 architecture and implementations. 310 6.9. Lossless Path (Connection) Switching 312 When switching data traffic from one path (connection) to another, 313 packets may be lost or delivered out-of-order, which will have 314 negative impacts on the performance of higher layer protocols, e.g. 315 TCP. MAMS should provide necessary mechanisms to ensure in-order 316 delivery at the receiver, as well as support retransmissions at the 317 transmitter during path switching. 319 6.10. Concatenation and Fragmentation to adapt to MTU differences 321 MAMS should support heterogeneous access networks, which may have 322 different MTU sizes. Moreover, tunneling protocols also have a big 323 impact on the MTU size. Hence, MAMS should support concatenation 324 such that multiple IP packets may be encapsulated into a single 325 packet to improve efficiency. MAMS should also support fragmentation 326 such that a single IP packet may be fragmented and encapsulated into 327 multiple ones to avoid IP fragmentation. 329 6.11. Configuring network middleboxes based on negotiated protocols 331 MAMS enables identification of the optimal parameters that may be 332 used for configuring the middle-boxes, like binding expiry times and 333 supported MTUs, for efficient operation of the user plane protocols, 334 depending on the data plane related parameters negotiated between the 335 client and the network. e.g. Configuring longer binding expiry time 336 in NATs when UDP transport is used in contrast to the scenario where 337 TCP is configured at the transport layer. 339 6.12. Client policy 341 MAMS framework should support consideration of policies at the 342 client, in addition to guidance from the network in determination of 343 network paths selected for different application services. 345 6.13. Control plane signaling 347 MAMS control signaling is carried over the user plane and is 348 transparent to the transport protocols. MAMS should support delivery 349 of control signaling over the existing Internet protocols, e.g. TCP 350 or UDP. 352 6.14. Service discovery and reachability 354 MAMS offers the flexibility for the functional entity NCM to be 355 collocated with any of the network elements and reachable via any of 356 the available user plane paths. MAMS framework allows the 357 flexibility for the CCM to choose one of the available NCM's and 358 exchange control plane signaling over any of the available user plane 359 paths. The choice of NCM can be based on considerations like, but 360 not limited to, quality of link through with the NCM is reachable, 361 Client preference or pre-configuration etc. 363 7. MAMS Reference Architecture 364 +---------------------------------------------------+ 365 ! +---------------+ +---------------+ ! 366 ! ! ! ! ! ! 367 ! !Core(IP anchor)! !Core(IP anchor)! ! 368 ! !(network 2) ! !(network 1) ! ! 369 ! ! ! ! ! ! 370 ! +---------------+ +---------------+ ! 371 ! +-----------------------+ ! 372 ! ! +-----+ +------+ ! ! 373 ! ! ! NCM ! !N-MADP| ! ! 374 ! ! +-----+ +------+ ! ! 375 ! +-----------------------+ ! 376 ! ! 377 ! +-----------+ +---------------+ ! 378 ! ! ! ! ! ! 379 ! ! ! ! ! ! 380 ! !access ! !access ! ! 381 ! !(network 2)! !(network 1) ! ! 382 ! ! ! ! ! ! 383 ! +-----------+ +---------------+ ! 384 +---------------------------------------------------+ 386 +-----------------+ 387 ! +------+ +-----+! 388 ! |C-MADP| ! CCM !! 389 ! +------+ +-----+! 390 ! Client ! 391 +-----------------+ 393 Figure 1: MAMS Reference Architecture 395 Figure 1 illustrates MAMS architecture for the scenario of a client 396 served by 2 networks. The NCM and MADP, functional elements, are 397 introduced for supporting MAMS mechanisms. The architecture is 398 extendable to combine more than 2 networks, as well as any choice of 399 participating network types (e.g. LTE, WLAN, MuLTEfire, DSL) and 400 deployment architectures (e.g. with user plane gateway function at 401 the access edge). 403 The N-MADP entity, at the network, handles the user data traffic 404 forwarding across multiple network paths, as well as other user-plane 405 functionalities, e.g. encapsulation, fragmentation, concatenation, 406 reordering, retransmission, etc. N-MADP is the distribution node for 407 uplink and downlink data with visibility of packets at the IP layer. 408 Identification and distribution rules for different user data traffic 409 type at the N-MADP are configured by the NCM. The NCM configures the 410 routing in the N-MADP based on signaling exchanged with the CCM in 411 the client. In the UL, NCM specifies the core network path to be 412 used by MADP to route uplink user data at the N-MADP. In the DL, NCM 413 specifies the access links to be used for delivery of data to the 414 client at the N-MADP. 416 The scheduling and load balancing algorithm at the N-MADP is 417 configured by the NCM, based on static and/or dynamic network 418 policies like assigning access and core paths for specific user data 419 traffic type, data volume based percentage distribution, and link 420 availability and feedback information from exchange of MAMS signaling 421 with the CCM at the Client. 423 At the client, the Client Connection Manager (CCM) manages the 424 multiple network connections. CCM is responsible for exchange of 425 MAMS signaling messages with the NCM for supporting functions like 426 configuring UL and DL user network path configuration for 427 transporting user data packets, link sounding and reporting to 428 support adaptive network path selection by NCM. In the downlink, for 429 the user data received by the client, it configures IP layer 430 forwarding for application data packet received over any of the 431 accesses to reach the appropriate application module on the client. 432 In the uplink, for the data transmitted by the client, it configures 433 the routing table to determine the best access to be used for uplink 434 data based on a combination of local policy and network policy 435 delivered by the NCM. The C-MADP entity handles all MAMS-specific 436 user-plane functionalities at the client, e.g. encapsulation, 437 fragmentation, concatenation, reordering, retransmissions, etc. 438 C-MADP is configured by CCM based on signaling exchange with NCM and 439 local policies at the client. 441 A user plane tunnel, e.g. IPsec, may be needed for transporting user 442 data packets between the N-MADP at the network and the C-MADP at the 443 client. The user plane tunnel is needed to ensure security and 444 routability of the user plane packets between the N-MADP and the 445 C-MADP. The most common implementation of the user plane tunnel is 446 the IPsec. C-MADP receives the configuration from CCM indicates, to 447 C-MADP, the access network interfaces over which the IPsec tunnel 448 needs to be established, and for each of the indicated interfaces, 449 the parameters (e.g. N-MADP IPsec endpoint IP address reachable via 450 the indicated access network interface) for setting up the IPsec 451 tunnel. C-MADP sets up the IPsec tunnel with the N-MADP via each of 452 the indicated access network interfaces, using appropriate signaling, 453 say IKEv2 and parameters provided by the CCM. In deployments where 454 the access node belonging to the two networks are connected via a 455 secure and direct IP path, user plane tunnel may not be needed. 456 Notice that the method for transporting user data packets between the 457 N-MADP and the C-MADP should be general and based on the existing 458 protocols. 460 8. MAMS call flow 462 +----------------------------------------+ 463 | MAMS enabled Network of Networks | 464 | +-----+ +-----+ +-----+ +------+ 465 +-----------------+ | | | | | | | | || 466 | Client | | |Netwo| |Netwo| | | | || 467 | +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP|| 468 | C-MADP |CCM | | | |(LTE)| |(WiFi) | | | || 469 | +-----+ +-----+ | | +-----+ +-----+ +-----+ +------| 470 -+----------------+ +----------------------------------------+ 471 | | | | | | | 472 | | | | | | | 473 | | 1.SETUP CONNECTION| | | | 474 |<-----------+------------>| | | | 475 | | | + + | | 476 | | | 2. MAMS Capabilities Exchange | | 477 | | |<-------------+----------+-------->| | 478 | | | | | | | 479 | | + | | | | 480 | | 3. SETUP CONNECTION | | | 481 |<--+-------------------------------->| | | 482 | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| 483 | C-MADP | PROTOCOL AND PARAMETERS | |N-MADP | 484 | |<----->|<-------------+----------+-------->|<-------->| 485 | | | + + | | 486 | | |5. ESTABLISH USER PLANE PATH ACCORDING TO | 487 | | | SELECTED FLOW PROTOCOL | | | 488 | |<---------------------+----------+------------------->| 489 | | | | | | | 490 + + + + + + + 492 Figure 2: MAMS call flow 494 Figure 2 illustrates the MAMS signaling mechanism for negotiation of 495 network paths and flow protocols between the client and the network. 496 In this example scenario, the client is connected to two networks 497 (say LTE and WiFi). 499 1. UE connects to network 1 and gets an IP address assigned by 500 network 1. 501 2. CCM communicates with NCM functional element via the network 1 502 connection and exchanges capabilities and parameters for MAMS 503 operation. Note: The NCM credentials can be made known to the UE 504 by pre-provisioning. 506 3. Client sets up connection with network 2 and gets an IP address 507 assigned by network 2. 508 4. CCM and NCM negotiate capabilities and parameters for 509 establishment of network paths, which are then used to configure 510 user plane functions N-MADP at the network and C-MADP at the 511 client. 513 4a. CCM and NCM negotiate network paths, flow routing and 514 aggregation protocols, and related parameters. 516 4b. NCM communicates with the N-MADP to exchange and configure 517 flow aggregation protocols, policies and parameters in alignment 518 with those negotiated with the CCM. 520 4c. CCM communicates with the C-MADP to exchange and configure 521 flow aggregation protocols, policies and parameters in alignment 522 with those negotiated with the NCM. 524 5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE 525 [RFC7296] signaling, based on the negotiated flow aggregation 526 protocol and parameters specified by NCM. 528 CCM and NCM can further exchange messages containing access link 529 measurements for link maintenance by the NCM. NCM evaluates the link 530 conditions in the UL and DL across LTE and WiFi, based on link 531 measurements reported by CCM and/or link probing techniques and 532 determines the UL and DL user data distribution policy. NCM and CCM 533 also negotiate application level policies for categorizing 534 applications, e.g. based on DSCP, Destination IP address, and 535 determining which of the available network paths, needs to be used 536 for transporting data of that category of applications. NCM 537 configures N-MADP and CCM configures C-MADP based on the negotiated 538 application policies. CCM may apply local application policies, in 539 addition to the application policy conveyed by the NCM. 541 9. Implementation considerations 543 MAMS builds on commonly available functions available on terminal 544 devices that can be delivered as a software update over the popular 545 end-user device operating systems, enabling rapid deployment and 546 addressing the large deployed device base. 548 10. Applicability to Mobile Edge Computing 550 Mobile edge computing (MEC) is an access-edge cloud platform being 551 standardized at ETSI, whose initial focus was to improve quality of 552 experience by leveraging intelligence at cellular (e.g. 3GPP 553 technologies like LTE) access edge, and the scope is now being 554 extended to support access technologies beyond 3GPP. This 555 applicability of the framework described in this document to the MEC 556 platform has been evaluated and tested in different network 557 configurations. 559 The NCM and N-MADP are hosted on the MEC cloud server that is located 560 in the user plane path at the edge of multi-technology access 561 networks, and in a particular large venue use case at the edge of LTE 562 and Wi-Fi access networks. The NCM and CCM negotiate the network 563 path combinations based on application needs and the necessary user 564 plane protocols to manage the multiple paths. The network conditions 565 reported by the CCM to the NCM is used in addition to Radio Analytics 566 application residing at the MEC to configure the uplink and downlink 567 access paths according to changing radio and congestion conditions. 569 The aim of these enhancements is to improve the end-user's quality of 570 experience by leveraging the best network path based on application 571 needs and network conditions. 573 11. Security Considerations 575 This section details the security considerations for the MAMS 576 framework. 578 11.1. Data and Control plane security 580 Signaling messages and the user data in MAMS framework rely on the 581 security of the underlying network transport paths. When this cannot 582 be assumed, network connection manager configures use of protocols, 583 like IPsec [RFC4301] [RFC3948], for securing user data and MAMS 584 signaling messages. 586 12. Contributors 588 This protocol is the outcome of work by many engineers, not just the 589 authors of this document. In alphabetical order, the contributors to 590 the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru 591 Calin, Jonathan Ling, Krishna Pramod A., Lohith Nayak, Michael 592 Scharf. 594 13. References 596 13.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 604 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 605 December 2005, . 607 13.2. Informative References 609 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 610 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 611 RFC 3948, DOI 10.17487/RFC3948, January 2005, 612 . 614 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 615 Kivinen, "Internet Key Exchange Protocol Version 2 616 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 617 2014, . 619 Authors' Addresses 621 Satish Kanugovi 622 Nokia 624 Email: satish.k@nokia.com 626 Subramanian Vasudevan 627 Nokia 629 Email: vasu.vasudevan@nokia.com 631 Florin Baboescu 632 Broadcom 634 Email: florin.baboescu@broadcom.com 636 Jing Zhu 637 Intel 639 Email: jing.z.zhu@intel.com