idnits 2.17.1 draft-kanugovi-intarea-mams-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 (July 17, 2016) is 2838 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: 2 errors (**), 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: January 18, 2017 F. Baboescu 6 Broadcom 7 July 17, 2016 9 Multiple Access Management Protocol 10 draft-kanugovi-intarea-mams-protocol-00 12 Abstract 14 A communication network includes an access network element that 15 delivers data to/from the user and an associated core network element 16 that typically is the IP gateway having connectivity with the 17 application servers. Multiconnectivity scenarios are common where a 18 device can be simultaneously connected to multiple communication 19 networks based on different technology implementations and network 20 architectures like WiFi, LTE, DSL. A smart combination and selection 21 of access and core network paths can improve quality of experience 22 that a user in a multiconnectivity scenario. This document presents 23 the problem statement and proposes solution principles. It specifies 24 the requirements and reference architecture for a multi access 25 management services framework that can be used to flexibly select the 26 best combination of uplink and downlink access and core network 27 paths, ensuring better network efficiency and enhanced application 28 performance. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 18, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Conventions used in this document . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Solution Principles . . . . . . . . . . . . . . . . . . . . . 4 68 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5.1. Access technology agnostic interworking . . . . . . . . . 4 70 5.2. Support common transport deployments . . . . . . . . . . 5 71 5.3. Independent Access path selection for Uplink and Downlink 5 72 5.4. IP anchor selection independent of uplink and downlink 73 access . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.5. Adaptive network path selection . . . . . . . . . . . . . 5 75 5.6. Multipath support and Aggregation of access link 76 capacities . . . . . . . . . . . . . . . . . . . . . . . 5 77 5.7. Scalable mechanism based on IP interworking . . . . . . . 5 78 5.8. Separate Control and Data plane functions . . . . . . . . 6 79 6. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 6 80 7. MAMS call flow . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 8.1. Data and Control plane security . . . . . . . . . . . . . 9 83 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Terminology 97 "Client": The end-user device supporting connections with multiple 98 access nodes, possibly over different access technologies. 100 "Multiconnectivity Client": A client with multiple network 101 connections. 103 "Access network element": The functional element in the network that 104 delivers user data packets to the client via a point-to-point access 105 link like WiFi airlink, LTE airlink, DSL. 107 "Core": The functional element that anchors the client's IP address 108 used for communication with applications via the network. 110 "User Plane Gateway": The functional element that can intercept and 111 route user data packets. 113 "Network Connection manager"(NCM): A functional entity in the network 114 that oversees distribution of data packets over the multiple 115 available access and core network paths. 117 "Client Connection Manager" (CCM): A functional entity in the client 118 that exchanges MAMS Signaling with the Network Connection Manager and 119 configures the multiple network paths for transport of user data. 121 "Anchor network element": The functional element in the network with 122 connectivity via multiple access paths to the client. 124 "Multi Access Data Proxy" (MADP ): This entity handles the user data 125 traffic forwarding across multiple network paths. 127 3. Problem Statement 129 Typically, a device has access to multiple communication networks 130 based on different technologies, say LTE, WiFi, DSL, MuLTEfire, for 131 accessing application services. Different technologies exhibit 132 benefits and limitations in different scenarios. For example, WiFi 133 leverages the large spectrum available in unlicensed spectrum to 134 deliver high capacities at low cost in uncongested scenarios with 135 small user population, but can show significant degradation in 136 application performance in congested scenarios with large user 137 population. Another example is LTE network, the capacity of which is 138 often constrained by high cost and limited availability of the 139 licensed spectrum, but offers predictable service even in multi-user 140 scenarios due to controlled scheduling and licensed spectrum usage. 142 Additionally, the use of a particular access network path is often 143 coupled with the use of the associated core network. For example, in 144 an enterprise that has deployed WiFi and LTE communications network, 145 enterprise applications, like printers, Corporate Audio and Video 146 conferencing, are accessible only via WiFi access connected to the 147 enterprise hosted WiFi core, whereas the LTE access can be used to 148 get LTE operator core anchored services including access to public 149 internet. 151 Application performance in different scenarios, therefore becomes 152 dependent on the choice of the communication networks due to the 153 tight coupling of the access and the core network paths. Therefore 154 to leverage the best possible application performance in the widest 155 possible scenarios, a framework is needed that allows flexible 156 selection of the combination of access and core network paths for 157 application data delivery. 159 For example, in uncongested scenarios, it would be beneficial to use 160 WiFi access in the uplink and downlink for connecting to enterprise 161 applications. Whereas in congested scenarios, where use of WiFi in 162 uplink by multiple users can lead to degraded capacity and increased 163 delays due to contention, it would be beneficial to use scheduled LTE 164 uplink access combined with WiFi downlink. 166 4. Solution Principles 168 This document proposes a Multiple Access Management Services(MAMS) 169 framework for dynamic selection of uplink and downlink access and 170 core network paths for a device connected to multiple communication 171 networks. The selection of paths is based on negotiation of 172 capabilities and network link quality between the device and a 173 functional element in the network, namely the network connection 174 manager. NCM has the intelligence to setup and offer the best 175 network path based on device and network capabilities, application 176 needs and knowledge of the network state. 178 5. Requirements 180 The requirements set out in this section are for the behavior of the 181 MAMS mechanism and the related functional elements. 183 5.1. Access technology agnostic interworking 185 The access nodes can be of different technology types like LTE, WiFi 186 etc. Since MAMS routes user plane data packets at the IP layer, 187 which makes it agnostic to the type of underlying technology used at 188 the access node for delivery of data to the client. 190 5.2. Support common transport deployments 192 The network path selection and user plane distribution should work 193 transparently across transport deployments that include e2e IPsec, 194 VPNs, and middleboxes like NATs and proxies. 196 5.3. Independent Access path selection for Uplink and Downlink 198 IP layer routing enables the client to transmit on uplink using one 199 access and receive data on downlink using another access, allowing 200 client and network connection manager to select the access paths for 201 uplink and downlink independent of each other. 203 5.4. IP anchor selection independent of uplink and downlink access 205 A client is able to flexibly negotiate the IP anchor, core network, 206 independent of the access paths used to reach the IP anchor depending 207 on the application needs. 209 5.5. Adaptive network path selection 211 The network connection manager node has the ability to determine the 212 quality of each of the network paths, e.g. access link delay and 213 capacity. The network path quality information is fed into the logic 214 for selection of combination of network paths to be used for 215 transporting user data. The path selection algorithm can use network 216 path quality information, in addition to other considerations like 217 network policies, for optimizing network usage and enhancing QoE 218 delivered to the user. 220 5.6. Multipath support and Aggregation of access link capacities 222 MAMS supports distribution and aggregation of user data across 223 multiple network paths. MAMS allows the client to leverage the 224 combined capacity of the multiple network connections by enabling 225 simultaneous transport of user data over multiple network paths. If 226 required, packet re-ordering is done at the receiver, client and/or 227 the Anchor network element, when user data packets are received out 228 of order. MAMS allows flexibility to choose the flow steering and 229 aggregation protocol based on capabilities supported by the client 230 and the Anchor network element. 232 5.7. Scalable mechanism based on IP interworking 234 The mechanism is based on IP interworking, requiring only the IP 235 connectivity between the access nodes and the interworking 236 functionality is based on generically available IP routing and 237 encapsulation capabilities. This makes solution easy to deploy and 238 scale easily when different networks are added and removed. 240 5.8. Separate Control and Data plane functions 242 The client negotiates with a network connection manager the choice of 243 access for both uplink and downlink accesses and the IP anchor(core). 244 The network connection manager configures the actual user data 245 distribution function residing in the Anchor element, thus 246 maintaining a clear separation between the control and data plane 247 functions. This makes the MAMS framework amenable to SDN based 248 architecture and implementations. 250 6. MAMS Reference Architecture 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 ! +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! 254 ! ! ! ! ! ! 255 ! !Core(IP anchor)! !Core(IP anchor)! ! 256 ! !(network 2) ! !(network 1) ! ! 257 ! ! ! ! ! ! 258 ! +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! 259 ! +-+-+-+-+-+-+-+-+-+-+-+-+ ! 260 ! ! +-+-+-+ +-+-+-+ ! ! 261 ! ! ! NCM ! !MADP ! ! ! 262 ! ! +-+-+-+ +-+-+-+ ! ! 263 ! +-+-+-+-+-+-+-+-+-+-+-+-+ ! 264 ! ! 265 ! +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! 266 ! ! ! ! ! ! 267 ! ! ! ! ! ! 268 ! !access ! !access ! ! 269 ! !(network 2)! !(network 1) ! ! 270 ! ! ! ! ! ! 271 ! +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ! 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 +-+-+-+-+-+ 275 ! +-+-+-+! 276 ! ! CCM !! 277 ! +-+-+-+! 278 !Client ! 279 +-+-+-+-+-+ 281 Figure 1: MAMS Reference Architecture 283 Figure 1 illustrates MAMS architecture for the scenario of a client 284 served by 2 networks. The NCM and MADP, functional elements, are 285 introduced for supporting MAMS mechanisms. The architecture is 286 extendable to combine more than 2 networks, as well as any choice of 287 participating network types (e.g. LTE, WLAN, MuLTEfire, DSL) and 288 deployment architectures (e.g. with user plane gateway function at 289 the access edge). 291 The MADP entity handles the user data traffic forwarding across 292 multiple network paths. MADP is the distribution node for uplink and 293 downlink data with visibility of packets at the IP layer. 294 Identification and distribution rules for different user data traffic 295 type at the MADP are configured by the NCM. The NCM configures the 296 routing in the MADP based on signaling exchanged with the CCM in the 297 client. In the UL, NCM specifies the core network path to be used by 298 MADP to route uplink user data. In the DL, NCM specifies the access 299 links to be used for delivery of data to the client. 301 The distribution algorithm at the MADP is configured by the NCM, 302 based on static and/or dynamic network policies like assigning access 303 and core paths for specific user data traffic type, data volume based 304 percentage distribution, and link availability and feedback 305 information from exchange of MAMS signaling with the CCM at the 306 Client. 308 At the client, the Client Connection Manager (CCM) manages the 309 multiple network connections. CCM is responsible for exchange of 310 MAMS signaling messages with the NCM for supporting functions like 311 configuring UL and DL user network path configuration for 312 transporting user data packets, link sounding and reporting to 313 support adaptive network path selection by NCM. In the downlink, for 314 the user data received by the client, it configures IP layer 315 forwarding for application data packet received over any of the 316 accesses to reach the appropriate application module on the client. 317 In the uplink, for the data transmitted by the client, it configures 318 the routing table to determine the best access to be used for uplink 319 data based on a combination of local policy and network policy 320 delivered by the NCM. 322 A user plane tunnel, e.g. IPsec, may be needed for transporting user 323 data packets between the MADP and the client. The user plane tunnel 324 is needed to ensure security and routability of the user plane 325 packets between the MADP and the client. The most common 326 implementation of the user plane tunnel is the IPsec. In deployments 327 where the access node belonging to the two networks are connected via 328 a secure and direct IP path, user plane tunnel may not be needed. 330 7. MAMS call flow 332 +----------------------------------------+ 333 | MAMS enabled Network of Networks | 334 | +-----+ +-----+ +-----+ +-----+| 335 +-----------------+ | | | | | | | | || 336 | | | |Netwo| |Netwo| | | | || 337 |Client +-----+ | | |rk 1 | |rk 2 | |NCM | |MADP || 338 | |CCM | | | |(LTE)| |(WiFi) | | | || 339 | +-----+ | | +-----+ +-----+ +-----+ +-----+| 340 +---+-------------+ +----------------------------------------+ 341 | | | | | | 342 | | | | | | 343 | 1.SETUP CONNECTION | | | | 344 +<-------+------------->| | | | 345 | | | | | | 346 | | 2. MAMS Capabilities Exchange | | 347 | |<-------------+----------+-------->| | 348 | | | | | | 349 | | | | | | 350 | 3. SETUP CONNECTION | | | | 351 |<-------------------------------->| | | 352 | | 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| 353 | | PROTOCOL AND PARAMETERS |MADP | 354 | |<-------------+----------+-------->|<-------->| 355 | | | | | | 356 | |5. ESTABLISH USER PLANE PATH ACCORDING TO | 357 | | SELECTED FLOW PROTOCOL | | 358 | |<-------------+----------+---------+--------->| 359 | | | | | | 360 | | | | | | 362 Figure 2: MAMS call flow 364 Figure 2 illustrates the MAMS signaling mechanism for negotiation of 365 network paths and flow protocols between the client and the network. 366 In this example scenario, the client is connected to two networks 367 (say LTE and WiFi). 369 1. UE connects to network 1 and gets an IP address assigned by 370 network 1. 371 2. CCM communicates with NCM functional element via the network 1 372 connection and exchanges capabilities and parameters for MAMS 373 operation. Note: The NCM credentials can be made known to the UE 374 by pre-provisioning. 376 3. Client sets up connection with network 2 and gets an IP address 377 assigned by network 2. 378 4. CCM and MADP negotiate capabilites and parameters with NCM for 379 establishment of network paths. 381 4a. CCM and NCM negotiate network paths, flow routing and 382 aggregation protocols, and related parameters. 384 4b. NCM communicates with the MADP to exchange and configure 385 flow aggregation and routing protocols, policies and parameters 386 in alignment with those negotiation with the CCM. 388 5. CCM and MADP establish the user plane paths, e.g. using IKE 389 [RFC7296] signaling, based on the negotiated flow protocol and 390 parameters specified by NCM. 392 CCM and NCM can further exchange messages containing access link 393 measurements for link maintenance by the NCM. NCM evaluates the link 394 conditions in the UL and DL across LTE and WiFi, based on link 395 measurements reported by CCM and/or link probing techniques and 396 determines the UL and DL user data distribution policy. NCM 397 configures MADP and CCM with these policies for controlling network 398 paths over which the user data is transported. CCM may apply local 399 policies, in addition to the network policy conveyed by the NCM. 401 8. Security Considerations 403 This section details the security considerations for the MAMS 404 framework. 406 8.1. Data and Control plane security 408 Signaling messages and the user data in MAMS framework rely on the 409 security of the underlying network transport paths. When this cannot 410 be assumed, network connection manager configures use of protocols, 411 like IPsec [RFC4301] [RFC3948], for securing user data and MAMS 412 signaling messages. 414 9. Contributors 416 This protocol is the outcome of work by many engineers, not just the 417 authors of this document. In alphabetical order, the contributors to 418 the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru 419 Calin, Jonathan Ling, Krishna Pramod A., Lohith Nayak, Michael 420 Scharf. 422 10. References 424 10.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 432 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 433 December 2005, . 435 10.2. Informative References 437 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 438 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 439 RFC 3948, DOI 10.17487/RFC3948, January 2005, 440 . 442 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 443 Kivinen, "Internet Key Exchange Protocol Version 2 444 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 445 2014, . 447 Authors' Addresses 449 Satish Kanugovi 450 Nokia 452 Email: satish.k@nokia.com 454 Subramanian Vasudevan 455 Nokia 457 Email: vasu.vasudevan@nokia.com 459 Florin Baboescu 460 Broadcom 462 Email: florin.baboescu@broadcom.com