idnits 2.17.00 (12 Aug 2021) /tmp/idnits20947/draft-zhou-netext-lmac-dynamiclma-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2014) is 3048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6463' is mentioned on line 134, but not defined == Missing Reference: 'RFC2119' is mentioned on line 120, but not defined == Missing Reference: 'RFC5844' is mentioned on line 349, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group Q. Zhou 3 Internet-Draft Huawei 4 Intended status: Informational S. Peters 5 Expires: July 2014 TU Berlin 6 F.Sivrikaya 7 TU Berlin 8 R. Sofia 9 COPELABS 10 January 2014 12 LMA Coordination in a Dynamic LMA Environment 13 draft-zhou-netext-lmac-dynamiclma-00.txt 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as 29 "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on July 31, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 This document describes local mobility anchor coordination 57 functionality and corresponding mobility options for Proxy Mobile 58 IPv6. The mobility anchor coordination targets LMAs with a dynamic 59 service provisioning behavior, and is achieved by Proxy Binding 60 Update and a Proxy Binding Acknowledgement message exchange between a 61 Local Mobility Anchor (LMA) and a Local Mobility Anchor Coordinator 62 (LMAc). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions used in this document . . . . . . . . . . . . . . 3 68 3. Overview of LMA Coordination . . . . . . . . . . . . . . . . 3 69 3.1. Operational Scenarios . . . . . . . . . . . . . . . . . . 5 70 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. LMA Update mobility option . . . . . . . . . . . . . . . 7 72 4.2. Existing mobility options reused. . . . . . . . . . . . . 9 73 5. General Operation . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 75 5.2. LMA Operation . . . . . . . . . . . . . . . . . . . . . 11 76 5.3. LMAc Operation . . . . . . . . . . . . . . . . . . . . . 11 77 5.4. MAG Operation . . . . . . . . . . . . . . . . . . . . . 11 78 6. Protocol Configuration Variables . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 A single-LMA environment may cause a single point of failure and 90 bottleneck for mobility support. Thus, Proxy Mobile IPv6 (PMIPv6) 91 specification supports the use of multiple LMAs in a PMIPv6 domain, 92 but assumes that each LMA serves a preconfigured group of mobile 93 nodes [RFC5213]. Dynamic LMA assignment is discussed in several 94 documents; e.g. in [RFC 6463], runtime LMA assignment is proposed for 95 the purpose of load sharing in a multi-LMA environment. 97 In a network with flat architecture, e.g. a user-centric network 98 [UCN], the MAG and LMA functions are implemented in the network 99 elements that are potentially provided by the end users, and thus the 100 offered services are made available according to users' preferences 101 and in a dynamic fashion. As a consequence the number of available 102 LMAs is not known at the time of deployment, which is implicitly 103 assumed in [RFC 6463]. 105 In this proposal the LMAs that are currently offering their anchoring 106 service to MNs, and which are thus available for dynamic selection, 107 are coordinated in the PMIPv6 domain by a broker-like entity. 109 This document specifies the required protocol extensions to PMIPv6 to 110 exchange the LMA information, coordinate the LMA selection, and 111 enable the dynamic provision of LMAs to the MAG, facilitated in a 112 dynamic, multi-LMA environment. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC-2119 [RFC2119]. 119 Terminology. 121 In addition to the terminology defined in [RFC5213], the following 122 terminology is also used: 124 Local Mobility Anchor Coordinator (LMAc): An LMA which receives PBU 125 messages includes the LMA availability and IP address of the LMA, 126 selects the LMA for the MN, and sends the LMA information to the MAG. 128 3. Overview of LMA Coordination 130 As described in section 5.7 of [RFC5213], the PMIPv6 standard assumes 131 the LMA to be assigned to a mobile node via a statically configured 132 profile; other mechanisms are outside the scope of the standard. 134 In [RFC 6463], runtime LMA assignment is proposed for the purpose of 135 load sharing in multi-LMA environment, however, how the runtime LMA 136 assignment functionality (rfLMA) obtains the information on the 137 available target LMAs (r2LMAs) is not specified. 139 This draft builds on [RFC6463], and we describe the dynamic 140 assignment of LMAs to mobile nodes by a newly introduced entity 141 referred to as Local Mobility Anchor Coordinator (LMAc). 143 The LMAc is responsible for the coordination of available LMAs by 144 receiving registration messages from LMAs, selecting an LMA for a 145 specific MN, and sending the selected LMA to the MAG. The MAG finally 146 triggers the standard PMIPv6 procedure. The LMAc is located in the 147 PMIPv6 domain and communicates with MAG and LMA via PMIPv6. 149 Given the mobility coordination performed by LMAc the availability 150 and resource utilization information about LMAs is known to the 151 network. Consequently, the LMA can be selected dynamically for the 152 MNs when the MN attaches to the network, or in case the current LMA 153 goes out of service. 155 An example of such an LMA coordination scenario is shown in Figure 1, 156 where a mobile node (MN) has attached to the MAG. Two LMAs (LMA1 and 157 LMA2) provide the LMA functionality. In addition, the Local Mobility 158 Anchor Coordination (LMAc) entity is also part of the PMIPv6 domain 159 to coordinate the LMA selection. 161 +-------------------------------+ 162 ( +-------+ +-------+ ) 163 ( | LMA1 | | LMA2 | ) 164 ( +-------+ +-------+ ) 165 ( || \ / || ) 166 ( || \ / || ) 167 ( || \ / || ) 168 ( || +-------+ || PMIPv6 ) 169 ( || | LMAc | || domain ) 170 ( || +-------+ || ) 171 ( || | || ) 172 ( || | || ) 173 ( +--------------------+ ) 174 ( | MAG | ) 175 ( +--------------------+ ) 176 +---------------|----------------+ 177 | 178 +------+ 179 | MN | 180 +------+ 181 Figure 1 Overview of LMAc 183 LMA coordination also applies to a mobile network architecture that 184 complies with the 3GPP Evolved Packet Core (EPC) specifications, 185 where the P-GW plays the role of LMA. The Mobility Management Entity 186 (MME) in 3GPP shall select the P-GW for the UE. MME is required to be 187 aware the context of P-GWs, e.g. available resource in the P-GW, to 188 select a better P-GW for the UE. 190 3.1. Operational Scenarios 192 LMA coordination fits well in a user-centric network, where the MAG 193 and LMA functions are implemented in user provided devices, which 194 implies that the offered services are made available according to 195 user's preferences and in a dynamic fashion. The LMAs that are 196 currently offering their service to MNs, and that are available for 197 dynamic selection are required to be known by the LMAc by means of a 198 registration procedure. Subsequently the LMAc is able to select the 199 most suitable anchor node out of the registered LMAs. The specific 200 LMA selection algorithms performed by the LMAc are out of scope of 201 this specification. 203 There are two operational scenarios on LMA coordination considered in 204 this draft: LMA selection on MN attachment, and LMA re-selection. 206 3.1.1. LMA Selection on MN Attachment 208 Figure 2 details the procedure of LMA selection that is triggered 209 when a MN attaches to a MAG that is part of the PMIPv6 domain managed 210 by the LMAc. First, the LMA informs the LMAc of its availability and 211 includes relevant contextual information, such as currently available 212 resources for performing the anchoring service. 214 The LMAc receives the LMA Register message from LMAs and maintains a 215 list of the currently available LMAs. Upon MN attachment the MAG 216 sends an LMA Request to LMAc and thereby requests the LMA for the MN. 217 The LMAc performs the decision, selects the most suitable LMA for the 218 MN, and sends it to the MAG in LMA Response message. 220 +-----+ +-----+ +-----+ +------+ +------+ 221 | MN | | MAG | | LMAc| | LMA1 | | LMA2 | 222 +-----+ +-----+ +-----+ +------+ +------+ 223 | | | | | 224 | | | LMA Register | | 225 | | |<-------------| | 226 | | | LMA Register | 227 | | |<----------------------------| 228 |MN Attachment| | | | 229 |------------>| LMA Request | | | 230 | |------------>| | | 231 | | | | | 232 | | ========================== | | 233 | | || LMA selection || | | 234 | | ========================== | | 235 | | | | | 236 | | LMA Response| | | 237 | |<------------| | | 238 | | | | | 239 | | Binding Request | | 240 | |--------------------------->| | 241 | | Binding Response | | 242 | |<---------------------------| | 243 | | | | | 244 | |<======PMIP tunnel ========>| | 245 | | | | | 247 Figure 2 LMA Selection on MN Attachment 249 3.1.2. LMA Re-Selection 251 Figure 3 details the procedure of LMA re-selection when the current 252 LMA stops offering its service: When MAG detects out-of-service 253 status of current LMA, it sends LMA Request to LMAc, and requests the 254 LMA for the MN, LMAc performs the decision and selects the LMA for 255 the MN, and sends it to the MAG in LMA Response message. 257 +-----+ +-----+ +-----+ +------+ +------+ 258 | MN | | MAG | | LMAc| | LMA1 | | LMA2 | 259 +-----+ +-----+ +-----+ +------+ +------+ 260 | | | | | 261 | |<========PMIP tunnel=======>| | 262 | | | | | 263 | | | LMA1 disappears | 264 | | Keep Alive | | 265 | |--------------------------->| | 266 | TimeOut | | | 267 | | | | | 268 | | LMA Request | | | 269 | |------------>| | | 270 | | | | | 271 | | ========================== | | 272 | | || LMA selection || | | 273 | | ========================== | | 274 | | | | | 275 | | LMA Response| | | 276 | |<------------| | | 277 | | | | | 278 | | Binding Request | 279 | |------------------------------------------>| 280 | | Binding Response | 281 | |<------------------------------------------| 282 | | | | | 283 | |<===============PMIP tunnel ==============>| 284 | | | | | 286 Figure 3 LMA Re-Selection 288 4. Message Format 290 The messages exchanged between MAG and LMAc are the same as defined 291 in Runtime LMA Assignment Support for Proxy Mobile IPv6 protocol 292 message [RFC6463]. The MAG considers LMAc as the default LMA and 293 sends a Proxy Binding Update to the LMAc, then retrieves a redirect- 294 to LMA in Proxy Binding Acknowledgement if a better LMA is selected 295 by LMAc. 297 This section defines extensions to Proxy Mobile IPv6 [RFC5213] and to 298 the Runtime LMA Assignment Support for Proxy Mobile IPv6 protocol 299 message [RFC6463]. 301 4.1. LMA Update mobility option 302 A new mobility header option, LMA Update mobility option is defined 303 for use with Proxy Binding Update from LMA to LMAc. This option is 304 used to register or deregister an LMA to the LMAc. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Option Type | Option Length |K|N|R| Reserved | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 | Optional IPv6 LMA Address | 313 | | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Optional IPv4 LMA Address | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 4 LMA Update Mobility Option 320 o Option Type: To be defined by IANA. 322 o Option Length: 8-bit unsigned integer, representing the length 323 of the LMA Update mobility option in octets, excluding the 324 Option Type and Length fields. If the 'K' flag is set and 'N' 325 is unset, then the length MUST be 18. If the 'K' flag is 326 unset and 'N' is set, then the length MUST be 6. Both the 'K' 327 and 'N' flags cannot be set or unset simultaneously. 329 o 'K' flag: This bit is set (1) if the 'Optional IPv6 LMA 330 Address' is included in the mobility option. Otherwise, the 331 bit is unset (0). 333 o 'N' flag: This bit is set (1) if the 'Optional IPv4 LMA 334 Address' is included in the mobility option. Otherwise, the 335 bit is unset (0). 337 o 'R' flag: This bit is set (1) when LMA registers to the LMAc, 338 and is unset (0) when LMA deregisters to the LMAc. 340 o Reserved: This field is reserved for future use. MUST be set 341 to zero by the sender and ignored by the receiver. 343 o Optional IPv6 LMA Address: the unicast IPv6 address of the LMA. 344 This value is present when the corresponding PBU was sourced 345 from an IPv6 address. 347 o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. 348 This value is present when the corresponding PBU was sourced 349 from an IPv4 address (for IPv4 transport, see [RFC5844]). 351 4.2. Existing mobility options reused. 353 The existing mobility header option, Load Information Mobility Option 354 (see [RFC6463]) can also be used for LMA Register in the Proxy 355 Binding Update from LMA to LMAc, to report priority and key load 356 information of a LMA to LMAc. 358 5. General Operation 360 5.1. Overall Operation 362 5.1.1. LMA Selection on MN Attachment 364 The overall operation procedure of LMA selection on MN attachment is 365 shown in Figure 5: There are three pairs of PBU/PBA messages. The 366 first pair of PBU/PBA is between LMA and LMAc, to register LMA to the 367 LMAc; the second pair of PBU/PBA is between MAG and LMAc, to select 368 the LMA; and the third pair of PBU/PBA is between MAG and selected 369 LMA, to setup the data tunnel for the MN. 371 +-----+ +-----+ +-----+ +------+ 372 | MN | | MAG | | LMAc| | LMA | 373 +-----+ +-----+ +-----+ +------+ 374 | | | PBU | 375 1) | | |<-------------| LMA Registration 376 | | | PBA | 377 2) | | |------------->| PBA to LMA 378 |MN Attachment| | | 379 |------------>| PBU | | 380 3) | |------------>| | LMA Request 381 | | PBA | | 382 4) | |<------------| | Selected LMA 383 | | | | contained 384 | | PBU | 385 5) | |--------------------------->| PBU to LMA 386 | | PBA | 387 6) | |<---------------------------| PBA and setup 388 | | | | data tunnel 389 | |<===========data===========>| 390 | | | | 391 Figure 5 LMA Selection Overall Procedure 393 5.1.2. LMA Re-Selection 395 +-----+ +-----+ +-----+ +------+ +-----+ 396 | MN | | MAG | | LMAc| | LMA1 | |LMA2 | 397 +-----+ +-----+ +-----+ +------+ +-----+ 398 | | | | | 399 | |<===========data===========>| | 400 | | | | | 401 1) | | | LMA1 disappears | 402 | | PBU | | 403 2) | |--------------------------->| | 404 | | | | | 405 3) | TimeOut | | | 406 | | PBU | | | 407 4) | |------------>| | | 408 | | PBA | | | 409 5) | |<------------| | | 410 | | | | | 411 | | | PBU | | 412 6) | |---------------------------------------->| 413 | | | PBA | | 414 7) | |<----------------------------------------| 415 | | | | | 416 | |<==================data=================>| 417 | | | | | 419 Figure 6 LMA Re-Selection Overall Procedure 421 The overall operation procedure of LMA re-selection is shown in 422 Figure 6: When LMA1 goes out-of-service, the MAG enters timeout after 423 sending PBU to LMA1 and waiting for the PBA from LMA1; the MAG 424 requests LMA from LMAc by sending PBU to LMAc, and gets the selected 425 LMA in PBA from LMAc; the data tunnel for the MN is setup after the 426 PBU/PBA message exchange between MAG and LMA2. 428 5.2. LMA Operation 430 The LMA shall report its availability, IP address, priority and key 431 load information to LMAc periodically. 433 5.3. LMAc Operation 435 The LMAc shall receive the availability, IP address, priority and key 436 load information from LMAs and maintain them in its database. 438 The LMAc shall check the availability of the LMA by a timer to 439 receive LMA Update from the LMA. If the timer expires prior to 440 receiving an update message, the LMA is considered unavailable and it 441 shall be removed from the database. 443 The LMAc shall make the decision to select the available LMA for the 444 MN based on priority and load information. 446 The LMAc shall support LMA function in the Runtime LMA Assignment 447 Support for Proxy Mobile IPv6 protocol message [RFC6463], to send the 448 selected LMA to the MAG. 450 5.4. MAG Operation 452 The MAG shall detect the LMA out-of-service when sending a PBU to 453 LMA1 and a timeout occurs while waiting for the PBA from LMA1. 455 The MAG shall support MAG function in the Runtime LMA Assignment 456 Support for Proxy Mobile IPv6 protocol message [RFC6463], to receive 457 the selected LMA from LMAc. 459 6. Protocol Configuration Variables 461 The local mobility anchor MUST allow the following variables to be 462 configured by the system management. The configured values for these 463 protocol variables MUST survive server reboots and service restarts. 465 LMAUpdateReportTimer 466 This variable specifies the time in seconds the local mobility 467 anchor MUST report its availability to LMAc. 469 The default value for this variable is 30 seconds. 471 LMACoordinatorTimeout 473 This variable specifies the time in seconds for the timer in LMAc 474 to check the availability of the LMA, which is cleared to 0 when 475 LMA Update is received from the LMA. If the timer reaches the 476 timeout value, the LMA is considered unavailable, and it shall be 477 removed from the database. 479 The default value for this variable is 60 seconds. 481 7. Security Considerations 483 The security considerations of PMIPv6 signaling described in RFC 5213 484 and RFC 6463 apply to this document. This document assumes that the 485 LMAs, LMAc and MAG that participate in LMA coordination have adequate 486 prior agreement and trust relationships between each other. 488 8. IANA Considerations 490 New mobility options for use with PMIPv6 are defined in the [RFC6275] 491 "Mobility Options" registry. The mobility options are defined in 492 Section 4. 494 9. Acknowledgments 496 The authors would like to thank all participants in EU FP7 User 497 Centric Local Loop (ULOOP) project, www.uloop.eu. 499 10. References 501 10.1. Normative References 503 [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, 504 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 506 [RFC6463] J. Korhonen, S. Gundavelli, H. YoKota, and X. Cui, 507 "Runtime Local Mobility Anchor (LMA) Assignment Support 508 for Proxy Mobile IPv6", RFC 6463, February 2012. 510 [RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support 511 in IPv6", RFC 6275, July 2011. 513 10.2. Informative References 515 [UCN] P. Mendes, W. Moreira, C. Pereira, T. Jamal, A. Bogliolo, 516 H. Haci, and H. Zhu, "Cooperative Networking in User- 517 Centric Wireless Networks", ULOOP Project White Paper 05, 518 September 2012. 520 Authors' Addresses 522 Qing Zhou 523 Huawei Technologies Dusseldorf GmbH 524 Carnotstr 4, Berlin, 10587 525 Germany 527 Email: zhouqing@huawei.com 529 Sebastian Peters 530 DAI Labor, Technische Universit?t Berlin 531 Ernst-Reuter-Platz 7, Berlin, 10587 532 Germany 534 Email: Sebastian.Peters@dai-labor.de 536 Fikret Sivrikaya 537 DAI Labor, Technische Universit?t Berlin 538 Ernst-Reuter-Platz 7, Berlin, 10587 539 Germany 541 Email: fikret.sivrikaya@dai-labor.de 543 Rute Sofia 544 COPELABS, University Lusofona Campus 545 Building U, First Floor 546 Campo Grande 388, Lisboa, 1749-024 Lisboa 547 Portugal 549 Email: rute.sofia@ulusofona.pt