idnits 2.17.1 draft-luo-dmm-pmip-based-dmm-approach-02.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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 29, 2013) is 3922 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) -- Looks like a reference, but probably isn't: '5213' on line 508 -- No information found for draft-ietf-netext-pmip-lr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-netext-pmip-lr' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 6097 ** Downref: Normative reference to an Informational RFC: RFC 6279 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Luo 3 Internet-Draft J. Liu 4 Intended status: Standards Track ZTE 5 Expires: January 30, 2014 July 29, 2013 7 PMIP Based DMM Approaches 8 draft-luo-dmm-pmip-based-dmm-approach-02 10 Abstract 12 Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility 13 management for mobile nodes (MN). For supporting Distributed 14 Mobility Management based on current PMIP standard, enhanced Proxy 15 Mobile IPv6 (ePMIP) with two new logic functions is introduced. (1) 16 Location Management Function (LMF), (2) Distributed Anchoring 17 Function (DAF), including Distributed Routing sub-Function (DRF) and 18 Distributed Mobility sub-Function (DMF). Basic signalling procedures 19 and considerations are also described in this document. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 30, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 63 3. Overview of Ehanced Porxy Mobile IPv6 . . . . . . . . . . . . 3 64 3.1. Ehanced PMIP Networking Schematic . . . . . . . . . . . . 4 65 3.2. Functions of eMAG . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Functions of eLMA . . . . . . . . . . . . . . . . . . . . 5 67 4. Overview of ePMIP Approaches . . . . . . . . . . . . . . . . 6 68 4.1. Initial Registration . . . . . . . . . . . . . . . . . . 6 69 4.2. Optimized Routing . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Handoff when Optimaized Routing is Established . . . . . 9 71 4.4. Multiple eLMAs Consideration . . . . . . . . . . . . . . 11 72 4.4.1. Determining eLMA Based on Configuration . . . . . . . 11 73 4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options 74 Header . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.4.3. Determining eLMA Based on Interface Between eLMAs . . 13 76 5. CN Considerations . . . . . . . . . . . . . . . . . . . . . . 14 77 5.1. CN Which is not Registered with eLMA . . . . . . . . . . 14 78 5.2. Routing Optimization Considerations when the CN is a 79 Fixed Node . . . . . . . . . . . . . . . . . . . . . . . 15 80 6. Handoff between eMAG and MAG . . . . . . . . . . . . . . . . 16 81 7. Considerations for Other Implementation . . . . . . . . . . . 17 82 7.1. One Alternative Implementation . . . . . . . . . . . . . 17 83 7.2. Optimized Routing Consideration . . . . . . . . . . . . . 18 84 7.3. Correspondent Node Consideration . . . . . . . . . . . . 18 85 7.4. Location Management Consideration . . . . . . . . . . . . 19 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 9. Difference with Localized Routing . . . . . . . . . . . . . . 21 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 91 11.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 Centralized mobility anchoring has several drawbacks such as single 98 point of failure, routing in a non optimal route and etc. which are 99 discussed in [I-D.draft-ietf-dmm-requirements]. For supporting 100 Distributed Mobility Management to eliminate those drawbacks, 101 enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions based 102 on PMIP ([RFC5213]) is introduced in this document . (1) Location 103 Management Function (LMF), maintaining the mappings between IP 104 addresses and location information of mobile nodes. (2) Distributed 105 Anchoring Function (DAF), including Distributed Routing sub-Function 106 (DRF) which enables optimized routing between mobile node and its 107 correspondent node and Distributed Mobility sub-Function (DMF) which 108 guarantees mobile node's mobility with minimal packet loss when 109 optimized routing is established. 111 DAF can be deployed in [RFC5213]specified MAG to constitute an eMAG, 112 and LMF can be deployed in [RFC5213] specified LMA to constitute an 113 eLMA. This document intends to provide approaches for eliminating 114 those drawbacks by means of allowing mobile node can change its 115 traffic anchor point dynamically. Besides, Distributed Mobility 116 Management approaches are considered not only for communication 117 between two mobile nodes, but also for communication between a mobile 118 node and a fixed node (section 5.2). Further, an alternative 119 implementation is also considered in section 7. 121 2. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119 [RFC2119]. 127 3. Overview of Ehanced Porxy Mobile IPv6 129 For supporting Distributed Mobility Management discussed in [I-D 130 DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions 131 is introduced in this document . (1) Location Management Function 132 (LMF), maintaining the mappings between IP addresses and location 133 information of mobile nodes (perhaps location information of fixed 134 nodes are also included). (2) Distributed Anchoring Function (DAF), 135 including Distributed Routing sub-Function (DRF) which enables 136 optimized routing between mobile node and its correspondent node and 137 Distributed Mobility sub-Function (DMF) which guarantees the mobile 138 node's mobility when optimized routing is enabled. 140 3.1. Ehanced PMIP Networking Schematic 142 Prefix A Prefix B Prefix C+D Prefix X 143 \ | / \ | / \ | / | \ | / 144 \ | / \ | / \ | / | \ | / 145 eLMA1 eLMA2 eLMA3 | LMA 146 | 147 ( )( )( ) ( ) ( )|( ) 148 ( area1 )( area2 )( area3 ) ( area4 )...( arean )|( arean+1) 149 ( )( )( ) ( ) ( )|( ) 150 ( eMAG1 )( eMAG2 )( eMAG3 ) ( eMAG4 )...( eMAGn )|( MAG ) 151 | | 152 | | +-----+ 153 | | | CN2 | 154 MN1 CN1 +-----+ 156 PMIP Domain with ePMIP deployed 158 Figure 1. RFC[5213] specified PMIP Domain with ePMIP deployed 160 The ePMIP can be implemented in many ways. One is to extend Location 161 Management Function in [RFC5213] specified Local Mobility Anchor 162 (i.e. legacy LMA) and to extend Distributed Anchoring Function in 163 [RFC5213] specified Mobile Access Gateway (i.e. legacy MAG). Legacy 164 LMA with LMF is called as enhanced local mobility anchor (eLMA), and 165 legacy MAG with DAF is called as enhanced mobile access gateway 166 (eMAG) respectively in the context of this document. 168 Figure 1 illustrates a possible deployment for ePMIP, in which ePMIP 169 is deployed within a PMIP domain. Mechanism specified by the ePMIP 170 is enabled automatically for a mobile node when it attaches to an 171 eMAG and without any of its awareness, therefore there is no 172 additional requirement for a IPv6 mobile node. For fixed node 173 considerations, please refer to section 5.2. 175 Clear boundary between ePMIP and PMIP is not necessary, however, 176 deploying ePMIP in a continuous area is preferred. Distributed 177 mobility management approaches will be applied only when 178 correspondent node of this mobile node also attaches to an entity 179 which supports at least DRF (e.g. an eMAG), otherwise [RFC5213] 180 specified PMIP (say legacy PMIP) approaches will be applied (for more 181 details, refer to section 5). For supporting distributed mobility 182 management approaches, new signalling messages among the LMFs and 183 DAFs are also proposed in this draft. 185 For other implementation considerations, please refer to section 7. 187 3.2. Functions of eMAG 189 The eMAG is fully compatible with legacy MAG with limited additional 190 functions which are included in the distributed anchoring function. 191 The general considerations of the eMAG (DAF is a part of eMAG) are 192 described as following: 194 - If eMAG decides to route traffic from its attached mobile node in 195 an optimized way, it should invoke the Distributed Anchoring Function 196 (DAF), more specifically, the Distributed Routing Function (DRF), to 197 enable distributed mobility management approaches. 199 - Optimized routing is realized by a direct tunnel between two DRFs 200 of mobile node and its correspondent node. DRF is responsible for 201 maintaining location information of mobile node's correspondent node. 203 - If correspondent node also attaches to an eMAG and is registered 204 with an eLMA, the direct tunnel is established between two eMAGs and 205 tunnel endpoints are IP addresses of these two eMAGs (or CoAs of 206 these two communicating peers). For other scenarios, e.g. the 207 correspondent node is a fixed node, refer to section 5. 209 - Optimized routing can only be enabled when location of 210 correspondent node is determined. In case the location cannot be 211 determined locally, DRF should initiate a query approach with a 212 corresponding LMF. In case DRF is informed with the location (could 213 be CN's new location in handoff scenario), it should update the 214 location locally and forward any follow-up traffic based on that 215 location. In case location of correspondent node cannot be 216 determined by any means, common routing (e.g. PMIP routing) mechanism 217 should be used. 219 - For supporting mobile node's handoff from previously attached eMAG 220 (p-eMAG) to newly attached eMAG (n-eMAG), Distributed Mobility 221 Function (DMF) of both eMAGs shall be enabled. The responsibility of 222 n-DMF (n-eMAG) is to inform p-DMF (p-eMAG) with new location of that 223 mobile node during handoff. The responsibility of p-DMF (p-eMAG ) is 224 to forward any received traffic which designated to that mobile node 225 from DRF of correspondent node to n-DMF (n-eMAG ) and to inform the 226 DRF with new location for session continuity. 228 3.3. Functions of eLMA 230 The eLMA is fully compatible with legacy LMA with limited additional 231 functions which are included in the Location Management Function. 232 The general considerations of the eLMA (LMF is a part of eLMA) are 233 described as following: 235 - The responsibility of LMF is to determine the location of a 236 specified mobile node (perhaps a fixed node, please refer to section 237 5) identified by its IP address (e.g. HoA) when it is queried by DRF. 238 Interface between LMFs for determining the location information is 239 proposed, for other alternatives, please refer to section 4.4. 241 - The location information of a mobile node can be its CoA, and 242 mechanisms for maintaining the mapping of mobile node's IP address 243 and its location information (i.e. HoA-CoA correlation) can be based 244 on Binding Cache Entry (BCE) which is specified in [RFC5213]. 246 4. Overview of ePMIP Approaches 248 As described above, one implementation of ePMIP is to deploy LMF with 249 legacy LMA to constitute an eLMA, and deploy DAF (including DRF and 250 DMF sub-functions) with legacy MAG to constitute an eMAG. The 251 sections including section 4 to 6 assume ePMIP adopts this 252 implementation. Considerations for other alternative 253 implementations, please refer to section 7. 255 The overall assumptions for section 4 are as following: 257 - The correspondent node is also a mobile node which attaches to an 258 eMAG and is registered with an eLMA. 260 For other scenarios, such as correspondent node is a fixed station or 261 not registered with an eLMA, please refer to section 5. 263 4.1. Initial Registration 265 The initial registration procedure for ePMIP is triggered when a 266 mobile node is initialized and attaches to an access link on which 267 there is an eMAG. The most likely procedures for initial 268 registration are identical with those specified in [RFC5213]. 270 When determining the mobile node is authorized for the network-based 271 mobility management service, eMAG sends PBU to a selected eLMA for 272 the mobile node to complete the registration. General, an eLMA is 273 always preferred for the mobile node, unless there has other 274 constraints. 276 For example, If the mobile node's policy profile includes a filed of 277 mobile node's IPv6 home network prefix(es) assigned to the mobile 278 node's connected interface, and if the HNP(es) is(are) managed by a 279 legacy LMA, the eMAG shall send a PBU to that LMA. In this case, the 280 eMAG shall act as a legacy MAG for this mobile node which means the 281 DAF function in this eMAG shall be disabled for this mobile node. 283 When initial registration with eLMA is completed, the mobile node 284 gets its HNP(es) and eLMA creates a binding cache entry for this 285 mobile node to maintain the mapping of this mobile node's HNP(es) and 286 Proxy-CoA. 288 4.2. Optimized Routing 290 As described in section 3.2, ePMIP leverages a direct tunnel between 291 two eMAGs which are implemented with DRF to realize an optimized 292 routing between mobile node and its correspond node. The effect is 293 similar with the MAG-MAG tunnel specified in 294 [I-D.ietf-netext-pmip-lr] but the principle is different, refer to 295 section 9 for more information. 297 +-----+ +--------+ +-------+ +--------+ +-----+ 298 | MN1 | | eMAG1 | | eLMA | | eMAG4 | | MN2 | 299 +-----+ +--------+ +-------+ +--------+ +-----+ 300 | | | | | 301 | 1.Attach and PMIP Reg. | 1.Attach and PMIP Reg. | 302 |<------------|----------->|<------------|------------>| 303 | | | | | 304 |2.uplink Data| | | | 305 |============>| 3. PBQR | | | 306 | |----------->| | | 307 | | 4. PBQA | | | 308 | |<-----------| | | 309 | +------------------+ | | | 310 | | 5.Record Location| | | | 311 | | of MN2 | | | | 312 | +------------------+ | | | 313 | | 6.uplink data in tunnel | | 314 | |=========================>| | 315 | | | |7.uplink data| 316 | | | |============>| 317 | | 8. Ongoing traffic | | 318 |<===========>|<========================>|<===========>| 319 | | | | | 321 Figure 2. Optimized Routing 323 Figure 2 illustrates data delivery approaches of ePMIP for 324 Distributed Mobility Management. Except for the general assumptions 325 applied for section 4, two more assumptions are also applied as 326 following: 328 - Mobile nodes (MN1 and MN2) attach to different eMAGs (eMAG1 and 329 eMAG4) respectively. 331 - Mobile nodes are registered with a same eLMA. 333 For other scenarios, such as mobile nodes are registered with 334 different eLMAs, refer to section 4.4. 336 After the initial registration, both mobile nodes get their HNPes. 337 And eLMA maintains the mappings of HNP(es) and Proxy-CoAs of both 338 mobile nodes in binding cache entries for them respectively . 340 The communication between MN1 and MN2 is initiated by MN1 sending IP 341 packets to MN2 (i.e. uplink traffic). The destination IP address of 342 the uplink traffic is set to HoA of MN2. Upon receiving the initial 343 uplink traffic, eMAG1 should determine whether an optimized routing 344 can be established by the support of DRF on it. 346 The eMAG1 (DRF) should determine whether it holds the location (i.e. 347 CoA) of MN2 locally first. If not, eMAG1 (DRF) should determine the 348 location by initiating a query (i.e. sending a PMIP Binding Query 349 Request, PBQR) to eLMA (LMF) who holds the BCE for MN2. Based on HNP 350 of MN2 provided in the PBQR, eLMA (LMF) could derive the location of 351 MN2 (i.e. CoA) in a corresponding BCE and responses eMAG1 (DRF) with 352 an answer (i.e. sending a PMIP Binding Query Answer, PBQA) carrying 353 the location information. Upon receiving the PBQA, eMAG1 (DRF) 354 records the location of MN2 locally. 356 Upon the location of MN2 is determined, eMAG1 (DRF) sets up its 357 endpoint of a tunnel (e.g. IP in IP tunnel) to eMAG2 (DRF). And all 358 follow-up uplink traffic will be encapsulated by eMAG1 (DRF) and sent 359 to eMAG4 (DRF) in the established tunnel directly. 361 Before the optimized routing is established, eMAG1 could forward the 362 first few packets of the uplink traffic to eLMA via bi-directional 363 PMIP tunnel between the two as specified by legacy PMIP. In this 364 case, the routing of the first few packets is non-optimized, and the 365 delay of those packets may be a litter bit larger than the follow-up 366 traffic. Another alternative is that eMAG1 buffers those packets 367 until the optimized routing is set up. In this case, how to 368 determine capacity of the buffer should be carefully considered. 370 Upon receiving encapsulated packet in the eMAG-eMAG tunnel, the eMAG4 371 (DRF) needs to decapsulate the packet and forwards the uplink traffic 372 to MN2. As an alternative, eMAG4 (DRF) may parse the packet and 373 record the location of MN1. The location of MN1 can be derived from 374 the outer IP header of the encapsulated packet (i.e. the IP address 375 of the tunnel entry point). 377 Upon receiving downlink traffic from MN2 to MN1, eMAG4 (DRF) should 378 also set up its endpoint of a tunnel to eMAG1 (DRF) for the downlink 379 traffic when the location of MN1 is determined. At this moment, a 380 bi-directional tunnel between two eMAGs has been established for all 381 follow-up uplink and downlink traffic and an optimized routing for 382 MN1 and MN2 is set. 384 4.3. Handoff when Optimaized Routing is Established 386 MN1 may change its point of attachment from previously attached eMAG 387 (p-eMAG) to newly attached eMAG (n-eMAG) at any time after the 388 optimized routing has been established as described in section 4.2. 389 The routing shall still be remained optimized after handoff. 391 [I-D.ietf-netext-pmip-lr] also specifies a method for re-establishing 392 optimized routing after the handoff which leverages another new 393 trigger from LMA to both MAGs involved. The consequence is to make 394 the routing non-optimized during the handoff, and optimized again 395 after the handoff. The handoff approach specified here is much 396 different from [I-D.ietf-netext-pmip-lr] specified approach and may 397 provide less latency and jitter. 399 +---+ +--------+ +--------+ +-------+ +--------+ +---+ 400 |MN1| | p-eMAG | | n-eMAG | | eLMA | | eMAG4 | |MN2| 401 +---+ +--------+ +--------+ +-------+ +--------+ +---+ 402 | | | | | | 403 | | 1. Ongoing traffic | | 404 |<==========>|<==================================>|<=========>| 405 | | | | | | 406 | | 2.attach and PMIP Reg. | | | 407 |<----------------------->|<--------->| | | 408 | | 3.PBCI | | | | 409 | |<-----------| | | | 410 | | 4.PBCA | | | | 411 | |----------->| | | | 412 | 5. Uplink traffic | | | | 413 |========================>| | | | 414 | | +-----------------+ | | | 415 | | | 6.Determine the | | | | 416 | | | Location of MN2 | | | | 417 | | +-----------------+ | | | 418 | | | | | | 419 | | +--------------------------------------------+ 420 | | | 7. Process of uplink traffic is similar | 421 | | | with the approaches in figure 2 | 422 | | +--------------------------------------------+ 423 | | | | | | 424 | | | 8 . Downlink Traffic | | 425 | |<===================================|<==========| 426 | |===========>| | | | 427 |<========================| | | | 428 | | | 9. PBCI | | | 429 | |----------------------------------->| | 430 | | | | +----------------+ | 431 | | | | | 10. Update | | 432 | | | | | Location of MN1| | 433 | | | | +----------------+ | 434 | | | 11. PBCA | | | 435 | |<-----------------------------------| | 436 | | 12. Ongoing Downlink Traffic | | 437 |<========================|<======================|<==========| 438 | | | | | 440 Figure 3. Handoff When Optimized Routing is Established 442 Figure 3 illustrates approach for handoff of MN1 from p-eMAG to 443 n-eMAG. During handoff, legacy PMIP specified procedure is performed 444 for MN1 to maintain its HNP(es) unchanged. The n-eMAG on new access 445 link, upon detecting MN1 on the link, assigns a new CoA for MN1 and 446 generates a PBU message to eLMA for updating the BCE for MN1. In 447 sequence, eLMA responses a PBA message to n-eMAG with one additional 448 new extension which includes the previous location of MN1 (i.e. CoA 449 of MN1 assigned by p-eMAG). 451 Further, n-eMAG (DMF) initiates an inform message (i.e. PMIP Binding 452 Change Inform, PBCI) to p-eMAG (DMF) with new location of MN1 (i.e. 453 CoA assigned by n-eMAG) based on the acquired previous location of 454 MN1. Sequencely, p-eMAG (DMF) updates the location of MN1 and 455 responses with an acknowledge message (i.e. PMIP Binding Change Ack, 456 PBCA) with all location information of the MN1's current 457 correspondent nodes (in figure3, the current correspondent node is 458 only MN2). 460 Upon uplink traffic arriving at n-eMAG instead of p-eMAG, n-eMAG 461 (DRF) can derive the location of MN2 locally and forwards the traffic 462 in an optimized way of routing (i.e. MN1->n-eMAG->eMAG4->MN2). 464 The most likely is that downlink traffic during the handoff is still 465 forwarded by eMAG4 (DRF) to p-eMAG (DRF) before location of MN1 466 stored in eMAG4 (DRF) locally is updated (i.e. 467 MN2->eMAG4->p-eMAG->MN1) and is discarded by p-eMAG (DRF). 469 For reducing packet loss, p-eMAG (DMF) is proposed to establish a 470 directional tunnel to n-eMAG (DMF) and forward any received downlink 471 traffic to n-eMAG (DMF) via the tunnel. Meanwhile, p-eMAG (DMF) is 472 also proposed to update the location of MN1 stored in eMAG4 (DRF) by 473 initiating a PBCI to eMAG4 (DRF) to indicate eMAG4 (DRF) to forward 474 follow-up downlink traffic to n-eMAG (DRF) directly: 475 MN2->eMAG4->n-eMAG->MN1. 477 4.4. Multiple eLMAs Consideration 479 As illustrated in figure 1, multiple eLMAs can be deployed. The most 480 likely is that the mobile node and its correspondent node (i.e. 481 another mobile node) are registered with different eLMAs. The 482 approaches described in subsection 4.2 and 4.3 simply assume both 483 mobile nodes are registered with the same eLMA (the same assumption 484 applied to [I-D.ietf-netext-pmip-lr]), and this section considers 485 multiple eLMAs. 487 Announce PA Announce PB Announce PC and PD 488 \ | / \ | / \ | / 489 \ | / \ | / \ | / 490 +--------+ +--------+ +--------+ 491 | eLMA1 | | eLMA2 | | eLMA3 | 492 +-----+--+ +--------+ +---+----+ 493 | _______________| 494 / | 495 +---+----+ +----+---+ 496 | eMAG1 | | eMAG2 | 497 +---+----+ +---+----+ 498 | | 499 +--+-+ +-+--+ 500 | MN1| | MN2| 501 +----+ +----+ 503 Figure 4. Mobile node and its Correspondent Node are Registered with 504 Different eLMAs 506 As illustrated in figure 4, MN1 is registered with eLMA1 by eMAG1, 507 and MN2 is registered with eLMA3 by eMAG2 respectively. Based on 508 RFC[5213], only the LMA which is involved in PMIP registration for a 509 mobile node holds this mobile node's Binding Cache Entry. Therefore, 510 in figure 4, only eLMA1 holds the location information of MN1 and 511 only eLMA3 holds the location information of MN2. 513 As described in section 4.2, before establishing optimized routing 514 for the traffic, eMAG1 shall determine the location of MN2. In case 515 the location can not be determined locally, eMAG1 shall determine to 516 which eLMA it should send a PBQR message. 518 4.4.1. Determining eLMA Based on Configuration 519 As illustrated in figure 4, each eLMA manages a set of IPv6 prefixes 520 with which it uses to allocate home network prefixes or HoAs to the 521 MNs registered to that eLMA. For example, eLMA1 announces prefixes 522 PA to routing system and eLMA3 announces prefixes PC+PD. 524 If eMAGs could be aware of the IPv6 prefixes configurations of each 525 eLMA, e.g. from operator's management plane since they are in a same 526 administrative domain. The eMAG (DRF) can determine the 527 corresponding eLMA (LMF) to which it should send the PBQR, based on 528 the destination IPv6 address of the traffic and the configured 529 information. 531 For example, the destination IP address of the traffic from MN1 to 532 MN2 is MN2's HoA. Based on configuration information, eMAG1 (DRF) 533 can determine the HNP of MN2 is prefix PC and is managed by eLMA3. 534 Therefore, eMAG1 (DRF) can determine the eLMA3 (LMF) should be 535 queried when it wants to determine the location of MN2. 537 This solution looks simple, but it depends on static configured 538 information on every eMAGs. If configuration of a eLMA is changed 539 (e.g. add a prefix PE into eLMA1's IPv6 prefix set), the most likely 540 is that the configured information in all eMAGs in same 541 administrative domain needs update. It seems like that this solution 542 works well for a administrative domain with small number of eMAGs. 544 4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options Header 546 Announce PA Announce PB Announce PC and PD 547 \ | / \ | / \ | / 548 \ | / \ | / \ | / 549 eLMA1 eLMA2 eLMA3 550 + 551 /!\ 552 ,------- Router1-------- Router2 .| 553 | 554 | 555 eMAG1 557 eMAG1 initiates a query message (PBQR) carried in a IP 558 packet whose destination IP address is HoA of MN2. 559 The packet will be intercepted, processed and terminated by 560 eLMA3 who manages the prefix of the MN2's HoA based on 561 the mechanism of the Hop-by-Hop Option Header. 563 Figure 5. Determining eLMA Based on Hop-by-Hop Options Header 564 When constructing a PBQR message, eMAG1 can use HoA of MN2 as 565 destination IP address of this message and construct an appropriate 566 IPv6 Hop-by-Hop Option Header as extension header ([RFC2460]). The 567 HoA of MN2 is the destination IP address of the uplink traffic. 569 When IP packet which includes the PBQR message is sent into the 570 routing system, standard routing mechanism ensures the packet can 571 reach eLMA3 which manages the prefix of MN2's HoA. Depending on the 572 mechanism of the Hop-by-Hop Option Header, each router including 573 eLMA3 on the routing pass of this packet will intercept the packet 574 and check the Hop-by-Hop Option Header. 576 Based on the indication carried by the options in Hop-by-Hop Option 577 Header, eLMA3 determines whether the prefix of destination IP address 578 belongs to its management. If it does, eLMA3 shall treat itself as 579 destination of this message and let the LMF on it process the 580 message. 582 It seems like that, all common routers on the routing pass of this 583 packet will check the Hop-by-Hop Option Header and may cause some 584 delay. Another disadvantage is that it will take relative longer 585 time to make sure no location information of correspondent node can 586 not be determined (refer to section 5.1 for more details). 588 4.4.3. Determining eLMA Based on Interface Between eLMAs 590 +-----------------------------+ 591 | eLMA2 | 592 | | 593 | eLMA1--------------> eLMA3 | 594 | /|\ further query | 595 +-----+-----------------------+ 596 | 597 query | 598 | 599 eMAG1 601 Figure 6. Determining eLMA Based on Interface Between eLMAs 603 Interface between eLMAs which are located in a same administrative 604 domain is introduced for determining location information of a 605 particular mobile node. 607 When determining location of correspondent node, eMAG1 (DRF), in 608 figure 6, could simply send a PBRQ message to any random eLMA (LMF) 609 it considers convenient (e.g. eLMA1). The most likely is that the 610 eLMA (LMF) queried does not hold the relevant location information. 612 But the eLMA (LMF) can determine which eLMA (LMF) holds the 613 information (e.g. eLMA3). 615 For example, if IPv6 prefixes managed by each eLMA are awared of, the 616 eLMA1 (LMF) can determine which eLMA (LMF) should be queried further 617 and query it. It can be expected that the number of eLMA deployed in 618 a administrative domain will not be large (as illustrated in figure 619 1), therefore, depending on configuration is applicable. 621 5. CN Considerations 623 The assumption of section 4 is that the correspondent node is also a 624 mobile mode and is registered with eLMA by eMAG. Other scenarios, 625 such as correspondent node is a fixed node, or a mobile node but is 626 not registered with eLMA, are considered in this section. 628 5.1. CN Which is not Registered with eLMA 630 This section considers scenario that the correspondent node (e.g. 631 CN2 in figure 1) is a mobile node but not registered with eLMA. For 632 example, CN2 is registered with a legacy LMA by attaching to a legacy 633 MAG. For another example, CN2 just locates in common IPv6 634 environment. 636 When mobile node (MN1 in figure 1) initiates uplink traffic to 637 correspondent node (CN2 in figure 1), eMAG1 (DRF) to which MN1 638 attaches should initiate a query for determining location of CN2 as 639 described in section 4.2. 641 According to section 4.4.1, eMAG1 (DRF) can not determine to which 642 eLMA (LMF) it should send the query message, because CN2's prefix is 643 out of the management of any eLMA. In this case, eMAG1 (DRF) can 644 make sure no location information can be determined. 646 According to section 4.4.2, eMAG1 (DRF) should construct a query 647 message and set message's destination to IP address of CN2. The 648 query message will be routed to CN2 based on common routing mechanism 649 and no response is excepted. The eMAG1 (DRF) should wait for the 650 response until the related timer is timeout. Before eMAG1 (DRF) can 651 make sure no location information can be determined, one or more 652 query message may be re-sent by eMAG1 (DRF). Thus, it will take a 653 relative longer time to make sure no location information can be 654 determined. 656 According to section 4.4.3, eMAG1 (DRF) can send a query message to 657 any one of those eLMAs (LMF) and the eLMA (LMF) queried performs the 658 query among those eLMAs (LMF). In this case, eMAG1 (DRF) can make 659 sure no location information can be determined. 661 As described above, the failed queries are excepted and location 662 information of CN2 can not be determined by eMAG1 (DRF). In this 663 case, eMAG1 should behavior as a legacy MAG for this session and PMIP 664 specified routing mechanism shall be applied for the uplink traffic 665 (i.e. no optimized routing), e.g. MN->eMAG1->E-LMA->common 666 router->CN. 668 Of course, if the correspondent node itself is a fixed node, same 669 rules described above are also applicable. 671 5.2. Routing Optimization Considerations when the CN is a Fixed Node 673 As described above, if correspondent node is a fixed node, eMAG1 will 674 behavior as a legacy MAG and no optimized routing is enabled. 676 Most of correspondent nodes which are fixed nodes are deployed in a 677 centralized manner in most deployment, e.g. CDN/IDC/Web Servers and 678 etc. Those fixed nodes are generally converged by a couple of access 679 routers, although the topology within those fixed nodes may be very 680 complicate, to access operator's IP bearer network which is 681 illustrated in figure 7. If mechanism which providing optimized 682 routing cannot be applied when correspondent node are fixed nodes of 683 these kind, effect of this mechanism will be very limited. 685 __________ 686 / CN \ ,--------. 687 ((CDN\IDC\Web )---Access Router `. _.----------. 688 ( Server) ) ,--' `-'' eLMA : 689 \___________/ \ _.-------. ,--' 690 '-- eMAG-----'' `---' 691 | 692 | 693 MN1 695 Figure7. Correspondent Nodes are Fixed Nodes Cause Non-optimized 696 Routing 698 Refer to figure 7, it seems like that non-optimized routing (e.g. 699 between MN1 and CDN) will be a problem for this deployment as 700 discussed in [I-D DMM Problem Statement]. For purpose of eliminating 701 non-optimized routing, one implementation is to replace those common 702 access routers in figure 7 with routers which are implemented with 703 Distributed Routing Function (DRF). No Distributed Mobility Function 704 (DMF) is needed, since nodes attached are all fixed nodes. 706 ,-------. 707 ,' `-. 709 ( CDN\IDC\Web )-. _.----. 710 ( Server ) \ ,--_.--'' `-. 711 \____________' AR+DRF-' `-------. 712 ,-----------. / -. \ 713 ; Fixed User : ,' `- \ 714 : Equipments ;---AR+DRF ----LMF eLMA : 715 `-----------' \ ,- ; 716 AR+DRF--' ,----. ; 717 ,-----------. / `\ eMAG `--. ; 718 ; Fixed User : / -------------' | `-----' 719 : Equipments ;/ | 720 `-----------' | 721 | 722 MN1 724 Figure 8. Applying Optimized Routing when Correspondent Nodes are 725 fixed nodes 727 Additionally, one more LMF needs deployed as illustrated in figure 8. 728 The responsibility of that LMF is to response any received PBRQ 729 message with location of queried fixed node (e.g. IP address of one 730 of those AR+DRF). Method specified in section 4.2.2 may not be 731 applicable, because PBRQ will be routed to one of those AR+DRF 732 directly. No response will be expected, except that the AR+DRF is 733 also co-located with a LMF. 735 6. Handoff between eMAG and MAG 737 As illustrated in figure 1, ePMIP is deployed in PMIP domain (no 738 clear boundary), and belongs to a same administrative domain, e.g. a 739 same operator. The mobile node which is initial registered with eLMA 740 by attaching a eMAG may handoff to a legacy MAG and vice versa. By 741 supporting the handoff between eMAG and MAG , ePMIP can be deployed 742 in manner of incremental when assuming PMIP is well deployed. 744 As described above, eLMA is a legacy LMA implemented with LMF, and 745 eMAG is a legacy MAG implemented DAF (DRF+DMF). When a mobile node 746 which attaches to an eMAG handoff to a legacy MAG, the legacy MAG 747 will perform PMIP registration to the eLMA and establish a bi- 748 directional tunnel with the eLMA. In this case, PMIP routing 749 mechanism will be applied (i.e. no routing optimization). On the 750 other hand, when a mobile node which attaches to a legacy MAG handoff 751 to an eMAG, the eMAG will perform PMIP registration to the legacy LMA 752 and establish a bi-directional tunnel with the legacy LMA. In this 753 case, PMIP routing mechanism will also be applied (i.e. no routing 754 optimization). 756 7. Considerations for Other Implementation 758 As described in section 3.1, ePMIP can be implemented in many ways. 759 Section 3.1 also indicates one of those implementations, i.e. 760 deploying LMF in legacy LMA, and DAF in legacy MAG. This section 761 considers one alternative implementation. 763 7.1. One Alternative Implementation 765 One alternative implementation is to deploy DAF in legacy LMA, and 766 deploy LMF independently. When multiple LMFs are deployed, 767 interfaces between those LMFs are necessary as illustrated in figure 768 10. 770 _.---------------------. 771 ,---'' LMF2 `--- , 772 ,' _..-'' ``-.._ ; 773 ,-' LMF1 --------- LMF3 \ 774 / : Prefix ePMIP 775 / ( area1 )( area2 )( area3 )...( arean ) | / 776 | ( )( )( ) ( ) ; / ( arean+1) 777 : ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) BG+DRF --- ( ) 778 \ | | | / \ ( LMA ) 779 `-----+. | _.----+--ePIMP Area-----' \ | 780 | `------|' | | 781 | | | | 782 MAG1 MAG2 MAG3 MAG 783 | | 784 MN1 CN1 786 Figure 10. One Alternative Implementation of ePMIP 788 For routing consideration, a clear boundary seems necessary if ePMIP 789 takes this kind of implementation. A set of IPv6 prefixes which are 790 used for allocating HNP(es) or HoA(s) to mobile nodes should be 791 assigned to ePMIP area and each LMA manages part of them. The eLMAs 792 don't announce any IPv6 prefix to routing system. Instead, a border 793 gateway implemented with DRF (BG+DRF) which is located at the 794 boundary of this ePMIP area announces those set IPv6 prefix(es) to 795 outside as illustrated in figure 10. 797 The node inside ePMIP area could be a mobile node or a fixed node. 798 When a correspondent node located outside of ePMIP area sends IP 799 traffic to a node located inside ePMIP area, traffic will be routed 800 to BG+DRF which announces the management of the prefix of the 801 traffic's destination IP address. 803 7.2. Optimized Routing Consideration 805 Consider that a mobile node (MN1) is initiated in ePMIP area and 806 attaches to a legacy MAG, legacy PMIP registration procedures will be 807 performed. The MAG will select a local mobility anchor (e.g. eLMA1) 808 for MN1 and send a PBU to it. Note that, the LMA selected by the MAG 809 is actually an eLMA. MAGs cannot tell the distinguishes between LMAs 810 and eLMAs. 812 After successful PMIP registration, MN1 acquires its HNP(es) and 813 eLMA1 manages a binding cache entry for MN1 as specified by legacy 814 PMIP. Further, eLMA1 (DRF) has to inform a corresponding LMF with 815 the HNP(es) and location information of MN1 (i.e. IP address of eLMA1 816 itself). LMF will manage the mapping between HNP(es) and location. 817 How to determine which LMF the eLMA1 (DRF) should inform, refer to 818 section 7.4. 820 Consider that correspondent node (CN1) of MN1 is also a mobile node 821 and is located in same ePMIP area (refer to section 7.3 for other 822 scenarios). 824 Upon receiving uplink traffic from MN1 to CN1 via the bi-directional 825 PMIP tunnel, eLMA1 (DRF) should determine whether it holds location 826 information of CN1 locally. If not, a corresponding LMF should be 827 queried by eLMA1 (DRF), and the required location (e.g. IP address of 828 eLMA3) should be stored by eLMA1 (DRF) locally. Upon determining the 829 location, eLMA1 (DRF) sets up a tunnel to eLMA3 (DRF) by using the 830 location of CN1 as tunnel endpoint, and forwards uplink traffic to 831 eLMA3 (DRF) directly. 833 Upon movement of MN1, a PMIP handoff from pMAG to nMAG will be 834 triggered. [RFC6097] provides a mechanism for LMA discovery, and 835 requires nMAG of a mobile node should discovery a same LMA with which 836 the pMAG has discovered for that mobile node. The nMAG in this draft 837 does not have to discover a same eLMA (i.e. eLMA1) but a best eLMA 838 (e.g. eLMA2) for MN1 and performs PMIP registration. The 839 implementation can take any method specified in [RFC6097] for 840 discovering the best eLMA. 842 The eLMA2 (DRF) should update LMF with new location information of 843 MN1 (e.g. IP address of eLMA2 itself) and eLMA2 (DMF) should also 844 inform eLMA1 with the new location. The approaches are quite similar 845 with those described in section 4.3. 847 7.3. Correspondent Node Consideration 849 The correspondent node may be located outside of ePMIP area (could be 850 a mobile node or a fixed node). In this case, the prefixes or IP 851 address of CN are not managed by ePMIP. Actually, the set of IPv6 852 prefixes which are assigned to ePMIP can be configured in LMF. In 853 this case, when eLMA1 (DRF) queries LMF CN's location, the LMF will 854 response with IP address of BG+DRF. The routing will be: MN1 <-> MAG 855 <-> eLMA <->BR+DRF <-> CN. 857 In the case of the correspondent node is a fixed node and is located 858 inside ePMIP area, it seems like that the traffic from CN to MN1 859 cannot be routed correctly, because CN doesn't have any idea of MN1's 860 location. 862 A simple approach is to let BG+DRF also announce the set of prefixes 863 which are assigned to ePMIP to routing system in ePMIP area. In this 864 case, traffic will be routed to BG+DRF and further forwarded by 865 BG+DRF. But it seems that the BG+DRF could be overloaded easily and 866 routing will be no-optimal. 868 Another approach is to deploy multiple routers implemented with DRF 869 in ePMIP area and let them announce same set of prefix(es) which are 870 assigned to ePMIP to routing system (as illustrated in figure 11). 871 In this case, the anycast mechanism is used for attract traffic from 872 CN and optimized routing is enabled: CN <->Access Router <-> 873 Router+DRF <-> eLMA <-> MAG <-> MN 875 ,-------------- 876 / CN `------------. 877 ,' | LMF2 `---. 878 / | _..-'' ``-.._ `. 879 ; Access LMF1 --------- LMF3 `. 880 + Router `. 881 | \ 882 | \ | / Prefix ePMIP \ | / \ 883 | \ | / \ | / \ 884 : router+DRF router+DRF : 885 : / | \ / | \ | Prefix ePMIP 886 | / | \ / | \ | / 887 | | / 888 + ( area1 )( area2 )( area3 )...( arean ) BG+DRF--- 889 \ ( )( )( ) ( ) | \ 890 \ ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) | \ 891 ` --------------------------------------------; 893 Figure 11. Anycast Mechanism for Attracting Traffic From CN 895 7.4. Location Management Consideration 896 As illustrated in figure 11, multiple LMFs can be deployed in ePMIP 897 area. When a mobile node is registered with an eLMA, the eLMA (DRF) 898 needs to update location of this mobile node in a corresponding LMF. 899 And when eLMA (DRF) want to determine location information of a 900 mobile node, it need to query a corresponding LMF. 902 Interface between those LMFs is proposed in this draft. One 903 preferred LMF can be configured in every specific eLMAs (DRF). If 904 eLMA (DRF) need to update or query location of a mobile node (or 905 correspondent node), it can always sends a corresponding message to 906 that preferred LMF. Upon receiving the message, that preferred LMF 907 should determine which LMF is responsible for managing the location 908 for that mobile (or correspondent node) and relay the message to that 909 determined LMF. 911 Many methods can be used by preferred LMF for determining to which 912 LMF it should relay the message. For example, Hash algorithm 913 (hashing the HNP(es)), DHT algorithm and etc. 915 8. Security Considerations 917 This draft defines several new signaling messages among eMAGs and 918 eLMAs for supporting Distributed Mobility Management. Security 919 considerations for those messages are considered in this section for 920 two implementation cases discussed in this draft. 922 For first implementation case, as described in section 3.1, deploying 923 LMF in legacy LMA, and DAF in legacy MAG, respectively eLMA and eMAG. 924 Basic assumption is that all those eMAGs and eLMAs belong to one same 925 administrative domain (e.g. a same operator), other scenarios are out 926 of scope of this draft. 928 The function of signaling messages PBQR/PBQA between eMAG and eLMA is 929 for acquiring location information of a specific mobile node (or a 930 fixed node). This draft uses the same security association mechanism 931 which is defined in [RFC5213] to protect those PBQR\PBQA messages. 932 The function of signaling messages PBCI/PBCA exchanged between eMAGs 933 is for supporting mobile node's handoff when optimized routing has 934 been established. This is an essential feature for supporting 935 Distributed Mobility Management. The said PBCI/PBCA messages MUST be 936 protected by using end-to-end security association(s) offering 937 integrity and data origin authentication, the eMAGs is proposed to 938 implement IPsec [RFC4301] or other equivalents for protecting 939 PBCI\PBCA messages. E.g. IPsec Encapsulating Security Payload (ESP, 940 [RFC4303]) in transport mode with mandatory integrity protection 941 could be used for protecting those signaling messages. 943 Similar security considerations for protecting PBQR/PBQA and PBCI/ 944 PBCA messages which are described for the first implementation case 945 above are also applied for the second implementation case which is 946 described in section 7, i.e. deploying DAF in the legacy LMA to 947 constitute eLMA, and deploying LMF independently. 949 9. Difference with Localized Routing 951 [I-D.ietf-netext-pmip-lr] (i.e. LR) allows mobile nodes attached to 952 the same or different mobile access gateways to route traffic by 953 using localized forwarding or a direct tunnel between the gateways. 954 The core idea is to establish an optimized forwarding path between 955 two mobile nodes. Such localized communication enables offloading 956 traffic from LMAs and from the core network to the edge. Since 957 traffic can be routed by MAGs directly, those MAGs can be considered 958 as a kind of traffic anchor point. In this point of view, LR could 959 be a potential solution for Distributed Mobility Management taken MAG 960 as mobile node's dynamic anchor. 962 But LR cannot be used as a DMM solution directly, it still has some 963 gaps, e.g. packet loss, scalability and etc. LR does not consider 964 solution for scenario when two mobile nodes are attached to different 965 MAGs and registered with different LMAs (i.e. scenario A22 described 966 in [RFC6279]), because PMIPv6 does not define any interface between 967 LMAs. But it is most likely that, in a real network, multiple LMAs 968 are deployed. Because deploying a single LMA in same administrative 969 domain (e.g. a same operator) is prone to single point of failure and 970 low performance due to bottleneck. We can say that, a large part of 971 MN-MN communications will fall into scenario A22. In this case, if 972 scenario A22 is not considered, the usage of LR will be limited. 973 This draft considers inter-LMA communications which is one of the 974 main differences from LR. 976 In scenario when MN and CN attached to different MAGs but same LMA 977 (i.e. scenario A21 described in section 5 of 978 [I-D.ietf-netext-pmip-lr]) , if MN detaches from its current MAG and 979 attaches to a new MAG the localized routing state needs to be re- 980 established. During this period packets from CN will arrive at the 981 old MAG, this will result in packet loss. The packet loss problem 982 will be even more worse when MN handoffs from Scenario A12 to A22, in 983 Scenario A22, neither LMA nor MAG has a means to determine and 984 initiate LR , this can result in transient packet loss when routing 985 switches between the localized path into the normal path through the 986 LMAs as described in section 7 of [I-D.ietf-netext-pmip-lr]. Due to 987 this limitation LR is not applicable for packet-loss-sensitive 988 applications. This draft considers this issue and can guarantee 989 minimal packet loss. This is another differences from LR. 991 MN and CN in LR MUST be PMIPv6 mobile nodes. However, in real 992 deployment scenarios, a large part of communications between MN and 993 its CN involve accessing fixed node by MN (e.g. access a web server 994 ). As described in section 5.2 (figure 7), non-optimized routing 995 could be a problem for MN accessing fixed node. So if this scenario 996 is not considered, the usage of LR will also be limited. This draft 997 considers the routing optimization between mobile node and fixed node 998 which is one another difference from LR. 1000 In technical level, LR is established by utilizing Localized Routing 1001 Initiation (LRI) and Local Routing Acknowledgment (LRA) message 1002 between MAG and LMA. LMA provides one MAG with IP address of another 1003 MAG, and this approach will lead to so called race condition 1004 situation when both mobile nodes move and attach to a new access 1005 router simultaneously (refer to last bullet in section 3.2 of 1006 [RFC6279]). Solution specified in this draft utilize location 1007 information query mechanism to establish the optimized path which 1008 eliminates the race condition and also provides more flexibility in 1009 different deployment implementations(e.g. deploying LMF in LMA and 1010 DAF in MAG, deploying DAF in LMA and deploying LMF independently). 1012 10. IANA Considerations 1014 This document makes no request of IANA. 1016 11. References 1018 11.1. Normative References 1020 [I-D.ietf-netext-pmip-lr] 1021 Krishnan, S., Koodli , R., Loureiro, P., Wu, Q., and A. 1022 Dutta , "Localized Routing for Proxy Mobile IPv6", January 1023 2012. 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1029 (IPv6) Specification", RFC 2460, December 1998. 1031 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1032 Internet Protocol", RFC 4301, December 2005. 1034 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1035 4303, December 2005. 1037 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1038 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1040 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 1041 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 1042 2011. 1044 [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 1045 (PMIPv6) Localized Routing Problem Statement", RFC 6279, 1046 June 2011. 1048 11.2. Informative References 1050 [I-D.draft-ietf-dmm-requirements] 1051 Chan, H., "Requirements for Distributed Mobility 1052 Management", June 2013. 1054 Authors' Addresses 1056 Wen Luo 1057 ZTE 1058 No.68, Zijinhua RD,Yuhuatai District 1059 Nanjing, Jiangsu 210012 1060 China 1062 Email: luo.wen@zte.com.cn 1064 Juan Liu 1065 ZTE 1066 No.68, Zijinhua RD,Yuhuatai District 1067 Nanjing, Jiangsu 210012 1068 China 1070 Email: liu.juan45@zte.com.cn