idnits 2.17.00 (12 Aug 2021) /tmp/idnits50573/draft-bernardos-mext-dmm-pmip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 3960 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-chan-distributed-mobility-ps-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: January 12, 2012 F. Giust 6 IMDEA Networks and UC3M 7 T. Melia 8 Alcatel-Lucent 9 July 11, 2011 11 A PMIPv6-based solution for Distributed Mobility Management 12 draft-bernardos-mext-dmm-pmip-01 14 Abstract 16 The number of mobile users and their traffic demand is expected to be 17 ever-increasing in future years, and this growth can represent a 18 limitation for deploying current mobility management schemes that are 19 intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. For 20 this reason it has been waved a need for distributed and dynamic 21 mobility management approaches, with the objective of reducing 22 operators' burdens, evolving to a cheaper and more efficient 23 architecture. 25 This draft describes a solution to distribute the data forwarding 26 plane on Proxy Mobile IPv6 domains, thus trying to overcome the 27 suboptimal data path introduced when the LMA is traversed. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 12, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Description of the solution . . . . . . . . . . . . . . . . . 4 66 3.1. Initial registration . . . . . . . . . . . . . . . . . . . 5 67 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . . 5 68 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 7 69 3.4. The CMD as PBU/PBA proxy . . . . . . . . . . . . . . . . . 8 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Current IP mobility solutions, standardized with the names of Mobile 81 IPv6 [RFC3775], or Proxy Mobile IPv6 [RFC5213], just to cite the two 82 most relevant examples, offer mobility support at the cost of 83 handling operations at a cardinal point, the mobility anchor, and 84 burdening it with data forwarding and control mechanisms for a great 85 amount of users. As stated in [I-D.chan-distributed-mobility-ps], 86 centralized mobility solutions are prone to several problems and 87 limitations: longer (sub-optimal) routing paths, scalability 88 problems, signaling overhead (and most likely a longer associated 89 handover latency), more complex network deployment, higher 90 vulnerability due to the existence of a potential single point of 91 failure, and lack of granularity on the mobility management service 92 (i.e., mobility is offered on a per-node basis, not being possible to 93 define finer granularity policies, as for example per-application). 95 There are basically two main approaches being researched now: one 96 aimed at making Mobile IPv6 work in a distributed way (a complete 97 solution can be found in [I-D.bernardos-mext-dmm-cmip]), and another 98 one doing the same exercise for Proxy Mobile IPv6. In this draft we 99 describe a solution to achieve a DMM behavior for network-based 100 mobility support (i.e., inspired by PMIPv6). This document is based 101 on a research paper of the same authors, currently under submission, 102 called "A Network-based Localized Mobility Solution for Distributed 103 Mobility Management" [Net-basedDMM]. 105 2. Terminology 107 The following terms used in this document are defined in the Proxy 108 Mobile IPv6 specification [RFC5213]: 110 Local Mobility Anchor (LMA) 112 Mobile Access Gateway (MAG) 114 Mobile Node (MN) 116 Binding Cache Entry (BCE) 118 Proxy Care-of Address (P-CoA) 120 Proxy Binding Update (PBU) 122 Proxy Binding Acknowledgement (PBA) 124 The following terms are defined and used in this document: 126 MAAR (Mobility Anchor and Access Router). First hop routers where 127 the mobile nodes attach to. They also play the role of mobility 128 managers for the IPv6 prefixes they anchor. 130 CMD (Central Mobility Database). Node that stores the BCEs for the 131 MNs in the mobility domain. 133 A-MAAR (Anchor MAAR). MAAR which was previously visited by the MN 134 and is still involved in an active flow using an IPv6 prefix it 135 has advertised to the MN (i.e., MAAR where that IPv6 prefix is 136 anchored). 138 S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. 140 3. Description of the solution 142 The purpose of Distributed Mobility Management approaches is to 143 overcome the limitations of the traditional centralized mobility 144 management by bringing the mobility anchor closer to the MN. 145 Following this idea, in our proposal, the central anchor is moved to 146 the edge of the network, being deployed in the default gateway of the 147 mobile node. That is, the first elements that provide IP 148 connectivity to a set of MNs are also the mobility managers for those 149 MNs. In the following, we will call these Mobility Anchor and Access 150 Routers (MAARs). 152 However, MAARs leverage on the Central Mobility Database (CMD) to 153 access and update information related to the MNs, stored as mobility 154 sessions; hence, a centralized node maintains a global view on the 155 status of the network. The CMD is queried whenever a MN is detected 156 to join the mobility domain. It might be a fresh attachment or a 157 handover, but as MAARs do not store any mobilty session, they contact 158 the CMD to retrieve the data of interest and eventually take the 159 appropriate action. The procedure adopted for the query and the 160 messages exchange sequence might vary to optimize the update latency 161 and/or the signaling overhead. Here is presented one method for the 162 initial registration, and three different approaches to update the 163 mobility sessions using PBUs and PBAs. Each approach assigns a 164 different role to the CMD: 166 o The CMD is a PBU/PBA relay 168 o The CMD is only a MAAR locator 170 o PBU/PBA is a PBU/PBA proxy 172 3.1. Initial registration 174 Upon the MN's attachment to a MAAR, say MAAR1, an IPv6 global prefix 175 belonging to the MAAR's prefix pool is reserved for it (Pref1). The 176 prefix is sent in a PBU with the MN's Identifier (MN-ID) to the CMD, 177 which, since the session is new, stores a Binding Cache Entry 178 containing as main fields the MN-ID, the MN's prefix and MAAR1's 179 address as Proxy-CoA. The CMD replies to MAAR1 with a PBA indicating 180 that the MN's registration is fresh and no past status is available. 181 MAAR1 sends a Router Advertisement (RA) in unicast to the MN 182 including the prefix reserved before, that can be used by the MN to 183 configure an IPv6 address (e.g., with stateless auto-configuration). 184 The address is routable at the MAAR, in the sense that it is on the 185 path of packets addressed to the MN. Moreover, the MAAR acts as 186 plain router for those packets, as no encapsulation nor special 187 handling takes place. Figure 1 illustrates this scenario. 189 +-----+ +---+ +--+ 190 |MAAR1| |CMD| |CN| 191 +-----+ +---+ +*-+ 192 | | * 193 MN | * +---+ 194 attach. | ***** _|CMD|_ 195 detection | flow1 * / +-+-+ \ 196 | | * / | \ 197 |--- PBU -->| * / | \ 198 | | * / | \ 199 | BCE +---*-+-' +--+--+ `+-----+ 200 | creation | * | | | | | 201 | | |MAAR1+------+MAAR2+-----+MAAR3| 202 |<-- PBA ---| | * | | | | | 203 | | +---*-+ +-----+ +-----+ 204 | | * 205 | | Pref1 * 206 | | +*-+ 207 | | |MN| 208 | | +--+ 210 (Operations sequence) (Packets flow) 212 Figure 1: First attachment to the network 214 3.2. The CMD as PBU/PBA relay 216 When the MN moves from its current access, it associates to MAAR2 217 (now the S-MAAR), which delegates another IPv6 prefix (Pref2) and 218 sends it to the CMD for registration. The CMD has already an entry 219 for the MN, binding the MN-ID to its former location; thus, it 220 forwards the PBU to the MAAR indicated as Proxy CoA, in this case 221 MAAR1 (now the A-MAAR), and it updates the P-CoA field with the 222 S-MAAR's address. Upon PBU reception, MAAR1 replies to the CMD with 223 a PBA to ensure that the new location has successfully changed, 224 containing the prefix anchored at MAAR1. The CMD updates the BCE 225 adding the P-MAAR address in the list of old P-CoAs and forwards the 226 PBA to the new S-MAAR, containing the previous Proxy-CoA and the 227 prefix anchored to it, so that a tunnel can be established between 228 the two MAARs and new routes are set appropriately to recover the 229 flow(s). 231 Now packets destined to Pref1 are first received by MAAR1, 232 encapsulated into the tunnel and forwarded to MAAR2, which finally 233 delivers them to their destination. In uplink, when the MN transmits 234 packets using Pref1 for the source address, they are sent to MAAR2, 235 as it is MN's new default gateway, then tunneled to MAAR1 which 236 routes them towards the next hop to destination. Conversely, packets 237 carrying Pref2 are routed by MAAR2 without any special packet 238 handling both for uplink and downlink. The procedure is depicted in 239 Figure 2. 241 +-----+ +---+ +-----+ +--+ +--+ 242 |MAAR1| |CMD| |MAAR2| |CN| |CN| 243 +-----+ +---+ +-----+ +*-+ +*-+ 244 | | | * * 245 | | MN * +---+ * 246 | | attach. ***** _|CMD|_ * 247 | | det. flow1 * / +-+-+ \ *flow2 248 | |<-- PBU ---| * / | \ * 249 | BCE | * / | ******* 250 | check+ | * / | * \ 251 | update | +---*-+-' +--+-*+ `+-----+ 252 |<-- PBU ---| | | * | | *| | | 253 route | | |MAAR1|______|MAAR2+-----+MAAR3| 254 update | | | **(______)** *| | | 255 |--- PBA -->| | +-----+ +-*--*+ +-----+ 256 | BCE | * * 257 | update | Pref1 * *Pref2 258 | |--- PBA -->| +*--*+ 259 | | route ---move-->|*MN*| 260 | | update +----+ 262 (Operations sequence) (Packets flow) 264 Figure 2: Scenario after a handover, CMD as relay 266 For next MN's movements the process is repeated except for the number 267 of P-MAARs involved, that rises accordingly to the number of prefixes 268 that the MN wishes to maintain. Indeed, once the CMD receives the 269 first PBU from the new S-MAAR, it forwards copies of the PBU to all 270 the A-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 271 prior to handover) and old P-CoAs. They reply with a PBA to the CMD, 272 which aggregates them into a single one to notify the S-MAAR, that 273 finally can establish the tunnels with the A-MAARs. It should be 274 noted that this design separates the mobility management at the 275 prefix granularity, and it can be tuned in order to erase old 276 mobility sessions when not required, while the MN is reachable 277 through the latest prefix acquired. Moreover, the latency associated 278 to the mobility upadate is bound to the PBA sent by the furthest 279 A-MAAR, that takes the longest time to reach the CMD. The drawback 280 can be mitigated introducing a timeout at the CMD, by which, after 281 its expiration, all the PBAs so far collected are transmitted, and 282 the remaining are sent later upon their arrival. 284 3.3. The CMD as MAAR locator 286 The latency experienced in the approach shown before can be mitigated 287 if the A-MAARs are allowed to signal directly their information to 288 the new S-MAAR. This procedure reflect what was described in 289 Section 3.2 up to the moment the A-MAAR receives the PBU. At that 290 point an A-MAAR is aware of the new MN's location (i.e., S-MAAR) and, 291 besides sending a PBA to the CMD, it also sends a PBA to the S-MAAR 292 including the prefix it is anchoring. The CMD is relieved from 293 forwarding the PBA to the S-MAAR, as it receives a copy directly from 294 the A-MAAR with the necessary information to build the tunnel and set 295 the appropriate routes. In Figure 3 is illustrated the new messages 296 sequence, while the data forwarding is unaltered. 298 +-----+ +---+ +-----+ +--+ +--+ 299 |MAAR1| |CMD| |MAAR2| |CN| |CN| 300 +-----+ +---+ +-----+ +*-+ +*-+ 301 | | | * * 302 | | MN * +---+ * 303 | | attach. ***** _|CMD|_ * 304 | | det. flow1 * / +-+-+ \ *flow2 305 | |<-- PBU ---| * / | \ * 306 | BCE | * / | ******* 307 | check+ | * / | * \ 308 | update | +---*-+-' +--+-*+ `+-----+ 309 |<-- PBU ---| | | * | | *| | | 310 route | | |MAAR1|______|MAAR2+-----+MAAR3| 311 update | | | **(______)** *| | | 312 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 313 |--- PBA -->| route * * 314 | BCE update Pref1 * *Pref2 315 | update | +*--*+ 316 | | | ---move-->|*MN*| 317 | | | +----+ 319 (Operations sequence) (Packets flow) 321 Figure 3: Scenario after a handover, CMD as locator 323 3.4. The CMD as PBU/PBA proxy 325 A further enhancement of previous solutions can be achieved when the 326 CMD sends the PBA to the new S-MAAR before notifying the A-MAARs of 327 the location change. Indeed, when the CMD receives the PBU for the 328 new registration, it is already in possess of all the information 329 that the new S-MAAR requires to set up the tunnel and the routes. 330 Thus the PBA is sent to the S-MAAR immediately after a PBU is 331 received. In parallel, a PBU is sent by the CMD to the A-MAARs to 332 notify them about the new MN's location, so they receive the 333 information to establish the tunnel and routes on their side. When 334 A-MAARs complete the update, they send a PBA to the CMD to indicate 335 that the operation is concluded and the information are updated in 336 all network nodes. This scheme is depicted in Figure 4, where, 337 again, the data forwarding is kept untouched. 339 +-----+ +---+ +-----+ +--+ +--+ 340 |MAAR1| |CMD| |MAAR2| |CN| |CN| 341 +-----+ +---+ +-----+ +*-+ +*-+ 342 | | | * * 343 | | MN * +---+ * 344 | | attach. ***** _|CMD|_ * 345 | | det. flow1 * / +-+-+ \ *flow2 346 | |<-- PBU ---| * / | \ * 347 | BCE | * / | ******* 348 | check+ | * / | * \ 349 | update | +---*-+-' +--+-*+ `+-----+ 350 |<-- PBU ---x--- PBA -->| | * | | *| | | 351 route | route |MAAR1|______|MAAR2+-----+MAAR3| 352 update | update | **(______)** *| | | 353 |--- PBA ->| | +-----+ +-*--*+ +-----+ 354 | BCE | * * 355 | update | Pref1 * *Pref2 356 | | | +*--*+ 357 | | | ---move-->|*MN*| 358 | | | +----+ 360 (Operations sequence) (Packets flow) 362 Figure 4: Scenario after a handover, CMD as proxy 364 4. IANA Considerations 366 TBD. 368 5. Security Considerations 370 TBD. 372 6. Acknowledgments 374 The authors would like to thank Marco Liebsch for his comments and 375 discussion on this document. 377 The research leading to these results has received funding from the 378 European Community's Seventh Framework Programme (FP7-ICT-2009-5) 379 under grant agreement n. 258053 (MEDIEVAL project). The work of 380 Carlos J. Bernardos has also been partially supported by the Ministry 381 of Science and Innovation of Spain under the QUARTET project 382 (TIN2009-13992-C02-01). 384 7. References 386 7.1. Normative References 388 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 389 in IPv6", RFC 3775, June 2004. 391 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 392 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 394 7.2. Informative References 396 [I-D.bernardos-mext-dmm-cmip] 397 Bernardos, C. and F. Giust, "A IPv6 Distributed Client 398 Mobility Management approach using existing mechanisms", 399 draft-bernardos-mext-dmm-cmip-00 (work in progress), 400 March 2011. 402 [I-D.chan-distributed-mobility-ps] 403 Chan, A., "Problem statement for distributed and dynamic 404 mobility management", 405 draft-chan-distributed-mobility-ps-03 (work in progress), 406 July 2011. 408 [Net-basedDMM] 409 Giust, F., de la Oliva, A., Bernardos, CJ., and RP. 410 Ferreira Da Costa, "FA Network-based Localized Mobility 411 Solution for Distributed Mobility Management", under 412 submission , 2011. 414 Authors' Addresses 416 Carlos J. Bernardos 417 Universidad Carlos III de Madrid 418 Av. Universidad, 30 419 Leganes, Madrid 28911 420 Spain 422 Phone: +34 91624 6236 423 Email: cjbc@it.uc3m.es 424 URI: http://www.it.uc3m.es/cjbc/ 425 Antonio de la Oliva 426 Universidad Carlos III de Madrid 427 Av. Universidad, 30 428 Leganes, Madrid 28911 429 Spain 431 Phone: +34 91624 8803 432 Email: aoliva@it.uc3m.es 433 URI: http://www.it.uc3m.es/aoliva/ 435 Fabio Giust 436 Institute IMDEA Networks and Universidad Carlos III de Madrid 437 Av. del Mar Mediterraneo, 22 438 Leganes, Madrid 28918 439 Spain 441 Phone: +34 91481 6979 442 Email: fabio.giust@imdea.org 444 Telemaco Melia 445 Alcatel-Lucent Bell Labs 446 Route de Villejust 447 Nozay, Ile de France 91620 448 France 450 Email: telemaco.melia@alcatel-lucent.com