| INTAREA | S. Kanugovi |
| Internet-Draft | S. Vasudevan |
| Intended status: Standards Track | Nokia |
| Expires: September 14, 2017 | J. Zhu |
| Intel | |
| F. Baboescu | |
| Broadcom | |
| S. Peng | |
| Huawei | |
| March 13, 2017 |
Control Plane Protocols and Procedures for Multiple Access Management Services
draft-zhu-intarea-mams-control-protocol-00
Today, a device can be simultaneously connected to multiple communication networks based on different technology implementations and network architectures like WiFi, LTE, DSL. In such multi-connectivity scenario, it is desirable to combine multiple access networks or select the best one to improve quality of experience for a user and improve overall network utilization and efficiency. This document presents the control plane protocols, as well as describes control plane procedures for configuring the user plane in a multi access management services (MAMS) framework that can be used to flexibly select the combination of uplink and downlink access and core network paths, and user plane treatment for improving network efficiency and enhanced application quality of experience.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Multi Access Management Service (MAMS) [I-D.kanugovi-intarea-mams-protocol] is a framework to select and configure network paths when multiple connections can serve a client device. It allows the path selection and configuration to adapt to dynamic network conditions. It is based on principles of user plane interworking that enables the solution to be deployed as an overlay without impacting the underlying networks.
This document presents the control plane protocols for the MAMS framework. It co-exists and complements user plane protocols (e.g. MPTCP [RFC6824] or MPTCP Proxy [I-D.boucadair-mptcp-plain-mode], [I-D.wei-mptcp-proxy-mechanism]) by providing a way to negotiate and configure them based on client and network capabilities. It allows exchange of network state information and leverages network intelligence to optimize the performance of such protocols.
"Anchor Connection": Refers to the network path from the N-MADP to the Application Server that corresponds to a specific IP anchor that has assigned an IP address to the client.
"Delivery Connection”: Refers to the network path from the N-MADP to the client.
"Network Connection Manager" (NCM), "Client Connection Manager" (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi Access Data Proxy" (C-MADP) in this document are to be interpreted as described in [I-D.kanugovi-intarea-mams-protocol].
The MAMS architecture [I-D.kanugovi-intarea-mams-protocol] introduces the following functional elements,
+------------------------------------------+
| Multi Access (MX) Control Message |
| |
+------------------------------------------+
| HTTPS |
| |
+------------------------------------------+
| TCP/TLS |
| |
+------------------------------------------+
Figure 1: TCP-based MAMS Control Plane Protocol Stack
Figure 1 shows the default MAMS control plane protocol stack. HTTPS is used for transporting management and control messages between NCM and CCM.
+-----------------------------------------------------+
| User Payload (e.g. IP PDU) |
+-----------------------------------------------------+
+-----------------------------------------------------------+
| +-----------------------------------------------------+ |
| | Multi Access (MX) Convergence Sublayer | |
| +-----------------------------------------------------+ |
| +-----------------------------------------------------+ |
| | MX Adaptation | MX Adaptation | MX Adaptation | |
| | Sublayer | Sublayer | Sublayer | |
| | (optional) | (optional) | (optional) | |
| +----------------++--------------+-+------------------+ |
| | Access #1 IP | Access #2 IP | Access #3 IP | |
| +-----------------------------------------------------+ |
| MAMS User Plane Protocol Stack|
+-----------------------------------------------------------+
Figure 2: MAMS User Plane Protocol Stack
Figure 2 shows the MAMS user plane protocol stack.
It consists of the following two Sublayers:
CCM and NCM exchange signaling messages to configure the user plane functions, C-MADP and N-MADP, at the client and network respectively. The means for CCM to obtain the NCM credentials (FQDN or IP Address) for sending the initial discovery messages are outside of the scope of MAMS document, e.g. using methods like provisioning, DNS. Once the discovery process is successful, the (initial) NCM can update and assign additional NCM addresses for sending subsequent control plane messages.
+-----+ +-----+ | CCM | | NCM | +--+--+ +--+--+ | Discovery and | | Capability | | Exchange | <----------------------> | | | User Plane | | Protocols | | Setup | <----------------------> | Path Quality | | Estimation | <----------------------> | Network capabilities | | e.g. Radio (RNIS) | <----------------------+ | | | Network policies | <----------------------+ + +
Figure 3: MAMS Control Plane Procedures
CCM discovers and exchanges capabilities with the NCM. NCM provides the credentials of the N-MADP end-point and negotiates the parameters for user plane with the CCM. CCM configures C-MADP to setup the user plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, Associated Core Network Path), and the parameters exchanged with the NCM. The key procedures are described in details in the following sub-sections.
Each MAMS control message consists of the following common fields:
CCM NCM
| |
+------- MX Discovery Message ---------------------->|
| +-----------------+
| |Learn CCM |
| | IP address |
| |& port |
| +-----------------+
| |
|<--------------------------------MX System INFO-----|
| |
|<--------------------------------MX Capability REQ--|
|------ MX Capability RSP+-------------------------->|
| |
+ +
Figure 4: MAMS Control Procedure for Discovery & Capability Exchange
Figure 4 shows the MAMS discovery and capability exchange procedure consisting of the following key steps:
Step 1 (Discovery): CCM periodically sends out the MX Discovery Message to a pre-defined (NCM) IP Address/ port until receives an MX System INFO message in acknowledgement.
MX Discovery Message includes the following information:
MX System INFO includes the following information:
Step 2 (Capability Exchange): once receiving a MX discovery message, NCM learns the IP address and port number to communicate with CCM, and sends out the MX Capability REQ message, including the following Parameters:
In response, CCM sends out the MX Capability RSP message, including the following information:
CCM NCM | | | +-----------+----------------+ | | NCM prepares N+MADP for | | | User Plane|Setup | | +----------------------------+ |<----------------------------- MX UP Setup Config---| |-----| MX UP Setup CNF+---------------------------->| +-------------------+ | |Link "X" is up/down| | +-------------------+ | |-----|MX Reconfiguration REQ +--------------------->| |<------------------------+MX Reconfiguration RSP+---|
Figure 5: MAMS Control Procedure for User Plane Configuration
Figure 5 shows the user plane configuration procedure consisting of the following key steps:
User Plane Protocols Setup: Based on the negotiated capabilities, NCM sets up the user plane (Adaptation Layer and Convergence Layer) protocols at the N-MADP, and informs the CCM of the user plane protocols to setup at the client (C-MADP) and the parameters for C-MADP to connect to N-MADP.
Each MADP instance is responsible for one anchor connection. The MX UP Setup Config consists of the following parameters:
e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys to CCM that IPsec needs to be setup as the MX Adaptation Layer over the Wi-Fi Access, using the following parameters - IPsec end-point IP address, Pre-Shared Key., No Adaptation Layer is needed over the LTE Access as it is considered secure with no NAT. The MX Convergence Method is configured as MPTCP Proxy along with parameters for connection to the MPTCP Proxy, namely IP Address and Port of the MPTCP Proxy for TCP Applications.
Once the user plane protocols are configured, CCM informs the NCM of the status via the MX UP Setup CNF message
Reconfiguration: when the client detects that the link is up/down or the IP address changes (e.g. via APIs provided by the client OS), CCM sends out a MX Reconfiguration REQ Message to setup / release /update the connection, and the message SHOULD include the following information
If (Reconfiguration Action is setup or update), then include the following parameters
CCM NCM | | |<--------------+ MX Path Estimation Configuration+--| |-----+ MX Path Estimation Results+----------------->| | |
Figure 6: MAMS Control Plane Procedure for Path Quality Estimation
NCM sends following the configuration parameters in the MX Path Estimation Configuration message to the CCM
CCM configures the C-MADP for probe reception based on these parameters and for collection of the statistics according to the following configuration.
The user plane probing is divided into two phases - Initialization phase and Active phase.
In Initialization phase, NCM configures N-MADP to send an MX Idle Probe REQ message. CCM collects the Idle probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Initialization Probe Results configuration.
In Active phase, NCM configures N-MADP to send an MX Active Probe REQ message.. C-MADP calculates the metrics as specified by the Active Probe Results Configuration. CCM collects the Active probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Active Probe Results configuration.
CCM NCM | | | +------------------------------+ | |Steer user traffic to Path "X"| | +------------------------------+ |<------------------MX Traffic Steering (TS) REQ--| |----- MX Traffic Steering (TS) RSP ------------->|
Figure 7: MAMS Traffic Steering Procedure
NCM sends out a MX Traffic Steering (TS) REQ message to steer data traffic. It is also possible to send data traffic over multiple connections simultaneously, i.e. aggregation. The message includes the following information:
In response, CCM sends out a MX Traffic Steering (TS) RSP message, including the following information:
If NCM determines that N-MADP is to be instantiated with MPTCP as the MX Convergence Protocol, it exchanges the MPTCP capability support in discovery and capability exchange procedures. NCM then exchanges the credentials of the N-MADP instance, setup as MPTCP Proxy, along with related parameters to the CCM. CCM configures C-MADP with these parameters to connect with the N-MADP (MPTCP proxy [I-D.wei-mptcp-proxy-mechanism], [I-D.boucadair-mptcp-plain-mode]) instance, on the available network path (Access).
C-MADP N-MADP Internet (MPTCP) (MPTCP-Proxy) (TCP) | | | +---------------+ | | |Link "X" is up | | | +---------------+ | | | | | +---------------------+ | | |obtain MX Adaptation | | | |Layer (IPsec) Params | | | +---------------------+ | | |<-- IKEv2 Message Exchange--->| | +-------------------------------------------+ | | IPSec transport mode is active to protect| | | IP traffic between C-MADP and MPTCP-Proxy| | +-------------------------------------------+ | | | | +------------------+ | | |obtain MPTCP-Proxy| | | |IP address of Link| | | |"X" from CCM | | | +------------------+ | | | | | +--------------------------------|--+ | | MPTCP Signaling between | | | | C-MADP and MPTCP-Proxy | | | +--------------------------------|--+ | | +---------+ | | | inspect | | | | MPTCP | | | | signal | | | | and | | | |establish| | | |sub-flow | | | | over | | | | Link "X"| | | +--|------+ | | +------------+ | |<======Data===========>|Data Mapping|<----Data---------->| | +------|-----+ |
Figure 8: MAMS-assisted MPTCP Proxy as User Plane
Figure 8 shows the MAMS assisted MPTCP Proxy control procedure.
MAMS u-plane protocols support multiple combinations and instances of user plane protocols to be used in the MX Adaptation and the Convergence layer.
For example, one instance of the MX Convergence Layer can be MPTCP Proxy and another instance can be Trailer based. The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may be set up when network pathneeds to be secured, e.g. to protect the TCP subflow traversing the network path between the client and MPTCP proxy.
Each of the instances of MAMS user plane, i.e. combination of MX Convergence and MX Adaptation layer protocols, can coexist simultaneously and independently handle different traffic types.
For deployment scenarios, where the client is configured (e.g. by the network operator) to use a specific network for exchanging control plane messages and assume the network path to be secure, MAMS control messages will rely on security provided by the underlying transport network.
For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246] to secure control plane message exchange between the NCM and CCM.
For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available.
User data in MAMS framework relies on the security of the underlying network transport paths. When this cannot be assumed, NCM configures use of protocols, like IPsec [RFC4301] [RFC3948] in the MX Adaptation Layer, for security.
The editors gratefully acknowledge the following additional contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005. |
If the connection between CCM and NCM over which the MAMS control plane messages are transported is assumed to be secure, UDP is used as the transport for management & control messages between NCM and UCM (see Figure 9).
+-----------------------------------------------------+ | Multi-Access (MX) Control Message | |-----------------------------------------------------| | UDP | |-----------------------------------------------------|
Figure 9: UDP-based MAMS Control plane Protocol Stack