idnits 2.17.1 draft-bernardos-dmm-pmip-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 date (January 31, 2014) is 3735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3315' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC4620' is defined on line 682, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-03 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-02 == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-12 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Standards Track F. Giust 5 Expires: August 4, 2014 UC3M 6 January 31, 2014 8 A PMIPv6-based solution for Distributed Mobility Management 9 draft-bernardos-dmm-pmip-03 11 Abstract 13 The number of mobile users and their traffic demand is expected to be 14 ever-increasing in future years, and this growth can represent a 15 limitation for deploying current mobility management schemes that are 16 intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. 17 For this reason it has been waved a need for distributed and dynamic 18 mobility management approaches, with the objective of reducing 19 operators' burdens, evolving to a cheaper and more efficient 20 architecture. 22 This draft describes multiple solutions for network-based distributed 23 mobility management inspired by the well known Proxy Mobile IPv6. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 4, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Partially distributed solution . . . . . . . . . . . . . . . 4 68 3.1. Initial registration . . . . . . . . . . . . . . . . . . 6 69 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 7 70 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 9 71 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 10 72 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 11 73 3.6. Message Format . . . . . . . . . . . . . . . . . . . . . 11 74 3.6.1. Previous MAAR Option . . . . . . . . . . . . . . . . 11 75 3.6.2. Serving MAAR Option . . . . . . . . . . . . . . . . . 13 76 4. Fully distributed solution . . . . . . . . . . . . . . . . . 13 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 8.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Appendix A. Comparison with Requirement document . . . . . . . . 15 84 A.1. Distributed Processing . . . . . . . . . . . . . . . . . 16 85 A.2. Transparency to Upper Layers when needed . . . . . . . . 16 86 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 16 87 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 16 88 A.5. Co-existence with deployed networks and hosts . . . . . . 17 89 A.6. Security considerations . . . . . . . . . . . . . . . . . 17 90 A.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 91 Appendix B. Implementation experience . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 Current IP mobility solutions, standardized with the names of Mobile 97 IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two 98 most relevant examples, offer mobility support at the cost of 99 handling operations at a cardinal point, the mobility anchor, and 100 burdening it with data forwarding and control mechanisms for a great 101 amount of users. As stated in [I-D.ietf-dmm-requirements], 102 centralized mobility solutions are prone to several problems and 103 limitations: longer (sub-optimal) routing paths, scalability 104 problems, signaling overhead (and most likely a longer associated 105 handover latency), more complex network deployment, higher 106 vulnerability due to the existence of a potential single point of 107 failure, and lack of granularity on the mobility management service 108 (i.e., mobility is offered on a per-node basis, not being possible to 109 define finer granularity policies, as for example per-application). 111 The purpose of Distributed Mobility Management is to overcome the 112 limitations of the traditional centralized mobility management 113 [I-D.ietf-dmm-requirements] 114 [I-D.ietf-dmm-best-practices-gap-analysis]; the main concept behind 115 DMM solutions is indeed bringing the mobility anchor closer to the 116 MN. Following this idea, in our proposal, the central anchor is 117 moved to the edge of the network, being deployed in the default 118 gateway of the mobile node. That is, the first elements that provide 119 IP connectivity to a set of MNs are also the mobility managers for 120 those MNs. In the following, we will call these entities Mobility 121 Anchor and Access Routers (MAARs). 123 This document focuses on network-based DMM, hence the starting point 124 is making PMIPv6 working in a distributed manner 125 [I-D.ietf-dmm-best-practices-gap-analysis]. In our proposal, as in 126 PMIPv6, mobility is handled by the network without the MNs 127 involvement, but, differently from PMIP, when the MN moves from one 128 access network to another, it also changes anchor router, hence 129 requiring signaling between the anchors to retrieve the MN's previous 130 location(s). Also, a key-aspect of network-based DMM, is that a 131 prefix pool belongs exclusively to each MAAR, in the sense that those 132 prefixes are assigned by the MAAR to the MNs attached to it, and they 133 are routable at that MAAR. 135 In the following, we consider two main approaches to design our DMM 136 solutions: 138 o Partially distributed schemes, where the data plane only is 139 distributed among access routers similar to MAGs, whereas the 140 control plane is kept centralized towards a cardinal node used as 141 information store, but relieved from any route management and MN's 142 data forwarding task. 144 o Fully distributed schemes, where both data and control planes are 145 distributed among the access routers. 147 2. Terminology 149 The following terms used in this document are defined in the Proxy 150 Mobile IPv6 specification [RFC5213]: 152 Local Mobility Anchor (LMA) 154 Mobile Access Gateway (MAG) 156 Mobile Node (MN) 158 Binding Cache Entry (BCE) 160 Proxy Care-of Address (P-CoA) 162 Proxy Binding Update (PBU) 164 Proxy Binding Acknowledgement (PBA) 166 The following terms are defined and used in this document: 168 MAAR (Mobility Anchor and Access Router). First hop router where the 169 mobile nodes attach to. It also plays the role of mobility 170 manager for the IPv6 prefixes it anchors, running the 171 functionalities of PMIP's MAG and LMA. 173 CMD (Central Mobility Database). Node that stores the BCEs allocated 174 for the MNs in the mobility domain. 176 P-MAAR (Previous MAAR). MAAR which was previously visited by the MN 177 and is still involved in an active flow using an IPv6 prefix it 178 has advertised to the MN (i.e., MAAR where that IPv6 prefix is 179 anchored). There might be multiple P-MAARs for an MN's mobility 180 session. 182 S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. 184 3. Partially distributed solution 186 The following solution consists in de-coupling the entities that 187 participates in the data and the control planes: the data plane 188 becomes distributed and managed by the MAARs near the edge of the 189 network, while the control plane, besides on the MAARs, relies on a 190 central entity called Central Mobility Database (CMD). In the 191 proposed architecture, the hierarchy present in PMIP between LMA and 192 MAG is preserved, but with the following substantial variations: 194 o The LMA is relieved from the data forwarding role, only the 195 Binding Cache and its management operations are maintained. Hence 196 the LMA is renamed into Central Mobility Database (CMD). Also, 197 the CMD is able to send and parse both PBU and PBA messages. 199 o The MAG is enriched with the LMA functionalities, hence the name 200 Mobility Anchor and Access Router (MAAR). It maintains a local 201 Binding Cache for the MNs that are attached to it and it is able 202 to send and parse PBU and PBA messages. 204 o The binding cache will have to be extended to include information 205 regarding previous MAARs where the mobile node was anchored and 206 still retains active data sessions, see Appendix B for further 207 details. 209 o Each MAAR has a unique set of global prefixes (which are 210 configurable), that can be allocated by the MAAR to the MNs, but 211 must be exclusive to that MAAR, i.e. no other MAAR can allocate 212 the same prefixes. 214 The MAARs leverage on the Central Mobility Database (CMD) to access 215 and update information related to the MNs, stored as mobility 216 sessions; hence, a centralized node maintains a global view on the 217 status of the network. The CMD is queried whenever a MN is detected 218 to join/leave the mobility domain. It might be a fresh attachment, a 219 detachment or a handover, but as MAARs are not aware of past 220 information related to a mobility session, they contact the CMD to 221 retrieve the data of interest and eventually take the appropriate 222 action. The procedure adopted for the query and the messages 223 exchange sequence might vary to optimize the update latency and/or 224 the signaling overhead. Here is presented one method for the initial 225 registration, and three different approaches to update the mobility 226 sessions using PBUs and PBAs. Each approach assigns a different role 227 to the CMD: 229 o The CMD is a PBU/PBA relay; 231 o The CMD is only a MAAR locator; 233 o The CMD is a PBU/PBA proxy. 235 3.1. Initial registration 237 Upon the MN's attachment to a MAAR, say MAAR1, if the MN is 238 authorized for the service, an IPv6 global prefix belonging to the 239 MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding 240 Cache Entry (BCE) allocated locally. The prefix is sent in a 241 [RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which, 242 since the session is new, stores a permanent BCE containing as main 243 fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. 244 The CMD replies to MAAR1 with a PBA including the usual options 245 defined in PMIP/RFC5213, meaning that the MN's registration is fresh 246 and no past status is available. MAAR1 definitely stores the 247 temporal BCE previously allocated and unicasts a Router Advertisement 248 (RA) to the MN including the prefix reserved before, that can be used 249 by the MN to configure an IPv6 address (e.g., with stateless auto- 250 configuration). The address is routable at the MAAR, in the sense 251 that it is on the path of packets addressed to the MN. Moreover, the 252 MAAR acts as plain router for those packets, as no encapsulation nor 253 special handling takes place. Figure 1 illustrates this scenario. 255 +-----+ +---+ +--+ 256 |MAAR1| |CMD| |CN| 257 +-----+ +---+ +*-+ 258 | | * 259 MN | * +---+ 260 attach. | ***** _|CMD|_ 261 detection | flow1 * / +-+-+ \ 262 | | * / | \ 263 local BCE | * / | \ 264 allocation | * / | \ 265 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 266 | BCE | * | | | | | 267 | creation |MAAR1+------+MAAR2+-----+MAAR3| 268 |<-- PBA ---| | * | | | | | 269 local BCE | +---*-+ +-----+ +-----+ 270 finalized | * 271 | | Pref1 * 272 | | +*-+ 273 | | |MN| 274 | | +--+ 276 Operations sequence Packets flow 278 Figure 1: First attachment to the network 280 3.2. The CMD as PBU/PBA relay 282 When the MN moves from its current access and associates to MAAR2 283 (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it 284 stores a temporal BCE, and it sends a plain PBU to the CMD for 285 registration. Upon PBU reception and BC lookup, the CMD retrieves an 286 already existing entry for the MN, binding the MN-ID to its former 287 location; thus, the CMD forwards the PBU to the MAAR indicated as 288 Proxy CoA (MAAR1), including a new mobility option to communicate the 289 S-MAAR's global address to MAAR1, defined as Serving MAAR Option in 290 Section 3.6.2. The CMD updates the P-CoA field in the BCE related to 291 the MN with the S-MAAR's address. 293 Upon PBU reception, MAAR1 can install a tunnel on its side towards 294 MAAR2 and the related routes for Pref1. Then MAAR1 replies to the 295 CMD with a PBA (including the option mentioned before) to ensure that 296 the new location has successfully changed, containing the prefix 297 anchored at MAAR1 in the Home Network Prefix option. The CMD, after 298 receiving the PBA, updates the BCE populating an instance of the 299 P-MAAR list. The P-MAAR list is an additional field on the BCE that 300 contains an element for each P-MAAR involved in the MN's mobility 301 session. The list element contains the P-MAAR's global address and 302 the prefix it has delegated (see Appendix B for further details). 303 Also, the CMD send a PBA to the new S-MAAR, containing the previous 304 Proxy-CoA and the prefix anchored to it embedded into a new mobility 305 option called Previous MAAR Option (defined in Section 3.6.1), so 306 that, upon PBA arrival, a bi-directional tunnel can be established 307 between the two MAARs and new routes are set appropriately to recover 308 the IP flow(s) carrying Pref1. 310 Now packets destined to Pref1 are first received by MAAR1, 311 encapsulated into the tunnel and forwarded to MAAR2, which finally 312 delivers them to their destination. In uplink, when the MN transmits 313 packets using Pref1 as source address, they are sent to MAAR2, as it 314 is MN's new default gateway, then tunneled to MAAR1 which routes them 315 towards the next hop to destination. Conversely, packets carrying 316 Pref2 are routed by MAAR2 without any special packet handling both 317 for uplink and downlink. The procedure is depicted in Figure 2. 319 +-----+ +---+ +-----+ +--+ +--+ 320 |MAAR1| |CMD| |MAAR2| |CN| |CN| 321 +-----+ +---+ +-----+ +*-+ +*-+ 322 | | | * * 323 | | MN * +---+ * 324 | | attach. ***** _|CMD|_ * 325 | | det. flow1 * / +-+-+ \ *flow2 326 | |<-- PBU ---| * / | \ * 327 | BCE | * / | ******* 328 | check+ | * / | * \ 329 | update | +---*-+-? +--+-*+ `+-----+ 330 |<-- PBU*---| | | * | | *| | | 331 route | | |MAAR1|______|MAAR2+-----+MAAR3| 332 update | | | **(______)** *| | | 333 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 334 | BCE | * * 335 | update | Pref1 * *Pref2 336 | |--- PBA*-->| +*--*+ 337 | | route ---move-->|*MN*| 338 | | update +----+ 340 Operations sequence Data Packets flow 341 PBU/PBA Messages with * contain 342 a new mobility option 344 Figure 2: Scenario after a handover, CMD as relay 346 For next MN's movements the process is repeated except for the number 347 of P-MAARs involved, that rises accordingly to the number of prefixes 348 that the MN wishes to maintain. Indeed, once the CMD receives the 349 first PBU from the new S-MAAR, it forwards copies of the PBU to all 350 the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 351 prior to handover) and in the P-MAARs list. They reply with a PBA to 352 the CMD, which aggregates them into a single one to notify the 353 S-MAAR, that finally can establish the tunnels with the P-MAARs. 355 It should be noted that this design separates the mobility management 356 at the prefix granularity, and it can be tuned in order to erase old 357 mobility sessions when not required, while the MN is reachable 358 through the latest prefix acquired. Moreover, the latency associated 359 to the mobility update is bound to the PBA sent by the furthest 360 P-MAAR, in terms of RTT, that takes the longest time to reach the 361 CMD. The drawback can be mitigated introducing a timeout at the CMD, 362 by which, after its expiration, all the PBAs so far collected are 363 transmitted, and the remaining are sent later upon their arrival. 365 3.3. The CMD as MAAR locator 367 The handover latency experienced in the approach shown before can be 368 reduced if the P-MAARs are allowed to signal directly their 369 information to the new S-MAAR. This procedure reflect what was 370 described in Section 3.2 up to the moment the P-MAAR receives the PBU 371 with the P-MAAR option. At that point a P-MAAR is aware of the new 372 MN's location (because of the S-MAAR's address in the S-MAAR option), 373 and, besides sending a PBA to the CMD, it also sends a PBA to the 374 S-MAAR including the prefix it is anchoring. This latter PBA does 375 not need to include new options, as the prefix is embedded in the HNP 376 option and the P-MAAR's address OS taken from the message's source 377 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 378 as the latter receives a copy directly from the P-MAAR with the 379 necessary information to build the tunnels and set the appropriate 380 routes. In Figure 3 is illustrated the new messages sequence, while 381 the data forwarding is unaltered. 383 +-----+ +---+ +-----+ +--+ +--+ 384 |MAAR1| |CMD| |MAAR2| |CN| |CN| 385 +-----+ +---+ +-----+ +*-+ +*-+ 386 | | | * * 387 | | MN * +---+ * 388 | | attach. ***** _|CMD|_ * 389 | | det. flow1 * / +-+-+ \ *flow2 390 | |<-- PBU ---| * / | \ * 391 | BCE | * / | ******* 392 | check+ | * / | * \ 393 | update | +---*-+-? +--+-*+ `+-----+ 394 |<-- PBU*---| | | * | | *| | | 395 route | | |MAAR1|______|MAAR2+-----+MAAR3| 396 update | | | **(______)** *| | | 397 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 398 |--- PBA*-->| route * * 399 | BCE update Pref1 * *Pref2 400 | update | +*--*+ 401 | | | ---move-->|*MN*| 402 | | | +----+ 404 Operations sequence Data Packets flow 405 PBU/PBA Messages with * contain 406 a new mobility option 408 Figure 3: Scenario after a handover, CMD as locator 410 3.4. The CMD as MAAR proxy 412 A further enhancement of previous solutions can be achieved when the 413 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 414 the location change. Indeed, when the CMD receives the PBU for the 415 new registration, it is already in possess of all the information 416 that the new S-MAAR requires to set up the tunnels and the routes. 417 Thus the PBA is sent to the S-MAAR immediately after a PBU is 418 received, including also in this case the P-MAAR option. In 419 parallel, a PBU is sent by the CMD to the P-MAARs containing the 420 S-MAAR option, to notify them about the new MN's location, so they 421 receive the information to establish the tunnels and routes on their 422 side. When P-MAARs complete the update, they send a PBA to the CMD 423 to indicate that the operation is concluded and the information are 424 updated in all network nodes. This procedure is obtained from the 425 first one re-arranging the order of the messages, but the parameters 426 communicated are the same. This scheme is depicted in Figure 4, 427 where, again, the data forwarding is kept untouched. 429 +-----+ +---+ +-----+ +--+ +--+ 430 |MAAR1| |CMD| |MAAR2| |CN| |CN| 431 +-----+ +---+ +-----+ +*-+ +*-+ 432 | | | * * 433 | | MN * +---+ * 434 | | attach. ***** _|CMD|_ * 435 | | det. flow1 * / +-+-+ \ *flow2 436 | |<-- PBU ---| * / | \ * 437 | BCE | * / | ******* 438 | check+ | * / | * \ 439 | update | +---*-+-? +--+-*+ `+-----+ 440 |<-- PBU*---x--- PBA*-->| | * | | *| | | 441 route | route |MAAR1|______|MAAR2+-----+MAAR3| 442 update | update | **(______)** *| | | 443 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 444 | BCE | * * 445 | update | Pref1 * *Pref2 446 | | | +*--*+ 447 | | | ---move-->|*MN*| 448 | | | +----+ 450 Operations sequence Data Packets flow 451 PBU/PBA Messages with * contain 452 a new mobility option 454 Figure 4: Scenario after a handover, CMD as proxy 456 3.5. De-registration 458 The de-registration mechanism devised for PMIPv6 is no longer valid 459 in the Partial DMM architecture. This is motivated by the fact that 460 each MAAR handles an independent mobility session (i.e., a single or 461 a set of prefixes) for a given MN, whereas the aggregated session is 462 stored at the CMD. Indeed, when a previous MAAR initiates a de- 463 registration procedure, because the MN is no longer present on the 464 MAAR's access link, it removes the routing state for that (those) 465 prefix(es), that would be deleted by the CMD as well, hence defeating 466 any prefix continuity attempt. The simplest approach to overcome 467 this limitation is to deny an old MAAR to de-register a prefix, that 468 is, allowing only a serving MAAR to de-register the whole MN session. 469 This can be achieved by first removing any layer-2 detachment event, 470 so that de-registration is triggered only when the session lifetime 471 expires, hence providing a guard interval for the MN to connect to a 472 new MAAR. Then, a change in the MAAR operations is required, and at 473 this stage two possible solutions can be deployed: 475 o A previous MAAR stops the BCE timer upon receiving a PBU from the 476 CMD containing a "Serving MAAR" option. In this way only the 477 Serving MAAR is allowed to de-register the mobility session, 478 arguing that the MN left definitely the domain. 480 o Previous MAARs can, upon BCE expiry, send de-registration messages 481 to the CMD, which, instead of acknowledging the message with a 0 482 lifetime, send back a PBA with a non-zero lifetime, hence re- 483 newing the session, if the MN is still connected to the domain. 485 The evaluation of these methods is left for future work. 487 3.6. Message Format 489 This section defines two Mobility Options to be used in the PBU and 490 PBA messages: 492 Previous MAAR Option; 494 Serving MAAR Option. 496 In the current draft the messages reflect IPv6 format only. IPv4 497 compatibility will be added in next release. 499 3.6.1. Previous MAAR Option 501 This new option is defined for use with the Proxy Binding 502 Acknowledgement messages exchanged by the CMD to a MAAR. This option 503 is used to notify the S-MAAR about the previous MAAR's global address 504 and the prefix anchored to it. There can be multiple Previous MAAR 505 options present in the message. Its format is as follows: 507 0 1 2 3 508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type | Length | Prefix Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 + + 514 | | 515 + P-MAAR's address + 516 | | 517 + + 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 + + 522 | | 523 + Home Network Prefix + 524 | | 525 + + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Type 531 To be assigned by IANA. 533 Length 535 8-bit unsigned integer indicating the length of the option in 536 octets, excluding the type and length fields. This field MUST be 537 set to 34. 539 Prefix Length 541 8-bit unsigned integer indicating the prefix length of the IPv6 542 prefix contained in the option. 544 Previous MAAR's address 546 A sixteen-byte field containing the P-MAAR's IPv6 global address. 548 Home Network Prefix 550 A sixteen-byte field containing the mobile node's IPv6 Home 551 Network Prefix. 553 3.6.2. Serving MAAR Option 555 This new option is defined for use with the Proxy Binding Update and 556 Proxy Binding Acknowledgement messages exchanged between the CMD and 557 a Previous MAAR. This option is used to notify the P-MAAR about the 558 current Serving MAAR's global address. Its format is as follows: 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 + + 567 | | 568 + S-MAAR's address + 569 | | 570 + + 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Type 576 To be assigned by IANA. 578 Length 580 8-bit unsigned integer indicating the length of the option in 581 octets, excluding the type and length fields. This field MUST be 582 set to 16. 584 Serving MAAR's address 586 A sixteen-byte field containing the S-MAAR's IPv6 global address. 588 4. Fully distributed solution 590 In this section we introduce the guidelines to evolve our partially 591 DMM solution into a fully distributed one. We list the key concepts 592 in the following (some of the points are already enforced in previous 593 sections of this document): 595 o All MAARs have a pool of global routable IPv6 prefixes to be 596 assigned to MNs on the access link. 598 o Any central control entity is removed from the architecture and 599 each MAAR will retain it's own cache for the mobile nodes directly 600 anchored to it. 602 o Both control and data planes are now entirely handled by the 603 MAARs. 605 Because we aim for a fully distributed approach, the lack of 606 knowledge of other MAARs and their advertised prefixes becomes a 607 serious obstacle. In this particular case, when a MN attaches to a 608 MAAR, there are two main pieces ofi nformation that this MAAR 609 requires to know, to properly assure a mobile node's mobility and 610 continuity of its data flows: i) if the node has any P-MAARs and 611 their addresses; ii) if it has P-MAARs, which prefixes were 612 advertised by which MAAR. 614 There are several methods to achieve this: 616 o Make before approaches, employing Layer 2 or Layer 3 mechanisms. 617 The target MAAR is known in advance by the current MAAR before 618 handover, hence the mobility context can be transferred. 620 o Distributed schemes for MAAR discovery: it can based on a peer-to- 621 peer approach; or it can employ a unicast, multicast or broadcast 622 query system. 624 o Explicit notification by the MN. For example, extending the layer 625 three IP address configuration mechanisms (e.g., ND). 627 o Other MN to MAAR communication protocol (e.g., IEEE 802.21). 629 5. IANA Considerations 631 TBD. 633 6. Security Considerations 635 The solution assumes that the nodes are trusted and secure MAAR-to- 636 MAAR communications are in place, for instance re-using the security 637 mechanisms defined for PMIPv6. Thus, the solution does not introduce 638 any new security vulnerability. 640 7. Acknowledgments 642 The authors would like to thank Marco Liebsch for his comments and 643 discussion on this document. 645 8. References 647 8.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 653 and M. Carney, "Dynamic Host Configuration Protocol for 654 IPv6 (DHCPv6)", RFC 3315, July 2003. 656 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 657 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 659 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 660 in IPv6", RFC 6275, July 2011. 662 8.2. Informative References 664 [I-D.bernardos-dmm-distributed-anchoring] 665 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 666 anchoring", draft-bernardos-dmm-distributed-anchoring-03 667 (work in progress), October 2013. 669 [I-D.ietf-dmm-best-practices-gap-analysis] 670 Liu, D., Zuniga, J., Seite, P., Chan, A., and C. 671 Bernardos, "Distributed Mobility Management: Current 672 practices and gap analysis", draft-ietf-dmm-best- 673 practices-gap-analysis-02 (work in progress), October 674 2013. 676 [I-D.ietf-dmm-requirements] 677 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 678 "Requirements for Distributed Mobility Management", draft- 679 ietf-dmm-requirements-12 (work in progress), December 680 2013. 682 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 683 Queries", RFC 4620, August 2006. 685 Appendix A. Comparison with Requirement document 687 In this section we descrbe how our solution addresses the DMM 688 requirements listed in [I-D.ietf-dmm-requirements]. 690 A.1. Distributed Processing 692 "IP mobility, network access and routing solutions provided by DMM 693 MUST enable distributed processing for mobility management of some 694 flows so that traffic does not need to traverse centrally deployed 695 mobility anchors and thereby avoid non-optimal routes." 697 In our solution, a MAAR is responsible to handle the mobility for 698 those IP flows started when the MN is attached to it. As long as the 699 MN remains connected to the MAAR's access links, the IP packets of 700 such flows can benefit from the optimal path. When the MN moves to 701 another MAAR, the path becomes non-optimal for ongoing flows, as they 702 are anchored to the previous MAAR, but newly started IP sessions are 703 forwarded by the new MAAR through the optimal path. 705 A.2. Transparency to Upper Layers when needed 707 "DMM solutions MUST provide transparent mobility support above the IP 708 layer when needed. Such transparency is needed, for example, when, 709 upon change of point of attachment to the network, an application 710 flow cannot cope with a change in the IP address. However, it is not 711 always necessary to maintain a stable home IP address or prefix for 712 every application or at all times for a mobile node." 714 Our DMM solution operates at the IP layer, hence upper layers are 715 totally transparent to the mobility operations. In particular, 716 ongoing IP sessions are not disrupted after a change of access 717 network. The routability of the old address is ensured by the IP 718 tunnel with the old MAAR. New IP sessions are started with the new 719 address. From the application's perspective, those processes which 720 sockets are bound to a unique IP address do not suffer any impact. 721 For the other applications, the sockets bound to the old address are 722 preserved, whereas next sockets use the new address. 724 A.3. IPv6 deployment 726 "DMM solutions SHOULD target IPv6 as the primary deployment 727 environment and SHOULD NOT be tailored specifically to support IPv4, 728 in particular in situations where private IPv4 addresses and/or NATs 729 are used." 731 The DMM solution we propose targets IPv6 only. 733 A.4. Existing mobility protocols 735 "A DMM solution SHOULD first consider reusing and extending IETF- 736 standardized protocols before specifying new protocols." 737 This DMM solution is derived from the operations and messages 738 specified in [RFC5213]. 740 A.5. Co-existence with deployed networks and hosts 742 "The DMM solution MUST be able to co-exist with existing network 743 deployments and end hosts. For example, depending on the environment 744 in which DMM is deployed, DMM solutions may need to be compatible 745 with other deployed mobility protocols or may need to co-exist with a 746 network or mobile hosts/routers that do not support DMM protocols. 747 The mobile node may also move between different access networks, 748 where some of them may support neither DMM nor another mobility 749 protocol. Furthermore, a DMM solution SHOULD work across different 750 networks, possibly operated as separate administrative domains, when 751 allowed by the trust relationship between them." 753 The partially DMM solution can be extended to provide a fallback 754 mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to 755 instruct MAARs to always establish a tunnel with the same MAAR, 756 working as LMA. The fully DMM solution can be extended as well, but 757 it requires more intervention. The partially DMM solution can be 758 deployed across different domains with trust agreements if the CMDs 759 ot the operators are enabled to transfer context from one node to 760 another. The fully DMM solution works across multiple domains if 761 both solution apply the same signalling scheme. 763 A.6. Security considerations 765 "DMM protocol solutions MUST consider security risks introduced by 766 DMM into the network. Such considerations may include authentication 767 and authorization mechanisms that allow a mobile host/router to use 768 the mobility support provided by the DMM solution; measures against 769 redirecting traffic to the wrong host when providing DMM support; 770 signaling message protection for authentication, integrity and 771 confidentiality." 773 The proposed solution does not specify a security mechanism, given 774 that the same mechanism for PMIPv6 can be used. 776 A.7. Multicast 778 "DMM SHOULD enable multicast solutions in flexible distribution 779 scenario. This flexibility pertains to the preservation of IP 780 multicast nature from the perspective of a mobility entity and 781 transmission of multicast packets to/from various multicast- enabled 782 entities. Therefore, this flexibility enables different IP multicast 783 flows with respect to a mobile host to be managed (e.g., subscribed, 784 received and/or transmitted) using multiple multicast-enabled 785 endpoints." 787 This solution in its current version does not specify any support for 788 multicast traffic, which is left for study in future versions. 790 Appendix B. Implementation experience 792 The network-based DMM solution described in section Section 3.4 is 793 now available at the Open Distributed Mobility Management (ODMM) 794 project (http://www.odmm.net), under the name of Mobility Anchors 795 Distribution for PMIPv6 (MAD-PMIPv6). The ODMM platform is intended 796 to foster DMM development and deployment, by serving as a framework 797 to host open source implementations. 799 The MAD-PMIPv6 code is developed in ANSI C from the existing UMIP 800 implementation for PMIP. The most relevant changes with respect to 801 the UMIP original version are related to how to create the CMD and 802 MAAR's state machines from those of an LMA and a MAG; for this 803 purpose, part of the LMA code was copied to the MAG, in order to send 804 PBA messages and parse PBU. Also, the LMA routing functions were 805 removed completely, and moved to the MAG, because MAARs need to route 806 through the tunnels in downlink (as an LMA) and in uplink (as a MAG). 808 Tunnel management is hence a relevant technical aspect, as multiple 809 tunnels are established by a single MAAR, which keeps their status 810 directly into the MN's BCE. Indeed, from the implementation 811 experience it was chosen to create an ancillary data structure as 812 field within a BCE: the data structure is called "MAAR list" and 813 stores the previous MAARs' address and the corresponding prefix(es) 814 assigned for the MN. Only the CMD and the serving MAAR store this 815 data structure, because the CMD maintains the global MN's mobility 816 session formed during the MN's roaming within the domain, and the 817 serving MAAR needs to know which previous MAARs were visited, the 818 prefix(es) they assigned and the tunnels established with them. 819 Conversely, a previous MAAR only needs to know which is the current 820 Serving MAAR and establish a single tunnel with it. For this reason, 821 a MAAR that receives a PBU from the CMD (meaning that the MN attached 822 to another MAAR), first sets up the routing state for the MN's 823 prefix(es) it is anchoring, then stop the BCE expiry timer and 824 deletes the MAAR list (if present) since it is no longer useful. 826 In order to have the MN totally unaware of the changes in the access 827 link, all MAARs implement the Distributed Logical Interface (DLIF) 828 concept devised in [I-D.bernardos-dmm-distributed-anchoring]. 829 Moreover, it should be noted that the protocols designed in the 830 document work only at the network layer to handle the MNs joining or 831 leaving the domain. This should guarantee a certain independency to 832 a particular access technology. The implementation reflects this 833 reasoning, but we argue that an interaction with lower layers 834 produces a more effective attachment and detachment detection, 835 therefore improving the performance, also regarding de-registration 836 mechanisms. 838 It was chosen to implement the "proxy" solution because it produces 839 the shortest handover latency, but a slight modification on the CMD 840 state machine can produce the first scenario described ("relay") 841 which guarantees a more consistent request/ack scheme between the 842 MAARS. By modifying also the MAAR's state machine it can be 843 implemented the second solution ("locator"). 845 An early MAD-PMIPv6 implementation was shown during a demo session at 846 the IETF 83rd, in Paris in March 2012. An enhancement version of the 847 prototype has been presented at the 87th IETF meeting in Berlin, July 848 2013. The updated demo included a use case scenario employing a CDN 849 system for video delivery. More, MAD-PMIPv6 has been extensively 850 used and evaluated within a testbed employing heterogeneous radio 851 accesses within the framework of the MEDIEVAL EU project. MAD-PMIPv6 852 software is currently part of a DMM test-bed comprising 3 MAARs, one 853 CMD, one MN and a CN. All the machines used in the demos were Linux 854 UBUNTU 10.04 systems with kernel 2.6.32, but the prototype has been 855 tested also under newer systems. This testbed is being maintained by 856 the iJOIN EU project. 858 Authors' Addresses 860 Carlos J. Bernardos 861 Universidad Carlos III de Madrid 862 Av. Universidad, 30 863 Leganes, Madrid 28911 864 Spain 866 Phone: +34 91624 6236 867 Email: cjbc@it.uc3m.es 868 URI: http://www.it.uc3m.es/cjbc/ 870 Antonio de la Oliva 871 Universidad Carlos III de Madrid 872 Av. Universidad, 30 873 Leganes, Madrid 28911 874 Spain 876 Phone: +34 91624 8803 877 Email: aoliva@it.uc3m.es 878 URI: http://www.it.uc3m.es/aoliva/ 879 Fabio Giust 880 Universidad Carlos III de Madrid 881 Av. Universidad, 30 882 Leganes, Madrid 28911 883 Spain 885 Phone: +34 91624 8859 886 Email: fgiust@it.uc3m.es 887 URI: http://www.it.uc3m.es/fgiust/