Internet DRAFT - draft-wei-dmm-anchorless-mm
draft-wei-dmm-anchorless-mm
INTERNET-DRAFT X.Wei Ed.
Intended Status: Proposed Standard F.Yang
Expires: December 3, 2017 Huawei Technologies
June 1, 2017
Anchorless Mobility Management
draft-wei-dmm-anchorless-mm-01
Abstract
This memo discusses anchor-less mobility management based on
ID/Locator split scheme, especially for VM handoff scenario in MEC
network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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
J.Wei Expires December 3, 2017 [Page 1]
INTERNET DRAFT <Document Title> June 1, 2017
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
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Mobility Management Gap Analysis . . . . . . . . . . . . . . . 4
3 Mobility Solution Based on ID/Locater Split . . . . . . . . . . 5
4 Relations with Existing DMM Solutions . . . . . . . . . . . . . 9
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 10
Contributors: . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
J.Wei Expires December 3, 2017 [Page 2]
INTERNET DRAFT <Document Title> June 1, 2017
1 Introduction
With the development of network technology, there are more and more
services sensitive to network latency, for example, interactive VR,
tactile Internet, remote control, automatic drive etc. Also low
latency has become an important requirement in 5G network design. For
service with low latency requirements, the network needs to meet its
end-to-end latency requirements.
The MEC (Multi-access Edge Computing) sinks computing and storage
capacity to the edge of the network. The MEC server is deployed at
the edge of the network and applications could be deployed in the MEC
server. This allows the MN to access the required services in close
proximity without having to traverse through the core network,
thereby reducing the end-to-end RTT, and satisfying latency
requirements. Usually, MN and MEC server are under the same operator
network. One of the basic MEC deployment scenarios is shown in Figure
1:
+--+ +---+ +---+ +----------+
|MN|-----------|UP1| |UP3|-----|MEC Server|
+--+ +---+ +---+ +----------+
+---+ +---+ +----------+
|UP2| |UP4|-----|MEC Server|
+---+ +---+ +----------+
UP: User Plane function
Figure 1: MEC Deployment Architecture
In order to meet the low latency requirements of network services, an
alternative approach is to deploy services with low latency
requirements in the MEC system. The MEC architecture is an effective
means of addressing low latency requirements by deploying the
application in an MEC server close to the terminal equipment.
Application instance runs in a MEC server, and the service connection
is established between application runs on MN and application
instance runs on MEC server. When the MN moves in the MEC server's
coverage area, in order to ensure continuity of the service, the
connectivity between MN application and mobile edge application needs
to be maintained. As MN moves further away from the location of the
mobile edge application, there could be an increased latency between
the MN and the mobile edge application. Due to this reason or others
(e.g. network congestion), for some mobile edge applications, it
might become necessary to migrate the application instance, i.e.
J.Wei Expires December 3, 2017 [Page 3]
INTERNET DRAFT <Document Title> June 1, 2017
migrating the application instance to a new MEC server near to MN's
current location, in order to satisfy the latency requirements, when
the application instance is migrated the service continuity need to
be maintained [GS_MEC003].
For instance, when the MN runs interactive VR (Virtual Reality)
service, in order to guarantee the high bandwidth and low latency
requirement of the VR's service, the MEC server is used to provide
service for the MN, that is, the MEC server starts a VM (Virtual
Machine) running the VR service for MN, when the MN moves far away
from the original MEC server, if the nearest MEC server is available,
the VM will be migrated to the new MEC server, and ensuring
continuity of VR service. The case where the VM migration follows
MN's mobility is also referred as VM handoff [Ha2015].
This memo analyzes the above mentioned MEC mobility scenario in which
the application instance migrates following MN's movement, and a
mobility management solution based on the ID/Locator split scheme is
discussed.
1.1 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 RFC 2119 [RFC2119].
2 Mobility Management Gap Analysis
In the DMM, the on-demand mobility scheme [ODMM] is proposed, in
which the network provides IP session continuity and IP address
reachability based on application requirements. If the application
requires both session continuity and IP address reachability, the
application chooses to use a fixed IP address; if the application
needs IP session continuity but does not need IP address
reachability, then the application will use Session-lasting IP
Address; if the application neither need IP session continuity nor IP
address reachability, then non-persistent IP Address will be used.
On-demand mobility scheme separate applications need IP session
continuity from applications don't need IP session continuity , and
then the network provides applications with different types of
session continuity support based on this separation: for a
application that does not require session continuity support, session
continuity is not provided, and a new IP address is allowed to be
used when the MN moves, in this way the routing redundancy problem
could be avoided; for an application that needs session continuity
support from the network, the network side sustains the IP address
used by the MN during the movement of the MN, so that the IP address
J.Wei Expires December 3, 2017 [Page 4]
INTERNET DRAFT <Document Title> June 1, 2017
used by the application is not changed, however, this approach
provides session continuity while also introduces routing redundancy
for application traffic. The on-demand approach does not address the
mobility requirements in the VM handoff scenario described earlier.
The fundamental cause for the route redundancy is the dual attributes
of the IP address: the network location attribute and the session
identification attribute. The two communication sides use IP
addresses to identify the session, so in order to maintain session
continuity the IP addresses need keep the same, but because IP
address also determines network location, when the IP address keeps
the same the service traffic flows back to the IP address's IP
anchor, which leads to routing redundancy problem.
3 Mobility Solution Based on ID/Locater Split
ID/Locator separation scheme separate ID attribute from Locator
attribute in one IP address, it can be a good choice to solve the
routing redundancy problem caused by mobility.
In this memo, an architecture of network-based mobility management
solution based on the concept of ID/Locator split is discussed which
is also align with DMM working group's existing CP-UP separation
architecture.
When a host is connected to the network, the network assigns a host
ID (or ID for abbreviation) to the host, which uniquely identifies
the host in the network. The ID is independent of the network
location where the host located in, the host can be found by its ID
regardless of where the host locates in the network. During
communication, the communication peers identify the session based on
the ID. The location independence of the ID ensures that the ID does
not change when the host moves in the network, thus ensuring that the
sessions on both sides of the communication are not interrupted due
to changes in the host network location.
In addition to the host ID, the host will also have a locator
information to identify the location of the network to which it
belongs. The locator information is bound to the network location.
When the host's network location changes, the host locator changes so
that host locator can correctly identify the host's current network
located. The packets transmitted between the two parties are routed
based on the locator through the network. Figure 2 illustrates an
overview of the mobility solution architecture.
J.Wei Expires December 3, 2017 [Page 5]
INTERNET DRAFT <Document Title> June 1, 2017
+-------------+
|Control Plane|
+-|-|---|----|+
| | | |
| | | | _MEC server
+--+ | | | ,'' `-.
| | | | /'
+--+ +-|-+ | | +|--+ .' +---+ |
|MN|-----------|UP1| | | |UP3|---------|VM1| |
+--+ +---+ | | +---+ +---+ /
| LOC1 | | LOC3 `. | ,'
| +----+ +----+ ` |--'
V | | V__
+--+ +-|-+ +|--+ ,'' `-.
|MN|-----------|UP2| |UP4|---------+---+
+--+ +---+ +---+ .' |VM1| |
LOC2 LOC4 | +---+ |
/
`. ,'
``---'
MEC server
Figure2: Mobile Management Architecture Based on ID/Locator Separation
UP1 to UP4 are user plane functions. They are responsible for the
management of Locator, packet encapsulation and decapsulation, packet
forwarding, signaling interaction with Control Plane (for example,
ID/Locator relationship update).
The Control Plane is responsible for maintaining the mapping of
ID/Locator and configuring the ID/Locator mapping to the
corresponding UP to control UP's processing of the packet.
The MN and VM instance use ID-based communication with each other. MN
and VM instance obtains its corresponding host ID from the network
respectively. Both IDs are carried in packets. At the same time, the
network assigns a locator to each party of the communication. The
locator can be shared by multiple hosts located under the same UP, or
each host can be assigned a seperate locator. The ID carried in
packets will be mapped to locator for packet routing, the network
routes and forwards packets based on locator.
In order not to modify the existing mobile terminal, an alternative
is to use the IP address as the host ID, except that the IP address
referred to here is only in the same form as the IP address but is
not bound to the network location and is not used for packet routing,
the two sides of communication in the scheme use the 5-tuple (src ID,
dest ID, src port, dest port, protocol No.) to identify the session.
J.Wei Expires December 3, 2017 [Page 6]
INTERNET DRAFT <Document Title> June 1, 2017
It is assumed that the ID used by the MN and CN in the communication
are ID-mn and ID-cn respectively. UP1 to UP4 is responsible for
allocating locator for MN and CN. An illustration of host side
protocol stack is shown in figure 3.
+---------------+ +---------------+
| |------------| |
| Application | | Application |
+---------------+ +---------------+
| | | |
| Transport |------------| Transport |
+---------------+ +---------------+
| | | |
| ID Layer |------------| ID Layer |
+---------------+ +---------------+
| | | |
| Link Layer |------------| Link Layer |
+---------------+ +---------------+
Figure 3: Host Protocol Stack
When the MN is located at UP1, a communication connection is
established between MN and MN's correspondent node VM1, at which time
the VM1 accesses UP3. The packet between MN and the VM1 is
transmitted through the tunnel established between UP1 and UP3, where
the outer header of the tunnel uses the locator assigned by UP1 and
UP3.
+-------------+
|Control Plane|
+-|----------|+
| |
| | _MEC server
+--+ | ,'' `-.
ID-mn | | /' ID-vm
+--+ +-|-+ +|--+ .' +--+ |
|MN|-----------|UP1|##########|UP3|---------|VM1| |
+--+ +---+ +---+ +--+ /
LOC1 LOC3 `. ,'
` ---'
Figure4: Communication Connection before Movement Occurs
When the MN moves to UP2, MN's ID will be remain unchanged, and the
MN's locator changed to LOC2. The communication between the MN and
the VM adopts the make-before-break mode. The MN communicates with
the VM instance located at the UP3 position until the VM instance
completely migrates to the UP4 position. During this period, packets
J.Wei Expires December 3, 2017 [Page 7]
INTERNET DRAFT <Document Title> June 1, 2017
are transmitted through tunnels between UP2 and UP3. The outer header
of the tunnel uses the locators assigned by UP2 and UP3.
+-------------+
|Control Plane|
+-|-|--------|+
| | |
| | | _MEC server
+--+ | | ,'' `-.
ID-mn | | | /' ID-vm
+--+ +-|-+ | +|--+ .' +--+ |
|MN|-----------|UP1| | ####|UP3|---------|VM1| |
+--+ +---+ | # +---+ +--+ /
| LOC1 | # LOC3 `. ,'
| +----+ # ` ---'
V | #
+--+ +-|-+ #
|MN|-----------|UP2|#######
+--+ +---+
ID-mn LOC2
Figure5: Communication Connection during Movement
When the VM instance has been migrated to UP4 position, the ID for VM
remains unchanged. The MN will communicate with the VM instance at
the UP4 position. That is, the communication path will be switched
from between UP2 and UP3 to UP2 and UP4. In this case, it is
necessary to set up a temporary path between UP3 and UP4 and forward
previous in-transit packets from UP3 to UP4, the temporary path will
be released after all the packets has been forwarded to UP4.
J.Wei Expires December 3, 2017 [Page 8]
INTERNET DRAFT <Document Title> June 1, 2017
+-------------+
|Control Plane|
+-|-|---|----|+
| | | |
| | | |
+--+ | | |
| | | |
+-|-+ | | +|--+
|UP1| | | |UP3|
+---+ | | +--$+
LOC1 | | LOC3 $
+----+ +----+ $
ID-mn | | $ V__
+--+ +-|-+ +|-$+ ,'' `-.
|MN|-----------|UP2|##########|UP4|---------+--+
+--+ +---+ +---+ .' |VM1| |
LOC2 LOC4 | +--+ |
ID-vm /
`. ,'
``---'
MEC server
Figure6: Communication Connection after Movement
In the ID-based communication, the ID does not change during the move
of the host, thus ensuring the continuity of the session, and because
the packet always routes using the locator that identifies the
current location of the host, the routing path is optimized providing
a guarantee for achieving low latency.
NOTE: The interaction signaling between Control Plane and User Plane
is TBD.
4 Relations with Existing DMM Solutions
TBD.
5 Security Considerations
TBD.
6 IANA Considerations
TBD.
J.Wei Expires December 3, 2017 [Page 9]
INTERNET DRAFT <Document Title> June 1, 2017
7 References
7.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003, <http://www.rfc-
editor.org/info/rfc3514>.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009, <http://www.rfc-
editor.org/info/rfc5513>.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009, <http://www.rfc-editor.org/info/rfc5514>.
[GS_MEC003] Mobile Edge Computing (MEC); Framework and Reference
Architecture, Mar 2016.
[Ha2015] Kiryong Ha., "Adaptive VM Handoff Across Cloudlets", June
2015.
[ODMM] Alper Yegin., "draft-ietf-dmm-ondemand-mobility-10 ", January
29, 2017.
Contributors:
I would like to acknowledge the contribution of the following people
to the document:
Rui Meng, mengrui@huawei.com
Cheng Chen, chencheng@huawei.com
Authors' Addresses
Xinpeng(Jackie) Wei
Huanbaoyuan Q22, Haidian District, Beijing, China
J.Wei Expires December 3, 2017 [Page 10]
INTERNET DRAFT <Document Title> June 1, 2017
EMail: weixinpeng@huawei.com
Fei Yang
Huanbaoyuan Q22, Haidian District, Beijing, China
yangfei15@huawei.com
J.Wei Expires December 3, 2017 [Page 11]
