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 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 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 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 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 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 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 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 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 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, . 7.2 Informative References [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003, . [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009, . [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009, . [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 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]