idnits 2.17.1 draft-ietf-dmm-distributed-mobility-anchoring-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 12, 2017) is 2355 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-03 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-09 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-12 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-75 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: May 16, 2018 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 November 12, 2017 15 Distributed Mobility Anchoring 16 draft-ietf-dmm-distributed-mobility-anchoring-07 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 may be 24 configured with distributed mobility anchoring functions according to 25 the needs of mobility support. In the distributed mobility anchoring 26 environment, multiple anchors are available for mid-session switching 27 of an IP prefix anchor. To start a new flow or to handle a flow not 28 requiring IP session continuity as a mobile node moves to a new 29 network, the flow can be started or re-started using a new IP address 30 configured from the new IP prefix which is anchored to the new 31 network. For a flow requiring IP session continuity, the anchoring 32 of the prior IP prefix may be moved to the new network. The mobility 33 functions and their operations and parameters are general for 34 different configurations. The mobility signaling may be between 35 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 https://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 May 16, 2018. 57 Copyright Notice 59 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . 6 77 3.1. Configurations for Different Networks . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.1.3. Host-based Mobility Support . . . . . . . . . . . . . 10 82 3.1.4. NEtwork MObility (NEMO) Basic Support . . . . . . . . 11 83 3.2. Operations and Parameters . . . . . . . . . . . . . . . . 12 84 3.2.1. Location Management . . . . . . . . . . . . . . . . . 12 85 3.2.2. Forwarding Management . . . . . . . . . . . . . . . . 15 86 4. IP Mobility Handling in Distributed Anchoring Environments - 87 Mobility Support Only When Needed . . . . . . . . . . . . . . 21 88 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 22 89 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP 90 Prefix/Address . . . . . . . . . . . . . . . . . . . 23 91 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 25 92 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility . . . 26 93 5. IP Mobility Handling in Distributed Mobility Anchoring 94 Environments - Anchor Switching to the New Network . . . . . 28 95 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 28 96 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat 97 Network . . . . . . . . . . . . . . . . . . . . . . . 29 99 5.2. IP Prefix/Address Anchor Switching for Flat Network with 100 Centralized Control Plane . . . . . . . . . . . . . . . . 30 101 5.2.1. Additional Guidelines for IPv6 Nodes: Switching 102 Anchor with Centralized CP . . . . . . . . . . . . . 33 103 5.3. Hierarchical Network . . . . . . . . . . . . . . . . . . 34 104 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical 105 Network with No Anchor Relocation . . . . . . . . . . 35 106 5.4. IP Prefix/Address Anchor Switching for a Hierarchical 107 Network . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 5.4.1. Additional Guidelines for IPv6 Nodes: Switching 109 Anchor with Hierarchical Network . . . . . . . . . . 37 110 5.5. Network Mobility . . . . . . . . . . . . . . . . . . . . 38 111 5.5.1. Additional Guidelines for IPv6 Nodes: Network 112 mobility . . . . . . . . . . . . . . . . . . . . . . 40 113 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 114 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 115 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 116 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 117 9.1. Normative References . . . . . . . . . . . . . . . . . . 42 118 9.2. Informative References . . . . . . . . . . . . . . . . . 45 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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. This draft defines different configurations, 126 functional operations and parameters for distributed mobility 127 anchoring and explains how to use them to make the route changes to 128 avoid unnecessarily long routes. 130 Companion distributed mobility management documents are already 131 addressing the architecture and deployment 132 [I-D.ietf-dmm-deployment-models], source address selection 133 [I-D.ietf-dmm-ondemand-mobility], and control-plane data-plane 134 signaling [I-D.ietf-dmm-fpc-cpdp]. A number of distributed mobility 135 solutions have also been proposed, for example, in 136 [I-D.seite-dmm-dma], [I-D.bernardos-dmm-cmip], 137 [I-D.bernardos-dmm-pmip], [I-D.sarikaya-dmm-for-wifi], 138 [I-D.yhkim-dmm-enhanced-anchoring], and 139 [I-D.matsushima-stateless-uplane-vepc]. Yet in 5G Wireless and 140 beyond, the mobility requirements are diverse, and IP mobility 141 support is no longer by default with a one-size-fit-all solution. In 142 different networks, different kinds of mobility support are possible 143 depending on the needs. In designing mobility solutions, it may not 144 always be obvious on how to best configure and use only the needed 145 mobility functions to provide the specific mobility support. This 146 document aims at filling such background. 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 basic support are described respectively in 157 Section 3.1.1, Section 3.1.2, Section 3.1.3 and Section 3.1.4. 158 Required operations and parameters for distributed mobility anchoring 159 are presented in Section 3.2. For instance, location management is 160 described in Section 3.2.1, forwarding management is described in 161 Section 3.2.2. 163 As an MN attaches to an access router and establishes a link between 164 them, a /64 IPv6 prefix anchored to the router may be assigned to the 165 link for exclusive use by the MN [RFC6459]. The MN may then 166 configure a global IPv6 address from this prefix and use it as the 167 source IP address in a flow to communicate with its correspondent 168 node (CN). When there are multiple mobility anchors, an address 169 selection for a given flow is first required before the flow is 170 initiated. Using an anchor in an MN's network of attachment has the 171 advantage that the packets can simply be forwarded according to the 172 forwarding table. However, after the flow has been initiated, the MN 173 may later move to another network, so that the IP address no longer 174 belongs to the current network of attachment of the MN. 176 Whether the flow needs IP session continuity will determine how to 177 ensure that the IP address of the flow will be anchored to the new 178 network of attachment. If the ongoing IP flow can cope with an IP 179 prefix/address change, the flow can be reinitiated with a new IP 180 address anchored in the new network as shown in Section 4.1. On the 181 other hand, if the ongoing IP flow cannot cope with such change, 182 mobility support is needed as shown in Section 4.2. A network 183 supporting a mix of flows both requiring and not requiring IP 184 mobility support will need to distinguish these flows. The 185 guidelines for the network to make such a distinction are described 186 in Section 4.1.1. The general guidelines for such network to provide 187 IP mobility support are described in Section 4.2.1. 189 Specifically, IP mobility support can be provided by relocating the 190 anchoring of the IP prefix/address of the flow from the home network 191 of the flow to the new network of attachment. The basic case may be 192 with network-based mobility for a flat network configuration 193 described in Section 5.1 with the guidelines described in 194 Section 5.1.1. This case is discussed further with a centralized 195 control plane in Section 5.2 with additional guidelines described in 196 Section 5.2.1. A level of hierarchy of nodes may then be added to 197 the network configuration as described in Section 5.3 with additional 198 guidelines described in Section 5.3.1. Local Mobility in such 199 hierarchical network is described in Section 5.4 with additional 200 guidelines described in Section 5.4.1. Network mobiltiy example is 201 described in Section 5.5 with additional guidelines described in 202 Section 5.5.1. 204 2. Conventions and Terminology 206 The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 All general mobility-related terms and their acronyms used in this 211 document are to be interpreted as defined in the Mobile IPv6 (MIPv6) 212 base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) 213 specification [RFC5213], the "Mobility Related Terminologies" 214 [RFC3753], and the DMM current practices and gap analysis [RFC7429]. 215 These include terms such as mobile node (MN), correspondent node 216 (CN), home agent (HA), home address (HoA), care-of-address (CoA), 217 local mobility anchor (LMA), and mobile access gateway (MAG). 219 In addition, this document uses the following terms: 221 Home network of an application session or a home address: the 222 network that has assigned the HoA used as the session identifier 223 by the application running in an MN. The MN may be running 224 multiple application sessions, and each of these sessions can have 225 a different home network. 227 Anchoring (an IP prefix/address): An IP prefix, i.e., Home Network 228 Prefix (HNP), or address, i.e., HoA, assigned for use by an MN is 229 topologically anchored to an anchor node when the anchor node is 230 able to advertise a connected route into the routing 231 infrastructure for the assigned IP prefix. 233 Location Management (LM) function: that keeps and manages the 234 network location information of an MN. The location information 235 may be a binding of the advertised IP address/prefix, e.g., HoA or 236 HNP, to the IP routing address of the MN or of a node that can 237 forward packets destined to the MN. 239 When the MN is a mobile router (MR) carrying a mobile network of 240 mobile network nodes (MNN), the location information will also 241 include the mobile network prefix (MNP), which is the aggregate IP 242 prefix delegated to the MR to assign IP prefixes for use by the 243 MNNs in the mobile network. 245 In a client-server protocol model, location query and update 246 messages may be exchanged between a Location Management client 247 (LMc) and a Location Management server (LMs), where the location 248 information can be updated to or queried from the LMs. 249 Optionally, there may be a Location Management proxy (LMp) between 250 LMc and LMs. 252 With separation of control plane and data plane, the LM function 253 is in the control plane. It may be a logical function at the 254 control plane node, control plane anchor, or mobility controller. 256 It may be distributed or centralized. 258 Forwarding Management (FM) function: packet interception and 259 forwarding to/from the IP address/prefix assigned for use by the 260 MN, based on the internetwork location information, either to the 261 destination or to some other network element that knows how to 262 forward the packets to their destination. 264 This function may be used to achieve traffic indirection. With 265 separation of control plane and data plane, the FM function may 266 split into a FM function in the data plane (FM-DP) and a FM 267 function in the control plane (FM-CP). 269 FM-DP may be distributed with distributed mobility management. It 270 may be a function in a data plane anchor or data plane node. 272 FM-CP may be distributed or centralized. It may be a function in 273 a control plane node, control plane anchor or mobility controller. 275 3. Distributed Mobility Anchoring 277 3.1. Configurations for Different Networks 279 The mobility functions may be implemented in different configurations 280 of distributed mobility anchoring in architectures separating the 281 control and data planes. The separation described in 282 [I-D.ietf-dmm-deployment-models] has defined the home control plane 283 anchor (Home-CPA), home data plane anchor (Home-DPA), access control 284 plane node (Access-CPN), and access data plane node (Access-DPN), 285 which are respectively abbreviated as CPA, DPA, CPN, and DPN here. 287 Different networks may have different configurations in distributed 288 mobility anchoring. 290 The configurations also differ depending on the desired mobility 291 supports: network-based mobility support for a flat network in 292 Section 3.1.1, network-based mobility support for a hierarchical 293 network in Section 3.1.2, host-based mobility support in 294 Section 3.1.3, and NEtwork MObility (NEMO) based support in 295 Section 3.1.4. 297 3.1.1. Network-based Mobility Support for a Flat Network 299 Figure 1 show the configurations of network-based distributed 300 mobility management for a flat network. 302 The features in Figure 1 are: 304 dmm:1 There are multiple instances of DPA, each with an FM-DP 305 function. 307 dmm:2 The control plane may either be distributed (not shown) or 308 centralized. The CPA and DPA may co-locate or may be 309 separate. When the CPA, each with an FM-CP function, is co- 310 located with the distributed DPA there will be multiple 311 instances of the co-located CPA and DPA (not shown). 313 dmm:3 An IP prefix/address IP1, which is anchored to the DPA with 314 the IP prefix/address IPa1, is assigned for use by an MN. The 315 MN uses IP1 to communicate with a CN not shown in the figure. 316 The flow of this communication session is shown as flow(IP1, 317 ...), meaning it uses IP1 and other parameters. 319 ____________ Network 320 ___/ \___________ 321 / +-----+ \___ 322 ( |LMs | Control \ 323 / +-.---+ plane \ 324 / +--------.---+ functions \ 325 ( |CPA: . | in the ) 326 ( |FM-CP, LMc | network ) 327 ( +------------+ \ 328 / . . \ 329 ( . . ) 330 ( . . ) 331 ( . . \ 332 \ +------------+ +------------+Distributed ) 333 ( |DPA(IPa1): | |DPA(IPa2): |DPA's ) 334 ( |anchors IP1 | |anchors IP2 | _/ 335 \ |FM-DP | |FM-DP | etc. / 336 \ +------------+ +------------+ / 337 \___ Data plane _____/ 338 \______ functions / 339 \__________________/ 341 +------------+ 342 |MN(IP1) | Mobile node attached 343 |flow(IP1,..)| to the network 344 +------------+ 346 Figure 1. Configurations of network-based mobility management for a 347 flat network to which MN is attached. The mobility management 348 functions in the network are LMs in the control plane, LMc at CPA, 349 and FM-DP at DPA. 351 In Figure 1, the LM function is split into a separate server LMs and 352 a client LMc at the CPA. Then, the LMs may be centralized whereas 353 the LMc may be distributed or centralized according to whether the 354 CPA is distributed (not shown) or centralized. 356 In a special case (not shown), LMs and LMc may co-locate. 358 3.1.2. Network-based Mobility Support for a Hierarchical Network 360 Figure 2 shows the configurations of network-based mobility 361 management for a hierarchical network. 363 +-----+ 364 |LMs | 365 +-.---+ 366 +--------.---+ 367 |CPA: . | 368 |FM-CP, LMp | 369 +------------+ 370 . . 371 . . 372 . . 373 . . 374 +------------+ +------------+ Distributed 375 |DPA(IPa1): | |DPA(IPa2): | DPA's 376 |anchors IP1 | |anchors IP2 | etc. 377 |FM-DP | |FM-DP | 378 +------------+ +------------+ 380 +------------+ 381 |CPN: | 382 |FM-CP, LMc | 383 +------------+ 384 . . 385 . . 386 . . 387 . .Distributed DPN's 388 +------------+ +------------+ +------------+ +------------+ 389 |DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22): | 390 |FM-DP | |FM-DP | etc. |FM-DP | |FM-DP | etc. 391 +------------+ +------------+ +------------+ +------------+ 393 +------------+Mobile node +------------+Mobile node 394 |MN(IP1) |using IP1 |MN(IP2) |using IP1 395 |flow(IP1,..)|anchored to |flow(IP2,..)|anchored to 396 +------------+DPA(IPa1) +------------+DPA(IPa2) 398 Figure 2. Configurations of network-based mobility management for a 399 hierarchical network to which MN is attached. The mobility 400 management functions in the network include a separate LMs, FM-CP and 401 LMp at CPA, FM-DP at DPA; FM-CP and LMc at CPN, FM-DP at DPN. 403 In addition to the dmm feature already described in Figure 1, 404 Figure 2 shows that there may be multiple instances of DPN, each with 405 an FM-DP function, for each DPA in the hierarchy. Also when the CPN, 406 each with an FM-CP function, is co-located with the distributed DPN 407 there will be multiple instances of the co-located CPN and DPN (not 408 shown). 410 In Figure 2 the LMs is separated out, and a proxy LMp at the CPA is 411 added between the separate LMs and LMc at the CPN. Then, LMs may be 412 centralized whereas the LMp may be distributed or centralized 413 according to whether the CPA is distributed or centralized. 415 In a particular case (not shown), LMs and LMp may co-locate. 417 3.1.3. Host-based Mobility Support 419 Host-based mobility function configurations as variants from Figure 2 420 is shown in Figure 3 where the role to perform mobility functions by 421 CPN and DPN are now taken by the MN. The MN then needs to possess 422 the mobility functions FM and LMc. 424 +-----+ 425 |LMs | 426 +-.---+ 427 +--------.---+ 428 |CPA: . | 429 |FM-CP, LMp | 430 +------------+ 431 . . 432 . . 433 . . 434 . . 435 +------------+ +------------+ Distributed 436 |DPA(IPa1): | |DPA(IPa2): | DPA's 437 |anchors IP1 | |anchors IP2 | 438 |FM-DP | |FM-DP | etc. 439 +------------+ +------------+ 441 +------------+ 442 |MN(IP1) |Mobile node 443 |flow(IP1,..)|using IP1 444 |FM, LMc |anchored to 445 +------------+DPA(IPa1) 447 Figure 3. Configuration of host-based mobility management. The 448 mobility management functions in the network include LMs in control 449 plane, FM-CP and LMp at CPA, FM-DP at DPA. The mobility management 450 functions FM and LMc are also at the host (MN). 452 Figure 3 shows configurations of host-based mobility management with 453 multiple instances of DPA for a distributed mobility anchoring 454 environment. Figure 3 can be obtained by simply collapsing CPN, DPN 455 and MN from the Figure 2 into the MN in Figure 3 which now possesses 456 the mobility functions FM and LMc that were performed previously by 457 the CPN and the DPN. 459 3.1.4. NEtwork MObility (NEMO) Basic Support 461 Figure 4 shows the configurations of NEMO basic support for a mobile 462 router. 464 +-----+ 465 |LMs | 466 +-.---+ 467 +--------.---+ 468 |CPA: . | 469 |FM-CP, LMp | 470 +------------+ 471 . . 472 . . 473 . . 474 . . 475 +--------------+ +--------------+ Distributed 476 |DPA(IPa1): | |DPA(IPa2): | DPA's 477 |anchors IP1 | |anchors IP2 | 478 |DHCPv6-PD IPn1| |DHCPv6-PD IPn2| etc. 479 |FM-DP | |FM-DP | 480 +--------------+ +--------------+ 482 +--------------+Mobile router 483 |MR(IP1) |using IP1 484 |delegated IPn1|anchored to 485 |FM, LMc |DPA(IPa1) 486 +--------------+ 488 +------------+Mobile network node 489 |MNN(IPn1) |using IPn1 490 |flow(IPn1,.)|attached to MR(IP1) 491 +------------+ 493 Figure 4. Configurations of NEMO basic support for an MR which is 494 attached to a network. The mobility management functions in the 495 network are a separate LMs, FM-CP and LMp at CPA, FM-DP at DPA. The 496 mobility management functions FM and LMc are also at the MR to which 497 MNN is attached. 499 Figure 4 shows configurations of host-based mobility management for 500 an MR with multiple instances of DPA for a distributed mobility 501 anchoring environment. Figure 4 can be obtained by simply changing 502 the MN from the Figure 3 into the MR carrying a mobile network 503 consisting of mobile network nodes (MNNs) in Figure 4. 505 An IP prefix/address IPn1 delegated to the MR is assigned for use by 506 the MNN in the mobile network. The MNN uses IPn1 to communicate with 507 a correspondent node (CN) not shown in the figure. The flow of this 508 communication session is shown as flow(IPn1, ...), meaning it uses 509 IPn1 and other parameters. 511 To enable the MR to assign the IP prefix IPn1, the DPA delegates the 512 prefix using DHCPv6-PD to the MR. 514 3.2. Operations and Parameters 516 The operations of distributed mobility anchoring are defined in order 517 that they might work together to produce a distributed mobility 518 solution. The needed information is passed as mobility message 519 parameters, which must be protected in terms of integrity. Some 520 parameters may require a means to support privacy of an MN or MR. 522 The mobility needs in 5G Wireless and beyond are diverse. Therefore 523 operations needed to enable different distributed mobility solutions 524 in different distributed mobility anchoring configurations are 525 extensive as illustrated below. It is however not necessary for 526 every distributed mobility solution to exhibit all the operations 527 listed in this section. A given distributed mobility solution may 528 exhibit only those operations needed. 530 3.2.1. Location Management 532 An example LM design consists of a distributed database with multiple 533 LMs servers. The location information about the prefix/address of an 534 MN is primarily at a given LMs. Peer LMs may exchange the location 535 information with each other. LMc may retrieve a given record or send 536 a given record update to LMs. 538 Location management configurations: 540 LM-cfg: As shown in Section 3.1: 542 LMs may be implemented at CPA, may be co-located with LMc at 543 CPA, or may be a separate server. 545 LMc may be at CPA, CPN, or MN. 547 LMp may proxy between LMs and LMc. 549 Specifically: 551 Location management operations and parameters: 553 LM-cfg:1 LMs and LMc may co-locate or may be separate, whereas LMc 554 is implemented in CPA in a flat network with network-based 555 mobility as shown in Figure 1 in Section 3.1.1. 557 LM-cfg:2 Either LMs may be a separate server with LMp implemented at 558 CPA, or LMs may be implemented at CPA. LMc is implemented 559 at CPN in a hierarchical network with network-based 560 mobility as shown in Figure 2 in Section 3.1.2, at MN for 561 host-based mobility as shown in Figure 3 in Section 3.1.3, 562 or at MR for network mobility as shown in Figure 4 in 563 Section 3.1.4. 565 LM-db: LM may manage the location information in a client-server 566 database system. 568 Example LM database functions are as follows: 570 LM-db:1 LMc may query LMs about location information for a prefix of 571 MN (pull). 572 Parameters: 574 - IP prefix of MN: integrity support required and privacy 575 support may be required. 577 LM-db:2 LMs may reply to LMc query about location information for a 578 prefix of MN (pull). 579 Parameters: 581 - IP prefix of MN: integrity support required and privacy 582 support may be required, 583 - IP address of FM-DP/DPA/DPN to forward the packets of the 584 flow: integrity support required. 586 LM-db:3 LMs may inform LMc about location information for a prefix 587 of MN (push). 588 Parameters: 590 - IP prefix of MN: integrity support required and privacy 591 support may be required, 592 - IP address of FM-DP/DPA/DPN to forward the packets of the 593 flow: integrity support required. 595 This function in the PMIPv6 protocol is the Update 596 Notification (UPN) together with the Update Notification 597 Acknowledgment (UPA) as defined in [RFC7077]. 599 LM-db:4 LMc may inform LMs about update location information for a 600 prefix of MN. 601 Parameters: 603 - IP prefix of MN: integrity support required and privacy 604 support may be required, 605 - IP address of FM-DP/DPA/DPN to forward the packets of the 606 flow: integrity support required. 608 This function in the MIPv6 / PMIPv6 protocol is the Binding 609 Update (BU) / Proxy Binding Update (PBU) together with the 610 Binding Acknowledgment (BA) / Proxy Binding Acknowledgment 611 (PBA) as defined in [RFC6275] / [RFC5213] respectively. 613 LM-db:5 The MN may be a host or a router. When the MN is an MR, the 614 prefix information may include the IP prefix delegated to 615 the MR. 616 Additional parameters: 618 - IP prefix delegated to MR: integrity support required and 619 privacy support may be required, 620 - IP prefix/address of the MR to forward the packets of the 621 prefix delegated to the MR: integrity support required. 623 LM-svr: The LM may be a distributed database with multiple LMs 624 servers. 626 For example: 628 LM-svr:1 A LMs may join a pool of LMs servers. 629 Parameters: 631 - IP address of the LMs: integrity support required, 632 - IP prefixes for which the LMs will host the primary 633 location information: integrity support required. 635 LM-svr:2 LMs may query a peer LMs about location information for a 636 prefix of MN. 637 Parameters: 639 - IP prefix: integrity support required and privacy support 640 may be required. 642 LM-svr:3 LMs may reply to a peer LMs about location information for 643 a prefix of MN. 644 Parameters: 646 - IP prefix of MN: integrity support required and privacy 647 support may be required, 648 - IP address of FM-DP/DPA/DPN to forward the packets of the 649 flow: integrity support required. 651 The list above only gives the minimal set of the required parameters. 652 In a specific mobility protocol, additional parameters should be 653 added as needed. Examples of these additional parameters are those 654 passed in the mobility options of the mobility header for MIPv6 655 [RFC6275] and for PMIPv6 [RFC5213]. 657 3.2.2. Forwarding Management 659 Forwarding management configurations: 661 FM-cfg: As shown in Section 3.1: 663 FM-CP may be implemented at CPA, CPN, MN depending on the 664 configuration chosen. 666 FM-DP may also be implemented at CPA, CPN, MN depending on 667 the configuration chosen. 669 Specifically: 671 FM-cfg:1 FM-CP and FM-DP may be implemented at CPA and DPA 672 respectively in a flat network with network-based mobility 673 as shown in Figure 1 in Section 3.1.1. 675 FM-cfg:2 FM-CP may be implemented at both CPA and CPN and FM-DP is 676 implemented at both DPA and DPN in a hierarchical network 677 with network-based mobility as shown in Figure 2 in 678 Section 3.1.2. 680 FM-cfg:3 FM-CP and FM-DP may be implemented at CPA and DPA 681 respectively and also both implemented at MN for host-based 682 mobility as shown in Figure 3 in Section 3.1.3. 684 FM-cfg:4 FM-CP and FM-DP may be implemented at CPA and DPA 685 respectively and also both implemented at MR for network 686 mobility as shown in Figure 4 in Section 3.1.4. 688 Forwarding management operations and parameters: 690 FM-find:1 An anchor may discover and be discovered such as through 691 an anchor registration system as follows: 693 FM-find:2 FM registers and authenticates itself with a centralized 694 mobility controller. 695 Parameters: 697 - IP address of DPA and its CPA: integrity support 698 required, 699 - IP prefix anchored to the DPA: integrity support 700 required. 702 Registration reply: acknowledge of registration and echo 703 the input parameters. 705 FM-find:3 FM discovers the FM of another IP prefix by querying the 706 mobility controller based on the IP prefix. 707 Parameters: 709 - IP prefix of MN: integrity support required and privacy 710 support may be required. 712 FM-find:4 When making anchor discovery FM expects the answer 713 parameters: 715 - IP address of DPA to which IP prefix of MN is anchored: 716 integrity support required, 717 - IP prefix of the corresponding CPA: integrity support 718 required. 720 FM-flow:1 The FM may be carried out on the packets to/from an MN up 721 to the granularity of a flow. 723 FM-flow:2 Example matching parameters are in the 5-tuple of a flow. 725 FM-path:1 FM may change the forwarding path of a flow upon a change 726 of point of attachment of an MN. Prior to the changes, 727 packets coming from the CN to the MN would traverse from 728 the CN to the home network anchor of the flow for the MN 729 before reaching the MN. Changes are from this original 730 forwarding path or paths to a new forwarding path or paths 731 from the CN to the current AR of the MN and then the MN 732 itself. 734 FM-path:2 As an incoming packet is forwarded from the CN to the MN, 735 the far end where forwarding path change begins may in 736 general be any node in the original forwarding path from 737 the CN to the home network DPA. The packet is forwarded 738 to the MN for host-based mobility and to a node in the 739 network which will deliver the packets to the MN for 740 network-based mobility. The near-end is generally a DPN 741 with a hierarchical network but may also be another node 742 with DPA capability in a flattened network. 744 FM-path:3 The mechanisms to accomplish such changes may include 745 changes to the forwarding table and indirection such as 746 tunneling, rewriting packet header, segment routing 747 [I-D.matsushima-spring-dmm-srv6-mobile-uplane], or NAT. 749 Note: An emphasis in this document in distributed mobility 750 anchoring is to explain the use of multiple anchors to 751 avoid unnecessarily long route which may be encountered in 752 centralized mobility anchoring. It is therefore not the 753 emphasis of this document on which particular mechanism to 754 choose from. 756 FM-path-tbl:4 The objective of forwarding table updates is to change 757 the forwarding path so that the packets in the flow 758 will be forwarded from the CN to the new AR instead of 759 the home network anchor or previous AR. Each of the 760 affected forwarding switches will need appropriate 761 changes to its forwarding table. 763 Specifically, such forwarding table updates may 764 include: (1) addition of forwarding table entries 765 needed to forward the packets destined to the MN to 766 the new AR; (2) deletion of forwarding table entries 767 to forward the packets destined to the MN to the home 768 network anchor or to the previous AR. 770 FM-path-tbl:5 With a centralized control plane, forwarding table 771 updates may be achieved through messaging between the 772 centralized control plane and the distributed 773 forwarding switches as described above (FM-cpdp) in 774 this section. 776 FM-path-tbl:6 To reduce excessive signaling, the scope of such 777 updates for a given flow may be confined to only those 778 forwarding switches such that only the packets sent 779 from the "CN" to the MN will go to the new AR. Such 780 confinement may be made when using a centralized 781 control plane possessing a global view of all the 782 forwarding switches. 784 FM-path-tbl:7 FM reverts the changes previously made to the 785 forwarding path of a flow when such changes are no 786 longer needed, e.g., when all the ongoing flows using 787 an IP prefix/address requiring IP session continuity 788 have closed. 790 FM-path-ind:8 Indirection forwards the incoming packets of the flow 791 from the DPA at the far end to a DPA/DPN at the near 792 end of indirection. Both ends of the indirection need 793 to know the LM information of the MN for the flow and 794 also need to possess FM capability to perform 795 indirection. 797 FM-path-ind:9 The mechanism of changing the forwarding path in MIPv6 798 [RFC6275] and PMIPv6 [RFC5213] is tunneling. In the 799 control plane, the FM-CP sets up the tunnel by 800 instructing the FM-DP at both ends of the tunnel. In 801 the data plane, the FM-DP at the start of the tunnel 802 performs packet encapsulation, whereas the FM-DP at 803 the end of the tunnel decapsulates the packet. 805 Note that in principle the ends of the indirection 806 path can be any pair of network elements with the FM- 807 DP function. 809 FM-path-ind:10 FM reverts the changes previously made to the 810 forwarding path of a flow when such changes are no 811 longer needed, e.g., when all the ongoing flows using 812 an IP prefix/address requiring IP session continuity 813 have closed. When tunneling is used, the tunnels will 814 be torn down when they are no longer needed. 816 FM-cpdp: With separation of control plane function and data plane 817 function, FM-CP and FM-DP communicate with each other. Such 818 communication may be realized by the appropriate messages in 819 [I-D.ietf-dmm-fpc-cpdp]. 821 For example: 823 FM-cpdp:1 CPA/FM-CP sends forwarding table updates to DPA/FM-DP. 824 Parameters: 826 - New forwarding table entries to add: integrity support 827 required, 828 - Expired forwarding table entries to delete: integrity 829 support required. 831 FM-cpdp:2 DPA/FM-DP sends to CPA/FM-CP about its status and load. 833 Parameters: 835 - State of forwarding function being active or not: 836 integrity support required, 837 - Loading percentage: integrity support required. 839 FM-CPA: The CPA possesses FM-CP function to make the changes to the 840 forwarding path as described in FM-path, and the changes may 841 be implemented through forwarding table changes or through 842 indirection as described respectively in FM-path-tbl and FM- 843 path-ind above. 845 The FM-CP communicates with the FM-DP using the appropriate 846 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 847 above so that it may instruct the FM-DP to perform the 848 changed forwarding tasks. 850 FM-DPA: The DPA possesses FM-DP function to forward packets according 851 to the changed forwarding path as described in FM-path, and 852 also FM-path-tbl or FM-path-ind depending on whether 853 forwarding table changes or indirection is used. 855 The FM-DP communicates with the FM-CP using the appropriate 856 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 857 above so that it may perform the changed forwarding tasks. 859 The operations and their parameters for the DPA to perform 860 distributed mobility management are described below: 862 FM-DPA:1 The DPAs perform the needed functions such that for the 863 incoming packets from the CN, forwarding path change by FM 864 is from the DPA at the far end which may be at any 865 forwarding switch (or even CN itself) in the original 866 forwarding path to the near end DPA/DPN. 868 FM-DPA:2 It is necessary that any incoming packet from the CN of the 869 flow must traverse the DPA (or at least one of the DPAs, 870 e.g., in the case of anycast) at the far end in order for 871 the packet to detour to a new forwarding path. Therefore a 872 convenient design is to locate the far end DPA at a unique 873 location which is always in the forwarding path. This is 874 the case in a centralized mobility design where the DPA at 875 the far end is the home network anchor of the flow. 877 Distributed mobility however may place the far end DPA at 878 other locations in order to avoid unnecessarily long route. 880 FM-DPA:3 With multiple nodes possessing DPA capabilities, the role 881 of FM to begin path change for the incoming packets of a 882 flow at the home network DPA at the far end may be passed 883 to or added to that of another DPA. 885 In particular, this DPA role may be moved upstream from the 886 home network DPA in the original forwarding path from CN to 887 MN. 889 FM-DPA:4 Optimization of the new forwarding path may be achieved 890 when the path change for the incoming packets begins at a 891 DPA where the original path and the direct IPv6 path 892 overlap. Then the new forwarding path will resemble the 893 direct IPv6 path from the CN to the MN. 895 FM-DPA-ind:5 Another mobility support employs indirection from the 896 far end DPA to the near end DPA. Both DPAs need to be 897 capable to performing indirection. For incoming 898 packets from the CN to the MN, the far end DPA needs to 899 start the indirection towards the near end DPA, which 900 will be the receiving end of indirection. In addition, 901 the near end DPA needs to continue the forwarding of 902 the packet towards the MN, such as through L2 903 forwarding or through another indirection towards the 904 MN. 906 FM-DPA-ind:6 With indirection, locating or moving the FM function to 907 begin indirection upstream along the forwarding path 908 from CN to MN again may help to reduce unnecessarily 909 long paths. 911 FM-DPA-ind:7 Changes made by FM to establish indirection at the DPA 912 and DPN, which are IPv6 nodes, at the ends of the path 913 change for a flow will be reverted when the mobility 914 support for the flow is no longer needed, e.g., when 915 the flows have terminated. 917 FM-buffer: An anchor can buffer packets of a flow in a mobility 918 event: 920 FM-buffer:1 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow. 921 Trigger: 923 - MN leaves DPA in a mobility event. 925 Parameters: 927 - IP prefix of the flow for which packets need to be 928 buffered: integrity support required 930 FM-buffer:2 CPA/FM-CP on behalf of a new DPA/FM-DP informs the CPA/ 931 FM-CP of the prior DPA/FM-DP that it is ready to receive 932 any buffered packets of a flow. 933 Parameters: 935 - Destination IP prefix of the flow's packets: integrity 936 support required, 937 - IP address of the new DPA: integrity support required. 939 FM-mr:1 When the MN is a mobile router (MR) the access router 940 anchoring the IP prefix of the MR will also own the IP 941 prefix or prefixes to be delegated to the MR. The MNNs in 942 the network carried by the MR obtain IP prefixes from the 943 MR. 945 4. IP Mobility Handling in Distributed Anchoring Environments - 946 Mobility Support Only When Needed 948 IP mobility support may be provided only when needed instead of being 949 provided by default. The LM and FM functions in the different 950 configurations shown in Section 3.1 are then utilized only when 951 needed. 953 A straightforward choice of mobility anchoring is for a flow to use 954 the IP prefix of the network to which the MN is attached when the 955 flow is initiated [I-D.seite-dmm-dma]. 957 The IP prefix/address at the MN's side of a flow may be anchored at 958 the access router to which the MN is attached. For example, when an 959 MN attaches to a network (Net1) or moves to a new network (Net2), an 960 IP prefix from the attached network is assigned to the MN's 961 interface. In addition to configuring new link-local addresses, the 962 MN configures from this prefix an IP address which is typically a 963 dynamic IP address. It then uses this IP address when a flow is 964 initiated. Packets to the MN in this flow are simply forwarded 965 according to the forwarding table. 967 There may be multiple IP prefixes/addresses that an MN can select 968 when initiating a flow. They may be from the same access network or 969 different access networks. The network may advertise these prefixes 970 with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node 971 may choose the one with the least cost. In addition, these IP 972 prefixes/addresses may be of different types regarding whether 973 mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow 974 will need to choose the appropriate one according to whether it needs 975 IP mobility support. 977 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 979 When IP mobility support is not needed for a flow, the LM and FM 980 functions are not utilized so that the configurations in Section 3.1 981 are simplified as shown in Figure 5. 983 Net1 Net2 985 +---------------+ +---------------+ 986 |AR1 | AR is changed |AR2 | 987 +---------------+ -------> +---------------+ 988 |CPA: | |CPA: | 989 |---------------| |---------------| 990 |DPA(IPa1): | |DPA(IPa2): | 991 |anchors IP1 | |anchors IP2 | 992 +---------------+ +---------------+ 994 +...............+ +---------------+ 995 .MN(IP1) . MN moves |MN(IP2) | 996 .flow(IP1,...) . =======> |flow(IP2,...) | 997 +...............+ +---------------+ 999 Figure 5. Changing to the new IP prefix/address. MN running a flow 1000 using IP1 in a network Net1 changes to running a flow using IP2 in 1001 Net2. 1003 When there is no need to provide IP mobility to a flow, the flow may 1004 use a new IP address acquired from a new network as the MN moves to 1005 the new network. 1007 Regardless of whether IP mobility is needed, if the flow has 1008 terminated before the MN moves to a new network, the flow may 1009 subsequently restart using the new IP address assigned from the new 1010 network. 1012 When IP session continuity is needed, even if a flow is ongoing as 1013 the MN moves, it may still be desirable for the flow to change to 1014 using the new IP prefix configured in the new network. The flow may 1015 then close and then restart using a new IP address configured in the 1016 new network. Such a change in the IP address of the flow may be 1017 enabled using a higher layer mobility support which is not in the 1018 scope of this document. 1020 In Figure 5, a flow initiated while the MN was using the IP prefix 1021 IP1 anchored to a previous access router AR1 in network Net1 has 1022 terminated before the MN moves to a new network Net2. After moving 1023 to Net2, the MN uses the new IP prefix IP2 anchored to a new access 1024 router AR2 in network Net2 to start a new flow. The packets may then 1025 be forwarded without requiring IP layer mobility support. 1027 An example call flow is outlined in Figure 6. 1029 MN AR1 AR2 CN 1030 |MN attaches to AR1: | | | 1031 |acquire MN-ID and profile | | 1032 |--RS---------------->| | | 1033 | | | | 1034 |<----------RA(IP1)---| | | 1035 | | | | 1036 Assigned prefix IP1 | | | 1037 IP1 address configuration | | 1038 | | | | 1039 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1040 | | | | 1041 |MN detaches from AR1 | | | 1042 |MN attaches to AR2 | | | 1043 | | | | 1044 |--RS------------------------------>| | 1045 | | | | 1046 |<--------------RA(IP2)-------------| | 1047 | | | | 1048 Assigned prefix IP2 | | | 1049 IP2 address configuration | | 1050 | | | | 1051 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1052 | | | | 1054 Figure 6. Re-starting a flow to use the IP prefix assigned from the 1055 network at which the MN is attached. 1057 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address 1059 A network may not need IP mobility support. For example, a network 1060 for stationary sensors only will never encounter mobility. 1062 The standard functions in IPv6 already include dropping the old IPv6 1063 prefix/address and acquiring new IPv6 prefix/address when the node 1064 changes its point of attachment to a new network. Therefore, a 1065 network not providing IP mobility support at all will not need any of 1066 the functions with the mobility operations and messages described in 1067 Section 3.2. 1069 On the other hand, a network supporting a mix of flows both requiring 1070 and not requiring IP mobility support will need the mobility 1071 functions, which it will invoke or not invoke as needed. 1073 The guidelines for the IPv6 nodes in a network supporting a mix of 1074 flows both requiring and not requiring IP mobility support include 1075 the following: 1077 GL-cfg:1 A network supporting a mix of flows both requiring and not 1078 requiring mobility support may take any of the 1079 configurations described in Section 3.1 and need to 1080 implement at the appropriate IPv6 nodes the mobility 1081 functions LM and FM as described respectively in LM-cfg and 1082 FM-cfg in Section 3.2 according to the configuration 1083 chosen. 1085 GL-mix:1 These mobility functions perform some of the operations 1086 with the appropriate messages as described in Section 3.2 1087 depending on which mobility mechanisms are being used. Yet 1088 these mobility functions must not be invoked for a flow 1089 that does not need IP mobility support so that it is 1090 necessary to be able to distinguish the needs of a flow. 1091 The guidelines for the MN and the AR are in the following. 1093 GL-mix:2 Regardless of whether there are flows requiring IP mobility 1094 support, when the MN changes its point of attachment to a 1095 new network, it needs to configure a new global IP address 1096 for use in the new network in addition to configuring the 1097 new link-local addresses. 1099 GL-mix:3 The MN needs to check whether a flow needs IP mobility 1100 support. This can be performed when the application is 1101 initiated. The specific method is not in the scope of this 1102 document. 1104 GL-mix:4 The information of whether a flow needs IP mobility support 1105 is conveyed to the network such as by choosing an IP 1106 address to be provided with mobility support as described 1107 in [I-D.ietf-dmm-ondemand-mobility]. Then as the MN 1108 attaches to a new network, if the MN was using an IP 1109 address that is not supposed to be provided with mobility 1110 support, the access router will not invoke the mobility 1111 functions described in Section 3.2 for this IP address. 1112 That is, the IP address from the prior network is simply 1113 not used in the new network. 1115 The above guidelines are only to enable distinguishing whether there 1116 is need of IP mobility support for a flow that does not. When the 1117 flow needs IP mobility support, the list of guidelines will continue 1118 in Section 4.2.1. 1120 4.2. Need of IP Mobility 1122 When IP mobility is needed for a flow, the LM and FM functions in 1123 Section 3.1 are utilized. The mobility support may be provided by IP 1124 prefix anchor switching to the new network to be described in 1125 Section 5 or by using other mobility management methods 1126 ([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and 1127 [Paper-Distributed.Mobility.Review]). Then the flow may continue to 1128 use the IP prefix from the prior network of attachment. Yet some 1129 time later, the user application for the flow may be closed. If the 1130 application is started again, the new flow may not need to use the 1131 prior network's IP address to avoid having to invoke IP mobility 1132 support. This may be the case where a dynamic IP prefix/address 1133 rather than a permanent one is used. The flow may then use the new 1134 IP prefix in the network where the flow is being initiated. Routing 1135 is again kept simpler without employing IP mobility and will remain 1136 so as long as the MN which is now in the new network has not moved 1137 again and left to another new network. 1139 An example call flow in this case is outlined in Figure 7. 1141 MN AR1 AR2 CN 1142 |MN attaches to AR1: | | | 1143 |acquire MN-ID and profile | | 1144 |--RS---------------->| | | 1145 | | | | 1146 |<----------RA(IP1)---| | | 1147 | | | | 1148 Assigned prefix IP1 | | | 1149 IP1 address configuration | | 1150 | | | | 1151 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1152 | | | | 1153 |MN detach from AR1 | | | 1154 |MN attach to AR2 | | | 1155 | | | | 1156 |--RS------------------------------>| | 1157 IP mobility support such as that described in next sub-section 1158 |<--------------RA(IP2,IP1)---------| | 1159 | | | | 1160 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1161 | | | | 1162 Assigned prefix IP2 | | | 1163 IP2 address configuration | | 1164 | | | | 1165 Flow(IP1,IPcn) terminates | | 1166 | | | | 1167 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1168 | | | | 1170 Figure 7. A flow continues to use the IP prefix from its home 1171 network after MN has moved to a new network. 1173 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility 1175 The configuration guidelines of distributed mobility for the IPv6 1176 nodes in a network supporting a mix of flows both requiring and not 1177 requiring distributed mobility support are as follows: 1179 GL-cfg:2 Multiple instances of DPAs (at access routers) which are 1180 providing IP prefix to the MNs are needed to provide 1181 distributed mobility anchoring in an appropriate 1182 configuration such as those described in Figure 1 1183 (Section 3.1.1) for network-based distributed mobility or 1184 in Figure 3 (Section 3.1.3) for host-based distributed 1185 mobility. 1187 The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) have to 1188 implement the mobility functions LM and FM as described 1189 respectively in LM-cfg and FM-cfg in Section 3.2 according 1190 to the configuration chosen. 1192 The guidelines of distributed mobility for the IPv6 nodes in a 1193 network supporting a mix of flows both requiring and not requiring 1194 distributed mobility support had begun with those given as GL-mix in 1195 Section 4.1.1 and continue as follows: 1197 GL-mix:5 The distributed anchors may need to message with each 1198 other. When such messaging is needed, the anchors may need 1199 to discover each other as described in the FM operations 1200 and mobility message parameters (FM-find) in Section 3.2.2. 1202 GL-mix:6 The anchors may need to provide mobility support on a per- 1203 flow basis as described in the FM operations and mobility 1204 message parameters (FM-flow) in Section 3.2.2. 1206 GL-mix:7 Then the anchors need to properly forward the packets of 1207 the flows in the appropriate FM operations and mobility 1208 message parameters depending on the specific mobility 1209 mechanism as described in Section 3.2.2. 1211 GL-mix:8 When using a mechanism of changing forwarding table 1212 entries, the FM operations and mobility message parameters 1213 are described in FM-path, FM-path-tbl, and FM-DPA in 1214 Section 3.2.2. 1216 The forwarding table updates will take place at AR1, AR2, 1217 the far end DPA, and other affected switches/routers such 1218 that the packet from the CN to the MN will traverse from 1219 the far end DPA towards AR2 instead of towards AR1. 1221 Therefore new entries to the forwarding table will be added 1222 at AR2 and the far end DPA as well as other affected 1223 switches/routers between them so that these packets will 1224 traverse towards AR2. Meanwhile, changes to the forwarding 1225 table entries will also occur at AR1 and the far end DPA as 1226 well as other affected switches/routers between them so 1227 that if these packets ever reach any of them, they will not 1228 traverse towards AR1 but will traverse towards AR2 (see 1229 Section 3.2.2). 1231 GL-mix:9 Alternatively when using a mechanism of indirection, the FM 1232 operations and mobility message parameters are described in 1233 FM-path, FM-path-ind, FM-DPA, and FM-DPA-ind in 1234 Section 3.2.2. 1236 GL-mix:10 If there are in-flight packets toward the old anchor while 1237 the MN is moving to the new anchor, it may be necessary to 1238 buffer these packets and then forward to the new anchor 1239 after the old anchor knows that the new anchor is ready. 1240 Such procedures are described in the FM operations and 1241 mobility message parameters (FM-buffer) in Section 3.2.2. 1243 5. IP Mobility Handling in Distributed Mobility Anchoring Environments 1244 - Anchor Switching to the New Network 1246 IP mobility is invoked to enable IP session continuity for an ongoing 1247 flow as the MN moves to a new network. Here the anchoring of the IP 1248 address of the flow is in the home network of the flow, which is not 1249 in the current network of attachment. A centralized mobility 1250 management mechanism may employ indirection from the anchor in the 1251 home network to the current network of attachment. Yet it may be 1252 difficult to avoid unnecessarily long route when the route between 1253 the MN and the CN via the anchor in the home network is significantly 1254 longer than the direct route between them. An alternative is to 1255 switch the IP prefix/address anchoring to the new network. 1257 5.1. IP Prefix/Address Anchor Switching for Flat Network 1259 The IP prefix/address anchoring may move without changing the IP 1260 prefix/address of the flow. Here the LM and FM functions in Figure 1 1261 in Section 3.1 are implemented as shown in Figure 8. 1263 Net1 Net2 1265 +---------------+ +---------------+ 1266 |AR1 | |AR2 | 1267 +---------------+ +---------------+ 1268 |CPA: | |CPA: | 1269 |LM:IP1 at IPa1 | |LM:IP1 at IPa2 | 1270 | changes to | | | 1271 | IP1 at IPa2 | | | 1272 |---------------| |---------------| 1273 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1274 |anchored IP1 | =======> |anchors IP2,IP1| 1275 +---------------+ +---------------+ 1277 +...............+ +---------------+ 1278 .MN(IP1) . MN moves |MN(IP2,IP1) | 1279 .flow(IP1,...) . =======> |flow(IP1,...) | 1280 +...............+ +---------------+ 1282 Figure 8. IP prefix/address anchor switching to the new network. MN 1283 with flow using IP1 in Net1 continues to run the flow using IP1 as it 1284 moves to Net2. 1286 As an MN with an ongoing session moves to a new network, the flow may 1287 preserve IP session continuity by moving the anchoring of the 1288 original IP prefix/address of the flow to the new network. One way 1289 to accomplish such move is to use a centralized routing protocol to 1290 be described in Section 5.2 with a centralized control plane. 1292 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network 1294 The configuration guideline for a flat network supporting a mix of 1295 flows both requiring and not requiring IP mobility support is: 1297 GL-cfg:3 Multiple instances of DPAs (at access routers) which are 1298 providing IP prefix to the MNs are needed to provide 1299 distributed mobility anchoring according to Figure 1 in 1300 Section 3.1 for a flat network. 1302 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1303 mobility functions LM and FM as described respectively in 1304 LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1306 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1307 IPv6 nodes for a network supporting a mix of flows both requiring and 1308 not requiring IP mobility support apply here. In addition, the 1309 following are required. 1311 GL-switch:1 The location management provides information about which 1312 IP prefix from an AR in the original network is being 1313 used by a flow in which AR in a new network. Such 1314 information needs to be deleted or updated when such 1315 flows have closed so that the IP prefix is no longer 1316 used in a different network. The LM operations are 1317 described in Section 3.2.1. 1319 GL-switch:2 The anchor operations to properly forward the packets 1320 for a flow are described in the FM operations and 1321 mobility message parameters in FM-path, FM-path-tbl, FM- 1322 cpdp, and FM-DPA in Section 3.2.2. If there are in- 1323 flight packets toward the old anchor while the MN is 1324 moving to the new anchor, it may be necessary to buffer 1325 these packets and then forward to the new anchor after 1326 the old anchor knows that the new anchor is ready as are 1327 described in FM-buffer in Section 3.2.2. The anchors 1328 may also need to discover each other as described also 1329 in the FM operations and mobility message parameters 1330 (FM-find). 1332 GL-switch:3 The security policy must allow to assign to the anchor 1333 node at the new network the original IP prefix/address 1334 used by the mobile node at the previous (original) 1335 network. As the assigned original IP prefix/address is 1336 to be used in the new network, the security policy must 1337 allow the anchor node in the new network to advertise 1338 the prefix of the original IP address and also allow the 1339 mobile node to send and receive data packets with the 1340 original IP address. 1342 GL-switch:4 The security policy must allow the mobile node to 1343 configure the original IP prefix/address used at the 1344 previous (original) network when the original IP prefix/ 1345 address is assigned by the anchor node in the new 1346 network. It must also allow the mobile node to use the 1347 original IP address for the previous flow in the new 1348 network. 1350 5.2. IP Prefix/Address Anchor Switching for Flat Network with 1351 Centralized Control Plane 1353 An example of IP prefix anchor switching is in the case where Net1 1354 and Net2 both belong to the same operator network with separation of 1355 control and data planes ([I-D.liu-dmm-deployment-scenario] and 1356 [I-D.matsushima-stateless-uplane-vepc]), where the controller may 1357 send to the switches/routers the updated information of the 1358 forwarding tables with the IP address anchoring of the original IP 1359 prefix/address at AR1 moved to AR2 in the new network. That is, the 1360 IP address anchoring in the original network which was advertising 1361 the prefix will need to move to the new network. As the anchoring in 1362 the new network advertises the prefix of the original IP address in 1363 the new network, the forwarding tables will be updated so that 1364 packets of the flow will be forwarded according to the updated 1365 forwarding tables. 1367 The configurations in Figure 1 in Section 3.1 for which the FM-CP and 1368 the LM are centralized and the FM-DPs are distributed apply here. 1369 Figure 9 shows its implementation where the LM is a binding between 1370 the original IP prefix/address of the flow and the IP address of the 1371 new DPA, whereas the FM uses appropriate control plane to data plane 1372 messages. 1374 Net1 Net2 1375 +----------------------------------------------------------------------+ 1376 | CPA: | 1377 | LM:IP1 at IPa2 | 1378 | FM-CP | 1379 +----------------------------------------------------------------------+ 1381 +---------------+ +---------------+ 1382 |AR1 | |AR2 | 1383 +---------------+ +---------------+ 1384 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1385 |anchored IP1 | =======> |anchors IP2,IP1| 1386 +---------------+ +---------------+ 1388 +...............+ +---------------+ 1389 .MN(IP1) . MN moves |MN(IP2,IP1) | 1390 .flow(IP1,...) . =======> |flow(IP1,...) | 1391 +...............+ +---------------+ 1393 Figure 9. IP prefix/address anchor switching to the new network with 1394 the LM and the FM-CP in a centralized control plane whereas the FM- 1395 DPs are distributed. 1397 The example call flow in Figure 10 shows that IP1 is assigned to MN 1398 when the MN attaches to the AR1 A flow running in MN and needing IP 1399 mobility may continue to use the previous IP prefix by moving the 1400 anchoring of the IP prefix to the new network. Yet a new flow to be 1401 initiated in the new network may simply use a new IP prefix assigned 1402 from the new network. 1404 MN AR1 AR2 CPA CN 1405 |MN attaches to AR1: | | | | 1406 |acquire MN-ID and profile | | | 1407 |--RS---------------->| | | | 1408 |<----------RA(IP1)---| | | | 1409 | | | Assign MN:IP1 | 1410 IP addr config | | | | 1411 | | | | | 1412 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1413 | | | | | 1414 |MN detach from AR1 | | | | 1415 |MN attach to AR2 | | | | 1416 | | | | | 1417 |--RS------------------------------>| | | 1418 | | | | | 1419 | |<---------------control messages-->| | 1420 | | | | | 1421 | | |<-control messages-->| | 1422 | | | | | 1423 | forwarding table updates <--------------| | 1424 | | | | | 1425 |<--------------RA(IP2,IP1)---------| | | 1426 | | | Assign MN:IP2 | 1427 IP addr config | | | | 1428 | | | | | 1429 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1430 | | | | | 1431 | Flow(IP1,IPcn,...) terminates | | | 1432 | | | | | 1433 | forwarding table updates <--------------| | 1434 | | | | | 1435 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1436 | | | | | 1438 Figure 10. DMM solution. MN with flow using IP1 in Net1 continues 1439 to run the flow using IP1 as it moves to Net2. 1441 As the MN moves from AR1 to AR2, the AR1 may exchange messages with 1442 CPA to release the IP1. It is now necessary for AR2 to learn the IP 1443 prefix of the MN from the previous network so that it will be 1444 possible for Net2 to assign both the previous network prefix and the 1445 new network prefix. The network may learn the previous prefix in 1446 different methods. For example, the MN may provide its previous 1447 network prefix information by including it to the RS message 1448 [I-D.jhlee-dmm-dnpp]. 1450 Then forwarding tables updates will take place here. 1452 In addition, the MN also needs a new IP in the new network. The AR2 1453 may now send RA to the MN with prefix information that includes IP1 1454 and IP2. The MN may then continue to use IP1. In addition, the 1455 prefix IP2 is assigned to the MN which may configure the IP addresses 1456 of its interface. Now for flows using IP1, packets destined to IP1 1457 will be forwarded to the MN via AR2. 1459 As such flows have terminated, IP1 goes back to Net1. MN will then 1460 be left with IP2 only, which it will use when it now starts a new 1461 flow. 1463 5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1464 Centralized CP 1466 The configuration guideline for a flat network with centralized 1467 control plane and supporting a mix of flows both requiring and not 1468 requiring IP mobility support is: 1470 GL-cfg:4 Multiple instances of DPAs (at access routers) which are 1471 providing IP prefix to the MNs are needed to provide 1472 distributed mobility anchoring according to Figure 1 in 1473 Section 3.1 with centralized control plane for a flat 1474 network. 1476 At the appropriate IPv6 nodes (CPA, DPA) have to implement 1477 the mobility functions LM and FM as described respectively 1478 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1480 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1481 IPv6 nodes for a network supporting a mix of flows both requiring and 1482 not requiring IP mobility support apply here. The guidelines (GL- 1483 mix) in Section 5.1.1 for moving anchoring for a flat network also 1484 apply here. In addition, the following are required. 1486 GL-switch:5 It was already mentioned that the anchor operations to 1487 properly forward the packets for a flow are described in 1488 the FM operations and mobility message parameters in FM- 1489 path, FM-path-tbl, FM-cpdp, and FM-DPA in Section 3.2.2 1490 and such changes are reverted later when the application 1491 has already closed. Here however, with separation of 1492 control and data planes for the anchors and where the 1493 LMs and the FM-CP are centralized in the same control 1494 plane, messaging between anchors and the discovery of 1495 anchors become internal to the control plane. 1497 GL-switch:6 The centralized FM-CP needs to communicate with the 1498 distributed FM-DP using the FM operations and mobility 1499 message parameters as described in FM-cpdp in 1500 Section 3.2.2. Such may be realized by the appropriate 1501 messages in [I-D.ietf-dmm-fpc-cpdp]. 1503 GL-switch:7 It was also already mentioned before that, if there are 1504 in-flight packets toward the previous anchor while the 1505 MN is moving to the new anchor, it may be necessary to 1506 buffer these packets and then forward to the new anchor 1507 after the old anchor knows that the new anchor is ready. 1508 Here however, the corresponding FM operations and 1509 mobility message parameters as described in 1510 Section 3.2.2 (FM-buffer) can be realized by the 1511 internal operations in the control plane together with 1512 signaling between the control plane and distributed data 1513 plane. These signaling may be realized by the 1514 appropriate messages in [I-D.ietf-dmm-fpc-cpdp]. 1516 5.3. Hierarchical Network 1518 The configuration for a hierarchical network has been shown in 1519 Figure 2 in Section 3.1.2. With centralized control plane, CPA and 1520 CPN, with the associated LM and FM-CP are all co-located. There are 1521 multiple DPAs (each with FM-DP) in distributed mobility anchoring. 1522 In the data plane, there are multiple DPNs (each with FM-DP) 1523 hierarchically below each DPA. The DPA at each AR supports 1524 forwarding to the DPN at each of a number of forwarding switches 1525 (FWs). A mobility event in this configuration belonging to 1526 distributed mobility management will be deferred to Section 5.4. 1528 In this distributed mobility configuration, a mobility event 1529 involving change of FW only but not of AR as shown in Figure 11 may 1530 still belong to centralized mobility management and may be supported 1531 using PMIPv6. This configuration of network-based mobility is also 1532 applicable to host-based mobility with the modification for the MN 1533 directly taking the role of DPN and CPN, and the corresponding 1534 centralized mobility event may be supported using MIPv6. 1536 In Figure 11, the IP prefix assigned to the MN is anchored at the 1537 access router (AR) supporting indirection to the old FW to which the 1538 MN was originally attached as well as to the new FW to which the MN 1539 has moved. 1541 The realization of LM may be the binding between the IP prefix/ 1542 address of the flow used by the MN and the IP address of the DPN to 1543 which MN has moved. The implementation of FM to enable change of FW 1544 without changing AR may be accomplished using tunneling between the 1545 AR and the FW as described in [I-D.korhonen-dmm-local-prefix] and in 1546 [I-D.templin-aerolink] or using some other L2 mobility mechanism. 1548 Net1 Net2 1549 +----------------------------------------------------------------------+ 1550 | CPA,CPN: LM:IP1 at IPn2 | 1551 | FM-CP | 1552 +----------------------------------------------------------------------+ 1554 +---------------+ 1555 |AR1 | 1556 +---------------+ 1557 |DPA(IPa1): | 1558 |anchors IP1 | 1559 |FM-DP | 1560 +---------------+ 1562 +---------------+ +---------------+ 1563 |FW1 | |FW2 | 1564 +---------------+ FW is changed +---------------+ 1565 |DPN(IPn1): | -------> |DPN(IPn2): | 1566 |FM-DP | |FM-DP | 1567 +---------------+ +---------------+ 1569 +...............+ +---------------+ 1570 .MN(IP1) . MN moves |MN(IP2) | 1571 .flow(IP1,...) . =======> |flow(IP1,...) | 1572 +...............+ +---------------+ 1574 Figure 11. Mobility without involving change of IP anchoring in a 1575 network in which the IP prefix assigned to the MN is anchored at an 1576 AR which is hierarchically above multiple FWs to which the MN may 1577 connect. 1579 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical Network with 1580 No Anchor Relocation 1582 The configuration guideline for a hierarchical network with 1583 centralized control plane and supporting a mix of flows both 1584 requiring and not requiring IP mobility support is: 1586 GL-cfg:5 Multiple instances of DPAs (at access routers) which are 1587 providing IP prefix to the MNs are needed to provide 1588 distributed mobility anchoring according to Figure 2 in 1589 Section 3.1.2 with centralized control plane for a 1590 hierarchical network. 1592 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1593 mobility functions LM and FM as described respectively in 1594 LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. 1596 Even when the mobility event does not involve change of anchor, it is 1597 still necessary to distinguish whether a flow needs IP mobility 1598 support. 1600 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1601 IPv6 nodes for a network supporting a mix of flows both requiring and 1602 not requiring IP mobility support apply here. In addition, the 1603 following are required. 1605 GL-switch:8 Here, the LM operations and mobility message parameters 1606 described in Section 3.2.1 provide information of which 1607 IP prefix from its FW needs to be used by a flow using 1608 which new FW. The anchor operations to properly forward 1609 the packets of a flow described in the FM operations and 1610 mobility message parameters (FM-path, FM-path-ind, FM- 1611 cpdp in Section 3.2.2) may be realized with PMIPv6 1612 protocol [I-D.korhonen-dmm-local-prefix] or with AERO 1613 protocol [I-D.templin-aerolink] to tunnel between the AR 1614 and the FW. 1616 5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network 1618 The configuration for the hierarchical network has been shown in 1619 Figure 2 in Section 3.1.2. Again, with centralized control plane, 1620 CPA and CPN, with the associated LM and FM-CP are all co-located. 1621 There are multiple DPAs (each with FM-DP) in distributed mobility 1622 anchoring. In the data plane, there are multiple DPNs (each with FM- 1623 DP) hierarchically below each DPA. The DPA at each AR supports 1624 forwarding to the DPN at each of a number of forwarding switches 1625 (FWs). 1627 A distributed mobility event in this configuration involves change 1628 from a previous DPN which is hierarchically under the previous DPA to 1629 a new DPN which is hierarchically under a new DPA. Such an event 1630 involving change of both DPA and DPN is shown in Figure 12. 1632 Net1 Net2 1633 +----------------------------------------------------------------------+ 1634 | CPA,CPN,Aggregate Router: LM:IP1 at IPn2 at IPa2 | 1635 | FM-CP | 1636 +----------------------------------------------------------------------+ 1638 +-----------------+ 1639 |Aggregate Router | 1640 +-----------------+ 1641 |FM-DP | 1642 +-----------------+ 1644 +---------------+ +---------------+ 1645 |AR1 | |AR2 | 1646 +---------------+ +---------------+ 1647 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1648 |anchored IP1 | =======> |anchors IP2,IP1| 1649 +---------------+ +---------------+ 1651 +---------------+ +---------------+ 1652 |FW1 | |FW2 | 1653 +---------------+ FW is changed +---------------+ 1654 |DPN(IPn1): | -------> |DPN(IPn2): | 1655 |FM-DP | |FM-DP | 1656 +---------------+ +---------------+ 1658 +...............+ +---------------+ 1659 .MN(IP1) . MN moves |MN(IP2,IP1) | 1660 .flow(IP1,...) . =======> |flow(IP1,...) | 1661 +...............+ +---------------+ 1663 Figure 12. Mobility involving change of IP anchoring in a network 1664 with hierarchy in which the IP prefix assigned to the MN is anchored 1665 at an Edge Router supporting multiple access routers to which the MN 1666 may connect. 1668 This deployment case involves both a change of anchor from AR1 to AR2 1669 and a network hierarchy AR-FW. It can be realized by a combination 1670 of relocating the IP prefix/address anchoring from AR1 to AR2 with 1671 the mechanism as described in Section 5.2 and then forwarding the 1672 packets with network hierarchy AR-FW as described in Section 5.3. 1674 5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1675 Hierarchical Network 1677 The configuration guideline (GL-cfg) for a hierarchical network with 1678 centralized control plane described in Section 5.3.1 applies here. 1680 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1681 IPv6 nodes for a network supporting a mix of flows both requiring and 1682 not requiring IP mobility support apply here. 1684 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1685 and in Section 5.2.1 for a centralized control plane also apply here. 1687 In addition, the guidelines for indirection between the new DPA and 1688 the new DPN as described in Section 5.3.1 apply as well. 1690 5.5. Network Mobility 1692 The configuration for network mobility has been shown in Figure 4 in 1693 Section 3.1.4. Again, with centralized control plane, CPA, with the 1694 associated LM and FM-CP are all co-located. There are multiple DPAs 1695 (each with FM-DP) in the data plane in distributed mobility 1696 anchoring. The MR possesses the mobility functions FM and LMc. The 1697 IP prefix IPn1 is delegated to the MR, to which an MNN is attached 1698 and has an IP address from IPn1 assigned to its interface. 1700 Figure 13 shows a distributed mobility event in a hierarchical 1701 network with a centralized control plane involving a change of 1702 attachment of the MR from a previous DPA to a new DPA while the MNN 1703 is attached to the MR and therefore moves with the MR. 1705 Net1 Net2 1706 +----------------------------------------------------------------------+ 1707 | CPA,Aggregate Router: LM:IP1 at IPa2; IPn1 at IP1 | 1708 | FM-CP, LM | 1709 +----------------------------------------------------------------------+ 1711 +-----------------+ 1712 |Aggregate Router | 1713 +-----------------+ 1714 |FM-DP | 1715 +-----------------+ 1717 +---------------+ +---------------+ 1718 |AR1 | |AR2 | 1719 +---------------+ +---------------+ 1720 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1721 |anchored IP1 | =======> |anchors IP2,IP1| 1722 |DHCPv6-PD IPn1 | | | 1723 |FM-DP | |FM-DP | 1724 +---------------+ +---------------+ 1726 +...............+ +---------------+ 1727 .MR(IP1) . MR moves |MR(IP2,IP1) | 1728 +...............+ =======> +---------------+ 1729 .FM, LMc . |FM, LMc | 1730 .delegated IPn1 . |delegated IPn1 | 1731 +...............+ +---------------+ 1733 +...............+ +---------------+ 1734 .MNN(IPn1) . MNN moves with MR |MNN(IPn1) | 1735 .flow(IPn1,...) . =======> |flow(IPn1,...) | 1736 +...............+ +---------------+ 1738 Figure 13. Mobility involving change of IP anchoring for an MR to 1739 which an MNN is attached. 1741 As the MR with source IP prefix IP1 moves from AR1 to AR2, mobility 1742 support may be provided by moving the anchoring of IP1 from AR1 to 1743 AR2 using the mechanism described in Section 5.2. 1745 The forwarding table updates will take place at AR1, AR2, the 1746 aggregate router, and other affected routers such that the packet 1747 from the CN to the MNN will traverse from the aggregate router 1748 towards AR2 instead of towards AR1. 1750 5.5.1. Additional Guidelines for IPv6 Nodes: Network mobility 1752 The configuration guideline for a network with centralized control 1753 plane to provide network mobility is: 1755 GL-cfg:6 Multiple instances of DPAs (at access routers) which are 1756 providing IP prefix of the MRs are needed to provide 1757 distributed mobility anchoring according to Figure 4 in 1758 Section 3.1. 1760 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1761 mobility functions LM and FM as described respectively in 1762 LM-cfg:3 or LM-cfg:4 and FM-cfg:4 in Section 3.2. 1764 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1765 IPv6 nodes for a network supporting a mix of flows both requiring and 1766 not requiring IP mobility support apply here. 1768 Here, because the MN is an MR, the following guideline is added: 1770 GL-mix:11 There are no flows requiring network mobility support when 1771 there are no MNNs attaching to the MR. Here there are also 1772 no MNNs using a prefix delegated to the MR. Therefore the 1773 anchor of the MR may change to a new AR. The new AR may 1774 delegate new IP prefix to the MR, so that the MR may 1775 support potential MNNs to attach to it. On the other hand 1776 the delegation of IP prefix to the MR from the old AR may 1777 be deleted. 1779 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1780 and in Section 5.2.1 for a centralized control plane also apply here. 1782 Again because the MN is an MR, the following guidelines are added: 1784 GL-switch:9 Network mobility may be provided using the FM operations 1785 and mobility message parameters as described in FM-mr in 1786 Section 3.2.2. 1788 GL-switch:10 The following changes to forwarding table entries are 1789 needed: 1791 New entries to the forwarding tables are added at AR2 1792 and the aggregate router as well as other affected 1793 switches/routers between them so that packets from the 1794 CN to the MNN destined to IPn1 will traverse towards 1795 AR2. Meanwhile, changes to the forwarding table will 1796 also occur at AR1 and the aggregate router as well as 1797 other affected switches/routers between them so that in 1798 case such packets ever reach any of these switches/ 1799 routers, the packets will not traverse towards AR1 but 1800 will traverse towards AR2. 1802 GL-switch:11 The security policy must allow the MNN to continue to 1803 own the IP prefix/address originally delegated to the MR 1804 and used by the MNN at the prior network. As this 1805 original IP prefix/address is to be used in the new 1806 network, the security policy must allow the anchor node 1807 to advertise the prefix of the original IP address and 1808 also allow the MNN to send and receive data packets with 1809 the original IP address. 1811 GL-switch:12 The security policy must allow the mobile router to 1812 configure the original IP prefix/address delegated to 1813 the MR from the previous (original) network when the 1814 original IP prefix/address is being delegated to the MR 1815 in the new network. The security policy must also 1816 allows to use the original IP address by the MNN for the 1817 previous flow in the new network. 1819 6. Security Considerations 1821 Security protocols and mechanisms are employed to secure the network 1822 and to make continuous security improvements, and a DMM solution is 1823 required to support them [RFC7333]. In a DMM deployment 1824 [I-D.ietf-dmm-deployment-models] various attacks such as 1825 impersonation, denial of service, man-in-the-middle attacks need to 1826 be prevented. An appropriate security management function as defined 1827 in Section 2 controls these security protocols and mechanisms to 1828 provide access control, integrity, authentication, authorization, 1829 confidentiality, etc. 1831 Security considerations are described in terms of integrity support, 1832 privacy support etc. in describing the mobility functions in 1833 Section 3.2. Here the mobility message parameters used in DMM must 1834 be protected, and some parameters require means to support MN and MR 1835 privacy. The security considerations are also described in the 1836 guidelines for IPv6 nodes in various subsections in Section 4, and 1837 Section 5. 1839 The IP address anchoring of an IP prefix is effectively moved from 1840 one network to another network to support IP mobility Section 5.1. 1841 As is considered in the guidelines for IPv6 nodes in Section 5.1.1, 1842 the security policy needs to enable the use in the new network of 1843 attachment the IP prefix assigned from another network. Yet it must 1844 do so without compromising on the needed security to prevent the 1845 possible misuse of an IP prefix belonging to another network. A 1846 viable solution is likely not be a global solution, but is limited in 1847 scope to within specific regions with the proper trust relationship. 1849 In network mobility, the MNN using an IP prefix assigned to it from 1850 the MR when the MR was in a prior network moves with the MR to a new 1851 network Section 5.5. As is considered in the guidelines for IPv6 1852 nodes in Section 5.5.1 to support IP mobility for an ongoing flow, 1853 the security management function needs to enable the continued use of 1854 this IP prefix by the MNN with MR in the new network of attachment. 1855 Yet it must do so without compromising on the needed security to 1856 prevent the possible misuse of an IP prefix belonging to another 1857 network. Again, a viable solution is likely not be a global 1858 solution, but is limited in scope to within specific regions with the 1859 proper trust relationship. 1861 7. IANA Considerations 1863 This document presents no IANA considerations. 1865 8. Contributors 1867 This document has benefited from other work on mobility support in 1868 SDN network, on providing mobility support only when needed, and on 1869 mobility support in enterprise network. These works have been 1870 referenced. While some of these authors have taken the work to 1871 jointly write this document, others have contributed at least 1872 indirectly by writing these drafts. The latter include Philippe 1873 Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, 1874 and Sri Gundavelli. 1876 Valuable comments have been received from John Kaippallimalil, 1877 ChunShan Xiong, and Dapeng Liu. Dirk von Hugo, Byju Pularikkal, 1878 Pierrick Seite, Carlos Bernardos have generously provided careful 1879 review with helpful corrections and suggestions. 1881 9. References 1883 9.1. Normative References 1885 [I-D.bernardos-dmm-cmip] 1886 Bernardos, C., Oliva, A., and F. Giust, "An IPv6 1887 Distributed Client Mobility Management approach using 1888 existing mechanisms", draft-bernardos-dmm-cmip-08 (work in 1889 progress), September 2017. 1891 [I-D.bernardos-dmm-pmip] 1892 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1893 solution for Distributed Mobility Management", draft- 1894 bernardos-dmm-pmip-09 (work in progress), September 2017. 1896 [I-D.ietf-dmm-deployment-models] 1897 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1898 Architectural Considerations", draft-ietf-dmm-deployment- 1899 models-03 (work in progress), November 2017. 1901 [I-D.ietf-dmm-fpc-cpdp] 1902 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1903 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1904 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 1905 (work in progress), October 2017. 1907 [I-D.ietf-dmm-ondemand-mobility] 1908 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 1909 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 1910 ondemand-mobility-12 (work in progress), July 2017. 1912 [I-D.jhlee-dmm-dnpp] 1913 Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", 1914 draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. 1916 [I-D.korhonen-dmm-local-prefix] 1917 Korhonen, J., Savolainen, T., and S. Gundavelli, "Local 1918 Prefix Lifetime Management for Proxy Mobile IPv6", draft- 1919 korhonen-dmm-local-prefix-01 (work in progress), July 1920 2013. 1922 [I-D.liu-dmm-deployment-scenario] 1923 Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, 1924 "Distributed mobility management deployment scenario and 1925 architecture", draft-liu-dmm-deployment-scenario-05 (work 1926 in progress), October 2015. 1928 [I-D.matsushima-spring-dmm-srv6-mobile-uplane] 1929 Matsushima, S., Filsfils, C., Kohno, M., and d. 1930 daniel.voyer@bell.ca, "Segment Routing IPv6 for Mobile 1931 User-Plane", draft-matsushima-spring-dmm-srv6-mobile- 1932 uplane-03 (work in progress), November 2017. 1934 [I-D.matsushima-stateless-uplane-vepc] 1935 Matsushima, S. and R. Wakikawa, "Stateless user-plane 1936 architecture for virtualized EPC (vEPC)", draft- 1937 matsushima-stateless-uplane-vepc-06 (work in progress), 1938 March 2016. 1940 [I-D.mccann-dmm-prefixcost] 1941 McCann, P. and J. Kaippallimalil, "Communicating Prefix 1942 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 1943 (work in progress), April 2016. 1945 [I-D.sarikaya-dmm-for-wifi] 1946 Sarikaya, B. and L. Li, "Distributed Mobility Management 1947 Protocol for WiFi Users in Fixed Network", draft-sarikaya- 1948 dmm-for-wifi-05 (work in progress), October 2017. 1950 [I-D.seite-dmm-dma] 1951 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 1952 Anchoring", draft-seite-dmm-dma-07 (work in progress), 1953 February 2014. 1955 [I-D.templin-aerolink] 1956 Templin, F., "Asymmetric Extended Route Optimization 1957 (AERO)", draft-templin-aerolink-75 (work in progress), May 1958 2017. 1960 [I-D.yhkim-dmm-enhanced-anchoring] 1961 Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in 1962 Distributed Mobility Management", draft-yhkim-dmm- 1963 enhanced-anchoring-05 (work in progress), July 2016. 1965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1966 Requirement Levels", BCP 14, RFC 2119, 1967 DOI 10.17487/RFC2119, March 1997, 1968 . 1970 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 1971 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 1972 . 1974 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1975 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1976 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1977 . 1979 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1980 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1981 2011, . 1983 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1984 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1985 Partnership Project (3GPP) Evolved Packet System (EPS)", 1986 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1987 . 1989 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 1990 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 1991 RFC 7077, DOI 10.17487/RFC7077, November 2013, 1992 . 1994 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1995 Korhonen, "Requirements for Distributed Mobility 1996 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1997 . 1999 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 2000 CJ. Bernardos, "Distributed Mobility Management: Current 2001 Practices and Gap Analysis", RFC 7429, 2002 DOI 10.17487/RFC7429, January 2015, 2003 . 2005 9.2. Informative References 2007 [Paper-Distributed.Mobility] 2008 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 2009 IP Mobility Management from the Perspective of the IETF: 2010 Motivations, Requirements, Approaches, Comparison, and 2011 Challenges", IEEE Wireless Communications, October 2013. 2013 [Paper-Distributed.Mobility.PMIP] 2014 Chan, H., "Proxy Mobile IP with Distributed Mobility 2015 Anchors", Proceedings of GlobeCom Workshop on Seamless 2016 Wireless Mobility, December 2010. 2018 [Paper-Distributed.Mobility.Review] 2019 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 2020 "Distributed and Dynamic Mobility Management in Mobile 2021 Internet: Current Approaches and Issues", February 2011. 2023 Authors' Addresses 2025 H. Anthony Chan (editor) 2026 Huawei Technologies 2027 5340 Legacy Dr. Building 3 2028 Plano, TX 75024 2029 USA 2031 Email: h.a.chan@ieee.org 2032 Xinpeng Wei 2033 Huawei Technologies 2034 Xin-Xi Rd. No. 3, Haidian District 2035 Beijing, 100095 2036 P. R. China 2038 Email: weixinpeng@huawei.com 2040 Jong-Hyouk Lee 2041 Sangmyung University 2042 31, Sangmyeongdae-gil, Dongnam-gu 2043 Cheonan 31066 2044 Republic of Korea 2046 Email: jonghyouk@smu.ac.kr 2048 Seil Jeon 2049 Sungkyunkwan University 2050 2066 Seobu-ro, Jangan-gu 2051 Suwon, Gyeonggi-do 2052 Republic of Korea 2054 Email: seiljeon@skku.edu 2056 Alexandre Petrescu 2057 CEA, LIST 2058 CEA Saclay 2059 Gif-sur-Yvette, Ile-de-France 91190 2060 France 2062 Phone: +33169089223 2063 Email: Alexandre.Petrescu@cea.fr 2065 Fred L. Templin 2066 Boeing Research and Technology 2067 P.O. Box 3707 2068 Seattle, WA 98124 2069 USA 2071 Email: fltemplin@acm.org