idnits 2.17.1 draft-bernardos-dmm-pmip-01.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 (March 13, 2012) is 4428 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 UC3M 5 Expires: September 14, 2012 F. Giust 6 IMDEA Networks and UC3M 7 T. Melia 8 R. Costa 9 Alcatel-Lucent 10 March 13, 2012 12 A PMIPv6-based solution for Distributed Mobility Management 13 draft-bernardos-dmm-pmip-01 15 Abstract 17 The number of mobile users and their traffic demand is expected to be 18 ever-increasing in future years, and this growth can represent a 19 limitation for deploying current mobility management schemes that are 20 intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. 21 For this reason it has been waved a need for distributed and dynamic 22 mobility management approaches, with the objective of reducing 23 operators' burdens, evolving to a cheaper and more efficient 24 architecture. 26 This draft describes multiple solutions for network-based distributed 27 mobility management inspired by the well known Proxy Mobile IPv6. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 September 14, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. PMIPv6-based solution . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Initial registration . . . . . . . . . . . . . . . . . . . 7 72 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . . 8 73 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 74 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 75 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 76 3.6. Message Format . . . . . . . . . . . . . . . . . . . . . . 12 77 3.6.1. Previous MAAR Option . . . . . . . . . . . . . . . . . 12 78 3.6.2. Serving MAAR Option . . . . . . . . . . . . . . . . . 14 79 4. DHCPv6-based solution . . . . . . . . . . . . . . . . . . . . 14 80 4.1. Using DHCPv6's database . . . . . . . . . . . . . . . . . 15 81 4.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 15 82 4.3. De-Registration . . . . . . . . . . . . . . . . . . . . . 17 83 4.4. Non-supported nodes and DHCPv6 . . . . . . . . . . . . . . 18 84 5. Fully distributed solution . . . . . . . . . . . . . . . . . . 18 85 5.1. Solution Example . . . . . . . . . . . . . . . . . . . . . 19 86 5.2. Work Flow . . . . . . . . . . . . . . . . . . . . . . . . 19 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 93 Appendix A. Implementation experience . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 Current IP mobility solutions, standardized with the names of Mobile 99 IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two 100 most relevant examples, offer mobility support at the cost of 101 handling operations at a cardinal point, the mobility anchor, and 102 burdening it with data forwarding and control mechanisms for a great 103 amount of users. As stated in [I-D.chan-distributed-mobility-ps], 104 centralized mobility solutions are prone to several problems and 105 limitations: longer (sub-optimal) routing paths, scalability 106 problems, signaling overhead (and most likely a longer associated 107 handover latency), more complex network deployment, higher 108 vulnerability due to the existence of a potential single point of 109 failure, and lack of granularity on the mobility management service 110 (i.e., mobility is offered on a per-node basis, not being possible to 111 define finer granularity policies, as for example per-application). 113 The purpose of Distributed Mobility Management is to overcome the 114 limitations of the traditional centralized mobility management; the 115 main concept behind DMM solutions is indeed bringing the mobility 116 anchor closer to the MN. Following this idea, in our proposal, the 117 central anchor is moved to the edge of the network, being deployed in 118 the default gateway of the mobile node. That is, the first elements 119 that provide IP connectivity to a set of MNs are also the mobility 120 managers for those MNs. In the following, we will call these 121 entities Mobility 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. In our proposal, 125 as in PMIPv6, mobility is handled by the network without the MNs 126 involvement, but, differently from PMIP, when the MN moves from one 127 access network to another, it also changes anchor router, hence 128 requiring signaling between the anchors to retrieve the MN's previous 129 location(s). Also, a key-aspect of network-based DMM, is that a 130 prefix pool belongs exclusively to each MAAR, in the sense that those 131 prefixes are assigned by the MAAR to the MNs attached to it, and they 132 are routable at that MAAR. 134 In the following, we consider two main approaches to design our DMM 135 solutions: 137 o Partially distributed schemes, where the data plane only is 138 distributed among access routers similar to MAGs, whereas the 139 control plane is kept centralized towards a cardinal node used as 140 information store, but relieved from any route management and MN's 141 data forwarding task. We describe in this document two different 142 approaches: one based on extending PMIPv6 signaling and the use of 143 a centralized database entity (when stateless address 144 configuration is used by the mobile node), and one based on 145 extending DHCPv6 (when stateful address configuration is used by 146 the mobile node). 148 o Fully distributed schemes, where both data and control planes are 149 distributed among the access routers. 151 2. Terminology 153 The following terms used in this document are defined in the Proxy 154 Mobile IPv6 specification [RFC5213]: 156 Local Mobility Anchor (LMA) 158 Mobile Access Gateway (MAG) 160 Mobile Node (MN) 162 Binding Cache Entry (BCE) 164 Proxy Care-of Address (P-CoA) 166 Proxy Binding Update (PBU) 168 Proxy Binding Acknowledgement (PBA) 170 The following terms are defined and used in this document: 172 MAAR (Mobility Anchor and Access Router). First hop router where the 173 mobile nodes attach to. It also plays the role of mobility 174 manager for the IPv6 prefixes it anchors, running the 175 functionalities of PMIP's MAG and LMA. 177 CMD (Central Mobility Database). Node that stores the BCEs allocated 178 for the MNs in the mobility domain. 180 P-MAAR (Previous MAAR). MAAR which was previously visited by the MN 181 and is still involved in an active flow using an IPv6 prefix it 182 has advertised to the MN (i.e., MAAR where that IPv6 prefix is 183 anchored). There might be multiple P-MAARs for an MN's mobility 184 session. 186 S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. 188 3. PMIPv6-based solution 190 The following solution belongs to the partially distributed category, 191 and it consists in de-coupling the entities that participates in the 192 data and the control planes: the data plane becomes distributed and 193 managed by the MAARs near the edge of the network, while the control 194 plane, besides on the MAARs, relies on a central entity called 195 Central Mobility Database (CMD). In the proposed architecture, the 196 hierarchy present in PMIP between LMA and MAG is preserved, but with 197 the following substantial variations: 199 o The LMA is relieved from the data forwarding role, only the 200 Binding Cache and its management operations are maintained. Hence 201 the LMA is renamed into Central Mobility Database (CMD). Also, 202 the CMD is able to send and parse both PBU and PBA messages. 204 o The MAG is enriched with the LMA functionalities, hence the name 205 Mobility Anchor and Access Router (MAAR). It maintains a local 206 Binding Cache for the MNs that are attached to it and it is able 207 to send and parse PBU and PBA messages. 209 o The binding cache will have to be extended to include information 210 regarding previous MAARs where the mobile node was anchored and 211 still retains active data sessions, see Appendix A for further 212 details. 214 o Each MAAR has a unique set of global prefixes (which are 215 configurable), that can be allocated by the MAAR to the MNs, but 216 must be exclusive to that MAAR, i.e. no other MAAR can allocate 217 the same prefixes. 219 The MAARs leverage on the Central Mobility Database (CMD) to access 220 and update information related to the MNs, stored as mobility 221 sessions; hence, a centralized node maintains a global view on the 222 status of the network. The CMD is queried whenever a MN is detected 223 to join/leave the mobility domain. It might be a fresh attachment, a 224 detachment or a handover, but as MAARs are not aware of past 225 information related to a mobility session, they contact the CMD to 226 retrieve the data of interest and eventually take the appropriate 227 action. The procedure adopted for the query and the messages 228 exchange sequence might vary to optimize the update latency and/or 229 the signaling overhead. Here is presented one method for the initial 230 registration, and three different approaches to update the mobility 231 sessions using PBUs and PBAs. Each approach assigns a different role 232 to the CMD: 234 o The CMD is a PBU/PBA relay; 235 o The CMD is only a MAAR locator; 237 o The CMD is a PBU/PBA proxy. 239 3.1. Initial registration 241 Upon the MN's attachment to a MAAR, say MAAR1, if the MN is 242 authorized for the service, an IPv6 global prefix belonging to the 243 MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding 244 Cache Entry (BCE) allocated locally. The prefix is sent in a 245 [RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which, 246 since the session is new, stores a permanent BCE containing as main 247 fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. 248 The CMD replies to MAAR1 with a PBA including the usual options 249 defined in PMIP/RFC5213, meaning that the MN's registration is fresh 250 and no past status is available. MAAR1 definitely stores the 251 temporal BCE previously allocated and unicasts a Router Advertisement 252 (RA) to the MN including the prefix reserved before, that can be used 253 by the MN to configure an IPv6 address (e.g., with stateless auto- 254 configuration). The address is routable at the MAAR, in the sense 255 that it is on the path of packets addressed to the MN. Moreover, the 256 MAAR acts as plain router for those packets, as no encapsulation nor 257 special handling takes place. Figure 1 illustrates this scenario. 259 +-----+ +---+ +--+ 260 |MAAR1| |CMD| |CN| 261 +-----+ +---+ +*-+ 262 | | * 263 MN | * +---+ 264 attach. | ***** _|CMD|_ 265 detection | flow1 * / +-+-+ \ 266 | | * / | \ 267 local BCE | * / | \ 268 allocation | * / | \ 269 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 270 | BCE | * | | | | | 271 | creation |MAAR1+------+MAAR2+-----+MAAR3| 272 |<-- PBA ---| | * | | | | | 273 local BCE | +---*-+ +-----+ +-----+ 274 finalized | * 275 | | Pref1 * 276 | | +*-+ 277 | | |MN| 278 | | +--+ 280 Operations sequence Packets flow 282 Figure 1: First attachment to the network 284 3.2. The CMD as PBU/PBA relay 286 When the MN moves from its current access and associates to MAAR2 287 (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it 288 stores a temporal BCE, and it sends a plain PBU to the CMD for 289 registration. Upon PBU reception and BC lookup, the CMD retrieves an 290 already existing entry for the MN, binding the MN-ID to its former 291 location; thus, the CMD forwards the PBU to the MAAR indicated as 292 Proxy CoA (MAAR1), including a new mobility option to communicate the 293 S-MAAR's global address to MAAR1, defined as Serving MAAR Option in 294 Section 3.6.2. The CMD updates the P-CoA field in the BCE related to 295 the MN with the S-MAAR's address. 297 Upon PBU reception, MAAR1 can install a tunnel on its side towards 298 MAAR2 and the related routes for Pref1. Then MAAR1 replies to the 299 CMD with a PBA (including the option mentioned before) to ensure that 300 the new location has successfully changed, containing the prefix 301 anchored at MAAR1 in the Home Network Prefix option. The CMD, after 302 receiving the PBA, updates the BCE populating an instance of the 303 P-MAAR list. The P-MAAR list is an additional field on the BCE that 304 contains an element for each P-MAAR involved in the MN's mobility 305 session. The list element contains the P-MAAR's global address and 306 the prefix it has delegated (see Appendix A for further details). 307 Also, the CMD send a PBA to the new S-MAAR, containing the previous 308 Proxy-CoA and the prefix anchored to it embedded into a new mobility 309 option called Previous MAAR Option (defined in Section 3.6.1), so 310 that, upon PBA arrival, a bi-directional tunnel can be established 311 between the two MAARs and new routes are set appropriately to recover 312 the IP flow(s) carrying Pref1. 314 Now packets destined to Pref1 are first received by MAAR1, 315 encapsulated into the tunnel and forwarded to MAAR2, which finally 316 delivers them to their destination. In uplink, when the MN transmits 317 packets using Pref1 as source address, they are sent to MAAR2, as it 318 is MN's new default gateway, then tunneled to MAAR1 which routes them 319 towards the next hop to destination. Conversely, packets carrying 320 Pref2 are routed by MAAR2 without any special packet handling both 321 for uplink and downlink. The procedure is depicted in Figure 2. 323 +-----+ +---+ +-----+ +--+ +--+ 324 |MAAR1| |CMD| |MAAR2| |CN| |CN| 325 +-----+ +---+ +-----+ +*-+ +*-+ 326 | | | * * 327 | | MN * +---+ * 328 | | attach. ***** _|CMD|_ * 329 | | det. flow1 * / +-+-+ \ *flow2 330 | |<-- PBU ---| * / | \ * 331 | BCE | * / | ******* 332 | check+ | * / | * \ 333 | update | +---*-+-? +--+-*+ `+-----+ 334 |<-- PBU*---| | | * | | *| | | 335 route | | |MAAR1|______|MAAR2+-----+MAAR3| 336 update | | | **(______)** *| | | 337 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 338 | BCE | * * 339 | update | Pref1 * *Pref2 340 | |--- PBA*-->| +*--*+ 341 | | route ---move-->|*MN*| 342 | | update +----+ 344 Operations sequence Data Packets flow 345 PBU/PBA Messages with * contain 346 a new mobility option 348 Figure 2: Scenario after a handover, CMD as relay 350 For next MN's movements the process is repeated except for the number 351 of P-MAARs involved, that rises accordingly to the number of prefixes 352 that the MN wishes to maintain. Indeed, once the CMD receives the 353 first PBU from the new S-MAAR, it forwards copies of the PBU to all 354 the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 355 prior to handover) and in the P-MAARs list. They reply with a PBA to 356 the CMD, which aggregates them into a single one to notify the 357 S-MAAR, that finally can establish the tunnels with the P-MAARs. 359 It should be noted that this design separates the mobility management 360 at the prefix granularity, and it can be tuned in order to erase old 361 mobility sessions when not required, while the MN is reachable 362 through the latest prefix acquired. Moreover, the latency associated 363 to the mobility update is bound to the PBA sent by the furthest 364 P-MAAR, in terms of RTT, that takes the longest time to reach the 365 CMD. The drawback can be mitigated introducing a timeout at the CMD, 366 by which, after its expiration, all the PBAs so far collected are 367 transmitted, and the remaining are sent later upon their arrival. 369 3.3. The CMD as MAAR locator 371 The handover latency experienced in the approach shown before can be 372 reduced if the P-MAARs are allowed to signal directly their 373 information to the new S-MAAR. This procedure reflect what was 374 described in Section 3.2 up to the moment the P-MAAR receives the PBU 375 with the P-MAAR option. At that point a P-MAAR is aware of the new 376 MN's location (because of the S-MAAR's address in the S-MAAR option), 377 and, besides sending a PBA to the CMD, it also sends a PBA to the 378 S-MAAR including the prefix it is anchoring. This latter PBA does 379 not need to include new options, as the prefix is embedded in the HNP 380 option and the P-MAAR's address OS taken from the message's source 381 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 382 as the latter receives a copy directly from the P-MAAR with the 383 necessary information to build the tunnels and set the appropriate 384 routes. In Figure 3 is illustrated the new messages sequence, while 385 the data forwarding is unaltered. 387 +-----+ +---+ +-----+ +--+ +--+ 388 |MAAR1| |CMD| |MAAR2| |CN| |CN| 389 +-----+ +---+ +-----+ +*-+ +*-+ 390 | | | * * 391 | | MN * +---+ * 392 | | attach. ***** _|CMD|_ * 393 | | det. flow1 * / +-+-+ \ *flow2 394 | |<-- PBU ---| * / | \ * 395 | BCE | * / | ******* 396 | check+ | * / | * \ 397 | update | +---*-+-? +--+-*+ `+-----+ 398 |<-- PBU*---| | | * | | *| | | 399 route | | |MAAR1|______|MAAR2+-----+MAAR3| 400 update | | | **(______)** *| | | 401 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 402 |--- PBA*-->| route * * 403 | BCE update Pref1 * *Pref2 404 | update | +*--*+ 405 | | | ---move-->|*MN*| 406 | | | +----+ 408 Operations sequence Data Packets flow 409 PBU/PBA Messages with * contain 410 a new mobility option 412 Figure 3: Scenario after a handover, CMD as locator 414 3.4. The CMD as MAAR proxy 416 A further enhancement of previous solutions can be achieved when the 417 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 418 the location change. Indeed, when the CMD receives the PBU for the 419 new registration, it is already in possess of all the information 420 that the new S-MAAR requires to set up the tunnels and the routes. 421 Thus the PBA is sent to the S-MAAR immediately after a PBU is 422 received, including also in this case the P-MAAR option. In 423 parallel, a PBU is sent by the CMD to the P-MAARs containing the 424 S-MAAR option, to notify them about the new MN's location, so they 425 receive the information to establish the tunnels and routes on their 426 side. When P-MAARs complete the update, they send a PBA to the CMD 427 to indicate that the operation is concluded and the information are 428 updated in all network nodes. This procedure is obtained from the 429 first one re-arranging the order of the messages, but the parameters 430 communicated are the same. This scheme is depicted in Figure 4, 431 where, again, the data forwarding is kept untouched. 433 +-----+ +---+ +-----+ +--+ +--+ 434 |MAAR1| |CMD| |MAAR2| |CN| |CN| 435 +-----+ +---+ +-----+ +*-+ +*-+ 436 | | | * * 437 | | MN * +---+ * 438 | | attach. ***** _|CMD|_ * 439 | | det. flow1 * / +-+-+ \ *flow2 440 | |<-- PBU ---| * / | \ * 441 | BCE | * / | ******* 442 | check+ | * / | * \ 443 | update | +---*-+-? +--+-*+ `+-----+ 444 |<-- PBU*---x--- PBA*-->| | * | | *| | | 445 route | route |MAAR1|______|MAAR2+-----+MAAR3| 446 update | update | **(______)** *| | | 447 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 448 | BCE | * * 449 | update | Pref1 * *Pref2 450 | | | +*--*+ 451 | | | ---move-->|*MN*| 452 | | | +----+ 454 Operations sequence Data Packets flow 455 PBU/PBA Messages with * contain 456 a new mobility option 458 Figure 4: Scenario after a handover, CMD as proxy 460 3.5. De-registration 462 The de-registration mechanism devised for PMIPv6 is no longer valid 463 in the Partial DMM architecture. This is motivated by the fact that 464 each MAAR handles an independent mobility session (i.e., a single or 465 a set of prefixes) for a given MN, whereas the aggregated session is 466 stored at the CMD. Indeed, when a previous MAAR initiates a de- 467 registration procedure, because the MN is no longer present on the 468 MAAR's access link, it removes the routing state for that (those) 469 prefix(es), that would be deleted by the CMD as well, hence defeating 470 any prefix continuity attempt. The simplest approach to overcome 471 this limitation is to deny an old MAAR to de-register a prefix, that 472 is, allowing only a serving MAAR to de-register the whole MN session. 473 This can be achieved by first removing any layer-2 detachment event, 474 so that de-registration is triggered only when the session lifetime 475 expires, hence providing a guard interval for the MN to connect to a 476 new MAAR. Then, a change in the MAAR operations is required, and at 477 this stage two possible solutions can be deployed: 479 o A previous MAAR stops the BCE timer upon receiving a PBU from the 480 CMD containing a "Serving MAAR" option. In this way only the 481 Serving MAAR is allowed to de-register the mobility session, 482 arguing that the MN left definitely the domain. 484 o Previous MAARs can, upon BCE expiry, send de-registration messages 485 to the CMD, which, instead of acknowledging the message with a 0 486 lifetime, send back a PBA with a non-zero lifetime, hence re- 487 newing the session, if the MN is still connected to the domain. 489 The evaluation of these methods is left for future work. 491 3.6. Message Format 493 This section defines two Mobility Options to be used in the PBU and 494 PBA messages: 496 Previous MAAR Option 498 Serving MAAR Option 500 In the current draft the messages reflect IPv6 format only. IPv4 501 compatibility will be added in next release. 503 3.6.1. Previous MAAR Option 505 This new option is defined for use with the Proxy Binding 506 Acknowledgement messages exchanged by the CMD to a MAAR. This option 507 is used to notify the S-MAAR about the previous MAAR's global address 508 and the prefix anchored to it. There can be multiple Previous MAAR 509 options present in the message. Its format is as follows: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Prefix Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 + + 518 | | 519 + P-MAAR's address + 520 | | 521 + + 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 + + 526 | | 527 + Home Network Prefix + 528 | | 529 + + 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Type 535 To be assigned by IANA. 537 Length 539 8-bit unsigned integer indicating the length of the option in 540 octets, excluding the type and length fields. This field MUST be 541 set to 34. 543 Prefix Length 545 8-bit unsigned integer indicating the prefix length of the IPv6 546 prefix contained in the option. 548 Previous MAAR's address 550 A sixteen-byte field containing the P-MAAR's IPv6 global address. 552 Home Network Prefix 554 A sixteen-byte field containing the mobile node's IPv6 Home 555 Network Prefix. 557 3.6.2. Serving MAAR Option 559 This new option is defined for use with the Proxy Binding Update and 560 Proxy Binding Acknowledgement messages exchanged between the CMD and 561 a Previous MAAR. This option is used to notify the P-MAAR about the 562 current Serving MAAR's global address. Its format is as follows: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type | Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 + + 571 | | 572 + S-MAAR's address + 573 | | 574 + + 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Type 580 To be assigned by IANA. 582 Length 584 8-bit unsigned integer indicating the length of the option in 585 octets, excluding the type and length fields. This field MUST be 586 set to 16. 588 Serving MAAR's address 590 A sixteen-byte field containing the S-MAAR's IPv6 global address. 592 4. DHCPv6-based solution 594 As the solution presented before, next scheme follows the partially 595 distributed approach. Instead of using a dedicated entity such as 596 the CMD, in this proposal we leverage on the collaboration between 597 PMIPv6 and DHCPv6 [RFC3315] to provide the control plane, while the 598 data plane is distributed among the MAARs. To be clearer, in the 599 following key points we present the similarities and differences 600 between this solution and the ones before: 602 o The CMD is removed from the architecture. 604 o The MAAR entity is present, but an emphasis in given to the DCHP 605 relay component running along with the LMA and MAG 606 functionalities. 608 o The set of global prefixes assigned to each MAAR must be 609 synchronized with the domain's DHCPv6 server as defined in 610 [RFC5213]. This means, we push the prefix management operations 611 to the DHCP domain server, providing in the MAAR just the mobility 612 control. 614 o All MAARs must have global routable IPv6 addresses (one per 615 prefix) on the access link, which are built in the exact same way 616 (derived from the link-local address), and maintain the same link- 617 local address principle as in PMIPv6 (i.e. all MAARs are 618 configured with the same link-local address on the access link). 619 (Note: in the first version of this document no DHCP options are 620 defined for P-MAAR recognition, it is work for furhter study). 622 o Each MAAR may or may not have knowledge of other MAARs, and may or 623 may not have had previous contact with other MAARs. 625 4.1. Using DHCPv6's database 627 An issue to be albe to perform the PBU/PBA signaling among MAARs is 628 how to know the address of the P-MAAR(s) from where the mobile node 629 came from and has other anchored data flows, so to direct the PBU to 630 the right P-MAAR(s) and subsequently tunnel the data flows. 632 To solve the issue we intend to gather the information required to 633 address the PBU/PBA message sequence to the corresponding P-MAARs in 634 a simple way. By slightly adapting the work flow of the protocols, 635 we allow the MAARs to learn the node's P-MAARs from the address 636 configuration process of DHCPv6. Since the PMIPv6 protocol standard 637 has specific mechanisms in place that already adapt DHCPv6 to be able 638 to cope with PMIPv6 specifications, we take advantage of these DHCPv6 639 mechanisms and enhance them to fit our needs. 641 4.2. Protocol Operation 643 When the managed network is using DHCPv6 and a new mobile node 644 attaches to a MAAR, a Binding Cache Entry is created, and a prefix is 645 allocated to the mobile node. Since the node is using statefull IP 646 address configuration, the mobile node will shortly send a DHCP- 647 Request message to the proper address and port on the MAAR where a 648 DHCP-Relay will be listening. The DHCP-Relay will act according to 649 the specified behavior in [RFC5213] and on reception and treatment of 650 the DHCP-Request by the DHCP server, we propose adding the following 651 enhancements: 653 o Once the DHCP server receives a DHCP-Request message from the 654 mobile node, it will reply not only with the same prefixes already 655 existent in the previous lease, but will also allocate the new 656 prefixes corresponding to the new link. 658 o The prefixes belonging to any P-MAARs will have their lifetime set 659 to zero, establishing them as deprecated and to be used only for 660 ongoing data flows, while new data flows should use the newly 661 allocated prefixes. 663 When the DHCP-Relay co-located with the MAAR receives the DHCP-Reply 664 message, it will pass the information contained in the message to the 665 MAAR. If there were no other previous prefixes then this is a new 666 registration, and the MAAR BCE is updated, the DHCP-Reply relayed to 667 the mobile node, allowing the address configuration based on the 668 allocated prefix. 670 Otherwise if there were older prefixes, the MAAR must send PBUs to 671 the P-MAARs. The MAAR will first look for any known P-MAAR addresses 672 related to the prefixes received from the DHCP-Relay. If the query 673 is unsuccessful, a P-MAAR address can still be built based on three 674 pieces of information: i) the previous prefixes allocated to the 675 mobile node by the DHCP server, known through the DHCP-Relay; ii) the 676 fact that the IP addresses of the MAARs on the link access are all 677 built the same way; iii) the fact that the the IP addresses of the 678 MAARs on the link access are reachable through the core network. 680 The PBUs are sent to the P-MAARs in order to update their BCEs, 681 routing and establish new data tunnels if any flows for this mobile 682 node are anchored in that P-MAAR. The P-MAARs will reply back with 683 PBAs accordingly, using as source address not the access link address 684 but their own core network interface address. Upon reception, this 685 enables the MAAR to learn the right address for the P-MAAR and update 686 it's BCE information, routing and to create a data tunnel if 687 necessary. 689 Meanwhile the DHCP Relay on the MAAR had relayed the DHCP-Reply 690 message to the mobile node, triggering it's IP address configuration. 692 +-------+ +-------+ +-------+ +-----------+ +--+ +--+ 693 |DHCP CL| |DHCP RL| |DHCP RL| |DHCP Server| |CN| |CN| 694 +-------+ +-------+ +-------+ +-----------+ +*-+ +*-+ 695 | MN | | P-MAAR| | MAAR | | * * 696 +-------+ +-------+ +-------+ | flow1* flow2 * 697 | | | | * * 698 | | MN attach. | .*-'-.-'-.-*. 699 |------- DHCP REQ ----->| | / * * \ 700 | | BCE create+ | \ * Core * / 701 | | Prefix Alloc | / * Network * \ 702 | | | | \ * * / 703 | | |--DHCP RL REQ->| '*'-.-'-.-'*' 704 | | | | * * 705 | | | Renews old +-----------+ * * 706 | | | prefix(s)+ adds |DHCP Server| * * 707 | | | new prefix(s) +----:------+ * * 708 | | | | :............. * 709 | | |<-DHCP RL REP--| : * : * 710 | | BCE | +----:-+ * +-:----+* 711 | | update | |DHCP | * |DHCP |* 712 |<------ DHCP REP ------| | |Relay | ****** |Relay |* 713 | | build | +------+-*+ +------+*+ 714 | | P-MAAR | | P-MAAR *|_____| MAAR *| 715 | | address | | *(_____)* *| 716 | |<-- PBU ---| | +---------+ +*------*+ 717 | BCE | | * * 718 | update | | +*------*+ 719 | +route | | |* MN *| 720 | update | | --- move --> +--------+ 721 | |--- PBA -->| | |DHCP CL | 722 | | BCE | +--------+ 723 | | update | 724 | | +route | 725 | | update | 727 Control Signalling Data Flow 729 Figure 5: Work flow of the DHCPv6 partially distributed approach. 731 4.3. De-Registration 733 The PMIPv6 protocol already includes the case in which the need to 734 revoke or delete an allocated prefix to a mobile node arises. It 735 uses the DHCP's mechanism to do so and it is complemented, in this 736 case, by the MAAR sending to the mobile a Route Advertisement with 737 the mentioned prefix's lifetime set to zero. 739 4.4. Non-supported nodes and DHCPv6 741 It may happen that network wishes to allow terminals that the network 742 does not have support for mobility (e.g. roaming terminals that do 743 not belong to this domain), to enjoy the benefit of using stateful 744 address configuration. To these nodes regular DHCPv6 behavior can 745 still be attained. Upon identification of the node and it's status, 746 any mobility related procedures can be skipped, allowing the regular 747 procedures of DHCPv6 to take place. 749 5. Fully distributed solution 751 Following the logical sense of the approaches described in previous 752 sections of this document, the next logical step would be to 753 introduce a fully distributed solution. We present it in order to 754 show that our previous proposals can be reused to tackle with the 755 enormous restriction of depending on the use of a centralized control 756 entity, and so we decided to also cover this possibility as the final 757 step of an evolving mobility architecture. 759 Firstly, we reuse the concept of MAAR: the MAARs are, in a 760 distributed manner, located on the edge of the network near the 761 access, being the major difference here the lack of a centralized 762 control to share information between themselves. The information and 763 functionalities of both PMIP's MAG and LMA are now present on each 764 and every MAAR, giving each MAAR it's own micro domain and therefore 765 a view of only a subset that composes the local domain network, 766 namely the set of mobile nodes directly anchored to it. 768 We reuse as well some of the points enforced in previous sections of 769 this document: 771 o Any central control entity is removed from the architecture and 772 each MAAR will retain it's own cache for the mobile nodes directly 773 anchored to it. 775 o Both control and data planes are now entirely handled by the 776 MAARs, although data and control are decoupled. 778 o All MAARs must have global routable IPv6 addresses (one per 779 prefix) on the access link, which are built in the exact same way 780 (derived from the link-local address), and maintain the same link- 781 local address principle as in PMIPv6 (i.e. all MAARs are 782 configured with the same link-local address on the access link). 784 Because we aim for a fully distributed approach, the lack of 785 knowledge of other MAARs and their advertised prefixes becomes a 786 serious obstacle. In this particular case, there are three main 787 pieces of information that a MAAR requires to know, to properly 788 assure a mobile node's mobility and continuity of it's data flows: i) 789 if the node has any P-MAARs; ii) if it has P-MAARs, how many are 790 there; and iii) the P-MAARs addresses. 792 There are several methods to achieve this: 794 o Layer 2 mechanisms with capability to retrieve the IP addresses 795 configured in the mobile node (MN to MAAR communication) 797 o A peer-to-peer communication service between the MAARs (either 798 unicast or multicast). 800 o A distibuted scheme that allows MAAR discovery (either unicast or 801 multicast) 803 o Extensions to layer three IP address configuration mechanisms 804 (e.g. ND) 806 o Other MN to MAAR communication protocol (e.g. IEEE 802.21) 808 5.1. Solution Example 810 The Node Information Queries (NIQ) [RFC4620] protocol fits nicely in 811 this situation, where it can allow the MAAR to obtain part of the 812 needed information from the mobile node. The NIQ protocol makes 813 possible for two entities to communicate at a simple level and 814 through a simple query-reply message sequence retrieves information 815 related to names and IP addresses. The protocol's applicability 816 statement clearly points out that the protocol can be used to learn 817 configured IP addresses and names on a point-to-point or medium- 818 shared link, such as the the connection between the MAAR and the 819 mobile node. 821 5.2. Work Flow 823 If the managed network is not using DHCPv6, then it falls to the use 824 of NIQ [RFC4620]. When When a new mobile node attaches to a MAAR, a 825 Binding Cache Entry is created, and a prefix is allocated to the 826 mobile node. Since the node is using stateless IP address 827 configuration, the mobile node will shortly send a IMCP Route 828 Solicitation message that will be listened by the MAAR. 830 The MAAR will then send a NI Query message to the mobile node's link- 831 local address with the Qtype field with set to 3, asking for the 832 mobile node's IPv6 addresses. The mobile node will reply with a NI 833 Reply message containing currently configured IP addresses. 835 Upon the reception of the NI Reply, the MAAR will check the 836 configured addresses and extract the prefixes. Then it will first 837 look for any known P-MAAR addresses related to the prefixes. If any 838 prefix does not have a P-MAAR address the P-MAAR address can still be 839 built based on three pieces of information: i) the prefixes extracted 840 from the IP address belonging to the NI-Reply message; ii) the fact 841 that the IP addresses of the MAARs on the link access are all built 842 the same way; iii) the fact that the the IP addresses of the MAARs on 843 the link access are reachable through the core network. 845 Once all the required P-MAAR addresses are known, a PBU is sent to 846 each P-MAAR, updating their BCEs, routing and will establish new data 847 tunnels if any flows for this mobile node are anchored in that 848 P-MAAR. The P-MAARs will reply back with PBAs accordingly, using as 849 source address not the access link address but their own address. 850 Upon reception, this enables the MAAR to learn the right address for 851 the P-MAAR and update it's BCE information, routing and to create 852 it's endpoint of the data tunnel if necessary. 854 Finally the MAAR will send the unicast Route Advertisement message to 855 the mobile node, triggering it's new IP address configuration. 857 +-----+ +-------+ +-----+ +--+ +--+ 858 | MN | | P-MAAR| | MAAR| |CN| |CN| 859 +-----+ +-------+ +-----+ +*-+ +*-+ 860 | | | * * 861 | | MN attach. * flow1 * flow2 862 | | BCE create+ * * 863 | | Prefix Alloc .*.-'-.-'-.-'-.-*. 864 |-------- RtSol ------->| / * * \ 865 |<------ NI Query ------| | * Core Network * | 866 |------- NI Reply ----->| \ * * / 867 | | build '*-'-.-'-.-'-.-'*' 868 | | P-MAAR * * 869 | | address * * 870 | |<-- PBU ---| +--------*+ +-------*+ 871 | BCE | | P-MAAR *|_____| MAAR *| 872 | update | | *(_____)* *| 873 | +route | +---------+ +*------*+ 874 | update | * * 875 | |--- PBA -->| * * 876 | | BCE +*------*+ 877 | | update --- move --> |* MN *| 878 | | +route +--------+ 879 | | update 880 |<------- RtAdv --------| 882 Control Signalling Data Flow 884 Figure 6: Work flow of the fully distributed approach. 886 6. IANA Considerations 888 TBD. 890 7. Security Considerations 892 TBD. 894 8. Acknowledgments 896 The authors would like to thank Marco Liebsch for his comments and 897 discussion on this document. 899 The research leading to these results has received funding from the 900 European Community's Seventh Framework Programme (FP7-ICT-2009-5) 901 under grant agreement n. 258053 (MEDIEVAL project). The work of 902 Carlos J. Bernardos has also been partially supported by the Ministry 903 of Science and Innovation of Spain under the QUARTET project 904 (TIN2009-13992-C02-01). 906 9. References 908 9.1. Normative References 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 914 and M. Carney, "Dynamic Host Configuration Protocol for 915 IPv6 (DHCPv6)", RFC 3315, July 2003. 917 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 918 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 920 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 921 in IPv6", RFC 6275, July 2011. 923 9.2. Informative References 925 [I-D.chan-distributed-mobility-ps] 926 Chan, A., "Problem statement for distributed and dynamic 927 mobility management", 928 draft-chan-distributed-mobility-ps-05 (work in progress), 929 October 2011. 931 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 932 Queries", RFC 4620, August 2006. 934 Appendix A. Implementation experience 936 The solution described in section Section 3.4 has been implemented in 937 a real test-bed comprising 3 MAARs, one CMD, one MN and a CN. The CN 938 is connected to the DMM domain through a router, which simulates the 939 gateway to the internet cloud. All the machines used are Linux 940 UBUNTU 10.04 systems with kernel 2.26.32. 942 The code is developed from an existing implementation of PMIP 943 (OpenAirInterface Proxy Mobile IPv6: OAI PMIPv6) partially developed 944 within the framework of the MEDIEVAL EU project. The most relevant 945 changes are related to how to create the CMD and MAAR's state 946 machines from those of an LMA and a MAG; for this purpose, part of 947 the LMA code was copied to the MAG, in order to send PBA messages and 948 parse PBU. Also, the LMA routing functions were removed completely, 949 and moved to the MAG, because MAARs need to route through the tunnels 950 in downlink (as an LMA) and in uplink (as a MAG). 952 Tunnel management is hence a relevant technical aspect, as multiple 953 tunnels are established by a single MAAR, which keeps their status 954 directly into the MN's BCE. Indeed, from the implementation 955 experience it was chosen to create an ancillary data structure as 956 field within a BCE: the data structure is called "MAAR list" and 957 stores the previous MAARs' address and the corresponding prefix(es) 958 assigned for the MN. Only the CMD and the serving MAAR store this 959 data structure, because the CMD maintains the global MN's mobility 960 session formed during the MN's roaming within the domain, and the 961 serving MAAR needs to know which previous MAARs were visited, the 962 prefix(es) they assigned and the tunnels established with them. 963 Conversely, a previous MAAR only needs to know which is the current 964 Serving MAAR and establish a single tunnel with it. For this reason, 965 a MAAR that receives a PBU from the CMD (meaning that the MN attached 966 to another MAAR), first sets up the routing state for the MN's 967 prefix(es) it is anchoring, then stop the BCE expiry timer and 968 deletes the MAAR list (if present) since it is no longer useful. 970 In order to have the MN totally unaware of the changes in the access 971 link, all MAARs exhibit the same L2 and L3 identifiers in the access 972 interface (as the PMIPv6 Fixed MAG Link Local Address feature). A 973 solution is under study to avoid this configuration and influence the 974 MN on the source address choice. Moreover, it should be noted that 975 the protocols designed in the document work only at the network layer 976 to handle the MNs joining or leaving the domain. This should 977 guarantee a certain independency to a particular access technology. 978 The implementation reflects this reasoning, but we argue that an 979 interaction with lower layers produces a more effective attachment 980 and detachment detection, therefore improving the performance, also 981 regarding de-registration mechanisms. 983 It was chosen to implement the "proxy" solution because it produces 984 the shortest handover latency, but a slight modification on the CMD 985 state machine can produce the first scenario described ("relay") 986 which guarantees a more consistent request/ack scheme between the 987 MAARS. By modifying also the MAAR's state machine it can be 988 implemented the second solution ("locator"). 990 Authors' Addresses 992 Carlos J. Bernardos 993 Universidad Carlos III de Madrid 994 Av. Universidad, 30 995 Leganes, Madrid 28911 996 Spain 998 Phone: +34 91624 6236 999 Email: cjbc@it.uc3m.es 1000 URI: http://www.it.uc3m.es/cjbc/ 1002 Antonio de la Oliva 1003 Universidad Carlos III de Madrid 1004 Av. Universidad, 30 1005 Leganes, Madrid 28911 1006 Spain 1008 Phone: +34 91624 8803 1009 Email: aoliva@it.uc3m.es 1010 URI: http://www.it.uc3m.es/aoliva/ 1012 Fabio Giust 1013 Institute IMDEA Networks and Universidad Carlos III de Madrid 1014 Av. del Mar Mediterraneo, 22 1015 Leganes, Madrid 28918 1016 Spain 1018 Phone: +34 91481 6979 1019 Email: fabio.giust@imdea.org 1021 Telemaco Melia 1022 Alcatel-Lucent Bell Labs 1023 Route de Villejust 1024 Nozay, Ile de France 91620 1025 France 1027 Email: telemaco.melia@alcatel-lucent.com 1028 Rui Pedro Ferreira da Costa 1029 Alcatel-Lucent Bell Labs 1030 Route de Villejust 1031 Nozay, Ile de France 91620 1032 France 1034 Email: rui_pedro.ferreira_da_costa@alcatel-lucent.com