idnits 2.17.1 draft-chan-dmm-framework-gap-analysis-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 == Line 205 has weird spacing: '...ocation is th...' == Line 1023 has weird spacing: '...ecurity buted...' == Line 1025 has weird spacing: '... first bil...' == Line 1055 has weird spacing: '...(HoA of cases...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 7, 2012) is 4159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ID-dmm-requirements' is mentioned on line 774, but not defined == Missing Reference: 'ID.seite-dmm-dma' is mentioned on line 1108, but not defined == Missing Reference: 'ID.liu-dmm-dynamic-anchor-discussion' is mentioned on line 1146, but not defined == Missing Reference: 'ID.bernardos-dmm-pmip' is mentioned on line 1136, but not defined == Missing Reference: 'ID.sarikaya-dmm-dmipv6' is mentioned on line 1132, but not defined == Missing Reference: 'I-D.liu-dmm-pmip-based-dmm-approach' is mentioned on line 1249, but not defined == Unused Reference: 'I-D.bernardos-dmm-distributed-anchoring' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: 'I-D.bernardos-dmm-pmip' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-dmm-dynamic-anchor-discussion' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-dmm-pmip-based-approach' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'I-D.patil-dmm-issues-and-approaches2dmm' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-dmm-dmipv6' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'I-D.xue-dmm-routing-optimization' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'MHA' is defined on line 1363, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-01 == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-pmip-01 == Outdated reference: A later version (-02) exists of draft-luo-dmm-pmip-based-dmm-approach-01 == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-05 == Outdated reference: A later version (-02) exists of draft-xue-dmm-routing-optimization-00 -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) Summary: 0 errors (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chan 3 Internet-Draft Huawei Technologies 4 Intended status: Informational P. Seite 5 Expires: May 11, 2013 France Telecom - Orange 6 K. Pentikousis 7 Huawei Technologies 8 JH. Lee 9 Telecom Bretagne 10 November 7, 2012 12 Framework for Mobility Management Protocol Analysis 13 draft-chan-dmm-framework-gap-analysis-06 15 Abstract 17 This document introduces a framework for analyzing mobility 18 management protocols in terms of their key abstracted logical 19 functions. The framework is capable of presenting a unified view, 20 reducing the clutter that obscures a casual reader from understanding 21 the commonalities between different approaches in mobility 22 management. More importantly, a first order application of this 23 framework allows us to examine previously standardized mobility 24 management protocols, such as MIPv6 and PMIPv6 (as well as several of 25 their extensions), and describe their core functionality in terms of 26 different configurations of the logical functions defined by the 27 framework. As a result, we can use the framework to analyze the gaps 28 between the protocols needed in a distributed mobility management 29 environment and the functionality provided by the current generation 30 of mobility management protocols. Our analysis points to the need 31 for a re-configuration of logical functions identified in the 32 framework as well as the need for new extensions which can make 33 distributed mobility management possible in the future. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 11, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 71 2.1. Conventions used in this document . . . . . . . . . . . . 6 72 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Mobility Management Logical Functions . . . . . . . . . . . . 7 74 4. Functional Representation of Existing Mobility Protocols . . . 7 75 4.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. MIPv6 versus PMIPv6 . . . . . . . . . . . . . . . . . . . 8 77 4.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . 10 78 4.4. Distributing mobility anchors . . . . . . . . . . . . . . 11 79 4.5. Migrating Home Agents . . . . . . . . . . . . . . . . . . 12 80 5. DMM Functional Scenarios . . . . . . . . . . . . . . . . . . . 14 81 5.1. Flat Network Scenario . . . . . . . . . . . . . . . . . . 14 82 5.1.1. Network-based Mobility Management . . . . . . . . . . 14 83 5.1.2. Client-based Mobility Management . . . . . . . . . . . 15 84 5.2. Fully distributed scenario with separation of control 85 and data planes . . . . . . . . . . . . . . . . . . . . . 16 86 6. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 6.1. DMM Requirements . . . . . . . . . . . . . . . . . . . . . 18 88 6.1.1. Considering existing protocols first . . . . . . . . . 18 89 6.1.2. Compatibility . . . . . . . . . . . . . . . . . . . . 18 90 6.1.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . 19 91 6.1.4. Security considerations . . . . . . . . . . . . . . . 19 92 6.1.5. Distributed deployment . . . . . . . . . . . . . . . . 20 93 6.1.6. Transparency to Upper Layers when needed . . . . . . . 20 94 6.1.7. Route optimization . . . . . . . . . . . . . . . . . . 21 95 6.2. Mobility Protocols Gap Analysis . . . . . . . . . . . . . 22 96 6.2.1. Gap analysis with the unified framework . . . . . . . 22 97 6.2.2. Gap analysis with MIPv6 . . . . . . . . . . . . . . . 22 98 6.2.3. Gap analysis with PMIPv6 . . . . . . . . . . . . . . . 22 99 6.2.4. Gap analysis with HMIPv6 . . . . . . . . . . . . . . . 22 100 6.2.5. Gap analysis with Distributing Mobility Anchors . . . 23 101 6.2.6. Gap analysis with HAHA . . . . . . . . . . . . . . . . 23 102 6.2.7. Gap analysis with Dynamic mobility management . . . . 23 103 6.2.8. Gap Analysis with Multiple MRs and Distributed LM 104 Database . . . . . . . . . . . . . . . . . . . . . . . 24 105 6.2.9. Gap Analysis with Route Optimization Mechanisms . . . 24 106 6.3. Gap analysis summary . . . . . . . . . . . . . . . . . . . 24 107 7. DMM analysis . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 7.1. DMM scenarios and Dynamic mobility management 109 requirement . . . . . . . . . . . . . . . . . . . . . . . 26 110 7.2. Route optimization of DMM scenarios . . . . . . . . . . . 27 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 115 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 118 1. Introduction 120 While there is ongoing research on new protocols for distributed 121 mobility management (DMM), it has also been proposed, e.g., in 122 [Paper-Distributed.Mobility.PMIP] and in other publications, that a 123 distributed mobility management architecture can be designed using 124 primarily existing mobility management protocols with some 125 extensions. This is reflected in the requirement presented in [ID- 126 dmm-requirements]: distributed mobility management is to first use 127 existing protocols and their extensions before considering new 128 protocol designs. 130 Mobile IPv6 [RFC6275], which is a logically centralized mobility 131 management approach addressing primarily hierarchical mobile 132 networks, has numerous variants and extensions including, just to 133 name a few, PMIPv6 [RFC5213], Hierarchical MIPv6 (HMIPv6) [RFC5380], 134 Fast MIPv6 (FMIPv6) [RFC4068] [RFC4988], Proxy-based FMIPv6 (PFMIPv6) 135 [RFC5949]. These variants or extensions of MIPv6 have been developed 136 over the years owing to the different needs that have been arising 137 ever since the first specification of MIP came into life. 139 This document argues that we can gain much more insights into this 140 design space by abstracting functions of existing mobility management 141 protocols in terms of logical functions. Different variants of 142 existing mobility management protocols can then be expressed as 143 different design variations of how these logical functions are put 144 together. The result is a rich framework that can express 145 sophisticated functionalities in a more straightforward manner and 146 can be used to perform gap analysis of existing protocols. What is 147 more, this document shows how to reconfigure these logical functions 148 towards various distributed mobility management designs. 150 The following subsection presents an overview of this document. 152 1.1. Overview 154 Section 3 proposes to abstract existing mobility management protocol 155 functions into three logical functions, namely, home address 156 allocation, mobility routing and location management. Such 157 functional decomposition will enable us to clearly separate data 158 plane and the control plane functionality, and gives us the 159 flexibility in an implementation to position said logical functions 160 at their most appropriate places in the system design. 162 Section 4 shows that these logical functions can indeed perform the 163 same functions as the major existing mobility protocols. These 164 functions therefore become the foundation for a unified framework 165 upon which different designs of distributed mobility management may 166 be built upon. 168 Section 6 presents the gap analysis of existing protocols by 169 comparing them against the DMM requirements as per [ID-dmm- 170 requirements]. 172 Extensions to overcome the gaps are presented in Sections 5 and 7. 173 Based on the introduced unified framework, extensions to dynamically 174 provide mobility support are described in Section 7.1 where the home 175 IP address of an MN is generalized to that of an application session. 176 A distributed database architecture is described in Section 5.1. 177 Using this distributed architecture, various route optimizations can 178 be defined as explained in Section 7.2. 180 2. Conventions and Terminology 182 2.1. Conventions used in this document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 2.2. Terminology 190 All general mobility-related terms and their acronyms used in this 191 document are to be interpreted as defined in the Mobile IPv6 base 192 specification [RFC6275] and in the Proxy mobile IPv6 specification 193 [RFC5213]. These terms include mobile node (MN), correspondent node 194 (CN), home agent (HA), local mobility anchor (LMA), and mobile access 195 gateway (MAG). 197 In addition, this document uses the following terms: 199 Mobility routing (MR) is the logical function that intercepts 200 packets to/from the HoA of a mobile node and forwards them, based 201 on internetwork location information, either directly towards 202 their destination or to some other network element that knows how 203 to forward the packets to their ultimate destination. 205 Home address allocation is the logical function that allocates the 206 home network prefix or home address to a mobile node. 208 Location management (LM) is the logical function that manages and 209 keeps track of the internetwork location information of a mobile 210 node, which includes the mapping of the MN HoA to the MN routing 211 address or another network element that knows where to forward 212 packets destined for the MN. 214 Home network of an application session (or an HoA IP address) is the 215 network that has allocated the IP address used as the session 216 identifier (HoA) by the application being run in an MN. The MN 217 may be attached to more than one home networks. 219 3. Mobility Management Logical Functions 221 The existing mobility management functions of MIPv6, PMIPv6, and 222 HMIPv6 ca be abstracted into the following logical functions: 224 1. Anchoring: allocation of home network prefix or HoA to an MN that 225 registers with the network; 227 2. Mobility Routing (MR) function: packets interception and 228 forwarding to/from the HoA of the MN, based on the internetwork 229 location information, either to the destination or to some other 230 network element that knows how to forward the packets to their 231 destination; 233 3. Internetwork Location Management (LM) function: managing and 234 keeping track of the internetwork location of an MN, which 235 includes a mapping of the HoA to the mobility anchoring point 236 that the MN is anchored to; 238 4. Location Update (LU): provisioning of MN location information to 239 the LM function; 241 5. Routing Control (RC): this logical function configures the 242 forwarding state of the mobility routing function. 244 4. Functional Representation of Existing Mobility Protocols 246 This section shows that existing mobility management protocols can be 247 expressed as different configurations of the logical functions 248 introduced in Section 3 above. 250 Using these generic logical functions, we will build up the existing 251 mobility protocols one step at a time in the following sequence: 252 MIPv6, PMIPv6, HMIPv6, and HAHA. Functions are added and modified as 253 needed in each step. 255 4.1. Mobile IPv6 257 Figure 1 shows Mobile IPv6 [RFC6275] in a functional representation. 258 The combination of the logical functions MR, LM and HoA allocation in 259 network1 is the home agent or the mobility anchor. The mobile node 260 MN11 was originally attached to Network1 and was allocated the IP 261 prefix for its home address HoA11. After some time, MN11 moved to 262 Network3, from which it is allocated a new prefix to configure the IP 263 address IP32. LM1 maintains the binding HoA11:IP32 so that packets 264 from CN21 in Network2 destined to HoA11 will be intercepted by MR1, 265 which will then tunnel them to IP32. MN11 must perform mobility 266 signaling using the LU function. 268 Network1 Network3 Network2 269 +-----+ 270 | LM1 | 271 +-----+ 272 location=IP32 273 HoA1 alc IP3 alc IP2 alc 274 | 275 | 276 +-----+ 277 | MR1 | 278 +-----+ 279 . 280 . +----+ +----+ +----+ 281 . |MN31| |MN11| |CN21| 282 . | | |+LU | | | 283 . +----+ +----+ +----+ 284 HoA11 IP31 IP32, 285 HoA11 287 Figure 1. Functional decomposition of Mobile IPv6. 289 4.2. MIPv6 versus PMIPv6 291 MIPv6 and PMIPv6 both employ the same concept of separating the 292 session identifier from the routing address into the HoA and CoA, 293 respectively. Figure 2 contrasts (a) MIPv6 and (b) PMIPv6 by showing 294 the destination IP address in the network-layer header as a packet 295 traverses from a CN to an MN. 297 (a) MIPv6: 298 +---+ +---+---+ +---+ 299 |HoA| --> |HoA|HoA| |HoA| 300 | | | |---| |---| 301 | | | |CoA| ==> |CoA| 302 +---+ +---+---+ +---+ 303 CN MR MN+LU 305 (b) PMIPv6: 306 +---+ +---+---+ +---+---+ +---+ 307 |HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA| 308 | | | |---| |---| | | | 309 | | | |CoA| ==> |CoA| | | | 310 +---+ +---+---+ +---+---+ +---+ 311 CN MR AR+LU MN 313 Figure 2. Network layer in the protocol stack of packets sent from 314 the CN and tunneled (a) to the MN+LU in MIPv6; and (b) to the AR+LU 315 in PMIPv6 showing the destination IP address as the packet traverses 316 from the CN to the MN. 318 Figure 2 shows that, as far as data-plane traffic is concerned, 319 routing from CN to MN+LU in MIPv6 is similar to the route from CN to 320 AR+LU in PMIPv6. The difference is in that the MN with the LU 321 function is substituted by the combination of the AR with the LU 322 function and the MN. While additional signaling is needed to enable 323 the combination of AR+LU and MN to behave like MN+LU, such signaling 324 can be confined between the AR+LU and MN only. It can therefore be 325 seen under this unified formulation, that a host-based mobility 326 management protocol can be translated using this substitution into a 327 network-based mobility management protocol and vice versa. 329 MIPv6 and PMIPv6 bundle all three mobility management logical 330 functions: LM1, IP1 prefix allocation, and MR1 into the home agent 331 (HA) and Local Mobility Anchor (LMA) respectively. 333 The functional representation of Proxy Mobile IPv6 [RFC5213] is shown 334 in Figure 3. In PMIPv6, the combination of LM, MR, and HoA 335 allocation is the Local Mobility Anchor (LMA), whereas the AR+LU 336 combination together with additional signaling with MN comprises the 337 Mobile Access Gateway (MAG). Here MN11 is attached to the access 338 router AR31 which has the IP address IP31 in Network3. LM1 maintains 339 the binding HoA11:IP31. The access router AR31 also behaves like a 340 home link to MN11 so that MN11 can use its original IP address HoA11. 342 Network1 Network3 Network2 343 +-----+ 344 | LM1 | 345 +-----+ 346 HoA1 alc IP3 alc IP2 alc 347 | 348 | 349 +-----+ 350 | MR1 | 351 +-----+ 352 . 353 . +----+ +----+ 354 . |AR31| |CN21| 355 . |+LU | | | 356 . +----+ +----+ 357 HoA11 IP31 358 | 359 | 360 +----+ 361 |MN11| 362 +----+ 363 HoA11 365 Figure 3. Functional representation of PMIPv6. 367 4.3. Hierarchical Mobile IPv6 369 The functional representation of Hierarchical Mobile IPv6 [RFC5380] 370 is shown in Figure 4. 372 Network1 Network3 Network2 373 +-----+ 374 | LM1 | 375 +-----+ 376 HoA1 alc IP3 alc IP2 alc 377 | 378 | 379 +-----+ +-----+ 380 | MR1 | | MR3 | 381 | | |+ LM | 382 | | |proxy| 383 +-----+ +-----+ 384 . / \ 385 . / \ 386 . / \ 387 . +----+ +----+ +----+ 388 . |AR31| |MN11| |CN21| 389 . |+LU | |+LU | | | 390 . +----+ +----+ +----+ 391 HoA11 IP31 IP32, 392 | HoA11 393 | 394 +----+ 395 |MN31| 396 +----+ 398 Figure 4. Functional representation of Hierarchical Mobile IPv6. 400 Besides the logical functions: LM1, MR1, and HoA1 prefix allocation 401 in Network1 as MIPv6 in Figure 2 and PMIPv6 in Figure 3, there is an 402 MR function (MR3) in the visited network (Network3). MR3 is also a 403 proxy between LM1 and MN11 in the hierarchical LM function LM1--MR3-- 404 MN11. That is, LM1 maintains the LM binding HoA11:MR3 while MR3 405 keeps the LM binding HoA11:IP32. The combined function of MR and the 406 LM proxy function is the Mobility Anchor Point (MAP). 408 In Figure 4, if MN11 takes the place of MN31 which is attached to 409 AR31, the resulting mobility management becomes network-based. 411 4.4. Distributing mobility anchors 413 It is possible to repeat the mobility anchoring function for any of 414 MIPv6, PMIPv6, or HMIPv6, in multiple networks as shown in Figure 5 415 which shows such an example with three networks. 417 Network1 Network3 Network2 418 +-----+ +-----+ +-----+ 419 | LM1 | | LM3 | | LM2 | 420 +-----+ +-----+ +-----+ 421 HoA1 alc HoA3 alc HoA2 alc 422 | | | 423 | | | 424 +-----+ +-----+ +-----+ 425 | MR1 | | MR3 | | MR2 | 426 +-----+ +-----+ +-----+ 427 . / \ 428 . / \ 429 . / \ 430 . +----+ +----+ +----+ 431 . |AR31| |MN11| |CN21| 432 . |+LU | |+LU | | | 433 . +----+ +----+ +----+ 434 HoA11 IP31 IP32, 435 | HoA11 436 | 437 +----+ 438 |MN31| 439 +----+ 441 Figure 5. Functional representation of distributing mobility 442 anchors. 444 4.5. Migrating Home Agents 446 When all these logical functions are bundled into one single entity 447 e.g., a home agent in MIPv6 or a local mobility anchor in PMIPv6, in 448 a single network, the result is triangular routing when the MN and 449 the CN are in networks close to each other but are far from the 450 anchor point. 452 A method to solve the triangle routing problem is to duplicate the 453 anchor points in many networks in different geographic locations as 454 in [Paper-Migrating.Home.Agents]. A functional representation of 455 Migrating Home Agents is shown in Figure 6. 457 Network1 Network3 Network2 458 +-----+ +-----+ +-----+ 459 | LM0 |------| LM0 |------| LM0 | 460 +-----+ +-----+ +-----+ 461 HoA1 alc HoA3 alc HoA2 alc 462 | | | 463 | | | 464 +-----+ +-----+ +-----+ 465 | MR1 | | MR3 | | MR2 | 466 +-----+ +-----+ +-----+ 467 . / \ 468 . / \ 469 . / \ 470 . +----+ +----+ +----+ 471 . |AR31| |MN11| |CN21| 472 . +----+ +----+ +----+ 473 HoA11 IP31 IP32, 474 | HoA11 475 | 476 +----+ 477 |MN31| 478 +----+ 480 Figure 6. Functional representation of Migrating Home Agents. 482 Here, the MR function is available in each of the three networks 483 Network1, Network2, and Network3. The LM function in each network 484 (LM0) contains the LM information for all networks. Each MR in each 485 network advertises the HoA IP prefixes of all these networks using 486 anycast. Traffic from CN21 in Network2 destined to HoA11 will 487 therefore be intercepted by the MR nearest to CN, which is MR2. 488 Using the LM information in LM0, MR2 will use the binding HoA11:IP32 489 to tunnel the packets to MN11. 491 Similarly, traffic originating from MN11 will be served by its 492 nearest MR (MR3). Triangular routing is therefore avoided. Yet the 493 synchronization of all home agents becomes a challenge as discussed 494 in [Paper-SMGI]. In addition, the amount of signaling traffic needed 495 in synchronizing the home agents may become excessive when both the 496 number of mobile nodes and the number of home agents increase. 498 As before, if MN11 in Figure 6 takes the place of MN31 which is 499 attached to AR31, the resulting mobility management becomes network- 500 based. 502 5. DMM Functional Scenarios 504 This section covers the functional description of DMM. Basically, 505 the scenario presents a way to distribute the logical mobility 506 functions. Gap analysis will be made on the functional scenarios. 508 5.1. Flat Network Scenario 510 In a flat network, the logical functions in the functional 511 representation may all be located at the AR as shown in Figures 7 and 512 8, respectively. These two figures depict the network- and client- 513 based distributed mobility management scenarios. The AR is expected 514 to support the HoA allocation function. Then, depending on the 515 mobility situation of the MN, the AR can run different functions: 517 1. the AR can act as a legacy IP router; 519 2. the AR can provide the MR function (i.e. act as mobility anchor); 521 3. the AR can provide the LU functions; 523 4. the AR can provide both MR and LU functions. 525 For example, [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed- 526 anchoring] are PMIPv6 based implementation of this scenario. 528 5.1.1. Network-based Mobility Management 530 The functional description of network-based mobility management is 531 depicted in Figure 7. 533 In case (1), MN1 attaches to AR1. AR advertises prefix HoA1 to MN1 534 and then acts as a legacy IP router. MN1 initiates a communication 535 with CN11. 537 In case (2), MN1 performs a handover from AR1 to AR3 while 538 maintaining ongoing IP communication with CN11. AR1 becomes the 539 mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM 540 functions for MN1. AR3 performs LU up to the LM in AR1: AR3 541 indicates to AR1 the new location of the MN1. AR3 allocates a new IP 542 prefix (HoA3) for new IP communications. HoA3 is supposed to be used 543 for new IP communication, e.g., if MN1 initiates IP communication 544 with CN21. AR3 shall act as a legacy IP router for MN1-CN21 545 communication. 547 In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP 548 communication with CN11 and CN21. AR1 is the mobility anchor for the 549 MN1-CN11 IP communication. AR3 becomes the mobility anchor for the 550 MN1-CN21 IP communication. Both AR1 and AR3 run MR and LM functions 551 for MN1, respectively, anchoring HoA1 and HoA3. AR2 performs 552 location updates up to the LMs in AR1 and AR3 for respectively 553 relocate HoA1 and HoA3. 555 Network1 Network1 Network3 556 +----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+ 557 |CN11| +-----+ |CN11| +-----+ +-----+ |CN21| 558 | |------| | | |------| MR1 |------| |------- | | 559 +----+ | | +----+ | LM1 |------|LU31 | +----+ 560 | AR1 | | AR1 | |AR3 | 561 | | | | | | 562 +-----+ +-----+ +-----+ 563 | | 564 | | 565 | | 566 +----+ +----+ 567 |MN1 | |MN1 | 568 | | | | 569 +----+ +----+ 570 HoA11 HoA11, 571 HoA31 572 (1) (2) 574 Network2 575 Network1 HoA2 al 576 +----+ HoA1 alc +-----+ 577 |CN11| +-----+ | | 578 | |------| MR1 |-----------------|LU21 |-------+ 579 +----+ | LM1 |-----------------|AR2 | | 580 | AR1 | | | | 581 | | Network3 +-----+ | 582 +-----+ HoA3 al | | +----+ 583 +-----+ | | |MN1 | 584 +----+ |MR3 |------ | | | 585 |CN21| |LM3 |-------- +----+ 586 | |------| | HoA11, 587 +----+ |AR3 | HoA31 588 +-----+ (3) 590 Figure 7. Network-based DMM architecture for a flat network. 592 5.1.2. Client-based Mobility Management 594 The functional description of client-based mobility management is 595 depicted in Figure 8. 597 In case (1), MN1 attaches to AR1. AR advertises the prefix HoA1 to 598 MN1 then acts as a legacy IP router. MN1 initiates a communication 599 with CN11. 601 In case (2), MN1 performs a handover from AR1 to AR3 with ongoing IP 602 communication with CN11. AR1 becomes the mobility anchor for the 603 MN1-CN11 IP communication: AR1 runs MR and LM functions for MN1. The 604 MN performs LU directly up to the LM in AR1 or via AR3; in this case 605 AR3 acts as a proxy locator (pLU) (e.g. as a FA in MIPv4). AR3 606 allocates a new IP prefix (HoA3) for new IP communications. HoA3 is 607 supposed to be used for new IP communications, e.g., if MN1 initiates 608 IP communication with CN21. AR3 shall act as a legacy IP router for 609 MN1-CN21 communication. 611 Network1 Network1 Network3 612 +----+ HoA1 alc +----+ HoA1 alc +----+ 613 |CN11| +-----+ |CN | +-----+ +-----+ |CN21| 614 | |------| | | |------| MR1 |------| |------- | | 615 +----+ | | +----+ | LM1 |------|pLU31| +----+ 616 | AR1 | | AR1 | |AR31 | 617 | | | | | | 618 +-----+ +-----+ +-----+ 619 | | 620 | | 621 | | 622 +----+ +----+ 623 |MN1 | |MN1 | 624 | | |LU31| 625 +----+ +----+ 626 HoA11 HoA11, 627 IP31 629 (1) (2) 631 Figure 8. Client-based DMM architecture for a flat network. 633 5.2. Fully distributed scenario with separation of control and data 634 planes 636 This scenario considers multiple MRs and a distributed LM database. 638 The different use case scenarios of distributed mobility management 639 are described in [I-D.yokota-dmm-scenario] as well as in [Paper- 640 Distributed.Mobility.Review]. The architecture described in this 641 document is mainly on separating the data plane from the control 642 plane. 644 Figure 9 shows an example DMM architecture with the same three 645 networks as in Figure 5. As is in Figure 5, each network in Figure 9 646 has its own IP prefix allocation function. In the data plane, the 647 mobility routing function is distributed to multiple locations at the 648 MRs so that routing can be optimized. In the control plane, the MRs 649 may exchange signaling with each other. In addition to these 650 features in Figure 5, the LM function in Figure 9 is a distributed 651 database, with multiple servers, of the mapping of HoA to CoA. 653 Network1 Network3 Network2 654 +-----+ +-----+ +-----+ 655 | LM1 | | LM3 | | LM2 | 656 +-----+ +-----+ +-----+ 657 HoA1 alc HoA3 alc HoA2 alc 658 | \ \ / | \ / / | 659 | \ \ / | \ / / | 660 | \ \/ | \/ / | 661 | \ / \ | / \ / | 662 | \/ \|/ \/ | 663 | /\ /|\ /\ | 664 | / \ / | \ / \ | 665 | / /\ | /\ \ | 666 | / / \ | / \ \ | 667 | / / \ | / \ \ | 668 +-----+ +-----+ +-----+ 669 | MR1 |------| MR3 |------| MR2 | 670 +-----+ +-----+ +-----+ 671 . / \ 672 . / \ 673 . / \ 674 . +----+ +----+ +----+ 675 . |AR31| |MN11| |CN21| 676 . |+LU | |+LU | | | 677 . +----+ +----+ +----+ 678 HoA11 IP31 IP32, 679 | HoA11 680 | 681 +----+ 682 |MN31| 683 +----+ 685 Figure 9. A distributed architecture for mobility management. 687 To perform mobility routing, the MRs need the location information 688 which is maintained at the LMs. The MRs are therefore the clients of 689 the LM servers and may also send location updates to the LM as the 690 MNs perform the handover. The location information may either be 691 pulled from the LM servers by the MR, or pushed to the MR by the LM 692 servers. In addition, the MR may also cache a limited amount of 693 location information. 695 This figure shows three MRs (MR1, MR2, and MR3) in three networks. 696 MN11 has moved from the first network supported by MR1 and LM1 to the 697 third network supported by MR3 and LM3. It may use an HoA (HoA11) 698 allocated to it when it was in the first network for those 699 application sessions that had already started when MN11 was attached 700 there and that require session continuity after the handover to the 701 third network. When MN11 was in the first network, no location 702 management is needed so that LM1 will not keep an entry of HoA11. 703 After MN11 has performed its handover to the third network, the 704 database server LM1 maintains a mapping of HoA11 to MR3. That is, 705 LM1 points to the third network and it is the third network that will 706 keep track of how to reach MN11. Such a hierarchical mapping can 707 prevent frequent update signaling to LM1 as MN11 performs intra- 708 network handover within the third network. In other words, the 709 concept of hierarchical mobile IP [RFC5380] is applied here but only 710 in location management and not in routing in the data plane. 712 6. Gap analysis 714 6.1. DMM Requirements 716 6.1.1. Considering existing protocols first 718 The fourth DMM requirement is on existing mobility protocols [ID-dmm- 719 requirements: 721 REQ4: A DMM solution SHOULD first consider reusing and extending 722 IETF-standardized protocols before specifying new protocols. 724 Abstracting the existing protocol functions into logical functions in 725 this draft is a way to see how one can maximize the use of existing 726 protocols. It remains to be seen whether all DMM requirements can be 727 met. One needs to check the rest of the requirements to identify the 728 gaps. 730 In addition, individual DMM proposals available at the IETF DMM 731 working group are mostly based on the existing IETF-standardized 732 protocols. 734 6.1.2. Compatibility 736 The first part of the fifth DMM requirement is on compatibility: 738 REQ5: (first part) The DMM solution MUST be able to co-exist with 739 existing network deployments and end hosts. For example, depending 740 on the environment in which DMM is deployed, DMM solutions may need 741 to be compatible with other deployed mobility protocols or may need 742 to interoperate with a network or mobile hosts/routers that do not 743 support DMM protocols. 745 Different deployments using the same abstract functions are basically 746 reconfiguration of these same functions if their functions use common 747 message formats between these functions. A design principle of the 748 IPv6 message format accommodates the use of common message formats as 749 it allows to define extension headers, e.g., use of mobility header 750 and options. It is shown in Section 4 that MIPv6, PMIPv6, HMIPv6, 751 Distributing mobility anchors can be constructed from the abstract 752 functions by adding more features and additional messages one on top 753 of the other in the above order. The later protocol will therefore 754 support the one from which the later is constructed by adding more 755 messages. 757 6.1.3. IPv6 deployment 759 The third DMM requirement on IPv6 deployment is the following. 761 REQ3: DMM solutions SHOULD target IPv6 as the primary deployment 762 environment and SHOULD NOT be tailored specifically to support IPv4, 763 in particular in situations where private IPv4 addresses and/or NATs 764 are used. 766 This is not an issue with MIPv6, PMIPv6 and their extensions. Using 767 the unified scheme here based on abstracting these existing protocol 768 functions will meet the DMM requirements as these protocols are 769 originally designed for IPv6. 771 6.1.4. Security considerations 773 The first part of the fourth requirement as well as the sixth DMM 774 requirement [ID-dmm-requirements] are as follows: 776 REQ5 (second part): Furthermore, a DMM solution SHOULD work across 777 different networks, possibly operated as separate administrative 778 domains, when allowed by the trust relationship between them. 780 REQ6: DMM protocol solutions MUST consider security aspects, 781 including confidentiality and integrity. Examples of aspects to be 782 considered are authentication and authorization mechanisms that allow 783 a legitimate mobile host/router to use the mobility support provided 784 by the DMM solution; signaling message protection in terms of 785 authentication, encryption, etc.; data integrity and confidentiality; 786 opt-in or opt-out data confidentiality to signaling messages 787 depending on network environments or user requirements. 789 It is preferred that these security requirements are considered as an 790 integral part of the DMM design. 792 6.1.5. Distributed deployment 794 The first DMM requirement has 2 parts. The first part is on 795 distributed deployment whereas the second part is on avoiding longer 796 routes. 798 REQ1: (part 1)IP mobility, network access and routing solutions 799 provided by DMM MUST enable distributed deployment for mobility 800 management of IP sessions (part 2) so that traffic does not need to 801 traverse centrally deployed mobility anchors and thus can be routed 802 in an optimal manner. 804 With the first part, multiple MRs will become available in MIPv6 by 805 simply having an HA for each home network. This is illustrated in 806 terms of the logical functions as in Figure 9. Note that [Paper- 807 Host.based.DMM] shows an example of a host-based DMM protocol based 808 on MIPv6. 810 With the second part, one can examine dynamic mobility and route 811 optimization to be discussed later. 813 6.1.6. Transparency to Upper Layers when needed 815 To see how to avoid traversing centralized deployed mobility anchors, 816 let us look at the second requirement on non-optimal routes [ID-dmm- 817 requirements]. 819 REQ2: DMM solutions MUST provide transparent mobility support above 820 the IP layer when needed. Such transparency is needed, for example, 821 when, upon change of point of attachment to the Internet, an 822 application flow cannot cope with a change in the IP address. 823 Otherwise, support for maintaining a stable home IP address or prefix 824 during handovers may be declined. 826 In order to avoid traversing long routes after the MN has moved to a 827 new network, the new network can simply be used as the home network 828 for new sessions. The sessions that had already started in the 829 previous network would still need to use the original network in 830 which the session had started as the home network. There may then be 831 different IP sessions using different IP prefixes/addresses in the 832 same MN. 834 The capability to use different IP addresses for different IP 835 sessions are therefore needed. 837 The association with the HoA of an MN is not sufficient to support 838 the above use of IP for an application. This gap can be overcome by 839 generalizing the concept of the HoA of the MN to the HoA of an 840 application running on the MN as will be discussed in Section 7.1 841 below. 843 Using the dynamic mobility management scheme has avoided routing back 844 to the home network when the application does not have such a need. 845 There are, however, application sessions that had originated from a 846 prior network and that require mobility support. Longer routes than 847 the natural IP route can therefore emerge. Route optimization 848 schemes already exist, but one needs to deal with multiple HA's when 849 using multiple HA's. 851 6.1.7. Route optimization 853 The second part of first requirement is on route optimization. 855 REQ1: (part 1)IP mobility, network access and routing solutions 856 provided by DMM MUST enable distributed deployment for mobility 857 management of IP sessions (part 2) so that traffic does not need to 858 traverse centrally deployed mobility anchors and thus can be routed 859 in an optimal manner. 861 One generalization in terms of the unified framework is that the LM 862 functions can be considered as a distributed database as will be 863 shown in the next section. There, the MN and the LM have a client- 864 server relationship, with optionally a proxy in between and the proxy 865 can be co-located with an MR. A distributed database may have 866 different servers to store different data. The data in each server 867 need not be pushed to all other servers but the database system only 868 needs to know which data resides on which server. In addition, each 869 client (i.e., MN) needs to be able to query the database. 871 Existing functions, such as BU and BA messages, can be considered as 872 a method of database update function for the mobility context of the 873 MN. Completing the design of messages for the database update 874 functions will enable the distributed database design for route 875 optimization. 877 In the unified scheme, complete with database and mobility routing 878 functionalities, numerous route optimizations can be designed as 879 described in Section 7.2. 881 6.2. Mobility Protocols Gap Analysis 883 6.2.1. Gap analysis with the unified framework 885 The use of the unified framework meets the following requirements: 887 REQ4: Considering existing protocols first 889 REQ5: (first part) compatibility 891 REQ3: IPv6 deployment 893 The unified framework has separated the HA function into an MR and an 894 LM function. The following is needed in addition: 896 REQ6: Security - Trust between MR and LM is needed when they are not 897 co-located. 899 6.2.2. Gap analysis with MIPv6 901 MIPv6 using the unified framework follows the above gap analysis with 902 the unified framework. In addition, the following is needed. 904 REQ6: Security consideration 906 Trust between MN and MR is needed. 908 6.2.3. Gap analysis with PMIPv6 910 In terms of the unified framework, PMIPv6 differs from MIPv6 only in 911 the sense that the combination of an AR and the MN in the network- 912 based solution behaves like an MN in the host-based solution. While 913 the gap analysis with MIPv6 applies here, the following change is 914 needed: The trust between MN and MR in MIPv6 is therefore replaced by 915 the trust between AR and MR, and trust between the AR and the MN is 916 needed. 918 REQ6: Security consideration 920 Trust between AR and MR is needed. 922 Trust between MN and MR is needed. 924 6.2.4. Gap analysis with HMIPv6 926 In terms of the unified framework, HMIPv6 differs from MIPv6 and 927 PMIPv6 only in the addition that packets are routed in the hierarchy 928 MR(home network) -- MR(visited network) -- MN in MIPv6 or AR in 929 PMIPv6. While the gap analysis with MIPv6 and PMIPv6 applies to 930 HMIPv6, the following additional trust relationship is needed between 931 the MR's of different networks. 933 REQ6: Security consideration 935 Trust between MRs in different networks is needed. 937 6.2.5. Gap analysis with Distributing Mobility Anchors 939 The scenario of distributing mobility anchors is simply achieved with 940 the implementation of the unified framework for MIPv6, PMIPv6, or 941 HMIPv6 in each network of the multiple network. Therefore the gap 942 analysis for MIPv6, PMIPv6, or HMIPv6 apply depending on which of 943 these variants of MIP is used in these networks. In addition, the MR 944 function is now available in different networks. The following 945 requirement of distributed deployment is then met. 947 REQ1: Distributed deployment 949 The unified framework functions can be deployed in each of the 950 multiple networks. 952 6.2.6. Gap analysis with HAHA 954 The scenario for Migrating Home Agent can be constructed from that of 955 the distributing mobility anchors and modifying the LM in each 956 network to propagate its data to all LM servers in all other 957 networks. Therefore the gap analysis with distributing mobility 958 anchors apply. 960 In addition, trust between the LM servers is needed. 962 REQ6: Security consideration 964 Trust among the LM servers is needed. 966 6.2.7. Gap analysis with Dynamic mobility management 968 In Section 6, the unified framework functions are built by extending 969 that of the distributing mobility anchors scenario. Therefore the 970 gap analyses with distributing mobility anchors apply to the dynamic 971 mobility management. In addition, 973 REQ2: Transparency to upper layers when needed. 975 The home network and HoA was previously associated with an MN. By 976 extending the concept to that of an application rather than an MN 977 which has multiple applications, dynamic mobility management can be 978 achieved. 980 6.2.8. Gap Analysis with Multiple MRs and Distributed LM Database 982 In Section 7, an architecture of distributed mobility management is 983 constructed from the unified framework functions and can be seen as 984 an extension of the distributing mobility anchor scenario with 985 dynamic mobility management support. Therefore the gap analyses for 986 the dynamic mobility management also apply. In addition, the 987 following gap analysis applies. 989 REQ1: (part 2) Distributed deployment 991 The LMs may generalize into a distributed database. 993 REQ6: Security considerations 995 Trust between the LM in a different network and the MR is needed. 997 6.2.9. Gap Analysis with Route Optimization Mechanisms 999 In Section 8, different possibilities to optimize the route using the 1000 architecture in Section 7 is described. Therefore the gap analyses 1001 for the DMM architecture in Section 7 apply. In addition, the 1002 following gap analyses apply. 1004 REQ1: (part 2) Distributed deployment 1006 MR may cache the LM information when needed. 1008 MR function is needed in the CN's network. 1010 REQ6: Security considerations 1012 Trust between the MR and the LM is needed. 1014 6.3. Gap analysis summary 1016 The gap analyses for different protocols are summarized in this 1017 section. 1019 Table 1. Summary of Gap Analysis 1020 Upper- 1021 layer 1022 Existing Distri- trans- 1023 proto- IPv6 Security buted parency Route 1024 cols Compati- deploy- consi- deploy- when Optimi- 1025 first bility ment derations ment needed zation 1027 Unified 1028 framework Y Y Y 1030 MIPv6 Y Y Y Y N N N 1032 PMIPv6 Y Y Y Y N N N 1033 (supports (MN-AR) 1034 above) 1036 HMIPv6 Y Y Y Y N N N 1037 (supports (MN-AR) 1038 above) 1040 Optimize Y Y Y Y N N locat- 1041 route (supports ion pr 1042 above) ivacy 1044 Distribute Y Y Y Y Y N N 1045 mobility (supports 1046 anchors above) 1048 Multiple 1049 MRs and Y Y Y Y Y Y 1050 Distri- (supports (LM-MR in 1051 buted LM above) different 1052 database networks) 1054 Dynamic Y Y Y Y Y Y most 1055 mobility (supports (LM,MR-MR in (HoA of cases 1056 above) different appl) 1057 networks) 1058 DMM Y Y Y Y Y Y except 1059 (supports (LM,MR-MR in (HoA of 1st 1060 above) different appl) pkts 1061 networks) 1063 7. DMM analysis 1065 This section analyses how DMM proposals meet above requirements. 1067 7.1. DMM scenarios and Dynamic mobility management requirement 1069 The distributed architecture described in Section 5.1, which has an 1070 MR and an HoA allocation function in each network, enables dynamic 1071 mobility management. 1073 When new applications are started after the MN moves to a new 1074 network, the device can simply use a new IP address allocated by the 1075 new network. Dynamic mobility management, i.e., invoking mobility 1076 management only when needed, has been proposed in [Paper- 1077 Distributed.Dynamic.Mobility] and [Paper-Host.based.DMM]. 1079 The architecture with multiple mobility routing functions compared 1080 with a centralized approach is more appropriate for achieving dynamic 1081 mobility management. In Figure 9 above, the LM function and the IP 1082 address allocation function may be co-located. The device MN11, 1083 originally attached to the first network (Network1), may simply be 1084 using a dynamic IP address HoA11 which is leased from Network1 with a 1085 finite lifetime of, say, 24 hours. As MN11 leaves the first network 1086 and attaches to the third network (Network3), it acquires a new IP 1087 address IP33 from Network3. MN11 may or may not have ongoing 1088 sessions requiring session continuity. If it does not have, there is 1089 no need for LM1 to keep a binding for the home address HoA11 of MN11. 1090 If it does, it may use the existing MIPv6 signaling mechanism so that 1091 the LM1 will maintain the binding HoA11:MR3. MR3 in turn will 1092 maintain the binding HoA11:IP33. Such a hierarchy of binding with 1093 MR3 acting as the proxy location maintenance function between LM1 and 1094 MN11 will also cause MR3 to act as a proxy MR function between MR1 1095 and MN11 so that packets destined to MR1 will be redirected to MR3. 1097 When all ongoing sessions requiring session continuity terminate, it 1098 is possible for MN11 to deregister from LM1. Yet one may not assume 1099 the device will always perform the de-registration. Alternatively 1100 the lease of the dynamic IP address HoA11 will expire upon which LM1 1101 will remove the binding. 1103 In the event that the ongoing session outlives the lease of HoA11, 1104 MN11 will need to renew the lease with the IP address allocation 1105 function in the first network. 1107 More details on dynamically providing mobility support are found in 1108 [ID.seite-dmm-dma], [ID.liu-dmm-dynamic-anchor-discussion], 1109 [ID.bernardos-dmm-pmip], [I-D.ma-dmm-armip], and [ID.sarikaya-dmm- 1110 dmipv6]. 1112 [I-D.seite-dmm-dma] describes dynamic mobility management using 1113 PMIPv6. In that document, MR, LM, and the HoA allocation functions 1114 are co-located at the access router in a flat network. 1116 [Paper-Net.based.DMM], or equivalently the draft [I-D.seite-dmm-dma], 1117 also describes dynamic mobility management in which the MR and the 1118 HoA allocation functions are both co-located at the access router, 1119 whereas the LM information in each of these access routers are linked 1120 together under the hierarchy of a centralized LM server. 1122 [Paper-Host.based.DMM] described fully distributed dynamic mobility 1123 management using MIPv6. An access mobility anchor (AMA) is 1124 introduced as a mobility anchor that provides the MR, LM, and HoA 1125 allocation functions. As a host-based DMM protocol, an MN is allowed 1126 to signal its movement to a serving AMA co-located at an access 1127 router. The serving AMA signals to other AMAs associated to the 1128 active sessions of the MN that enable session continuity for the 1129 sessions anchored to the other AMAs. No centralized LM server is 1130 required. 1132 [ID.sarikaya-dmm-dmipv6] also described dynamic mobility management 1133 for a flat network, with separate data plane and control plane. The 1134 needed authentication is also described. 1136 [ID.bernardos-dmm-pmip] co-locates the home prefix allocation 1137 function and the mobility routing function at the access router, 1138 which is then named Mobility Anchor and Access Router (MAAR) in that 1139 draft. The LM function is centralized and is named Central Mobility 1140 Database (CMD). 1142 [I-D.ma-dmm-armip] again describes dynamic mobility management in 1143 which the MR and the HoA allocation function are both co-located at 1144 the access router. 1146 [ID.liu-dmm-dynamic-anchor-discussion] describes the gaps and 1147 extensions needed to accomplish dynamic mobility management. 1149 7.2. Route optimization of DMM scenarios 1151 The distributed architecture has already enabled dynamic mobility 1152 management, as is described in [I-D.seite-dmm-dma], even when the 1153 routes are not optimized. Route optimization mechanism can be 1154 achieved in addition to dynamic mobility. 1156 With the above architecture, there are a number of ways to enable 1157 reachability of an MN by packets sent from a CN using the mobility 1158 routing function. 1160 The target to avoid unnecessarily long route is the direct route 1161 instead of a triangular route. In general, when a packet is sent 1162 from a CN in one network to an MN in another network, the direct 1163 route consists of the following 3 routing segments (RS): 1165 RS1.CN-MR(CN): the route segment from the CN to the nearest MR; 1167 RS2.MR(CN)-MR(MN): the route segment from the MR serving (and 1168 therefore being closest to) the CN to the MR serving the MN; and 1170 RS3.MR(MN)-MN: the route segment from the MR serving the MN to the 1171 MN. 1173 One may therefore examine the route optimization mechanism in terms 1174 of these 3 routing segments. In the first segment RS1:CN-MR(CN), the 1175 alternatives are: 1177 RS1.CN-MR(CN).anycast: Use anycast to route the packet to the 1178 nearest MR function. Here, each MR includes all the HoAs in its 1179 route announcement as if each of them is the destination for the 1180 HoA. Such route announcements will affect the routing table such 1181 that the packet destined to an HoA will be routed to the nearest 1182 MR. The use of anycast to reach the nearest HA has been used in 1183 [Paper-Migrating.Home.Agents] but with a different distributed 1184 architecture of duplicating many HAs. It is again proposed in 1185 [Paper-Distributed.Mobility.PMIP]. 1187 RS1.CN-MR(CN).gw/ar: Co-locate the MR function at a convenient 1188 location to which the packet will always pass. Such locations may 1189 be the gateway router or the access router. This approach will be 1190 described later. 1191 It is noted here that in a PMIPv6 design with a hierarchical 1192 network, the MAG generally is at the access router but LMA can be 1193 in the gateway router of a network. Whether a distributed 1194 mobility design enhances the MAG or the LMA may involve quite 1195 different mechanisms. Yet when looking at the logical function, 1196 it is basically the same MR function whether this function co- 1197 locates with the access router or the gateway router. This draft 1198 therefore put both approaches together. There is however a 1199 difference that the access router needs to perform proxy function 1200 when using PMIPv6. Yet the logical MR functions are the same. 1201 It is again noted that in flattened network, the access router and 1202 the gateway router may merge together. With they are merged, the 1203 needed function is again the same logical MR function. 1205 In the second segment RS2.MR(CN)-MR(MN), the alternatives are: 1207 RS2.MR(CN)-MR(MN).query: The MR query the LM database and use the 1208 result to tunnel the packet to the MR serving the MN. In order 1209 words, the MR pulls the needed internetwork location information 1210 from the LM server. There will be a delay owing to the time taken 1211 to send this query and to receive the reply. Optionally, before 1212 receiving the reply, the first packet or the first few packets may 1213 be forwarded using mip or pmip. Then the first packet may incur a 1214 triangle route rather than to wait for the query reply. After 1215 receiving the reply, the packet will be tunneled to the MR(MN). 1216 The result may be cached for forwarding subsequent packets. 1218 RS2.MR(CN)-MR(MN).push: The MR routes the first packet to the home 1219 network using the existing MIPv6 or PMIPv6 mechanism. It will 1220 then be intercepted by the MR of the MN which, with the help of 1221 LM, knows whether the MN has moved to a different network and use 1222 the mapping in LM to tunnel the packet to the MR of the MN. Then 1223 the MR of the MN will inform MR of the CN to tunnel the packet 1224 directly to the MR of the MN in future. In order words, after 1225 MR(CN) has forwarded the first packet to MR(MN), the MR(MN) is 1226 triggered to push the location information to MR(CN). The MR of 1227 the CN may keep this information in its cache memory for 1228 forwarding subsequent packets. 1230 In the final segment RS3.MR(MN)-MN, the MR may keep track of the 1231 location of MN and route to it using its intra-network mobility 1232 management mechanism. 1234 Different designs using the above architecture can be made by taking 1235 different combinations of the different designs in the different 1236 route segments. For example, the overall design of DMM may be: 1238 1. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).query: 1240 2. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).push: 1242 An example is [Paper-Distributed.Mobility.PMIP] which is 1243 explained for network-based mobile IP but is also applicable to 1244 host-based mobile IP. 1246 3. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).query: 1248 An example is in [I-D.luo-dmm-pmip-based-dmm-approach] or 1249 [I-D.liu-dmm-pmip-based-dmm-approach] in which the MR function is 1250 co-located at the MAG which is usually at the access router. 1251 Here, when CN is also an MN using PMIPv6, the packet sent from it 1252 naturally goes to the access router which takes the logical 1253 function of MR so that it will query the LM, which resides in the 1254 LMA. It then uses the query result to tunnel the packet to the 1255 MR(MN), which resides in the AR/MAG of the destination MN. The 1256 signaling flow and other details are described in the referenced 1257 draft. 1259 Another example is in [I-D.jikim-dmm-pmip]. In the signal driven 1260 approach, the MR is co-located the access router, which is 1261 considered as an extension of MAG. The MR, i.e., the extended 1262 MAG, serving the CN queries the LM and cache the result so that 1263 it can tunnel packets to the MR serving the destination MN. 1265 [I-D.liebsch-mext-dmm-nat-phl] also co-locates the MR at the 1266 gateways. The gateway which serves the network of transmitting 1267 node and where the MR is co-located is called the Ingress router, 1268 whereas that at the network of the MN at the receiving side is 1269 called egress router. Instead of tunneling between these 2 1270 gateways, header rewrite using NAT is used to forward the packet 1271 through the internetwork route segment. 1273 4. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).push: 1275 Another example is described in [Paper- 1276 Distributed.Mobility.Management]. 1278 8. Security Considerations 1280 TBD 1282 9. IANA Considerations 1284 None 1286 10. References 1288 10.1. Normative References 1290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, March 1997. 1293 10.2. Informative References 1295 [I-D.bernardos-dmm-distributed-anchoring] 1296 Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed 1297 anchoring", draft-bernardos-dmm-distributed-anchoring-01 1298 (work in progress), September 2012. 1300 [I-D.bernardos-dmm-pmip] 1301 Bernardos, C., Oliva, A., Giust, F., Melia, T., and R. 1302 Costa, "A PMIPv6-based solution for Distributed Mobility 1303 Management", draft-bernardos-dmm-pmip-01 (work in 1304 progress), March 2012. 1306 [I-D.jikim-dmm-pmip] 1307 Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy 1308 Mobile IPv6 for Distributed Mobility Management", 1309 draft-jikim-dmm-pmip-00 (work in progress), March 2012. 1311 [I-D.liebsch-mext-dmm-nat-phl] 1312 Liebsch, M., "Per-Host Locators for Distributed Mobility 1313 Management", draft-liebsch-mext-dmm-nat-phl-02 (work in 1314 progress), October 2012. 1316 [I-D.liu-dmm-dynamic-anchor-discussion] 1317 Liu, D., Deng, H., and W. Luo, "DMM Dynamic Anchor 1318 Discussion", draft-liu-dmm-dynamic-anchor-discussion-00 1319 (work in progress), March 2012. 1321 [I-D.liu-dmm-pmip-based-approach] 1322 Liu, D., Song, J., and W. Luo, "PMIP Based DMM 1323 Approaches", draft-liu-dmm-pmip-based-approach-02 (work in 1324 progress), March 2012. 1326 [I-D.luo-dmm-pmip-based-dmm-approach] 1327 Luo, W. and J. Liu, "PMIP Based DMM Approaches", 1328 draft-luo-dmm-pmip-based-dmm-approach-01 (work in 1329 progress), March 2012. 1331 [I-D.ma-dmm-armip] 1332 Ma, Z. and X. Zhang, "An AR-level solution support for 1333 Distributed Mobility Management", draft-ma-dmm-armip-00 1334 (work in progress), February 2012. 1336 [I-D.patil-dmm-issues-and-approaches2dmm] 1337 Patil, B., Williams, C., and J. Korhonen, "Approaches to 1338 Distributed mobility management using Mobile IPv6 and its 1339 extensions", draft-patil-dmm-issues-and-approaches2dmm-00 1340 (work in progress), March 2012. 1342 [I-D.sarikaya-dmm-dmipv6] 1343 Sarikaya, B., "Distributed Mobile IPv6", 1344 draft-sarikaya-dmm-dmipv6-00 (work in progress), 1345 February 2012. 1347 [I-D.seite-dmm-dma] 1348 Seite, P. and P. Bertin, "Distributed Mobility Anchoring", 1349 draft-seite-dmm-dma-05 (work in progress), July 2012. 1351 [I-D.xue-dmm-routing-optimization] 1352 Xue, K., Li, L., Hong, P., and P. McCann, "Routing 1353 optimization in DMM", 1354 draft-xue-dmm-routing-optimization-00 (work in progress), 1355 June 2012. 1357 [I-D.yokota-dmm-scenario] 1358 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 1359 scenarios for Distributed Mobility Management", 1360 draft-yokota-dmm-scenario-00 (work in progress), 1361 October 2010. 1363 [MHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 1364 Agents Towards Internet-scale Mobility Deployments", 1365 Proceedings of the ACM 2nd CoNEXT Conference on Future 1366 Networking Technologies, Lisboa, Portugal, December 2006. 1368 [Paper-Distributed.Centralized.Mobility] 1369 Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or 1370 Centralized Mobility?", Proceedings of Global 1371 Communications Conference (GlobeCom), December 2009. 1373 [Paper-Distributed.Dynamic.Mobility] 1374 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 1375 Dynamic Mobility Management Scheme Designed for Flat IP 1376 Architectures", Proceedings of 3rd International 1377 Conference on New Technologies, Mobility and Security 1378 (NTMS), 2008. 1380 [Paper-Distributed.Mobility.Management] 1381 Chan, H., "Distributed Mobility Management with Mobile 1382 IP", Proceedings of IEEE ICC 2012 Workshop on 1383 Telecommunications: from Research to Standards, June 2012. 1385 [Paper-Distributed.Mobility.PMIP] 1386 Chan, H., "Proxy Mobile IP with Distributed Mobility 1387 Anchors", Proceedings of GlobeCom Workshop on Seamless 1388 Wireless Mobility, December 2010. 1390 [Paper-Distributed.Mobility.Review] 1391 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 1392 "Distributed and Dynamic Mobility Management in Mobile 1393 Internet: Current Approaches and Issues", February 2011. 1395 [Paper-Host.based.DMM] 1396 Lee, JH., Bonnin, JM., and X. Lagrange, "Host-based 1397 Distributed Mobility Management Support Protocol for IPv6 1398 Mobile Networks", Proceedings of IEEE WiMob, Barcelona, 1399 Spain, October 2012. 1401 [Paper-Migrating.Home.Agents] 1402 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 1403 Agents Towards Internet-scale Mobility Deployments", 1404 Proceedings of the ACM 2nd CoNEXT Conference on Future 1405 Networking Technologies, December 2006. 1407 [Paper-Net.based.DMM] 1408 Giust, F., de la Oliva, A., Bernardos, CJ., and RPF. Da 1409 Costa, "A network-based localized mobility solution for 1410 Distributed Mobility Management", Proceedings of 14th 1411 International Symposium on Wireless Personal Multimedia 1412 Communications (WPMC), October 2011. 1414 [Paper-SMGI] 1415 Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in 1416 the Global Internet", Proceedings of ACM Workshop on 1417 MICNET, MobiCom 2009, Beijing, China, September 2009. 1419 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1420 July 2005. 1422 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1423 RFC 4988, October 2007. 1425 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1426 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1428 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1429 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1430 Management", RFC 5380, October 2008. 1432 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 1433 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 1434 September 2010. 1436 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1437 in IPv6", RFC 6275, July 2011. 1439 Authors' Addresses 1441 H Anthony Chan 1442 Huawei Technologies 1443 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 1444 Email: h.a.chan@ieee.org 1445 Pierrick Seite 1446 France Telecom - Orange 1447 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 1448 Email: pierrick.seite@orange-ftgroup.com 1450 Kostas Pentikousis 1451 Huawei Technologies 1452 Carnotstr. 4 10587 Berlin, Germany 1453 Email: k.pentikousis@huawei.com 1455 Jong-Hyouk Lee 1456 Telecom Bretagne 1457 RSM Department, Telecom Bretagne, Cesson-Sevigne, 35512, France 1458 Email: jh.lee@telecom-bretagne.eu