idnits 2.17.1 draft-ietf-dmm-distributed-mobility-anchoring-03.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 (December 14, 2016) is 2662 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-05 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-09 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-74 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: June 17, 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 December 14, 2016 15 Distributed Mobility Anchoring 16 draft-ietf-dmm-distributed-mobility-anchoring-03 18 Abstract 20 This document defines distributed mobility anchoring in terms of the 21 different configurations, operations and parameters of mobility 22 functions to provide different IP mobility support for the diverse 23 mobility needs in 5G Wireless and beyond. A network or network slice 24 may be configured with distributed mobility anchoring functions 25 according to the needs of mobility support. In the distributed 26 mobility anchoring environment, multiple anchors are available for 27 mid-session switching of an IP prefix anchor. To start a new flow or 28 to handle a flow not requiring IP session continuity as a mobile node 29 moves to a new network, the flow can be started or re-started using a 30 new IP prefix which is allocated from and is therefore anchored to 31 the new network. For a flow requiring IP session continuity, the 32 anchoring of the prior IP prefix may be moved to the new network. 33 The mobility functions and their operations and parameters are 34 general for different configurations. The mobility signaling may be 35 between anchors and nodes in the network in a network-based mobility 36 solution. It may also be between the anchors and the mobile node in 37 a host-based solution. The mobile node may be a host, but may also 38 be a router carrying a network requiring network mobility support. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on June 17, 2017. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 76 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 7 77 3.1. Configurations for Different Networks or Network Slices . 7 78 3.1.1. Network-based Mobility Support for a Flat Network . . 7 79 3.1.2. Network-based Mobility Support for a Hierarchical 80 Network . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.1.3. Host-based Mobility Support . . . . . . . . . . . . . 11 82 3.1.4. NEtwork MObility (NEMO) Basic Support . . . . . . . . 13 83 3.2. Operations and Parameters . . . . . . . . . . . . . . . . 15 84 3.2.1. Location Management . . . . . . . . . . . . . . . . . 16 85 3.2.2. Forwarding Management . . . . . . . . . . . . . . . . 18 86 4. IP Mobility Handling in Distributed Anchoring Environments - 87 Mobility Support Only When Needed . . . . . . . . . . . . . . 26 88 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 27 89 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP 90 Prefix/Address . . . . . . . . . . . . . . . . . . . 29 91 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 30 92 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility . . . 31 93 5. IP Mobility Handling in Distributed Mobility Anchoring 94 Environments - Anchor Switching to the New Network . . . . . 33 95 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 33 96 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat 97 Network . . . . . . . . . . . . . . . . . . . . . . . 34 99 5.2. IP Prefix/Address Anchor Switching for Flat Network with 100 Centralized Control Plane . . . . . . . . . . . . . . . . 36 101 5.2.1. Additional Guidelines for IPv6 Nodes: Switching 102 Anchor with Centralized CP . . . . . . . . . . . . . 38 103 5.3. Hierarchical Network . . . . . . . . . . . . . . . . . . 39 104 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical 105 Network with No Anchor Relocation . . . . . . . . . . 41 106 5.4. IP Prefix/Address Anchor Switching for a Hierarchical 107 Network . . . . . . . . . . . . . . . . . . . . . . . . . 42 108 5.4.1. Additional Guidelines for IPv6 Nodes: Switching 109 Anchor with Hierarchical Network . . . . . . . . . . 44 110 5.5. Network Mobility . . . . . . . . . . . . . . . . . . . . 44 111 5.5.1. Additional Guidelines for IPv6 Nodes: Network 112 mobility . . . . . . . . . . . . . . . . . . . . . . 46 113 6. Security Considerations . . . . . . . . . . . . . . . . . . . 47 114 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 115 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 116 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 117 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 118 9.2. Informative References . . . . . . . . . . . . . . . . . 50 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 121 1. Introduction 123 A key requirement in distributed mobility management [RFC7333] is to 124 enable traffic to avoid traversing a single mobility anchor far from 125 an optimal route. Distributed mobility management solutions do not 126 rely on a centrally deployed mobility anchor in the data plane 127 [Paper-Distributed.Mobility]. As such, the traffic of a flow SHOULD 128 be able to change from traversing one mobility anchor to traversing 129 another mobility anchor as a mobile node (MN) moves, or when changing 130 operation and management requirements call for mobility anchor 131 switching, thus avoiding non-optimal routes. 133 Companion distributed mobility management documents are already 134 addressing the architecture and deployment 135 [I-D.ietf-dmm-deployment-models], source address selection 136 [I-D.ietf-dmm-ondemand-mobility], and control-plane data-plane 137 signaling [I-D.ietf-dmm-fpc-cpdp]. Yet in 5G Wireless and beyond, 138 the mobility requirements are diverse, and IP mobility support is no 139 longer by default with a one-size-fit-all solution. In different 140 networks or network slices, different kinds of mobility support are 141 possible depending on the needs. It may not always be obvious on how 142 to best configure and use only the needed mobility functions to 143 provide the specific mobility support. This draft defines different 144 configurations, functional operations and parameters for distributed 145 mobility anchoring and explains how to use them to make the route 146 changes to avoid unnecessarily long routes. 148 Distributed mobility anchoring employs multiple anchors in the data 149 plane. In general, control plane functions may be separate from data 150 plane functions and be centralized but may also be co-located with 151 the data plane functions at the distributed anchors. Different 152 configurations of distributed mobility anchoring are described in 153 Section 3.1. For instance, the configurations for network-based 154 mobility support in a flat network, for network-based mobility 155 support in a hierarchical network, for host-based mobility support, 156 and for NEtwork MObility (NEMO) basic support are described 157 respectively in Section 3.1.1, Section 3.1.2, Section 3.1.3 and 158 Section 3.1.4. Required operations and parameters for distributed 159 mobility anchoring are presented in Section 3.2. For instance, 160 location management is described in Section 3.2.1, forwarding 161 management is described in Section 3.2.2. 163 An MN attached to an access router of a network or network slice may 164 be allocated an IP prefix which is anchored to that router. It may 165 then use an IP address configured from this prefix as the source IP 166 address to run a flow with its correspondent node (CN). When there 167 are multiple mobility anchors, an address selection for a given flow 168 is first required before the flow is initiated. Using an anchor in 169 an MN's network of attachment has the advantage that the packets can 170 simply be forwarded according to the forwarding table. Although the 171 anchor is in the MN's network of attachment when the flow was 172 initiated, the MN may later move to another network, so that the IP 173 no longer belongs to the current network of attachment of the MN. 175 Whether the flow needs IP session continuity will determine how to 176 ensure that the IP address of the flow will be anchored to the new 177 network of attachment. If the ongoing IP flow can cope with an IP 178 prefix/address change, the flow can be reinitiated with a new IP 179 address anchored in the new network as shown in Section 4.1. On the 180 other hand, if the ongoing IP flow cannot cope with such change, 181 mobility support is needed as shown in Section 4.2. A network or 182 network slice supporting a mix of flows requiring and not requiring 183 IP mobility support will need to distinguish these flows. The 184 guidelines for such network or network slice are described in 185 Section 4.1.1. The general guidelines for such network or network 186 slice to provide IP mobility support are described in Section 4.2.1. 188 Specifically, IP mobility support can be provided by relocating the 189 anchoring of the IP prefix/address of the flow from the home network 190 of the flow to the new network of attachment. The basic case may be 191 with network-based mobility for a flat network configuration 192 described in Section 5.1 with the guidelines described in 193 Section 5.1.1. This case is discussed further with a centralized 194 control plane in Section 5.2 with additional guidelines described in 195 Section 5.2.1. A level of hierarchy of nodes may then be added to 196 the network configuration. Mobility involving change in the Data 197 Plane Node (DPN) without changing the Data Plane Anchor (DPA) is 198 described in Section 5.3 with additional guidelines described in 199 Section 5.3.1 Mobility involving change in the DPN without changing 200 the DPA is described in Section 5.4 with additional guidelines 201 described in Section 5.4.1 203 2. Conventions and Terminology 205 The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 All general mobility-related terms and their acronyms used in this 210 document are to be interpreted as defined in the Mobile IPv6 (MIPv6) 211 base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) 212 specification [RFC5213], the "Mobility Related Terminologies" 213 [RFC3753], and the DMM current practices and gap analysis [RFC7429]. 214 These include terms such as mobile node (MN), correspondent node 215 (CN), home agent (HA), home address (HoA), care-of-address (CoA), 216 local mobility anchor (LMA), and mobile access gateway (MAG). 218 In addition, this document uses the following terms: 220 Home network of an application session or a home address: the 221 network that has allocated the HoA used for the session identifier 222 by the application running in an MN. The MN may be running 223 multiple application sessions, and each of these sessions can have 224 a different home network. 226 IP prefix/address anchoring: An IP prefix, i.e., Home Network Prefix 227 (HNP), or address, i.e., HoA, allocated to an MN is topologically 228 anchored to an anchor node when the anchor node is able to 229 advertise a connected route into the routing infrastructure for 230 the allocated IP prefix. 232 Location Management (LM) function: managing and keeping track of the 233 internetwork location of an MN. The location information may be a 234 binding of the IP advertised address/prefix, e.g., HoA or HNP, to 235 the IP routing address of the MN or of a node that can forward 236 packets destined to the MN. 238 When the MN is a mobile router (MR) carrying a mobile network of 239 mobile network nodes (MNN), the location information will also 240 include the mobile network prefix (MNP), which is the IP prefix 241 delegated to the MR. The MNP is allocated to the MNNs in the 242 mobile network. 244 LM is a control plane function. 246 In a client-server protocol model, location query and update 247 messages may be exchanged between a Location Management client 248 (LMc) and a Location Management server (LMs). 250 Optionally, there may be a Location Management proxy (LMp) between 251 LMc and LMs. 253 With separation of control plane and data plane, the LM function 254 is in the control plane. It may be a logical function at the 255 control plane node, control plane anchor, or mobility controller. 257 It may be distributed or centralized. 259 Forwarding Management (FM) function: packet interception and 260 forwarding to/from the IP address/prefix assigned to the MN, based 261 on the internetwork location information, either to the 262 destination or to some other network element that knows how to 263 forward the packets to their destination. 265 This function may be used to achieve traffic indirection. With 266 separation of control plane and data plane, the FM function may 267 split into a FM function in the data plane (FM-DP) and a FM 268 function in the control plane (FM-CP). 270 FM-DP may be distributed with distributed mobility management. It 271 may be a function in a data plane anchor or data plane node. 273 FM-CP may be distributed or centralized. It may be a function in 274 a control plane node, control plane anchor or mobility controller. 276 Security Management (SM) function: The security management function 277 controls security mechanisms/protocols providing access control, 278 integrity, authentication, authorization, confidentiality, etc. 279 for the control plane and data plane. 281 This function resides in all nodes such as control plane anchor, 282 data plane anchor, mobile node, and correspondent node. 284 3. Distributed Mobility Anchoring 286 3.1. Configurations for Different Networks or Network Slices 288 The mobility functions may be implemented in different configurations 289 of distributed mobility anchoring in architectures separating the 290 control and data planes. The separation described in 291 [I-D.ietf-dmm-deployment-models] has defined the home control plane 292 anchor (Home-CPA), home data plane anchor (Home-DPA), access control 293 plane node (Access-CPN), and access data plane node (Access-DPN), 294 which are respectively abbreviated as CPA, DPA, CPN, and DPN here. 296 Different networks or different network slices may have different 297 configurations in distributed mobility anchoring. 299 The configurations also differ depending on the desired mobility 300 supports: network-based mobility support for a flat network in 301 Section 3.1.1, network-based mobility support for a hierarchical 302 network in Section 3.1.2, host-based mobility support in 303 Section 3.1.3, and NEtwork MObility (NEMO) based support in 304 Section 3.1.4. 306 3.1.1. Network-based Mobility Support for a Flat Network 308 Figure 1 shows two different configurations of network-based mobility 309 management for a flat network. 311 (a) (b) 312 +-----+ 313 |LMs | 314 +-----+ 316 +------------+ +------------+ 317 |CPA: | |CPA: | 318 |FM-CP, LM | |FM-CP, LMc | 319 +------------+ +------------+ 320 +------------+ +------------+ +------------+ +------------+ 321 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 322 |anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... 323 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 324 +------------+ +------------+ +------------+ +------------+ 326 +------------+ +------------+ 327 |MN(IP1) | |MN(IP1) | 328 |flow(IP1,..)| |flow(IP1,..)| 329 +------------+ +------------+ 331 Figure 1. Configurations of network-based mobility management for a 332 flat network (a) FM-CP and LM at CPA, FM-DP at DPA; (b) Separate LMs, 333 FM-CP and LMc at CPA, FM-DP at DPA. 335 Figure 1 also shows a distributed mobility anchoring environment with 336 multiple instances of the DPA. 338 There is an FM-DP function at each of the distributed DPA. 340 The control plane may either be distributed (not shown) or 341 centralized. When the CPA co-locates with the distributed DPA there 342 will be multiple instances of the co-located CPA and DPA (not shown). 344 There is an FM-CP function at the CPA. 346 An MN is allocated an IP prefix/address IP1 which is anchored to the 347 DPA with the IP prefix/address IPa1. The MN uses IP1 to communicate 348 with a CN not shown in the figure. The flow of this communication 349 session is shown as flow(IP1, ...) which uses IP1 and other 350 parameters. 352 In Figure 1(a), LM and FM-CP co-locate at CPA. 354 Then LM may be distributed or centralized according to whether the 355 CPA is distributed (not shown) or centralized. 357 Figure 1(b) differs from Figure 1(a) in that the LM function is split 358 into a server LMs and a client LMc. 360 LMc and FM-CP co-locate at the CPA. 362 The LMs may be centralized whereas the LMc may be distributed or 363 centralized according to whether the CPA is distributed (not shown) 364 or centralized. 366 3.1.2. Network-based Mobility Support for a Hierarchical Network 368 Figure 2 shows two different configurations of network-based mobility 369 management for a hierarchical network. 371 (a) 372 +------------+ 373 |CPA: | 374 |FM-CP, LMs | 375 +------------+ 376 +------------+ +------------+ 377 |DPA(IPa1): | |DPA(IPa2): | 378 |anchors IP1 | |anchors IP2 | ... 379 |FM-DP | |FM-DP | 380 +------------+ +------------+ 382 +------------+ 383 |CPN: | 384 |FM-CP, LMc | 385 +------------+ 386 +------------+ +------------+ +------------+ +------------+ 387 |DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) | 388 |FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ... 389 +------------+ +------------+ +------------+ +------------+ 391 +------------+ +------------+ 392 |MN(IP1) | |MN(IP2) | 393 |flow(IP1,..)| |flow(IP2,..)| 394 +------------+ +------------+ 396 Figure 2(a). Configurations of network-based mobility management for 397 a hierarchical network with FM-CP and LMs at CPA, FM-DP at DPA; FM-CP 398 and LMc at CPN, FM-DP at DPN. 400 (b) 401 +-----+ 402 |LMs | 403 +-----+ 405 +------------+ 406 |CPA: | 407 |FM-CP, LMp | 408 +------------+ 409 +------------+ +------------+ 410 |DPA(IPa1): | |DPA(IPa2): | 411 |anchors IP1 | |anchors IP2 | ... 412 |FM-DP | |FM-DP | 413 +------------+ +------------+ 415 +------------+ 416 |CPN: | 417 |FM-CP, LMc | 418 +------------+ 419 +------------+ +------------+ +------------+ +------------+ 420 |DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) | 421 |FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ... 422 +------------+ +------------+ +------------+ +------------+ 424 +------------+ +------------+ 425 |MN(IP1) | |MN(IP2) | 426 |flow(IP1,..)| |flow(IP2,..)| 427 +------------+ +------------+ 429 Figure 2(b). Configurations of network-based mobility management for 430 a hierarchical network with separate LMs, FM-CP and LMp at CPA, FM-DP 431 at DPA; FM-CP and LMc at CPN, FM-DP at DPN. 433 Figures 2 also shows a distributed mobility anchoring environment 434 with multiple instances of the DPA. 436 In the hierarchy, there may be multiple DPN's for each DPA. 438 There is FM-DP at each of the distributed DPA and at each of the 439 distributed DPN. 441 The control plane may either be distributed (not shown) or 442 centralized. 444 When the CPA co-locates with the distributed DPA there will be 445 multiple instances of the co-located CPA and DPA (not shown). 447 When the CPN co-locates with the distributed DPN there will be 448 multiple instances of the co-located CPN and DPN (not shown). 450 There is FM-CP function at the CPA and at the CPN. 452 MN is allocated an IP prefix/address IP1 which is anchored to the DPA 453 with the IP prefix/address IPa1. It is using IP1 to communicate with 454 a correspondent node (CN) not shown in the figure. The flow of this 455 communication session is shown as flow(IP1, ...) which uses IP1 and 456 other parameters. 458 In Figure 2(a), LMs and FM-CP are at the CPA. In addition, there are 459 FM-CP and LMc at the CPN. 461 LMs may be distributed or centralized according to whether the CPA is 462 distributed or centralized. The CPA may co-locate with DPA or may 463 separate. 465 Figure 2(b) differs from Figure 2(a) in that the LMs is separated 466 out, and a proxy LMp is added between the LMs and LMc. 468 LMp and FM-CP co-locate at the CPA. 470 FM-CP and LMc co-locate at the CPN. 472 The LMs may be centralized whereas the LMp may be distributed or 473 centralized according to whether the CPA is distributed or 474 centralized. 476 3.1.3. Host-based Mobility Support 478 Host-based variants of the mobility function configurations from 479 Figures 2(a) and 2(b) are respectively shown in Figures 3(a) and 3(b) 480 where the role to perform mobility functions by CPN and DPN are now 481 taken by the MN. The MN then needs to possess the mobility functions 482 FM and LMc. 484 (a) (b) 485 +-----+ 486 |LMs | 487 +-----+ 489 +------------+ +------------+ 490 |CPA: | |CPA: | 491 |FM-CP, LMs | |FM-CP, LMp | 492 +------------+ +------------+ 493 +------------+ +------------+ +------------+ +------------+ 494 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 495 |anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... 496 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 497 +------------+ +------------+ +------------+ +------------+ 499 +------------+ +------------+ 500 |MN(IP1) | |MN(IP1) | 501 |flow(IP1,..)| |flow(IP1,..)| 502 |FM, LMc | |FM, LMc | 503 +------------+ +------------+ 505 Figure 3. Configurations of host-based mobility management (a) FM-CP 506 and LMs at CPA, FM-DP at DPA, FM and LMc at MN; (b) Separate LMs, FM- 507 CP and LMp at CPA, FM-DP at DPA, FM and LMc at MN. 509 Figure 3 shows 2 configurations of host-based mobility management 510 with multiple instances of DPA for a distributed mobility anchoring 511 environment. 513 There is an FM-DP function at each of the distributed DPA. 515 The control plane may either be distributed (not shown) or 516 centralized. 518 When the CPA co-locates with the distributed DPA there will be 519 multiple instances of the co-located CPA and DPA (not shown). 521 There is an FM-CP function at the CPA. 523 The MN possesses the mobility functions such as FM and LMc. 525 The MN is allocated an IP prefix/address IP1 which is anchored to the 526 DPA with the IP prefix/address IPa1. It is using IP1 to communicate 527 with a CN not shown in the figure. The flow of this communication 528 session is shown as flow(IP1, ...) which uses IP1 and other 529 parameters. 531 In Figure 3(a), LMs and FM-CP co-locate at the CPA. 533 The LMs may be distributed or centralized according to whether the 534 CPA is distributed (not shown) or centralized. 536 Figure 3(b) differs from Figure 3(a) in that the LMs is separated out 537 and the proxy LMp is added between the LMs and LMc. 539 LMp and FM-CP co-locate at the CPA. 541 The LMs may be centralized whereas the LMp may be distributed or 542 centralized according to whether the CPA is distributed (not shown) 543 or centralized. 545 3.1.4. NEtwork MObility (NEMO) Basic Support 547 Figure 4 shows two configurations of NEMO basic support for a mobile 548 router. 550 (a) (b) 551 +-----+ 552 |LMs | 553 +-----+ 555 +------------+ +------------+ 556 |CPA: | |CPA: | 557 |FM-CP, LMs | |FM-CP, LMp | 558 +------------+ +------------+ 559 +------------+ +------------+ +------------+ +------------+ 560 |DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | 561 |anchors IP1 | |anchors IP2 | |anchors IP1 | |anchors IP2 | 562 |DHCPv6-PD | |DHCPv6-PD | ... |DHCPv6-PD | |DHCPv6-PD | ... 563 | IPn1| | IPn2| | IPn1| | IPn2| 564 |FM-DP | |FM-DP | |FM-DP | |FM-DP | 565 +------------+ +------------+ +------------+ +------------+ 567 +------------+ +------------+ 568 |MR(IP1) | |MR(IP1) | 569 |anchors IPn1| |anchors IPn1| 570 |FM, LMc | |FM, LMc | 571 +------------+ +------------+ 573 +------------+ +------------+ 574 |MNN(IPn1) | |MNN(IPn1) | 575 |flow(IPn1,.)| |flow(IPn1,.)| 576 +------------+ +------------+ 578 Figure 4. Configurations of NEMO basic support for a MR. (a) FM-CP 579 and LMs at CPA, FM-DP at DPA, FM and LMc at MR; (b) Separate LMs, FM- 580 CP and LMp at CPA, FM-DP at DPA, FM and LMc at MR. 582 Figure 4 shows 2 configurations of host-based mobility management for 583 a MR with multiple instances of DPA for a distributed mobility 584 anchoring environment. 586 There is an FM-DP function at each of the distributed DPA. 588 The control plane may either be distributed (not shown) or 589 centralized. 591 When the CPA co-locates with the distributed DPA there will be 592 multiple instances of the co-located CPA and DPA (not shown). 594 There is FM-CP function at the CPA. 596 The MR possesses the mobility functions FM and LMc. 598 MR is allocated an IP prefix/address IP1 which is anchored to the DPA 599 with the IP prefix/address IPa1. 601 A mobile network node (MNN) in the mobile network is allocated an IP 602 prefix/address IPn1 which is anchored to the MR with the IP prefix/ 603 address IP1. 605 The MNN is using IPn1 to communicate with a correspondent node (CN) 606 not shown in the figure. The flow of this communication session is 607 shown as flow(IPn1, ...) which uses IPn1 and other parameters. 609 In Figure 4(a), LMs and FM-CP co-locate at the CPA. 611 The LMs may be distributed or centralized according to whether the 612 CPA is distributed (not shown) or centralized. 614 Figure 4(b) differs from Figure 4(a) in that the LMs is separated out 615 and the proxy LMp is added between the LMs and LMc. 617 LMp and FM-CP co-locate at the CPA. 619 The LMs may be centralized whereas the LMp may be distributed or 620 centralized according to whether the CPA is distributed (not shown) 621 or centralized. 623 3.2. Operations and Parameters 625 The operations of distributed mobility anchoring are defined in order 626 that they may work together in expected manners to produce a 627 distributed mobility solution. The needed information is passed as 628 mobility message parameters, which must be protected in terms of 629 integrity. Some parameters may require a means to support privacy of 630 an MN or MR. 632 The mobility needs in 5G Wireless and beyond are diverse. Therefore 633 operations needed to enable different distributed mobility solutions 634 in different distributed mobility anchoring configurations are 635 extensive as illustrated below. It is however not necessary for 636 every distributed mobility solution to exhibit all the operations 637 listed in this section. A given distributed mobility solution may 638 exhibit the operations as needed. 640 3.2.1. Location Management 642 An example LM design consists of a distributed database with multiple 643 LMs servers. The location information about the prefix/address of an 644 MN is primarily at a given LMs. Peer LMs may exchange the location 645 information with each other. LMc may retrieve a given record or send 646 a given record update to LMs. 648 Location management configurations: 650 LM-cfg: As shown in Section 3.1: 652 LMs may be implemented at CPA, may co-locate with LMc at CPA, 653 or may be a separate server. 655 LMc may be at CPA, CPN, or MN. 657 LMp may proxy between LMs and LMc. 659 Specifically: 661 Location management operations and parameters: 663 LM-cfg:1 LMs may co-locate with LMc at CPA in a flat network with 664 network-based mobility as shown in Figure 1(a) in 665 Section 3.1.1. 667 LM-cfg:2 LMs may be a separate server whereas LMc is implemented in 668 CPA in a flat network with network-based mobility as shown 669 in Figure 1(b) in Section 3.1.1. 671 LM-cfg:3 LMs may be implemented at CPA, whereas LMc is implemented 672 at CPN in a hierarchical network with network-based 673 mobility as shown in Figure 2(a) in Section 3.1.2, at MN 674 for host-based mobility as shown in Figure 3(a) in 675 Section 3.1.3, or at MR for network mobility as shown in 676 Figure 4(a) in Section 3.1.4. 678 LM-cfg:4 LMs may be a separate server with LMp implemented at CPA 679 whereas LMc is implemented at CPN in a hierarchical network 680 with network-based mobility as shown in Figure 2(b) in 681 Section 3.1.2, at MN for host-based mobility as shown in 682 Figure 3(b) in Section 3.1.3, or at MR for network mobility 683 as shown in Figure 4(b) in Section 3.1.4. 685 LM-db: LM may manage the location information in a client-server 686 database system. 688 Example LM database functions are as follows: 690 LM-db:1 LMc may query LMs about location information for a prefix of 691 MN (pull). 692 Parameters: 694 - IP prefix of MN: integrity support required and privacy 695 support may be required. 697 LM-db:2 LMs may reply to LMc query about location information for a 698 prefix of MN (pull). 699 Parameters: 701 - IP prefix of MN: integrity support required and privacy 702 support may be required, 703 - IP address of FM-DP/DPA/DPN to forward the packets of the 704 flow: integrity support required. 706 LM-db:3 LMs may inform LMc about location information for a prefix 707 of MN (push). 708 Parameters: 710 - IP prefix of MN: integrity support required and privacy 711 support may be required, 712 - IP address of FM-DP/DPA/DPN to forward the packets of the 713 flow: integrity support required. 715 This function in the PMIPv6 protocol is the Update 716 Notification (UPN) together with the Update Notification 717 Acknowledgment (UPA) as defined in [RFC7077]. 719 LM-db:4 LMc may inform LMs about update location information for a 720 prefix of MN. 721 Parameters: 723 - IP prefix of MN: integrity support required and privacy 724 support may be required, 725 - IP address of FM-DP/DPA/DPN to forward the packets of the 726 flow: integrity support required. 728 This function in the MIPv6 / PMIPv6 protocol is the Binding 729 Update (BU) / Proxy Binding Update (PBU) together with the 730 Binding Acknowledgment (BA) / Proxy Binding Acknowledgment 731 (PBA) as defined in [RFC6275] / [RFC5213] respectively. 733 LM-db:5 The MN may be a host or a router. When the MN is an MR, the 734 prefix information may include the IP prefix delegated to 735 the MR. 737 Additional parameters: 739 - IP prefix delegated to MR: integrity support required and 740 privacy support may be required, 741 - IP prefix/address of the MR to forward the packets of the 742 prefix delegated to the MR: integrity support required. 744 LM-svr: The LM may be a distributed database with multiple LMs 745 servers. 747 For example: 749 LM-svr:1 A LMs may join a pool of LMs servers. 750 Parameters: 752 - IP address of the LMs: integrity support required, 753 - IP prefixes for which the LMs will host the primary 754 location information: integrity support required. 756 LM-svr:2 LMs may query a peer LMs about location information for a 757 prefix of MN. 758 Parameters: 760 - IP prefix: integrity support required and privacy support 761 may be required. 763 LM-svr:3 LMs may reply to a peer LMs about location information for 764 a prefix of MN. 765 Parameters: 767 - IP prefix of MN: integrity support required and privacy 768 support may be required, 769 - IP address of FM-DP/DPA/DPN to forward the packets of the 770 flow: integrity support required. 772 The parameters indicated above are only the minimal. In a specific 773 mobility protocol, additional parameters should be added as needed. 774 Examples of these additional parameters are those passed in the 775 mobility options of the mobility header for MIPv6 [RFC6275] and for 776 PMIPv6 [RFC5213]. 778 3.2.2. Forwarding Management 780 Forwarding management configurations: 782 FM-cfg: As shown in Section 3.1: 784 FM-CP may be implemented at CPA, CPN, MN depending on the 785 configuration chosen. 787 FM-DP may also be implemented at CPA, CPN, MN depending on 788 the configuration chosen. 790 Specifically: 792 FM-cfg:1 FM-CP and FM-DP may be implemented at CPA and DPA 793 respectively in a flat network with network-based mobility 794 as shown in Figure 1(a) and Figure 1(b) in Section 3.1.1. 796 FM-cfg:2 FM-CP may be implemented at both CPA and CPN and FM-DP is 797 implemented at both DPA and DPN in a hierarchical network 798 with network-based mobility as shown in Figure 2(a) and 799 Figure 2(b) in Section 3.1.2. 801 FM-cfg:3 FM-CP and FM-DP may be implemented at CPA and DPA 802 respectively and also both implemented at MN for host-based 803 mobility as shown in Figure 3(a) and Figure 3(b) in 804 Section 3.1.3. 806 FM-cfg:4 FM-CP and FM-DP may be implemented at CPA and DPA 807 respectively and also both implemented at MR for network 808 mobility as shown in Figure 4(a) and Figure 4(b) in 809 Section 3.1.4. 811 Forwarding management operations and parameters: 813 FM-find:1 An anchor may discover and be discovered such as through 814 an anchor registration system as follows: 816 FM-find:2 FM registers and authenticates itself with a centralized 817 mobility controller. 818 Parameters: 820 - IP address of DPA and its CPA: integrity support 821 required, 822 - IP prefix anchored to the DPA: integrity support 823 required. 825 Registration reply: acknowledge of registration and echo 826 the input parameters. 828 FM-find:3 FM discovers the FM of another IP prefix by querying the 829 mobility controller based on the IP prefix. 830 Parameters: 832 - IP prefix of MN: integrity support required and privacy 833 support may be required. 835 FM-find:4 When making anchor discovery FM expects the answer 836 parameters: 838 - IP address of DPA to which IP prefix of MN is anchored: 839 integrity support required, 840 - IP prefix of the corresponding CPA: integrity support 841 required. 843 FM-flow:1 The FM may be carried out on the packets to/from an MN up 844 to the granularity of a flow. 846 FM-flow:2 Example matching parameters are in the 5-tuple of a flow. 848 FM-path:1 FM may change the forwarding path of a flow upon a change 849 of point of attachment of a MN. Prior to the changes, 850 packets coming from the CN to the MN would traverse from 851 the CN to the home network anchor of the flow for the MN 852 before reaching the MN. Changes are from this original 853 forwarding path or paths to a new forwarding path or paths 854 from the CN to the current AR of the MN and then the MN 855 itself. 857 FM-path:2 As an incoming packet is forwarded from the CN to the MN, 858 the far end where forwarding path change begins may in 859 general be any node in the original forwarding path from 860 the CN to the home network DPA. The packet is forwarded 861 to the MN for host-based mobility and to a node in the 862 network which will deliver the packets to the MN for 863 network-based mobility. The near-end is generally a DPN 864 with a hierarchical network but may also be another node 865 with DPA capability in a flattened network. 867 FM-path:3 The mechanisms to accomplish such changes may include 868 changes to the forwarding table and indirection such as 869 tunneling, rewriting packet header, or NAT. 871 Note: An emphasis in this document in distributed mobility 872 anchoring is to explain the use of multiple anchors to 873 avoid unnecessarily long route which may be encountered in 874 centralized mobility anchoring. It is therefore not the 875 emphasis of this document on which particular mechanism to 876 choose from. 878 FM-path-tbl:4 With forwarding table updates, changes to the 879 forwarding table are needed at each of the affected 880 forwarding switches in order to change the forwarding 881 path of the packets for the flow from that originally 882 between the CN and the home network anchor or previous 883 AR to that between the CN and the new AR. 885 Specifically, such forwarding table updates may 886 include: (1) addition of forwarding table entries 887 needed to forward the packets destined to the MN to 888 the new AR; (2) deletion of forwarding table entries 889 to forward the packets destined to the MN to the home 890 network anchor or to the previous AR. 892 FM-path-tbl:5 Forwarding table updates may be triggered using 893 DHCPv6-PD prefix delegation to change the role of IP 894 anchoring from the home network anchor or previous AR 895 (with FM-DP) to the new anchor (with FM-DP) to which 896 the MN is currently attached. The new anchor will 897 then advertise routes for the delegated prefix. 899 With a distributed routing protocol, the updates 900 spread out from neighbors to neighbors and will affect 901 all the forwarding switches such that the packets sent 902 from "any" node to MN will go to the new AR. 904 FM-path-tbl:6 Forwarding table updates may also be achieved through 905 BGP update as described in [I-D.templin-aerolink], 906 [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved 907 Packet Core (EPC) network in 908 [I-D.matsushima-stateless-uplane-vepc] when the scope 909 and response time can be managed. 911 FM-path-tbl:7 Alternatively, with a centralized control plane, 912 forwarding table updates may be achieved through 913 messaging between the centralized control plane and 914 the distributed forwarding switches as described above 915 (FM-cpdp) in this section. 917 FM-path-tbl:8 To reduce excessive signaling, the scope of such 918 updates for a given flow may be confined to only those 919 forwarding switches such that only the packets sent 920 from the "CN" to the MN will go to the new AR. Such 921 confinement may be made when using a centralized 922 central plane possessing a global view of all the 923 forwarding switches. 925 FM-path-tbl:9 FM reverts the changes previously made to the 926 forwarding path of a flow when such changes are no 927 longer needed, e.g., when all the ongoing flows using 928 an IP prefix/address requiring IP session continuity 929 have closed. When using DHCPv6-PD, the forwarding 930 paths will be reverted upon prefix lease expiration. 932 FM-path-ind:10 Indirection forwards the incoming packets of the flow 933 from the DPA at the far end to a DPA/DPN at the near 934 end of indirection. Both ends of the indirection need 935 to know the LM information of the MN for the flow and 936 also need to possess FM capability to perform 937 indirection. 939 FM-path-ind:11 The mechanism of changing the forwarding path in MIPv6 940 [RFC6275] and PMIPv6 [RFC5213] is tunneling. In the 941 control plane, the FM-CP sets up the tunnel by 942 instructing the FM-DP at both ends of the tunnel. In 943 the data plane, the FM-DP at the start of the tunnel 944 performs packet encapsulation, whereas the FM-DP at 945 the end of the tunnel decapsulates the packet. 947 Note that in principle the ends of the indirection 948 path can be any pair of network elements with the FM- 949 DP function. 951 FM-path-ind:12 FM reverts the changes previously made to the 952 forwarding path of a flow when such changes are no 953 longer needed, e.g., when all the ongoing flows using 954 an IP prefix/address requiring IP session continuity 955 have closed. When tunneling is used, the tunnels will 956 be torn down when they are no longer needed. 958 FM-cpdp: With separation of control plane function and data plane 959 function, FM-CP and FM-DP communicate with each other. Such 960 communication may be realized by the appropriate messages in 961 [I-D.ietf-dmm-fpc-cpdp]. 963 For example: 965 FM-cpdp:1 CPA/FM-CP sends forwarding table updates to DPA/FM-DP. 966 Parameters: 968 - New forwarding table entries to add: integrity support 969 required, 971 - Expired forwarding table entries to delete: integrity 972 support required. 974 FM-cpdp:2 DPA/FM-DP sends to CPA/FM-CP about its status and load. 975 Parameters: 977 - State of forwarding function being active or not: 978 integrity support required, 979 - Loading percentage: integrity support required. 981 FM-CPA: The CPA possesses FM-CP function to make the changes to the 982 forwarding path as described in FM-path, and the changes may 983 be implemented through forwarding table changes or through 984 indirection as described respectively in FM-path-tbl and FM- 985 path-ind above. 987 The FM-CP communicates with the FM-DP using the appropirate 988 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 989 above so that it may instruct the FM-DP to perform the 990 changed forwarding tasks. 992 FM-DPA: The DPA possesses FM-DP function to forward packets according 993 to the changed forwarding path as described in FM-path, and 994 also FM-path-tbl or FM-path-ind depending on whether 995 forwarding table changes or indirection is used. 997 The FM-DP communicates with the FM-CP using the appropirate 998 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 999 above so that it may perform the changed forwarding tasks. 1001 The operations and their parameters for the DPA to perform 1002 distributed mobility management are described below: 1004 FM-DPA:1 The DPAs perform the needed functions such that for the 1005 incoming packets from the CN, forwarding path change by FM 1006 is from the DPA at the far end which may be at any 1007 forwarding switch (or even CN itself) in the original 1008 forwarding path to the near end DPA/DPN. 1010 FM-DPA:2 It is necessary that any incoming packet from the CN of the 1011 flow must traverse the DPA (or at least one of the DPAs, 1012 e.g., in the case of anycast) at the far end in order for 1013 the packet to detour to a new forwarding path. Therefore a 1014 convenient design is to locate the far end DPA at a unique 1015 location which is always in the forwarding path. This is 1016 the case in a centralized mobility design where the DPA at 1017 the far end is the home network anchor of the flow. 1019 Distributed mobility however may place the far end DPA at 1020 other locations in order to avoid unnecessarily long route. 1022 FM-DPA:3 With multiple nodes possessing DPA capabilities, the role 1023 of FM to begin path change for the incoming packets of a 1024 flow at the home network DPA at the far end may be passed 1025 to or added to that of another DPA. 1027 In particular, this DPA role may be moved upstream from the 1028 home network DPA in the original forwarding path from CN to 1029 MN. 1031 FM-DPA:4 Optimization of the new forwarding path may be achieved 1032 when the path change for the incoming packets begins at a 1033 DPA where the original path and the direct IPv6 path 1034 overlaps. Then the new forwarding path will resemble the 1035 direct IPv6 path from the CN to the MN. 1037 FM-DPA-tbl:5 One method to support IP mobility is through forwarding 1038 table changes triggered using DHCPv6-PD to change the 1039 role of IP anchoring from the home network anchor (DPA 1040 with FM-DP) to the new anchor (DPA with FM-DP). It 1041 therefore puts the near end of the path change at the 1042 new DPA. Forwarding table updates will subsequently 1043 propagate upstream from this DPA up to a far end DPA 1044 where the original path and the direct IPv6 path 1045 overlap. 1047 When that far end is too far upstream the signaling of 1048 forwarding table updates may become excessive. An 1049 alternative is to use indirection (see FM-DPA-ind) from 1050 that far end to the new DPA at the near end. 1052 Still another alternative is to combine forwarding 1053 table update with indirection. 1055 FM-DPA-tbl:6 Changes made by FM to the forwarding tables, which are 1056 IPv6 nodes, at the ends of the path change for a flow 1057 will be reverted when the mobility support for the flow 1058 is no longer needed, e.g., when the flows have 1059 terminated. 1061 FM-DPA-ind:7 An alternative mobility support is indirection from the 1062 far end DPA to the near end DPA. Both DPAs need to be 1063 capable to performing indirection. For incoming 1064 packets from the CN to the MN, the far end DPA needs to 1065 start the indirection towards the near end DPA, which 1066 will be the receiving end of indirection. In addition, 1067 the near end DPA needs to continue the forwarding of 1068 the packet towards the MN, such as through L2 1069 forwarding or through another indirection towards the 1070 MN. 1072 FM-DPA-ind:8 With indirection, locating or moving the FM function to 1073 begin indirection upstream along the forwarding path 1074 from CN to MN again may help to reduce unnecessarily 1075 long path. 1077 FM-DPA-ind:9 Changes made by FM to establish indirection at the DPA 1078 and DPN, which are IPv6 nodes, at the ends of the path 1079 change for a flow will be reverted when the mobility 1080 support for the flow is no longer needed, e.g., when 1081 the flows have terminated. 1083 FM-state:1 In addition to the above, a flow/session may contain 1084 states with the required information for QoS, charging, 1085 etc. as needed. These states need to be transferred from 1086 the old anchor to the new anchor. 1088 FM-buffer: An anchor can buffer packets of a flow in a mobility 1089 event: 1091 FM-buffer:1 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow. 1092 Trigger: 1094 - MN leaves DPA in a mobility event. 1096 Parameters: 1098 - IP prefix of the flow for which packets need to be 1099 buffered: integrity support required 1101 FM-buffer:2 CPA/FM-CP on behalf of a new DPA/FM-DP informs the CPA/ 1102 FM-CP of the prior DPA/FM-DP that it is ready to receive 1103 any buffered packets of a flow. 1104 Parameters: 1106 - Destination IP prefix of the flow's packets: integrity 1107 support required, 1108 - IP address of the new DPA: integrity support required. 1110 FM-mr:1 When the MN is a mobile router (MR) the access router 1111 anchoring the IP prefix of the MR will also own the IP 1112 prefix or prefixes to be delegated to the MR. The MNNs in 1113 the network carried by the MR obtains IP prefixes from the 1114 MR. 1116 FM-mr:2 When the MR moves from a previous AR to a new AR, the MNNs 1117 moves with the MR. Network mobility support for these MNNs 1118 may be provided by forwarding table updates such that 1119 packets destined to the MNNs will be forwarded towards the 1120 new AR instead of towards the old AR. 1122 Changes to forwarding table entries may occur at the new AR, 1123 the aggregate router, and other affected switch/routers such 1124 that packets destined to the MNNs will be forwarded to the 1125 new AR. 1127 Meanwhile, changes to forwarding table entries may also 1128 occur at the old AR, the aggregate router, and other 1129 affected switch/routers such that packets destined to the 1130 MNNs will not be forwarded to the old AR. 1132 4. IP Mobility Handling in Distributed Anchoring Environments - 1133 Mobility Support Only When Needed 1135 IP mobility support may be provided only when needed instead of being 1136 provided by default. The LM and FM functions in the different 1137 configurations shown in Section 3.1 are then utilized only when 1138 needed. 1140 A straightforward choice of mobility anchoring is for a flow to use 1141 the IP prefix of the network to which the MN is attached when the 1142 flow is initiated [I-D.seite-dmm-dma]. 1144 The IP prefix/address at the MN's side of a flow may be anchored at 1145 the access router to which the MN is attached. For example, when an 1146 MN attaches to a network (Net1) or moves to a new network (Net2), it 1147 is allocated an IP prefix from the attached network. In addition to 1148 configuring new link-local addresses, the MN configures from this 1149 prefix an IP address which is typically a dynamic IP address. It 1150 then uses this IP address when a flow is initiated. Packets to the 1151 MN in this flow are simply forwarded according to the forwarding 1152 table. 1154 There may be multiple IP prefixes/addresses that an MN can select 1155 when initiating a flow. They may be from the same access network or 1156 different access networks. The network may advertise these prefixes 1157 with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node 1158 may choose the one with the least cost. In addition, these IP 1159 prefixes/addresses may be of different types regarding whether 1160 mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow 1161 will need to choose the appropriate one according to whether it needs 1162 IP mobility support. 1164 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 1166 When IP mobility support is not needed for a flow, the LM and FM 1167 functions are not utilized so that the configurations in Section 3.1 1168 are simplified as shown in Figure 5. 1170 Net1 Net2 1172 +---------------+ +---------------+ 1173 |AR1 | AR is changed |AR2 | 1174 +---------------+ -------> +---------------+ 1175 |CPA: | |CPA: | 1176 |---------------| |---------------| 1177 |DPA(IPa1): | |DPA(IPa2): | 1178 |anchors IP1 | |anchors IP2 | 1179 +---------------+ +---------------+ 1181 +...............+ +---------------+ 1182 .MN(IP1) . MN moves |MN(IP2) | 1183 .flow(IP1,...) . =======> |flow(IP2,...) | 1184 +...............+ +---------------+ 1186 Figure 5. Changing to the new IP prefix/address. MN running a flow 1187 using IP1 in a network Net1 changes to running a flow using IP2 in 1188 Net2. 1190 When there is no need to provide IP mobility to a flow, the flow may 1191 use a new IP address acquired from a new network as the MN moves to 1192 the new network. 1194 Regardless of whether IP mobility is needed, if the flow has 1195 terminated before the MN moves to a new network, the flow may 1196 subsequently restart using the new IP address allocated from the new 1197 network. 1199 When IP session continuity is needed, even if a flow is ongoing as 1200 the MN moves, it may still be desirable for the flow to change to 1201 using the new IP prefix configured in the new network. The flow may 1202 then close and then restart using a new IP address configured in the 1203 new network. Such a change in the IP address of the flow may be 1204 enabled using a higher layer mobility support which is not in the 1205 scope of this document. 1207 In Figure 5, a flow initiated while the MN was using the IP prefix 1208 IP1 anchored to a previous access router AR1 in network Net1 has 1209 terminated before the MN moves to a new network Net2. After moving 1210 to Net2, the MN uses the new IP prefix IP2 anchored to a new access 1211 router AR2 in network Net2 to start a new flow. The packets may then 1212 be forwarded without requiring IP layer mobility support. 1214 An example call flow is outlined in Figure 6. 1216 MN AR1 AR2 CN 1217 |MN attaches to AR1: | | | 1218 |acquire MN-ID and profile | | 1219 |--RS---------------->| | | 1220 | | | | 1221 |<----------RA(IP1)---| | | 1222 | | | | 1223 Allocated prefix IP1 | | | 1224 IP1 address configuration | | 1225 | | | | 1226 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1227 | | | | 1228 |MN detaches from AR1 | | | 1229 |MN attaches to AR2 | | | 1230 | | | | 1231 |--RS------------------------------>| | 1232 | | | | 1233 |<--------------RA(IP2)-------------| | 1234 | | | | 1235 Allocated prefix IP2 | | | 1236 IP2 address configuration | | 1237 | | | | 1238 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1239 | | | | 1241 Figure 6. Re-starting a flow to use the IP allocated from the 1242 network at which the MN is attached. 1244 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address 1246 A network or network slice may not need IP mobility support. For 1247 example, a network slice for stationary sensors only will never 1248 encounter mobility. 1250 The standard functions in IPv6 already include dropping the old IPv6 1251 prefix/address and acquiring new IPv6 prefix/address when the node 1252 changes its point of attachment to a new network. Therefore, a 1253 network or network slice not providing IP mobility support at all 1254 will not need any of the functions with the mobility operations and 1255 messages described in Section 3.2. 1257 On the other hand, a network or network slice supporting a mix of 1258 flows requiring and not requiring IP mobility support will still need 1259 the mobility functions, which it will invoke or not invoke as needed. 1261 The guidelines for the IPv6 nodes in a network or network slice 1262 supporting a mix of flows requiring and not requiring IP mobility 1263 support include the following: 1265 GL-cfg:1 A network or network slice supporting a mix of flows 1266 requiring and not requiring mobility support may take any 1267 of the configurations described in Section 3.1 and need to 1268 implement in the appropriate IPv6 nodes the mobility 1269 functions LM and FM as described respectively in LM-cfg and 1270 FM-cfg in Section 3.2 according to the configuration 1271 chosen. 1273 GL-mix:1 These mobility functions perform some of the operations 1274 with the appropriate messages as described in Section 3.2 1275 depending on which mobility mechanisms are used. Yet these 1276 mobility functions must not be invoked for a flow that does 1277 not need IP mobility support. It is necessary to be able 1278 to distinguish the needs of a flow. The guidelines for the 1279 MN and the AR are in the following. 1281 GL-mix:2 Regardless of whether there are flows requiring IP mobility 1282 support, when the MN changes its point of attachment to a 1283 new network, it needs to configure a new global IP address 1284 for use in the new network in addition to configuring the 1285 new link-local addresses. 1287 GL-mix:3 The MN needs to check whether a flow needs IP mobility 1288 support. This can be performed when the application was 1289 initiated. The specific method is not in the scope of this 1290 document. 1292 GL-mix:4 The information of whether a flow needs IP mobility support 1293 is conveyed to the network such as by choosing an IP 1294 address to be provided with mobility support as described 1295 in [I-D.ietf-dmm-ondemand-mobility]. Then as the MN 1296 attaches to a new network, if the MN was using an IP 1297 address that is not supposed to be provided with mobility 1298 support, the access router will not invoke the mobility 1299 functions described in Section 3.2 for this IP address. 1300 That is, the IP address from the prior network is simply 1301 not used in the new network. 1303 The above guidelines are only to enable distinguishing whether there 1304 is need of IP mobility support for a flow that does not. When the 1305 flow needs IP mobility support, the list of guidelines will continue 1306 in Section 4.2.1. 1308 4.2. Need of IP Mobility 1310 When IP mobility is needed for a flow, the LM and FM functions in 1311 Section 3.1 are utilized. The mobility support may be provided by IP 1312 prefix anchor switching to the new network to be described in 1313 Section 5 or by using other mobility management methods 1314 ([Paper-Distributed.Mobility.PMIP] and 1315 [Paper-Distributed.Mobility.Review]). Then the flow may continue to 1316 use the IP prefix from the prior network of attachment. Yet some 1317 time later, the user application for the flow may be closed. If the 1318 application is started again, the new flow may not need to use the 1319 prior network's IP address to avoid having to invoke IP mobility 1320 support. This may be the case where a dynamic IP prefix/address 1321 rather than a permanent one is used. The flow may then use the new 1322 IP prefix in the network where the flow is being initiated. Routing 1323 is again kept simpler without employing IP mobility and will remain 1324 so as long as the MN which is now in the new network has not moved 1325 again and left to another new network. 1327 An example call flow in this case is outlined in Figure 7. 1329 MN AR1 AR2 CN 1330 |MN attaches to AR1: | | | 1331 |acquire MN-ID and profile | | 1332 |--RS---------------->| | | 1333 | | | | 1334 |<----------RA(IP1)---| | | 1335 | | | | 1336 Allocated prefix IP1 | | | 1337 IP1 address configuration | | 1338 | | | | 1339 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1340 | | | | 1341 |MN detach from AR1 | | | 1342 |MN attach to AR2 | | | 1343 | | | | 1344 |--RS------------------------------>| | 1346 IP mobility support such as that described in next sub-section 1347 |<--------------RA(IP2,IP1)---------| | 1348 | | | | 1349 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1350 | | | | 1351 Allocated prefix IP2 | | | 1352 IP2 address configuration | | 1353 | | | | 1354 Flow(IP1,IPcn) terminates | | 1355 | | | | 1356 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1357 | | | | 1359 Figure 7. A flow continues to use the IP from its home network after 1360 MN has moved to a new network. 1362 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility 1364 The configuration guidelines of distributed mobility for the IPv6 1365 nodes in a network or network slice supporting a mix of flows 1366 requiring and not requiring distributed mobility support are as 1367 follows: 1369 GL-cfg:2 Multiple instances of DPAs (at access routers) which are 1370 providing IP prefix to the MNs are needed to provide 1371 distributed mobility anchoring in an appropriate 1372 configuration such as those in Figure 1 (Section 3.1.1) for 1373 network-based distributed mobility or in Figure 3 1374 (Section 3.1.3) for host-based distributed mobility. 1376 The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) are to be 1377 implemented the mobility functions LM and FM as described 1378 respectively in LM-cfg and FM-cfg in Section 3.2 according 1379 to the configuration chosen. 1381 The guidelines of distributed mobility for the IPv6 nodes in a 1382 network or network slice supporting a mix of flows requiring and not 1383 requiring distributed mobility support had begun with those given as 1384 GL-mix in Section 4.1.1 and continue as follows: 1386 GL-mix:5 The distributed anchors may need to message with each 1387 other. When such messaging is needed, the anchors may need 1388 to discover each other as described in the FM operations 1389 and mobility message parameters (FM-find) in Section 3.2.2. 1391 GL-mix:6 The anchors may need to provide mobility support on a per- 1392 flow basis as described in the FM operations and mobility 1393 message parameters (FM-flow) in Section 3.2.2. 1395 GL-mix:7 Then the anchors need to properly forward the packets of 1396 the flows in the appropriate FM operations and mobility 1397 message parameters depending on the specific mobility 1398 mechanism as described in Section 3.2.2. 1400 GL-mix:8 When using a mechanism of changing forwarding table 1401 entries, the FM operations and mobility message parameters 1402 are described in FM-path, FM-path-tbl, FM-DPA, and FM-DPA- 1403 tbl in Section 3.2.2. 1405 The forwarding table updates will take place at AR1, AR2, 1406 the far end DPA, and other affected switches/routers such 1407 that the packet from the CN to the MN will traverse from 1408 the far end DPA towards AR2 instead of towards AR1. 1410 Therefore new entries to the forwarding table will be added 1411 between AR2, the far end DPA and other affected routers so 1412 that these packets will traverse towards AR2. Meanwhile, 1413 changes to the forwarding table entries will also occur 1414 between AR1, the far end DPA and other affected routers so 1415 that if these packets ever reaches any of them, the they 1416 will not traverse towards AR1 but will traverse towards 1417 AR2. Section 3.2.2. 1419 GL-mix:9 Alternatively when using a mechanism of indirection, the FM 1420 operations and mobility message parameters are described in 1421 FM-path, FM-path-ind, FM-DPA, and FM-DPA-ind in 1422 Section 3.2.2. 1424 GL-mix:10 If there are in-flight packets toward the old anchor while 1425 the MN is moving to the new anchor, it may be necessary to 1426 buffer these packets and then forward to the new anchor 1427 after the old anchor knows that the new anchor is ready. 1428 Such are described in the FM operations and mobility 1429 message parameters (FM-buffer) in Section 3.2.2. 1431 5. IP Mobility Handling in Distributed Mobility Anchoring Environments 1432 - Anchor Switching to the New Network 1434 IP mobility is invoked to enable IP session continuity for an ongoing 1435 flow as the MN moves to a new network. Here the anchoring of the IP 1436 address of the flow is in the home network of the flow, which is not 1437 in the current network of attachment. A centralized mobility 1438 management mechanism may employ indirection from the anchor in the 1439 home network to the current network of attachment. Yet it may be 1440 difficult to avoid unnecessarily long route when the route between 1441 the MN and the CN via the anchor in the home network is significantly 1442 longer than the direct route between them. An alternative is to 1443 switch the IP prefix/address anchoring to the new network. 1445 5.1. IP Prefix/Address Anchor Switching for Flat Network 1447 The IP prefix/address anchoring may move without changing the IP 1448 prefix/address of the flow. Here the LM and FM functions in Figures 1449 1(a) and 1(b) in Section 3.1 are implemented as shown in Figure 8. 1451 Net1 Net2 1453 +---------------+ +---------------+ 1454 |AR1 | |AR2 | 1455 +---------------+ +---------------+ 1456 |CPA: | |CPA: | 1457 |LM:IP1<-->IPa2 | |LM:IP1<-->IPa2 | 1458 |---------------| |---------------| 1459 |DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | 1460 |anchored IP1 | =======> |anchors IP2,IP1| 1461 |FM:DHCPv6-PD | |FM:DHCPv6-PD | 1462 +---------------+ +---------------+ 1464 +...............+ +---------------+ 1465 .MN(IP1) . MN moves |MN(IP2,IP1) | 1466 .flow(IP1,...) . =======> |flow(IP1,...) | 1467 +...............+ +---------------+ 1469 Figure 8. IP prefix/address anchor switching to the new network. MN 1470 with flow using IP1 in Net1 continues to run the flow using IP1 as it 1471 moves to Net2. 1473 As an MN with an ongoing session moves to a new network, the flow may 1474 preserve IP session continuity by moving the anchoring of the 1475 original IP prefix/address of the flow to the new network. BGP 1476 UPDATE messages may be used to change the forwarding table entries as 1477 described in [I-D.templin-aerolink] and [I-D.mccann-dmm-flatarch] if 1478 the response time of such updates does not exceed the handover delay 1479 requirement of the flow. An alternative is to use a centralized 1480 routing protocol to be described in Section 5.2 with a centralized 1481 control plane. 1483 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network 1485 The configuration guideline for a flat network or network slice 1486 supporting a mix of flows requiring and not requiring IP mobility 1487 support is: 1489 GL-cfg:3 Multiple instances of DPAs (at access routers) which are 1490 providing IP prefix to the MNs are needed to provide 1491 distributed mobility anchoring according to Figure 1(a) or 1492 Figure 1(b) in Section 3.1 for a flat network. 1494 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1495 the mobility functions LM and FM as described respectively 1496 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1498 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1499 IPv6 nodes for a network or network slice supporting a mix of flows 1500 requiring and not requiring IP mobility support apply here. In 1501 addition, the following are required. 1503 GL-switch:1 The location management provides information about which 1504 IP prefix from an AR in the original network is being 1505 used by a flow in which AR in a new network. Such 1506 information needs to be deleted or updated when such 1507 flows have closed so that the IP prefix is no longer 1508 used in a different network. The LM operations are 1509 described in Section 3.2.1. 1511 GL-switch:2 The FM functions are implemented through the DHCPv6-PD 1512 protocol. Here the anchor operations to properly 1513 forward the packets for a flow as described in the FM 1514 operations and mobility message parameters in FM-path, 1515 FM-path-tbl, FM-DPA, and FM-DPA-tbl in Section 3.2.2 are 1516 realized by changing the anchor with DHCPv6-PD and also 1517 by reverting such changes later after the application 1518 has already closed and when the DHCPv6-PD timer expires. 1519 If there are in-flight packets toward the old anchor 1520 while the MN is moving to the new anchor, it may be 1521 necessary to buffer these packets and then forward to 1522 the new anchor after the old anchor knows that the new 1523 anchor is ready as are described in FM-buffer in 1524 Section 3.2.2. The anchors may also need to discover 1525 each other as described also in the FM operations and 1526 mobility message parameters (FM-find). 1528 GL-switch:3 The security management function in the anchor node at a 1529 new network must allow to assign the original IP prefix/ 1530 address used by the mobile node at the previous 1531 (original) network. As the assigned original IP prefix/ 1532 address is to be used in the new network, the security 1533 management function in the anchor node must allow to 1534 advertise the prefix of the original IP address and also 1535 allow the mobile node to send and receive data packets 1536 with the original IP address. 1538 GL-switch:4 The security management function in the mobile node must 1539 allow to configure the original IP prefix/address used 1540 at the previous (original) network when the original IP 1541 prefix/address is assigned by the anchor node in the new 1542 network. The security management function in the mobile 1543 node also allows to use the original IP address for the 1544 previous flow in the new network. 1546 5.2. IP Prefix/Address Anchor Switching for Flat Network with 1547 Centralized Control Plane 1549 An example of IP prefix anchor switching is in the case where Net1 1550 and Net2 both belong to the same operator network with separation of 1551 control and data planes ([I-D.liu-dmm-deployment-scenario] and 1552 [I-D.matsushima-stateless-uplane-vepc]), where the controller may 1553 send to the switches/routers the updated information of the 1554 forwarding tables with the IP address anchoring of the original IP 1555 prefix/address at AR1 moved to AR2 in the new network. That is, the 1556 IP address anchoring in the original network which was advertising 1557 the prefix will need to move to the new network. As the anchoring in 1558 the new network advertises the prefix of the original IP address in 1559 the new network, the forwarding tables will be updated so that 1560 packets of the flow will be forwarded according to the updated 1561 forwarding tables. 1563 The configurations in Figures 1(a) and 1(b) in Section 3.1 for which 1564 the FM-CP and the LM are centralized and the FM-DP's are distributed 1565 apply here. Figure 9 shows its implementation where the LM is a 1566 binding between the original IP prefix/address of the flow and the IP 1567 address of the new DPA, whereas the FM uses the DHCPv6-PD protocol. 1569 Net1 Net2 1570 +----------------------------------------------------------------------+ 1571 | CPA: | 1572 | LM:IP1<-->IPa2 | 1573 | FM-CP | 1574 +----------------------------------------------------------------------+ 1576 +---------------+ +---------------+ 1577 |AR1 | |AR2 | 1578 +---------------+ +---------------+ 1579 |DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | 1580 |anchored IP1 | =======> |anchors IP2,IP1| 1581 |FM:DHCPv6-PD | |FM:DHCPv6-PD | 1582 +---------------+ +---------------+ 1584 +...............+ +---------------+ 1585 .MN(IP1) . MN moves |MN(IP2,IP1) | 1586 .flow(IP1,...) . =======> |flow(IP1,...) | 1587 +...............+ +---------------+ 1589 Figure 9. IP prefix/address anchor switching to the new network with 1590 with the LM and the FM-CP in a centralized control plane whereas the 1591 FM-DP's are distributed. 1593 The example call flow in Figure 10 shows that MN is allocated IP1 1594 when it attaches to the AR1 A flow running in MN and needing IP 1595 mobility may continue to use the previous IP prefix by moving the 1596 anchoring of the IP prefix to the new network. Yet a new flow to be 1597 initiated in the new network may simply use a new IP prefix allocated 1598 from the new network. 1600 MN AR1 AR2 DHCPv6 Servers CN 1601 |MN attaches to AR1: | | | | 1602 |acquire MN-ID and profile | | | 1603 |--RS---------------->| | | | 1604 |<----------RA(IP1)---| | | | 1605 | | | Allocate MN:IP1 | 1606 IP addr config | | | | 1607 | | | | | 1608 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1609 | | | | | 1610 |MN detach from AR1 | | | | 1611 |MN attach to AR2 | | | | 1612 | | | | | 1613 |--RS------------------------------>| | | 1614 | | | | | 1615 | |------DHCPv6 release-------------->| | 1616 | | | | | 1617 | | |--DHCPv6 PD request->| | 1618 | | |<-DHCPv6 PD reply--->| | 1619 | | | | | 1620 | forwarding table updates | | 1621 | | | | | 1622 |<--------------RA(IP2,IP1)---------| | | 1623 | | | Allocate MN:IP2 | 1624 IP addr config | | | | 1625 | | | | | 1626 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1627 | | | | | 1628 | Flow(IP1,IPcn,...) terminates | | | 1629 | | | | | 1630 | | DHCPv6-PD timeout | | 1631 | | | | | 1632 | forwarding table updates | | 1633 | | | | | 1634 | | | | | 1635 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1636 | | | | | 1638 Figure 10. DMM solution. MN with flow using IP1 in Net1 continues 1639 to run the flow using IP1 as it moves to Net2. 1641 As the MN moves from AR1 to AR2, the AR1 as a DHCPv6 client may send 1642 a DHCPv6 release message to release the IP1. It is now necessary for 1643 AR2 to learn the IP prefix of the MN from the previous network so 1644 that it will be possible for Net2 to allocate both the previous 1645 network prefix and the new network prefix. The network may learn the 1646 previous prefix in different methods. For example, the MN may 1647 provide its previous network prefix information by including it to 1648 the RS message [I-D.jhlee-dmm-dnpp]. 1650 Knowing that MN is using IP1, the AR2 sends to a DHCPv6 server a 1651 DHCPv6-PD request to move the IP1 to AR2. The server sends to AR2 a 1652 DHCPv6-PD reply to move the IP1. Then forwarding tables updates will 1653 take place here. 1655 In addition, the MN also needs a new IP in the new network. The AR2 1656 may now send RA to AR2, with prefix information that includes IP1 and 1657 IP2. The MN may then continue to use IP1. In addition, the MN is 1658 allocated the prefix IP2 with which it may configure its IP 1659 addresses. Now for flows using IP1, packets destined to IP1 will be 1660 forwarded to the MN via AR2. 1662 As such flows have terminated and DHCPv6-PD has timed out, IP1 goes 1663 back to Net1. MN will then be left with IP2 only, which it will use 1664 when it now starts a new flow. 1666 5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1667 Centralized CP 1669 The configuration guideline for a flat network or network slice with 1670 centralized control plane and supporting a mix of flows requiring and 1671 not requiring IP mobility support is: 1673 GL-cfg:4 Multiple instances of DPAs (at access routers) which are 1674 providing IP prefix to the MNs are needed to provide 1675 distributed mobility anchoring according to Figure 1(a) or 1676 Figure 1(b) in Section 3.1 with centralized control plane 1677 for a flat network. 1679 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1680 the mobility functions LM and FM as described respectively 1681 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1683 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1684 IPv6 nodes for a network or network slice supporting a mix of flows 1685 requiring and not requiring IP mobility support apply here. The 1686 guidelines (GL-mix) in Section 5.1.1 for moving anchoring for a flat 1687 network also apply here. In addition, the following are required. 1689 GL-switch:5 It was already mentioned that the anchor operations to 1690 properly forward the packets for a flow as described in 1691 the FM operations and mobility message parameters in FM- 1692 path, FM-path-tbl, FM-DPA, and FM-DPA-tbl in 1693 Section 3.2.2 is realized by changing the anchoring with 1694 DHCPv6-PD and undoing such changes later when its timer 1695 expires and the application has already closed. Here 1696 however, with separation of control and data planes for 1697 the anchors and where the LMs and the FM-CP are 1698 centralized in the same control plane, messaging between 1699 anchors and the discovery of anchors become internal to 1700 the control plane. 1702 GL-switch:6 The centralized FM-CP needs to communicate with the 1703 distributed FM-DP using the FM operations and mobility 1704 message parameters as described in FM-cpdp in 1705 Section 3.2.2. Such may be realized by the appropriate 1706 messages in [I-D.ietf-dmm-fpc-cpdp]. 1708 GL-switch:7 It was also already mentioned before that, if there are 1709 in-flight packets toward the previous anchor while the 1710 MN is moving to the new anchor, it may be necessary to 1711 buffer these packets and then forward to the new anchor 1712 after the old anchor knows that the new anchor is ready 1713 Here however, the corresponding FM operations and 1714 mobility message parameters as described in 1715 Section 3.2.2 (FM-buffer) can be realized by the 1716 internal operations in the control plane together with 1717 signaling between the control plane and distributed data 1718 plane. These signaling may be realized by the 1719 appropriate messages in [I-D.ietf-dmm-fpc-cpdp]. 1721 5.3. Hierarchical Network 1723 The configuration for a hierarchical network has been shown in 1724 Figures 2(a) and 2(b) in Section 3.1.2. With centralized control 1725 plane, CPA and CPN, with the associated LM and FM-CP are all co- 1726 located. There are multiple DPAs (each with FM-DP) in distributed 1727 mobility anchoring. In the data plane, there are multiple DPNs (each 1728 with FM-DP) hierarchically below each DPA. The DPA at each AR 1729 supports forwarding to the DPN at each of a number of forwarding 1730 switches (FW's). A mobility event in this configuration belonging to 1731 distributed mobility management will be deferred to Section 5.4. 1733 In this distributed mobility configuration, a mobility event 1734 involving change of FW only but not of AR as shown in Figure 11 may 1735 still belong to centralized mobility management and may be supported 1736 using PMIPv6. This configuration of network-based mobility is also 1737 applicable to host-based mobility with the modification for the MN 1738 directly taking the role of DPN and CPN, and the corresponding 1739 centralized mobility event may be supported using MIPv6. 1741 In Figure 11, the IP prefix allocated to the MN is anchored at the 1742 access router (AR) supporting indirection to the old FW to which the 1743 MN was originally attached as well as to the new FW to which the MN 1744 has moved. 1746 The realization of LM may be the binding between the IP prefix/ 1747 address of the flow used by the MN and the IP address of the DPN to 1748 which MN has moved. The implementation of FM to enable change of FW 1749 without changing AR may be accomplished using tunneling between the 1750 AR and the FW as described in [I-D.korhonen-dmm-local-prefix] and in 1751 [I-D.templin-aerolink] or using some other L2 mobility mechanism. 1753 Net1 Net2 1754 +----------------------------------------------------------------------+ 1755 | CPA,CPN: | 1756 | LM:IP1<-->IPn2 | 1757 | FM-CP | 1758 +----------------------------------------------------------------------+ 1760 +---------------+ 1761 |AR1 | 1762 +---------------+ 1763 |DPA(IPa1): | 1764 |anchors IP1 | 1765 |FM-DP | 1766 +---------------+ 1768 +---------------+ +---------------+ 1769 |FW1 | |FW2 | 1770 +---------------+ FW is changed +---------------+ 1771 |DPN(IPn1): | -------> |DPN(IPn2): | 1772 |FM-DP | |FM-DP | 1773 +---------------+ +---------------+ 1775 +...............+ +---------------+ 1776 .MN(IP1) . MN moves |MN(IP2) | 1777 .flow(IP1,...) . =======> |flow(IP1,...) | 1778 +...............+ +---------------+ 1780 Figure 11. Mobility without involving change of IP anchoring in a 1781 network in which the IP prefix allocated to the MN is anchored at an 1782 AR which is hierarchically above multiple FWs to which the MN may 1783 connect. 1785 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical Network with 1786 No Anchor Relocation 1788 The configuration guideline for a hierarchical network or network 1789 slice with centralized control plane and supporting a mix of flows 1790 requiring and not requiring IP mobility support is: 1792 GL-cfg:5 Multiple instances of DPAs (at access routers) which are 1793 providing IP prefix to the MNs are needed to provide 1794 distributed mobility anchoring according to Figure 2(a) or 1795 Figure 2(b)in Section 3.1.2 with centralized control plane 1796 for a hierarchical network. 1798 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1799 the mobility functions LM and FM as described respectively 1800 in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. 1802 Even when the mobility event does not involve change of anchor, it is 1803 still necessary to distinguish whether a flow needs IP mobility 1804 support. 1806 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1807 IPv6 nodes for a network or network slice supporting a mix of flows 1808 requiring and not requiring IP mobility support apply here. In 1809 addition, the following are required. 1811 GL-switch:8 Here, the LM operations and mobility message parameters 1812 described in Section 3.2.1 provides information of which 1813 IP prefix from its FW needs to be used by a flow using 1814 which new FW. The anchor operations to properly forward 1815 the packets of a flow described in the FM operations and 1816 mobility message parameters (FM-path, FM-path-ind, FM- 1817 cpdp in Section 3.2.2) may be realized with PMIPv6 1818 protocol [I-D.korhonen-dmm-local-prefix] or with AERO 1819 protocol [I-D.templin-aerolink] to tunnel between the AR 1820 and the FW. 1822 5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network 1824 The configuration for the hierarchical network has been shown in 1825 Figures 2(a) and 2(b) in Section 3.1.2. Again, with centralized 1826 control plane, CPA and CPN, with the associated LM and FM-CP are all 1827 co-located. There are multiple DPAs (each with FM-DP) in distributed 1828 mobility anchoring. In the data plane, there are multiple DPNs (each 1829 with FM-DP) hierarchically below each DPA. The DPA at each AR 1830 supports forwarding to the DPN at each of a number of forwarding 1831 switches (FW's). 1833 A distributed mobility event in this configuration involves change 1834 from a previous DPN which is hierarchically under the previous DPA to 1835 a new DPN which is hierarchically under a new DPA. Such an event 1836 involving change of both DPA and DPN is shown in Figure 12. 1838 Net1 Net2 1839 +----------------------------------------------------------------------+ 1840 | CPA,CPN,Aggregate Router: | 1841 | LM:IP1<-->IPa2,IPn2 | 1842 | FM-CP | 1843 +----------------------------------------------------------------------+ 1845 +-----------------+ 1846 |Aggregate Router | 1847 +-----------------+ 1848 |FM-DP | 1849 +-----------------+ 1851 +---------------+ +---------------+ 1852 |AR1 | |AR2 | 1853 +---------------+ +---------------+ 1854 |DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | 1855 |anchored IP1 | =======> |anchors IP2,IP1| 1856 |FM:DHCPv6-PD | |FM:DHCPv6-PD | 1857 +---------------+ +---------------+ 1859 +---------------+ +---------------+ 1860 |FW1 | |FW2 | 1861 +---------------+ FW is changed +---------------+ 1862 |DPN(IPn1): | -------> |DPN(IPn2): | 1863 |FM-DP | |FM-DP | 1864 +---------------+ +---------------+ 1866 +...............+ +---------------+ 1867 .MN(IP1) . MN moves |MN(IP2,IP1) | 1868 .flow(IP1,...) . =======> |flow(IP1,...) | 1869 +...............+ +---------------+ 1871 Figure 12. Mobility involving change of IP anchoring in a network 1872 with hierarchy in which the IP prefix allocated to the MN is anchored 1873 at an Edge Router supporting multiple access routers to which the MN 1874 may connect. 1876 This deployment case involves both a change of anchor from AR1 to AR2 1877 and a network hierarchy AR-FW. It can be realized by a combination 1878 of relocating the IP prefix/address anchoring from AR1 to AR2 with 1879 the mechanism as described in Section 5.2 and then forwarding the 1880 packets with network hierarchy AR-FW as described in Section 5.3. 1882 To change the anchoring of IP1, AR1 acting as a DHCPv6-PD client may 1883 exchange message with the DHCPv6 server to release the prefix IP1. 1884 Meanwhile, AR2 acting as a DHCPv6-PD client may exchange message with 1885 the DHCPv6 server to delegate the prefix IP1 to AR2. 1887 5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1888 Hierarchical Network 1890 The configuration guideline (GL-cfg) for a hierarchical network or 1891 network slice with centralized control plane described in 1892 Section 5.3.1 apply here. 1894 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1895 IPv6 nodes for a network or network slice supporting a mix of flows 1896 requiring and not requiring IP mobility support apply here. 1898 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1899 and in Section 5.2.1 for a centralized control plane also apply here. 1901 In addition, the guidelines for indirection between the new DPA and 1902 the new DPN as described in Section 5.3.1 apply as well. 1904 5.5. Network Mobility 1906 The configuration for network mobility has been shown in Figures 4(a) 1907 and 4(b) in Section 3.1.4. Again, with centralized control plane, 1908 CPA, with the associated LM and FM-CP are all co-located. There are 1909 multiple DPAs (each with FM-DP) in the data plane in distributed 1910 mobility anchoring. The MR possesses the mobility functions FM and 1911 LMc. The IP prefix IPn1 is delegated to the MR, to which a MNN is 1912 attached and is allocated with an IP address from IPn1. 1914 Figure 13 shows a distributed mobility event in a hierarchical 1915 network with a centralized control plane involving a change of 1916 attachment of the MR from a previous DPA to a new DPA while the MNN 1917 is attached to and therefore moves with the MR. 1919 Net1 Net2 1920 +----------------------------------------------------------------------+ 1921 | CPA,Aggregate Router: | 1922 | LM:IP1<-->IPa2; IPn1<-->IP1 | 1923 | FM-CP, LM | 1924 +----------------------------------------------------------------------+ 1926 +-----------------+ 1927 |Aggregate Router | 1928 +-----------------+ 1929 |FM-DP | 1930 +-----------------+ 1932 +---------------+ +---------------+ 1933 |AR1 | |AR2 | 1934 +---------------+ +---------------+ 1935 |DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | 1936 |anchored IP1 | =======> |anchors IP2,IP1| 1937 |DHCPv6-PD IPn1 | | | 1938 |FM-DP | |FM-DP | 1939 +---------------+ +---------------+ 1941 +...............+ +---------------+ 1942 .MR(IP1) . MR moves |MR(IP2,IP1) | 1943 +...............+ =======> +---------------+ 1944 .FM, LMc . |FM, LMc | 1945 .anchors IPn1 . |anchors IPn1 | 1946 +...............+ +---------------+ 1948 +...............+ +---------------+ 1949 .MNN(IPn1) . MNN moves with MR |MNN(IPn1) | 1950 .flow(IPn1,...) . =======> |flow(IPn1,...) | 1951 +...............+ +---------------+ 1953 Figure 13. Mobility involving change of IP anchoring for a MR to 1954 which a MNN is attached. 1956 As the MR with source IP prefix IP1 moves from AR1 to AR2, mobility 1957 support may be provided by moving the anchoring of IP1 from AR1 to 1958 AR2 using the mechanism described in Section 5.2. 1960 The forwarding table updates will take place at AR1, AR2, the 1961 aggregate router, and other affected routers such that the packet 1962 from the CN to the MNN will traverse from the aggregate router 1963 towards AR2 instead of towards AR1. 1965 5.5.1. Additional Guidelines for IPv6 Nodes: Network mobility 1967 The configuration guideline for a network or network slice with 1968 centralized control plane to provide network mobility is: 1970 GL-cfg:6 Multiple instances of DPAs (at access routers) which are 1971 providing IP prefix of the MRs are needed to provide 1972 distributed mobility anchoring according to Figure 4(a) or 1973 Figure 4(b) in Section 3.1. 1975 The appropriate IPv6 nodes (CPA, DPA) are to be implemented 1976 the mobility functions LM and FM as described respectively 1977 in LM-cfg:3 or LM-cfg:4 and FM-cfg:4 in Section 3.2. 1979 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1980 IPv6 nodes for a network or network slice supporting a mix of flows 1981 requiring and not requiring IP mobility support apply here. 1983 Here, because the MN is a MR, the following guideline is added: 1985 GL-mix:11 There are no flows requiring network mobility support when 1986 there are no MNN attaching to the MR. Here there are also 1987 no MNN using a prefix delegated to the MR. Therefore the 1988 anchor of the MR may change to a new AR. The new AR may 1989 delegate new IP prefix to the AR, so that the MR may 1990 support potential MNN to attach to it. On the other hand 1991 the delegation of IP prefix to the MR from the old AR may 1992 be deleted. 1994 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1995 and in Section 5.2.1 for a centralized control plane also apply here. 1997 Again because the MN is a MR, the following guidelines are added: 1999 GL-switch:9 Network mobility may be provided using the FM operations 2000 and mobility message parameters as described in FM-mr in 2001 Section 3.2.2. 2003 GL-switch:10 The following changes to forwarding table entries are 2004 needed: 2006 New entries to the forwarding tables are added between 2007 AR2, the aggregate router and other affected routers so 2008 that packets from the CN to the MNN destined to IPn1 2009 will traverse towards AR2. Meanwhile, changes to the 2010 forwarding table will also occur between AR1, the 2011 aggregate router and other affected routers so that such 2012 packets ever reaches any of them, the packet will not 2013 traverse towards AR1 but will traverse towards AR2. 2015 GL-switch:11 The security management function in the anchor node at a 2016 new network must allow to assign the original IP prefix/ 2017 address allocated to the MR and used by the MNN at the 2018 previous (original) network. As the assigned original 2019 IP prefix/address is to be used in the new network, the 2020 security management function in the anchor node must 2021 allow to advertise the prefix of the original IP address 2022 and also allow the MNN to send and receive data packets 2023 with the original IP address. 2025 GL-switch:12 The security management function in the mobile router 2026 must allow to configure the original IP prefix/address 2027 delegated to the MR from the previous (original) network 2028 when the original IP prefix/address is being delegated 2029 to the MR in the new network. The security management 2030 function in the mobile router also allows to use the 2031 original IP address by the MNNs for the previous flow in 2032 the new network. 2034 6. Security Considerations 2036 The security considerations are already described in different 2037 sessions through this document. They are described in terms of 2038 integrity support, privacy support etc. in describing the mobility 2039 functions in Section 3.2. They are also described in the guidelines 2040 for IPv6 nodes in various subsections Section 4 and Section 5. 2042 7. IANA Considerations 2044 This document presents no IANA considerations. 2046 8. Contributors 2048 This document has benefited from other work on mobility solutions 2049 using BGP update, on mobility support in SDN network, on providing 2050 mobility support only when needed, and on mobility support in 2051 enterprise network. These work have been referenced. While some of 2052 these authors have taken the work to jointly write this document, 2053 others have contributed at least indirectly by writing these drafts. 2054 The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, 2055 Peter McCann, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. 2057 Valuable comments have also been received from John Kaippallimalil, 2058 ChunShan Xiong, and Dapeng Liu. 2060 9. References 2062 9.1. Normative References 2064 [I-D.ietf-dmm-deployment-models] 2065 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 2066 Architectural Considerations", draft-ietf-dmm-deployment- 2067 models-00 (work in progress), August 2016. 2069 [I-D.ietf-dmm-fpc-cpdp] 2070 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 2071 and D. Moses, "Protocol for Forwarding Policy 2072 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-05 2073 (work in progress), October 2016. 2075 [I-D.ietf-dmm-ondemand-mobility] 2076 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 2077 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 2078 ondemand-mobility-09 (work in progress), December 2016. 2080 [I-D.jhlee-dmm-dnpp] 2081 Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", 2082 draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. 2084 [I-D.korhonen-dmm-local-prefix] 2085 Korhonen, J., Savolainen, T., and S. Gundavelli, "Local 2086 Prefix Lifetime Management for Proxy Mobile IPv6", draft- 2087 korhonen-dmm-local-prefix-01 (work in progress), July 2088 2013. 2090 [I-D.liu-dmm-deployment-scenario] 2091 Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, 2092 "Distributed mobility management deployment scenario and 2093 architecture", draft-liu-dmm-deployment-scenario-05 (work 2094 in progress), October 2015. 2096 [I-D.matsushima-stateless-uplane-vepc] 2097 Matsushima, S. and R. Wakikawa, "Stateless user-plane 2098 architecture for virtualized EPC (vEPC)", draft- 2099 matsushima-stateless-uplane-vepc-06 (work in progress), 2100 March 2016. 2102 [I-D.mccann-dmm-flatarch] 2103 McCann, P., "Authentication and Mobility Management in a 2104 Flat Architecture", draft-mccann-dmm-flatarch-00 (work in 2105 progress), March 2012. 2107 [I-D.mccann-dmm-prefixcost] 2108 McCann, P. and J. Kaippallimalil, "Communicating Prefix 2109 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 2110 (work in progress), April 2016. 2112 [I-D.seite-dmm-dma] 2113 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 2114 Anchoring", draft-seite-dmm-dma-07 (work in progress), 2115 February 2014. 2117 [I-D.templin-aerolink] 2118 Templin, F., "Asymmetric Extended Route Optimization 2119 (AERO)", draft-templin-aerolink-74 (work in progress), 2120 November 2016. 2122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2123 Requirement Levels", BCP 14, RFC 2119, 2124 DOI 10.17487/RFC2119, March 1997, 2125 . 2127 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 2128 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 2129 . 2131 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 2132 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 2133 RFC 5213, DOI 10.17487/RFC5213, August 2008, 2134 . 2136 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2137 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2138 2011, . 2140 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 2141 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 2142 RFC 7077, DOI 10.17487/RFC7077, November 2013, 2143 . 2145 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 2146 Korhonen, "Requirements for Distributed Mobility 2147 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 2148 . 2150 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 2151 CJ. Bernardos, "Distributed Mobility Management: Current 2152 Practices and Gap Analysis", RFC 7429, 2153 DOI 10.17487/RFC7429, January 2015, 2154 . 2156 9.2. Informative References 2158 [Paper-Distributed.Mobility] 2159 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 2160 IP Mobility Management from the Perspective of the IETF: 2161 Motivations, Requirements, Approaches, Comparison, and 2162 Challenges", IEEE Wireless Communications, October 2013. 2164 [Paper-Distributed.Mobility.PMIP] 2165 Chan, H., "Proxy Mobile IP with Distributed Mobility 2166 Anchors", Proceedings of GlobeCom Workshop on Seamless 2167 Wireless Mobility, December 2010. 2169 [Paper-Distributed.Mobility.Review] 2170 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 2171 "Distributed and Dynamic Mobility Management in Mobile 2172 Internet: Current Approaches and Issues", February 2011. 2174 Authors' Addresses 2176 H Anthony Chan (editor) 2177 Huawei Technologies 2178 5340 Legacy Dr. Building 3 2179 Plano, TX 75024 2180 USA 2182 Email: h.a.chan@ieee.org 2184 Xinpeng Wei 2185 Huawei Technologies 2186 Xin-Xi Rd. No. 3, Haidian District 2187 Beijing, 100095 2188 P. R. China 2190 Email: weixinpeng@huawei.com 2191 Jong-Hyouk Lee 2192 Sangmyung University 2193 31, Sangmyeongdae-gil, Dongnam-gu 2194 Cheonan 31066 2195 Republic of Korea 2197 Email: jonghyouk@smu.ac.kr 2199 Seil Jeon 2200 Sungkyunkwan University 2201 2066 Seobu-ro, Jangan-gu 2202 Suwon, Gyeonggi-do 2203 Republic of Korea 2205 Email: seiljeon@skku.edu 2207 Alexandre Petrescu 2208 CEA, LIST 2209 CEA Saclay 2210 Gif-sur-Yvette, Ile-de-France 91190 2211 France 2213 Phone: +33169089223 2214 Email: Alexandre.Petrescu@cea.fr 2216 Fred L. Templin 2217 Boeing Research and Technology 2218 P.O. Box 3707 2219 Seattle, WA 98124 2220 USA 2222 Email: fltemplin@acm.org