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]