idnits 2.17.1 draft-ietf-dmm-distributed-mobility-anchoring-06.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 (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-bernardos-dmm-cmip-07 == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-pmip-08 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-deployment-models-01 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-07 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-11 == Outdated reference: A later version (-05) exists of draft-sarikaya-dmm-for-wifi-04 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-75 Summary: 0 errors (**), 0 flaws (~~), 9 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: January 4, 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 July 3, 2017 15 Distributed Mobility Anchoring 16 draft-ietf-dmm-distributed-mobility-anchoring-06 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 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 January 4, 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 (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 . . . . . . . . . . . . . . . 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 with its 168 correspondent node (CN). When there are multiple mobility anchors, 169 an address selection for a given flow is first required before the 170 flow is initiated. Using an anchor in an MN's network of attachment 171 has the advantage that the packets can simply be forwarded according 172 to the forwarding table. However, after the flow has been initiated, 173 the MN may later move to another network, so that the IP address no 174 longer 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 Figures 420 2 is shown in Figure 3 where the role to perform mobility functions 421 by 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. Figures 3 can be obtained by simply collapsing CPN, DPN 455 and MN from the Figures 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 a 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 a 500 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 Figures 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, or NAT. 748 Note: An emphasis in this document in distributed mobility 749 anchoring is to explain the use of multiple anchors to 750 avoid unnecessarily long route which may be encountered in 751 centralized mobility anchoring. It is therefore not the 752 emphasis of this document on which particular mechanism to 753 choose from. 755 FM-path-tbl:4 The objective of forwarding table updates is to change 756 the forwarding path so that the packets in the flow 757 will be forwarded from the CN to the new AR instead of 758 the home network anchor or previous AR. Each of the 759 affected forwarding switches will need appropriate 760 changes to its forwarding table. 762 Specifically, such forwarding table updates may 763 include: (1) addition of forwarding table entries 764 needed to forward the packets destined to the MN to 765 the new AR; (2) deletion of forwarding table entries 766 to forward the packets destined to the MN to the home 767 network anchor or to the previous AR. 769 FM-path-tbl:5 With a centralized control plane, forwarding table 770 updates may be achieved through messaging between the 771 centralized control plane and the distributed 772 forwarding switches as described above (FM-cpdp) in 773 this section. 775 FM-path-tbl:6 To reduce excessive signaling, the scope of such 776 updates for a given flow may be confined to only those 777 forwarding switches such that only the packets sent 778 from the "CN" to the MN will go to the new AR. Such 779 confinement may be made when using a centralized 780 control plane possessing a global view of all the 781 forwarding switches. 783 FM-path-tbl:7 FM reverts the changes previously made to the 784 forwarding path of a flow when such changes are no 785 longer needed, e.g., when all the ongoing flows using 786 an IP prefix/address requiring IP session continuity 787 have closed. 789 FM-path-ind:8 Indirection forwards the incoming packets of the flow 790 from the DPA at the far end to a DPA/DPN at the near 791 end of indirection. Both ends of the indirection need 792 to know the LM information of the MN for the flow and 793 also need to possess FM capability to perform 794 indirection. 796 FM-path-ind:9 The mechanism of changing the forwarding path in MIPv6 797 [RFC6275] and PMIPv6 [RFC5213] is tunneling. In the 798 control plane, the FM-CP sets up the tunnel by 799 instructing the FM-DP at both ends of the tunnel. In 800 the data plane, the FM-DP at the start of the tunnel 801 performs packet encapsulation, whereas the FM-DP at 802 the end of the tunnel decapsulates the packet. 804 Note that in principle the ends of the indirection 805 path can be any pair of network elements with the FM- 806 DP function. 808 FM-path-ind:10 FM reverts the changes previously made to the 809 forwarding path of a flow when such changes are no 810 longer needed, e.g., when all the ongoing flows using 811 an IP prefix/address requiring IP session continuity 812 have closed. When tunneling is used, the tunnels will 813 be torn down when they are no longer needed. 815 FM-cpdp: With separation of control plane function and data plane 816 function, FM-CP and FM-DP communicate with each other. Such 817 communication may be realized by the appropriate messages in 818 [I-D.ietf-dmm-fpc-cpdp]. 820 For example: 822 FM-cpdp:1 CPA/FM-CP sends forwarding table updates to DPA/FM-DP. 823 Parameters: 825 - New forwarding table entries to add: integrity support 826 required, 827 - Expired forwarding table entries to delete: integrity 828 support required. 830 FM-cpdp:2 DPA/FM-DP sends to CPA/FM-CP about its status and load. 831 Parameters: 833 - State of forwarding function being active or not: 834 integrity support required, 835 - Loading percentage: integrity support required. 837 FM-CPA: The CPA possesses FM-CP function to make the changes to the 838 forwarding path as described in FM-path, and the changes may 839 be implemented through forwarding table changes or through 840 indirection as described respectively in FM-path-tbl and FM- 841 path-ind above. 843 The FM-CP communicates with the FM-DP using the appropriate 844 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 845 above so that it may instruct the FM-DP to perform the 846 changed forwarding tasks. 848 FM-DPA: The DPA possesses FM-DP function to forward packets according 849 to the changed forwarding path as described in FM-path, and 850 also FM-path-tbl or FM-path-ind depending on whether 851 forwarding table changes or indirection is used. 853 The FM-DP communicates with the FM-CP using the appropriate 854 messages in [I-D.ietf-dmm-fpc-cpdp] as described in FM-cpdp 855 above so that it may perform the changed forwarding tasks. 857 The operations and their parameters for the DPA to perform 858 distributed mobility management are described below: 860 FM-DPA:1 The DPAs perform the needed functions such that for the 861 incoming packets from the CN, forwarding path change by FM 862 is from the DPA at the far end which may be at any 863 forwarding switch (or even CN itself) in the original 864 forwarding path to the near end DPA/DPN. 866 FM-DPA:2 It is necessary that any incoming packet from the CN of the 867 flow must traverse the DPA (or at least one of the DPAs, 868 e.g., in the case of anycast) at the far end in order for 869 the packet to detour to a new forwarding path. Therefore a 870 convenient design is to locate the far end DPA at a unique 871 location which is always in the forwarding path. This is 872 the case in a centralized mobility design where the DPA at 873 the far end is the home network anchor of the flow. 875 Distributed mobility however may place the far end DPA at 876 other locations in order to avoid unnecessarily long route. 878 FM-DPA:3 With multiple nodes possessing DPA capabilities, the role 879 of FM to begin path change for the incoming packets of a 880 flow at the home network DPA at the far end may be passed 881 to or added to that of another DPA. 883 In particular, this DPA role may be moved upstream from the 884 home network DPA in the original forwarding path from CN to 885 MN. 887 FM-DPA:4 Optimization of the new forwarding path may be achieved 888 when the path change for the incoming packets begins at a 889 DPA where the original path and the direct IPv6 path 890 overlap. Then the new forwarding path will resemble the 891 direct IPv6 path from the CN to the MN. 893 FM-DPA-ind:5 Another mobility support employs indirection from the 894 far end DPA to the near end DPA. Both DPAs need to be 895 capable to performing indirection. For incoming 896 packets from the CN to the MN, the far end DPA needs to 897 start the indirection towards the near end DPA, which 898 will be the receiving end of indirection. In addition, 899 the near end DPA needs to continue the forwarding of 900 the packet towards the MN, such as through L2 901 forwarding or through another indirection towards the 902 MN. 904 FM-DPA-ind:6 With indirection, locating or moving the FM function to 905 begin indirection upstream along the forwarding path 906 from CN to MN again may help to reduce unnecessarily 907 long paths. 909 FM-DPA-ind:7 Changes made by FM to establish indirection at the DPA 910 and DPN, which are IPv6 nodes, at the ends of the path 911 change for a flow will be reverted when the mobility 912 support for the flow is no longer needed, e.g., when 913 the flows have terminated. 915 FM-buffer: An anchor can buffer packets of a flow in a mobility 916 event: 918 FM-buffer:1 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow. 919 Trigger: 921 - MN leaves DPA in a mobility event. 923 Parameters: 925 - IP prefix of the flow for which packets need to be 926 buffered: integrity support required 928 FM-buffer:2 CPA/FM-CP on behalf of a new DPA/FM-DP informs the CPA/ 929 FM-CP of the prior DPA/FM-DP that it is ready to receive 930 any buffered packets of a flow. 931 Parameters: 933 - Destination IP prefix of the flow's packets: integrity 934 support required, 935 - IP address of the new DPA: integrity support required. 937 FM-mr:1 When the MN is a mobile router (MR) the access router 938 anchoring the IP prefix of the MR will also own the IP 939 prefix or prefixes to be delegated to the MR. The MNNs in 940 the network carried by the MR obtain IP prefixes from the 941 MR. 943 4. IP Mobility Handling in Distributed Anchoring Environments - 944 Mobility Support Only When Needed 946 IP mobility support may be provided only when needed instead of being 947 provided by default. The LM and FM functions in the different 948 configurations shown in Section 3.1 are then utilized only when 949 needed. 951 A straightforward choice of mobility anchoring is for a flow to use 952 the IP prefix of the network to which the MN is attached when the 953 flow is initiated [I-D.seite-dmm-dma]. 955 The IP prefix/address at the MN's side of a flow may be anchored at 956 the access router to which the MN is attached. For example, when an 957 MN attaches to a network (Net1) or moves to a new network (Net2), an 958 IP prefix from the attached network is assigned to the MN's 959 interface. In addition to configuring new link-local addresses, the 960 MN configures from this prefix an IP address which is typically a 961 dynamic IP address. It then uses this IP address when a flow is 962 initiated. Packets to the MN in this flow are simply forwarded 963 according to the forwarding table. 965 There may be multiple IP prefixes/addresses that an MN can select 966 when initiating a flow. They may be from the same access network or 967 different access networks. The network may advertise these prefixes 968 with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node 969 may choose the one with the least cost. In addition, these IP 970 prefixes/addresses may be of different types regarding whether 971 mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow 972 will need to choose the appropriate one according to whether it needs 973 IP mobility support. 975 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 977 When IP mobility support is not needed for a flow, the LM and FM 978 functions are not utilized so that the configurations in Section 3.1 979 are simplified as shown in Figure 5. 981 Net1 Net2 983 +---------------+ +---------------+ 984 |AR1 | AR is changed |AR2 | 985 +---------------+ -------> +---------------+ 986 |CPA: | |CPA: | 987 |---------------| |---------------| 988 |DPA(IPa1): | |DPA(IPa2): | 989 |anchors IP1 | |anchors IP2 | 990 +---------------+ +---------------+ 992 +...............+ +---------------+ 993 .MN(IP1) . MN moves |MN(IP2) | 994 .flow(IP1,...) . =======> |flow(IP2,...) | 995 +...............+ +---------------+ 997 Figure 5. Changing to the new IP prefix/address. MN running a flow 998 using IP1 in a network Net1 changes to running a flow using IP2 in 999 Net2. 1001 When there is no need to provide IP mobility to a flow, the flow may 1002 use a new IP address acquired from a new network as the MN moves to 1003 the new network. 1005 Regardless of whether IP mobility is needed, if the flow has 1006 terminated before the MN moves to a new network, the flow may 1007 subsequently restart using the new IP address assigned from the new 1008 network. 1010 When IP session continuity is needed, even if a flow is ongoing as 1011 the MN moves, it may still be desirable for the flow to change to 1012 using the new IP prefix configured in the new network. The flow may 1013 then close and then restart using a new IP address configured in the 1014 new network. Such a change in the IP address of the flow may be 1015 enabled using a higher layer mobility support which is not in the 1016 scope of this document. 1018 In Figure 5, a flow initiated while the MN was using the IP prefix 1019 IP1 anchored to a previous access router AR1 in network Net1 has 1020 terminated before the MN moves to a new network Net2. After moving 1021 to Net2, the MN uses the new IP prefix IP2 anchored to a new access 1022 router AR2 in network Net2 to start a new flow. The packets may then 1023 be forwarded without requiring IP layer mobility support. 1025 An example call flow is outlined in Figure 6. 1027 MN AR1 AR2 CN 1028 |MN attaches to AR1: | | | 1029 |acquire MN-ID and profile | | 1030 |--RS---------------->| | | 1031 | | | | 1032 |<----------RA(IP1)---| | | 1033 | | | | 1034 Assigned prefix IP1 | | | 1035 IP1 address configuration | | 1036 | | | | 1037 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1038 | | | | 1039 |MN detaches from AR1 | | | 1040 |MN attaches to AR2 | | | 1041 | | | | 1042 |--RS------------------------------>| | 1043 | | | | 1044 |<--------------RA(IP2)-------------| | 1045 | | | | 1046 Assigned prefix IP2 | | | 1047 IP2 address configuration | | 1048 | | | | 1049 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1050 | | | | 1052 Figure 6. Re-starting a flow to use the IP prefix assigned from the 1053 network at which the MN is attached. 1055 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address 1057 A network may not need IP mobility support. For example, a network 1058 for stationary sensors only will never encounter mobility. 1060 The standard functions in IPv6 already include dropping the old IPv6 1061 prefix/address and acquiring new IPv6 prefix/address when the node 1062 changes its point of attachment to a new network. Therefore, a 1063 network not providing IP mobility support at all will not need any of 1064 the functions with the mobility operations and messages described in 1065 Section 3.2. 1067 On the other hand, a network supporting a mix of flows both requiring 1068 and not requiring IP mobility support will need the mobility 1069 functions, which it will invoke or not invoke as needed. 1071 The guidelines for the IPv6 nodes in a network supporting a mix of 1072 flows both requiring and not requiring IP mobility support include 1073 the following: 1075 GL-cfg:1 A network supporting a mix of flows both requiring and not 1076 requiring mobility support may take any of the 1077 configurations described in Section 3.1 and need to 1078 implement at the appropriate IPv6 nodes the mobility 1079 functions LM and FM as described respectively in LM-cfg and 1080 FM-cfg in Section 3.2 according to the configuration 1081 chosen. 1083 GL-mix:1 These mobility functions perform some of the operations 1084 with the appropriate messages as described in Section 3.2 1085 depending on which mobility mechanisms are being used. Yet 1086 these mobility functions must not be invoked for a flow 1087 that does not need IP mobility support so that it is 1088 necessary to be able to distinguish the needs of a flow. 1089 The guidelines for the MN and the AR are in the following. 1091 GL-mix:2 Regardless of whether there are flows requiring IP mobility 1092 support, when the MN changes its point of attachment to a 1093 new network, it needs to configure a new global IP address 1094 for use in the new network in addition to configuring the 1095 new link-local addresses. 1097 GL-mix:3 The MN needs to check whether a flow needs IP mobility 1098 support. This can be performed when the application is 1099 initiated. The specific method is not in the scope of this 1100 document. 1102 GL-mix:4 The information of whether a flow needs IP mobility support 1103 is conveyed to the network such as by choosing an IP 1104 address to be provided with mobility support as described 1105 in [I-D.ietf-dmm-ondemand-mobility]. Then as the MN 1106 attaches to a new network, if the MN was using an IP 1107 address that is not supposed to be provided with mobility 1108 support, the access router will not invoke the mobility 1109 functions described in Section 3.2 for this IP address. 1110 That is, the IP address from the prior network is simply 1111 not used in the new network. 1113 The above guidelines are only to enable distinguishing whether there 1114 is need of IP mobility support for a flow that does not. When the 1115 flow needs IP mobility support, the list of guidelines will continue 1116 in Section 4.2.1. 1118 4.2. Need of IP Mobility 1120 When IP mobility is needed for a flow, the LM and FM functions in 1121 Section 3.1 are utilized. The mobility support may be provided by IP 1122 prefix anchor switching to the new network to be described in 1123 Section 5 or by using other mobility management methods 1124 ([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and 1125 [Paper-Distributed.Mobility.Review]). Then the flow may continue to 1126 use the IP prefix from the prior network of attachment. Yet some 1127 time later, the user application for the flow may be closed. If the 1128 application is started again, the new flow may not need to use the 1129 prior network's IP address to avoid having to invoke IP mobility 1130 support. This may be the case where a dynamic IP prefix/address 1131 rather than a permanent one is used. The flow may then use the new 1132 IP prefix in the network where the flow is being initiated. Routing 1133 is again kept simpler without employing IP mobility and will remain 1134 so as long as the MN which is now in the new network has not moved 1135 again and left to another new network. 1137 An example call flow in this case is outlined in Figure 7. 1139 MN AR1 AR2 CN 1140 |MN attaches to AR1: | | | 1141 |acquire MN-ID and profile | | 1142 |--RS---------------->| | | 1143 | | | | 1144 |<----------RA(IP1)---| | | 1145 | | | | 1146 Assigned prefix IP1 | | | 1147 IP1 address configuration | | 1148 | | | | 1149 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1150 | | | | 1151 |MN detach from AR1 | | | 1152 |MN attach to AR2 | | | 1153 | | | | 1154 |--RS------------------------------>| | 1155 IP mobility support such as that described in next sub-section 1156 |<--------------RA(IP2,IP1)---------| | 1157 | | | | 1158 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1159 | | | | 1160 Assigned prefix IP2 | | | 1161 IP2 address configuration | | 1162 | | | | 1163 Flow(IP1,IPcn) terminates | | 1164 | | | | 1165 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1166 | | | | 1168 Figure 7. A flow continues to use the IP prefix from its home 1169 network after MN has moved to a new network. 1171 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility 1173 The configuration guidelines of distributed mobility for the IPv6 1174 nodes in a network supporting a mix of flows both requiring and not 1175 requiring distributed mobility support are as follows: 1177 GL-cfg:2 Multiple instances of DPAs (at access routers) which are 1178 providing IP prefix to the MNs are needed to provide 1179 distributed mobility anchoring in an appropriate 1180 configuration such as those described in Figure 1 1181 (Section 3.1.1) for network-based distributed mobility or 1182 in Figure 3 (Section 3.1.3) for host-based distributed 1183 mobility. 1185 The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) have to 1186 implement the mobility functions LM and FM as described 1187 respectively in LM-cfg and FM-cfg in Section 3.2 according 1188 to the configuration chosen. 1190 The guidelines of distributed mobility for the IPv6 nodes in a 1191 network supporting a mix of flows both requiring and not requiring 1192 distributed mobility support had begun with those given as GL-mix in 1193 Section 4.1.1 and continue as follows: 1195 GL-mix:5 The distributed anchors may need to message with each 1196 other. When such messaging is needed, the anchors may need 1197 to discover each other as described in the FM operations 1198 and mobility message parameters (FM-find) in Section 3.2.2. 1200 GL-mix:6 The anchors may need to provide mobility support on a per- 1201 flow basis as described in the FM operations and mobility 1202 message parameters (FM-flow) in Section 3.2.2. 1204 GL-mix:7 Then the anchors need to properly forward the packets of 1205 the flows in the appropriate FM operations and mobility 1206 message parameters depending on the specific mobility 1207 mechanism as described in Section 3.2.2. 1209 GL-mix:8 When using a mechanism of changing forwarding table 1210 entries, the FM operations and mobility message parameters 1211 are described in FM-path, FM-path-tbl, and FM-DPA in 1212 Section 3.2.2. 1214 The forwarding table updates will take place at AR1, AR2, 1215 the far end DPA, and other affected switches/routers such 1216 that the packet from the CN to the MN will traverse from 1217 the far end DPA towards AR2 instead of towards AR1. 1219 Therefore new entries to the forwarding table will be added 1220 at AR2 and the far end DPA as well as other affected 1221 switches/routers between them so that these packets will 1222 traverse towards AR2. Meanwhile, changes to the forwarding 1223 table entries will also occur at AR1 and the far end DPA as 1224 well as other affected switches/routers between them so 1225 that if these packets ever reaches any of them, they will 1226 not traverse towards AR1 but will traverse towards AR2 (see 1227 Section 3.2.2). 1229 GL-mix:9 Alternatively when using a mechanism of indirection, the FM 1230 operations and mobility message parameters are described in 1231 FM-path, FM-path-ind, FM-DPA, and FM-DPA-ind in 1232 Section 3.2.2. 1234 GL-mix:10 If there are in-flight packets toward the old anchor while 1235 the MN is moving to the new anchor, it may be necessary to 1236 buffer these packets and then forward to the new anchor 1237 after the old anchor knows that the new anchor is ready. 1238 Such procedures are described in the FM operations and 1239 mobility message parameters (FM-buffer) in Section 3.2.2. 1241 5. IP Mobility Handling in Distributed Mobility Anchoring Environments 1242 - Anchor Switching to the New Network 1244 IP mobility is invoked to enable IP session continuity for an ongoing 1245 flow as the MN moves to a new network. Here the anchoring of the IP 1246 address of the flow is in the home network of the flow, which is not 1247 in the current network of attachment. A centralized mobility 1248 management mechanism may employ indirection from the anchor in the 1249 home network to the current network of attachment. Yet it may be 1250 difficult to avoid unnecessarily long route when the route between 1251 the MN and the CN via the anchor in the home network is significantly 1252 longer than the direct route between them. An alternative is to 1253 switch the IP prefix/address anchoring to the new network. 1255 5.1. IP Prefix/Address Anchor Switching for Flat Network 1257 The IP prefix/address anchoring may move without changing the IP 1258 prefix/address of the flow. Here the LM and FM functions in Figure 1 1259 in Section 3.1 are implemented as shown in Figure 8. 1261 Net1 Net2 1263 +---------------+ +---------------+ 1264 |AR1 | |AR2 | 1265 +---------------+ +---------------+ 1266 |CPA: | |CPA: | 1267 |LM:IP1 at IPa1 | |LM:IP1 at IPa2 | 1268 | changes to | | | 1269 | IP1 at IPa2 | | | 1270 |---------------| |---------------| 1271 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1272 |anchored IP1 | =======> |anchors IP2,IP1| 1273 +---------------+ +---------------+ 1275 +...............+ +---------------+ 1276 .MN(IP1) . MN moves |MN(IP2,IP1) | 1277 .flow(IP1,...) . =======> |flow(IP1,...) | 1278 +...............+ +---------------+ 1280 Figure 8. IP prefix/address anchor switching to the new network. MN 1281 with flow using IP1 in Net1 continues to run the flow using IP1 as it 1282 moves to Net2. 1284 As an MN with an ongoing session moves to a new network, the flow may 1285 preserve IP session continuity by moving the anchoring of the 1286 original IP prefix/address of the flow to the new network. One way 1287 to accomplish such move is to use a centralized routing protocol to 1288 be described in Section 5.2 with a centralized control plane. 1290 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network 1292 The configuration guideline for a flat network supporting a mix of 1293 flows both requiring and not requiring IP mobility support is: 1295 GL-cfg:3 Multiple instances of DPAs (at access routers) which are 1296 providing IP prefix to the MNs are needed to provide 1297 distributed mobility anchoring according to Figure 1 in 1298 Section 3.1 for a flat network. 1300 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1301 mobility functions LM and FM as described respectively in 1302 LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1304 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1305 IPv6 nodes for a network supporting a mix of flows both requiring and 1306 not requiring IP mobility support apply here. In addition, the 1307 following are required. 1309 GL-switch:1 The location management provides information about which 1310 IP prefix from an AR in the original network is being 1311 used by a flow in which AR in a new network. Such 1312 information needs to be deleted or updated when such 1313 flows have closed so that the IP prefix is no longer 1314 used in a different network. The LM operations are 1315 described in Section 3.2.1. 1317 GL-switch:2 The anchor operations to properly forward the packets 1318 for a flow are described in the FM operations and 1319 mobility message parameters in FM-path, FM-path-tbl, FM- 1320 cpdp, and FM-DPA in Section 3.2.2. If there are in- 1321 flight packets toward the old anchor while the MN is 1322 moving to the new anchor, it may be necessary to buffer 1323 these packets and then forward to the new anchor after 1324 the old anchor knows that the new anchor is ready as are 1325 described in FM-buffer in Section 3.2.2. The anchors 1326 may also need to discover each other as described also 1327 in the FM operations and mobility message parameters 1328 (FM-find). 1330 GL-switch:3 The security policy must allow to assign to the anchor 1331 node at the new network the original IP prefix/address 1332 used by the mobile node at the previous (original) 1333 network. As the assigned original IP prefix/address is 1334 to be used in the new network, the security policy must 1335 allow the anchor node in the new network to advertise 1336 the prefix of the original IP address and also allow the 1337 mobile node to send and receive data packets with the 1338 original IP address. 1340 GL-switch:4 The security policy must allow the mobile node to 1341 configure the original IP prefix/address used at the 1342 previous (original) network when the original IP prefix/ 1343 address is assigned by the anchor node in the new 1344 network. It must also allow the mobile node to use the 1345 original IP address for the previous flow in the new 1346 network. 1348 5.2. IP Prefix/Address Anchor Switching for Flat Network with 1349 Centralized Control Plane 1351 An example of IP prefix anchor switching is in the case where Net1 1352 and Net2 both belong to the same operator network with separation of 1353 control and data planes ([I-D.liu-dmm-deployment-scenario] and 1354 [I-D.matsushima-stateless-uplane-vepc]), where the controller may 1355 send to the switches/routers the updated information of the 1356 forwarding tables with the IP address anchoring of the original IP 1357 prefix/address at AR1 moved to AR2 in the new network. That is, the 1358 IP address anchoring in the original network which was advertising 1359 the prefix will need to move to the new network. As the anchoring in 1360 the new network advertises the prefix of the original IP address in 1361 the new network, the forwarding tables will be updated so that 1362 packets of the flow will be forwarded according to the updated 1363 forwarding tables. 1365 The configurations in Figure 1 in Section 3.1 for which the FM-CP and 1366 the LM are centralized and the FM-DPs are distributed apply here. 1367 Figure 9 shows its implementation where the LM is a binding between 1368 the original IP prefix/address of the flow and the IP address of the 1369 new DPA, whereas the FM uses appropriate control plane to data plane 1370 messages. 1372 Net1 Net2 1373 +----------------------------------------------------------------------+ 1374 | CPA: | 1375 | LM:IP1 at IPa2 | 1376 | FM-CP | 1377 +----------------------------------------------------------------------+ 1379 +---------------+ +---------------+ 1380 |AR1 | |AR2 | 1381 +---------------+ +---------------+ 1382 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1383 |anchored IP1 | =======> |anchors IP2,IP1| 1384 +---------------+ +---------------+ 1386 +...............+ +---------------+ 1387 .MN(IP1) . MN moves |MN(IP2,IP1) | 1388 .flow(IP1,...) . =======> |flow(IP1,...) | 1389 +...............+ +---------------+ 1391 Figure 9. IP prefix/address anchor switching to the new network with 1392 the LM and the FM-CP in a centralized control plane whereas the FM- 1393 DPs are distributed. 1395 The example call flow in Figure 10 shows that IP1 is assigned to MN 1396 when the MN attaches to the AR1 A flow running in MN and needing IP 1397 mobility may continue to use the previous IP prefix by moving the 1398 anchoring of the IP prefix to the new network. Yet a new flow to be 1399 initiated in the new network may simply use a new IP prefix assigned 1400 from the new network. 1402 MN AR1 AR2 CPA CN 1403 |MN attaches to AR1: | | | | 1404 |acquire MN-ID and profile | | | 1405 |--RS---------------->| | | | 1406 |<----------RA(IP1)---| | | | 1407 | | | Assign MN:IP1 | 1408 IP addr config | | | | 1409 | | | | | 1410 |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| 1411 | | | | | 1412 |MN detach from AR1 | | | | 1413 |MN attach to AR2 | | | | 1414 | | | | | 1415 |--RS------------------------------>| | | 1416 | | | | | 1417 | |<---------------control messages-->| | 1418 | | | | | 1419 | | |<-control messages-->| | 1420 | | | | | 1421 | forwarding table updates <--------------| | 1422 | | | | | 1423 |<--------------RA(IP2,IP1)---------| | | 1424 | | | Assign MN:IP2 | 1425 IP addr config | | | | 1426 | | | | | 1427 |<-Flow(IP1,IPcn,...)---------------+------------------------------->| 1428 | | | | | 1429 | Flow(IP1,IPcn,...) terminates | | | 1430 | | | | | 1431 | forwarding table updates <--------------| | 1432 | | | | | 1433 |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| 1434 | | | | | 1436 Figure 10. DMM solution. MN with flow using IP1 in Net1 continues 1437 to run the flow using IP1 as it moves to Net2. 1439 As the MN moves from AR1 to AR2, the AR1 may exchange messages with 1440 CPA to release the IP1. It is now necessary for AR2 to learn the IP 1441 prefix of the MN from the previous network so that it will be 1442 possible for Net2 to assign both the previous network prefix and the 1443 new network prefix. The network may learn the previous prefix in 1444 different methods. For example, the MN may provide its previous 1445 network prefix information by including it to the RS message 1446 [I-D.jhlee-dmm-dnpp]. 1448 Then forwarding tables updates will take place here. 1450 In addition, the MN also needs a new IP in the new network. The AR2 1451 may now send RA to the MN with prefix information that includes IP1 1452 and IP2. The MN may then continue to use IP1. In addition, the 1453 prefix IP2 is assigned to the MN which may configure the IP addresses 1454 of its interface. Now for flows using IP1, packets destined to IP1 1455 will be forwarded to the MN via AR2. 1457 As such flows have terminated, IP1 goes back to Net1. MN will then 1458 be left with IP2 only, which it will use when it now starts a new 1459 flow. 1461 5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1462 Centralized CP 1464 The configuration guideline for a flat network with centralized 1465 control plane and supporting a mix of flows both requiring and not 1466 requiring IP mobility support is: 1468 GL-cfg:4 Multiple instances of DPAs (at access routers) which are 1469 providing IP prefix to the MNs are needed to provide 1470 distributed mobility anchoring according to Figure 1 in 1471 Section 3.1 with centralized control plane for a flat 1472 network. 1474 At the appropriate IPv6 nodes (CPA, DPA) have to implement 1475 the mobility functions LM and FM as described respectively 1476 in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. 1478 The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the 1479 IPv6 nodes for a network supporting a mix of flows both requiring and 1480 not requiring IP mobility support apply here. The guidelines (GL- 1481 mix) in Section 5.1.1 for moving anchoring for a flat network also 1482 apply here. In addition, the following are required. 1484 GL-switch:5 It was already mentioned that the anchor operations to 1485 properly forward the packets for a flow are described in 1486 the FM operations and mobility message parameters in FM- 1487 path, FM-path-tbl, FM-cpdp, and FM-DPA in Section 3.2.2 1488 and such changes are reverted later when the application 1489 has already closed. Here however, with separation of 1490 control and data planes for the anchors and where the 1491 LMs and the FM-CP are centralized in the same control 1492 plane, messaging between anchors and the discovery of 1493 anchors become internal to the control plane. 1495 GL-switch:6 The centralized FM-CP needs to communicate with the 1496 distributed FM-DP using the FM operations and mobility 1497 message parameters as described in FM-cpdp in 1498 Section 3.2.2. Such may be realized by the appropriate 1499 messages in [I-D.ietf-dmm-fpc-cpdp]. 1501 GL-switch:7 It was also already mentioned before that, if there are 1502 in-flight packets toward the previous anchor while the 1503 MN is moving to the new anchor, it may be necessary to 1504 buffer these packets and then forward to the new anchor 1505 after the old anchor knows that the new anchor is ready. 1506 Here however, the corresponding FM operations and 1507 mobility message parameters as described in 1508 Section 3.2.2 (FM-buffer) can be realized by the 1509 internal operations in the control plane together with 1510 signaling between the control plane and distributed data 1511 plane. These signaling may be realized by the 1512 appropriate messages in [I-D.ietf-dmm-fpc-cpdp]. 1514 5.3. Hierarchical Network 1516 The configuration for a hierarchical network has been shown in 1517 Figure 2 in Section 3.1.2. With centralized control plane, CPA and 1518 CPN, with the associated LM and FM-CP are all co-located. There are 1519 multiple DPAs (each with FM-DP) in distributed mobility anchoring. 1520 In the data plane, there are multiple DPNs (each with FM-DP) 1521 hierarchically below each DPA. The DPA at each AR supports 1522 forwarding to the DPN at each of a number of forwarding switches 1523 (FWs). A mobility event in this configuration belonging to 1524 distributed mobility management will be deferred to Section 5.4. 1526 In this distributed mobility configuration, a mobility event 1527 involving change of FW only but not of AR as shown in Figure 11 may 1528 still belong to centralized mobility management and may be supported 1529 using PMIPv6. This configuration of network-based mobility is also 1530 applicable to host-based mobility with the modification for the MN 1531 directly taking the role of DPN and CPN, and the corresponding 1532 centralized mobility event may be supported using MIPv6. 1534 In Figure 11, the IP prefix assigned to the MN is anchored at the 1535 access router (AR) supporting indirection to the old FW to which the 1536 MN was originally attached as well as to the new FW to which the MN 1537 has moved. 1539 The realization of LM may be the binding between the IP prefix/ 1540 address of the flow used by the MN and the IP address of the DPN to 1541 which MN has moved. The implementation of FM to enable change of FW 1542 without changing AR may be accomplished using tunneling between the 1543 AR and the FW as described in [I-D.korhonen-dmm-local-prefix] and in 1544 [I-D.templin-aerolink] or using some other L2 mobility mechanism. 1546 Net1 Net2 1547 +----------------------------------------------------------------------+ 1548 | CPA,CPN: LM:IP1 at IPn2 | 1549 | FM-CP | 1550 +----------------------------------------------------------------------+ 1552 +---------------+ 1553 |AR1 | 1554 +---------------+ 1555 |DPA(IPa1): | 1556 |anchors IP1 | 1557 |FM-DP | 1558 +---------------+ 1560 +---------------+ +---------------+ 1561 |FW1 | |FW2 | 1562 +---------------+ FW is changed +---------------+ 1563 |DPN(IPn1): | -------> |DPN(IPn2): | 1564 |FM-DP | |FM-DP | 1565 +---------------+ +---------------+ 1567 +...............+ +---------------+ 1568 .MN(IP1) . MN moves |MN(IP2) | 1569 .flow(IP1,...) . =======> |flow(IP1,...) | 1570 +...............+ +---------------+ 1572 Figure 11. Mobility without involving change of IP anchoring in a 1573 network in which the IP prefix assigned to the MN is anchored at an 1574 AR which is hierarchically above multiple FWs to which the MN may 1575 connect. 1577 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical Network with 1578 No Anchor Relocation 1580 The configuration guideline for a hierarchical network with 1581 centralized control plane and supporting a mix of flows both 1582 requiring and not requiring IP mobility support is: 1584 GL-cfg:5 Multiple instances of DPAs (at access routers) which are 1585 providing IP prefix to the MNs are needed to provide 1586 distributed mobility anchoring according to Figure 2 in 1587 Section 3.1.2 with centralized control plane for a 1588 hierarchical network. 1590 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1591 mobility functions LM and FM as described respectively in 1592 LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. 1594 Even when the mobility event does not involve change of anchor, it is 1595 still necessary to distinguish whether a flow needs IP mobility 1596 support. 1598 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1599 IPv6 nodes for a network supporting a mix of flows both requiring and 1600 not requiring IP mobility support apply here. In addition, the 1601 following are required. 1603 GL-switch:8 Here, the LM operations and mobility message parameters 1604 described in Section 3.2.1 provide information of which 1605 IP prefix from its FW needs to be used by a flow using 1606 which new FW. The anchor operations to properly forward 1607 the packets of a flow described in the FM operations and 1608 mobility message parameters (FM-path, FM-path-ind, FM- 1609 cpdp in Section 3.2.2) may be realized with PMIPv6 1610 protocol [I-D.korhonen-dmm-local-prefix] or with AERO 1611 protocol [I-D.templin-aerolink] to tunnel between the AR 1612 and the FW. 1614 5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network 1616 The configuration for the hierarchical network has been shown in 1617 Figure 2 in Section 3.1.2. Again, with centralized control plane, 1618 CPA and CPN, with the associated LM and FM-CP are all co-located. 1619 There are multiple DPAs (each with FM-DP) in distributed mobility 1620 anchoring. In the data plane, there are multiple DPNs (each with FM- 1621 DP) hierarchically below each DPA. The DPA at each AR supports 1622 forwarding to the DPN at each of a number of forwarding switches 1623 (FWs). 1625 A distributed mobility event in this configuration involves change 1626 from a previous DPN which is hierarchically under the previous DPA to 1627 a new DPN which is hierarchically under a new DPA. Such an event 1628 involving change of both DPA and DPN is shown in Figure 12. 1630 Net1 Net2 1631 +----------------------------------------------------------------------+ 1632 | CPA,CPN,Aggregate Router: LM:IP1 at IPn2 at IPa2 | 1633 | FM-CP | 1634 +----------------------------------------------------------------------+ 1636 +-----------------+ 1637 |Aggregate Router | 1638 +-----------------+ 1639 |FM-DP | 1640 +-----------------+ 1642 +---------------+ +---------------+ 1643 |AR1 | |AR2 | 1644 +---------------+ +---------------+ 1645 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1646 |anchored IP1 | =======> |anchors IP2,IP1| 1647 +---------------+ +---------------+ 1649 +---------------+ +---------------+ 1650 |FW1 | |FW2 | 1651 +---------------+ FW is changed +---------------+ 1652 |DPN(IPn1): | -------> |DPN(IPn2): | 1653 |FM-DP | |FM-DP | 1654 +---------------+ +---------------+ 1656 +...............+ +---------------+ 1657 .MN(IP1) . MN moves |MN(IP2,IP1) | 1658 .flow(IP1,...) . =======> |flow(IP1,...) | 1659 +...............+ +---------------+ 1661 Figure 12. Mobility involving change of IP anchoring in a network 1662 with hierarchy in which the IP prefix assigned to the MN is anchored 1663 at an Edge Router supporting multiple access routers to which the MN 1664 may connect. 1666 This deployment case involves both a change of anchor from AR1 to AR2 1667 and a network hierarchy AR-FW. It can be realized by a combination 1668 of relocating the IP prefix/address anchoring from AR1 to AR2 with 1669 the mechanism as described in Section 5.2 and then forwarding the 1670 packets with network hierarchy AR-FW as described in Section 5.3. 1672 5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 1673 Hierarchical Network 1675 The configuration guideline (GL-cfg) for a hierarchical network with 1676 centralized control plane described in Section 5.3.1 applies here. 1678 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1679 IPv6 nodes for a network supporting a mix of flows both requiring and 1680 not requiring IP mobility support apply here. 1682 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1683 and in Section 5.2.1 for a centralized control plane also apply here. 1685 In addition, the guidelines for indirection between the new DPA and 1686 the new DPN as described in Section 5.3.1 apply as well. 1688 5.5. Network Mobility 1690 The configuration for network mobility has been shown in Figure 4 in 1691 Section 3.1.4. Again, with centralized control plane, CPA, with the 1692 associated LM and FM-CP are all co-located. There are multiple DPAs 1693 (each with FM-DP) in the data plane in distributed mobility 1694 anchoring. The MR possesses the mobility functions FM and LMc. The 1695 IP prefix IPn1 is delegated to the MR, to which an MNN is attached 1696 and has an IP address from IPn1 assigned to its interface. 1698 Figure 13 shows a distributed mobility event in a hierarchical 1699 network with a centralized control plane involving a change of 1700 attachment of the MR from a previous DPA to a new DPA while the MNN 1701 is attached to the MR and therefore moves with the MR. 1703 Net1 Net2 1704 +----------------------------------------------------------------------+ 1705 | CPA,Aggregate Router: LM:IP1 at IPa2; IPn1 at IP1 | 1706 | FM-CP, LM | 1707 +----------------------------------------------------------------------+ 1709 +-----------------+ 1710 |Aggregate Router | 1711 +-----------------+ 1712 |FM-DP | 1713 +-----------------+ 1715 +---------------+ +---------------+ 1716 |AR1 | |AR2 | 1717 +---------------+ +---------------+ 1718 |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): | 1719 |anchored IP1 | =======> |anchors IP2,IP1| 1720 |DHCPv6-PD IPn1 | | | 1721 |FM-DP | |FM-DP | 1722 +---------------+ +---------------+ 1724 +...............+ +---------------+ 1725 .MR(IP1) . MR moves |MR(IP2,IP1) | 1726 +...............+ =======> +---------------+ 1727 .FM, LMc . |FM, LMc | 1728 .delegated IPn1 . |delegated IPn1 | 1729 +...............+ +---------------+ 1731 +...............+ +---------------+ 1732 .MNN(IPn1) . MNN moves with MR |MNN(IPn1) | 1733 .flow(IPn1,...) . =======> |flow(IPn1,...) | 1734 +...............+ +---------------+ 1736 Figure 13. Mobility involving change of IP anchoring for a MR to 1737 which an MNN is attached. 1739 As the MR with source IP prefix IP1 moves from AR1 to AR2, mobility 1740 support may be provided by moving the anchoring of IP1 from AR1 to 1741 AR2 using the mechanism described in Section 5.2. 1743 The forwarding table updates will take place at AR1, AR2, the 1744 aggregate router, and other affected routers such that the packet 1745 from the CN to the MNN will traverse from the aggregate router 1746 towards AR2 instead of towards AR1. 1748 5.5.1. Additional Guidelines for IPv6 Nodes: Network mobility 1750 The configuration guideline for a network with centralized control 1751 plane to provide network mobility is: 1753 GL-cfg:6 Multiple instances of DPAs (at access routers) which are 1754 providing IP prefix of the MRs are needed to provide 1755 distributed mobility anchoring according to Figure 4 in 1756 Section 3.1. 1758 The appropriate IPv6 nodes (CPA, DPA) have to implement the 1759 mobility functions LM and FM as described respectively in 1760 LM-cfg:3 or LM-cfg:4 and FM-cfg:4 in Section 3.2. 1762 The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the 1763 IPv6 nodes for a network supporting a mix of flows both requiring and 1764 not requiring IP mobility support apply here. 1766 Here, because the MN is a MR, the following guideline is added: 1768 GL-mix:11 There are no flows requiring network mobility support when 1769 there are no MNN attaching to the MR. Here there are also 1770 no MNN using a prefix delegated to the MR. Therefore the 1771 anchor of the MR may change to a new AR. The new AR may 1772 delegate new IP prefix to the MR, so that the MR may 1773 support potential MNNs to attach to it. On the other hand 1774 the delegation of IP prefix to the MR from the old AR may 1775 be deleted. 1777 The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation 1778 and in Section 5.2.1 for a centralized control plane also apply here. 1780 Again because the MN is a MR, the following guidelines are added: 1782 GL-switch:9 Network mobility may be provided using the FM operations 1783 and mobility message parameters as described in FM-mr in 1784 Section 3.2.2. 1786 GL-switch:10 The following changes to forwarding table entries are 1787 needed: 1789 New entries to the forwarding tables are added at AR2 1790 and the aggregate router as well as other affected 1791 switches/routers between them so that packets from the 1792 CN to the MNN destined to IPn1 will traverse towards 1793 AR2. Meanwhile, changes to the forwarding table will 1794 also occur at AR1 and the aggregate router as well as 1795 other affected switches/routers between them so that in 1796 case such packets ever reach any of these switches/ 1797 routers, the packets will not traverse towards AR1 but 1798 will traverse towards AR2. 1800 GL-switch:11 The security policy must allow the MNN to continue to 1801 own the IP prefix/address originally delegated to the MR 1802 and used by the MNN at the prior network. As this 1803 original IP prefix/address is to be used in the new 1804 network, the security policy must allow the anchor node 1805 to advertise the prefix of the original IP address and 1806 also allow the MNN to send and receive data packets with 1807 the original IP address. 1809 GL-switch:12 The security policy must allow the mobile router to 1810 configure the original IP prefix/address delegated to 1811 the MR from the previous (original) network when the 1812 original IP prefix/address is being delegated to the MR 1813 in the new network. The security policy must also 1814 allows to use the original IP address by the MNNs for 1815 the previous flow in the new network. 1817 6. Security Considerations 1819 Security protocols and mechanisms are employed to secure the network 1820 and to make continuous security improvements, and a DMM solution is 1821 required to support them [RFC7333]. In a DMM deployment 1822 [I-D.ietf-dmm-deployment-models] various attacks such as 1823 impersonation, denial of service, man-in-the-middle attacks need to 1824 be prevented. An appropriate security management function as defined 1825 in Section 2 controls these security protocols and mechanisms to 1826 provide access control, integrity, authentication, authorization, 1827 confidentiality, etc. 1829 Security considerations are described in terms of integrity support, 1830 privacy support etc. in describing the mobility functions in 1831 Section 3.2. Here the mobility message parameters used in DMM must 1832 be protected, and some parameters require means to support MN and MR 1833 privacy. The security considerations are also described in the 1834 guidelines for IPv6 nodes in various subsections in Section 4, and 1835 Section 5. 1837 The IP address anchoring of an IP prefix is effectively moved from 1838 one network to another network to support IP mobility Section 5.1. 1839 As is considered in the guidelines for IPv6 nodes in Section 5.1.1, 1840 the security policy needs to enable the use in the new network of 1841 attachment the IP prefix assigned from another network. Yet it must 1842 do so without compromising on the needed security to prevent the 1843 possible misuse of an IP prefix belonging to another network. A 1844 viable solution is likely not be a global solution, but is limited in 1845 scope to within specific regions with the proper trust relationship. 1847 In network mobility, the MNN using an IP prefix assigned to it from 1848 the MR when the MR was in a prior network moves with the MR to a new 1849 network Section 5.5. As is considered in the guidelines for IPv6 1850 nodes in Section 5.5.1 to support IP mobility for an ongoing flow, 1851 the security management function needs to enable the continued use of 1852 this IP prefix by the MNN with MR in the new network of attachment. 1853 Yet it must do so without compromising on the needed security to 1854 prevent the possible misuse of an IP prefix belonging to another 1855 network. Again, a viable solution is likely not be a global 1856 solution, but is limited in scope to within specific regions with the 1857 proper trust relationship. 1859 7. IANA Considerations 1861 This document presents no IANA considerations. 1863 8. Contributors 1865 This document has benefited from other work on mobility support in 1866 SDN network, on providing mobility support only when needed, and on 1867 mobility support in enterprise network. These works have been 1868 referenced. While some of these authors have taken the work to 1869 jointly write this document, others have contributed at least 1870 indirectly by writing these drafts. The latter include Philippe 1871 Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, 1872 and Sri Gundavelli. 1874 Valuable comments have been received from John Kaippallimalil, 1875 ChunShan Xiong, and Dapeng Liu. Dirk von Hugo, Byju Pularikkal, 1876 Pierrick Seite, Carlos Bernardos have generously provided careful 1877 review with helpful corrections and suggestions. 1879 9. References 1881 9.1. Normative References 1883 [I-D.bernardos-dmm-cmip] 1884 Bernardos, C., Oliva, A., and F. Giust, "An IPv6 1885 Distributed Client Mobility Management approach using 1886 existing mechanisms", draft-bernardos-dmm-cmip-07 (work in 1887 progress), March 2017. 1889 [I-D.bernardos-dmm-pmip] 1890 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1891 solution for Distributed Mobility Management", draft- 1892 bernardos-dmm-pmip-08 (work in progress), March 2017. 1894 [I-D.ietf-dmm-deployment-models] 1895 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1896 Architectural Considerations", draft-ietf-dmm-deployment- 1897 models-01 (work in progress), February 2017. 1899 [I-D.ietf-dmm-fpc-cpdp] 1900 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1901 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1902 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-07 1903 (work in progress), March 2017. 1905 [I-D.ietf-dmm-ondemand-mobility] 1906 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 1907 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 1908 ondemand-mobility-11 (work in progress), June 2017. 1910 [I-D.jhlee-dmm-dnpp] 1911 Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", 1912 draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. 1914 [I-D.korhonen-dmm-local-prefix] 1915 Korhonen, J., Savolainen, T., and S. Gundavelli, "Local 1916 Prefix Lifetime Management for Proxy Mobile IPv6", draft- 1917 korhonen-dmm-local-prefix-01 (work in progress), July 1918 2013. 1920 [I-D.liu-dmm-deployment-scenario] 1921 Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, 1922 "Distributed mobility management deployment scenario and 1923 architecture", draft-liu-dmm-deployment-scenario-05 (work 1924 in progress), October 2015. 1926 [I-D.matsushima-stateless-uplane-vepc] 1927 Matsushima, S. and R. Wakikawa, "Stateless user-plane 1928 architecture for virtualized EPC (vEPC)", draft- 1929 matsushima-stateless-uplane-vepc-06 (work in progress), 1930 March 2016. 1932 [I-D.mccann-dmm-prefixcost] 1933 McCann, P. and J. Kaippallimalil, "Communicating Prefix 1934 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 1935 (work in progress), April 2016. 1937 [I-D.sarikaya-dmm-for-wifi] 1938 Sarikaya, B. and L. Xue, "Distributed Mobility Management 1939 Protocol for WiFi Users in Fixed Network", draft-sarikaya- 1940 dmm-for-wifi-04 (work in progress), March 2016. 1942 [I-D.seite-dmm-dma] 1943 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 1944 Anchoring", draft-seite-dmm-dma-07 (work in progress), 1945 February 2014. 1947 [I-D.templin-aerolink] 1948 Templin, F., "Asymmetric Extended Route Optimization 1949 (AERO)", draft-templin-aerolink-75 (work in progress), May 1950 2017. 1952 [I-D.yhkim-dmm-enhanced-anchoring] 1953 Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in 1954 Distributed Mobility Management", draft-yhkim-dmm- 1955 enhanced-anchoring-05 (work in progress), July 2016. 1957 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1958 Requirement Levels", BCP 14, RFC 2119, 1959 DOI 10.17487/RFC2119, March 1997, 1960 . 1962 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 1963 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 1964 . 1966 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1967 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1968 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1969 . 1971 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1972 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1973 2011, . 1975 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1976 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1977 Partnership Project (3GPP) Evolved Packet System (EPS)", 1978 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1979 . 1981 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 1982 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 1983 RFC 7077, DOI 10.17487/RFC7077, November 2013, 1984 . 1986 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1987 Korhonen, "Requirements for Distributed Mobility 1988 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1989 . 1991 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1992 CJ. Bernardos, "Distributed Mobility Management: Current 1993 Practices and Gap Analysis", RFC 7429, 1994 DOI 10.17487/RFC7429, January 2015, 1995 . 1997 9.2. Informative References 1999 [Paper-Distributed.Mobility] 2000 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 2001 IP Mobility Management from the Perspective of the IETF: 2002 Motivations, Requirements, Approaches, Comparison, and 2003 Challenges", IEEE Wireless Communications, October 2013. 2005 [Paper-Distributed.Mobility.PMIP] 2006 Chan, H., "Proxy Mobile IP with Distributed Mobility 2007 Anchors", Proceedings of GlobeCom Workshop on Seamless 2008 Wireless Mobility, December 2010. 2010 [Paper-Distributed.Mobility.Review] 2011 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 2012 "Distributed and Dynamic Mobility Management in Mobile 2013 Internet: Current Approaches and Issues", February 2011. 2015 Authors' Addresses 2017 H. Anthony Chan (editor) 2018 Huawei Technologies 2019 5340 Legacy Dr. Building 3 2020 Plano, TX 75024 2021 USA 2023 Email: h.a.chan@ieee.org 2025 Xinpeng Wei 2026 Huawei Technologies 2027 Xin-Xi Rd. No. 3, Haidian District 2028 Beijing, 100095 2029 P. R. China 2031 Email: weixinpeng@huawei.com 2032 Jong-Hyouk Lee 2033 Sangmyung University 2034 31, Sangmyeongdae-gil, Dongnam-gu 2035 Cheonan 31066 2036 Republic of Korea 2038 Email: jonghyouk@smu.ac.kr 2040 Seil Jeon 2041 Sungkyunkwan University 2042 2066 Seobu-ro, Jangan-gu 2043 Suwon, Gyeonggi-do 2044 Republic of Korea 2046 Email: seiljeon@skku.edu 2048 Alexandre Petrescu 2049 CEA, LIST 2050 CEA Saclay 2051 Gif-sur-Yvette, Ile-de-France 91190 2052 France 2054 Phone: +33169089223 2055 Email: Alexandre.Petrescu@cea.fr 2057 Fred L. Templin 2058 Boeing Research and Technology 2059 P.O. Box 3707 2060 Seattle, WA 98124 2061 USA 2063 Email: fltemplin@acm.org