idnits 2.17.1 draft-ietf-dmm-pmipv6-dlif-04.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 29, 2019) is 1907 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-15 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: Experimental UC3M 5 Expires: August 2, 2019 F. Giust 6 Athonet 7 JC. Zuniga 8 SIGFOX 9 A. Mourad 10 InterDigital 11 January 29, 2019 13 Proxy Mobile IPv6 extensions for Distributed Mobility Management 14 draft-ietf-dmm-pmipv6-dlif-04 16 Abstract 18 Distributed Mobility Management solutions allow for setting up 19 networks so that traffic is distributed in an optimal way and does 20 not rely on centrally deployed anchors to provide IP mobility 21 support. 23 There are many different approaches to address Distributed Mobility 24 Management, as for example extending network-based mobility protocols 25 (like Proxy Mobile IPv6), or client-based mobility protocols (like 26 Mobile IPv6), among others. This document follows the former 27 approach and proposes a solution based on Proxy Mobile IPv6 in which 28 mobility sessions are anchored at the last IP hop router (called 29 mobility anchor and access router). The mobility anchor and access 30 router is an enhanced access router which is also able to operate as 31 a local mobility anchor or mobility access gateway, on a per prefix 32 basis. The document focuses on the required extensions to 33 effectively support simultaneously anchoring several flows at 34 different distributed gateways. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 2, 2019. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 79 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 80 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 81 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11 82 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12 83 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13 84 3.6. The Distributed Logical Interface (DLIF) concept . . . . 13 85 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 17 86 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 17 87 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 18 88 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19 89 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 20 90 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 21 91 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 22 92 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 23 93 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 24 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 99 8.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Appendix A. Comparison with Requirement document . . . . . . . . 26 101 A.1. Distributed mobility management . . . . . . . . . . . . . 27 102 A.2. Bypassable network-layer mobility support for each 103 application session . . . . . . . . . . . . . . . . . . . 27 104 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 27 105 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 28 106 A.5. Coexistence with deployed networks/hosts and operability 107 across different networks . . . . . . . . . . . . . . . . 28 108 A.6. Operation and management considerations . . . . . . . . . 28 109 A.7. Security considerations . . . . . . . . . . . . . . . . . 28 110 A.8. Multicast considerations . . . . . . . . . . . . . . . . 29 111 Appendix B. Implementation experience . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 114 1. Introduction 116 The Distributed Mobility Management (DMM) paradigm aims at minimizing 117 the impact of currently standardized mobility management solutions 118 which are centralized (at least to a considerable extent). 120 Current IP mobility solutions, standardized with the names of Mobile 121 IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite 122 the two most relevant examples, offer mobility support at the cost of 123 handling operations at a cardinal point, the mobility anchor (i.e., 124 the home agent for Mobile IPv6, and the local mobility anchor for 125 Proxy Mobile IPv6), and burdening it with data forwarding and control 126 mechanisms for a great amount of users. As stated in [RFC7333], 127 centralized mobility solutions are prone to several problems and 128 limitations: longer (sub-optimal) routing paths, scalability 129 problems, signaling overhead (and most likely a longer associated 130 handover latency), more complex network deployment, higher 131 vulnerability due to the existence of a potential single point of 132 failure, and lack of granularity of the mobility management service 133 (i.e., mobility is offered on a per-node basis, not being possible to 134 define finer granularity policies, as for example per-application). 136 The purpose of Distributed Mobility Management is to overcome the 137 limitations of the traditional centralized mobility management 138 [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed 139 bringing the mobility anchor closer to the Mobile Node (MN). 140 Following this idea, in our proposal, the central anchor is moved to 141 the edge of the network, being deployed in the default gateway of the 142 mobile node. That is, the first elements that provide IP 143 connectivity to a set of MNs are also the mobility managers for those 144 MNs. In this document, we call these entities Mobility Anchors and 145 Access Routers (MAARs). 147 This document focuses on network-based DMM, hence the starting point 148 is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is 149 handled by the network without the MNs involvement, but, differently 150 from PMIPv6, when the MN moves from one access network to another, it 151 may also change anchor router, hence requiring signaling between the 152 anchors to retrieve the MN's previous location(s). Also, a key- 153 aspect of network-based DMM, is that a prefix pool belongs 154 exclusively to each MAAR, in the sense that those prefixes are 155 assigned by the MAAR to the MNs attached to it, and they are routable 156 at that MAAR. 158 We consider partially distributed schemes, where the data plane only 159 is distributed among access routers similar to MAGs, whereas the 160 control plane is kept centralized towards a cardinal node used as 161 information store, but relieved from any route management and MN's 162 data forwarding task. 164 2. Terminology 166 The following terms used in this document are defined in the Proxy 167 Mobile IPv6 specification [RFC5213]: 169 Local Mobility Anchor (LMA) 171 Mobile Access Gateway (MAG) 173 Mobile Node (MN) 175 Binding Cache Entry (BCE) 177 Proxy Care-of Address (P-CoA) 179 Proxy Binding Update (PBU) 181 Proxy Binding Acknowledgement (PBA) 183 The following terms used in this document are defined in the DMM 184 Deployment Models and Architectural Considerations document 185 [I-D.ietf-dmm-deployment-models]: 187 Home Control-Plane Anchor (Home-CPA) 189 Home Data Plane Anchor (Home-DPA) 191 Access Control Plane Node (Access-CPN) 192 Access Data Plane Node (Access-DPN) 194 The following terms are defined and used in this document: 196 MAAR (Mobility Anchor and Access Router). First hop router where the 197 mobile nodes attach to. It also plays the role of mobility 198 manager for the IPv6 prefixes it anchors, running the 199 functionalities of PMIP's MAG and LMA. Depending on the prefix, 200 it plays the role of Access-DPN, Home-DPA and Access-CPN. 202 CMD (Central Mobility Database). The node that stores the BCEs 203 allocated for the MNs in the mobility domain. It plays the role 204 of Home-CPA. 206 P-MAAR (Previous MAAR). When a MN moves to a new point of attachment 207 a new MAAR might be allocated as its anchor point for future IPv6 208 prefixes. The MAAR that served the MN prior to new attachment 209 becomes the P-MAAR. It is still the anchor point for the IPv6 210 prefixes it had allocated to the MN in the past and serves as the 211 Home-DPA for flows using these prefixes. There might be several 212 P-MAARs serving a MN when the MN is frequently switching points of 213 attachment while maintaining long-lasting flows. 215 S-MAAR (Serving MAAR). The MAAR which the MN is currently attached 216 to. Depending on the prefix, it plays the role of Access-DPN, 217 Home-DPA and Access-CPN. 219 DLIF (Distributed Logical Interface). It is a logical interface at 220 the IP stack of the MAAR. For each active prefix used by the MN, 221 the S-MAAR has a DLIF configured (associated to each MAAR still 222 anchoring flows). In this way, an S-MAAR exposes itself towards 223 each MN as multiple routers, one as itself and one per P-MAAR. 225 3. PMIPv6 DMM extensions 227 The solution consists of de-coupling the entities that participate in 228 the data and the control planes: the data plane becomes distributed 229 and managed by the MAARs near the edge of the network, while the 230 control plane, besides those on the MAARs, relies on a central entity 231 called Central Mobility Database (CMD). In the proposed 232 architecture, the hierarchy present in PMIPv6 between LMA and MAG is 233 preserved, but with the following substantial variations: 235 o The LMA is relieved from the data forwarding role, only the 236 Binding Cache and its management operations are maintained. Hence 237 the LMA is renamed into Central Mobility Database (CMD), which is 238 therefore a Home-CPA. Also, the CMD is able to send and parse 239 both PBU and PBA messages. 241 o The MAG is enriched with the LMA functionalities, hence the name 242 Mobility Anchor and Access Router (MAAR). It maintains a local 243 Binding Cache for the MNs that are attached to it and it is able 244 to send and parse PBU and PBA messages. 246 o The binding cache will be extended to include information 247 regarding P-MAARs where the mobile node was anchored and still 248 retains active data sessions, see Appendix B for further details. 250 o Each MAAR has a unique set of global prefixes (which are 251 configurable), that can be allocated by the MAAR to the MNs, but 252 must be exclusive to that MAAR, i.e. no other MAAR can allocate 253 the same prefixes. 255 The MAARs leverage the Central Mobility Database (CMD) to access and 256 update information related to the MNs, stored as mobility sessions; 257 hence, a centralized node maintains a global view of the network 258 status. The CMD is queried whenever a MN is detected to join/leave 259 the mobility domain. It might be a fresh attachment, a detachment or 260 a handover, but as MAARs are not aware of past information related to 261 a mobility session, they contact the CMD to retrieve the data of 262 interest and eventually take the appropriate action. The procedure 263 adopted for the query and the messages exchange sequence might vary 264 to optimize the update latency and/or the signaling overhead. Here 265 is presented one method for the initial registration, and three 266 different approaches for updating the mobility sessions using PBUs 267 and PBAs. Each approach assigns a different role to the CMD: 269 o The CMD is a PBU/PBA relay; 271 o The CMD is only a MAAR locator; 273 o The CMD is a PBU/PBA proxy. 275 This solution can be categorized under Model-1: Split Home Anchor 276 Mode in [I-D.ietf-dmm-deployment-models]. As another note, the 277 solution described in this document allows performing per-prefix 278 anchoring decisions, to support e.g., some flows to be anchored at a 279 central Home-DPA (like a traditional LMA) or to enable an application 280 to switch to the locally anchored prefix to gain route optimization, 281 as indicated in [I-D.ietf-dmm-ondemand-mobility]. This type of per- 282 prefix treatment would potentially require additional extensions to 283 the MAARs and signaling between the MAARs and the MNs to convey the 284 per-flow anchor preference (central, distributed), which are not 285 covered in this document. 287 Note that a MN MAY move across different MAARs, which might result in 288 several P-MAARs existing at a given moment of time, each of them 289 anchoring a different prefix used by the MN. 291 3.1. Initial registration 293 Initial registration is performed when an MN attaches to a network 294 for the first time (rather than attaching to a new network after 295 moving from a previous one). 297 In this description (shown in Figure 1), it is assumed that: 299 1. The MN is attaching to MAAR1. 301 2. The MN is authorized to attach to the network. 303 Upon MN attachment, the following operations take place: 305 1. MAAR1 assigns an IPv6 global prefix from its own prefix pool to 306 the MN (Pref1). It also stores this prefix (Pref1) in the 307 locally allocated temporary Binding Cache Entry (BCE). 309 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the 310 CMD. 312 3. Since this is an initial registration, the CMD stores a permanent 313 BCE containing as primary fields the MN-ID, Pref1 and MAAR1's 314 address as a Proxy-CoA. 316 4. The CMD replies with a PBA with the usual options defined in 317 PMIPv6 [RFC5213], meaning that the MN's registration is fresh and 318 no past status is available. 320 5. MAAR1 stores the BCE described in (1) and unicasts a Router 321 Advertisement (RA) to the MN with Pref1. 323 6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with 324 stateless auto-configuration, SLAAC). 326 Note that: 328 1. Alternative IPv6 auto-configuration mechanisms can also be used, 329 though this document describes the SLAAC-based one. 331 2. IP1 is routable at MAAR1, in the sense that it is on the path of 332 packets addressed to the MN. 334 3. MAAR1 acts as a plain router for packets destined to the MN, as 335 no encapsulation nor special handling takes place. 337 In the diagram shown in Figure 1 (and subsequent diagrams), the flow 338 of packets is presented using '*'. 340 +-----+ +---+ +--+ 341 |MAAR1| |CMD| |CN| 342 +-----+ +---+ +*-+ 343 | | * 344 MN | * +---+ 345 attach. | ***** _|CMD|_ 346 detection | flow1 * / +-+-+ \ 347 | | * / | \ 348 local BCE | * / | \ 349 allocation | * / | \ 350 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 351 | BCE | * | | | | | 352 | creation |MAAR1+------+MAAR2+-----+MAAR3| 353 |<-- PBA ---| | * | | | | | 354 local BCE | +---*-+ +-----+ +-----+ 355 finalized | * 356 | | Pref1 * 357 | | +*-+ 358 | | |MN| 359 | | +--+ 361 Operations sequence Packets flow 363 Figure 1: First attachment to the network 365 Note that the registration process does not change regardless of the 366 CMD's modes (relay, locator or proxy) described next. The procedure 367 is depicted in Figure 1. 369 3.2. The CMD as PBU/PBA relay 371 Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following 372 operations take place: 374 1. When the MN moves from its current point of attachment and 375 attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 376 prefix (Pref2), it stores a temporary BCE, and it sends a plain 377 PBU to the CMD for registration. 379 2. Upon PBU reception and BC lookup, the CMD retrieves an already 380 existing entry for the MN, binding the MN-ID to its former 381 location; thus, the CMD forwards the PBU to the MAAR indicated as 382 Proxy CoA (MAAR1), including a new mobility option to communicate 383 the S-MAAR's global address to MAAR1, defined as Serving MAAR 384 Option in Section 4.6. The CMD updates the P-CoA field in the 385 BCE related to the MN with the S-MAAR's address. 387 3. Upon PBU reception, MAAR1 can install a tunnel on its side 388 towards MAAR2 and the related routes for Pref1. Then MAAR1 389 replies to the CMD with a PBA (including the option mentioned 390 before) to ensure that the new location has successfully changed, 391 containing the prefix anchored at MAAR1 in the Home Network 392 Prefix option. 394 4. The CMD, after receiving the PBA, updates the BCE populating an 395 instance of the P-MAAR list. The P-MAAR list is an additional 396 field on the BCE that contains an element for each P-MAAR 397 involved in the MN's mobility session. The list element contains 398 the P-MAAR's global address and the prefix it has delegated (see 399 Appendix B for further details). Also, the CMD sends a PBA to 400 the new S-MAAR, containing the previous Proxy-CoA and the prefix 401 anchored to it embedded into a new mobility option called 402 Previous MAAR Option (defined in Section 4.5), so that, upon PBA 403 arrival, a bi-directional tunnel can be established between the 404 two MAARs and new routes are set appropriately to recover the IP 405 flow(s) carrying Pref1. 407 5. Now packets destined to Pref1 are first received by MAAR1, 408 encapsulated into the tunnel and forwarded to MAAR2, which 409 finally delivers them to their destination. In uplink, when the 410 MN transmits packets using Pref1 as source address, they are sent 411 to MAAR2, as it is MN's new default gateway, then tunneled to 412 MAAR1 which routes them towards the next hop to destination. 413 Conversely, packets carrying Pref2 are routed by MAAR2 without 414 any special packet handling both for uplink and downlink. 416 +-----+ +---+ +-----+ +--+ +--+ 417 |MAAR1| |CMD| |MAAR2| |CN| |CN| 418 +-----+ +---+ +-----+ +*-+ +*-+ 419 | | | * * 420 | | MN * +---+ * 421 | | attach. ***** _|CMD|_ * 422 | | det. flow1 * / +-+-+ \ *flow2 423 | |<-- PBU ---| * / | \ * 424 | BCE | * / | ******* 425 | check+ | * / | * \ 426 | update | +---*-+-' +--+-*+ `+-----+ 427 |<-- PBU*---| | | * | | *| | | 428 route | | |MAAR1|______|MAAR2+-----+MAAR3| 429 update | | | **(______)** *| | | 430 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 431 | BCE | * * 432 | update | Pref1 * *Pref2 433 | |--- PBA*-->| +*--*+ 434 | | route ---move-->|*MN*| 435 | | update +----+ 437 Operations sequence Data Packets flow 438 PBU/PBA Messages with * contain 439 a new mobility option 441 Figure 2: Scenario after a handover, CMD as relay 443 For MN's next movements the process is repeated except the number of 444 P-MAARs involved increases (accordingly to the number of prefixes 445 that the MN wishes to maintain). Indeed, once the CMD receives the 446 first PBU from the new S-MAAR, it forwards copies of the PBU to all 447 the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 448 prior to handover) and in the P-MAARs list. They reply with a PBA to 449 the CMD, which aggregates them into a single one to notify the 450 S-MAAR, that finally can establish the tunnels with the P-MAARs. 452 It should be noted that this design separates the mobility management 453 at the prefix granularity, and it can be tuned in order to erase old 454 mobility sessions when not required, while the MN is reachable 455 through the latest prefix acquired. Moreover, the latency associated 456 to the mobility update is bound to the PBA sent by the furthest 457 P-MAAR, in terms of RTT, that takes the longest time to reach the 458 CMD. The drawback can be mitigated introducing a timeout at the CMD, 459 by which, after its expiration, all the PBAs so far collected are 460 transmitted, and the remaining are sent later upon their arrival. 462 3.3. The CMD as MAAR locator 464 The handover latency experienced in the approach shown before can be 465 reduced if the P-MAARs are allowed to signal directly their 466 information to the new S-MAAR. This procedure reflects what was 467 described in Section 3.2 up to the moment the P-MAAR receives the PBU 468 with the P-MAAR option. At that point a P-MAAR is aware of the new 469 MN's location (because of the S-MAAR's address in the S-MAAR option), 470 and, besides sending a PBA to the CMD, it also sends a PBA to the 471 S-MAAR including the prefix it is anchoring. This latter PBA does 472 not need to include new options, as the prefix is embedded in the HNP 473 option and the P-MAAR's address is taken from the message's source 474 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 475 as the latter receives a copy directly from the P-MAAR with the 476 necessary information to build the tunnels and set the appropriate 477 routes. Figure 3 illustrates the new message sequence, while the 478 data forwarding is unaltered. 480 +-----+ +---+ +-----+ +--+ +--+ 481 |MAAR1| |CMD| |MAAR2| |CN| |CN| 482 +-----+ +---+ +-----+ +*-+ +*-+ 483 | | | * * 484 | | MN * +---+ * 485 | | attach. ***** _|CMD|_ * 486 | | det. flow1 * / +-+-+ \ *flow2 487 | |<-- PBU ---| * / | \ * 488 | BCE | * / | ******* 489 | check+ | * / | * \ 490 | update | +---*-+-' +--+-*+ `+-----+ 491 |<-- PBU*---| | | * | | *| | | 492 route | | |MAAR1|______|MAAR2+-----+MAAR3| 493 update | | | **(______)** *| | | 494 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 495 |--- PBA*-->| route * * 496 | BCE update Pref1 * *Pref2 497 | update | +*--*+ 498 | | | ---move-->|*MN*| 499 | | | +----+ 501 Operations sequence Data Packets flow 502 PBU/PBA Messages with * contain 503 a new mobility option 505 Figure 3: Scenario after a handover, CMD as locator 507 3.4. The CMD as MAAR proxy 509 A further enhancement of previous solutions can be achieved when the 510 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 511 the location change. Indeed, when the CMD receives the PBU for the 512 new registration, it is already in possession of all the information 513 that the new S-MAAR requires to set up the tunnels and the routes. 514 Thus the PBA is sent to the S-MAAR immediately after a PBU is 515 received, including also in this case the P-MAAR option. In 516 parallel, a PBU is sent by the CMD to the P-MAARs containing the 517 S-MAAR option, to notify them about the new MN's location, so they 518 receive the information to establish the tunnels and routes on their 519 side. When P-MAARs complete the update, they send a PBA to the CMD 520 to indicate that the operation is concluded and the information are 521 updated in all network nodes. This procedure is obtained from the 522 first one re-arranging the order of the messages, but the parameters 523 communicated are the same. This scheme is depicted in Figure 4, 524 where, again, the data forwarding is kept untouched. 526 +-----+ +---+ +-----+ +--+ +--+ 527 |MAAR1| |CMD| |MAAR2| |CN| |CN| 528 +-----+ +---+ +-----+ +*-+ +*-+ 529 | | | * * 530 | | MN * +---+ * 531 | | attach. ***** _|CMD|_ * 532 | | det. flow1 * / +-+-+ \ *flow2 533 | |<-- PBU ---| * / | \ * 534 | BCE | * / | ******* 535 | check+ | * / | * \ 536 | update | +---*-+-' +--+-*+ `+-----+ 537 |<-- PBU*---x--- PBA*-->| | * | | *| | | 538 route | route |MAAR1|______|MAAR2+-----+MAAR3| 539 update | update | **(______)** *| | | 540 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 541 | BCE | * * 542 | update | Pref1 * *Pref2 543 | | | +*--*+ 544 | | | ---move-->|*MN*| 545 | | | +----+ 547 Operations sequence Data Packets flow 548 PBU/PBA Messages with * contain 549 a new mobility option 551 Figure 4: Scenario after a handover, CMD as proxy 553 3.5. De-registration 555 The de-registration mechanism devised for PMIPv6 cannot be used as is 556 in this solution. The reason for this is that each MAAR handles an 557 independent mobility session (i.e., a single or a set of prefixes) 558 for a given MN, whereas the aggregated session is stored at the CMD. 559 Indeed, when a previous MAAR initiates a de-registration procedure, 560 because the MN is no longer present on the MAAR's access link, it 561 removes the routing state for that (those) prefix(es), that would be 562 deleted by the CMD as well, hence defeating any prefix continuity 563 attempt. The simplest approach to overcome this limitation is to 564 deny a P-MAAR to de-register a prefix, that is, allowing only a 565 serving MAAR to de-register the whole MN session. This can be 566 achieved by first removing any layer-2 detachment event, so that de- 567 registration is triggered only when the session lifetime expires, 568 hence providing a guard interval for the MN to connect to a new MAAR. 569 Then, a change in the MAAR operations is required, and at this stage 570 two possible solutions can be deployed: 572 o A previous MAAR stops the BCE timer upon receiving a PBU from the 573 CMD containing a "Serving MAAR" option. In this way only the 574 Serving MAAR is allowed to de-register the mobility session, 575 arguing that the MN definitely left the domain. 577 o Previous MAARs can, upon BCE expiry, send de-registration messages 578 to the CMD, which, instead of acknowledging the message with a 0 579 lifetime, sends back a PBA with a non-zero lifetime, hence re- 580 newing the session, if the MN is still connected to the domain. 582 3.6. The Distributed Logical Interface (DLIF) concept 584 One of the main challenges of a network-based DMM solution is how to 585 allow a mobile node to simultaneously send/receive traffic which is 586 anchored at different MAARs, and how to influence on the mobile 587 node's selection process of its source IPv6 address for a new flow, 588 without requiring special support from the mobile node's IP stack. 589 This document defines the Distributed Logical Interface (DLIF), which 590 is a software construct that allows to easily hide the change of 591 associated anchors from the mobile node. 593 +---------------------------------------------------+ 594 ( Operator's ) 595 ( core ) 596 +---------------------------------------------------+ 597 | | 598 +---------------+ tunnel +---------------+ 599 | IP stack |===============| IP stack | 600 +---------------+ +-------+-------+ 601 | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ 602 +---------------+ | | +-------+-------+ | 603 | phy interface | | | | phy interface | | 604 +---------------+ | | +---------------+ | 605 MAAR1 (o) (o) MAAR2 (o) 606 x x 607 x x 608 prefA::/64 x x prefB::/64 609 (AdvPrefLft=0) x x 610 (o) 611 | 612 +-----+ 613 prefA::MN1 | MN1 | prefB::MN1 614 (deprecated) +-----+ 616 Figure 5: DLIF: exposing multiple routers (one per P-MAAR) 618 The basic idea of the DLIF concept is the following: each serving 619 MAAR exposes itself towards a given MN as multiple routers, one per 620 P-MAAR associated to the MN. Let's consider the example shown in 621 Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 622 address (prefA::MN1) from a prefix locally anchored at MAAR1 623 (prefA::/64). At this stage, MAAR1 plays both the role of anchoring 624 and serving MAAR, and also behaves as a plain IPv6 access router. 625 MAAR1 creates a distributed logical interface to communicate (point- 626 to-point link) with MN1, exposing itself as a (logical) router with a 627 specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., 628 prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF 629 mn1mar1. As explained below, these addresses represent the "logical" 630 identity of MAAR1 towards MN1, and will "follow" the mobile node 631 while roaming within the domain (note that the place where all this 632 information is maintained and updated is out-of-scope of this draft; 633 potential examples are to keep it on the home subscriber server -- 634 HSS -- or the user's profile). 636 If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in 637 the example of Figure 5), this MAAR will create a new logical 638 interface (mn1mar2) to expose itself towards MN1, providing it with a 639 locally anchored prefix (prefB::/64). In this case, since the MN1 640 has another active IPv6 address anchored at a MAAR1, MAAR2 also needs 641 to create an additional logical interface configured to exactly 642 resemble the one used by MAAR1 to communicate with MN1. In this 643 example, there is only one P-MAAR (in addition to MAAR2, which is the 644 serving one): MAAR1, so only the logical interface mn1mar1 is 645 created, but the same process would be repeated in case there were 646 more P-MAARs involved. In order to maintain the prefix anchored at 647 MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and 648 the routing is modified accordingly. The PBU/PBA signaling is used 649 to set-up the bi-directional tunnel between MAAR1 and MAAR2, and it 650 might also be used to convey to MAAR2 the information about the 651 prefix(es) anchored at MAAR1 and about the addresses of the 652 associated DLIF (i.e., mn1mar1). 654 +------------------------------------------+ +----------------------+ 655 | MAAR1 | | MAAR2 | 656 |+----------------------------------------+| |+--------------------+| 657 ||+------------------++------------------+|| ||+------------------+|| 658 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 659 ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| 660 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 661 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 662 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 663 ||+------------------++------------------+|| ||+------------------+|| 664 || HMAC1 (phy if MAAR1) || ||HMAC2 (phy if MAAR2)|| 665 |+----------------------------------------+| |+--------------------+| 666 +------------------------------------------+ +----------------------+ 667 x x x 668 x x x 669 (o) (o) (o) 670 | | | 671 +--+--+ +--+--+ +--+--+ 672 | MN3 | | MN2 | | MN1 | 673 +-----+ +-----+ +-----+ 675 Figure 6: Distributed Logical Interface concept 677 Figure 6 shows the logical interface concept in more detail. The 678 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 679 and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two 680 P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the 681 role of anchoring MAAR for the attached (served) MNs. Each MAAR has 682 one single physical wireless interface. 684 As introduced before, each MN always "sees" multiple logical routers 685 -- one per P-MAAR -- independently of its currently serving MAAR. 686 From the point of view of the MN, these MAARs are portrayed as 687 different routers, although the MN is physically attached to one 688 single interface. The way this is achieved is by the serving MAAR 689 configuring different logical interfaces. Focusing on MN1, it is 690 currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and, 691 therefore, it has configured an IPv6 address from MAAR2's pool (e.g., 692 prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top 693 of its wireless physical interface (phy if MAAR2) which is used to 694 serve MN1. This interface has a logical MAC address (LMAC6), 695 different from the hardware MAC address (HMAC2) of the physical 696 interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its 697 locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 698 was attached to MAAR1, configuring also an address locally anchored 699 at that MAAR, which is still being used by MN1 in active 700 communications. MN1 keeps "seeing" an interface connecting to MAAR1, 701 as if it were directly connected to the two MAARs. This is achieved 702 by the serving MAAR (MAAR2) configuring an additional distributed 703 logical interface: mn1mar1, which behaves exactly as the logical 704 interface configured by MAAR1 when MN1 was attached to it. This 705 means that both the MAC and IPv6 addresses configured on this logical 706 interface remain the same regardless of the physical MAAR which is 707 serving the MN. The information required by a serving MAAR to 708 properly configure this logical interfaces can be obtained in 709 different ways: as part of the information conveyed in the PBA, from 710 an external database (e.g., the HSS) or by other means. As shown in 711 the figure, each MAAR may have several logical interfaces associated 712 to each attached MN, having always at least one (since a serving MAAR 713 is also an anchoring MAAR for the attached MN). 715 In order to enforce the use of the prefix locally anchored at the 716 serving MAAR, the router advertisements sent over those logical 717 interfaces playing the role of anchoring MAARs (different from the 718 serving one) include a zero preferred prefix lifetime (and a non-zero 719 valid prefix lifetime, so the prefix remains valid, while being 720 deprecated). The goal is to deprecate the prefixes delegated by 721 these MAARs (which will be no longer serving the MN). Note that on- 722 going communications may keep on using those addresses, even if they 723 are deprecated, so this only affects the establishment of new 724 sessions. 726 The distributed logical interface concept also enables the following 727 use case: suppose that access to a local IP network is provided by a 728 given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that 729 the resources available at that network cannot be reached from 730 outside the local network (e.g., cannot be accessed by an MN attached 731 to MAAR2). This is similar to the local IP access scenario 732 considered by 3GPP, where a local gateway node is selected for 733 sessions requiring access to services provided locally (instead of 734 going through a central gateway). The goal is to allow an MN to be 735 able to roam while still being able to have connectivity to this 736 local IP network. The solution adopted to support this case makes 737 use of RFC 4191 [RFC4191] more specific routes when the MN moves to a 738 MAAR different from the one providing access to the local IP network 739 (MAAR1 in the example). These routes are advertised through the 740 distributed logical interface representing the MAAR providing access 741 to the local network (MAAR1 in this example). In this way, if MN1 742 moves from MAAR1 to MAAR2, any active session that MN1 may have with 743 a node on the local network connected to MAAR1 will survive via the 744 tunnel between MAAR1 and MAAR2. Also, any potential future 745 connection attempt towards the local network will be supported, even 746 though MN1 is no longer attached to MAAR1. 748 4. Message Format 750 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 751 protocol messages. 753 4.1. Proxy Binding Update 755 A new flag (D) is included in the Proxy Binding Update to indicate 756 that the Proxy Binding Update is coming from a Mobility Anchor and 757 Access Router and not from a mobile access gateway. The rest of the 758 Proxy Binding Update format remains the same as defined in [RFC5213]. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Sequence # | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |A|H|L|K|M|R|P|F|T|B|S|D| Reser | Lifetime | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | | 768 . . 769 . Mobility options . 770 . . 772 | | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 MAAR Flag (D) 777 The D Flag is set to indicate to the receiver of the message that 778 the Proxy Binding Update is from a MAAR. When an LMA that does 779 not support the extensions described in this document receives a 780 message with the D-Flag set, the PBU in that case MUST NOT be 781 processed by the LMA and an error MUST be returned. 783 Mobility Options 784 Variable-length field of such length that the complete Mobility 785 Header is an integer multiple of 8 octets long. This field 786 contains zero or more TLV-encoded mobility options. The encoding 787 and format of defined options are described in Section 6.2 of 788 [RFC6275]. The MAAR MUST ignore and skip any options that it does 789 not understand. 791 4.2. Proxy Binding Acknowledgment 793 A new flag (D) is included in the Proxy Binding Acknowledgment to 794 indicate that the sender supports operating as a Mobility Anchor and 795 Access Router. The rest of the Proxy Binding Acknowledgment format 796 remains the same as defined in [RFC5213]. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Status |K|R|P|T|B|S|D| | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Sequence # | Lifetime | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | | 806 . . 807 . Mobility options . 808 . . 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 MAAR (D) 814 The D is set to indicate that the sender of the message supports 815 operating as a Mobility Anchor and Access Router. When a MAG that 816 does not support the extensions described in this document 817 receives a message with the D-Flag set, it MUST ignore the message 818 and an error MUST be returned. 820 Mobility Options 822 Variable-length field of such length that the complete Mobility 823 Header is an integer multiple of 8 octets long. This field 824 contains zero or more TLV-encoded mobility options. The encoding 825 and format of defined options are described in Section 6.2 of 826 [RFC6275]. The MAAR MUST ignore and skip any options that it does 827 not understand. 829 4.3. Anchored Prefix Option 831 A new Anchored Prefix option is defined for use with the Proxy 832 Binding Update and Proxy Binding Acknowledgment messages exchanged 833 between MAARs and CMDs. Therefore, this option can only appear if 834 the D bit is set in a PBU/PBA. This option is used for exchanging 835 the mobile node's prefix anchored at the anchoring MAAR. There can 836 be multiple Anchored Prefix options present in the message. 838 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 839 format is as follows: 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Length | Reserved | Prefix Length | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 + + 848 | | 849 + Anchored Prefix + 850 | | 851 + + 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Type 857 IANA-1. 859 Length 861 8-bit unsigned integer indicating the length of the option in 862 octets, excluding the type and length fields. This field MUST be 863 set to 18. 865 Reserved 867 This field is unused for now. The value MUST be initialized to 0 868 by the sender and MUST be ignored by the receiver. 870 Prefix Length 872 8-bit unsigned integer indicating the prefix length of the IPv6 873 prefix contained in the option. 875 Anchored Prefix 876 A sixteen-byte field containing the mobile node's IPv6 Anchored 877 Prefix. Only the first Prefix Length bytes are valid for the 878 Anchored Prefix. The rest of the bytes MUST be ignored. 880 4.4. Local Prefix Option 882 A new Local Prefix option is defined for use with the Proxy Binding 883 Update and Proxy Binding Acknowledgment messages exchanged between 884 MAARs. Therefore, this option can only appear if the D bit is set in 885 a PBU/PBA. This option is used for exchanging a prefix of a local 886 network that is only reachable via the anchoring MAAR. There can be 887 multiple Local Prefix options present in the message. 889 The Local Prefix Option has an alignment requirement of 8n+4. Its 890 format is as follows: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Type | Length | Reserved | Prefix Length | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 + + 899 | | 900 + Local Prefix + 901 | | 902 + + 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Type 908 IANA-2. 910 Length 912 8-bit unsigned integer indicating the length of the option in 913 octets, excluding the type and length fields. This field MUST be 914 set to 18. 916 Reserved 918 This field is unused for now. The value MUST be initialized to 0 919 by the sender and MUST be ignored by the receiver. 921 Prefix Length 922 8-bit unsigned integer indicating the prefix length of the IPv6 923 prefix contained in the option. 925 Local Prefix 927 A sixteen-byte field containing the IPv6 Local Prefix. Only the 928 first Prefix Length bytes are valid for the IPv6 Local Prefix. 929 The rest of the bytes MUST be ignored. 931 4.5. Previous MAAR Option 933 This new option is defined for use with the Proxy Binding 934 Acknowledgement messages exchanged by the CMD to a MAAR. This option 935 is used to notify the S-MAAR about the previous MAAR's global address 936 and the prefix anchored to it. There can be multiple Previous MAAR 937 options present in the message. Its format is as follows: 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Type | Length | Prefix Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 + + 946 | | 947 + P-MAAR's address + 948 | | 949 + + 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | | 953 + + 954 | | 955 + Home Network Prefix + 956 | | 957 + + 958 | | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Type 963 IANA-3. 965 Length 967 8-bit unsigned integer indicating the length of the option in 968 octets, excluding the type and length fields. This field MUST be 969 set to 33. 971 Prefix Length 973 8-bit unsigned integer indicating the prefix length of the IPv6 974 prefix contained in the option. 976 Previous MAAR's address 978 A sixteen-byte field containing the P-MAAR's IPv6 global address. 980 Home Network Prefix 982 A sixteen-byte field containing the mobile node's IPv6 Home 983 Network Prefix. Only the first Prefix Length bytes are valid for 984 the mobile node's IPv6 Home Network Prefix. The rest of the bytes 985 MUST be ignored. 987 4.6. Serving MAAR Option 989 This new option is defined for use with the Proxy Binding Update and 990 Proxy Binding Acknowledgement messages exchanged between the CMD and 991 a Previous MAAR. This option is used to notify the P-MAAR about the 992 current Serving MAAR's global address. Its format is as follows: 994 0 1 2 3 995 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 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Type | Length | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | | 1000 + + 1001 | | 1002 + S-MAAR's address + 1003 | | 1004 + + 1005 | | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 Type 1010 IANA-4. 1012 Length 1014 8-bit unsigned integer indicating the length of the option in 1015 octets, excluding the type and length fields. This field MUST be 1016 set to 16. 1018 Serving MAAR's address 1020 A sixteen-byte field containing the S-MAAR's IPv6 global address. 1022 4.7. DLIF Link-local Address Option 1024 A new DLIF Link-local Address option is defined for use with the 1025 Proxy Binding Update and Proxy Binding Acknowledgment messages 1026 exchanged between MAARs. This option is used for exchanging the 1027 link-local address of the DLIF to be configured on the serving MAAR 1028 so it resembles the DLIF configured on the P-MAAR. 1030 The DLIF Link-local Address option has an alignment requirement of 1031 8n+6. Its format is as follows: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Type | Length | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | | 1039 + + 1040 | | 1041 + DLIF Link-local Address + 1042 | | 1043 + + 1044 | | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Type 1049 IANA-5. 1051 Length 1053 8-bit unsigned integer indicating the length of the option in 1054 octets, excluding the type and length fields. This field MUST be 1055 set to 16. 1057 DLIF Link-local Address 1059 A sixteen-byte field containing the link-local address of the 1060 logical interface. 1062 4.8. DLIF Link-layer Address Option 1064 A new DLIF Link-layer Address option is defined for use with the 1065 Proxy Binding Update and Proxy Binding Acknowledgment messages 1066 exchanged between MAARs. This option is used for exchanging the 1067 link-layer address of the DLIF to be configured on the serving MAAR 1068 so it resembles the DLIF configured on the P-MAAR. 1070 The format of the DLIF Link-layer Address option is shown below. 1071 Based on the size of the address, the option MUST be aligned 1072 appropriately, as per mobility option alignment requirements 1073 specified in [RFC6275]. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Type | Length | Reserved | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | | 1081 + DLIF Link-layer Address + 1082 . ... . 1083 | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Type 1088 IANA-6. 1090 Length 1092 8-bit unsigned integer indicating the length of the option in 1093 octets, excluding the type and length fields. 1095 Reserved 1097 This field is unused for now. The value MUST be initialized to 0 1098 by the sender and MUST be ignored by the receiver. 1100 DLIF Link-layer Address 1102 A variable length field containing the link-layer address of the 1103 logical interface to be configured on the S-MAAR. 1105 The content and format of this field (including byte and bit 1106 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 1107 link-layer addresses. On certain access links, where the link- 1108 layer address is not used or cannot be determined, this option 1109 cannot be used. 1111 5. IANA Considerations 1113 This document defines new mobility options that require IANA actions: 1114 IANA-1 to IANA-6. 1116 6. Security Considerations 1118 The protocol extensions defined in this document share the same 1119 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 1120 that the signaling messages, Proxy Binding Update and Proxy Binding 1121 Acknowledgment, exchanged between the MAARs are protected using IPsec 1122 using the established security association between them. This 1123 essentially eliminates the threats related to the impersonation of a 1124 MAAR. 1126 7. Acknowledgments 1128 The authors would like to thank Dirk von Hugo and John Kaippallimalil 1129 for the comments on this document. The authors would also like to 1130 thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, 1131 Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru Matsushima for 1132 their comments and discussion on the documents 1133 [I-D.bernardos-dmm-distributed-anchoring] and 1134 [I-D.bernardos-dmm-pmip] on which the present document is based. 1136 The authors would also like to thank Lyle Bertz and Danny Moses for 1137 their in-deep review of this document and their very valuable 1138 comments and suggestions. 1140 8. References 1142 8.1. Normative References 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, 1146 DOI 10.17487/RFC2119, March 1997, 1147 . 1149 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1150 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1151 November 2005, . 1153 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1154 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1155 DOI 10.17487/RFC4861, September 2007, 1156 . 1158 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1159 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1160 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1161 . 1163 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1164 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1165 2011, . 1167 8.2. Informative References 1169 [I-D.bernardos-dmm-distributed-anchoring] 1170 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 1171 anchoring", draft-bernardos-dmm-distributed-anchoring-09 1172 (work in progress), May 2017. 1174 [I-D.bernardos-dmm-pmip] 1175 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1176 solution for Distributed Mobility Management", draft- 1177 bernardos-dmm-pmip-09 (work in progress), September 2017. 1179 [I-D.ietf-dmm-deployment-models] 1180 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1181 Architectural Considerations", draft-ietf-dmm-deployment- 1182 models-04 (work in progress), May 2018. 1184 [I-D.ietf-dmm-ondemand-mobility] 1185 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 1186 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 1187 ondemand-mobility-15 (work in progress), July 2018. 1189 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1190 Korhonen, "Requirements for Distributed Mobility 1191 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1192 . 1194 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1195 CJ. Bernardos, "Distributed Mobility Management: Current 1196 Practices and Gap Analysis", RFC 7429, 1197 DOI 10.17487/RFC7429, January 2015, 1198 . 1200 Appendix A. Comparison with Requirement document 1202 In this section we describe how our solution addresses the DMM 1203 requirements listed in [RFC7333]. 1205 A.1. Distributed mobility management 1207 "IP mobility, network access solutions, and forwarding solutions 1208 provided by DMM MUST enable traffic to avoid traversing a single 1209 mobility anchor far from the optimal route." 1211 In our solution, a MAAR is responsible to handle the mobility for 1212 those IP flows started when the MN is attached to it. As long as the 1213 MN remains connected to the MAAR's access links, the IP packets of 1214 such flows can benefit from the optimal path. When the MN moves to 1215 another MAAR, the path becomes non-optimal for ongoing flows, as they 1216 are anchored to the previous MAAR, but newly started IP sessions are 1217 forwarded by the new MAAR through the optimal path. 1219 A.2. Bypassable network-layer mobility support for each application 1220 session 1222 "DMM solutions MUST enable network-layer mobility, but it MUST be 1223 possible for any individual active application session (flow) to not 1224 use it. Mobility support is needed, for example, when a mobile host 1225 moves and an application cannot cope with a change in the IP address. 1226 Mobility support is also needed when a mobile router changes its IP 1227 address as it moves together with a host and, in the presence of 1228 ingress filtering, an application in the host is interrupted. 1229 However, mobility support at the network layer is not always needed; 1230 a mobile node can often be stationary, and mobility support can also 1231 be provided at other layers. It is then not always necessary to 1232 maintain a stable IP address or prefix for an active application 1233 session." 1235 Our DMM solution operates at the IP layer, hence upper layers are 1236 totally transparent to the mobility operations. In particular, 1237 ongoing IP sessions are not disrupted after a change of access 1238 network. The routability of the old address is ensured by the IP 1239 tunnel with the old MAAR. New IP sessions are started with the new 1240 address. From the application's perspective, those processes which 1241 sockets are bound to a unique IP address do not suffer any impact. 1242 For the other applications, the sockets bound to the old address are 1243 preserved, whereas next sockets use the new address. 1245 A.3. IPv6 deployment 1247 "DMM solutions SHOULD target IPv6 as the primary deployment 1248 environment and SHOULD NOT be tailored specifically to support IPv4, 1249 particularly in situations where private IPv4 addresses and/or NATs 1250 are used." 1252 The DMM solution we propose targets IPv6 only. 1254 A.4. Existing mobility protocols 1256 "A DMM solution MUST first consider reusing and extending IETF 1257 standard protocols before specifying new protocols." 1259 This DMM solution is derived from the operations and messages 1260 specified in [RFC5213]. 1262 A.5. Coexistence with deployed networks/hosts and operability across 1263 different networks 1265 "A DMM solution may require loose, tight, or no integration into 1266 existing mobility protocols and host IP stacks. Regardless of the 1267 integration level, DMM implementations MUST be able to coexist with 1268 existing network deployments, end hosts, and routers that may or may 1269 not implement existing mobility protocols. Furthermore, a DMM 1270 solution SHOULD work across different networks, possibly operated as 1271 separate administrative domains, when the needed mobility management 1272 signaling, forwarding, and network access are allowed by the trust 1273 relationship between them" 1275 The partially distributed DMM solution (distributed data plane and 1276 centralized control plane) can be extended to provide a fallback 1277 mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to 1278 instruct MAARs to always establish a tunnel with the same MAAR, 1279 working as LMA. The fully distributed DMM solution (distributed data 1280 and control plane) can be extended as well, but it requires more 1281 intervention. The partially distributed DMM solution can be deployed 1282 across different domains with trust agreements if the CMDs of the 1283 operators are enabled to transfer context from one node to another. 1284 The fully distributed DMM solution works across multiple domains if 1285 the same signalling scheme is used in both domains. 1287 A.6. Operation and management considerations 1289 "A DMM solution needs to consider configuring a device, monitoring 1290 the current operational state of a device, and responding to events 1291 that impact the device, possibly by modifying the configuration and 1292 storing the data in a format that can be analyzed later. 1294 The proposed solution can re-use existing mechanisms defined for the 1295 operation and management of Proxy Mobile IPv6. 1297 A.7. Security considerations 1299 "A DMM solution MUST support any security protocols and mechanisms 1300 needed to secure the network and to make continuous security 1301 improvements. In addition, with security taken into consideration 1302 early in the design, a DMM solution MUST NOT introduce new security 1303 risks or amplify existing security risks that cannot be mitigated by 1304 existing security protocols and mechanisms." 1306 The proposed solution does not specify a security mechanism, given 1307 that the same mechanism for PMIPv6 can be used. 1309 A.8. Multicast considerations 1311 "DMM SHOULD enable multicast solutions to be developed to avoid 1312 network inefficiency in multicast traffic delivery." 1314 This solution in its current version does not specify any support for 1315 multicast traffic. 1317 Appendix B. Implementation experience 1319 The network-based DMM solution described in section Section 3.4 is 1320 now available at the Open Distributed Mobility Management (ODMM) 1321 project (http://www.odmm.net/), under the name of Mobility Anchors 1322 Distribution for PMIPv6 (MAD-PMIPv6). The ODMM platform is intended 1323 to foster DMM development and deployment, by serving as a framework 1324 to host open source implementations. 1326 The MAD-PMIPv6 code is developed in ANSI C from the existing UMIP 1327 implementation for PMIP. The most relevant changes with respect to 1328 the UMIP original version are related to how to create the CMD and 1329 MAAR's state machines from those of an LMA and a MAG; for this 1330 purpose, part of the LMA code was copied to the MAG, in order to send 1331 PBA messages and parse PBU. Also, the LMA routing functions were 1332 removed completely, and moved to the MAG, because MAARs need to route 1333 through the tunnels in downlink (as an LMA) and in uplink (as a MAG). 1335 Tunnel management is hence a relevant technical aspect, as multiple 1336 tunnels are established by a single MAAR, which keeps their status 1337 directly into the MN's BCE. Indeed, from the implementation 1338 experience it was chosen to create an ancillary data structure as 1339 field within a BCE: the data structure is called "MAAR list" and 1340 stores the previous MAARs' address and the corresponding prefix(es) 1341 assigned for the MN. Only the CMD and the serving MAAR store this 1342 data structure, because the CMD maintains the global MN's mobility 1343 session formed during the MN's roaming within the domain, and the 1344 serving MAAR needs to know which previous MAARs were visited, the 1345 prefix(es) they assigned and the tunnels established with them. 1346 Conversely, a previous MAAR only needs to know which is the current 1347 Serving MAAR and establish a single tunnel with it. For this reason, 1348 a MAAR that receives a PBU from the CMD (meaning that the MN attached 1349 to another MAAR), first sets up the routing state for the MN's 1350 prefix(es) it is anchoring, then stops the BCE expiry timer and 1351 deletes the MAAR list (if present) since it is no longer useful. 1353 In order to have the MN totally unaware of the changes in the access 1354 link, all MAARs implement the Distributed Logical Interface (DLIF) 1355 concept. Moreover, it should be noted that the protocols designed in 1356 the document work only at the network layer to handle the MNs joining 1357 or leaving the domain. This should guarantee a certain independency 1358 to a particular access technology. The implementation reflects this 1359 reasoning, but we argue that an interaction with lower layers 1360 produces a more effective attachment and detachment detection, 1361 therefore improving the performance, also regarding de-registration 1362 mechanisms. 1364 It was chosen to implement the "proxy" solution because it produces 1365 the shortest handover latency, but a slight modification on the CMD 1366 state machine can produce the first scenario described ("relay") 1367 which guarantees a more consistent request/ack scheme between the 1368 MAARS. By modifying also the MAAR's state machine it can be 1369 implemented the second solution ("locator"). 1371 An early MAD-PMIPv6 implementation was shown during a demo session at 1372 the IETF 83rd, in Paris in March 2012. An enhancement version of the 1373 prototype has been presented at the 87th IETF meeting in Berlin, July 1374 2013. The updated demo included a use case scenario employing a CDN 1375 system for video delivery. More, MAD-PMIPv6 has been extensively 1376 used and evaluated within a testbed employing heterogeneous radio 1377 accesses within the framework of the MEDIEVAL EU project. MAD-PMIPv6 1378 software is currently part of a DMM test-bed comprising 3 MAARs, one 1379 CMD, one MN and a CN. All the machines used in the demos were Linux 1380 UBUNTU 10.04 systems with kernel 2.6.32, but the prototype has been 1381 tested also under newer systems. This testbed was also used by the 1382 iJOIN EU project. 1384 Authors' Addresses 1386 Carlos J. Bernardos 1387 Universidad Carlos III de Madrid 1388 Av. Universidad, 30 1389 Leganes, Madrid 28911 1390 Spain 1392 Phone: +34 91624 6236 1393 Email: cjbc@it.uc3m.es 1394 URI: http://www.it.uc3m.es/cjbc/ 1395 Antonio de la Oliva 1396 Universidad Carlos III de Madrid 1397 Av. Universidad, 30 1398 Leganes, Madrid 28911 1399 Spain 1401 Phone: +34 91624 8803 1402 Email: aoliva@it.uc3m.es 1403 URI: http://www.it.uc3m.es/aoliva/ 1405 Fabio Giust 1406 Athonet S.r.l. 1408 Email: fabio.giust.2011@ieee.org 1410 Juan Carlos Zuniga 1411 SIGFOX 1412 425 rue Jean Rostand 1413 Labege 31670 1414 France 1416 Email: j.c.zuniga@ieee.org 1417 URI: http://www.sigfox.com/ 1419 Alain Mourad 1420 InterDigital Europe 1422 Email: Alain.Mourad@InterDigital.com 1423 URI: http://www.InterDigital.com/