Multiple Access Management Services
draft-kanugovi-intarea-mams-protocol-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Satish Kanugovi , Subramanian Vasudevan , Florin Baboescu , Jing Zhu , Shuping Peng , Julius Mueller | ||
| Last updated | 2017-03-09 | ||
| Replaced by | draft-kanugovi-intarea-mams-framework, RFC 8743 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kanugovi-intarea-mams-protocol-03
INTAREA S. Kanugovi
Internet-Draft S. Vasudevan
Intended status: Standards Track Nokia
Expires: September 11, 2017 F. Baboescu
Broadcom
J. Zhu
Intel
S. Peng
Huawei
J. Mueller
AT&T
March 10, 2017
Multiple Access Management Services
draft-kanugovi-intarea-mams-protocol-03
Abstract
A communication network includes an access network segment that
delivers data to/from the users and an associated core network
segment providing connectivity with the application servers.
Multiconnectivity scenarios are common where an end-user device can
simultaneously connect to multiple communication networks based on
different technology implementations and network architectures like
WiFi, LTE, DSL. A smart selection and combination of access and core
network paths that can dynamically adapt to changing network
conditions can improve quality of experience for a user in such a
Multiconnectivity scenario and improve overall network utilization
and efficiency. This document presents the problem statement and
proposes solution principles. It specifies the requirements and
reference architecture for a multi-access management services
framework that can be used to flexibly select the best combination of
access and core network paths for uplink and downlink, as well as the
flexible usage of uplink and downlink, 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 http://datatracker.ietf.org/drafts/current/.
Kanugovi, et al. Expires September 11, 2017 [Page 1]
Internet-Draft MAMS March 2017
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 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. Contributing Authors . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
6. Solution Principles . . . . . . . . . . . . . . . . . . . . . 6
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Access technology agnostic interworking . . . . . . . . . 6
7.2. Support common transport deployments . . . . . . . . . . 6
7.3. Independent Access path selection for Uplink and Downlink 6
7.4. Core selection independent of uplink and downlink access 7
7.5. Adaptive network path selection . . . . . . . . . . . . . 7
7.6. Multipath support and Aggregation of access link
capacities . . . . . . . . . . . . . . . . . . . . . . . 7
7.7. Scalable mechanism based on user plane interworking . . . 7
7.8. Separate Control and Data plane functions . . . . . . . . 8
7.9. Lossless Path (Connection) Switching . . . . . . . . . . 8
7.10. Concatenation and Fragmentation to adapt to MTU
differences . . . . . . . . . . . . . . . . . . . . . . . 8
7.11. Configuring network middleboxes based on negotiated
protocols . . . . . . . . . . . . . . . . . . . . . . . . 8
7.12. Policy based Optimal path selection . . . . . . . . . . . 8
7.13. MAMS Control signaling . . . . . . . . . . . . . . . . . 9
7.14. Service discovery and reachability . . . . . . . . . . . 9
Kanugovi, et al. Expires September 11, 2017 [Page 2]
Internet-Draft MAMS March 2017
8. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 9
9. Solution Principles . . . . . . . . . . . . . . . . . . . . . 12
10. Implementation considerations . . . . . . . . . . . . . . . . 13
11. Applicability to Mobile Edge Computing . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.1. Data and Control plane security . . . . . . . . . . . . 14
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. Contributing Authors
The editors gratefully acknowledge the following additional
Contributors in alphabetical order: Hannu Flinck/Nokia, Nurit
Sprecher/Nokia
3. 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,
which can leverage network intelligence and policies to dynamically
adapt to changing network/link conditions. The network path
selection and configuration procedures use the user plane to exchange
data between the functional elements in the network and the end-user
device without any impact to the control plane signaling schemes of
each 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. The proposed MAMS framework offers the
capabilities of smart selection and flexible combination of access
paths and core network paths. It is a broad programmable framework
providing functions beyond just sharing network policies, e.g. in
comparison to ANDSF that provides policies/rules for assisting 3GPP
devices to discover and select available access networks, that allows
choosing and configuring user plane protocols and treatment depending
on needs of the application.
The document presents the requirements, solution principles and
functional architecture for the MAMS framework. MAMS mechanisms are
Kanugovi, et al. Expires September 11, 2017 [Page 3]
Internet-Draft MAMS March 2017
not dependent on any specific network and transport protocols like
TCP, UDP, GRE, MPTCP etc. It co-exists and complements the existing
protocols by providing a way to negotiate and configure the protocols
based on client and network capabilities. 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 there is minimal or no
dependency on the actual access technologies of the participating
links, beyond the fact that the MAMS functional elements can be
placed in the user plane. This allows the scheme to be future proof,
for addition of new access technologies and for independent
technology evolution of the existing access and core networks.
4. Terminology
"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's IP address
used for communication with applications via the network.
"User Plane Gateway": The functional element that can intercept and
route user data packets.
"Network Connection manager"(NCM): A functional entity in the network
that oversees distribution of data packets over the multiple
available access and core network paths.
"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 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
Kanugovi, et al. Expires September 11, 2017 [Page 4]
Internet-Draft MAMS March 2017
network paths. C-MADP is responsible for MAMS related user-plane
functionalities in the client.
5. 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 leverages the large spectrum available in
unlicensed spectrum to deliver high capacities at low cost in
uncongested scenarios with small user population, but can show
significant degradation in application performance in congested
scenarios with large user population. Another example is LTE
network, the capacity of which is often constrained by high cost and
limited availability of the licensed spectrum, but offers predictable
service 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. For example, in
an enterprise that has deployed WiFi and LTE communications network,
enterprise applications, 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 LTE operator core anchored services including access to public
Internet.
Application performance in different scenarios, therefore becomes
dependent on the choice of the communication networks based on
different technologies (e.g. WiFi and LTE) due to the tight coupling
of the access and the core network paths. Therefore to achieve the
best possible application performance in a wide range of possible
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, in uncongested scenarios, it would be beneficial to use
WiFi access in both uplink and downlink for connecting to enterprise
applications. Whereas in congested scenarios, where use of WiFi in
uplink by multiple users can lead to degraded capacity and increased
delays due to contention, it would be beneficial to use scheduled LTE
as uplink combined with WiFi as downlink.
Kanugovi, et al. Expires September 11, 2017 [Page 5]
Internet-Draft MAMS March 2017
6. Solution Principles
This document proposes a Multiple Access Management Services(MAMS)
framework for dynamic selection and flexible combination of access
and core network paths as uplink and downlink for a device connected
to multiple communication networks. The multiple communication
networks interwork at the user plane. The selection of paths 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 (C-MADP) and the network (N-MADP).NCM has
the intelligence to setup and offer the best network path based on
device and network capabilities, application needs and knowledge of
the network state.
The NCM communicates with the Client Connection Manager (CCM), a
functional element in the device, for negotiation, sharing
information on the network path conditions, and configuring usage of
the network paths. The messages between the NCM and CCM are carried
as user plane data over any of the available network paths between
the NCM and CCM.
7. Requirements
The requirements set out in this section are for the definition of
behavior of the MAMS mechanism and the related functional elements.
7.1. Access technology agnostic interworking
The access nodes can be of different technology types like LTE, WiFi
etc. Since MAMS routes user plane data packets at the IP layer,
which makes it agnostic to the type of underlying technology used at
the access nodes.
7.2. Support common transport deployments
The network path selection and user data distribution should work
transparently across transport deployments that include e2e IPsec,
VPNs, and middleboxes like NATs and proxies.
7.3. Independent Access path selection for Uplink and Downlink
IP layer routing enables the client to transmit on uplink using one
access and receive data on downlink using another access, allowing
client and network connection manager to select the access paths for
uplink and downlink independent of each other.
Kanugovi, et al. Expires September 11, 2017 [Page 6]
Internet-Draft MAMS March 2017
7.4. Core selection independent of uplink and downlink access
A client is able to flexibly select the Core, independent of the
access paths used to reach the Core, depending on the application
needs.
7.5. Adaptive network path selection
The MAMS functional elements 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 is fed into the logic
for selection of 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.
7.6. Multipath support and Aggregation of access link capacities
MAMS supports distribution and aggregation of user data across
multiple network paths at the IP layer. MAMS allows the client 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 is done at the receiver,
client(C-MADP) and/or the network (N-MADP), when user data packets
are received out of order. MAMS allows flexibility to choose the
flow steering and aggregation protocol based on capabilities
supported by the client and the network data plane entities, C-MADP
and N-MADP respectively. A MAMS multi-connection aggregation
solution should support existing transport and network layer
protocols like TCP, UDP, GRE. If flow aggregation functions are
realized using existing protocols such as Multi-Path TCP(MPTCP) and
SCTP, MAMS framework should allow use and configuration of these
aggregation protocols.
7.7. Scalable mechanism based on user plane interworking
The mechanism is based on user plane interworking, requiring only
that the MAMS functional elements (NCM and N-MADP) should be added in
the user plane path between the client and the network. The
interworking functionality is based on generically available routing
and tunneling capabilities. This makes solution easy to deploy and
scale when different networks are added and removed.
Kanugovi, et al. Expires September 11, 2017 [Page 7]
Internet-Draft MAMS March 2017
7.8. Separate Control and Data plane functions
The client negotiates with a network connection manager on the choice
of access for both uplink and downlink, as well as the Core. The
network connection manager configures the actual user plane data
distribution function. This allows common control protocol to be
used with multiple and potentially different user plane (e.g.
tunneling) protocols, thus maintaining a clear separation between the
control and data plane functions. This makes the MAMS framework
scalable and extensible, e.g. by being amenable to SDN based
architecture and implementations.
7.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. MAMS should provide necessary mechanisms to ensure in-order
delivery at the receiver, as well as support retransmissions at the
transmitter during path switching.
7.10. Concatenation and Fragmentation to adapt to MTU differences
MAMS should support heterogeneous access networks, which may have
different MTU sizes. Moreover, tunneling protocols also have a big
impact on the MTU size. Hence, MAMS should support concatenation
such that multiple IP packets may be encapsulated into a single
packet to improve efficiency. MAMS should also support fragmentation
such that a single IP packet may be fragmented and encapsulated into
multiple ones to avoid IP fragmentation.
7.11. Configuring network middleboxes based on negotiated protocols
MAMS enables identification of the optimal parameters that may be
used for configuring the middle-boxes, like binding expiry times and
supported MTUs, for efficient operation of the user plane protocols,
depending on the data plane related 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.
7.12. Policy based Optimal path selection
MAMS framework should support consideration of policies at the
client, in addition to guidance from the network in determination of
network paths selected for different application services.
Kanugovi, et al. Expires September 11, 2017 [Page 8]
Internet-Draft MAMS March 2017
7.13. MAMS Control signaling
MAMS control signaling is carried over the user plane and is
transparent to the transport protocols. MAMS should support delivery
of control signaling over the existing Internet protocols, e.g. TCP
or UDP.
7.14. Service discovery and reachability
MAMS offers the flexibility for the functional entity NCM to be
collocated with any of the network elements and reachable via any of
the available user plane paths. MAMS framework allows the
flexibility for the CCM to choose one of the available NCMs and
exchange control plane signaling over any of the available user plane
paths. The choice of NCM can be based on considerations like, but
not limited to, quality of link through which the NCM is reachable,
Client preference, or pre-configuration etc.
8. MAMS Reference Architecture
Kanugovi, et al. Expires September 11, 2017 [Page 9]
Internet-Draft MAMS March 2017
+---------------------------------------------------+
! +---------------+ +---------------+ !
! ! ! ! ! !
! !Core(IP anchor)! !Core(IP anchor)! !
! !(network n) ! !(network 1) ! !
! ! ! ! ! !
! +---------------+ +---------------+ !
! +-----------------------+ !
! ! +-----+ +------+ ! !
! ! ! NCM ! !N-MADP| ! !
! ! +-----+ +------+ ! !
! +-----------------------+ !
! !
! +-----------+ +---------------+ !
! ! ! ! ! !
! ! ! ! ! !
! !access ! !access ! !
! !(network n)! !(network 1) ! !
! ! ! ! ! !
! +-----------+ +---------------+ !
+---------------------------------------------------+
+-----------------+
! +------+ +-----+!
! |C-MADP| ! CCM !!
! +------+ +-----+!
! Client !
+-----------------+
Figure 1: MAMS Reference Architecture
Figure 1 illustrates MAMS architecture for the scenario of a client
served by multiple (n) networks. The NCM and N-MADP, functional
elements, are introduced for supporting MAMS mechanisms. The
architecture is extendable to combine any number of networks, as well
as any choice of participating network types (e.g. LTE, WLAN,
MuLTEfire, DSL) and deployment architectures (e.g. with user plane
gateway function at the access edge).
The N-MADP entity, at the network, handles the user data traffic
forwarding across multiple network paths, as well as other user-plane
functionalities, e.g. encapsulation, fragmentation, concatenation,
reordering, retransmission, etc. N-MADP is the distribution node for
uplink and downlink data delivery with visibility of packets at the
IP layer. There can be multiple N-MADP entities in the network, e.g.
to load balance across clients. A single client can also be served
by multiple N-MADP instances, e.g to address different user plane
Kanugovi, et al. Expires September 11, 2017 [Page 10]
Internet-Draft MAMS March 2017
requirements of multiple applications running on the client.
Identification and distribution rules for different user data traffic
types at the N-MADP are configured by the NCM. The NCM configures
the data delivery paths, access links, and user plane protocols to be
used by N-MADP for downlink user data traffic. The CCM configures
the data delivery paths, access links, and user plane protocols to be
used by C-MADP for uplink user data traffic based on the signaling
exchanged with NCM. In the UL, NCM allows selection of the core
network path to be used by N-MADP to route uplink user data.
The scheduling and 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.
At the client, the Client Connection Manager (CCM) manages the
multiple network connections. CCM 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. The C-MADP entity
handles all MAMS-specific user-plane functionalities at the client,
e.g. encapsulation, fragmentation, concatenation, reordering,
retransmissions, etc. C-MADP is configured by CCM based on signaling
exchange with NCM and local policies at the client.
A user plane tunnel, e.g. IPsec, may be needed for transporting user
data packets between the N-MADP at the network and the C-MADP at the
client. The user plane tunnel is needed to ensure security and
routability of the user plane packets between the N-MADP and the
C-MADP. The most common implementation of the user plane tunnel is
the IPsec. C-MADP receives the configuration from CCM indicates, to
C-MADP, the access network interfaces over which the IPsec tunnel
needs to be established, and for each of the indicated interfaces,
the parameters (e.g. N-MADP IPsec endpoint IP address reachable via
the indicated access network interface) for setting up the IPsec
tunnel. C-MADP sets up the IPsec tunnel with the N-MADP via each of
the indicated access network interfaces, using appropriate signaling,
say IKEv2 and parameters provided by the CCM. In deployments where
N-MADP and the client are connected via a secure and direct IP path,
Kanugovi, et al. Expires September 11, 2017 [Page 11]
Internet-Draft MAMS March 2017
user plane tunnel may not be needed. Note that the method for
transporting user data packets between the N-MADP and the C-MADP
should be general, based on the existing protocols, and consider
minimizing overhead.
9. Solution Principles
+----------------------------------------+
| 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 2: MAMS call flow
Figure 2 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).
Kanugovi, et al. Expires September 11, 2017 [Page 12]
Internet-Draft MAMS March 2017
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.
10. 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.
Kanugovi, et al. Expires September 11, 2017 [Page 13]
Internet-Draft MAMS March 2017
11. Applicability to Mobile Edge Computing
Mobile edge computing (MEC) 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 and N-MADP are hosted on the MEC cloud server that is located
in the user plane path at the edge of multi-technology access
networks, and in a particular large venue use case at the edge of LTE
and Wi-Fi access networks. The NCM and CCM negotiate the network
path combinations based on application needs and the necessary user
plane protocols to manage the multiple paths. The network conditions
reported by the CCM to the NCM is used in addition to Radio Analytics
application residing at the MEC to configure the uplink and downlink
access paths according to changing radio and congestion conditions.
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.
12. Security Considerations
This section details the security considerations for the MAMS
framework.
12.1. Data and Control plane security
Signaling messages and the user data in MAMS framework rely on the
security of the underlying network transport paths. When this cannot
be assumed, network connection manager configures use of protocols,
like IPsec [RFC4301] [RFC3948], for securing user data and MAMS
signaling messages.
13. Contributors
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, Krishna Pramod A., Lohith Nayak, Michael
Scharf.
Kanugovi, et al. Expires September 11, 2017 [Page 14]
Internet-Draft MAMS March 2017
14. References
14.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>.
14.2. Informative References
[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>.
[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>.
Authors' Addresses
Satish Kanugovi
Nokia
Email: satish.k@nokia.com
Subramanian Vasudevan
Nokia
Email: vasu.vasudevan@nokia.com
Florin Baboescu
Broadcom
Email: florin.baboescu@broadcom.com
Kanugovi, et al. Expires September 11, 2017 [Page 15]
Internet-Draft MAMS March 2017
Jing Zhu
Intel
Email: jing.z.zhu@intel.com
Shuping Peng
Huawei
Email: pengshuping@huawei.com
Julius Mueller
AT&T
Email: jm169k@att.com
Kanugovi, et al. Expires September 11, 2017 [Page 16]