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