INTAREA S. Kanugovi
Internet-Draft S. Vasudevan
Intended status: Standards Track Nokia
Expires: September 28, 2017 J. Zhu
Intel
F. Baboescu
Broadcom
S. Peng
Huawei
S. Seo
Korea Telecom
March 27, 2017
Control Plane Protocols and Procedures for Multiple Access Management
Services
draft-zhu-intarea-mams-control-protocol-01
Abstract
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.
Status of This Memo
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."
Kanugovi, et al. Expires September 28, 2017 [Page 1]
Internet-Draft MAMS C-plane March 2017
This Internet-Draft will expire on September 28, 2017.
Copyright Notice
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.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. MAMS Control-Plane Protocol . . . . . . . . . . . . . . . . . 3
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MAMS User Plane Protocol . . . . . . . . . . . . . . . . . . 4
6. MAMS Control Plane Procedures . . . . . . . . . . . . . . . . 6
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Common fields in MAMS Control Messages . . . . . . . . . 7
6.3. Discovery & Capability Exchange . . . . . . . . . . . . . 7
6.4. User Plane Configuration . . . . . . . . . . . . . . . . 10
6.5. MAMS Path Quality Estimation . . . . . . . . . . . . . . 12
6.6. MAMS Traffic Steering . . . . . . . . . . . . . . . . . . 13
7. Applying MAMS Control Procedures with MPTCP Proxy as User
Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Co-existence of MX Adaptation and MX Convergence Layers . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. MAMS Control plane security . . . . . . . . . . . . . . . 16
9.2. MAMS User plane security . . . . . . . . . . . . . . . . 16
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. MAMS Control Plane Optimization over Secure
Connections . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Kanugovi, et al. Expires September 28, 2017 [Page 2]
Internet-Draft MAMS C-plane March 2017
1. Conventions used in this document
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].
2. Introduction
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.
3. Terminology
"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].
4. MAMS Control-Plane Protocol
4.1. Overview
The MAMS architecture [I-D.kanugovi-intarea-mams-protocol] introduces
the following functional elements,
o Network Connection Manager (NCM) and Client Connection Manager
(CCM) in the control plane, and
Kanugovi, et al. Expires September 28, 2017 [Page 3]
Internet-Draft MAMS C-plane March 2017
o Network Multi Access Data Proxy (N-MADP) and Client Multi Access
Data Proxy (C-MADP) handling the user plane.
Figure 1 shows the default MAMS control plane protocol stack. HTTPS
is used for transporting management and control messages between NCM
and CCM.
+------------------------------------------+
| Multi Access (MX) Control Message |
| |
+------------------------------------------+
| HTTPS |
| |
+------------------------------------------+
| TCP/TLS |
| |
+------------------------------------------+
Figure 1: TCP-based MAMS Control Plane Protocol Stack
5. MAMS User Plane Protocol
Figure 2 shows the MAMS user plane protocol stack.
Kanugovi, et al. Expires September 28, 2017 [Page 4]
Internet-Draft MAMS C-plane March 2017
+-----------------------------------------------------+
| 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
It consists of the following two Sublayers:
o Multi-Access (MX) Convergence Sublayer: This layer performs multi-
access specific tasks, e.g. access (path) selection, multi-link
(path) aggregation, splitting/reordering, lossless switching,
fragmentation, concatenation, etc. For example, MX Convergence
layer can be implemented using existing user plane protocols like
MPTCP or by adapting encapsulating header/trailer schemes (e.g
Trailer Based MX Convergence as specified in
[I-D.zhu-intarea-mams-user-protocol]).
o Multi-Access (MX) Adaptation Sublayer: This layer performs
functions to handle tunnelling, network layer security, and NAT.
For example, MX Adaptation can be implemented using IPsec, DTLS or
Client NAT (Source NAT at Client with inverse mapping at N-MADP
[I-D.zhu-intarea-mams-user-protocol] ). The MX Adaptation Layer
is optional and can be independently configured for each of the
Access Links, e.g. in a deployment with LTE (assumed secure) and
Wi-Fi (assumed not secure), the MX Adaptation Sublayer can be
omitted for the LTE link but MX Adaptation Sublayer is configured
as IPsec for the Wi-Fi link.
Kanugovi, et al. Expires September 28, 2017 [Page 5]
Internet-Draft MAMS C-plane March 2017
6. MAMS Control Plane Procedures
6.1. Overview
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 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.
Kanugovi, et al. Expires September 28, 2017 [Page 6]
Internet-Draft MAMS C-plane March 2017
+-----+ +-----+
| 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
6.2. Common fields in MAMS Control Messages
Each MAMS control message consists of the following common fields:
o Version: indicates the version of MAMS control protocol.
o Message Type: indicates the type of the message, e.g. MX
Discovery, MX Capability REQ/RSP etc.
o Sequence Number: auto-incremented integer to uniquely identify a
transaction of message exchange, e.g. MX Capability REQ/RSP.
6.3. Discovery & Capability Exchange
Figure 4 shows the MAMS discovery and capability exchange procedure
consisting of the following key steps:
Kanugovi, et al. Expires September 28, 2017 [Page 7]
Internet-Draft MAMS C-plane March 2017
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
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:
o MAMS Version
MX System INFO includes the following information:
o Number of Anchor Connections
For each Anchor Connection, it includes the following parameters:
* Connection ID: Unique identifier for the Anchor Connection
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3:
LTE)
* NCM Endpoint Address (For Control Plane Messages over this
connection)
+ IP Address or FQDN (Fully Qualified Domain Name)
+ Port Number
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:
Kanugovi, et al. Expires September 28, 2017 [Page 8]
Internet-Draft MAMS C-plane March 2017
o MX Feature Activation List: Indicates if the corresponding feature
is enabled or not, e.g. lossless switching, fragmentation,
concatenation, Uplink aggregation, Downlink aggregation,
Measurement, etc.
o Number of Anchor Connections (Core Networks)
For each Anchor Connection, it includes the following parameters:
* Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3:
LTE)
o Number of Delivery Connections (Access Links)
For each Delivery Connection, it includes the following
parameters:
* Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3:
LTE)
o MX Convergence Method Support List
* Trailer-based MX Convergence;
* MPTCP Proxy;
o MX Adaptation Method Support List
* UDP Tunnel without DTLS;
* UDP Tunnel with DTLS;
* IPsec Tunnel[RFC3948];
* Client NAT;
In response, CCM sends out the MX Capability RSP message, including
the following information:
o MX Feature Activation List: Indicates if the corresponding feature
is enabled or not, e.g. lossless switching, fragmentation,
concatenation, Uplink aggregation, Downlink aggregation,
Measurement, etc.
o Number of Anchor Connections (Core Networks)
For each Anchor Connection, it includes the following parameters:
* Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3:
LTE)
o Number of Delivery Connections (Access Links)
For each Delivery Connection, it includes the following
parameters:
Kanugovi, et al. Expires September 28, 2017 [Page 9]
Internet-Draft MAMS C-plane March 2017
* Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3:
LTE)
o MX Convergence Method Support List
* Trailer-based MX Convergence;
* MPTCP Proxy;
o MX Adaptation Method Support List
* UDP Tunnel without DTLS;
* UDP Tunnel with DTLS;
* IPsec Tunnel[RFC3948];
* Client NAT;
6.4. User Plane Configuration
Figure 5 shows the user plane configuration procedure consisting of
the following key steps:
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
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:
Kanugovi, et al. Expires September 28, 2017 [Page 10]
Internet-Draft MAMS C-plane March 2017
o Number of Anchor Connections (Core Networks)
For Each Anchor Connection, it includes the following parameters
* Anchor Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NGC; 2: Multi-Fire; 3:
LTE)
* MX Convergence Method
+ Trailer-based MX Convergence;
+ MPTCP Proxy;
* MX Convergence Method Parameters
+ Convergence Proxy IP Address
+ Convergence Proxy Port
* Number of Delivery Connections
For each Delivery Connection, include the following:
+ Delivery Connection ID
+ Connection Type (e.g., 0: Wi-Fi; 1: 5G NGC; 2: Multi-Fire;
3: LTE)
+ MX Adaptation Method
- UDP Tunnel without DTLS;
- UDP Tunnel with DTLS;
- IPSec Tunnel;
- Client NAT;
+ MX Adaptation Method Parameters
- Tunnel Endpoint IP Address
- Tunnel Endpoint Port
- Shared Secret
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
Kanugovi, et al. Expires September 28, 2017 [Page 11]
Internet-Draft MAMS C-plane March 2017
sends out a MX Reconfiguration REQ Message to setup / release /update
the connection, and the message SHOULD include the following
information
o Reconfiguration Action: indicate the reconfiguration action (0:
release; 1: setup; 2: update)
o Connection ID: identify the connection for reconfiguration
If (Reconfiguration Action is setup or update), then include the
following parameters
o IP address of the connection
o MTU (Maximum Transmission Unit) size of the connection
6.5. MAMS Path Quality Estimation
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
o Connection ID (of Delivery Connection whose path quality needs to
be estimated)
o Init Probe Test Duration (ms)
o Init Probe Test Rate (Mbps)
o Init Probe Size (Bytes)
o Init Probe Ack Required (0 -> No/1 -> Yes)
o Active Probe Frequency (ms)
o Active Probe Size (Bytes)
o Active Probe Ack Required (0 -> No/1 -> Yes)
CCM configures the C-MADP for probe reception based on these
parameters and for collection of the statistics according to the
following configuration.
o Init Probe Results Configuration
Kanugovi, et al. Expires September 28, 2017 [Page 12]
Internet-Draft MAMS C-plane March 2017
* Lost Probes (%)
* Probe Delay
* Probe Rate
o Active Probe Results Configuration
* Average Throughput in the last Probe Duration
The user plane probing is divided into two phases - Initialization
phase and Active phase.
o Initialization phase: A network path that is not included by
N-MADP for transmission of user data is deemed to be in the
Initialization phase. The user data may be transmitted over other
available network paths.
o Active phase: A network path that is included by N-MADP for
transmission of user data is deemed to be in 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.
6.6. MAMS Traffic Steering
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:
o Connection ID of the Anchor Connection
Kanugovi, et al. Expires September 28, 2017 [Page 13]
Internet-Draft MAMS C-plane March 2017
o Connection ID List of Delivery Connections for DL traffic
o Connection ID List of Delivery connections for UL traffic
o MX Feature Activation List: each parameter indicates if the
corresponding feature is enabled or not: lossless switching,
fragmentation, concatenation, Uplink aggregation, Downlink
aggregation, Measurement
In response, CCM sends out a MX Traffic Steering (TS) RSP message,
including the following information:
o MX Feature Activation List: each parameter indicates if the
corresponding feature is enabled or not: lossless switching,
fragmentation, concatenation, Uplink aggregation, Downlink
aggregation
7. Applying MAMS Control Procedures with MPTCP Proxy as User Plane
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).
Figure 8 shows the MAMS assisted MPTCP Proxy control procedure.
o For securing the TCP subflow data over links that cannot be
assumed to be secure, NCM configures MX Adaptation Layer. E.g.
NCM can inform CCM to use IPsec as the MX Adaptation Layer over
the link "X" (e.g. Wi-Fi). CCM informs C-MADP to set up IPSec
(transport mode) with N-MADP using the MPTCP-Proxy IP address to
protect the TCP subflow over Link "X".
o NCM informs the CCM that N-MADP is configured as the MPTCP proxy
and provides the parameters like MPTCP Proxy IP address/Port.
C-MADP obtains the IP address & port of MPTCP-Proxy for Link "X"
locally from CCM. This is useful if N-MADP is reachable via
different IP address or/and port, from different access networks.
The current MPTCP signaling can't identify or differentiate the
MPTCP proxy IP address & port among multiple access networks.
Kanugovi, et al. Expires September 28, 2017 [Page 14]
Internet-Draft MAMS C-plane March 2017
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
Kanugovi, et al. Expires September 28, 2017 [Page 15]
Internet-Draft MAMS C-plane March 2017
8. Co-existence of MX Adaptation and MX Convergence Layers
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.
9. Security Considerations
9.1. MAMS Control plane security
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.
9.2. MAMS User plane security
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.
10. Contributing Authors
The editors gratefully acknowledge the following additional
contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu
Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia
Kanugovi, et al. Expires September 28, 2017 [Page 16]
Internet-Draft MAMS C-plane March 2017
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
11.2. Informative References
[I-D.boucadair-mptcp-plain-mode]
Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,
D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,
Contreras, L., and B. Peirens, "Extensions for Network-
Assisted MPTCP Deployment Models", draft-boucadair-mptcp-
plain-mode-10 (work in progress), March 2017.
[I-D.kanugovi-intarea-mams-protocol]
Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng,
S., and J. Mueller, "Multiple Access Management Services",
draft-kanugovi-intarea-mams-protocol-03 (work in
progress), March 2017.
[I-D.wei-mptcp-proxy-mechanism]
Wei, X., Xiong, C., and E. Ed, "MPTCP proxy mechanisms",
draft-wei-mptcp-proxy-mechanism-02 (work in progress),
June 2015.
[I-D.zhu-intarea-mams-user-protocol]
Zhu, J., "User-Plane Protocols for Multiple Access
Management Service", draft-zhu-intarea-mams-user-
protocol-00 (work in progress), March 2017.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005,
<http://www.rfc-editor.org/info/rfc3948>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
Kanugovi, et al. Expires September 28, 2017 [Page 17]
Internet-Draft MAMS C-plane March 2017
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
Appendix A. MAMS Control Plane Optimization over Secure Connections
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
Authors' Addresses
Satish Kanugovi
Nokia
Email: satish.k@nokia.com
Subramanian Vasudevan
Nokia
Email: vasu.vasudevan@nokia.com
Jing Zhu
Intel
Email: jing.z.zhu@intel.com
Kanugovi, et al. Expires September 28, 2017 [Page 18]
Internet-Draft MAMS C-plane March 2017
Florin Baboescu
Broadcom
Email: florin.baboescu@broadcom.com
Shuping Peng
Huawei
Email: pengshuping@huawei.com
SungHoon Seo
Korea Telecom
Email: sh.seo@kt.com
Kanugovi, et al. Expires September 28, 2017 [Page 19]