idnits 2.17.1 draft-wei-dmm-anchorless-mm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2017) is 2597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 136, but not defined == Unused Reference: 'KEYWORDS' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 339, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J.Wei Ed. 3 Intended Status: Proposed Standard F.Yang 4 Expires: September 11, 2017 Huawei Technologies 5 March 10, 2017 7 Anchor-less Mobility Management Solution 8 draft-wei-dmm-anchorless-mm-00 10 Abstract 12 This memo discusses an anchor-less mobility management solution based 13 on ID/Locator split scheme, especially for VM handoff scenario in MEC 14 network. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2 Mobility Management Gap Analysis . . . . . . . . . . . . . . . 4 57 3 Mobility Solution Based on ID/Locater Split . . . . . . . . . . 5 58 4 Relations with Existing DMM Solutions . . . . . . . . . . . . . 8 59 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 60 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 61 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 63 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 64 Contributors: . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1 Introduction 69 With the development of network technology, there are more and more 70 services sensitive to network latency, for example, interactive VR, 71 tactile Internet, remote control, automatic drive etc. Also low 72 latency has become an important requirement in 5G network design. For 73 service with low latency requirements, the network needs to meet its 74 end-to-end latency requirements. 76 The MEC (Multi-access Edge Computing) sinks computing and storage 77 capacity to the edge of the network. The MEC server is deployed at 78 the edge of the network and applications could be deployed in the MEC 79 server. This allows the MN to access the required services in close 80 proximity without having to traverse through the core network, 81 thereby reducing the end-to-end RTT, and satisfying latency 82 requirements. One of the basic MEC deployment scenarios is shown in 83 Figure 1: 85 +--+ +---+ +---+ +----------+ 86 |MN|-----------|UP1| |UP3|-----|MEC Server| 87 +--+ +---+ +---+ +----------+ 89 +---+ +---+ +----------+ 90 |UP2| |UP4|-----|MEC Server| 91 +---+ +---+ +----------+ 93 Figure 1: MEC Deployment Architecture 95 In order to meet the low latency requirements of network services, an 96 alternative approach is to deploy services with low latency 97 requirements in the MEC system. The MEC architecture is an effective 98 means of addressing low latency requirements by deploying the 99 application in an MEC server close to the terminal equipment. 101 Application instance runs in a MEC server, and the service connection 102 is established between application runs on MN and application 103 instance runs on MEC server. When the MN moves in the MEC server's 104 coverage area, in order to ensure continuity of the service, the 105 connectivity between MN application and mobile edge application needs 106 to be maintained. As MN moves further away from the location of the 107 mobile edge application, there could be an increased latency between 108 the MN and the mobile edge application. Due to this reason or others 109 (e.g. network congestion), for some mobile edge applications, it 110 might become necessary to relocate the application instance, i.e. 111 relocating the application instance to a new MEC server near to MN's 112 current location, in order to satisfy the latency requirements, when 113 the application instance is relocated the service continuity need to 114 be maintained. [GS_MEC003] 116 For instance, when the MN runs interactive VR (Virtual Reality) 117 service, in order to guarantee the high bandwidth and low latency 118 requirement of the VR's service, the MEC server is used to provide 119 service for the MN, that is, the MEC server starts a VM (Virtual 120 Machine) running the VR service for MN, when the MN moves far away 121 from the original MEC server, if the nearest MEC server is available, 122 the VM will be migrated to the new MEC server, and ensuring 123 continuity of VR service. The case where the VM relocation follows 124 MN's mobility is also referred as VM handoff [Ha2015]. 126 This memo analyzes the mobility scenario of the correspondent node 127 following the MN to avoid the redundancy of the route redundancy, and 128 a mobility management solution based on the ID/Locator split scheme 129 is provided. 131 1.1 Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2 Mobility Management Gap Analysis 139 In the DMM, the on-demand mobility scheme [ODMM] is proposed, in 140 which the network provides IP session continuity and IP address 141 reachability based on application requirements. If the application 142 requires both session continuity and IP address reachability, the 143 application chooses to use a fixed IP address; if the application 144 needs IP session continuity but does not need IP address 145 reachability, then the application will use Session-lasting IP 146 Address; if the application neither need IP session continuity nor IP 147 address reachability, then non-persistent IP Address will be used. 149 On-demand mobility scheme separate applications need IP session 150 continuity from applications don't need IP session continuity , and 151 then the network provides applications with different types of 152 session continuity support based on this separation: for a 153 application that does not require session continuity support, session 154 continuity is not provided, and a new IP address is allowed to be 155 used when the MN moves, in this way the routing redundancy problem 156 could be avoided; for an application that needs session continuity 157 support from the network, the network side sustains the IP address 158 used by the MN during the movement of the MN, so that the IP address 159 used by the application is not changed, however, this approach 160 provides session continuity while also introduces routing redundancy 161 for application traffic. The on-demand approach does not address the 162 mobility requirements in the VM handoff scenario described earlier. 164 The fundamental cause for the route redundancy is the dual attributes 165 of the IP address: the network location attribute and the session 166 identification attribute. The two communication sides use IP 167 addresses to identify the session, so in order to maintain session 168 continuity the IP addresses need keep the same, but because IP 169 address also determines network location, when the IP address keeps 170 the same the service traffic flows back to the IP address's IP 171 anchor, which leads to routing redundancy problem. 173 3 Mobility Solution Based on ID/Locater Split 175 ID/Locator separation scheme separate ID attribute from Locator 176 attribute in one IP address, it can be a good choice to solve the 177 routing redundancy problem caused by mobility. 179 In this memo, the architecture of network-based mobility management 180 solution based on the concept of ID/Locator split is discussed which 181 is also align with DMM working group's existing CP-UP separation 182 architecture. Figure 2 illustrates an overview of the mobility 183 solution architecture. 185 +-------------+ 186 |Control Plane| 187 +-|-|---|----|+ 188 | | | | 189 | | | | _MEC server 190 +--+ | | | ,'' `-. 191 | | | | /' 192 +--+ +-|-+ | | +|--+ .' +--+ | 193 |MN|-----------|UP1| | | |UP3|---------|VM| | 194 +--+ +---+ | | +---+ +--+ / 195 | LOC1 | | LOC3 `. | ,' 196 | +----+ +----+ ` |--' 197 V | | V__ 198 +--+ +-|-+ +|--+ ,'' `-. 199 |MN|-----------|UP2| |UP4|---------+--+ 200 +--+ +---+ +---+ .' |VM| | 201 LOC2 LOC4 | +--+ | 202 / 203 `. ,' 204 ``---' 205 MEC server 207 Figure2: Mobile Management Architecture Based on ID/Locator Separation 209 UP1 to UP4 are data plane functions. They are responsible for the 210 management of Locator, packet encapsulation and decapsulation, packet 211 forwarding, signaling interaction with Control Plane (for example, 212 ID/Locator relationship update). 214 The Control Plane is responsible for maintaining the mapping of 215 ID/Locator and configuring the ID/Locator to the corresponding UP to 216 control UP's processing of the packet. 218 In order not to modify the existing mobile terminal, the two sides of 219 communication in the scheme still use the 5-tuple to identify the 220 session. It is assumed that the IP addresses used by the MN and CN in 221 the communication are IP-mn and IP-cn respectively. During 222 communication, IP-mn and IP-cn only act as IDs, which are used to 223 identify sessions, but are not used as locators. UP1 to UP4 is 224 responsible for allocating Locator for MN and CN. 226 When the MN is located at UP1, a communication connection is 227 established with MN's correspondent node VM , at which time the VM 228 accesses UP3. The packet between MN and the VM is transmitted through 229 the tunnel established between UP1 and UP3, where the outer header of 230 the tunnel uses the locator assigned by UP1 and UP3. 232 +-------------+ 233 |Control Plane| 234 +-|----------|+ 235 | | 236 | | _MEC server 237 +--+ | ,'' `-. 238 IP-mn | | /' IP-vm 239 +--+ +-|-+ +|--+ .' +--+ | 240 |MN|-----------|UP1|##########|UP3|---------|VM| | 241 +--+ +---+ +---+ +--+ / 242 LOC1 LOC3 `. ,' 243 ` ---' 245 Figure3: Communication Connection before Movement Occurs 247 When the MN moves to UP2, the communication between the MN and the VM 248 adopts the make-before-break mode. The MN communicates with the VM 249 instance located at the UP3 position until the VM instance completely 250 relocated to the UP4 position. During this period, packets are 251 transmitted through tunnels between UP2 and UP3. The outer header of 252 the tunnel uses the locators assigned by UP2 and UP3. 254 +-------------+ 255 |Control Plane| 256 +-|-|--------|+ 257 | | | 258 | | | _MEC server 259 +--+ | | ,'' `-. 260 IP-mn | | | /' IP-vm 261 +--+ +-|-+ | +|--+ .' +--+ | 262 |MN|-----------|UP1| | ####|UP3|---------|VM| | 263 +--+ +---+ | # +---+ +--+ / 264 | LOC1 | # LOC3 `. ,' 265 | +----+ # ` ---' 266 V | # 267 +--+ +-|-+ # 268 |MN|-----------|UP2|####### 269 +--+ +---+ 270 IP-mn LOC2 272 Figure4: Communication Connection during Movement 274 When the VM instance has been relocated to UP4 position, the MN will 275 communicate with the VM instance at the UP4 position. That is, the 276 communication path will be switched from UP2 to UP3. In this case, it 277 is necessary to set up a temporary path between UP3 and UP4 and 278 forward previous in-transit packets from UP3 to UP4, the temporary 279 path will be released after all the packets has been forwarded to 280 UP4. 282 +-------------+ 283 |Control Plane| 284 +-|-|---|----|+ 285 | | | | 286 | | | | 287 +--+ | | | 288 | | | | 289 +-|-+ | | +|--+ 290 |UP1| | | |UP3| 291 +---+ | | +--$+ 292 LOC1 | | LOC3 $ 293 +----+ +----+ $ 294 IP-mn | | $ V__ 295 +--+ +-|-+ +|-$+ ,'' `-. 296 |MN|-----------|UP2|##########|UP4|---------+--+ 297 +--+ +---+ +---+ .' |VM| | 298 LOC2 LOC4 | +--+ | 299 IP-vm / 300 `. ,' 301 ``---' 302 MEC server 304 Figure5: Communication Connection after Movement 306 NOTE: The interaction signaling between Control Plane and User Plane 307 is TBD. 309 4 Relations with Existing DMM Solutions 311 TBD. 313 5 Security Considerations 315 TBD. 317 6 IANA Considerations 319 TBD. 321 7 References 323 7.1 Normative References 325 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997, 327 . 329 7.2 Informative References 331 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 332 RFC 3514, April 1 2003, . 335 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 336 Acronyms", RFC 5513, April 1 2009, . 339 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 340 2009, . 342 [GS_MEC003] Mobile Edge Computing (MEC); Framework and Reference 343 Architecture, Mar 2016. 345 [Ha2015] Kiryong Ha., "Adaptive VM Handoff Across Cloudlets", June 346 2015. 348 [ODMM] Alper Yegin., "draft-ietf-dmm-ondemand-mobility-10 ", January 349 29, 2017. 351 Contributors: 353 I would like to acknowledge the contribution of the following people 354 to the document: 356 Rui Meng, mengrui@huawei.com 358 Cheng Chen, chencheng@huawei.com 360 Authors' Addresses 362 Jackie Wei 364 Huanbaoyuan Q22, Haidian District, Beijing, China 366 EMail: weixinpeng@huawei.com 368 Fei Yang 370 Huanbaoyuan Q22, Haidian District, Beijing, China 371 yangfei15@huawei.com