idnits 2.17.1 draft-bernardos-dmm-pmipv6-dlif-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2018) is 2241 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 (-04) exists of draft-ietf-dmm-deployment-models-03 == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-13 Summary: 0 errors (**), 0 flaws (~~), 3 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 3, 2018 F. Giust 6 NEC 7 JC. Zuniga 8 SIGFOX 9 A. Mourad 10 InterDigital 11 March 2, 2018 13 Proxy Mobile IPv6 extensions for Distributed Mobility Management 14 draft-bernardos-dmm-pmipv6-dlif-01 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 centralized 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 (as 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 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 This document introduces the concept of distributed logical 37 interface, which is a software construct that allows to easily hide 38 the change of anchor from the mobile node. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 3, 2018. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3. PMIPv6 DMM extenstions . . . . . . . . . . . . . . . . . . . 5 83 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 84 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 85 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 86 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 87 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 88 3.6. The Distributed Logical Interface (DLIF) concept . . . . 12 89 3.7. Message Format . . . . . . . . . . . . . . . . . . . . . 16 90 3.7.1. Proxy Binding Update . . . . . . . . . . . . . . . . 16 91 3.7.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 17 92 3.7.3. Anchored Prefix Option . . . . . . . . . . . . . . . 17 93 3.7.4. Local Prefix Option . . . . . . . . . . . . . . . . . 18 94 3.7.5. Previous MAAR Option . . . . . . . . . . . . . . . . 19 95 3.7.6. Serving MAAR Option . . . . . . . . . . . . . . . . . 21 96 3.7.7. DLIF Link-local Address Option . . . . . . . . . . . 21 97 3.7.8. DLIF Link-layer Address Option . . . . . . . . . . . 22 98 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 100 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 103 7.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. Comparison with Requirement document . . . . . . . . 25 105 A.1. Distributed mobility management . . . . . . . . . . . . . 25 106 A.2. Bypassable network-layer mobility support for each 107 application session . . . . . . . . . . . . . . . . . . . 26 108 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26 109 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26 110 A.5. Coexistence with deployed networks/hosts and operability 111 across different networks . . . . . . . . . . . . . . . . 27 112 A.6. Operation and management considerations . . . . . . . . . 27 113 A.7. Security considerations . . . . . . . . . . . . . . . . . 27 114 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 115 Appendix B. Implementation experience . . . . . . . . . . . . . 28 116 Appendix C. Applicability to the fog environment . . . . . . . . 29 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 119 1. Introduction 121 The Distributed Mobility Management (DMM) paradigm aims at minimizing 122 the impact of currently standardized mobility management solutions, 123 which are centralized (at least to a considerable extent). 125 Current IP mobility solutions, standardized with the names of Mobile 126 IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two 127 most relevant examples, offer mobility support at the cost of 128 handling operations at a cardinal point, the mobility anchor, and 129 burdening it with data forwarding and control mechanisms for a great 130 amount of users. As stated in [RFC7333], centralized mobility 131 solutions are prone to several problems and limitations: longer (sub- 132 optimal) routing paths, scalability problems, signaling overhead (and 133 most likely a longer associated handover latency), more complex 134 network deployment, higher vulnerability due to the existence of a 135 potential single point of failure, and lack of granularity on the 136 mobility management service (i.e., mobility is offered on a per-node 137 basis, not being possible to define finer granularity policies, as 138 for example per-application). 140 The purpose of Distributed Mobility Management is to overcome the 141 limitations of the traditional centralized mobility management 143 [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed 144 bringing the mobility anchor closer to the MN. Following this idea, 145 in our proposal, the central anchor is moved to the edge of the 146 network, being deployed in the default gateway of the mobile node. 147 That is, the first elements that provide IP connectivity to a set of 148 MNs are also the mobility managers for those MNs. In the following, 149 we will call these entities Mobility Anchor and Access Routers 150 (MAARs). 152 This document focuses on network-based DMM, hence the starting point 153 is making PMIPv6 working in a distributed manner [RFC7429]. Mobility 154 is handled by the network without the MNs involvement, but, 155 differently from PMIPv6, when the MN moves from one access network to 156 another, it also changes anchor router, hence requiring signaling 157 between the anchors to retrieve the MN's previous location(s). Also, 158 a key-aspect of network-based DMM, is that a prefix pool belongs 159 exclusively to each MAAR, in the sense that those prefixes are 160 assigned by the MAAR to the MNs attached to it, and they are routable 161 at that MAAR. 163 We consider partially distributed schemes, where the data plane only 164 is distributed among access routers similar to MAGs, whereas the 165 control plane is kept centralized towards a cardinal node used as 166 information store, but relieved from any route management and MN's 167 data forwarding task. 169 2. Terminology 171 The following terms used in this document are defined in the Proxy 172 Mobile IPv6 specification [RFC5213]: 174 Local Mobility Anchor (LMA) 176 Mobile Access Gateway (MAG) 178 Mobile Node (MN) 180 Binding Cache Entry (BCE) 182 Proxy Care-of Address (P-CoA) 184 Proxy Binding Update (PBU) 186 Proxy Binding Acknowledgement (PBA) 188 The following terms used in this document are defined in the DMM 189 Deployment Models and Architectural Considerations document 190 [I-D.ietf-dmm-deployment-models]: 192 Home Control-Plane Anchor (H-CPA) 194 Home Data Plane Anchor (Home-DPA) 196 Access Control Plane Node (Access-CPN) 198 Access Data Plane Node (Access-DPN) 200 The following terms are defined and used in this document: 202 MAAR (Mobility Anchor and Access Router). First hop router where the 203 mobile nodes attach to. It also plays the role of mobility 204 manager for the IPv6 prefixes it anchors, running the 205 functionalities of PMIP's MAG and LMA. Depending on the prefix, 206 it plays the role of Access-DPN, Home-DPA and Access-CPN. 208 CMD (Central Mobility Database). Node that stores the BCEs allocated 209 for the MNs in the mobility domain. It plays the role of Home- 210 CPA. 212 P-MAAR (Previous MAAR). MAAR which was previously visited by the MN 213 and is still involved in an active flow using an IPv6 prefix it 214 has advertised to the MN (i.e., MAAR where that IPv6 prefix is 215 anchored). There might be multiple P-MAARs for an MN's mobility 216 session. It plays the role of Home-DPA. 218 S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. 219 Depending on the prefix, it plays the role of Access-DPN, Home-DPA 220 and Access-CPN. 222 DLIF (Distributed Logical Interface). It is a logical interface at 223 the IP stack of the MAAR. For each active prefix used by the 224 mobile node, the serving MAAR has a DLIF configured (associated to 225 the anchoring MAAR). In this way, a serving MAAR exposes itself 226 towards each MN as multiple routers, one per active anchoring 227 MAAR. 229 3. PMIPv6 DMM extenstions 231 The solution consists in de-coupling the entities that participates 232 in the data and the control planes: the data plane becomes 233 distributed and managed by the MAARs near the edge of the network, 234 while the control plane, besides on the MAARs, relies on a central 235 entity called Central Mobility Database (CMD). In the proposed 236 architecture, the hierarchy present in PMIPv6 between LMA and MAG is 237 preserved, but with the following substantial variations: 239 o The LMA is relieved from the data forwarding role, only the 240 Binding Cache and its management operations are maintained. Hence 241 the LMA is renamed into Central Mobility Database (CMD), which is 242 therefore a Home-CPA. Also, the CMD is able to send and parse 243 both PBU and PBA messages. 245 o The MAG is enriched with the LMA functionalities, hence the name 246 Mobility Anchor and Access Router (MAAR). It maintains a local 247 Binding Cache for the MNs that are attached to it and it is able 248 to send and parse PBU and PBA messages. 250 o The binding cache will have to be extended to include information 251 regarding previous MAARs where the mobile node was anchored and 252 still retains active data sessions, see Appendix B for further 253 details. 255 o Each MAAR has a unique set of global prefixes (which are 256 configurable), that can be allocated by the MAAR to the MNs, but 257 must be exclusive to that MAAR, i.e. no other MAAR can allocate 258 the same prefixes. 260 The MAARs leverage on the Central Mobility Database (CMD) to access 261 and update information related to the MNs, stored as mobility 262 sessions; hence, a centralized node maintains a global view on the 263 status of the network. The CMD is queried whenever a MN is detected 264 to join/leave the mobility domain. It might be a fresh attachment, a 265 detachment or a handover, but as MAARs are not aware of past 266 information related to a mobility session, they contact the CMD to 267 retrieve the data of interest and eventually take the appropriate 268 action. The procedure adopted for the query and the messages 269 exchange sequence might vary to optimize the update latency and/or 270 the signaling overhead. Here is presented one method for the initial 271 registration, and three different approaches to update the mobility 272 sessions using PBUs and PBAs. Each approach assigns a different role 273 to the CMD: 275 o The CMD is a PBU/PBA relay; 277 o The CMD is only a MAAR locator; 279 o The CMD is a PBU/PBA proxy. 281 This solution can be categorized under Model-1: Split Home Anchor 282 Mode in [I-D.ietf-dmm-deployment-models]. As another note, the 283 solution described in this document allows performing per-prefix 284 anchoring decisions, to support e.g., some flows to be anchored at a 285 central Home-DPA (like a traditional LMA) or to enable an application 286 to switch to the locally anchored prefix to gain route optimization, 287 as indicated in [I-D.ietf-dmm-ondemand-mobility]. 289 3.1. Initial registration 291 Upon the MN's attachment to a MAAR, say MAAR1, if the MN is 292 authorized for the service, an IPv6 global prefix belonging to the 293 MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding 294 Cache Entry (BCE) allocated locally. The prefix is sent in a 295 [RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which, 296 since the session is new, stores a permanent BCE containing as main 297 fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. 298 The CMD replies to MAAR1 with a PBA including the usual options 299 defined in PMIP/RFC5213, meaning that the MN's registration is fresh 300 and no past status is available. MAAR1 definitely stores the 301 temporal BCE previously allocated and unicasts a Router Advertisement 302 (RA) to the MN including the prefix reserved before, that can be used 303 by the MN to configure an IPv6 address (e.g., with stateless auto- 304 configuration). The address is routable at the MAAR, in the sense 305 that it is on the path of packets addressed to the MN. Moreover, the 306 MAAR acts as plain router for those packets, as no encapsulation nor 307 special handling takes place. Figure 1 illustrates this scenario. 309 +-----+ +---+ +--+ 310 |MAAR1| |CMD| |CN| 311 +-----+ +---+ +*-+ 312 | | * 313 MN | * +---+ 314 attach. | ***** _|CMD|_ 315 detection | flow1 * / +-+-+ \ 316 | | * / | \ 317 local BCE | * / | \ 318 allocation | * / | \ 319 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 320 | BCE | * | | | | | 321 | creation |MAAR1+------+MAAR2+-----+MAAR3| 322 |<-- PBA ---| | * | | | | | 323 local BCE | +---*-+ +-----+ +-----+ 324 finalized | * 325 | | Pref1 * 326 | | +*-+ 327 | | |MN| 328 | | +--+ 330 Operations sequence Packets flow 332 Figure 1: First attachment to the network 334 3.2. The CMD as PBU/PBA relay 336 When the MN moves from its current access and associates to MAAR2 337 (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it 338 stores a temporal BCE, and it sends a plain PBU to the CMD for 339 registration. Upon PBU reception and BC lookup, the CMD retrieves an 340 already existing entry for the MN, binding the MN-ID to its former 341 location; thus, the CMD forwards the PBU to the MAAR indicated as 342 Proxy CoA (MAAR1), including a new mobility option to communicate the 343 S-MAAR's global address to MAAR1, defined as Serving MAAR Option in 344 Section 3.7.6. The CMD updates the P-CoA field in the BCE related to 345 the MN with the S-MAAR's address. 347 Upon PBU reception, MAAR1 can install a tunnel on its side towards 348 MAAR2 and the related routes for Pref1. Then MAAR1 replies to the 349 CMD with a PBA (including the option mentioned before) to ensure that 350 the new location has successfully changed, containing the prefix 351 anchored at MAAR1 in the Home Network Prefix option. The CMD, after 352 receiving the PBA, updates the BCE populating an instance of the 353 P-MAAR list. The P-MAAR list is an additional field on the BCE that 354 contains an element for each P-MAAR involved in the MN's mobility 355 session. The list element contains the P-MAAR's global address and 356 the prefix it has delegated (see Appendix B for further details). 357 Also, the CMD send a PBA to the new S-MAAR, containing the previous 358 Proxy-CoA and the prefix anchored to it embedded into a new mobility 359 option called Previous MAAR Option (defined in Section 3.7.5), so 360 that, upon PBA arrival, a bi-directional tunnel can be established 361 between the two MAARs and new routes are set appropriately to recover 362 the IP flow(s) carrying Pref1. 364 Now packets destined to Pref1 are first received by MAAR1, 365 encapsulated into the tunnel and forwarded to MAAR2, which finally 366 delivers them to their destination. In uplink, when the MN transmits 367 packets using Pref1 as source address, they are sent to MAAR2, as it 368 is MN's new default gateway, then tunneled to MAAR1 which routes them 369 towards the next hop to destination. Conversely, packets carrying 370 Pref2 are routed by MAAR2 without any special packet handling both 371 for uplink and downlink. The procedure is depicted in Figure 2. 373 +-----+ +---+ +-----+ +--+ +--+ 374 |MAAR1| |CMD| |MAAR2| |CN| |CN| 375 +-----+ +---+ +-----+ +*-+ +*-+ 376 | | | * * 377 | | MN * +---+ * 378 | | attach. ***** _|CMD|_ * 379 | | det. flow1 * / +-+-+ \ *flow2 380 | |<-- PBU ---| * / | \ * 381 | BCE | * / | ******* 382 | check+ | * / | * \ 383 | update | +---*-+-? +--+-*+ `+-----+ 384 |<-- PBU*---| | | * | | *| | | 385 route | | |MAAR1|______|MAAR2+-----+MAAR3| 386 update | | | **(______)** *| | | 387 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 388 | BCE | * * 389 | update | Pref1 * *Pref2 390 | |--- PBA*-->| +*--*+ 391 | | route ---move-->|*MN*| 392 | | update +----+ 394 Operations sequence Data Packets flow 395 PBU/PBA Messages with * contain 396 a new mobility option 398 Figure 2: Scenario after a handover, CMD as relay 400 For next MN's movements the process is repeated except for the number 401 of P-MAARs involved, that rises accordingly to the number of prefixes 402 that the MN wishes to maintain. Indeed, once the CMD receives the 403 first PBU from the new S-MAAR, it forwards copies of the PBU to all 404 the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 405 prior to handover) and in the P-MAARs list. They reply with a PBA to 406 the CMD, which aggregates them into a single one to notify the 407 S-MAAR, that finally can establish the tunnels with the P-MAARs. 409 It should be noted that this design separates the mobility management 410 at the prefix granularity, and it can be tuned in order to erase old 411 mobility sessions when not required, while the MN is reachable 412 through the latest prefix acquired. Moreover, the latency associated 413 to the mobility update is bound to the PBA sent by the furthest 414 P-MAAR, in terms of RTT, that takes the longest time to reach the 415 CMD. The drawback can be mitigated introducing a timeout at the CMD, 416 by which, after its expiration, all the PBAs so far collected are 417 transmitted, and the remaining are sent later upon their arrival. 419 3.3. The CMD as MAAR locator 421 The handover latency experienced in the approach shown before can be 422 reduced if the P-MAARs are allowed to signal directly their 423 information to the new S-MAAR. This procedure reflect what was 424 described in Section 3.2 up to the moment the P-MAAR receives the PBU 425 with the P-MAAR option. At that point a P-MAAR is aware of the new 426 MN's location (because of the S-MAAR's address in the S-MAAR option), 427 and, besides sending a PBA to the CMD, it also sends a PBA to the 428 S-MAAR including the prefix it is anchoring. This latter PBA does 429 not need to include new options, as the prefix is embedded in the HNP 430 option and the P-MAAR's address OS taken from the message's source 431 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 432 as the latter receives a copy directly from the P-MAAR with the 433 necessary information to build the tunnels and set the appropriate 434 routes. In Figure 3 is illustrated the new messages sequence, while 435 the data forwarding is unaltered. 437 +-----+ +---+ +-----+ +--+ +--+ 438 |MAAR1| |CMD| |MAAR2| |CN| |CN| 439 +-----+ +---+ +-----+ +*-+ +*-+ 440 | | | * * 441 | | MN * +---+ * 442 | | attach. ***** _|CMD|_ * 443 | | det. flow1 * / +-+-+ \ *flow2 444 | |<-- PBU ---| * / | \ * 445 | BCE | * / | ******* 446 | check+ | * / | * \ 447 | update | +---*-+-? +--+-*+ `+-----+ 448 |<-- PBU*---| | | * | | *| | | 449 route | | |MAAR1|______|MAAR2+-----+MAAR3| 450 update | | | **(______)** *| | | 451 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 452 |--- PBA*-->| route * * 453 | BCE update Pref1 * *Pref2 454 | update | +*--*+ 455 | | | ---move-->|*MN*| 456 | | | +----+ 458 Operations sequence Data Packets flow 459 PBU/PBA Messages with * contain 460 a new mobility option 462 Figure 3: Scenario after a handover, CMD as locator 464 3.4. The CMD as MAAR proxy 466 A further enhancement of previous solutions can be achieved when the 467 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 468 the location change. Indeed, when the CMD receives the PBU for the 469 new registration, it is already in possess of all the information 470 that the new S-MAAR requires to set up the tunnels and the routes. 471 Thus the PBA is sent to the S-MAAR immediately after a PBU is 472 received, including also in this case the P-MAAR option. In 473 parallel, a PBU is sent by the CMD to the P-MAARs containing the 474 S-MAAR option, to notify them about the new MN's location, so they 475 receive the information to establish the tunnels and routes on their 476 side. When P-MAARs complete the update, they send a PBA to the CMD 477 to indicate that the operation is concluded and the information are 478 updated in all network nodes. This procedure is obtained from the 479 first one re-arranging the order of the messages, but the parameters 480 communicated are the same. This scheme is depicted in Figure 4, 481 where, again, the data forwarding is kept untouched. 483 +-----+ +---+ +-----+ +--+ +--+ 484 |MAAR1| |CMD| |MAAR2| |CN| |CN| 485 +-----+ +---+ +-----+ +*-+ +*-+ 486 | | | * * 487 | | MN * +---+ * 488 | | attach. ***** _|CMD|_ * 489 | | det. flow1 * / +-+-+ \ *flow2 490 | |<-- PBU ---| * / | \ * 491 | BCE | * / | ******* 492 | check+ | * / | * \ 493 | update | +---*-+-? +--+-*+ `+-----+ 494 |<-- PBU*---x--- PBA*-->| | * | | *| | | 495 route | route |MAAR1|______|MAAR2+-----+MAAR3| 496 update | update | **(______)** *| | | 497 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 498 | BCE | * * 499 | update | Pref1 * *Pref2 500 | | | +*--*+ 501 | | | ---move-->|*MN*| 502 | | | +----+ 504 Operations sequence Data Packets flow 505 PBU/PBA Messages with * contain 506 a new mobility option 508 Figure 4: Scenario after a handover, CMD as proxy 510 3.5. De-registration 512 The de-registration mechanism devised for PMIPv6 is no longer valid 513 in the Partial DMM architecture. This is motivated by the fact that 514 each MAAR handles an independent mobility session (i.e., a single or 515 a set of prefixes) for a given MN, whereas the aggregated session is 516 stored at the CMD. Indeed, when a previous MAAR initiates a de- 517 registration procedure, because the MN is no longer present on the 518 MAAR's access link, it removes the routing state for that (those) 519 prefix(es), that would be deleted by the CMD as well, hence defeating 520 any prefix continuity attempt. The simplest approach to overcome 521 this limitation is to deny an old MAAR to de-register a prefix, that 522 is, allowing only a serving MAAR to de-register the whole MN session. 523 This can be achieved by first removing any layer-2 detachment event, 524 so that de-registration is triggered only when the session lifetime 525 expires, hence providing a guard interval for the MN to connect to a 526 new MAAR. Then, a change in the MAAR operations is required, and at 527 this stage two possible solutions can be deployed: 529 o A previous MAAR stops the BCE timer upon receiving a PBU from the 530 CMD containing a "Serving MAAR" option. In this way only the 531 Serving MAAR is allowed to de-register the mobility session, 532 arguing that the MN left definitely the domain. 534 o Previous MAARs can, upon BCE expiry, send de-registration messages 535 to the CMD, which, instead of acknowledging the message with a 0 536 lifetime, send back a PBA with a non-zero lifetime, hence re- 537 newing the session, if the MN is still connected to the domain. 539 The evaluation of these methods is left for future work. 541 3.6. The Distributed Logical Interface (DLIF) concept 543 One of the main challenges of a network-based DMM solution is how to 544 allow a mobile node to simultaneously send/receive traffic which is 545 anchored at different MAARs, and how to influence on the preference 546 of the mobile selecting the source IPv6 address for a new 547 communication, without requiring special support on the mobile node 548 stack. This document defines the Distributed Logical Interface 549 (DLIF), which is a software construct that allows to easily hide the 550 change of anchor from the mobile node. 552 +---------------------------------------------------+ 553 ( Operator's ) 554 ( core ) 555 +---------------------------------------------------+ 556 | | 557 +---------------+ tunnel +---------------+ 558 | IP stack |===============| IP stack | 559 +---------------+ +-------+-------+ 560 | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ 561 +---------------+ | | +-------+-------+ | 562 | phy interface | | | | phy interface | | 563 +---------------+ | | +---------------+ | 564 MAAR1 (o) (o) MAAR2 (o) 565 x x 566 x x 567 prefA::/64 x x prefB::/64 568 (AdvPrefLft=0) x x 569 (o) 570 | 571 +-----+ 572 prefA::MN1 | MN1 | prefB::MN1 573 (deprecated) +-----+ 575 Figure 5: DLIF: exposing multiple routers (one per active anchoring 576 MAAR) 578 The basic idea of the DLIF concept is the following. Each serving 579 MAAR exposes itself towards a given MN as multiple routers, one per 580 active anchoring MAAR associated to the MN. Let's consider the 581 example shown in Figure 5, MN1 initially attaches to MAAR1, 582 configuring an IPv6 address (prefA::MN1) from a prefix locally 583 anchored at MAAR1 (prefA::/64). At this stage, MAAR1 plays both the 584 role of anchoring and serving MAAR, and also it behaves as a plain 585 IPv6 access router. MAAR1 creates a distributed logical interface to 586 communicate (point-to-point link) with MN1, exposing itself as a 587 (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and 588 IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) 589 using the DLIF mn1mar1. As explained below, these addresses 590 represent the "logical" identity of MAAR1 towards MN1, and will 591 "follow" the mobile node while roaming within the domain (note that 592 the place where all this information is maintained and updated is 593 out-of-scope of this draft; potential examples are to keep it on the 594 HSS or the user's profile). 596 If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in 597 the example of Figure 5), this MAAR will create a new logical 598 interface (mn1mar2) to expose itself towards MN1, providing it with a 599 locally anchored prefix (prefB::/64). In this case, since the MN1 600 has another active IPv6 address anchored at a MAAR1, MAAR2 also needs 601 to create an additional logical interface configured to exactly 602 resemble the one used by MAAR1 to communicate with MN1. In this 603 example, there is only one active anchoring MAAR (in addition to 604 MAAR2, which is the serving one): MAAR1, so only the logical 605 interface mn1mar1 is created, but the same process would be repeated 606 in case there were more active anchoring MAARs involved. In order to 607 maintain the prefix anchored at MAAR1 reachable, a tunnel between 608 MAAR1 and MAAR2 is established and the routing is modified 609 accordingly. The PBU/PBA signaling is used to set-up the bi- 610 directional tunnel between MAAR1 and MAAR2, and it might also be used 611 to convey to MAAR2 the information about the prefix(es) anchored at 612 MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1). 614 +------------------------------------------+ +----------------------+ 615 | MAAR1 | | MAAR2 | 616 |+----------------------------------------+| |+--------------------+| 617 ||+------------------++------------------+|| ||+------------------+|| 618 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 619 ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| 620 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 621 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 622 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 623 ||+------------------++------------------+|| ||+------------------+|| 624 || HMAC1 (phy if MAAR1) || ||HMAC2 (phy if MAAR2)|| 625 |+----------------------------------------+| |+--------------------+| 626 +------------------------------------------+ +----------------------+ 627 x x x 628 x x x 629 (o) (o) (o) 630 | | | 631 +--+--+ +--+--+ +--+--+ 632 | MN3 | | MN2 | | MN1 | 633 +-----+ +-----+ +-----+ 635 Figure 6: Distributed Logical Interface concept 637 Figure 6 shows the logical interface concept in more detail. The 638 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 639 and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two 640 active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR 641 always plays the role of anchoring MAAR for the attached (served) 642 MNs. Each MAAR has one single physical wireless interface. 644 As introduced before, each MN always "sees" multiple logical routers 645 -- one per active anchoring MAAR -- independently of to which serving 646 MAAR the MN is currently attached. From the point of view of the MN, 647 these MAARs are portrayed as different routers, although the MN is 648 physically attached to one single interface . The way this is 649 achieved is by the serving MAAR configuring different logical 650 interfaces. If we focus on MN1, it is currently attached to MAAR2 651 (i.e., MAAR2 is its serving MAAR) and, therefore, it has configured 652 an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set- 653 up a logical interface (mn1dgw2) on top of its wireless physical 654 interface (phy if MAAR2) which is used to serve MN1. This interface 655 has a logical MAC address (LMAC6), different from the hardware MAC 656 address (HMAC2) of the physical interface of MAAR2. Over the mn1dgw2 657 interface, MAAR2 advertises its locally anchored prefix prefB::/64. 658 Before attaching to MAAR2, MN1 visited MAAR1, configuring also an 659 address locally anchored at this MAAR, which is still being used by 660 the MN1 in active communications. MN1 keeps "seeing" an interface 661 connecting to MAAR1, as if it were directly connected to the two 662 MAARs. This is achieved by the serving MAAR (MAAR1) configuring an 663 additional distributed logical interface: mn1dgw1, which behaves 664 exactly as the logical interface configured by the actual MAAR1 when 665 MN1 was attached to it. This means that both the MAC and IPv6 666 addresses configured on this logical interface remain the same 667 regardless of the physical MAAR which is serving the MN. The 668 information required by a serving MAAR to properly configure this 669 logical interfaces can be obtained in different ways: as part of the 670 information conveyed in the PBA, from an external database (e.g., the 671 HSS) or by other means. As shown in the figure, each MAAR may have 672 several logical interfaces associated to each attached MN, having 673 always at least one (since a serving MAAR is also an anchoring MAAR 674 for the attached MN). 676 In order to enforce the use of the prefix locally anchored at the 677 serving MAAR, the router advertisements sent over those logical 678 interfaces playing the role of anchoring MAARs (different from the 679 serving one) include a zero prefix lifetime. The goal is to 680 deprecate the prefixes delegated by these MAARs (which will be no 681 longer serving the MN). Note that on-going communications keep on 682 using those addresses, even if they are deprecated, so this only 683 affects to new sessions. 685 The distributed logical interface concept also enables the following 686 use case. Suppose that access to a local IP network is provided by a 687 given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that 688 the resources available at that network cannot be reached from 689 outside the local network (e.g., cannot be accessed by an MN attached 690 to MAAR2). This is similar to the LIPA scenario currently being 691 consider by 3GPP. The goal is to allow an MN to be able to roam 692 while still being able to have connectivity to this local IP network. 693 The solution adopted to support this case makes use of RFC 4191 694 [RFC4191] more specific routes when the MN moves to a MAAR different 695 from the one providing access to the local IP network (MAAR1 in the 696 example). These routes are advertised through the distributed 697 logical interface representing the MAAR providing access to the local 698 network (MAAR1 in this example). In this way, if MN1 moves from 699 MAAR1 to MAAR2, any active session that MN1 may have with a node of 700 the local network connected to MAAR1 will survive, being the traffic 701 forwarded via the tunnel between MAAR1 and MAAR2. Also, any 702 potential future connection attempt towards the local network will be 703 supported, even though MN1 is no longer attached to MAAR1. 705 3.7. Message Format 707 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 708 protocol messages. 710 3.7.1. Proxy Binding Update 712 A new flag (D) is included in the Proxy Binding Update to indicate 713 that the Proxy Binding Update is coming from a Mobility Anchor and 714 Access Router and not from a mobile access gateway. The rest of the 715 Proxy Binding Update format remains the same as defined in [RFC5213]. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Sequence # | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | 725 . . 726 . Mobility options . 727 . . 729 | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 MAAR Flag (D) 734 The D Flag is set to indicate to the receiver of the message that 735 the Proxy Binding Update is from a MAAR. 737 Mobility Options 739 Variable-length field of such length that the complete Mobility 740 Header is an integer multiple of 8 octets long. This field 741 contains zero or more TLV-encoded mobility options. The encoding 742 and format of defined options are described in Section 6.2 of 744 [RFC6275]. The MAAR MUST ignore and skip any options that it does 745 not understand. 747 3.7.2. Proxy Binding Acknowledgment 749 A new flag (D) is included in the Proxy Binding Acknowledgment to 750 indicate that the sender supports operating as a distributed gateway. 751 The rest of the Proxy Binding Acknowledgment format remains the same 752 as defined in [RFC5213]. 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Status |K|R|P|D| Reser | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Sequence # | Lifetime | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 . . 763 . Mobility options . 764 . . 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 MAAR (D) 770 The D is set to indicate that the sender of the message supports 771 operating as a distributed gateway. 773 Mobility Options 775 Variable-length field of such length that the complete Mobility 776 Header is an integer multiple of 8 octets long. This field 777 contains zero or more TLV-encoded mobility options. The encoding 778 and format of defined options are described in Section 6.2 of 779 [RFC6275]. The MAAR MUST ignore and skip any options that it does 780 not understand. 782 3.7.3. Anchored Prefix Option 784 A new Anchored Prefix option is defined for use with the Proxy 785 Binding Update and Proxy Binding Acknowledgment messages exchanged 786 between distributed gateways. This option is used for exchanging the 787 mobile node's prefix anchored at the anchoring MAAR. There can be 788 multiple Anchored Prefix options present in the message. 790 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 791 format is as follows: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type | Length | Reserved | Prefix Length | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | 799 + + 800 | | 801 + Anchored Prefix + 802 | | 803 + + 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Type 809 To be assigned by IANA. 811 Length 813 8-bit unsigned integer indicating the length of the option in 814 octets, excluding the type and length fields. This field MUST be 815 set to 18. 817 Reserved 819 This field is unused for now. The value MUST be initialized to 0 820 by the sender and MUST be ignored by the receiver. 822 Prefix Length 824 8-bit unsigned integer indicating the prefix length of the IPv6 825 prefix contained in the option. 827 Anchored Prefix 829 A sixteen-byte field containing the mobile node's IPv6 Anchored 830 Prefix. 832 3.7.4. Local Prefix Option 834 A new Local Prefix option is defined for use with the Proxy Binding 835 Update and Proxy Binding Acknowledgment messages exchanged between 836 MAARs. This option is used for exchanging a prefix of a local 837 network that is only reachable via the anchoring MAAR. There can be 838 multiple Local Prefix options present in the message. 840 The Local Prefix Option has an alignment requirement of 8n+4. Its 841 format is as follows: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Type | Length | Reserved | Prefix Length | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | | 849 + + 850 | | 851 + Local Prefix + 852 | | 853 + + 854 | | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Type 859 To be assigned by IANA. 861 Length 863 8-bit unsigned integer indicating the length of the option in 864 octets, excluding the type and length fields. This field MUST be 865 set to 18. 867 Reserved 869 This field is unused for now. The value MUST be initialized to 0 870 by the sender and MUST be ignored by the receiver. 872 Prefix Length 874 8-bit unsigned integer indicating the prefix length of the IPv6 875 prefix contained in the option. 877 Local Prefix 879 A sixteen-byte field containing the IPv6 Local Prefix. 881 3.7.5. Previous MAAR Option 883 This new option is defined for use with the Proxy Binding 884 Acknowledgement messages exchanged by the CMD to a MAAR. This option 885 is used to notify the S-MAAR about the previous MAAR's global address 886 and the prefix anchored to it. There can be multiple Previous MAAR 887 options present in the message. Its format is as follows: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | Prefix Length | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 + + 896 | | 897 + P-MAAR's address + 898 | | 899 + + 900 | | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 + + 904 | | 905 + Home Network Prefix + 906 | | 907 + + 908 | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Type 913 To be assigned by IANA. 915 Length 917 8-bit unsigned integer indicating the length of the option in 918 octets, excluding the type and length fields. This field MUST be 919 set to 34. 921 Prefix Length 923 8-bit unsigned integer indicating the prefix length of the IPv6 924 prefix contained in the option. 926 Previous MAAR's address 928 A sixteen-byte field containing the P-MAAR's IPv6 global address. 930 Home Network Prefix 932 A sixteen-byte field containing the mobile node's IPv6 Home 933 Network Prefix. 935 3.7.6. Serving MAAR Option 937 This new option is defined for use with the Proxy Binding Update and 938 Proxy Binding Acknowledgement messages exchanged between the CMD and 939 a Previous MAAR. This option is used to notify the P-MAAR about the 940 current Serving MAAR's global address. Its format is as follows: 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Type | Length | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | | 948 + + 949 | | 950 + S-MAAR's address + 951 | | 952 + + 953 | | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Type 958 To be assigned by IANA. 960 Length 962 8-bit unsigned integer indicating the length of the option in 963 octets, excluding the type and length fields. This field MUST be 964 set to 16. 966 Serving MAAR's address 968 A sixteen-byte field containing the S-MAAR's IPv6 global address. 970 3.7.7. DLIF Link-local Address Option 972 A new DLIF Link-local Address option is defined for use with the 973 Proxy Binding Update and Proxy Binding Acknowledgment messages 974 exchanged between MAARs. This option is used for exchanging the 975 link-local address of the DLIF to be configured on the serving MAAR 976 so it resembles the DLIF configured on the anchoring MAAR. 978 The DLIF Link-local Address option has an alignment requirement of 979 8n+6. Its format is as follows: 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Type | Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 + + 988 | | 989 + DLIF Link-local Address + 990 | | 991 + + 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Type 997 To be assigned by IANA. 999 Length 1001 8-bit unsigned integer indicating the length of the option in 1002 octets, excluding the type and length fields. This field MUST be 1003 set to 16. 1005 DLIF Link-local Address 1007 A sixteen-byte field containing the link-local address of the 1008 logical interface. 1010 3.7.8. DLIF Link-layer Address Option 1012 A new DLIF Link-layer Address option is defined for use with the 1013 Proxy Binding Update and Proxy Binding Acknowledgment messages 1014 exchanged between MAARs. This option is used for exchanging the 1015 link-layer address of the DLIF to be configured on the serving MAAR 1016 so it resembles the DLIF configured on the anchoring MAAR. 1018 The format of the DLIF Link-layer Address option is shown below. 1019 Based on the size of the address, the option MUST be aligned 1020 appropriately, as per mobility option alignment requirements 1021 specified in [RFC6275]. 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Type | Length | Reserved | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | | 1029 + DLIF Link-layer Address + 1030 . ... . 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Type 1036 To be assigned by IANA. 1038 Length 1040 8-bit unsigned integer indicating the length of the option in 1041 octets, excluding the type and length fields. 1043 Reserved 1045 This field is unused for now. The value MUST be initialized to 0 1046 by the sender and MUST be ignored by the receiver. 1048 DLIF Link-layer Address 1050 A variable length field containing the link-layer address of the 1051 logical interface to be configured on the serving distributed 1052 gateway. 1054 The content and format of this field (including byte and bit 1055 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 1056 link-layer addresses. On certain access links, where the link- 1057 layer address is not used or cannot be determined, this option 1058 cannot be used. 1060 4. IANA Considerations 1062 This document defines new mobility options that require IANA actions. 1064 TBD. 1066 5. Security Considerations 1068 The protocol extensions defined in this document share the same 1069 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 1070 that the signaling messages, Proxy Binding Update and Proxy Binding 1071 Acknowledgment, exchanged between the MAARs are protected using IPsec 1072 using the established security association between them. This 1073 essentially eliminates the threats related to the impersonation of a 1074 MAAR. 1076 6. Acknowledgments 1078 The authors would like to thank Marco Liebsch for his comments and 1079 discussion on the documents [I-D.bernardos-dmm-distributed-anchoring] 1080 and [I-D.bernardos-dmm-pmip] on which the present document is based. 1082 7. References 1084 7.1. Normative References 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, 1088 DOI 10.17487/RFC2119, March 1997, 1089 . 1091 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1092 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1093 November 2005, . 1095 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1096 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1097 DOI 10.17487/RFC4861, September 2007, 1098 . 1100 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1101 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1102 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1103 . 1105 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1106 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1107 2011, . 1109 7.2. Informative References 1111 [I-D.bernardos-dmm-distributed-anchoring] 1112 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 1113 anchoring", draft-bernardos-dmm-distributed-anchoring-09 1114 (work in progress), May 2017. 1116 [I-D.bernardos-dmm-pmip] 1117 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1118 solution for Distributed Mobility Management", draft- 1119 bernardos-dmm-pmip-09 (work in progress), September 2017. 1121 [I-D.ietf-dmm-deployment-models] 1122 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1123 Architectural Considerations", draft-ietf-dmm-deployment- 1124 models-03 (work in progress), November 2017. 1126 [I-D.ietf-dmm-ondemand-mobility] 1127 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 1128 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 1129 ondemand-mobility-13 (work in progress), January 2018. 1131 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1132 Korhonen, "Requirements for Distributed Mobility 1133 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1134 . 1136 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1137 CJ. Bernardos, "Distributed Mobility Management: Current 1138 Practices and Gap Analysis", RFC 7429, 1139 DOI 10.17487/RFC7429, January 2015, 1140 . 1142 Appendix A. Comparison with Requirement document 1144 In this section we descrbe how our solution addresses the DMM 1145 requirements listed in [RFC7333]. 1147 A.1. Distributed mobility management 1149 "IP mobility, network access solutions, and forwarding solutions 1150 provided by DMM MUST enable traffic to avoid traversing a single 1151 mobility anchor far from the optimal route." 1153 In our solution, a MAAR is responsible to handle the mobility for 1154 those IP flows started when the MN is attached to it. As long as the 1155 MN remains connected to the MAAR's access links, the IP packets of 1156 such flows can benefit from the optimal path. When the MN moves to 1157 another MAAR, the path becomes non-optimal for ongoing flows, as they 1158 are anchored to the previous MAAR, but newly started IP sessions are 1159 forwarded by the new MAAR through the optimal path. 1161 A.2. Bypassable network-layer mobility support for each application 1162 session 1164 "DMM solutions MUST enable network-layer mobility, but it MUST be 1165 possible for any individual active application session (flow) to not 1166 use it. Mobility support is needed, for example, when a mobile host 1167 moves and an application cannot cope with a change in the IP address. 1168 Mobility support is also needed when a mobile router changes its IP 1169 address as it moves together with a host and, in the presence of 1170 ingress filtering, an application in the host is interrupted. 1171 However, mobility support at the network layer is not always needed; 1172 a mobile node can often be stationary, and mobility support can also 1173 be provided at other layers. It is then not always necessary to 1174 maintain a stable IP address or prefix for an active application 1175 session." 1177 Our DMM solution operates at the IP layer, hence upper layers are 1178 totally transparent to the mobility operations. In particular, 1179 ongoing IP sessions are not disrupted after a change of access 1180 network. The routability of the old address is ensured by the IP 1181 tunnel with the old MAAR. New IP sessions are started with the new 1182 address. From the application's perspective, those processes which 1183 sockets are bound to a unique IP address do not suffer any impact. 1184 For the other applications, the sockets bound to the old address are 1185 preserved, whereas next sockets use the new address. 1187 A.3. IPv6 deployment 1189 "DMM solutions SHOULD target IPv6 as the primary deployment 1190 environment and SHOULD NOT be tailored specifically to support IPv4, 1191 particularly in situations where private IPv4 addresses and/or NATs 1192 are used." 1194 The DMM solution we propose targets IPv6 only. 1196 A.4. Existing mobility protocols 1198 "A DMM solution MUST first consider reusing and extending IETF 1199 standard protocols before specifying new protocols." 1201 This DMM solution is derived from the operations and messages 1202 specified in [RFC5213]. 1204 A.5. Coexistence with deployed networks/hosts and operability across 1205 different networks 1207 "A DMM solution may require loose, tight, or no integration into 1208 existing mobility protocols and host IP stacks. Regardless of the 1209 integration level, DMM implementations MUST be able to coexist with 1210 existing network deployments, end hosts, and routers that may or may 1211 not implement existing mobility protocols. Furthermore, a DMM 1212 solution SHOULD work across different networks, possibly operated as 1213 separate administrative domains, when the needed mobility management 1214 signaling, forwarding, and network access are allowed by the trust 1215 relationship between them" 1217 The partially DMM solution can be extended to provide a fallback 1218 mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to 1219 instruct MAARs to always establish a tunnel with the same MAAR, 1220 working as LMA. The fully DMM solution can be extended as well, but 1221 it requires more intervention. The partially DMM solution can be 1222 deployed across different domains with trust agreements if the CMDs 1223 ot the operators are enabled to transfer context from one node to 1224 another. The fully DMM solution works across multiple domains if 1225 both solution apply the same signalling scheme. 1227 A.6. Operation and management considerations 1229 "A DMM solution needs to consider configuring a device, monitoring 1230 the current operational state of a device, and responding to events 1231 that impact the device, possibly by modifying the configuration and 1232 storing the data in a format that can be analyzed later. 1234 The proposed solution can re-use existing mechanisms defined for the 1235 operation and management of Proxy Mobile IPv6. 1237 A.7. Security considerations 1239 "A DMM solution MUST support any security protocols and mechanisms 1240 needed to secure the network and to make continuous security 1241 improvements. In addition, with security taken into consideration 1242 early in the design, a DMM solution MUST NOT introduce new security 1243 risks or amplify existing security risks that cannot be mitigated by 1244 existing security protocols and mechanisms." 1246 The proposed solution does not specify a security mechanism, given 1247 that the same mechanism for PMIPv6 can be used. 1249 A.8. Multicast 1251 "DMM SHOULD enable multicast solutions to be developed to avoid 1252 network inefficiency in multicast traffic delivery." 1254 This solution in its current version does not specify any support for 1255 multicast traffic, which is left for study in future versions. 1257 Appendix B. Implementation experience 1259 The network-based DMM solution described in section Section 3.4 is 1260 now available at the Open Distributed Mobility Management (ODMM) 1261 project (http://www.odmm.net/), under the name of Mobility Anchors 1262 Distribution for PMIPv6 (MAD-PMIPv6). The ODMM platform is intended 1263 to foster DMM development and deployment, by serving as a framework 1264 to host open source implementations. 1266 The MAD-PMIPv6 code is developed in ANSI C from the existing UMIP 1267 implementation for PMIP. The most relevant changes with respect to 1268 the UMIP original version are related to how to create the CMD and 1269 MAAR's state machines from those of an LMA and a MAG; for this 1270 purpose, part of the LMA code was copied to the MAG, in order to send 1271 PBA messages and parse PBU. Also, the LMA routing functions were 1272 removed completely, and moved to the MAG, because MAARs need to route 1273 through the tunnels in downlink (as an LMA) and in uplink (as a MAG). 1275 Tunnel management is hence a relevant technical aspect, as multiple 1276 tunnels are established by a single MAAR, which keeps their status 1277 directly into the MN's BCE. Indeed, from the implementation 1278 experience it was chosen to create an ancillary data structure as 1279 field within a BCE: the data structure is called "MAAR list" and 1280 stores the previous MAARs' address and the corresponding prefix(es) 1281 assigned for the MN. Only the CMD and the serving MAAR store this 1282 data structure, because the CMD maintains the global MN's mobility 1283 session formed during the MN's roaming within the domain, and the 1284 serving MAAR needs to know which previous MAARs were visited, the 1285 prefix(es) they assigned and the tunnels established with them. 1286 Conversely, a previous MAAR only needs to know which is the current 1287 Serving MAAR and establish a single tunnel with it. For this reason, 1288 a MAAR that receives a PBU from the CMD (meaning that the MN attached 1289 to another MAAR), first sets up the routing state for the MN's 1290 prefix(es) it is anchoring, then stop the BCE expiry timer and 1291 deletes the MAAR list (if present) since it is no longer useful. 1293 In order to have the MN totally unaware of the changes in the access 1294 link, all MAARs implement the Distributed Logical Interface (DLIF) 1295 concept. Moreover, it should be noted that the protocols designed in 1296 the document work only at the network layer to handle the MNs joining 1297 or leaving the domain. This should guarantee a certain independency 1298 to a particular access technology. The implementation reflects this 1299 reasoning, but we argue that an interaction with lower layers 1300 produces a more effective attachment and detachment detection, 1301 therefore improving the performance, also regarding de-registration 1302 mechanisms. 1304 It was chosen to implement the "proxy" solution because it produces 1305 the shortest handover latency, but a slight modification on the CMD 1306 state machine can produce the first scenario described ("relay") 1307 which guarantees a more consistent request/ack scheme between the 1308 MAARS. By modifying also the MAAR's state machine it can be 1309 implemented the second solution ("locator"). 1311 An early MAD-PMIPv6 implementation was shown during a demo session at 1312 the IETF 83rd, in Paris in March 2012. An enhancement version of the 1313 prototype has been presented at the 87th IETF meeting in Berlin, July 1314 2013. The updated demo included a use case scenario employing a CDN 1315 system for video delivery. More, MAD-PMIPv6 has been extensively 1316 used and evaluated within a testbed employing heterogeneous radio 1317 accesses within the framework of the MEDIEVAL EU project. MAD-PMIPv6 1318 software is currently part of a DMM test-bed comprising 3 MAARs, one 1319 CMD, one MN and a CN. All the machines used in the demos were Linux 1320 UBUNTU 10.04 systems with kernel 2.6.32, but the prototype has been 1321 tested also under newer systems. This testbed was also used by the 1322 iJOIN EU project. 1324 Appendix C. Applicability to the fog environment 1326 Virtualization is invading all domains of the E2E 5G network, 1327 including the access, as a mean to achieve the necessary flexibility 1328 in support of the E2E slicing concept. The ETSI NFV framework is the 1329 cornerstone for making virtualization such a promising technology 1330 that can be matured in time for 5G. Typically, virtualization has 1331 been mostly envisaged in the core network, where sophisticated data 1332 centers and clouds provided the right substrate. And mostly, the 1333 framework focused on virtualizing network functions, so called VNFs 1334 (virtualized network functions), which were somewhat limited to 1335 functions that are delay tolerant, typically from the core and 1336 aggregation transport. 1338 As the community has recently been developing the 5G applications and 1339 their technical requirements, it has become clear that certain 1340 applications would require very low latency which is extremely 1341 challenging and stressing for the network to deliver through a pure 1342 centralized architecture. The need to provide networking, computing, 1343 and storage capabilities closer to the users has therefore emerged, 1344 leading to what is known today as the concept of intelligent edge. 1346 ETSI has been the first to address this need recently by developing 1347 the framework of mobile edge computing (MEC). 1349 Such an intelligent edge could not be envisaged without 1350 virtualization. Beyond applications, it raises a clear opportunity 1351 for networking functions to execute at the edge benefiting from 1352 inherent low latencies. 1354 Whilst it is appreciated the particular challenge for the intelligent 1355 edge concept in dealing with mobile users, the edge virtualization 1356 substrate has been largely assumed to be fixed or stationary. 1357 Although little developed, the intelligent edge concept is being 1358 extended further to scenarios where for example the edge computing 1359 substrate is on the move, e.g., on-board a car or a train, or that it 1360 is distributed further down the edge, even integrating resources from 1361 different stakeholders, into what is known as the fog. The 1362 challenges and opportunities for such extensions of the intelligent 1363 edge remain an exciting area of future research. 1365 Figure 7 shows a diagram representing the fog virtualization concept. 1366 The fog is composed by virtual resources on top of heterogeneous 1367 resources available at the edge and even further in the RAN and end- 1368 user devices. These resources are therefore owned by different 1369 stakeholders who collaboratively form a single hosting environment 1370 for the VNFs to run. As an example, virtual resources provided to 1371 the fog might be running on eNBs, APs, at micro data centers deployed 1372 in shopping malls, cars, trains, etc. The fog is connected to data 1373 centers deeper into the network architecture (at the edge ir the 1374 core). 1376 +--------------------------------+ +-------------------+ 1377 | ------- -------- -------- | | ---------- | 1378 | | | | | | | | | ---------- | | 1379 | | @UE | | @car | | @eNB | | | ---------- | | | 1380 | ------- -------- -------- | | | Data | | | | 1381 | | | | Center | | - | 1382 | -------- Heterogeneous ------- | | | (DC) |- | 1383 phy | | | computing | | | | ---------- | 1384 infra | |@train| devices | @AP | |==| ---------- | 1385 | -------- forming ------- | | ---------- | | 1386 | the fog | | ---------- | | | 1387 | --------- ------------ | | | Data | | | | 1388 | | | | | | | | Center | | - | 1389 | | @mall | | @localDC | | | | (DC) |- | 1390 | --------- ------------ | | ---------- | 1391 | FOG | | CLOUD | 1392 +--------------------------------+ +-------------------+ 1393 <--------- fog and edge -----------------> 1394 <--- edge & central cloud ---> 1396 Figure 7: Fog virtualization 1398 In this context, where the "fog" hosts functions and resources, it is 1399 important to enable their mobility. In future versions of this 1400 document we will describe how to apply the solution described here to 1401 the fog environment. 1403 Authors' Addresses 1405 Carlos J. Bernardos 1406 Universidad Carlos III de Madrid 1407 Av. Universidad, 30 1408 Leganes, Madrid 28911 1409 Spain 1411 Phone: +34 91624 6236 1412 Email: cjbc@it.uc3m.es 1413 URI: http://www.it.uc3m.es/cjbc/ 1414 Antonio de la Oliva 1415 Universidad Carlos III de Madrid 1416 Av. Universidad, 30 1417 Leganes, Madrid 28911 1418 Spain 1420 Phone: +34 91624 8803 1421 Email: aoliva@it.uc3m.es 1422 URI: http://www.it.uc3m.es/aoliva/ 1424 Fabio Giust 1425 NEC Laboratories Europe 1426 NEC Europe Ltd. 1427 Kurfuersten-Anlage 36 1428 Heidelberg D-69115 1429 Germany 1431 Phone: +49 6221 4342216 1432 Email: fabio.giust@neclab.eu 1434 Juan Carlos Zuniga 1435 SIGFOX 1436 425 rue Jean Rostand 1437 Labege 31670 1438 France 1440 Email: j.c.zuniga@ieee.org 1441 URI: http://www.sigfox.com/ 1443 Alain Mourad 1444 InterDigital Europe 1446 Email: Alain.Mourad@InterDigital.com 1447 URI: http://www.InterDigital.com/