idnits 2.17.1 draft-chan-dmm-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-01 == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-06 == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM H. Chan 3 Internet-Draft Huawei Technologies 4 Intended status: Informational P. Seite 5 Expires: April 24, 2014 France Telecom - Orange 6 K. Pentikousis 7 EICT GmbH 8 A. Dutta 9 ATT 10 October 21, 2013 12 Distributed Mobility Management Framework 13 draft-chan-dmm-framework-03 15 Abstract 17 This document introduces a framework for mobility management 18 protocols in terms of their key, abstract logical functions. We 19 explain how the framework is capable of presenting a unified view, 20 reducing the clutter that prevents a casual reader from understanding 21 the commonalities between different approaches in mobility 22 management. A first order application of this framework is to enable 23 us to examine previously standardized mobility management protocols, 24 such as MIPv6 and PMIPv6 (as well as several of their extensions), 25 and describe their core functionality in terms of different 26 configurations of the logical functions defined by the framework. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 3. Mobility Management Logical Functions . . . . . . . . . . . . 4 65 4. Mobility Protocol Functional Decomposition . . . . . . . . . . 6 66 4.1. Decomposing Mobile IPv6 . . . . . . . . . . . . . . . . . 6 67 4.2. From MIPv6 to PMIPv6 . . . . . . . . . . . . . . . . . . . 7 68 4.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . 9 69 4.4. Distributing Mobility Anchors . . . . . . . . . . . . . . 10 70 4.5. Migrating Home Agents . . . . . . . . . . . . . . . . . . 11 71 5. DMM Functional Decomposition Scenarios . . . . . . . . . . . . 12 72 5.1. Flat Network Scenario . . . . . . . . . . . . . . . . . . 13 73 5.1.1. Network-based Mobility Management . . . . . . . . . . 13 74 5.1.2. Client-based Mobility Management . . . . . . . . . . . 14 75 5.2. DMM with Control and Data Plane Separation . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Appendix A. Comparing against DMM requirements . . . . . . . . . 19 82 A.1. First DMM requirement: distributed processing . . . . . . 19 83 A.2. Second DMM requirement: Transparency to upper layers 84 when needed . . . . . . . . . . . . . . . . . . . . . . . 20 85 A.3. Third DMM requirement: IPv6 deployment . . . . . . . . . 20 86 A.4. Fourth DMM requirement: Existing mobility protocols . . . 20 87 A.5. Fifth DMM requirement: co-existence . . . . . . . . . . . 20 88 A.6. Sixth DMM requirement: Security considerations . . . . . 20 89 A.7. Seventh DMM requirement: multicast . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 While there is ongoing research on new protocols for distributed 95 mobility management (DMM), it has also been proposed, e.g., in 96 [Paper-Distributed.Mobility.PMIP] and in other publications, that a 97 DMM architecture can be designed using primarily existing mobility 98 management protocols with some extensions. This is reflected in the 99 requirement included in [I-D.ietf-dmm-requirements]: distributed 100 mobility management is to first use existing protocols and their 101 extensions before considering new protocol designs. Although this a 102 key requirement as we move forward, it does not point to which 103 extensions are needed let alone how to devise them. 105 Mobile IPv6 [RFC6275], for instance, which is a logically centralized 106 mobility management approach addressing primarily hierarchical mobile 107 networks, has numerous variants and extensions including, PMIPv6 108 [RFC5213], Hierarchical MIPv6 (HMIPv6) [RFC5380], Fast MIPv6 (FMIPv6) 109 [RFC5568] [RFC4988], Proxy-based FMIPv6 (PFMIPv6) [RFC5949], just to 110 name a few. These variants or extensions of MIPv6 have been 111 developed over the years owing to the different needs that have been 112 arising ever since the first MIP specification came into life. This 113 document argues that we can gain much more insight into the design 114 space of DMM protocols by abstracting the functionality of existing 115 mobility management protocols in terms of logical functions. 116 Different variants of existing mobility management protocols can then 117 be expressed as different design variations of how these logical 118 functions are put together. The result is a rich framework that can 119 express sophisticated functionalities in a more straightforward 120 manner. What is more, this document shows how to reconfigure these 121 logical functions towards various distributed mobility management 122 designs. 124 The rest of this document is organized as follows. After setting the 125 stage with conventions and terminology in the following section, 126 Section 3 introduces the framework abstractions, based on common 127 functionality we observe in the current crop of mobility management 128 protocols. This includes three logical functions, namely, home 129 address allocation, routing management and location management. Such 130 functional decomposition will enable us to clearly separate data and 131 control plane functionality, and gives us the flexibility in an 132 implementation to position said logical functions at their most 133 appropriate places in the system design. Next, Section 4 shows that 134 these logical functions can indeed perform the same functions as 135 major existing mobility protocols. These functions therefore become 136 the foundation for a unified framework upon which different designs 137 of distributed mobility management may be built upon. Finally, 138 Section 5 presents scenarios where the functional aspects of the 139 framework are illustrated. 141 2. Conventions and Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 All general mobility-related terms and their acronyms used in this 148 document are to be interpreted as defined in the Mobile IPv6 base 149 specification [RFC6275] and in the Proxy Mobile IPv6 specification 150 [RFC5213]. This includes terms such as mobile node (MN), 151 correspondent node (CN), home agent (HA), home address (HoA), care- 152 of-address (CoA), local mobility anchor (LMA), and mobile access 153 gateway (MAG). 155 In addition, this document uses the following term: 157 Home network of an application session (or of an HoA) is the network 158 that has allocated the IP address (HoA) used for the session 159 identifier by the application running in an MN. An MN may be 160 running multiple application sessions, and each of these sessions 161 can have a different home network. 163 3. Mobility Management Logical Functions 165 Functional entity (FE) decomposition is an often-used engineering 166 approach that enables us to look at the similarities and differences 167 of complex systems while keeping track of their important operational 168 aspects. Earlier work, for instance, in the European research 169 project Ambient Networks investigated how to create an advanced and 170 forward-looking architecture aiming primarily for mobile and wireless 171 networks [Book-AN]. A key goal was to design mechanisms that can be 172 deployed in a variety of settings (ad-hoc or operator-controlled) and 173 scale from small home networks with little human supervision to 174 sensor networks deployed over large geographical areas with limited 175 resources, to large professionally-managed infrastructure networks. 176 The project put forward the concept of the Ambient Control Space 177 (ACS) which relies on only three interfaces; interested readers can 178 find more details in [Book-AN]. 180 Within the ACS, novel mobility management mechanisms were developed 181 based on the concept of self-containing Functional Entities (FEs) 182 which featured well-defined interfaces and interactions with each 183 other. This systematic decomposition enabled the development of 184 several mobility management mechanisms which put emphasis on 185 different aspects. Examples of these approaches include the Generic 186 Link Layer [Paper-GLL], Multi-radio Resource Management [Paper-MRRM], 187 and [Paper-NODEID], which has some similarities with HIP. Later work 188 in this area capitalized on the established FEs within the ACS to 189 define new mechanisms, that were not originally envisioned, such as 190 [Paper-ANHASA]. 192 Following this tradition, this document applies a similar approach to 193 logically decomposing mobility management functions. This way we can 194 establish a common framework that will enable us to reason about DMM 195 functionality with well-defined and well-understood FEs or logical 196 functions. As a first step, the DMM Framework presented in this 197 document demonstrates that the existing mobility management functions 198 of MIPv6, PMIPv6, and HMIPv6 can be abstracted into the following 199 logical functions: 201 1. Session identification (SID): An MN may use an SID to enable 202 session continuity for an application during handover. 203 Alternatively, a separate IP address different from the routing 204 IP address, such as that used previously in the home network 205 where the application was initiated, may be used as the SID. 206 Then, this function is tied to the IP prefix function at the home 207 network. In addition, an MN with multiple ongoing applications 208 may use multiple prefixes. This function is able to associate 209 each prefix with the applications actively using the prefix and 210 release the prefix when no application needs to use it anymore. 212 2. Location management (LM): The LM function keeps track of the 213 internetwork location of an MN which may change its IP address as 214 it moves. The information may associate with each SID, the IP 215 routing address of the MN, or of a node that can forward packets 216 destined to the MN. 218 In a client-server model of the system, location query and update 219 messages may be exchanged between the client (LMc) and the server 220 (LMs). Optionally, one (or more) proxy may exist between the LMs 221 and the LMc, i.e., LMs-proxy-LMc. Then, to the LMs, the proxy 222 behaves like the LMc; to the LMc, the proxy behaves like the LMs. 224 3. Routing Management (RM) function: In principle, it is possible to 225 update the routing tables according to the LM information. Yet 226 it is sometimes not practical or not scalable to update the 227 routing tables dynamically to reflect the fast changes of 228 locations especially when a very large number of MNs are in the 229 Internet. The RM function is then an additional routing function 230 beyond those provided by the routing tables, such as forwarding 231 packets using a tunnel, rewriting a packet header to route using 232 another IP address. It is often sufficient to have this 233 additional function in only a limited number of special routers. 234 Then, the RM function in these routers will need to intercept the 235 packets to/from the MN and forward the packets, based on the 236 internetwork location information, either to the destination or 237 to some other network element that knows how to forward the 238 packets to the destination. 240 In addition, the Access Router (AR) logical function provides first- 241 hop network access and includes functionality below the network 242 layer, e.g. radio communication facilities. An AR may provide home 243 address allocation as well as act as RM. 245 4. Mobility Protocol Functional Decomposition 247 This section shows that existing mobility management protocols can be 248 expressed as different configurations of the logical functions 249 introduced in Section 3 above. Using these generic logical 250 functions, we will build up the existing mobility protocols one step 251 at a time in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA. 252 Functions are added and modified as needed in each step. 254 4.1. Decomposing Mobile IPv6 256 Fig. 1 illustrates the Mobile IPv6 [RFC6275] functional decomposition 257 using the logical functions introduced in Section 3. The combination 258 of the RM, LM and HoA allocation logical functions in Network1 259 effectively defines the home agent or the mobility anchor. In the 260 depicted network scenario, the mobile node designated as MN11 was 261 originally attached to Network1 and was allocated an IP prefix for 262 its home address (HoA11). At a later stage, MN11 moves to Network3, 263 where it is allocated a new prefix to configure the IP address IP32. 264 LM1 maintains the binding HoA11:IP32 so that packets from its 265 correspondent node CN21 in Network2 destined to HoA11 can be 266 intercepted by RM1, which will then tunnel them to IP32. MN11 must 267 perform mobility signaling using the LU function. 269 Network1 Network3 Network2 270 SID11,IP32 272 +-----+ 273 | LM1 | 274 +-----+ 275 location=IP32 276 HoA1 alc IP3 alc IP2 alc 277 | 278 | 279 +-----+ 280 | RM1 | 281 +-----+ 282 . 283 . +----+ +----+ +----+ 284 . | | |MN11| | | 285 . |MN31| |+RM | |CN21| 286 . | | |+LMc| | | 287 . +----+ +----+ +----+ 288 SID11 IP31 IP32, 289 =IP11 SID11 291 Figure 1. Functional decomposition of Mobile IPv6 293 4.2. From MIPv6 to PMIPv6 295 The functional decomposition of Proxy Mobile IPv6 [RFC5213] according 296 to the proposed framework is shown in Fig. 2. In PMIPv6, the 297 combination of LM, RM, and HoA allocation effectively defines the 298 Local Mobility Anchor (LMA). The combination of AR and LU together 299 with additional signaling with MN comprises the Mobile Access Gateway 300 (MAG). In the figure, MN11 is attached to the access router AR31 301 which has the IP address IP31 in Network3. LM1 maintains the binding 302 HoA11:IP31. The access router AR31 also behaves like a home link to 303 MN11 so that MN11 can use its original IP address HoA11. 305 Network1 Network3 Network2 306 SID11,IP31 308 +-----+ 309 | LM1 | 310 +-----+ 311 HoA1 alc IP3 alc IP2 alc 312 | 313 | 314 +-----+ 315 | RM1 | 316 +-----+ 317 . 318 . +----+ +----+ 319 . |AR31| | | 320 . |+RM | |CN21| 321 . |+LMc| | | 322 . +----+ +----+ 323 SID11 IP31 324 =IP11 | 325 | 326 +----+ 327 |MN11| 328 +----+ 329 SID11 330 =IP11 332 Figure 2. Functional decomposition of PMIPv6 334 MIPv6 and PMIPv6 both employ the same concept of separating the 335 session identifier (HoA) from the routing address (CoA). Fig. 3 336 contrasts (a) MIPv6 with (b) PMIPv6 by illustrating the destination 337 IP address in the network-layer header as a packet traverses the 338 network from the CN to the MN. Note that MIPv6 and PMIPv6 bundle 339 three mobility management logical functions, namely, LM1, IP1 prefix 340 allocation and RM1 into the home agent (HA) and Local Mobility Anchor 341 (LMA), respectively. 343 Fig. 3 shows that, as far as data-plane traffic is concerned, routing 344 from CN to MN+LU in MIPv6 is similar to the route from CN to AR+LU in 345 PMIPv6. The difference is in that in the former case, the MN with 346 the LU function is substituted by the combination of the AR with the 347 LU function and the MN. While additional signaling is needed to 348 enable the combination of AR+LU and MN to behave like MN+LU in MIPv6, 349 such signaling can be confined between the AR+LU and the MN only. It 350 can therefore be seen under this unified formulation, that a host- 351 based mobility management protocol can be translated using this 352 substitution into a network-based mobility management protocol and 353 vice versa. 355 (a) MIPv6: 357 +---+ +---+---+ +---+ 358 |SID| --> |SID|SID| |SID| 359 | | | |---| |---| 360 | | | |IP | ==> |IP | 361 +---+ +---+---+ +---+ 362 CN RM MN+RM+LMc 364 (b) PMIPv6: 365 +---+ +---+---+ +---+---+ +---+ 366 |SID| --> |SID|SID| |SID|SID| --> |SID| 367 | | | |---| |---| | | | 368 | | | |IP | ==> |IP | | | | 369 +---+ +---+---+ +---+---+ +---+ 370 CN RM AR+RM+LMc MN 372 Figure 3. Network layer in the protocol stack of packets sent from 373 the CN and tunneled (a) to the MN+RM+LMc in MIPv6; and (b) to the AR+ 374 RM+LMc in PMIPv6 showing the destination IP address as the packet 375 traverses from the CN to the MN. 377 4.3. Hierarchical Mobile IPv6 379 The functional decomposition of Hierarchical Mobile IPv6 [RFC5380] is 380 shown in Fig. 4. Besides the logical functions LM1, RM1, and HoA1 381 prefix allocation in Network1, as we have seen above for MIPv6 and 382 PMIPv6, there is an RM function (RM3) in the visited network 383 (Network3). RM3 acts also as a proxy between LM1 and MN11 in the 384 hierarchical LM function LM1--RM3--MN11. That is, LM1 maintains the 385 LM binding HoA11:RM3 while RM3 tracks the LM binding HoA11:IP32. The 386 combined function of RM and the LM proxy function is the Mobility 387 Anchor Point (MAP). 389 Network1 Network3 Network2 390 +-----+ 391 | LM1 | 392 +-----+ 393 HoA1 alc IP3 alc IP2 alc 394 | 395 | 396 +-----+ +-----+ 397 | RM1 | | RM3 | 398 | | |+ LM | 399 | | |proxy| 400 +-----+ +-----+ 401 . / \ 402 . / \ 403 . / \ 404 . +----+ +----+ +----+ 405 . |AR31| |MN11| | | 406 . |+RM | |+RM | |CN21| 407 . |+LMc| |+LMc| | | 408 . +----+ +----+ +----+ 409 SID11 IP31 SID11, 410 =IP11 | IP32 411 | 412 +----+ 413 |MN31| 414 +----+ 415 SID11 416 =IP11 418 Figure 4. Functional decomposition of Hierarchical Mobile IPv6 420 Note that as depicted in Fig. 4, if MN11 takes the place of MN31 421 which is attached to AR31, the resulting mobility management becomes 422 network-based. 424 4.4. Distributing Mobility Anchors 426 As we have seen so far, the framework is sufficiently expressive to 427 enable us to decompose the major MIPv6 variants. It is possible to 428 replicate the mobility anchoring function for any of MIPv6, PMIPv6, 429 or HMIPv6, in multiple networks as shown in Fig. 5 which illustrates 430 such an example with three networks. 432 Network1 Network3 Network2 433 +-----+ +-----+ +-----+ 434 | LM1 | | LM3 | | LM2 | 435 +-----+ +-----+ +-----+ 436 HoA1 alc HoA3 alc HoA2 alc 437 | | | 438 | | | 439 +-----+ +-----+ +-----+ 440 | RM1 | | RM3 | | RM2 | 441 +-----+ +-----+ +-----+ 442 . / \ 443 . / \ 444 . / \ 445 . +----+ +----+ +----+ 446 . |AR31| |MN11| |CN21| 447 . |+RM | |+RM | | | 448 . |+LMc| |+LMc| | | 449 . +----+ +----+ +----+ 450 SID11 IP31 SID11, 451 =IP11 | IP32 452 | 453 +----+ 454 |MN31| 455 +----+ 456 SID11 457 =IP11 459 Figure 5. Distributing mobility anchors using the DMM Framework 460 logical functions 462 4.5. Migrating Home Agents 464 When all logical functions of the Framework are bundled into a single 465 entity e.g., a home agent in MIPv6 or a local mobility anchor in 466 PMIPv6, in a single network, the result is triangular routing when 467 the MN and the CN are in networks close to each other but are far 468 from the anchor point. A method to solve the triangle routing 469 problem is to duplicate the anchor points in many networks in 470 different geographic locations as advocated in 471 [Paper-Migrating.Home.Agents]. A functional decomposition of 472 Migrating Home Agents is shown in Fig. 6: the RM function is 473 available in each of the three networks Network1, Network2, and 474 Network3. The LM function in each network (LM0) contains the LM 475 information for all three networks. Each RM in each network 476 advertises the HoA IP prefixes of all these networks using anycast. 477 Traffic from CN21 in Network2 destined to HoA11 will therefore be 478 intercepted by the RM nearest to the CN, i.e. RM2 in the example of 479 Fig. 6. Using the LM information in LM0, RM2 will use the binding 480 HoA11:IP32 to tunnel the packets to MN11. 482 Network1 Network3 Network2 483 +-----+ +-----+ +-----+ 484 | LM0 |------| LM0 |------| LM0 | 485 +-----+ +-----+ +-----+ 486 HoA1 alc HoA3 alc HoA2 alc 487 | | | 488 | | | 489 +-----+ +-----+ +-----+ 490 | RM1 | | RM3 | | RM2 | 491 +-----+ +-----+ +-----+ 492 . / \ 493 . / \ 494 . / \ 495 . +----+ +----+ +----+ 496 . |AR31| |MN11| | | 497 . |+RM | |+RM | |CN21| 498 . |+LMc| |+LMc| | | 499 . +----+ +----+ +----+ 500 SID11 IP31 SID11, 501 =IP11 | IP32 502 | 503 +----+ 504 |MN31| 505 +----+ 506 SID11 507 =IP11 509 Figure 6. Functional decomposition of Migrating Home Agents 511 Similarly, traffic originating from MN11 will be served by its 512 nearest RM (RM3). Triangular routing is therefore avoided. Yet the 513 synchronization of all home agents becomes a challenge as discussed 514 in [Paper-SMGI]. In addition, the amount of signaling traffic 515 necessary for synchronizing the home agents may become excessive when 516 both the number of mobile nodes and the number of home agents 517 increase. 519 As before, if MN11 in Fig. 6 takes the place of MN31 which is 520 attached to AR31, the resulting mobility management becomes network- 521 based. 523 5. DMM Functional Decomposition Scenarios 525 This section covers the functional description of DMM. Basically, 526 the scenarios present a way to distribute the logical mobility 527 functions. 529 5.1. Flat Network Scenario 531 In a flat network, the logical functions may all be located at the AR 532 as shown in Figs. 7 and 8, respectively. For example, 533 [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed-anchoring] are 534 PMIPv6-based implementations of this scenario. These two figures 535 depict the network- and client-based distributed mobility management 536 scenarios, respectively. AR is expected to support the HoA 537 allocation function. Then, depending on the mobility situation of 538 the MN, the AR can run different functions: 540 1. AR can act as a standard IP router; 542 2. AR can provide the RM function (i.e. act as mobility anchor); 544 3. AR can provide the LU function; 546 4. AR can provide both RM and LU functions. 548 5.1.1. Network-based Mobility Management 550 The functional decomposition of network-based mobility management is 551 depicted in Fig. 7. In case (1), MN1 attaches to AR1. AR advertises 552 the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1 553 initiates a communication with CN11. 555 In case (2), MN1 performs a handover from AR1 to AR3 while 556 maintaining ongoing IP communication with CN11. AR1 becomes the 557 mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM 558 functions on behalf of MN1. AR3 performs LU up to the LM in AR1: AR3 559 indicates to AR1 the new location of the MN1. AR3 allocates a new IP 560 prefix (HoA3) for new IP communications. That is, HoA3 is used for 561 all new IP communications, e.g., if MN1 initiates IP communication 562 with CN21. AR3 shall act as a legacy IP router for MN1-CN21 563 communication. 565 In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP 566 communication with CN11 and CN21. AR1 is the mobility anchor for the 567 MN1-CN11 IP communication. AR3 becomes the mobility anchor for the 568 MN1-CN21 IP communication. Both AR1 and AR3 run RM and LM functions 569 for MN1, respectively, anchoring HoA1 and HoA3. AR2 performs 570 location updates up to the LMs in AR1 and AR3 for respectively 571 relocate HoA1 and HoA3. 573 Network1 Network1 Network3 574 +----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+ 575 |CN11| +-----+ |CN11| +-----+ +-----+ |CN21| 576 | |------| | | |------| RM1 |------| |------- | | 577 +----+ | | +----+ | LM1 |------|LU31 | +----+ 578 | AR1 | | AR1 | |AR3 | 579 | | | | | | 580 +-----+ +-----+ +-----+ 581 | | 582 | | 583 | | 584 +----+ +----+ 585 |MN1 | |MN1 | 586 | | | | 587 +----+ +----+ 588 HoA11 HoA11, 589 HoA31 590 (1) (2) 592 Network2 593 Network1 HoA2 al 594 +----+ HoA1 alc +-----+ 595 |CN11| +-----+ | | 596 | |------| RM1 |-----------------|LU21 |-------+ 597 +----+ | LM1 |-----------------|AR2 | | 598 | AR1 | | | | 599 | | Network3 +-----+ | 600 +-----+ HoA3 al | | +----+ 601 +-----+ | | |MN1 | 602 +----+ |RM3 |------ | | | 603 |CN21| |LM3 |-------- +----+ 604 | |------| | HoA11, 605 +----+ |AR3 | HoA31 606 +-----+ (3) 608 Figure 7. Network-based DMM architecture for a flat network 610 5.1.2. Client-based Mobility Management 612 The functional decomposition of client-based mobility management is 613 depicted in Fig. 8. In case (1), MN1 attaches to AR1. AR advertises 614 the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1 615 initiates a communication with CN11. 617 In case (2), MN1 performs a handover from AR1 to AR3 while 618 maintaining ongoing IP communication with CN11. AR1 becomes the 619 mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM 620 functions for MN1. The MN performs LU directly up to the LM in AR1 621 or via AR3; in this case AR3 acts as a proxy locator (pLU) (e.g. as a 622 FA in MIPv4). AR3 allocates a new IP prefix (HoA3) for new IP 623 communications. HoA3 is supposed to be used for new IP 624 communications, e.g., if MN1 initiates IP communication with CN21. 625 AR3 shall act as a legacy IP router for MN1-CN21 communication. 627 Network1 Network1 Network3 628 +----+ HoA1 alc +----+ HoA1 alc +----+ 629 |CN11| +-----+ |CN | +-----+ +-----+ |CN21| 630 | |------| | | |------| RM1 |------| |------- | | 631 +----+ | | +----+ | LM1 |------|pLU31| +----+ 632 | AR1 | | AR1 | |AR31 | 633 | | | | | | 634 +-----+ +-----+ +-----+ 635 | | 636 | | 637 | | 638 +----+ +----+ 639 |MN1 | |MN1 | 640 | | |LU31| 641 +----+ +----+ 642 HoA11 HoA11, 643 IP31 645 (1) (2) 646 Figure 8. Client-based DMM architecture for a flat network 648 5.2. DMM with Control and Data Plane Separation 650 This section considers a scenario which involves multiple RMs and a 651 distributed LM database. The different use case scenarios of 652 distributed mobility management are described in 653 [I-D.yokota-dmm-scenario] as well as in 654 [Paper-Distributed.Mobility.Review]. The functional decomposition 655 described in this document can be used to understand better the data 656 and control plane separation. 658 Fig. 9 shows an example DMM topology with the same three networks we 659 have been using in Fig. 5. As in Fig. 5, each network in Fig. 9 has 660 its own IP prefix allocation function. In the data plane, the 661 routing management function is distributed to multiple locations at 662 the RMs so that routing can be optimized. In the control plane, the 663 RMs may exchange information with each other. 665 In addition to these features, the LM function in Fig. 9 is a 666 distributed database, possibly implemented with multiple virtual or 667 physical servers, handling the mapping of HoA to CoA. To perform 668 routing management, the RMs need the location information which is 669 maintained at LM1, LM2, and LM3. The RMs are, therefore, the clients 670 of the LM servers and may also send location updates to the LM as the 671 MNs perform the handover. The location information may either be 672 pulled from the LM servers by the RM, or pushed to the RM by the LM 673 servers. In addition, the RM may also cache a limited amount of 674 location information. 676 Network1 Network3 Network2 677 +-----+ +-----+ +-----+ 678 | LM1 | | LM3 | | LM2 | 679 +-----+ +-----+ +-----+ 680 HoA1 alc HoA3 alc HoA2 alc 681 | \ \ / | \ / / | 682 | \ \ / | \ / / | 683 | \ \/ | \/ / | 684 | \ / \ | / \ / | 685 | \/ \|/ \/ | 686 | /\ /|\ /\ | 687 | / \ / | \ / \ | 688 | / /\ | /\ \ | 689 | / / \ | / \ \ | 690 | / / \ | / \ \ | 691 +-----+ +-----+ +-----+ 692 | RM1 |------| RM3 |------| RM2 | 693 +-----+ +-----+ +-----+ 694 . / \ 695 . / \ 696 . / \ 697 . +----+ +----+ +----+ 698 . |AR31| |MN11| | | 699 . |+RM | |+RM | |CN21| 700 . |+LMc| |+LMc| | | 701 . +----+ +----+ +----+ 702 SID11 IP31 SID11, 703 =IP11 | IP32 704 | 705 +----+ 706 |MN31| 707 +----+ 708 SID11 709 =IP11 711 Figure 9. DMM with Control and Data Plane Separation 713 Fig. 9 illustrates three RMs (RM1, RM2, and RM3) in three networks. 714 In this scenario we take that MN11 has moved from Network1 supported 715 by RM1 and LM1 to Network3 supported by RM3 and LM3. MN11 may use 716 the homa address (HoA11) allocated to it when it was directly 717 connected to the former network for those application sessions that 718 were started when the mobile node was attached there and do require 719 session continuity after the handover to the latter network. When 720 MN11 is connected to Network1, no location management is needed; LM1 721 will not keep an entry for HoA11. After MN11 handovers to Network3, 722 the LM1 server maintains a mapping of HoA11 to RM3. That is, LM1 723 points to Network3 and it is this network that will keep track of how 724 to reach MN11. Such a hierarchical mapping can prevent frequent 725 signaling updates to LM1, as MN11 performs intra-network handover(s) 726 within the Network3 domain. In other words, the concept of 727 hierarchical mobile IP [RFC5380] is applied here for location 728 management only but not for data plane routing. 730 6. Security Considerations 732 TBD 734 7. IANA Considerations 736 This document presents no IANA considerations. 738 8. References 740 8.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 8.2. Informative References 747 [Book-AN] Niebert, N., Schieder, A., Zander, J., and R. Hancock 748 (Eds.), "Ambient networks: co-operative mobile networking 749 for the wireless world.", Wiley, 2007. 751 [I-D.bernardos-dmm-distributed-anchoring] 752 Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed 753 anchoring", draft-bernardos-dmm-distributed-anchoring-01 754 (work in progress), September 2012. 756 [I-D.ietf-dmm-requirements] 757 Chan (Ed.) et al., H., "Requirements for Distributed 758 Mobility Management", draft-ietf-dmm-requirements-06 (work 759 in progress), December 2012. 761 [I-D.seite-dmm-dma] 762 Seite, P., Bertin, P., and JH. Lee, "Distributed Mobility 763 Anchoring", draft-seite-dmm-dma-06 (work in progress), 764 January 2013. 766 [I-D.yokota-dmm-scenario] 767 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 768 scenarios for Distributed Mobility Management", 769 draft-yokota-dmm-scenario-00 (work in progress), 770 October 2010. 772 [Paper-ANHASA] 773 Pentikousis, K., Aguero, R., Gebert, J., Galache, J., 774 Blume, O., and P. Paakkonen, "The Ambient Networks 775 heterogeneous access selection architecture", Mobility, 776 Multiaccess, and Network Management (M2NM) 2007. First 777 Ambient Networks Workshop on. Sydney, Australia, October 778 2007, pp. 49-54, October 2007. 780 [Paper-Distributed.Mobility.PMIP] 781 Chan, H., "Proxy Mobile IP with Distributed Mobility 782 Anchors", Proceedings of GlobeCom Workshop on Seamless 783 Wireless Mobility, December 2010. 785 [Paper-Distributed.Mobility.Review] 786 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 787 "Distributed and Dynamic Mobility Management in Mobile 788 Internet: Current Approaches and Issues", February 2011. 790 [Paper-GLL] 791 Koudouridis, G., Aguero, R., Alexandri, E., Choque, J., 792 Dimou, K., Karimi, H., Lederer, H., Sachs, J., and R. 793 Sigle, "Generic link layer functionality for multi-radio 794 access networks", Proc. IST Mobile and Wireless 795 Communication Summit 2005., 2005. 797 [Paper-MRRM] 798 Berggren, F., Bria, A., Badia, L., Karla, I., Litjens, R., 799 Magnusson, P., Meago, F., Tang, H., and R. Veronesi, 800 "Multi-radio resource management for ambient networks", 801 Personal, Indoor and Mobile Radio Communications (PIMRC) 802 2005. IEEE 16th International Symposium on. Vol. 2, pp. 803 942-946, 2005. 805 [Paper-Migrating.Home.Agents] 806 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 807 Agents Towards Internet-scale Mobility Deployments", 808 Proceedings of the ACM 2nd CoNEXT Conference on Future 810 Networking Technologies, December 2006. 812 [Paper-NODEID] 813 Ahlgren, B., Eggert, L., Ohlman, B., and A. Schieder, 814 "Ambient networks: Bridging heterogeneous network 815 domains", Personal, Indoor and Mobile Radio 816 Communications (PIMRC) 2005. IEEE 16th International 817 Symposium on. Vol. 2, pp. 937-941, 2005. 819 [Paper-SMGI] 820 Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in 821 the Global Internet", Proceedings of ACM Workshop on 822 MICNET, MobiCom 2009, Beijing, China, September 2009. 824 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 825 RFC 4988, October 2007. 827 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 828 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 830 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 831 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 832 Management", RFC 5380, October 2008. 834 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 835 July 2009. 837 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 838 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 839 September 2010. 841 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 842 in IPv6", RFC 6275, July 2011. 844 Appendix A. Comparing against DMM requirements 846 This section examines how the framework meets the DMM requirements. 848 A.1. First DMM requirement: distributed processing 850 The framework has defined a set of mm functions which can be 851 implemented in a distributed fashion. As further evidence, the 852 document explains how the mm functions can be used to implement in a 853 distributed manner the major mm protocols (MIPv6, PMIPv6, HMIP, DMA, 854 MHA). 856 A.2. Second DMM requirement: Transparency to upper layers when needed 858 In the framework, transparency depends on how the RM functions is 859 implemented. This draft has already shown that using the framework 860 one can express, for example, PMIP and DMA, which are transparent to 861 the upper layers. 863 A.3. Third DMM requirement: IPv6 deployment 865 The framework is not tied to a particular IP version, and therefore 866 supports IPv6 deployment. 868 A.4. Fourth DMM requirement: Existing mobility protocols 870 This draft has already described how to express the functionality of 871 several mm protocols (MIPv6, PMIPv6, HMIP, DMA, MHA). More cases can 872 be added as feedback is received. 874 A.5. Fifth DMM requirement: co-existence 876 The framework enables the expression of existing protocols in 877 functions that can be extended to provide distributed mobility 878 support, and can be made backwards compatible with existing 879 implementations. 881 A.6. Sixth DMM requirement: Security considerations 883 Security risks are associated with the particular DMM solution. The 884 framework is flexible and does not restrict DMM solutions in a way 885 that the DMM solution can increase security risks. 887 A.7. Seventh DMM requirement: multicast 889 It appears possible to extend the framework by decomposing multimob 890 solutions with the framework. 892 Authors' Addresses 894 H Anthony Chan 895 Huawei Technologies 896 5340 Legacy Dr. Building 3 897 Plano, TX 75024 898 USA 900 Email: h.a.chan@ieee.org 901 Pierrick Seite 902 France Telecom - Orange 903 4, rue du Clos Courtel, BP 91226 904 Cesson-Sevigne 35512 905 France 907 Email: pierrick.seite@orange-ftgroup.com 909 Kostas Pentikousis 910 EICT GmbH 912 Email: k.pentikousis@eict.de 914 Ashutosh Dutta 915 ATT 916 200 Laurel Ave S 917 Middletown, NJ 07748 918 USA 920 Email: ashutosh.dutta@ieee.org