Multiple Access Management Services
draft-kanugovi-intarea-mams-framework-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8743.
|
|
|---|---|---|---|
| Authors | Satish Kanugovi , Florin Baboescu , Jing Zhu , Julius Mueller , SungHoon Seo | ||
| Last updated | 2017-12-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| IETF conflict review | conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework, conflict-review-kanugovi-intarea-mams-framework | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 8743 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kanugovi-intarea-mams-framework-00
INTAREA S. Kanugovi
Internet-Draft Nokia
Intended status: Informational F. Baboescu
Expires: July 2, 2018 Broadcom
J. Zhu
Intel
J. Mueller
AT&T
S. Seo
Korea Telecom
December 29, 2017
Multiple Access Management Services
draft-kanugovi-intarea-mams-framework-00
Abstract
In multiconnectivity scenarios the end-user devices can
simultaneously connect to multiple networks based on different access
technologies and network architectures like WiFi, LTE, DSL. Both the
quality of experience of the users and the overall network
utilization and efficiency may be improved through a smart selection
and combination of access and core network paths that can dynamically
adapt to changing network conditions. This document presents the
problem statement and proposes solution principles. It specifies the
requirements and architecture for the multi-access management
services framework that can be used to 1) flexibly select the best
combination of access and core network paths for uplink and downlink,
as well as 2) determining the user plane treatment and traffic
distribution over the selected links ensuring better network
efficiency and enhanced application performance.
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 https://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 July 2, 2018 [Page 1]
Internet-Draft MAMS December 2017
This Internet-Draft will expire on July 2, 2018.
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
(https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Access technology agnostic interworking . . . . . . . . . 6
4.2. Support common transport deployments . . . . . . . . . . 6
4.3. Independent Access path selection for Uplink and Downlink 6
4.4. Core selection independent of uplink and downlink access 6
4.5. Adaptive network path selection . . . . . . . . . . . . . 7
4.6. Multipath support and Aggregation of access link
capacities . . . . . . . . . . . . . . . . . . . . . . . 7
4.7. Scalable mechanism based on user plane interworking . . . 7
4.8. Separate Control and Data plane functions . . . . . . . . 7
4.9. Lossless Path (Connection) Switching . . . . . . . . . . 8
4.10. Concatenation and Fragmentation to adapt to MTU
differences . . . . . . . . . . . . . . . . . . . . . . . 8
4.11. Configuring network middleboxes based on negotiated
protocols . . . . . . . . . . . . . . . . . . . . . . . . 8
4.12. Policy based Optimal path selection . . . . . . . . . . . 8
4.13. Access Technology Agnostic Control signaling . . . . . . 8
4.14. Service discovery and reachability . . . . . . . . . . . 9
5. Solution Principles . . . . . . . . . . . . . . . . . . . . . 9
6. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 9
7. MAMS Protocol Architecture . . . . . . . . . . . . . . . . . 12
7.1. MAMS Control-Plane Protocol . . . . . . . . . . . . . . . 12
7.2. MAMS User Plane Protocol . . . . . . . . . . . . . . . . 13
8. MAMS Control Plane Procedures . . . . . . . . . . . . . . . . 15
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Common fields in MAMS Control Messages . . . . . . . . . 17
Kanugovi, et al. Expires July 2, 2018 [Page 2]
Internet-Draft MAMS December 2017
8.3. Common procedures for MAMS Control Messages . . . . . . . 17
8.3.1. Message Timeout . . . . . . . . . . . . . . . . . . . 17
8.3.2. Keep Alive Procedure . . . . . . . . . . . . . . . . 17
8.4. Discovery & Capability Exchange . . . . . . . . . . . . . 18
8.5. User Plane Configuration . . . . . . . . . . . . . . . . 22
8.6. MAMS Path Quality Estimation . . . . . . . . . . . . . . 26
8.7. MAMS Traffic Steering . . . . . . . . . . . . . . . . . . 27
8.8. MAMS Network ID Indication . . . . . . . . . . . . . . . 28
8.9. MAMS Client Measurement Configuration and Reporting . . . 29
8.10. MAMS Session Termination Procedure . . . . . . . . . . . 31
9. Generic MAMS Signaling Flow . . . . . . . . . . . . . . . . . 32
10. Applying MAMS Control Procedures with MPTCP Proxy as User
Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. Applying MAMS Control Procedures for Network Assisted Traffic
Steering when there is no convergence layer . . . . . . . . . 39
12. Co-existence of MX Adaptation and MX Convergence Layers . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
13.1. MAMS Control plane security . . . . . . . . . . . . . . 41
13.2. MAMS User plane security . . . . . . . . . . . . . . . . 42
14. Implementation considerations . . . . . . . . . . . . . . . . 42
15. Applicability to Multi Access Edge Computing . . . . . . . . 42
16. Contributing Authors . . . . . . . . . . . . . . . . . . . . 43
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
19.1. Normative References . . . . . . . . . . . . . . . . . . 43
19.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. MAMS Control Plane Optimization over Secure
Connections . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
Multi Access Management Services (MAMS) is a programmable framework
that provides mechanisms for flexible selection of network paths in a
multi-access communication environment, based on application needs.
It leverages network intelligence and policies to dynamically adapt
traffic distribution across selected paths and user plane treatment
to changing network/link conditions. The network path selection and
configuration messages are carried as user plane data between the
functional elements in the network and the end-user device, and thus
without any impact to the control plane signaling schemes of the
individual access network. For example, in a multi-access network
with LTE and WiFi technologies, existing LTE and existing WiFi
signaling procedures will be used to setup the LTE and WiFi
connections, respectively, and MAMS specific control plane messages
are carried as LTE or WiFi user plane data. The proposed MAMS
framework offers the capabilities of smart selection and flexible
Kanugovi, et al. Expires July 2, 2018 [Page 3]
Internet-Draft MAMS December 2017
combination of access paths and core network paths, as well as the
user plane treatment when the traffic is distributed across the
selected paths. Thus, it is a broad programmable framework providing
functions beyond just sharing network policies, e.g. ANDSF that
provides policies/rules for assisting 3GPP devices to discover and
select available access networks. Further, it allows choosing and
configuring user plane treatment for the traffic over the multiple
paths, depending on needs of the application.
The document presents the requirements, solution principles,
functional architecture, and protocols for realizing the MAMS
framework. MAMS mechanisms are not dependent on any specific access
network type or user plane protocols like TCP, UDP, GRE, MPTCP etc.
It co-exists and complements the existing protocols by providing a
way to negotiate and configure these protocols based on client and
network capabilities to match the multi-access scenario. Further it
allows exchanges of network state information and leveraging network
intelligence to optimize the performance of such protocols.
An important goal for MAMS is to ensure that it either requires
minimum dependency or (better) no dependency on the actual access
technologies of the participating links, beyond the fact that MAMS
functional elements form an IP-overlay across the multiple paths.
This allows the scheme to be future proof by allowing independent
technology evolution of the existing access and core networks as well
as, seamless integration of new access technologies.
2. Terminology
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].
"Client": The end-user device supporting connections with multiple
access nodes, possibly over different access technologies.
"Multiconnectivity Client": A client with multiple network
connections.
"Access network": The segment in the network that delivers user data
packets to the client via an access link like WiFi airlink, LTE
airlink, or DSL.
"Core": The functional element that anchors the client IP address
used for communication with applications via the network.
"Network Connection manager"(NCM): A functional entity in the network
that handles MAMS control messages from the client and configures
Kanugovi, et al. Expires July 2, 2018 [Page 4]
Internet-Draft MAMS December 2017
distribution of data packets over the multiple available access and
core network paths, and user plane treatment of the traffic flows.
"Client Connection Manager" (CCM): A functional entity in the client
that exchanges MAMS Signaling with the Network Connection Manager and
configures the multiple network paths at the client for transport of
user data.
"Network Multi Access Data Proxy" (N-MADP): This functional entity in
the network handles the user data traffic forwarding across multiple
network paths. N-MADP is responsible for MAMS related user-plane
functionalities in the network.
"Client Multi Access Data Proxy" (C-MADP): This functional entity in
the client handles the user data traffic forwarding across multiple
network paths. C-MADP is responsible for MAMS related user-plane
functionalities in the client.
"Anchor Connection": Refers to the network path from the N-MADP to
the user plane gateway (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.
3. Problem Statement
Typically, an end-user device has access to multiple communication
networks based on different technologies, say LTE, WiFi, DSL,
MuLTEfire, for accessing application services. Different
technologies exhibit benefits and limitations in different scenarios.
For example, WiFi provides high throughput for end users when under
good coverage, but the throughput degrades significantly as the user
moves closer to the edge of WiFi coverage (typically in the range of
few tens of meters) or with large user population (due to contention
based WiFi access scheme). In LTE networks, the capacity is often
constrained by the limited availability of licensed spectrum.
However, the quality of the service is predictable even in multi-user
scenarios due to controlled scheduling and licensed spectrum usage.
Additionally, the use of a particular access network path is often
coupled with the use of its associated core network and the services
that are offered by it. For example, in an enterprise that has
deployed both WiFi and LTE networks, the enterprise services, like
printers, Corporate Audio and Video conferencing, are accessible only
via WiFi access connected to the enterprise hosted (WiFi) core,
whereas the LTE access can be used to get operator core anchored
services including access to public Internet.
Kanugovi, et al. Expires July 2, 2018 [Page 5]
Internet-Draft MAMS December 2017
Thus, application performance in different scenarios becomes
dependent on the choice of the access networks (e.g. WiFi, LTE,
etc.) because of the coupling of the access and the core network
paths. Therefore, to achieve the best possible application
performance in a wide range of scenarios, a framework is needed that
allows the selection and flexible combination of access and core
network paths for uplink and downlink data delivery.
For example, to ensure best performance for enterprise applications
at all times, in uncongested scenarios, when the user is under good
WiFi coverage, it would be beneficial to use WiFi access in both
uplink and downlink for connecting to enterprise applications.
However in congested scenarios or when the user is getting close to
the edge of its WiFi coverage, the use of WiFi in uplink by multiple
users can lead to degraded capacity and increased delays due to
contention. In this case, it would be beneficial to at least use the
LTE access for increased uplink coverage while WiFi may still
continue to be used for downlink
4. Requirements
The requirements set out in this section are for the definition of
behavior of the MAMS mechanism and the related functional elements.
4.1. Access technology agnostic interworking
The access nodes may use different technology types like LTE, WiFi,
etc. The framework, however, MUST agnostic to the type of underlying
technology used at the access network.
4.2. Support common transport deployments
The network path selection and user data distribution MUST work
transparently across various transport deployments that include e2e
IPsec, VPNs, and middleboxes like NATs and proxies.
4.3. Independent Access path selection for Uplink and Downlink
Client should be able to transmit on the uplink and, receive on the
downlink, using one or more accesses. The selection of the access
paths for uplink and downlink SHOULD happen independent of each
other.
4.4. Core selection independent of uplink and downlink access
A client SHOULD flexibly select the Core, independent of the access
paths used to reach the Core, depending on the application needs,
local policies and the result of MAMS control plane negotiation.
Kanugovi, et al. Expires July 2, 2018 [Page 6]
Internet-Draft MAMS December 2017
4.5. Adaptive network path selection
The framework MUST have the ability to determine the quality of each
of the network paths, e.g. access link delay and capacity. The
network path quality information needs to be considered in the logic
for selection of the combination of network paths to be used for
transporting user data. The path selection algorithm can use network
path quality information, in addition to other considerations like
network policies, for optimizing network usage and enhancing QoE
delivered to the user.
4.6. Multipath support and Aggregation of access link capacities
The framework MUST support distribution and aggregation of user data
across multiple network paths at the IP layer. The client SHOULD be
able to leverage the combined capacity of the multiple network
connections by enabling simultaneous transport of user data over
multiple network paths. If required, packet re-ordering needs to be
done at the receiver. The framework MUST allow flexibility to choose
the flow steering and aggregation protocols based on capabilities
supported by the client and the network data plane entities. The
multi-connection aggregation solution MUST support existing transport
and network layer protocols like TCP, UDP, GRE. The framework MUST
allow use and configuration of existing aggregation protocols such as
Multi-Path TCP(MPTCP) and SCTP.
4.7. Scalable mechanism based on user plane interworking
The framework MUST leverage commonly available routing and tunneling
capabilities to provide user plane interworking functionality. The
addition of functional elements in the user plane path between the
client and the network MUST not impact the access technology specific
procedures. This makes solution easy to deploy and scale when
different networks are added and removed.
4.8. Separate Control and Data plane functions
The client MUST use the control plane protocol to negotiate with the
network, the choice of access and core network paths for both uplink
and downlink, as well as the user plane protocol treatment. The
control plane MUST configure the actual user plane data distribution
function per this negotiation. A common control protocol SHOULD
allow creation of multiple user plane function instance with
potentially different user plane (e.g. tunneling) protocol types.
This enables maintaining a clear separation between the control and
data plane functions, allowing the framework to be scalable and
extensible, e.g. using SDN based architecture and implementations.
Kanugovi, et al. Expires July 2, 2018 [Page 7]
Internet-Draft MAMS December 2017
4.9. Lossless Path (Connection) Switching
When switching data traffic from one path (connection) to another,
packets may be lost or delivered out-of-order, which will have
negative impacts on the performance of higher layer protocols, e.g.
TCP. The framework SHOULD provide necessary mechanisms to ensure in-
order delivery at the receiver, e.g. during path switching. The
framework MUST not cause any packet loss beyond that of access
network mobility functions may cause.
4.10. Concatenation and Fragmentation to adapt to MTU differences
Different network paths may have different security and middlebox
(e.g NAT) configurations, which will lead to use of different
tunneling protocols for transport of data between the network user
plane function and the client. As a result, different effective
payload sizes (e.g. due to variable encapsulation header overheads)
per network path are possible. Hence, MAMS framework SHOULD support
fragmentation of a single IP packet payload across MTU sized IP
packets to avoid IP fragmentation when aggregating packets from
different paths. Further, concatenation of multiple IP packets into
a single IP packet to improve efficiency in packing the MTU size
should also be supported.
4.11. Configuring network middleboxes based on negotiated protocols
The framework SHOULD enable identification of the optimal parameters
that may be used for configuring the middle-boxes, like radio link
dormancy timers, binding expiry times and supported MTUs, for
efficient operation of the user plane protocols, based on parameters
negotiated between the client and the network, e.g. Configuring
longer binding expiry time in NATs when UDP transport is used in
contrast to the scenario where TCP is configured at the transport
layer.
4.12. Policy based Optimal path selection
The framework MUST support consideration of policies at the client,
in addition to guidance from the network, for network path selection
addressing different application requirements.
4.13. Access Technology Agnostic Control signaling
The control plane signaling MUST NOT be dependent on the underlying
access technology procedures, e.g. be carried transparently as user
plane. It should support delivery of control plane signaling over
the existing Internet protocols, e.g. TCP or UDP.
Kanugovi, et al. Expires July 2, 2018 [Page 8]
Internet-Draft MAMS December 2017
4.14. Service discovery and reachability
There can be multiple instances of the control and user plane
functional elements of the framework, either collocated or hosted on
separate network elements, and reachable via any of the available
user plane paths. The client MUST have flexibility to choose the
appropriate control plane instance in the network and use the control
plane signaling to choose the desired user plane functional element
instances. The choice can be based on considerations like, but not
limited to, quality of link through which the network function is
reachable, client preferences, pre-configuration etc.
5. Solution Principles
This document proposes the Multiple Access Management Services(MAMS)
framework for dynamic selection and flexible combination of access
and core network paths independently for the uplink and downlink, as
well as the user plane treatment for the traffic spread across the
selected links. MAMS framework consists of clearly separated control
and user plane functions in the network and the client. The control
plane protocol allows configuration of the user plane protocols and
desired network paths for transport of application traffic. The
control plane messages are carried as user plane data over any of the
available network paths between the peer control plane functional
elements in the client and the network . The selection of paths and
user plane treatment of the traffic, is based on negotiation of
capabilities (of device and network) and network link quality between
the user plane functional elements at the end-user device/client and
the network. The framework enables leveraging network intelligence
to setup and dynamically configure the best network path combination
based on device and network capabilities, application needs and
knowledge of the network state.
6. MAMS Reference Architecture
Kanugovi, et al. Expires July 2, 2018 [Page 9]
Internet-Draft MAMS December 2017
+--------------------------------------------------------+
| +---------------+ +---------------+ |
| ! ! ! ! |
| !Core(IP anchor)! +---+ !Core(IP anchor)! |
| !network 1 ! !(network 'n' ! |
| ! ! ! ! |
| +---------------+ +---------------+ |
| \ / |
| Anchor \ +---+ Anchor |
| Connection 1 Connection 'n' |
| \ / |
| +---------------+\+---+/+------+ |
| | |-----+ +----------+ | |
| +----|NCM ! | N-MADP | | |
| | | |-----+ +----------+ | |
| | +------------------------------+ |
| | / \ |
| Control Plane Delivery +----+Delivery |
| Path (over any Connection 1 Connection 'n' |
| access user plane) / \ |
| | / \ |
| +------------------+ +---------------+ |
| | | Access | +---+ | Access | |
| | | n/w 1 | | n/w 'n' | |
| +------------------+ +---------/-----+ |
+-----------------------------\----------------/---------+
| \ /
| +---- -\------------/-+
| | +---+ \ |------+ / |
+------------+CCM | \|C-MADP|/ |
| +---+ +------+ |
| Client |
+---------------------+
Figure 1: MAMS Reference Architecture
Figure 1 illustrates MAMS architecture for the scenario of a client
served by multiple (n) networks. It introduces the following
functional elements,
o Network Connection Manager (NCM) and Client Connection Manager
(CCM) in the control plane, and
o Network Multi Access Data Proxy (N-MADP) and Client Multi Access
Data Proxy (C-MADP) handling the user plane.
NCM: It is the functional element in the network that handles the
MAMS control plane procedures. It configures the network (N-MADP)
Kanugovi, et al. Expires July 2, 2018 [Page 10]
Internet-Draft MAMS December 2017
and client (C-MADP) user plane functions like negotiating the client
on the use of available access network paths, protocols and rules for
processing the user plane traffic, as well as link monitoring
procedures. The control plane messages between the NCM and CCM are
transported as an overlay, without any impact to the underlying
access networks.
CCM: It is the peer functional element in the client for handling
MAMS control plane procedures. It manages multiple network
connections at the client. It is responsible for exchange of MAMS
signaling messages with the NCM for supporting functions like UL and
DL user network path configuration for transporting user data
packets, link probing and reporting to support adaptive network path
selection by NCM. In the downlink, for the user data received by the
client, it configures C-MADP such that application data packet
received over any of the accesses to reach the appropriate
application on the client. In the uplink, for the data transmitted
by the client, it configures the C-MADP to determine the best access
links to be used for uplink data based on a combination of local
policy and network policy delivered by the NCM.
N-MADP: It is the functional element in the network that handles the
user data traffic forwarding across multiple network paths, as well
as other user-plane functionalities like encapsulation,
fragmentation, concatenation, reordering, retransmission, etc. It is
the distribution node that routes the uplink user plane traffic to
the appropriate anchor connection towards the core network, and the
downlink user traffic to the client over the appropriate delivery
connection(s). In the downlink, the NCM configures the use of
delivery connections, and user plane protocols at the N-MADP for
transporting user data traffic. The N-MADP should implement ECMP
support for the down link traffic. Or alternatively, it may be
connected to a router with ECMP functionality. The load balancing
algorithm at the N-MADP is configured by the NCM, based on static
and/or dynamic network policies like assigning access and core paths
for specific user data traffic type, data volume based percentage
distribution, and link availability and feedback information from
exchange of MAMS signaling with the CCM at the Client.. N-MADP can be
configured with appropriate user plane protocols to support both per-
flow and per-packet traffic distribution across the delivery
connections. In the uplink, N-MADP selects the appropriate anchor
connection over which to forward the user data traffic, received from
the client (via the delivery connections). The forwarding rules in
the uplink at the N-MADP are configured by the NCM based on
application requirements, e.g. Enterprise hosted Application flows
via Wi-Fi Anchor, Mobile Operator hosted applications via the
Cellular Core.
Kanugovi, et al. Expires July 2, 2018 [Page 11]
Internet-Draft MAMS December 2017
C-MADP: It is the functional element in the client that handles the
MAMS user plane data procedures. C-MADP is configured by CCM based
on signaling exchange with NCM and local policies at the client. The
CCM configures the selection of delivery connections and the user
plane protocols to be used for uplink user data traffic based on the
signaling exchanged with NCM. The C-MADP entity handles user plane
data forwarding across multiple delivery connections and associated
user-plane functions like encapsulation, fragmentation,
concatenation, reordering, retransmissions, etc.
The NCM and N-MADP can be either collocated or instantiated on
different network nodes. NCM can setup multiple N-MADP instances in
the network. NCM controls the selection of N-MADP instance by the
client and the rules for distribution of user traffic across the
N-MADP instances., This is beneficial in multple deployment
scenarios, like the following examples.
o Different N-MADP instances to handle different sets of clients for
load balancing across clients
o Address deployment topologies e.g. N-MADP hosted at the user
plane node at the access edge or in the core network, while the
NCM hosted at the access edge node)
o Address access network technology architecture. For exanple,
N-MADP instance at core network node to manage traffic
distribution across LTE and DSL networks, and N-MADP instance at
access network node to manage traffic distribution across LTE and
Wi-Fi traffic.
o A single client can be configured to use multiple N-MADP
instances. This is beneficial in addressing different application
requirements. For example, separate N-MADP instances to handle
TCP and UDP transport based traffic.
Thus, MAMS architecture flexibly addresses multiple network
deployments.
7. MAMS Protocol Architecture
This section describes the protocol structure for the MAMS User and
Control plane functional elements.
7.1. MAMS Control-Plane Protocol
Figure 2 shows the default MAMS control plane protocol stack.
WebSocket is used for transporting management and control messages
between NCM and CCM.
Kanugovi, et al. Expires July 2, 2018 [Page 12]
Internet-Draft MAMS December 2017
+------------------------------------------+
| Multi Access (MX) Control Message |
| |
+------------------------------------------+
| WebSocket |
| |
+------------------------------------------+
| TCP/TLS |
| |
+------------------------------------------+
Figure 2: TCP-based MAMS Control Plane Protocol Stack
7.2. MAMS User Plane Protocol
Figure 3 shows the MAMS user plane protocol stack.
Kanugovi, et al. Expires July 2, 2018 [Page 13]
Internet-Draft MAMS December 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 3: MAMS User Plane Protocol Stack
It consists of the following two Sublayers:
o Multi-Access (MX) Convergence Sublayer: The MAMS framework
configures the Convergence sublayer to perform multi-access
specific tasks in the user plane. This layer performs functions
Kanugovi, et al. Expires July 2, 2018 [Page 14]
Internet-Draft MAMS December 2017
like access (path) selection, multi-link (path) aggregation,
splitting/reordering, lossless switching, fragmentation,
concatenation, etc. 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: The MAMS framework
configures the Adaptation Sublayer to address transport network
related aspects like reachability and security in the user plane.
This layer performs functions to handle tunnelling, network layer
security, and NAT. 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 securing the Wi-Fi link. Further details on the MAMS
user plane are described in [I-D.zhu-intarea-mams-user-protocol].
8. MAMS Control Plane Procedures
8.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 out of the scope of
MAMS document. As an example, the client can obtain the NCM
credentials using methods like provisioning, DNS query. 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. Further, NCM and CCM exchange link status information to adapt
traffic steering and user plane treatment with dynamic network
conditions. The key procedures are described in details in the
following sub-sections.
Kanugovi, et al. Expires July 2, 2018 [Page 15]
Internet-Draft MAMS December 2017
+-----+ +-----+
| CCM | | NCM |
+--+--+ +--+--+
| Discovery and |
| Capability |
| Exchange |
<---------------------->
| |
| User Plane |
| Protocols |
| Setup |
<---------------------->
| Path Quality |
| Estimation |
<---------------------->
| Network capabilities |
| e.g. RNIS[ETSIRNIS] |
<----------------------+
| |
| Network policies |
<----------------------+
+ +
Kanugovi, et al. Expires July 2, 2018 [Page 16]
Internet-Draft MAMS December 2017
Figure 4: MAMS Control Plane Procedures
8.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.
8.3. Common procedures for MAMS Control Messages
This section describes the common procedures for MAMS Control
Messages.
8.3.1. Message Timeout
MAMS Control plane peer (NCM or CCM) waits for a duration of
MAMS_TIMEOUT ms, after sending a MAMS control message, before timing
out when expecting a response. The sender of the message will
retransmit the message for MAMS_RETRY times before declaring failure.
A failure implies that the MAMS peer is dead, and the sender reverts
back to native non-multi access/single path mode. CCM may initiate
the MAMS discovery procedure for re-establishment of the MAMS
session.
8.3.2. Keep Alive Procedure
MAMS Control plane peers execute the keep alive procedures to ensure
that peers are reachable and to recover from dead-peer scenarios.
Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer
that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE
timer is reset whenever the peer receives a MAMS Control message.
When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is
sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver
responds with a MAMS KEEP ALIVE RSP message. If the sender does not
receive a MAMS Control message in response to MAMS_RETRY number of
retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that
the peer is dead. CCM may initiate MAMS Discovery procedure for re-
establishment of the MAMS session.
CCM shall additionally send MX KEEP ALIVE REQ message immediately to
NCM whenever it detects a handover from one base station/access point
to another. During this time the user equipment shall stop using
MAMS user plane functionality in uplink direction till it receives a
MX KEEP ALIVE RSP from NCM.
Kanugovi, et al. Expires July 2, 2018 [Page 17]
Internet-Draft MAMS December 2017
MX KEEP ALIVE REQ includes following information:
o Reason: Can be 'Timeout' or 'Handover'. Reason 'Handover' shall
be used by CCM only on detection of handover.
o Unique Session Identifier: As defined in Section 8.4.
o Connection Id: This field shall be mandatorily be included if the
reason is 'Handover'.
o Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC
address in case of WiFi). This field shall be mandatorily be
included if the reason is 'Handover'.
8.4. Discovery & Capability Exchange
Figure 5 shows the MAMS discovery and capability exchange procedure
consisting of the following key steps:
Kanugovi, et al. Expires July 2, 2018 [Page 18]
Internet-Draft MAMS December 2017
CCM NCM
| |
+------- MX Discovery Message ---------------------->|
| +-----------------+
| |Learn CCM |
| | IP address |
| |& port |
| +-----------------+
| |
|<--------------------------------MX System INFO-----|
| |
|---------------------------------MX Capability REQ->|
|<----- MX Capability RSP----------------------------|
|---------------------------------MX Capability ACK->|
| |
+ +
Figure 5: 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 MX System INFO
message is received 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:
Kanugovi, et al. Expires July 2, 2018 [Page 19]
Internet-Draft MAMS December 2017
* Connection ID: Unique identifier for the Anchor Connection
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 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): On receiving MX System Info message CCM
learns the IP Address and port to start the step 2 of the control
plane connection, and sends out the MX Capability REQ message,
including the following Parameters:
o MX Feature Activation List: Indicates if the corresponding feature
is supported or not, e.g. lossless switching, fragmentation,
concatenation, Uplink aggregation, Downlink aggregation,
Measurement, probing, 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: MulteFire; 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: MulteFire; 3:
LTE)
o MX Convergence Method Support List
* Trailer-based MX Convergence
* MPTCP Proxy
* GRE Aggregation Proxy
o MX Adaptation Method Support List
* UDP Tunnel without DTLS
* UDP Tunnel with DTLS
* IPsec Tunnel [RFC3948]
* Client NAT
In response, NCM creates a unique identity for the CCM session, and
sends out the MX Capability RSP message, including the following
information:
Kanugovi, et al. Expires July 2, 2018 [Page 20]
Internet-Draft MAMS December 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, probing, 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: MulteFire; 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
* GRE Aggregation Proxy
o MX Adaptation Method Support List
* UDP Tunnel without DTLS
* UDP Tunnel with DTLS
* IPsec Tunnel [RFC3948]
* Client NAT
Unique Session Identifier: Unique session identifier for the CCM
which has setup the connection. In case the session for the UE
already exists then the existing unique session identifier is sent
back.
o NCM Id: Unique Identity of the NCM in the operator network.
o Session Id: Unique identity assigned to the CCM instance by this
NCM instance.
In response to MX Capability RSP message, the CCM sends confirmation
(or reject) in the MX Capability ACK message. MX Capability ACK
includes the following parameters
o Unique Session Identifier: Same identifier as provided in MX
Capability RSP.
o Acknowledgement: An indication if the client has accepted or
rejected the capability phase.
Kanugovi, et al. Expires July 2, 2018 [Page 21]
Internet-Draft MAMS December 2017
* MX ACCEPT: CCM Accepts the Capability set proposed by the NCM.
* MX REJECT: CCM Rejects the Capability set proposed by the NCM.
If MX_REJECT is received by the NCM, the current MAMS session will be
terminated.
If CCM can no longer continue with the current capabilities, it
should send an MX SESSION TERMINATE message to terminate the MAMS
session. In response, the NCM should send a MX SESSION TERMINATE ACK
to confirm the termination.
8.5. User Plane Configuration
Figure 6 shows the user plane configuration procedure consisting of
the following key steps:
Kanugovi, et al. Expires July 2, 2018 [Page 22]
Internet-Draft MAMS December 2017
CCM NCM
| |
|------MX Reconfiguration REQ (setup)--------------->|
|<------------------------+MX Reconfiguration RSP+---|
| +-----------+----------------+
| | NCM prepares N+MADP for |
| | User Plane|Setup |
| +----------------------------+
|<----------------------------- MX UP Setup Config---|
|-----| MX UP Setup CNF+---------------------------->|
+-------------------+ |
|Link "X" is up/down| |
+-------------------+ |
|-----MX Reconfiguration REQ (update/release)------->|
|<------------------------+MX Reconfiguration RSP+---|
Figure 6: MAMS Control Procedure for User Plane Configuration
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
o Unique Session Identifier: Identity of the CCM identity at NCM,
created by NCM during the capability exchange phase.
Kanugovi, et al. Expires July 2, 2018 [Page 23]
Internet-Draft MAMS December 2017
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 SSID (if Connection Type = WiFi)
o MTU of the connection: MTU of the delivery path that is calculated
at the UE for use by NCM to configure fragmentation and
concatenation procedures[I-D.zhu-intarea-mams-user-protocol] at
N-MADP.
o Delivery Node Identity: Identity of the node to which the client
is attached. ECGI in case of LTE and WiFi AP Id or MAC address in
case of WiFi.
At the beginning of a connection setup, CCM informs the NCM of the
connection status using the MX Reconfiguration REQ message with
Reconfiguration Action type set to "setup". NCM acknowledges the
connection setup status and exchanges parameters with the CCM for
user plane setup, described as follows.
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 is used to create (multiple) MADP instance(s) and
consists of the following parameters:
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 NR; 2: MulteFire; 3:
LTE)
* MX Convergence Method
+ Trailer-based MX Convergence
+ MPTCP Proxy
+ GRE Aggregation Proxy
* MX Convergence Method Parameters
+ Convergence Proxy IP Address
Kanugovi, et al. Expires July 2, 2018 [Page 24]
Internet-Draft MAMS December 2017
+ 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 NR; 2: MulteFire; 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 or Client NAT
may be used over the LTE Access as it is considered secure with no
NAT.
Similarly, as an example of the MX Convergence Method configuration
is to indicate the convergence protocol 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. The MX UP Setup CNF
consists of the following parameters:
o Unique Session Identifier: Session identifier provided to the
client in MX Capability RSP.
o MX Probe Parameters (included if probing is supported):
* UDP Port Number for receiving Probes
o Client Adaptation Layer Parameters:
* Number of Delivery Connections
* For each Delivery Connection, include the following:
+ Delivery Connection ID
Kanugovi, et al. Expires July 2, 2018 [Page 25]
Internet-Draft MAMS December 2017
+ UDP port number: If UDP based adaptation is in use, the UDP
port at C-MADP side
8.6. MAMS Path Quality Estimation
Path quality estimations can be done either passively or actively.
Traffic measurements in the network could be performed passively by
comparing the real-time data throughput of the device with the
capacity available in the network. In special deployments where the
NCM has interfaces with access nodes, direct interfaces can be used
to gather path quality information. For example, the utilization of
a cell/eNB attached to a device could be used as an indicator for
path quality estimations without creating an extra traffic overhead.
Active measurements by the device are an alternative for estimating
path quality.
CCM NCM
| |
|<--------------+ MX Path Estimation Configuration+--|
|-----+ MX Path Estimation Results+----------------->|
| |
Figure 7: 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 Test Duration (ms)
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.
Kanugovi, et al. Expires July 2, 2018 [Page 26]
Internet-Draft MAMS December 2017
o Unique Session Identifier: Session identifier provided to the
client in MX Capability RSP.
o Init Probe Results Configuration
* Lost Probes (%)
* Probe Receiving Rate (packets per second)
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.
8.7. MAMS Traffic Steering
CCM NCM
| |
| +------------------------------+
| |Steer user traffic to Path "X"|
| +------------------------------+
|<------------------MX Traffic Steering (TS) REQ--|
|----- MX Traffic Steering (TS) RSP ------------->|
Figure 8: 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
Kanugovi, et al. Expires July 2, 2018 [Page 27]
Internet-Draft MAMS December 2017
connections simultaneously, i.e. aggregation. The message includes
the following information:
o Connection ID of the Anchor Connection
o Connection ID List of Delivery Connections for DL traffic
o For the number of Specific UL traffic Templates, include the
following
* Traffic Template for identifying the UL traffic
* Connection ID List of Delivery connections for UL traffic
identified by the traffic template
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, probing
In response, CCM sends out a MX Traffic Steering (TS) RSP message,
including the following information:
o Unique Session Identifier: Session identifier provided to the
client in MX Capability RSP.
o MX Feature Activation List: each parameter indicates if the
corresponding feature is enabled or not: lossless switching,
fragmentation, concatenation, Uplink aggregation, Downlink
aggregation, probing
8.8. MAMS Network ID Indication
CCM NCM
| |
| +---------------------------------+
| |NCM determines preferred Networks|
| +---------------------------------+
|<------------------MX SSID Indication------------|
Figure 9: MAMS Network ID Indication Procedure
NCM indicates the preferred network list to the CCM to guide client
on networks that it should connect to. To indicate preferred Wi-Fi
Networks, the NCM sends the list of WLAN networks, represented by
SSID/BSSID/HESSID, available in the MX SSID Indication.
Kanugovi, et al. Expires July 2, 2018 [Page 28]
Internet-Draft MAMS December 2017
8.9. MAMS Client Measurement Configuration and Reporting
CCM NCM
| |
|<------------------MX MEAS CONFIG----------------|
| |
+---------------------------------+ |
|Client Ready to send measurements| |
+---------------------------------+ |
| |
|----- MX MEAS REPORT---------------------------->|
Figure 10: MAMS Client Measurement Configuration and Reporting
Procedure
NCM configures the CCM with the different parameters (e.g. radio link
information), with the associated thresholds to be reported by the
client. The MX MEAS CONFIG message contains the following
parameters. For each Delivery Connection, include the following:
o Delivery Connection ID
o Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE)
o If Connection Type is Wi-Fi
* WLAN_RSSI_THRESH: High and Low Thresholds for sending Average
RSSI of the Wi-Fi Link.
* WLAN_RSSI_PERIOD: Periodicity in ms for sending Average RSSI of
the Wi-Fi Link.
* WLAN_LOAD_THRESH: High and Low Thresholds for sending Loading
of the WLAN system.
* WLAN_LOAD_PERIOD: Periodicity in ms for sending Loading of the
WLAN system.
* UL_TPUT_THRESH: High and Low Thresholds for sending Reverse
Link Throughput on the Wi-Fi link.
* UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link
Throughput on the Wi-Fi link.
* DL_TPUT_THRESH: High and Low Thresholds for sending Forward
Link Throughput on the Wi-Fi link.
* DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link
Throughput on the Wi-Fi link.
* EST_UL_TPUT_THRESH: High and Low Thresholds for sending Reverse
Link Throughput (EstimatedThroughputOutbound as defined in
[IEEE]) on the Wi-Fi link.
Kanugovi, et al. Expires July 2, 2018 [Page 29]
Internet-Draft MAMS December 2017
* EST_UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link
Throughput (EstimatedThroughputOutbound as defined in [IEEE])
on the Wi-Fi link.
* EST_DL_TPUT_THRESH: High and Low Thresholds for sending Forward
Link Throughput (EstimatedThroughputInbound as defined in
[IEEE]) on the Wi-Fi link.
* EST_DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link
Throughput (EstimatedThroughputInbound as defined in [IEEE]) on
the Wi-Fi link.
o If Connection Type is LTE
* LTE_RSRP_THRESH: High and Low Thresholds for sending RSRP of
Serving LTE link.
* LTE_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving
LTE link.
* LTE_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of
the serving LTE link.
* LTE_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving
LTE link.
* UL_TPUT_THRESH: High and Low Thresholds for sending Reverse
Link Throughput on the serving LTE link.
* UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link
Throughput on the serving LTE link.
* DL_TPUT_THRESH: High and Low Thresholds for sending Forward
Link Throughput on the serving LTE link.
* DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link
Throughput on the serving LTE link.
The MX MEAS REPORT message contains the following parameters
o Unique Session Identifier: Session identifier provided to the
client in MX Capability RSP.
o For each Delivery Connection, include the following:
* Delivery Connection ID
* Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3:
LTE)
* Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or
MAC address in case of WiFi)
* If Connection Type is Wi-Fi
+ WLAN_RSSI: Average RSSI of the Wi-Fi Link.
+ WLAN_LOAD: Loading of the WLAN system.
+ UL_TPUT: Reverse Link Throughput on the Wi-Fi link.
+ DL_TPUT: Forward Link Throughput on the Wi-Fi link.
+ EST_UL_TPUT: Estimated Reverse Link Throughput on the Wi-Fi
link (EstimatedThroughputOutbound as defined in [IEEE]).
Kanugovi, et al. Expires July 2, 2018 [Page 30]
Internet-Draft MAMS December 2017
+ EST_DL_TPUT: Estimated Forward Link Throughput on the Wi-Fi
link (EstimatedThroughputInbound as defined in [IEEE]).
* If Connection Type is LTE
+ LTE_RSRP: RSRP of Serving LTE link.
+ LTE_RSRQ: RSRQ of the serving LTE link.
+ UL_TPUT: Reverse Link Throughput on the serving LTE link.
+ DL_TPUT: Forward Link Throughput on the serving LTE link.
8.10. MAMS Session Termination Procedure
CCM NCM
| |
|+----MX Session Terminate--------->|
| |
| |
|<---MX Session Terminate Ack-------|
| +---------------+
| Remove Resources
| +---------------+
| |
Figure 11: MAMS Session Termination Procedure - Client Initiated
CCM NCM
| |
|<----------MX Session Terminate--------|
| |
| |
| |
+--------MX Session Terminate Ack------->
| |
| |
+-----------+-----------+ |
| Remove Resources | |
+-----------+-----------+ |
| |
Figure 12: MAMS Session Termination Procedure - Network Initiated
At any point in MAMS functioning if CCM or NCM is unable to support
the MAMS functions anymore, then either of them can initiate a
termination procedure by sending MX Session Terminate to the peer,
Kanugovi, et al. Expires July 2, 2018 [Page 31]
Internet-Draft MAMS December 2017
the peer shall acknowledge the termination by sending MX Session
Terminate ACK message. After the session is disconnected the CCM
shall start a new procedure with MX Discover Message. MX Session
Terminate message shall contain Unique Session Identifier and reason
for termination in Request. Possible reasons for termination can be:
o Normal Release
o No Response from Peer
o Internal Error
9. Generic MAMS Signaling Flow
+----------------------------------------+
| MAMS enabled Network of Networks |
| +-----+ +-----+ +-----+ +------+
+-----------------+ | | | | | | | | ||
| Client | | |Netwo| |Netwo| | | | ||
| +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP||
| C-MADP |CCM | | | |(LTE)| |(WiFi) | | | ||
| +-----+ +-----+ | | +-----+ +-----+ +-----+ +------|
-+----------------+ +----------------------------------------+
| | | | | | |
| | | | | | |
| | 1.SETUP CONNECTION| | | |
|<-----------+------------>| | | |
| | | + + | |
| | | 2. MAMS Capabilities Exchange | |
| | |<-------------+----------+-------->| |
| | | | | | |
| | + | | | |
| | 3. SETUP CONNECTION | | |
|<--+-------------------------------->| | |
| 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config|
| C-MADP | PROTOCOL AND PARAMETERS | |N-MADP |
| |<----->|<-------------+----------+-------->|<-------->|
| | | + + | |
| | |5. ESTABLISH USER PLANE PATH ACCORDING TO |
| | | SELECTED FLOW PROTOCOL | | |
| |<---------------------+----------+------------------->|
| | | | | | |
+ + + + + + +
Figure 13: MAMS call flow
Kanugovi, et al. Expires July 2, 2018 [Page 32]
Internet-Draft MAMS December 2017
Figure 13 illustrates the MAMS signaling mechanism for negotiation of
network paths and flow protocols between the client and the network.
In this example scenario, the client is connected to two networks
(say LTE and WiFi).
1. UE connects to network 1 and gets an IP address assigned by
network 1.
2. CCM communicates with NCM functional element via the network 1
connection and exchanges capabilities and parameters for MAMS
operation. Note: The NCM credentials (e.g. NCM IP Address) can
be made known to the UE by pre-provisioning.
3. Client sets up connection with network 2 and gets an IP address
assigned by network 2.
4. CCM and NCM negotiate capabilities and parameters for
establishment of network paths, which are then used to configure
user plane functions N-MADP at the network and C-MADP at the
client.
4a. CCM and NCM negotiate network paths, flow routing and
aggregation protocols, and related parameters.
4b. NCM communicates with the N-MADP to exchange and configure
flow aggregation protocols, policies and parameters in alignment
with those negotiated with the CCM.
4c. CCM communicates with the C-MADP to exchange and configure
flow aggregation protocols, policies and parameters in alignment
with those negotiated with the NCM.
5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE
[RFC7296] signaling, based on the negotiated flow aggregation
protocols and parameters specified by NCM.
CCM and NCM can further exchange messages containing access link
measurements for link maintenance by the NCM. NCM evaluates the link
conditions in the UL and DL across LTE and WiFi, based on link
measurements reported by CCM and/or link probing techniques and
determines the UL and DL user data distribution policy. NCM and CCM
also negotiate application level policies for categorizing
applications, e.g. based on DSCP, Destination IP address, and
determining which of the available network paths, needs to be used
for transporting data of that category of applications. NCM
configures N-MADP, and CCM configures C-MADP, based on the negotiated
application policies. CCM may apply local application policies, in
addition to the application policy conveyed by the NCM.
Kanugovi, et al. Expires July 2, 2018 [Page 33]
Internet-Draft MAMS December 2017
10. 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 (e.g.
[I-D.wei-mptcp-proxy-mechanism], [I-D.boucadair-mptcp-plain-mode])
instance, on the available network path (Access).
Figure 14 shows the call flow describing MAMS control procedures
applied to configure user plane and dynamic optimal path selection in
a scenario with MPTCP Proxy as the convergence protocol in the user
plane.
Kanugovi, et al. Expires July 2, 2018 [Page 34]
Internet-Draft MAMS December 2017
+------+ +---------+ +---------+ +---------+ +---------+ +------+
| | | | | | | | | | | |
|CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP|
+------+ +---------+ +---------+ +---------+ +---------+ +------+
+------------------------------------------------------------------------+
| 1. LTE Session Setup and IP Add. Allocation |
-------------------------------------------+-------------+-------------+-+
|2. MAMS Discovery Message (MAMS Version) | | |
+-----------------------------------------+-------------> |
| 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | |
<-------------+-------------+-------------+-------------+ |
| | | | | |
|4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) |
+-----------------------------------------------------+-> |
|5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)| |
<-----------------------------------------+-------------+ |
| 6. MX CAPABILITY ACK(ACCEPT) | | |
+-------------+-------------+---------------------------> |
| | | | | |
|7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) |
<-------------------------------------------------------+ |
|8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | |
+-----------------------------------------+-------------> |
|9. MAMS SSID IND(List of SSIDs) | | |
<-------------+-------------+---------------------------+ |
| | | | | |
|10. MX RECONFIGURATION REQ (LTE IP) | | |
+-------------------------------------------------------> |
|11. MX RECONFONFIGURATION RSP | | |
<-----------------------------------------+-------------+ |
|12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | |
<---------------------------+-------------+-------------+ |
|13. MX UP SETUP RSP | | | |
+-------------+-------------+-------------+-------------> +
| | 14. MPTCP Connection with designated MPTCP Proxy over LTE
| +-------------+-------------+-------------+------------->
| | | | | |
+ + + + + +
Figure 14: MAMS-assisted MPTCP Proxy as User Plane - Initial Setup
with LTE leg
Following are the salient steps described in the call flow. The
client connects to the LTE network and obtains an IP address (assume
LTE is the first connection), and initiates the NCM discovery
procedures and exchange capabilities, including the support for MPTCP
as the convergence protocol at both the network and the client.
Kanugovi, et al. Expires July 2, 2018 [Page 35]
Internet-Draft MAMS December 2017
The CCM informs the LTE connection parameters to the NCM. NCM
provides the parameters like MPTCP Proxy IP address/Port for
configuring the convergence layer. 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 and port among multiple
access networks. Since LTE is the only connection, the user plane
traffic flows over the single TCP subflow over the LTE connection.
Optionally, NCM can provide assistance to the device on the
neighboring/preferred Wi-Fi networks that it can associate with.
Kanugovi, et al. Expires July 2, 2018 [Page 36]
Internet-Draft MAMS December 2017
+------+ +---------+ +---------+ +---------+ +---------+ +------+
| | | | | | | | | | | |
|CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP|
+------+ +---------+ +---------+ +---------+ +---------+ +------+
+------------------------------------------------------------------------+
| Traffic over LTE in UL and DL over MPTCP Connection |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Wi-Fi Connection Establishment and IP Address Allocation |
+---------------------------------------------------------------------+--+
|15. MX RECONFIGURATION REQ (Wi-Fi IP) | | |
+-------------------------------------------------------> |
|16. MX RECONFONFIGURATION RSP | | |
<-----------------------------------------+-------------+ |
|17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | |
<---------------------------+-------------+-------------+ |
|18. MX UP SETUP RSP | | | |
+-------------+-------------+-------------+-------------> |
| | 19. IPsec Tunnel Establishment over WLAN path |
| <-----------------------------------------|------------->
| 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+
+-------------+-------------+-------------+------------->+Wait for |
| | | | |+good reports |
| | | | |+-------------+
| 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+
<-----------------------------------------+-------------+ |Allow Use of|
| 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link |
+-------------+-------------+---------------------------> +-----------++
| | | | | |
| Add TCP subflow to the MPTCP connection over the WiFi link
| |<----------------------------------------------------->|
+-----------------------------------------------------------------------+
|| Aggregated Wi-Fi and LTE capacity for UL and DL ||
+-----------------------------------------------------------------------+
| |
| |
Figure 15: MAMS-assisted MPTCP Proxy as User Plane - Add Wi-Fi leg
Figure 15 describes the steps, when the client establishes a Wi-Fi
connection. CCM informs the NCM of the Wi-Fi connection along with
parameters like the Wi-Fi IP address, SSID. NCM determines that the
Wi-Fi connection needs to be secured and configures the Adaptation
Layer to be IPsec and provides the required parameters to the CCM.
In addition, NCM provides the information to configure the
convergence layer, (e.g. MPTCP Proxy IP Address), and provides the
Traffic Steering Request to indicate that client should use only the
Kanugovi, et al. Expires July 2, 2018 [Page 37]
Internet-Draft MAMS December 2017
LTE access. NCM may do this, for example, on determination from the
measurements that the Wi-Fi link is not consistently good enough. As
the Wi-Fi link conditions improve, NCM sends a Traffic Steering
Request to use Wi-Fi access as well. This triggers the client to
establish the TCP subflow over the Wi-Fi link with the MPTCP proxy
+------+ +---------+ +---------+ +---------+ +---------+ +------+
| | | | | | | | | | | |
|CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP|
+------+ +---------+ +---------+ +---------+ +---------+ +------+
+------------------------------------------------------------------------+
| Traffic over LTE and Wi Fi in UL And DL over MPTCP |
+-------------+-------------+-------------+-------------+------------+---+
| | | | | |
| 23. MX MEAS REPORT (WLAN RSSI, LTE RSRP ,UL/DL TPUT) |+-----------+---+
+-------------+-------------+-------------+------------>|| Reports of bad|
| | | | |+ Wi-Fi UL tput|
| + + + ++---------------+
| 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+
|<-----------------------------------------+------------+ |Disallow use|
| 25. MX TRAFFIC STEERING RSP (...) | | |of Wi-Fi UL |
|-------------+-------------+-------------------------->| +----------+--+
| | | | | |
++-------------+-------------+-------------+-------------+------------+-+
| UL data to use TCP subflow over LTE link only, |
| Aggregated Wi-Fi+LTE capacity for DL |
++-------------+-------------+-------------+-------------+-------------++
| | | | | |
+ + + + + +
Figure 16: MAMS-assisted MPTCP Proxy as User Plane - Wi-Fi UL
degrades
Figure 16 describes the steps, when the client reports that Wi-Fi
link conditions degrade in UL. MAMS control plane is used to
continuously monitor the access link conditions on Wi-Fi and LTE
connections. The NCM may at some point determine increase in UL
traffic on Wi-Fi, and trigger the client to only LTE in the UL via
Traffic Steering Request to improve UL performance.
Kanugovi, et al. Expires July 2, 2018 [Page 38]
Internet-Draft MAMS December 2017
+------+ +---------+ +---------+ +---------+ +---------+ +------+
| | | | | | | | | | | |
|CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP|
+------+ +---------+ +---------+ +---------+ +---------+ +------+
+-----------------------------------------------------------------------+
| UL data to use TCP subflow over LTE link only, |
| Aggregated Wi+Fi+LTE capacity for DL |
++-------------+-------------+-------------+-------------+------------+-+
| | | | | |
| + + + | |
| 23. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) +------------+---+
+-------------+-------------+-------------+------------>|| Reports of bad+
| | | | || Wi+Fi UL/DL tput
| + + + +----------------+
| 24. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+
+<----------------------------------------+-------------+ |Disallow use|
| 25. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi |
+-----------------------------------------+------------>+ +-------------+
| |Delete TCP subflow from MPTCP conn. over Wi-Fi link |
| +<---------------------------------------------------->|
+-----------------------------------------------------------------------+
|| Traffic over LTE link only for DL and UL | | |
|| (until Client reports better Wi-Fi link conditions) | | |
+-----------------------------------------------------------------------+
| | | | | |
+ + + + + +
Figure 17: MAMS-assisted MPTCP Proxy as User Plane - Part 4
Figure 17 describes the steps, when the client reports that Wi-Fi
link conditions degrade in both UL and DL. As the Wi-Fi link
conditions deteriorate further, the NCM may determine to send Traffic
Steering Request guiding the client to stop using Wi-Fi, and to use
only LTE access in both UL and DL. This condition may be maintained
until NCM determines, based on reported measurements that Wi-Fi link
has become usable.
11. Applying MAMS Control Procedures for Network Assisted Traffic
Steering when there is no convergence layer
Figure 18 shows the call flow describing MAMS control procedures
applied for dynamic optimal path selection in a scenario convergence
and Adaptation layer protocols are not omitted. This scenario
indicates the applicability of a MAMS Control Plane only solution.
In the capability exchange messages, NCM and CCM negotiate that
Convergence and Adaptation layer protocols are not needed (or
Kanugovi, et al. Expires July 2, 2018 [Page 39]
Internet-Draft MAMS December 2017
supported). CCM informs the NCM of the availability of the LTE and
Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be
used dynamically based on the reported link quality measurements.
+------+ +---------+ +---------+ +---------+ +---------+ +------+
| | | | | | | | | | | |
|CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP|
+------+ +---------+ +---------+ +---------+ +---------+ +------+
+------------------------------------------------------------------------+
| 1. LTE Session Setup and IP Add. Allocation |
+------------------------------------------+-------------+-------------+-+
|2. MAMS Discovery Message (MAMS Version) | | |
+-----------------------------------------+------------>| |
| 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | |
<-------------+-------------+-------------+-------------+ |
| + + + + |
|4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) |
+------------------------------------------------------>| |
|5. MX CAPABILITY RSP(No Convergence/Adpatation parameters) |
|<-----------------------------------------+------------+ |
| 6. MX CAPABILITY ACK(ACCEPT) | | |
+-------------+-------------+-------------------------->| |
| + + + + |
|7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) |
|<------------------------------------------------------| |
|8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | |
|-----------------------------------------+------------>| |
|9. MAMS SSID IND(List of SSIDs) | | |
|<------------------------------------------------------| |
+-----------------------------------------------------------------------++
| 10. Wi|Fi connection setup and IP Address allocation |
+-+-------------+-------------+-------------+-------------+-------------++
| + + | | |
|10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | |
+-----------------------------------------+------------>| |
|11. MX RECONFONFIGURATION RSP | | |
<------------------------------------------------------+| |
+-----------------------------------------------------------------------++
| Initial Condition, Data over LTE link only, WLAN link is poor |
+---------------------------------------------------------+-------------++
|12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+
|------------------------------------------------------>||Wi-Fi Link |
| | | | ||conditions |
| | | | ||reported good|
| | | | |+-------------+
| | | | | |
|13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+
Kanugovi, et al. Expires July 2, 2018 [Page 40]
Internet-Draft MAMS December 2017
|<-------------+-------------+-------------+------------||Steer traffic |
|14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi |
|<-------------+-------------+-------------+------------||link |
| | | | |+--------------+
+-----------------------------------------------------------------------++
| Use Wi-Fi link for Data |
+---------------------------------------------------------+-------------++
| | | | | |
+ + + + + +
Figure 18: MAMS With No Convergence Layer
12. Co-existence of MX Adaptation and MX Convergence Layers
MAMS user plane supports multiple instances and combinations of
protocols to be used at 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 path needs 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.
13. Security Considerations
13.1. MAMS Control plane security
The NCM functional element is hosted on a network node which is
assumed to be within a secure network, e.g. within the operator's
network, and is assumed to be protected against hijack attacks.
For deployment scenarios, where the client is configured (e.g. by the
network operator) to use a specific network path for exchanging
control plane messages and if the network path is assumed to be
secure, MAMS control messages will rely on security provided by the
underlying network.
For deployment scenarios where the security of the network path
cannot be assumed, NCM and CCM implementations MUST support the "wss"
URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to
secure control plane message exchange between the NCM and CCM.
Kanugovi, et al. Expires July 2, 2018 [Page 41]
Internet-Draft MAMS December 2017
For deployment scenarios where client authentication is desired, the
WebSocket server can use any client authentication mechanisms
available to a generic HTTP server, such as cookies, HTTP
authentication, or TLS authentication.
13.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.
14. Implementation considerations
MAMS builds on commonly available functions available on terminal
devices that can be delivered as a software update over the popular
end-user device operating systems, enabling rapid deployment and
addressing the large deployed device base.
15. Applicability to Multi Access Edge Computing
Multi Access Edge Computing (MEC), earlier known as Mobile edge
computing, is an access-edge cloud platform being standardized at
ETSI, whose initial focus was to improve quality of experience by
leveraging intelligence at cellular (e.g. 3GPP technologies like LTE)
access edge, and the scope is now being extended to support access
technologies beyond 3GPP. This applicability of the framework
described in this document to the MEC platform has been evaluated and
tested in different network configurations.
The NCM is hosted on the MEC cloud server that is located in the user
plane path at the edge of multi-technology access networks. The NCM
and CCM negotiate the network path combinations based on application
needs and the necessary user plane protocols to be used across the
multiple paths. The network conditions reported by the CCM to the
NCM is complemented by Radio Analytics application[ETSIRNIS] residing
at the MEC to configure the uplink and downlink access paths
according to changing radio and congestion conditions.
The user plane functional element, N-MADP, can either be collocated
with the NCM at the MEC cloud server (e.g. MEC hosted applications),
or placed at a separate network element like a common user plane
gateway across the multiple networks.
Also, even in scenarios where N-MADP is not deployed, NCM can be used
to augment the traffic steering decisions at the device.
Kanugovi, et al. Expires July 2, 2018 [Page 42]
Internet-Draft MAMS December 2017
The aim of these enhancements is to improve the end-user's quality of
experience by leveraging the best network path based on application
needs and network conditions, and building on the advantages of
significantly reduced latency and the dynamic and real-time exposure
of radio network information available at the MEC.
16. 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, Shuping
Peng/Huawei, Vasudevan Subramanian/Nokia. Vasudevan Subramanian has
been instrumental in conceptualization and development of solution
principles for the MAMS framework. Shuping Peng has been a key
contributor in refining the framework and control plane protocol
aspects.
17. Acknowledgments
This protocol is the outcome of work by many engineers, not just the
authors of this document. In alphabetical order, the contributors to
the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru
Calin, Jonathan Ling, Lohith Nayak, Michael Scharf.
18. IANA Considerations
This draft makes no requests of IANA
19. References
19.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,
<https://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, <https://www.rfc-editor.org/info/rfc4301>.
19.2. Informative References
[ETSIRNIS]
"Mobile Edge Computing (MEC) Radio Network Information
API", <ETSI GS MEC 012>.
Kanugovi, et al. Expires July 2, 2018 [Page 43]
Internet-Draft MAMS December 2017
[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.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., Seo, S., Kanugovi, S., and S. Peng, "User-Plane
Protocols for Multiple Access Management Service", draft-
zhu-intarea-mams-user-protocol-03 (work in progress),
August 2017.
[IEEE] "IEEE Standard for Information technology:
Telecommunications and information exchange between
systems Local and metropolitan area networks:Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.", <IEEE
802.11-2016>.
[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,
<https://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, <https://www.rfc-editor.org/info/rfc6347>.
[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,
<https://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, <https://www.rfc-editor.org/info/rfc7296>.
Kanugovi, et al. Expires July 2, 2018 [Page 44]
Internet-Draft MAMS December 2017
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 19).
+-----------------------------------------------------+
| Multi-Access (MX) Control Message |
|-----------------------------------------------------|
| UDP |
|-----------------------------------------------------|
Figure 19: UDP-based MAMS Control plane Protocol Stack
Authors' Addresses
Satish Kanugovi
Nokia
Email: satish.k@nokia.com
Florin Baboescu
Broadcom
Email: florin.baboescu@broadcom.com
Jing Zhu
Intel
Email: jing.z.zhu@intel.com
Julius Mueller
AT&T
Email: jm169k@att.com
SungHoon Seo
Korea Telecom
Email: sh.seo@kt.com
Kanugovi, et al. Expires July 2, 2018 [Page 45]