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