idnits 2.17.1 draft-ietf-dmm-distributed-mobility-anchoring-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 23, 2016) is 2769 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-dmm-deployment-models-00 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-03 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-07 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-71 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM H. Chan, Ed. 3 Internet-Draft X. Wei 4 Intended status: Informational Huawei Technologies 5 Expires: March 27, 2017 J. Lee 6 Sangmyung University 7 S. Jeon 8 Sungkyunkwan University 9 A. Petrescu 10 CEA, LIST 11 F. Templin 12 Boeing Research and Technology 13 September 23, 2016 15 Distributed Mobility Anchoring 16 draft-ietf-dmm-distributed-mobility-anchoring-02 18 Abstract 20 This document defines distributed mobility anchoring to meet diverse 21 mobility needs in 5G Wireless and beyond. Multiple anchors and nodes 22 with mobility functions work together to provide IP mobility support. 23 A network or network slice may be configured with distributed 24 mobility anchoring depending on the needs of mobility support. In 25 the distributed mobility anchoring environment, multiple anchors are 26 available for mid-session switching of an IP prefix anchor. Without 27 an ongoing session, i.e., no IP session continuity required, a flow 28 of a mobile node can be re-started using a new IP prefix which is 29 allocated from a new network of the mobile node and is therefore 30 anchored to the new network. With an ongoing session, the anchoring 31 of the prior IP prefix may be relocated to the new network to enable 32 IP session continuity. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 27, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 69 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 6 70 3.1. Configurations for Different Networks or Network Slices . 6 71 3.1.1. Network-based Mobility Support for a Flat Network . . 7 72 3.1.2. Network-based Mobility Support for a Hierarchical 73 Network . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1.3. Host-based Mobility Support . . . . . . . . . . . . . 11 75 3.1.4. NEtwork MObility (NEMO) Basic Support . . . . . . . . 13 76 3.2. Operations and Parameters . . . . . . . . . . . . . . . . 15 77 3.2.1. Location Management . . . . . . . . . . . . . . . . . 16 78 3.2.2. Forwarding Management . . . . . . . . . . . . . . . . 18 79 4. IP Mobility Handling in Distributed Anchoring Environments - 80 Mobility Support Only When Needed . . . . . . . . . . . . . . 24 81 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 25 82 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP 83 Prefix/Address . . . . . . . . . . . . . . . . . . . 27 84 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 28 85 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility . . . 30 86 5. IP Mobility Handling in Distributed Mobility Anchoring 87 Environments - Anchor Switching to the New Network . . . . . 31 88 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 31 89 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat 90 Network . . . . . . . . . . . . . . . . . . . . . . . 32 91 5.2. IP Prefix/Address Anchor Switching for Flat Network with 92 Centralized Control Plane . . . . . . . . . . . . . . . . 33 93 5.2.1. Additional Guidelines for IPv6 Nodes: Switching 94 Anchor with Centralized CP . . . . . . . . . . . . . 36 95 5.3. IP Prefix/Address Anchor Switching for a Hierarchical 96 Network . . . . . . . . . . . . . . . . . . . . . . . . . 37 97 5.3.1. Additional Guidelines for IPv6 Nodes: No Anchoring 98 Change with a Hierarchical Network . . . . . . . . . 39 99 5.4. IP Prefix/Address Anchor Switching for a Hierarchical 100 Network . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 5.4.1. Additional Guidelines for IPv6 Nodes: Switching 102 Anchor with Hierarchical Network . . . . . . . . . . 41 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 105 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 42 108 9.2. Informative References . . . . . . . . . . . . . . . . . 44 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 111 1. Introduction 113 A key requirement in distributed mobility management [RFC7333] is to 114 enable traffic to avoid traversing a single mobility anchor far from 115 an optimal route. Distributed mobility management solutions do not 116 make use of centrally deployed mobility anchor for a data plane 117 [Paper-Distributed.Mobility]. As such, the traffic of a flow SHOULD 118 be able to change from traversing one mobility anchor to traversing 119 another mobility anchor as a mobile node (MN) moves, or when changing 120 operation and management requirements call for mobility anchor 121 switching, thus avoiding non-optimal routes. This draft proposes 122 distributed mobility anchoring to enable making such route changes. 124 Distributed mobility anchoring employs multiple anchors in the data 125 plane. In general, control plane functions may be separate from data 126 plane functions and be centralized but may also be co-located with 127 the data plane functions at the distributed anchors. Different 128 configurations of distributed mobility anchoring are described in 129 Section 3.1. For instance, the configurations for network-based 130 mobility support in a flat network, for network-based mobility 131 support in a hierarchical network, for host-based mobility support, 132 and for NEtwork MObility (NEMO) basic support are described 133 respectively in Section 3.1.1, Section 3.1.2, Section 3.1.3 and 134 Section 3.1.4. Required operations and parameters for distributed 135 mobility anchoring are presented in Section 3.2. For instance, 136 location management is described in Section 3.2.1, forwarding 137 management is described in Section 3.2.2. 139 An MN attached to an access router of a network or network slice may 140 be allocated an IP prefix which is anchored to that router. It may 141 then use an IP address configured from this prefix as the source IP 142 address to run a flow with its correspondent node (CN). When there 143 are multiple mobility anchors, an address selection for a given flow 144 is first required before the flow is initiated. Using an anchor in 145 an MN's network of attachment has the advantage that the packets can 146 simply be forwarded according to the forwarding table. Although the 147 anchor is in the MN's network of attachment when the flow was 148 initiated, the MN may later move to another network, so that the IP 149 no longer belongs to the current network of attachment of the MN. 151 Whether the flow needs IP session continuity will determine how to 152 ensure that the IP address of the flow will be anchored to the new 153 network of attachment. If the ongoing IP flow can cope with an IP 154 prefix/address change, the flow can be reinitiated with a new IP 155 address anchored in the new network as shown in Section 4.1. On the 156 other hand, if the ongoing IP flow cannot cope with such change, 157 mobility support is needed as shown in Section 4.2. A network or 158 network slice supporting a mix of flows requiring and not requiring 159 IP mobility support will need to distinguish these flows. The 160 guidelines for such network or network slice are described in 161 Section 4.1.1. The general guidelines for such network or network 162 slice to provide IP mobility support are described in Section 4.2.1. 164 Specifically, IP mobility support can be provided by changing the 165 anchoring of the IP prefix/address of the flow from the home network 166 of the flow to the new network of attachment. The basic case may be 167 with network-based mobility for a flat network configuration 168 described in Section 5.1 with the guidelines described in 169 Section 5.1.1. This case is discussed further with a centralized 170 control plane in Section 5.2 with additional guidelines described in 171 Section 5.2.1. A level of hierarchy of nodes may then be added to 172 the network configuration. Mobility involving change in the Data 173 Plane Node (DPN) without changing the Data Plane Anchor (DPA) is 174 described in Section 5.3 with additional guidelines described in 175 Section 5.3.1 Mobility involving change in the DPN without changing 176 the DPA is described in Section 5.4 with additional guidelines 177 described in Section 5.4.1 179 2. Conventions and Terminology 181 The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 All general mobility-related terms and their acronyms used in this 186 document are to be interpreted as defined in the Mobile IPv6 (MIPv6) 187 base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) 188 specification [RFC5213], the "Mobility Related Terminologies" 189 [RFC3753], and the DMM current practices and gap analysis [RFC7429]. 190 These include terms such as mobile node (MN), correspondent node 191 (CN), home agent (HA), home address (HoA), care-of-address (CoA), 192 local mobility anchor (LMA), and mobile access gateway (MAG). 194 In addition, this document uses the following terms: 196 Home network of an application session or a home address: the 197 network that has allocated the HoA used for the session identifier 198 by the application running in an MN. The MN may be running 199 multiple application sessions, and each of these sessions can have 200 a different home network. 202 IP prefix/address anchoring: An IP prefix, i.e., Home Network Prefix 203 (HNP), or address, i.e., HoA, allocated to an MN is topologically 204 anchored to an anchor node when the anchor node is able to 205 advertise a connected route into the routing infrastructure for 206 the allocated IP prefix. 208 Location Management (LM) function: managing and keeping track of the 209 internetwork location of an MN. The location information may be a 210 binding of the IP advertised address/prefix, e.g., HoA or HNP, to 211 the IP routing address of the MN or of a node that can forward 212 packets destined to the MN. 214 When the MN is a mobile router (MR) carrying a mobile network of 215 mobile network nodes (MNN), the location information will also 216 include the mobile network prefix (MNP), which is the IP prefix 217 delegated to the MR. The MNP is allocated to the MNNs in the 218 mobile network. 220 LM is a control plane function. 222 In a client-server protocol model, location query and update 223 messages may be exchanged between a Location Management client 224 (LMc) and a Location Management server (LMs). 226 Optionally, there may be a Location Management proxy (LMp) between 227 LMc and LMs. 229 With separation of control plane and data plane, the LM function 230 is in the control plane. It may be a logical function at the 231 control plane node, control plane anchor, or mobility controller. 233 It may be distributed or centralized. 235 Forwarding Management (FM) function: packet interception and 236 forwarding to/from the IP address/prefix assigned to the MN, based 237 on the internetwork location information, either to the 238 destination or to some other network element that knows how to 239 forward the packets to their destination. 241 This function may be used to achieve traffic indirection. With 242 separation of control plane and data plane, the FM function may 243 split into a FM function in the data plane (FM-DP) and a FM 244 function in the control plane (FM-CP). 246 FM-DP may be distributed with distributed mobility management. It 247 may be a function in a data plane anchor or data plane node. 249 FM-CP may be distributed or centralized. It may be a function in 250 a control plane node, control plane anchor or mobility controller. 252 Security Management (SM) function: The security management function 253 controls security mechanisms/protocols providing access control, 254 integrity, authentication, authorization, confidentiality, etc. 255 for the control plane and data plane. 257 This function resides in all nodes such as control plane anchor, 258 data plane anchor, mobile node, and correspondent node. 260 3. Distributed Mobility Anchoring 262 3.1. Configurations for Different Networks or Network Slices 264 The mobility functions may be implemented in different configurations 265 of distributed mobility anchoring in architectures separating the 266 control and data planes. The separation described in 267 [I-D.ietf-dmm-deployment-models] has defined the home control plane 268 anchor (Home-CPA), home data plane anchor (Home-DPA), access control 269 plane node (Access-CPN), and access data plane node (Access-DPN), 270 which are respectively abbreviated as CPA, DPA, CPN, and DPN here. 271 Some configurations are described in 272 [I-D.sijeon-dmm-deployment-models]. 274 Different networks or different network slices may have different 275 configurations in distributed mobility anchoring. 277 The configurations also differ depending on the desired mobility 278 supports: network-based mobility support for a flat network in 279 Section 3.1.1, network-based mobility support for a hierarchical 280 network in Section 3.1.2, host-based mobility support 281 (Section 3.1.3), and NEtwork MObility (NEMO) based support in 282 Section 3.1.4. 284 3.1.1. Network-based Mobility Support for a Flat Network 286 Figure 1 shows two different configurations of network-based mobility 287 management for a flat network. 289 (a) (b) 290 +-----+ 291 |LMs | 292 +-----+ 294 +------------+ +------------+ 295 |CPA: | |CPA: | 296 |FM-CP, LM | |FM-CP, LMc | 297 +------------+ +------------+ 298 +------------+ +------------+ +------------+ +------------+ 299 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 300 |anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... 301 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 302 +------------+ +------------+ +------------+ +------------+ 304 +------------+ +------------+ 305 |MN(IP1) | |MN(IP1) | 306 |flow(IP1,..)| |flow(IP1,..)| 307 +------------+ +------------+ 309 Figure 1. Configurations of network-based mobility management for a 310 flat network (a) FM-CP and LM at CPA, FM-DP at DPA; (b) Separate LMs, 311 FM-CP and LMc at CPA, FM-DP at DPA. 313 Figure 1 also shows a distributed mobility anchoring environment with 314 multiple instances of the DPA. 316 There is an FM-DP function at each of the distributed DPA. 318 The control plane may either be distributed (not shown) or 319 centralized. When the CPA co-locates with the distributed DPA there 320 will be multiple instances of the co-located CPA and DPA (not shown). 322 There is an FM-CP function at the CPA. 324 An MN is allocated an IP prefix/address IP1 which is anchored to the 325 DPA with the IP prefix/address IPa1. The MN uses IP1 to communicate 326 with a CN not shown in the figure. The flow of this communication 327 session is shown as flow(IP1, ...) which uses IP1 and other 328 parameters. 330 In Figure 1(a), LM and FM-CP co-locate at CPA. 332 Then LM may be distributed or centralized according to whether the 333 CPA is distributed (not shown) or centralized. 335 Figure 1(b) differs from Figure 1(a) in that the LM function is split 336 into a server LMs and a client LMc. 338 LMc and FM-CP co-locate at the CPA. 340 The LMs may be centralized whereas the LMc may be distributed or 341 centralized according to whether the CPA is distributed (not shown) 342 or centralized. 344 3.1.2. Network-based Mobility Support for a Hierarchical Network 346 Figure 2 shows two different configurations of network-based mobility 347 management for a hierarchical network. 349 (a) 350 +------------+ 351 |CPA: | 352 |FM-CP, LMs | 353 +------------+ 354 +------------+ +------------+ 355 |DPA(IPa1): | |DPA(IPa2): | 356 |anchors IP1 | |anchors IP2 | ... 357 |FM-DP | |FM-DP | 358 +------------+ +------------+ 360 +------------+ 361 |CPN: | 362 |FM-CP, LMc | 363 +------------+ 364 +------------+ +------------+ +------------+ +------------+ 365 |DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) | 366 |FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ... 367 +------------+ +------------+ +------------+ +------------+ 369 +------------+ +------------+ 370 |MN(IP1) | |MN(IP2) | 371 |flow(IP1,..)| |flow(IP2,..)| 372 +------------+ +------------+ 374 Figure 2(a). Configurations of network-based mobility management for 375 a hierarchical network with FM-CP and LMs at CPA, FM-DP at DPA; FM-CP 376 and LMc at CPN, FM-DP at DPN. 378 (b) 379 +-----+ 380 |LMs | 381 +-----+ 383 +------------+ 384 |CPA: | 385 |FM-CP, LMp | 386 +------------+ 387 +------------+ +------------+ 388 |DPA(IPa1): | |DPA(IPa2): | 389 |anchors IP1 | |anchors IP2 | ... 390 |FM-DP | |FM-DP | 391 +------------+ +------------+ 393 +------------+ 394 |CPN: | 395 |FM-CP, LMc | 396 +------------+ 397 +------------+ +------------+ +------------+ +------------+ 398 |DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) | 399 |FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ... 400 +------------+ +------------+ +------------+ +------------+ 402 +------------+ +------------+ 403 |MN(IP1) | |MN(IP2) | 404 |flow(IP1,..)| |flow(IP2,..)| 405 +------------+ +------------+ 407 Figure 2(b). Configurations of network-based mobility management for 408 a hierarchical network with separate LMs, FM-CP and LMp at CPA, FM-DP 409 at DPA; FM-CP and LMc at CPN, FM-DP at DPN. 411 Figures 2 also shows a distributed mobility anchoring environment 412 with multiple instances of the DPA. 414 In the hierarchy, there may be multiple DPN's for each DPA. 416 There is FM-DP at each of the distributed DPA and at each of the 417 distributed DPN. 419 The control plane may either be distributed (not shown) or 420 centralized. 422 When the CPA co-locates with the distributed DPA there will be 423 multiple instances of the co-located CPA and DPA (not shown). 425 When the CPN co-locates with the distributed DPN there will be 426 multiple instances of the co-located CPN and DPN (not shown). 428 There is FM-CP function at the CPA and at the CPN. 430 MN is allocated an IP prefix/address IP1 which is anchored to the DPA 431 with the IP prefix/address IPa1. It is using IP1 to communicate with 432 a correspondent node (CN) not shown in the figure. The flow of this 433 communication session is shown as flow(IP1, ...) which uses IP1 and 434 other parameters. 436 In Figure 2(a), LMs and FM-CP are at the CPA. In addition, there are 437 FM-CP and LMc at the CPN. 439 LMs may be distributed or centralized according to whether the CPA is 440 distributed or centralized. The CPA may co-locate with DPA or may 441 separate. 443 Figure 2(b) differs from Figure 2(a) in that the LMs is separated 444 out, and a proxy LMp is added between the LMs and LMc. 446 LMp and FM-CP co-locate at the CPA. 448 FM-CP and LMc co-locate at the CPN. 450 The LMs may be centralized whereas the LMp may be distributed or 451 centralized according to whether the CPA is distributed or 452 centralized. 454 3.1.3. Host-based Mobility Support 456 Host-based variants of the mobility function configurations from 457 Figures 2(a) and 2(b) are respectively shown in Figures 3(a) and 3(b) 458 where the role to perform mobility functions by CPN and DPN are now 459 taken by the MN. The MN then needs to possess the mobility functions 460 FM and LMc. 462 (a) (b) 463 +-----+ 464 |LMs | 465 +-----+ 467 +------------+ +------------+ 468 |CPA: | |CPA: | 469 |FM-CP, LMs | |FM-CP, LMp | 470 +------------+ +------------+ 471 +------------+ +------------+ +------------+ +------------+ 472 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 473 |anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... 474 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 475 +------------+ +------------+ +------------+ +------------+ 477 +------------+ +------------+ 478 |MN(IP1) | |MN(IP1) | 479 |flow(IP1,..)| |flow(IP1,..)| 480 |FM, LMc | |FM, LMc | 481 +------------+ +------------+ 483 Figure 3. Configurations of host-based mobility management (a) FM-CP 484 and LMs at CPA, FM-DP at DPA, FM and LMc at MN; (b) Separate LMs, FM- 485 CP and LMp at CPA, FM-DP at DPA, FM and LMc at MN. 487 Figure 3 shows 2 configurations of host-based mobility management 488 with multiple instances of DPA for a distributed mobility anchoring 489 environment. 491 There is an FM-DP function at each of the distributed DPA. 493 The control plane may either be distributed (not shown) or 494 centralized. 496 When the CPA co-locates with the distributed DPA there will be 497 multiple instances of the co-located CPA and DPA (not shown). 499 There is an FM-CP function at the CPA. 501 The MN possesses the mobility functions such as FM and LMc. 503 The MN is allocated an IP prefix/address IP1 which is anchored to the 504 DPA with the IP prefix/address IPa1. It is using IP1 to communicate 505 with a CN not shown in the figure. The flow of this communication 506 session is shown as flow(IP1, ...) which uses IP1 and other 507 parameters. 509 In Figure 3(a), LMs and FM-CP co-locate at the CPA. 511 The LMs may be distributed or centralized according to whether the 512 CPA is distributed (not shown) or centralized. 514 Figure 3(b) differs from Figure 3(a) in that the LMs is separated out 515 and the proxy LMp is added between the LMs and LMc. 517 LMp and FM-CP co-locate at the CPA. 519 The LMs may be centralized whereas the LMp may be distributed or 520 centralized according to whether the CPA is distributed (not shown) 521 or centralized. 523 3.1.4. NEtwork MObility (NEMO) Basic Support 525 Figure 4 shows two configurations of NEMO basic support for a mobile 526 router. 528 (a) (b) 529 +-----+ 530 |LMs | 531 +-----+ 533 +------------+ +------------+ 534 |CPA: | |CPA: | 535 |FM-CP, LMs | |FM-CP, LMp | 536 +------------+ +------------+ 537 +------------+ +------------+ +------------+ +------------+ 538 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 539 |anchors IP1 | |anchors IP2 | |anchors IP1 | |anchors IP2 | 540 |DHCPv6-PD | |DHCPv6-PD | ... |DHCPv6-PD | |DHCPv6-PD | ... 541 | IPn1| | IPn2| | IPn1| | IPn2| 542 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 543 +------------+ +------------+ +------------+ +------------+ 545 +------------+ +------------+ 546 |FM-CP LMc | |FM-CP LMc | 547 |- - - - - - | |- - - - - - | 548 |MR(IP1) | |MR(IP1) | 549 |anchors IPn1| |anchors IPn1| 550 |FM-DP | |FM-DP | 551 +------------+ +------------+ 553 +------------+ +------------+ 554 |MNN(IPn1) | |MR(IP1n1) | 555 |flow(IPn1,.)| |flow(IPn1,.)| 556 +------------+ +------------+ 558 Figure 4. Configurations of NEMO basic support for a MR. (a) FM-CP 559 and LMs at CPA, FM-DP at DPA, FM and LMc at MR; (b) Separate LMs, FM- 560 CP and LMp at CPA, FM-DP at DPA, FM and LMc at MR. 562 Figure 4 shows 2 configurations of host-based mobility management for 563 a MR with multiple instances of DPA for a distributed mobility 564 anchoring environment. 566 There is an FM-DP function at each of the distributed DPA. 568 The control plane may either be distributed (not shown) or 569 centralized. 571 When the CPA co-locates with the distributed DPA there will be 572 multiple instances of the co-located CPA and DPA (not shown). 574 There is FM-CP function at the CPA. 576 The MR possesses the mobility functions FM and LMc. 578 MR is allocated an IP prefix/address IP1 which is anchored to the DPA 579 with the IP prefix/address IPa1. 581 A mobile network node (MNN) in the mobile network is allocated an IP 582 prefix/address IPn1 which is anchored to the MR with the IP prefix/ 583 address IP1. 585 The MNN is using IPn1 to communicate with a correspondent node (CN) 586 not shown in the figure. The flow of this communication session is 587 shown as flow(IPn1, ...) which uses IPn1 and other parameters. 589 In Figure 4(a), LMs and FM-CP co-locate at the CPA. 591 The LMs may be distributed or centralized according to whether the 592 CPA is distributed (not shown) or centralized. 594 Figure 4(b) differs from Figure 4(a) in that the LMs is separated out 595 and the proxy LMp is added between the LMs and LMc. 597 LMp and FM-CP co-locate at the CPA. 599 The LMs may be centralized whereas the LMp may be distributed or 600 centralized according to whether the CPA is distributed (not shown) 601 or centralized. 603 3.2. Operations and Parameters 605 The operations of distributed mobility anchoring are defined in order 606 that they may work together in expected manners to produce a 607 distributed mobility solution. The needed information is passed as 608 mobility message parameters, which must be protected in terms of 609 integrity. Some parameters may require a means to support privacy of 610 an MN or MR. 612 The mobility needs in 5G Wireless and beyond are diverse. Therefore 613 operations needed to enable different distributed mobility solutions 614 in different distributed mobility anchoring configurations are 615 extensive as illustrated below. It is however not necessary for 616 every distributed mobility solution to exhibit all the operations 617 listed in this section. A given distributed mobility solution may 618 exhibit the operations as needed. 620 3.2.1. Location Management 622 An example LM design consists of a distributed database with multiple 623 LMs servers. The location information about the prefix/address of an 624 MN is primarily at a given LMs. Peer LMs may exchange the location 625 information with each other. LMc may retrieve a given record or send 626 a given record update to LMs. 628 Location management configurations: 630 LM-cfg: As shown in Section 3.1: 632 LMs may be implemented at CPA, may co-locate with LMc at CPA, 633 or may be a separate server. 635 LMc may be at CPA, CPN, or MN. 637 LMp may proxy between LMs and LMc. 639 Specifically: 641 Location management operations and parameters: 643 LM-cfg:1 LMs may co-locate with LMc at CPA in a flat network with 644 network-based mobility as shown in Figure 1(a) in 645 Section 3.1.1. 647 LM-cfg:2 LMs may be a separate server whereas LMc is implemented in 648 CPA in a flat network with network-based mobility as shown 649 in Figure 1(b) in Section 3.1.1. 651 LM-cfg:3 LMs may be implemented at CPA, whereas LMc is implemented 652 at CPN in a hierarchical network with network-based 653 mobility as shown in Figure 2(a) in Section 3.1.2 or at MN 654 for host-based mobility as shown in Figure 3(a) in 655 Section 3.1.3. 657 LM-cfg:4 LMs may be a separate server with LMp implemented at CPA 658 whereas LMc is implemented at CPN in a hierarchical network 659 with network-based mobility as shown in Figure 2(b) in 660 Section 3.1.2 or at MN for host-based mobility as shown in 661 Figure 3(b) in Section 3.1.3. 663 LM-db: LM may manage the location information in a client-server 664 database system. 666 Example LM database functions are as follows: 668 LM-db:1 LMc may query LMs about location information for a prefix of 669 MN (pull). 670 Parameters: 671 - IP prefix of MN: integrity support required and privacy 672 support may be required. 674 LM-db:2 LMs may reply to LMc query about location information for a 675 prefix of MN (pull). 676 Parameters: 677 - IP prefix of MN: integrity support required and privacy 678 support may be required 679 - IP address of FM-DP/DPA/DPN to forward the packets of the 680 flow: integrity support required. 682 LM-db:3 LMs may inform LMc about location information for a prefix 683 of MN (push). 684 Parameters: 685 - IP prefix of MN: integrity support required and privacy 686 support may be required 687 - IP address of FM-DP/DPA/DPN to forward the packets of the 688 flow. 690 This function in the PMIPv6 protocol is the Update 691 Notification (UPN) together with the Update Notification 692 Acknowledgment (UPA) as defined in [RFC7077]. 694 LM-db:4 LMc may inform LMs about update location information for a 695 prefix of MN. 696 Parameters: 697 - IP prefix of MN: integrity support required and privacy 698 support may be required 699 - IP address of FM-DP/DPA/DPN to forward the packets of the 700 flow: integrity support required 702 This function in the MIPv6 / PMIPv6 protocol is the Binding 703 Update (BU) / Proxy Binding Update (PBU) together with the 704 Binding Acknowledgment (BA) / Proxy Binding Acknowledgment 705 (PBA) as defined in [RFC6275] / [RFC5213] respectively. 707 LM-db:5 The MN may be a host or a router. When the MN is an MR, the 708 prefix information may include the MNP delegated to the MR. 709 Additional parameters: 710 MNP: integrity support required and privacy support may be 711 required 713 LM-svr: The LM may be a distributed database with multiple LMs 714 servers. 716 For example: 718 LM-svr:1 A LMs may join a pool of LMs servers. 719 Parameters: 720 - IP address of the LMs: integrity support required 721 - IP prefixes for which the LMs will host the primary 722 location information: integrity support required. 724 LM-svr:2 LMs may query a peer LMs about location information for a 725 prefix of MN. 726 Parameters: 727 - IP prefix: integrity support required and privacy support 728 may be required. 730 LM-svr:3 LMs may reply to a peer LMs about location information for 731 a prefix of MN. 732 Parameters: 733 - IP prefix of MN: integrity support required and privacy 734 support may be required 735 - IP address of FM-DP/DPA/DPN to forward the packets of the 736 flow: integrity support required. 738 The parameters indicated above are only the minimal. In a specific 739 mobility protocol, additional parameters should be added as needed. 740 Examples of these additional parameters are those passed in the 741 mobility options of the mobility header for MIPv6 [RFC6275] and for 742 PMIPv6 [RFC5213]. 744 3.2.2. Forwarding Management 746 Forwarding management configurations: 748 FM-cfg: As shown in Section 3.1: 750 FM-CP may be implemented at CPA, CPN, MN depending on the 751 configuration chosen. 753 FM-DP may also be implemented at CPA, CPN, MN depending on 754 the configuration chosen. 756 Specifically: 758 FM-cfg:1 FM-CP and FM-DP may be implemented at CPA and DPA 759 respectively in a flat network with network-based mobility 760 as shown in Figure 1(a) and Figure 1(b) in Section 3.1.1. 762 FM-cfg:2 FM-CP may be implemented at both CPA and CPN and FM-DP is 763 implemented at both DPA and DPN in a hierarchical network 764 with network-based mobility as shown in Figure 2(a) and 765 Figure 2(b) in Section 3.1.2. 767 FM-cfg:3 FM-CP and FM-DP may be implemented at CPA and DPA 768 respectively and also both implemented at MN for host-based 769 mobility as shown in Figure 3(a) and Figure 3(b) in 770 Section 3.1.3. 772 Forwarding management operations and parameters: 774 FM-find:1 An anchor may discover and be discovered such as through 775 an anchor registration system as follows: 777 FM-find:2 FM registers and authenticates itself with a centralized 778 mobility controller. 779 Parameters: 780 - IP address of DPA and its CPA: integrity support 781 required 782 - IP prefix anchored to the DPA: integrity support 783 required 785 registration reply: acknowledge of registration and echo 786 the input parameters. 788 FM-find:3 FM discovers the FM of another IP prefix by querying the 789 mobility controller based on the IP prefix. 790 Parameters: 791 - IP prefix of MN: integrity support required and privacy 792 support may be required 794 FM-find:4 when making anchor discovery FM expects the answer 795 parameters: 796 - IP address of DPA to which IP prefix of MN is anchored: 797 integrity support required 798 - IP prefix of the corresponding CPA: integrity support 799 required 801 FM-flow:1 The FM may be carried out on the packets to/from an MN up 802 to the granularity of a flow. 804 FM-flow:2 Example matching parameters are in the 5-tuple of a flow. 806 FM-cpdp: With separation of control plane function and data plane 807 function, FM-CP and FM-DP communicate with each other. Such 808 communication may be realized by the appropriate messages in 809 [I-D.ietf-dmm-fpc-cpdp]. 811 For example: 813 FM-cpdp:1 CPA/FM-CP sends forwarding table updates to DPA/FM-DP. 814 Parameters: 815 - New forwarding table entries to add: integrity support 816 required 817 - Expired forwarding table entries to delete: integrity 818 support required 820 FM-cpdp:2 DPA/FM-DP sends to CPA/FM-CP about its status and load. 821 Parameters: 822 - State of forwarding function being active or not: 823 integrity support required 824 - Loading percentage: integrity support required 826 FM-path:1 FM may change the forwarding path of a flow upon a change 827 of point of attachment of a MN. Prior to the changes, 828 packets coming from the CN to the MN would traverse from 829 the CN to the home network anchor of the flow for the MN 830 before reaching the MN. Changes are from this original 831 forwarding path or paths to a new forwarding path or paths 832 from the CN to the current AR of the MN and then the MN 833 itself. 835 FM-path:2 As an incoming packet is forwarded from the CN to the MN, 836 the far end where forwarding path change begins may in 837 general be any node in the original forwarding path from 838 the CN to the home network DPA. The packet is forwarded 839 to the MN for host-based mobility and to a node in the 840 network which will deliver the packets to the MN for 841 network-based mobility. The near-end is generally a DPN 842 with a hierarchical network but may also be another node 843 with DPA capability in a flattened network. 845 FM-path:3 The mechanisms to accomplish such changes may include 846 changes to the forwarding table and indirection such as 847 tunneling, rewriting packet header, or NAT. 849 Note: An emphasis in this document in distributed mobility 850 anchoring is to explain the use of multiple anchors to 851 avoid unnecessarily long route which may be encountered in 852 centralized mobility anchoring. It is therefore not the 853 emphasis of this document on which particular mechanism to 854 choose from. 856 FM-path-tbl:4 With forwarding table updates, changes to the 857 forwarding table are needed at each of the affected 858 forwarding switches in order to change the forwarding 859 path of the packets for the flow from that originally 860 between the CN and the home network anchor to that 861 between the CN and the new AR. 863 Forwarding table updates may be achieved through BGP 864 update as described in [I-D.templin-aerolink], 865 [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved 866 Packet Core (EPC) network in 867 [I-D.matsushima-stateless-uplane-vepc] when the scope 868 and response time can be managed. Alternatively, a 869 centralized control plane may be used. 871 When the control plane is centralized, forwarding 872 table updates may be achieved through messaging 873 between the centralized control plane and the 874 distributed forwarding switches as described above 875 (FM-cpdp) in this section. 877 Forwarding table updates may be triggered using 878 DHCPv6-PD prefix delegation to change the role of IP 879 anchoring from the home network anchor (with FM-DP) to 880 the new anchor (with FM-DP) to which the MN is 881 currently attached. The new anchor will then 882 advertise routes for the delegated prefix. 884 With a distributed routing protocol, the updates 885 spread out from neighbors to neighbors and will affect 886 all the forwarding switches such that the packets sent 887 from "any" node to MN will go to the new AR. 889 Yet the scope of such updates for a given flow may be 890 confined to only those forwarding switches such that 891 the packets sent only from the "CN" to MN will go to 892 the new AR. Such confinement may be made when using a 893 centralized central plane possessing a global view of 894 all the forwarding switches. 896 FM-path-tbl:5 FM reverts the changes previously made to the 897 forwarding path of a flow when such changes are no 898 longer needed, e.g., when all the ongoing flows using 899 an IP prefix/address requiring IP session continuity 900 have closed. When using DHCPv6-PD, the forwarding 901 paths will be reverted upon prefix lease expiration. 903 FM-path-ind:6 Indirection forwards the incoming packets of the flow 904 from the DPA at the far end to a DPA/DPN at the near 905 end of indirection. Both ends of the indirection 906 needs to know the LM information of the MN for the 907 flow and also needs to possess FM capability to 908 perform indirection. 910 FM-path-ind:7 The mechanism of changing the forwarding path in 911 [RFC6275] and [RFC5213] is tunneling. In the control 912 plane, the FM-CP sets up the tunnel by instructing the 913 FM-DP at both ends of the tunnel. In the data plane, 914 the FM-DP at the start of the tunnel performs packet 915 encapsulation, whereas the FM-DP at the end of the 916 tunnel decapsulates the packet. 918 Note that in principle the ends of the indirection 919 path can be any pair of network elements with the FM- 920 DP function. 922 FM-path-ind:8 FM reverts the changes previously made to the 923 forwarding path of a flow when such changes are no 924 longer needed, e.g., when all the ongoing flows using 925 an IP prefix/address requiring IP session continuity 926 have closed. When tunneling is used, the tunnels will 927 be torn down when they are no longer needed. 929 FM-DPA:1 Recall from above that for the incoming packets from the 930 CN, forwarding path change by FM is from the DPA at the far 931 end which may be at any forwarding switch (or even CN 932 itself) in the original forwarding path to the near end 933 DPA/DPN. 935 It is necessary that any incoming packet from the CN of the 936 flow must traverse the DPA (or at least one of the DPAs, 937 e.g., in the case of anycast) at the far end in order for 938 the packet to detour to a new forwarding path. 940 Therefore a convenient design is to locate the far end DPA 941 at a unique location which is always in the forwarding 942 path. This is the case in a centralized mobility design 943 where the DPA at the far end is the home network anchor of 944 the flow. 946 Distributed mobility however may place the far end DPA at 947 other locations in order to avoid unnecessarily long route. 949 FM-DPA:2 With multiple nodes possessing DPA capabilities, the role 950 of FM to begin path change for the incoming packets of a 951 flow at the home network DPA at the far end may be passed 952 to or added to that of another DPA. 954 In particular, this DPA role may be moved upstream from the 955 home network DPA in the original forwarding path from CN to 956 MN. 958 FM-DPA:3 Optimization of the new forwarding path may be achieved 959 when the path change for the incoming packets begins at a 960 DPA where the original path and the direct IPv6 path 961 overlaps. Then the new forwarding path will resemble the 962 direct IPv6 path from the CN to the MN. 964 FM-DPA-tbl:4 Forwarding table updates, such as that triggered using 965 DHCPv6-PD to change the role of IP anchoring from the 966 home network anchor (DPA with FM-DP) to the new anchor 967 (DPA with FM-DP), may put the near end of the path 968 change at the new DPA. Subsequent forwarding table 969 updates may propagates upstream up to a far end where 970 the original path and the direct IPv6 path overlaps. 972 When that far end is too far upstream the signaling of 973 forwarding table updates may become excessive. An 974 alternative is to use indirection (see FM-DPA-ind) from 975 that far end to the new DPA at the near end. 977 Still another alternative is to combine forwarding 978 table update with indirection. 980 FM-DPA-tbl:5 Changes made by FM to the following tables, which are 981 IPv6 nodes, at the ends of the path change for a flow 982 will be reverted when the mobility support for the flow 983 is no longer needed, e.g., when the flows have 984 terminated. 986 FM-DPA-ind:6 With indirection, locating or moving the FM function to 987 begin indirection upstream along the forwarding path 988 from CN to MN again may help to reduce unnecessarily 989 long path. 991 FM-DPA-ind:7 Changes made by FM to establish indirection at the DPA 992 and DPN, which are IPv6 nodes, at the ends of the path 993 change for a flow will be reverted when the mobility 994 support for the flow is no longer needed, e.g., when 995 the flows have terminated. 997 FM-state:1 In addition to the above, a flow/session may contain 998 states with the required information for QoS, charging, 999 etc. as needed. These states need to be transferred from 1000 the old anchor to the new anchor. 1002 FM-buffer:1 An anchor can buffer packets of a flow in a mobility 1003 event: 1004 FM-buffer:2 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow. 1005 Trigger: 1006 - MN leaves DPA in a mobility event. 1007 Parameters: 1008 - IP prefix of the flow for which packets need to be 1009 buffered: integrity support required 1011 FM-buffer:3 CPA/FM-CP on behalf of a new DPA/FM-DP informs the CPA/ 1012 FM-CP of the prior DPA/FM-DP that it is ready to receive 1013 any buffered packets of a flow. 1014 Parameters: 1015 - Destination IP prefix of the flow's packets: integrity 1016 support required 1017 - IP address of the new DPA: integrity support required 1019 FM-mr:1 When the MN is a mobile router the access router anchoring 1020 the IP prefix of MR will also anchor the IP prefix or 1021 prefixes delegated to the MR. 1023 4. IP Mobility Handling in Distributed Anchoring Environments - 1024 Mobility Support Only When Needed 1026 IP Mobility Support Only When Needed: 1028 IP mobility support may be provided only when needed instead of being 1029 provided by default. The LM and FM functions in the different 1030 configurations shown in Section 3.1 are then utilized only when 1031 needed. 1033 A straightforward choice of mobility anchoring is for a flow to use 1034 the IP prefix of the network to which the MN is attached when the 1035 flow is initiated [I-D.seite-dmm-dma]. 1037 The IP prefix/address at the MN's side of a flow may be anchored at 1038 the access router to which the MN is attached. For example, when an 1039 MN attaches to a network (Net1) or moves to a new network (Net2), it 1040 is allocated an IP prefix from the attached network. In addition to 1041 configuring new link-local addresses, the MN configures from this 1042 prefix an IP address which is typically a dynamic IP address. It 1043 then uses this IP address when a flow is initiated. Packets to the 1044 MN in this flow are simply forwarded according to the forwarding 1045 table. 1047 There may be multiple IP prefixes/addresses that an MN can select 1048 when initiating a flow. They may be from the same access network or 1049 different access networks. The network may advertise these prefixes 1050 with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node 1051 may choose the one with the least cost. In addition, these IP 1052 prefixes/addresses may be of different types regarding whether 1053 mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow 1054 will need to choose the appropriate one according to whether it needs 1055 IP mobility support. 1057 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 1059 When IP mobility support is not needed for a flow, the LM and FM 1060 functions are not utilized so that the configurations in Section 3.1 1061 are simplified as shown in Figure 5. 1063 Net1 Net2 1065 +---------------+ +---------------+ 1066 |AR1 | |AR2 | 1067 +---------------+ +---------------+ 1068 |CPA: | |CPA: | 1069 |---------------| |---------------| 1070 |DPA(IPa1): | |DPA(IPa2): | 1071 |anchors IP1 | |anchors IP2 | 1072 +---------------+ +---------------+ 1074 +...............+ +---------------+ 1075 .MN(IP1) . move |MN(IP2) | 1076 .flow(IP1,...) . =======> |flow(IP2,...) | 1077 +...............+ +---------------+ 1079 Figure 5. Changing to the new IP prefix/address. MN running a flow 1080 using IP1 in a network Net1 changes to running a flow using IP2 in 1081 Net2. 1083 When there is no need to provide IP mobility to a flow, the flow may 1084 use a new IP address acquired from a new network as the MN moves to 1085 the new network. 1087 Regardless of whether IP mobility is needed, if the flow has 1088 terminated before the MN moves to a new network, the flow may 1089 subsequently restart using the new IP address allocated from the new 1090 network. 1092 When IP session continuity is needed, even if a flow is ongoing as 1093 the MN moves, it may still be desirable for the flow to change to 1094 using the new IP prefix configured in the new network. The flow may 1095 then close and then restart using a new IP address configured in the 1096 new network. Such a change in the IP address of the flow may be 1097 enabled using a higher layer mobility support which is not in the 1098 scope of this document. 1100 In Figure 5, a flow initiated while the MN was in a network Net1 has 1101 terminated before the MN moves to a new network Net2. After moving 1102 to Net2, the MN uses the new IP prefix anchored in Net2 to start a 1103 new flow. The packets may then be forwarded without requiring IP 1104 layer mobility support. 1106 An example call flow is outlined in Figure 6. 1108 MN p-AR n-AR CN 1109 |MN attaches to p-AR: | | | 1110 |acquire MN-ID and profile | | 1111 |--RS---------------->| | | 1112 | | | | 1113 |<----------RA(HNP1)--| | | 1114 | | | | 1115 Allocated prefix HNP1 1116 IP1 address configuration 1117 | | | | 1118 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1119 | | | | 1120 |MN detaches from p-AR| | | 1121 |MN attaches to n-AR | | | 1122 | | | | 1123 |--RS------------------------------>| | 1124 | | | | 1125 |<--------------RA(HNP2)------------| | 1126 | | | | 1127 Allocated prefix HNP2 1128 IP2 address configuration 1129 | | | | 1130 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1131 | | | | 1133 Figure 6. Re-starting a flow to use the IP allocated from the 1134 network at which the MN is attached. 1136 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address 1138 A network or network slice may not need IP mobility support. For 1139 example, a network slice for stationary sensors only will never 1140 encounter mobility. 1142 The standard functions in IPv6 already include dropping the old IPv6 1143 prefix/address and acquiring new IPv6 prefix/address when the node 1144 changes its point of attachment to a new network. Therefore, a 1145 network or network slice not providing IP mobility support at all 1146 will not need any of the functions with the mobility operations and 1147 messages described in Section 3.2. 1149 The guidelines for the IPv6 nodes in a network or network slice 1150 supporting a mix of flows requiring and not requiring IP mobility 1151 support include the following: 1153 GL-cfg:1 A network or network slice supporting a mix of flows 1154 requiring and not requiring mobility support may take any 1155 of the configurations described in Section 3.1 and need to 1156 implement in the appropriate IPv6 nodes the mobility 1157 functions LM and FM as described respectively in LM-cfg and 1158 FM-cfg in Section 3.2 according to the configuration 1159 chosen. 1161 GL-mix:1 These mobility functions perform some of the operations 1162 with the appropriate messages as described in Section 3.2 1163 depending on which mobility mechanisms are used. Yet these 1164 mobility functions must not be invoked for a flow that does 1165 not need IP mobility support. It is necessary to be able 1166 to distinguish the needs of a flow. The guidelines for the 1167 MN and the AR are in the following. 1169 GL-mix:2 Regardless of whether there are flows requiring IP mobility 1170 support, when the MN changes its point of attachment to a 1171 new network, it needs to configure a new global IP address 1172 for use in the new network in addition to configuring the 1173 new link-local addresses. 1175 GL-mix:3 The MN needs to check whether a flow needs IP mobility 1176 support. This can be performed when the application was 1177 initiated. The specific method is not in the scope of this 1178 document. 1180 GL-mix:4 The information of whether a flow needs IP mobility support 1181 is conveyed to the network such as by choosing an IP 1182 address to be provided with mobility support as described 1183 in [I-D.ietf-dmm-ondemand-mobility]. Then as the MN 1184 attaches to a new network, if the MN was using an IP 1185 address that is not supposed to be provided with mobility 1186 support, the access router will not invoke the mobility 1187 functions described in Section 3.2 for this IP address. 1188 That is, the IP address from the prior network is simply 1189 not used in the new network. 1191 The above guidelines are only to enable distinguishing whether there 1192 is need of IP mobility support for a flow that does not. When the 1193 flow needs IP mobility support, the list of guidelines will continue 1194 in Section 4.2.1. 1196 4.2. Need of IP Mobility 1198 When IP mobility is needed for a flow, the LM and FM functions in 1199 Section 3.1 are utilized. The mobility support may be provided by IP 1200 prefix anchor switching to the new network to be described in 1201 Section 5 or by using other mobility management methods 1202 ([Paper-Distributed.Mobility.PMIP] and 1203 [Paper-Distributed.Mobility.Review]). Then the flow may continue to 1204 use the IP prefix from the prior network of attachment. Yet some 1205 time later, the user application for the flow may be closed. If the 1206 application is started again, the new flow may not need to use the 1207 prior network's IP address to avoid having to invoke IP mobility 1208 support. This may be the case where a dynamic IP prefix/address 1209 rather than a permanent one is used. The flow may then use the new 1210 IP prefix in the network where the flow is being initiated. Routing 1211 is again kept simpler without employing IP mobility and will remain 1212 so as long as the MN which is now in the new network has not moved 1213 again and left to another new network. 1215 An example call flow in this case is outlined in Figure 7. 1217 MN p-AR n-AR CN 1218 |MN attaches to p-AR: | | | 1219 |acquire MN-ID and profile | | 1220 |--RS---------------->| | | 1221 | | | | 1222 |<----------RA(HNP1)--| | | 1223 | | | | 1224 Allocated prefix HNP1 1225 IP1 address configuration 1226 | | | | 1227 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1228 | | | | 1229 |MN detach from p-AR | | | 1230 |MN attach to n-AR | | | 1231 | | | | 1232 |--RS------------------------------>| | 1234 IP mobility support such as that described in next sub-section 1235 |<--------------RA(HNP2,HNP1)-------| | 1236 | | | | 1237 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1238 | | | | 1239 Allocated prefix HNP2 1240 IP2 address configuration 1241 | | | | 1242 Flow(IP1,IPcn) terminates 1243 | | | | 1244 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1245 | | | | 1247 Figure 7. A flow continues to use the IP from its home network after 1248 MN has moved to a new network. 1250 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility 1252 The configuration guidelines of distributed mobility for the IPv6 1253 nodes in a network or network slice supporting a mix of flows 1254 requiring and not requiring distributed mobility support are as 1255 follows: 1257 GL-cfg:2 Multiple instances of DPAs (at access routers) which are 1258 providing IP prefix to the MNs are needed to provide 1259 distributed mobility anchoring in an appropriate 1260 configuration such as those in Figure 1 (Section 3.1.1) for 1261 network-based distributed mobility or in Figure 3 1262 (Section 3.1.3) for host-based distributed mobility. 1264 The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) are to be 1265 implemented the mobility functions LM and FM as described 1266 respectively in LM-cfg and FM-cfg in Section 3.2 according 1267 to the configuration chosen. 1269 The guidelines of distributed mobility for the IPv6 nodes in a 1270 network or network slice supporting a mix of flows requiring and not 1271 requiring distributed mobility support had begun with those given as 1272 GL-mix in Section 4.1.1 and continue as follows: 1274 GL-mix:5 The distributed anchors may need to message with each 1275 other. When such messaging is needed, the anchors may need 1276 to discover each other as described in the FM operations 1277 and mobility message parameters (FM-find) in Section 3.2.2. 1279 GL-mix:6 The anchors may need to provide mobility support on a per- 1280 flow basis as described in the FM operations and mobility 1281 message parameters (FM-flow) in Section 3.2.2. 1283 GL-mix:7 Then the anchors need to properly forward the packets of 1284 the flows as described in the FM operations and mobility 1285 message parameters (FM-path, FM-path-tbl, FM-DPA, FM-DPA- 1286 tbl) in Section 3.2.2. 1288 GL-mix:8 If there are in-flight packets toward the old anchor while 1289 the MN is moving to the new anchor, it may be necessary to 1290 buffer these packets and then forward to the new anchor 1291 after the old anchor knows that the new anchor is ready. 1292 Such are described in the FM operations and mobility 1293 message parameters (FM-buffer) in Section 3.2.2. 1295 5. IP Mobility Handling in Distributed Mobility Anchoring Environments 1296 - Anchor Switching to the New Network 1298 IP Prefix/Address Anchor Switching to the New Network: 1300 IP mobility is invoked to enable IP session continuity for an ongoing 1301 flow as the MN moves to a new network. Here the anchoring of the IP 1302 address of the flow is in the home network of the flow, which is not 1303 in the current network of attachment. A centralized mobility 1304 management mechanism may employ indirection from the anchor in the 1305 home network to the current network of attachment. Yet it may be 1306 difficult to avoid unnecessarily long route when the route between 1307 the MN and the CN via the anchor in the home network is significantly 1308 longer than the direct route between them. An alternative is to 1309 switch the IP prefix/address anchoring to the new network. 1311 5.1. IP Prefix/Address Anchor Switching for Flat Network 1313 The IP prefix/address anchoring may move without changing the IP 1314 prefix/address of the flow. Here the LM and FM functions in Figures 1315 1(a) and 1(b) in Section 3.1 are implemented as shown in Figure 8. 1317 Net1 Net2 1319 +---------------+ +---------------+ 1320 |AR1 | |AR2 | 1321 +---------------+ +---------------+ 1322 |CPA: | |CPA: | 1323 |LM:IP1<-->IPa2 | |LM:IP1<-->IPa2 | 1324 |---------------| |---------------| 1325 |DPA(IPa1): | |DPA(IPa2): | 1326 |anchors IP1 | move |anchors IP2,IP1| 1327 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 1328 +---------------+ +---------------+ 1330 +...............+ +---------------+ 1331 .MN(IP1) . move |MN(IP2,IP1) | 1332 .flow(IP1,...) . =======> |flow(IP1,...) | 1333 +...............+ +---------------+ 1335 Figure 8. IP prefix/address anchor switching to the new network. MN 1336 with flow using IP1 in Net1 continues to run the flow using IP1 as it 1337 moves to Net2. 1339 As an MN with an ongoing session moves to a new network, the flow may 1340 preserve IP session continuity by moving the anchoring of the 1341 original IP prefix/address of the flow to the new network. BGP 1342 UPDATE messages may be used to change the forwarding table entries as 1343 described in [I-D.templin-aerolink] and [I-D.mccann-dmm-flatarch] if 1344 the response time of such updates does not exceed the handover delay 1345 requirement of the flow. An alternative is to use a centralized 1346 routing protocol to be described in Section 5.2 with a centralized 1347 control plane. 1349 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network 1351 The configuration guideline for a flat network or network slice 1352 supporting a mix of flows requiring and not requiring IP mobility 1353 support is: 1355 GL-cfg:3 Multiple instances of DPAs (at access routers) which are 1356 providing IP prefix to the MNs are needed to provide 1357 distributed mobility anchoring according to Figure 1(a) or 1358 Figure 1(b)in Section 3.1 for a flat network. 1360 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1361 the mobility functions LM and FM as described respectively 1362 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1364 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1365 IPv6 nodes for a network or network slice supporting a mix of flows 1366 requiring and not requiring IP mobility support apply here. In 1367 addition, the following are required. 1369 GL-switch:1 The location management provides information about which 1370 IP prefix from an AR in the original network is being 1371 used by a flow in which AR in a new network. Such 1372 information needs to be deleted or updated when such 1373 flows have closed so that the IP prefix is no longer 1374 used in a different network. The LM operations are 1375 described in Section 3.2.1. 1377 GL-switch:2 The FM functions are implemented through the DHCPv6-PD 1378 protocol. Here the anchor operations to properly 1379 forward the packets for a flow as described in the FM 1380 operations and mobility message parameters in 1381 Section 3.2.2 FM-path, FM-path-tbl, FM-DPA, FM-DPA-tbl 1382 are realized by changing the anchor with DHCPv6-PD and 1383 also by reverting such changes later after the 1384 application has already closed and when the DHCPv6-PD 1385 timer expires. If there are in-flight packets toward 1386 the old anchor while the MN is moving to the new anchor, 1387 it may be necessary to buffer these packets and then 1388 forward to the new anchor after the old anchor knows 1389 that the new anchor is ready as are described in 1390 Section 3.2.2 (FM-buffer). The anchors may also need to 1391 discover each other as described also in the FM 1392 operations and mobility message parameters (FM-find). 1394 GL-switch:3 The security management function in the anchor node at a 1395 new network must allow to assign the original IP prefix/ 1396 address used by the mobile node at the previous 1397 (original) network. As the assigned original IP prefix/ 1398 address is to be used in the new network, the security 1399 management function in the anchor node must allow to 1400 advertise the prefix of the original IP address and also 1401 allow the mobile node to send and receive data packets 1402 with the original IP address. 1404 GL-switch:4 The security management function in the mobile node must 1405 allow to configure the original IP prefix/address used 1406 at the previous (original) network when the original IP 1407 prefix/address is assigned by the anchor node in the new 1408 network. The security management function in the mobile 1409 node also allows to use the original IP address for the 1410 previous flow in the new network. 1412 5.2. IP Prefix/Address Anchor Switching for Flat Network with 1413 Centralized Control Plane 1415 An example of IP prefix anchor switching is in the case where Net1 1416 and Net2 both belong to the same operator network with separation of 1417 control and data planes ([I-D.liu-dmm-deployment-scenario] and 1418 [I-D.matsushima-stateless-uplane-vepc]), where the controller may 1419 send to the switches/routers the updated information of the 1420 forwarding tables with the IP address anchoring of the original IP 1421 prefix/address at AR1 moved to AR2 in the new network. That is, the 1422 IP address anchoring in the original network which was advertising 1423 the prefix will need to move to the new network. As the anchoring in 1424 the new network advertises the prefix of the original IP address in 1425 the new network, the forwarding tables will be updated so that 1426 packets of the flow will be forwarded according to the updated 1427 forwarding tables. The configurations in Figures 1(a) and 1(b) in 1428 Section 3.1 for which FM-CP and LM are centralized and FM-DP's are 1429 distributed apply here. Figure 9 shows its implementation where LM 1430 is a binding between the original IP prefix/address of the flow and 1431 the IP address of the new DPA, whereas FM uses the DHCPv6-PD 1432 protocol. 1434 Net1 Net2 1435 +----------------------------------------------------------------------+ 1436 | CPA: | 1437 | LM:IP1<-->IPa2 | 1438 | FM-CP | 1439 +----------------------------------------------------------------------+ 1441 +---------------+ +---------------+ 1442 |AR1 | |AR2 | 1443 +---------------+ +---------------+ 1444 |DPA(IPa1): | |DPA(IPa2): | 1445 |anchors IP1 | move |anchors IP2,IP1| 1446 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 1447 +---------------+ +---------------+ 1449 +...............+ +---------------+ 1450 .MN(IP1) . move |MN(IP2,IP1) | 1451 .flow(IP1,...) . =======> |flow(IP1,...) | 1452 +...............+ +---------------+ 1454 Figure 9. IP prefix/address anchor switching to the new network with 1455 with LM and FM-CP in a centralized control plane whereas the FM-DP's 1456 are distributed. 1458 The example call flow in Figure 10 shows that MN is allocated HNP1 1459 when it attaches to the p-AR. A flow running in MN and needing IP 1460 mobility may continue to use the previous IP prefix by moving the 1461 anchoring of the IP prefix to the new network. Yet a new flow to be 1462 initiated in the new network may simply use a new IP prefix allocated 1463 from the new network. 1465 MN p-AR n-AR DHCPv6 Servers CN 1466 |MN attaches to p-AR: | | | | 1467 |acquire MN-ID and profile | | | 1468 |--RS---------------->| | | | 1469 |<----------RA(HNP1)--| | | | 1470 | | | Allocate MN-HNP1 | 1471 IP addr config | | | | 1472 | | | | | 1473 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1474 | | | | | 1475 |MN detach from p-AR | | | | 1476 |MN attach to n-AR | | | | 1477 | | | | | 1478 |--RS------------------------------>| | | 1479 | | | | | 1480 | |------DHCPv6 release-------------->| | 1481 | | | | | 1482 | | |--DHCPv6 PD request->| | 1483 | | |<-DHCPv6 PD reply--->| | 1484 | | | | | 1485 | forwarding table updates | | 1486 | | | | | 1487 |<--------------RA(HNP2,HNP1)-------| | | 1488 | | | Allocate MN-HNP2 | 1489 IP addr config | | | | 1490 | | | | | 1491 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1492 | | | | | 1493 | Flow(IP1,IPcn,...) terminates | | | 1494 | | | | | 1495 | | DHCPv6-PD timeout | | 1496 | | | | | 1497 | forwarding table updates | | 1498 | | | | | 1499 | | | | | 1500 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1501 | | | | | 1503 Figure 10. DMM solution. MN with flow using IP1 in Net1 continues 1504 to run the flow using IP1 as it moves to Net2. 1506 As the MN moves from p-AR to n-AR, the p-AR as a DHCPv6 client may 1507 send a DHCPv6 release message to release the HNP1. It is now 1508 necessary for n-AR to learn the IP prefix of the MN from the previous 1509 network so that it will be possible for Net2 to allocate both the 1510 previous network prefix and the new network prefix. The network may 1511 learn the previous prefix in different methods. For example, the MN 1512 may provide its previous network prefix information by including it 1513 to the RS message [I-D.jhlee-dmm-dnpp]. 1515 Knowing that MN is using HNP1, the n-AR sends to a DHCPv6 server a 1516 DHCPv6-PD request to move the HNP1 to n-AR. The server sends to n-AR 1517 a DHCPv6-PD reply to move the HNP1. Then forwarding tables updates 1518 will take place here. 1520 In addition, the MN also needs a new HNP in the new network. The 1521 n-AR may now send RA to n-AR, with prefix information that includes 1522 HNP1 and HNP2. The MN may then continue to use IP1. In addition, 1523 the MN is allocated the prefix HNP2 with which it may configure its 1524 IP addresses. Now for flows using IP1, packets destined to IP1 will 1525 be forwarded to the MN via n-AR. 1527 As such flows have terminated and DHCPv6-PD has timed out, HNP1 goes 1528 back to Net1. MN will then be left with HNP2 only, which it will use 1529 when it now starts a new flow. 1531 5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1532 Centralized CP 1534 The configuration guideline for a flat network or network slice with 1535 centralized control plane and supporting a mix of flows requiring and 1536 not requiring IP mobility support is: 1538 GL-cfg:4 Multiple instances of DPAs (at access routers) which are 1539 providing IP prefix to the MNs are needed to provide 1540 distributed mobility anchoring according to Figure 1(a) or 1541 Figure 1(b)in Section 3.1 with centralized control plane 1542 for a flat network. 1544 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1545 the mobility functions LM and FM as described respectively 1546 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1548 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1549 IPv6 nodes for a network or network slice supporting a mix of flows 1550 requiring and not requiring IP mobility support apply here. The 1551 guidelines (GL-mix) in Section 5.1.1 also apply here. In addition, 1552 the following are required. 1554 GL-switch:5 The anchor operations to properly forward the packets 1555 for a flow as described in the FM operations and 1556 mobility message parameters in Section 3.2.2 FM-path, 1557 FM-path-tbl, FM-DPA, FM-DPA-tbl is realized by changing 1558 the anchoring with DHCPv6-PD and undoing such changes 1559 later when its timer expires and the application has 1560 already closed. With the anchors being separated in 1561 control and data planes with LMs and FM-CP centralized 1562 in the same control plane, messaging between anchors and 1563 the discovery of anchors become internal to the control 1564 plane as described in Section 3.2.2 FM-cpdp. However, 1565 the centralized FM-CP needs to communicate with the 1566 distributed FM-DP as described as described in the FM 1567 operations and mobility message parameters (FM-find). 1568 Such may be realized by the appropriate messages in 1569 [I-D.ietf-dmm-fpc-cpdp]. 1571 GL-switch:6 It was already mentioned before that, if there are in- 1572 flight packets toward the old anchor while the MN is 1573 moving to the new anchor, it may be necessary to buffer 1574 these packets and then forward to the new anchor after 1575 the old anchor knows that the new anchor is ready Here, 1576 however, the corresponding FM operations and mobility 1577 message parameters as described in Section 3.2.2 (FM- 1578 buffer) can be realized by the internal operations in 1579 the control plane together with signaling between the 1580 control plane and distributed data plane. These 1581 signaling may be realized by the appropriate messages in 1582 [I-D.ietf-dmm-fpc-cpdp]. 1584 5.3. IP Prefix/Address Anchor Switching for a Hierarchical Network 1586 The configuration for a hierarchical network is shown in Figures 1(c) 1587 and 1(d) in Section 3.1. With centralized control plane, CPA and 1588 CPN, with the associated LM and FM-CP are all co-located. There are 1589 multiple DPAs (each with FM-DP) in distributed mobility anchoring. 1590 In the data plane, there are multiple DPNs (each with FM-DP) 1591 hierarchically below each DPA. The DPA at each AR supports 1592 forwarding to the DPN at each of a number of forwarding switches 1593 (FW's). A mobility event in this configuration belonging to 1594 distributed mobility management will be deferred to Section 5.4. 1596 In this distributed mobility configuration, a mobility event 1597 involving change of FW only but not of AR as shown in Figure 11 may 1598 still belong to centralized mobility management and may be supported 1599 using PMIPv6. This configuration of network-based mobility is also 1600 applicable to host-based mobility with the modification for the MN 1601 directly taking the role of DPN and CPN, and the corresponding 1602 centralized mobility event may be supported using MIPv6. 1604 In Figure 11, the IP prefix allocated to the MN is anchored at the 1605 access router (AR) supporting indirection to the old FW to which the 1606 MN was originally attached as well as to the new FW to which the MN 1607 has moved. 1609 The realization of LM may be the binding between the IP prefix/ 1610 address of the flow used by the MN and the IP address of the DPN to 1611 which MN has moved. The implementation of FM to enable change of FW 1612 without changing AR may be accomplished using tunneling between the 1613 AR and the FW as described in [I-D.korhonen-dmm-local-prefix] and in 1614 [I-D.templin-aerolink] or using some other L2 mobility mechanism. 1616 Net1 Net2 1617 +----------------------------------------------------------------------+ 1618 | CPA,CPN: | 1619 | LM:IP1<-->IPn2 | 1620 | FM-CP | 1621 +----------------------------------------------------------------------+ 1623 +---------------+ 1624 |AR1 | 1625 +---------------+ 1626 |DPA(IPa1): | 1627 |anchors IP1 | 1628 |FM:DHCPv6-PD | 1629 +---------------+ 1631 +---------------+ +---------------+ 1632 |FW1 | |FW2 | 1633 +---------------+ move +---------------+ 1634 |DPN(IPn1): | =======> |DPN(IPn2): | 1635 +---------------+ +---------------+ 1637 +...............+ +---------------+ 1638 .MN(IP1) . move |MN(IP2) | 1639 .flow(IP1,...) . =======> |flow(IP1,...) | 1640 +...............+ +---------------+ 1642 Figure 11. Mobility without involving change of IP anchoring in a 1643 network in which the IP prefix allocated to the MN is anchored at an 1644 AR which is hierarchically above multiple FWs to which the MN may 1645 connect. 1647 5.3.1. Additional Guidelines for IPv6 Nodes: No Anchoring Change with a 1648 Hierarchical Network 1650 The configuration guideline ( ) for a hierarchical network or network 1651 slice with centralized control plane and supporting a mix of flows 1652 requiring and not requiring IP mobility support is: 1654 GL-cfg:5 Multiple instances of DPAs (at access routers) which are 1655 providing IP prefix to the MNs are needed to provide 1656 distributed mobility anchoring according to Figure 2(a) or 1657 Figure 2(b)in Section 3.1.2 with centralized control plane 1658 for a hierarchical network. 1660 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1661 the mobility functions LM and FM as described respectively 1662 in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. 1664 Even when the mobility event does not involve change of anchor, it is 1665 still necessary to distinguish whether a flow needs IP mobility 1666 support. 1668 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1669 IPv6 nodes for a network or network slice supporting a mix of flows 1670 requiring and not requiring IP mobility support apply here. The 1671 guidelines (GL-switch) in Section 5.1.1 and in Section 5.2.1 also 1672 apply here. In addition, the following are required. 1674 GL-switch:7 Here, the LM operations and mobility message parameters 1675 described in Section 3.2.1 provides information of which 1676 IP prefix from its FW needs to be used by a flow using 1677 which new FW. The anchor operations to properly forward 1678 the packets of a flow described in the FM operations and 1679 mobility message parameters (FM-path, FM-path-ind, FM- 1680 cpdp in Section 3.2.2) may be realized with PMIPv6 1681 protocol ([I-D.korhonen-dmm-local-prefix]) or with AERO 1682 protocol ([I-D.templin-aerolink]) to tunnel between the 1683 AR and the FW. 1685 5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network 1687 The configuration for the hierarchical network is again shown in 1688 Figures 1(c) and 1(d) in Section 3.1. Again, with centralized 1689 control plane, CPA and CPN, with the associated LM and FM-CP are all 1690 co-located. There are multiple DPAs (each with FM-DP) in distributed 1691 mobility anchoring. In the data plane, there are multiple DPNs (each 1692 with FM-DP) hierarchically below each DPA. The DPA at each AR 1693 supports forwarding to the DPN at each of a number of forwarding 1694 switches (FW's). 1696 A distributed mobility event in this configuration involves change 1697 from a previous DPN which is hierarchically under the previous DPA to 1698 a new DPN which is hierarchically under a new DPA. Such an event 1699 involving change of both DPA and DPN is shown in Figure 12. 1701 Net1 Net2 1702 +----------------------------------------------------------------------+ 1703 | CPA,CPN: | 1704 | LM:IP1<-->IPa2,IPn2 | 1705 | FM-CP | 1706 +----------------------------------------------------------------------+ 1708 +---------------+ 1709 |Aggregate Point| 1710 |---------------| 1711 |FM, LM | 1712 +---------------+ 1714 +---------------+ +---------------+ 1715 |AR1 | |AR2 | 1716 +---------------+ +---------------+ 1717 |DPA(IPa1): | |DPA(IPa2): | 1718 |anchors IP1 | move |anchors IP2,IP1| 1719 |FM:DHCPv6-PD | =======> |FM:DHCPv6-PD | 1720 +---------------+ +---------------+ 1722 +---------------+ +---------------+ 1723 |FW1 | |FW2 | 1724 +---------------+ move +---------------+ 1725 |DPN(IPn1): | =======> |DPN(IPn2): | 1726 +---------------+ +---------------+ 1728 +...............+ +---------------+ 1729 .MN(IP1) . move |MN(IP2,IP1) | 1730 .flow(IP1,...) . =======> |flow(IP1,...) | 1731 +...............+ +---------------+ 1733 Figure 12. Mobility involving change of IP anchoring in a network 1734 with hierarchy in which the IP prefix allocated to the MN is anchored 1735 at an Edge Router supporting multiple access routers to which the MN 1736 may connect. 1738 This deployment case involves both a change of anchor from AR1 to AR2 1739 and a network hierarchy AR-FW. It can be realized by a combination 1740 of changing the IP prefix/address anchoring from AR1 to AR2 with the 1741 mechanism as described in Section 5.2 and then forwarding the packets 1742 with network hierarchy AR-FW as described in Section 5.3. 1744 To change AR, AR1 acting as a DHCPv6-PD client may exchange message 1745 with the DHCPv6 server to release the prefix IP1. Meanwhile, AR2 1746 acting as a DHCPv6-PD client may exchange message with the DHCPv6 1747 server to delegate the prefix IP1 to AR2. 1749 5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1750 Hierarchical Network 1752 The configuration guideline (GL-cfg) for a hierarchical network or 1753 network slice with centralized control plane described in 1754 Section 5.3.1 apply here. 1756 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1757 IPv6 nodes for a network or network slice supporting a mix of flows 1758 requiring and not requiring IP mobility support apply here. 1760 The guidelines (GL-switch) in Section 5.1.1 and in Section 5.2.1 also 1761 apply here to change the anchoring of the IP prefix/address with a 1762 centralized control plane. 1764 In addition, the guideline for indirection between the new DPA and 1765 the new DPN as described in Section 5.3.1 apply here. 1767 6. Security Considerations 1769 TBD 1771 7. IANA Considerations 1773 This document presents no IANA considerations. 1775 8. Contributors 1777 This document has benefited from other work on mobility solutions 1778 using BGP update, on mobility support in SDN network, on providing 1779 mobility support only when needed, and on mobility support in 1780 enterprise network. These work have been referenced. While some of 1781 these authors have taken the work to jointly write this document, 1782 others have contributed at least indirectly by writing these drafts. 1783 The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, 1784 Peter McCann, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. 1786 Valuable comments have also been received from John Kaippallimalil, 1787 ChunShan Xiong, and Dapeng Liu. 1789 9. References 1791 9.1. Normative References 1793 [I-D.ietf-dmm-deployment-models] 1794 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1795 Architectural Considerations", draft-ietf-dmm-deployment- 1796 models-00 (work in progress), August 2016. 1798 [I-D.ietf-dmm-fpc-cpdp] 1799 Liebsch, M., Matsushima, S., Gundavelli, S., Moses, D., 1800 and L. Bertz, "Protocol for Forwarding Policy 1801 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-03 1802 (work in progress), March 2016. 1804 [I-D.ietf-dmm-ondemand-mobility] 1805 Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On 1806 Demand Mobility Management", draft-ietf-dmm-ondemand- 1807 mobility-07 (work in progress), July 2016. 1809 [I-D.jhlee-dmm-dnpp] 1810 Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", 1811 draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. 1813 [I-D.korhonen-dmm-local-prefix] 1814 Korhonen, J., Savolainen, T., and S. Gundavelli, "Local 1815 Prefix Lifetime Management for Proxy Mobile IPv6", draft- 1816 korhonen-dmm-local-prefix-01 (work in progress), July 1817 2013. 1819 [I-D.liu-dmm-deployment-scenario] 1820 Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, 1821 "Distributed mobility management deployment scenario and 1822 architecture", draft-liu-dmm-deployment-scenario-05 (work 1823 in progress), October 2015. 1825 [I-D.matsushima-stateless-uplane-vepc] 1826 Matsushima, S. and R. Wakikawa, "Stateless user-plane 1827 architecture for virtualized EPC (vEPC)", draft- 1828 matsushima-stateless-uplane-vepc-06 (work in progress), 1829 March 2016. 1831 [I-D.mccann-dmm-flatarch] 1832 McCann, P., "Authentication and Mobility Management in a 1833 Flat Architecture", draft-mccann-dmm-flatarch-00 (work in 1834 progress), March 2012. 1836 [I-D.mccann-dmm-prefixcost] 1837 McCann, P. and J. Kaippallimalil, "Communicating Prefix 1838 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 1839 (work in progress), April 2016. 1841 [I-D.seite-dmm-dma] 1842 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 1843 Anchoring", draft-seite-dmm-dma-07 (work in progress), 1844 February 2014. 1846 [I-D.sijeon-dmm-deployment-models] 1847 Jeon, S. and Y. Kim, "Deployment Models for Distributed 1848 Mobility Management", draft-sijeon-dmm-deployment- 1849 models-03 (work in progress), July 2016. 1851 [I-D.templin-aerolink] 1852 Templin, F., "Asymmetric Extended Route Optimization 1853 (AERO)", draft-templin-aerolink-71 (work in progress), 1854 September 2016. 1856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1857 Requirement Levels", BCP 14, RFC 2119, 1858 DOI 10.17487/RFC2119, March 1997, 1859 . 1861 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 1862 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 1863 . 1865 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1866 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1867 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1868 . 1870 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1871 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1872 2011, . 1874 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 1875 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 1876 RFC 7077, DOI 10.17487/RFC7077, November 2013, 1877 . 1879 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1880 Korhonen, "Requirements for Distributed Mobility 1881 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1882 . 1884 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1885 CJ. Bernardos, "Distributed Mobility Management: Current 1886 Practices and Gap Analysis", RFC 7429, 1887 DOI 10.17487/RFC7429, January 2015, 1888 . 1890 9.2. Informative References 1892 [Paper-Distributed.Mobility] 1893 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 1894 IP Mobility Management from the Perspective of the IETF: 1895 Motivations, Requirements, Approaches, Comparison, and 1896 Challenges", IEEE Wireless Communications, October 2013. 1898 [Paper-Distributed.Mobility.PMIP] 1899 Chan, H., "Proxy Mobile IP with Distributed Mobility 1900 Anchors", Proceedings of GlobeCom Workshop on Seamless 1901 Wireless Mobility, December 2010. 1903 [Paper-Distributed.Mobility.Review] 1904 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 1905 "Distributed and Dynamic Mobility Management in Mobile 1906 Internet: Current Approaches and Issues", February 2011. 1908 Authors' Addresses 1910 H Anthony Chan (editor) 1911 Huawei Technologies 1912 5340 Legacy Dr. Building 3 1913 Plano, TX 75024 1914 USA 1916 Email: h.a.chan@ieee.org 1918 Xinpeng Wei 1919 Huawei Technologies 1920 Xin-Xi Rd. No. 3, Haidian District 1921 Beijing, 100095 1922 P. R. China 1924 Email: weixinpeng@huawei.com 1925 Jong-Hyouk Lee 1926 Sangmyung University 1927 31, Sangmyeongdae-gil, Dongnam-gu 1928 Cheonan 31066 1929 Republic of Korea 1931 Email: jonghyouk@smu.ac.kr 1933 Seil Jeon 1934 Sungkyunkwan University 1935 2066 Seobu-ro, Jangan-gu 1936 Suwon, Gyeonggi-do 1937 Republic of Korea 1939 Email: seiljeon@skku.edu 1941 Alexandre Petrescu 1942 CEA, LIST 1943 CEA Saclay 1944 Gif-sur-Yvette, Ile-de-France 91190 1945 France 1947 Phone: +33169089223 1948 Email: Alexandre.Petrescu@cea.fr 1950 Fred L. Templin 1951 Boeing Research and Technology 1952 P.O. Box 3707 1953 Seattle, WA 98124 1954 USA 1956 Email: fltemplin@acm.org