idnits 2.17.1 draft-liu-dmm-pmip-based-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5213' on line 801 -- Looks like a reference, but probably isn't: '6097' on line 826 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Liu 2 Internet-Draft China Mobile 3 Intended status: Experimental J. SONG 4 Expires: Sep. 13, 2012 W. Luo 5 ZTE 6 March 13, 2012 8 PMIP Based DMM Approaches 9 draft-liu-dmm-pmip-based-approach-02 11 Abstract 12 This draft discusses a pmip based DMM solution 13 Requirements Language 15 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 16 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 17 document are to be interpreted as described in RFC 2119 [RFC2119]. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 27, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Overview of Ehanced Porxy Mobile IPv6 . . . . . . . . . . . . 3 56 3.1. Ehanced PMIP Networking Schematic . . . . . . . . . . . . 4 57 3.2. Functions of eMAG . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Functions of eLMA . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview of ePMIP Approaches . . . . . . . . . . . . . . . . . 6 60 4.1. Initial Registration . . . . . . . . . . . . . . . . . . . 6 61 4.2. Optimized Routing . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Handoff when Optimaized Routing is Established . . . . . . 9 63 4.4. Multiple eLMAs Consideration . . . . . . . . . . . . . . . 11 64 4.4.1. Determining eLMA Based on Configuration . . . . . . . 12 65 4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options 66 Header . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.4.3. Determining eLMA Based on Interface Between eLMAs . . 14 68 5. CN Considerations . . . . . . . . . . . . . . . . . . . . . . 14 69 5.1. CN Which is not Registered with eLMA . . . . . . . . . . . 15 70 5.2. Routing Optimization Considerations when CN is Fixed 71 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. Handoff between eMAG and MAG . . . . . . . . . . . . . . . . . 17 73 7. Considerations for Other Implementation . . . . . . . . . . . 17 74 7.1. One Alternative Implementation . . . . . . . . . . . . . . 17 75 7.2. Optimized Routing Consideration . . . . . . . . . . . . . 18 76 7.3. Correspondent Node Consideration . . . . . . . . . . . . . 19 77 7.4. Location Management Consideration . . . . . . . . . . . . 20 78 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 21 79 9. Difference with Localize Routing . . . . . . . . . . . . . . . 21 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 12. Normative References . . . . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 For supporting Distributed Mobility Management discussed in [I-D 90 DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions 91 is introduced in this draft . (1) Location Management Function (LMF), 92 maintaining the mappings between IP addresses and location 93 information of mobile nodes. (2) Distributed Anchoring Function 94 (DAF), including Distributed Routing sub-Function (DRF) which enables 95 optimized routing between mobile node and its correspondent node and 96 Distributed Mobility sub-Function (DMF) which guarantees mobile 97 node's mobility with minimal packet loss when optimized routing is 98 established. 100 DAF can be deployed in RFC[5213] specified MAG to constitute an eMAG, 101 and LMF can be deployed in RFC[5213] specified LMA to constitute an 102 eLMA. This draft intends to provide approaches for eliminating non- 103 optimized routing (section 4.2) which is identified as issues in [I-D 104 DMM] and dealing with handoff with quite low packet loss when 105 optimized routing is established (section 4.3). Besides, routing 106 optimization is considered not only for communication between two 107 mobile nodes, but also for communication between a mobile node and a 108 fixed node (section 5.2). Further, an alternative implementation is 109 also considered in section 7. 111 2. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC-2119 [RFC2119]. 117 3. Overview of Ehanced Porxy Mobile IPv6 119 For supporting Distributed Mobility Management discussed in [I-D 120 DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions 121 is introduced in this draft . (1) Location Management Function (LMF), 122 maintaining the mappings between IP addresses and location 123 information of mobile nodes (perhaps location information of fixed 124 nodes are also included). (2) Distributed Anchoring Function (DAF), 125 including Distributed Routing sub-Function (DRF) which enables 126 optimized routing between mobile node and its correspondent node and 127 Distributed Mobility sub-Function (DMF) which guarantees the mobile 128 node's mobility when optimized routing is enabled. 130 3.1. Ehanced PMIP Networking Schematic 132 Prefix A Prefix B Prefix C+D Prefix X 133 \ | / \ | / \ | / | \ | / 134 \ | / \ | / \ | / | \ | / 135 eLMA1 eLMA2 eLMA3 | LMA 136 | 137 ( )( )( ) ( ) ( )|( ) 138 ( area1 )( area2 )( area3 ) ( area4 )...( arean )|( arean+1) 139 ( )( )( ) ( ) ( )|( ) 140 ( eMAG1 )( eMAG2 )( eMAG3 ) ( eMAG4 )...( eMAGn )|( MAG ) 141 | | 142 | | +-----+ 143 | | | CN2 | 144 MN1 CN1 +-----+ 146 PMIP Domain with ePMIP deployed 147 Figure 1. RFC[5213] specified PMIP Domain with ePMIP deployed 149 The ePMIP can be implemented in many ways. One of those 150 implementations is to deploy LMF in RFC[5213] specified Local 151 Mobility Anchor (say legacy LMA) and to deploy DAF in RFC[5213] 152 specified Mobile Access Gateway (say legacy MAG). Legacy LMA with 153 LMF is called as enhanced local mobility anchor (eLMA), and legacy 154 MAG with DAF is called as enhanced mobile access gateway (eMAG) 155 respectively in the context of this draft. 157 Figure 1 illustrates a possible deployment for ePMIP, in which ePMIP 158 is deployed within a PMIP domain. Mechanism specified by the ePMIP 159 is enabled automatically for a mobile node when it attaches to an 160 eMAG and without any of its awareness, therefore there is no 161 additional requirement for a IPv6 mobile node. For fixed node 162 considerations, please refer to section 5.2. 164 Clear boundary between ePMIP and PMIP is not necessary, however, 165 deploying ePMIP in a continuous area is preferred. Distributed 166 mobility management approaches will be applied only when 167 correspondent node of this mobile node also attaches to an entity 168 which supports at least DRF (e.g. an eMAG), otherwise RFC[5213] 169 specified PMIP approaches will be applied (for more details, refer to 170 section 5). For supporting distributed mobility management 171 approaches, new signalling messages among the LMFs and DAFs are also 172 proposed in this draft. 174 For other implementation considerations, please refer to section 7. 176 3.2. Functions of eMAG 178 The eMAG is fully compatible with legacy MAG with limited additional 179 functions which are included in the distributed anchoring function 180 specified in this draft. The content below in this subsection is 181 general idea of the eMAG (DAF is a part of eMAG), including 183 - If eMAG decides to route traffic from its attached mobile node in 184 an optimized way, it should invoke the Distributed Anchoring Function 185 (DAF), more specifically, the Distributed Routing Function (DRF), to 186 enable distributed mobility management approaches. 188 - Optimized routing specified in this draft is realized by a direct 189 tunnel between two DRFs of mobile node and its correspondent node. 190 DRF is responsible for maintaining location information of mobile 191 node's correspondent node. 193 - If correspondent node also attaches to an eMAG and is registered 194 with an eLMA, the direct tunnel is established between two eMAGs and 195 tunnel endpoints are IP addresses of these two eMAGs (or CoAs of 196 these two communicating peers). For other scenarios, e.g. the 197 correspondent node is a fixed node, refer to section 5. 199 - Optimized routing can only be enabled when location of 200 correspondent node is determined. In case the location cannot be 201 determined locally, DRF should initiate a query approach with a 202 corresponding LMF. In case DRF is informed with the location (could 203 be CN's new location in handoff scenario), it should update the 204 location locally and forward any follow-up traffic based on that 205 location. In case location of correspondent node cannot be 206 determined by any means, common routing (e.g. PMIP routing) 207 mechanism should be used. 209 - For supporting mobile node's handoff from previously attached eMAG 210 (p-eMAG) to newly attached eMAG (n-eMAG), Distributed Mobility 211 Function (DMF) of both eMAGs shall be enabled. The responsibility of 212 n-DMF (n-eMAG) is to inform p-DMF (p-eMAG) with new location of that 213 mobile node during handoff. The responsibility of p-DMF (p-eMAG ) is 214 to forward any received traffic which designated to that mobile node 215 from DRF of correspondent node to n-DMF (n-eMAG ) and to inform the 216 DRF with new location for session continuity. 218 3.3. Functions of eLMA 220 The eLMA is fully compatible with legacy LMA with limited additional 221 functions which are included in the Location Management Function 222 specified in this draft. The content below in this subsection is 223 general idea of the eLMA (LMF is a part of eLMA), including 224 - The responsibility of LMF is to determine the location of a 225 specified mobile node (perhaps a fixed node, please refer to section 226 5) identified by its IP address (e.g. HoA) when it is queried by 227 DRF. Interface between LMFs for determining the location information 228 is proposed, for other alternatives, please refer to section 4.4. 230 - The location information of a mobile node can be its CoA, and 231 mechanisms for maintaining the mapping of mobile node's IP address 232 and its location information (i.e. HoA-CoA correlation) can be based 233 on Binding Cache Entry (BCE) which is specified in RFC[5213]. 235 4. Overview of ePMIP Approaches 237 As described above, one implementation of ePMIP is to deploy LMF with 238 legacy LMA to constitute an eLMA, and deploy DAF (including DRF and 239 DMF sub-functions) with legacy MAG to constitute an eMAG. The 240 sections including section 4 to 6 assumes ePMIP adopts this 241 implementation. Considerations for other alternative 242 implementations, please refer to section 7. 244 The overall assumptions for section 4 are as following: 246 - The correspondent node is also a mobile node which attaches to an 247 eMAG and is registered with an eLMA. 249 For other scenarios, such as correspondent node is a fixed station or 250 not registered with an eLMA, please refer to section 5. 252 4.1. Initial Registration 254 The initial registration procedure for ePMIP is triggered when a 255 mobile node is initialized and attaches to an access link on which 256 there is an eMAG. The mostly like is that the procedures for initial 257 registration are identical with those specified in RFC[5213]. 259 When determining the mobile node is authorized for the network-based 260 mobility management service, eMAG sends PBU to a selected eLMA for 261 the mobile node to complete the registration. General, an eLMA is 262 always preferred for the mobile node, unless there has other 263 constraints. 265 For example, If the mobile node's policy profile specified in 266 RFC[5213] includes a filed of mobile node's IPv6 home network 267 prefix(es) assigned to the mobile node's connected interface, and if 268 the HNP(es) is(are) managed by a legacy LMA, the eMAG shall send a 269 PBU to that LMA. In this case, the eMAG shall act as a legacy MAG 270 for this mobile node which means the DAF function in this eMAG shall 271 be disabled for this mobile node. 273 When initial registration with eLMA is completed, the mobile node 274 gets its HNP(es) and eLMA creates a binding cache entry for this 275 mobile node to maintain the mapping of this mobile node's HNP(es) and 276 Proxy-CoA. 278 4.2. Optimized Routing 280 As described in section 3.2, ePMIP leverages a direct tunnel between 281 two eMAGs which are implemented with DRF to realize an optimized 282 routing between mobile node and its correspond node. The effect is 283 similar with the MAG-MAG tunnel specified in [I-D Localized Routing 284 for Proxy Mobile IPv6] but the principle is different, refer to 285 section 9 for more information. 287 +-----+ +--------+ +-------+ +--------+ +-----+ 288 | MN1 | | eMAG1 | | eLMA | | eMAG4 | | MN2 | 289 +-----+ +--------+ +-------+ +--------+ +-----+ 290 | | | | | 291 | 1.Attach and PMIP Reg. | 1.Attach and PMIP Reg. | 292 |<------------|----------->|<------------|------------>| 293 | | | | | 294 |2.uplink Data| | | | 295 |============>| 3. PBQR | | | 296 | |----------->| | | 297 | | 4. PBQA | | | 298 | |<-----------| | | 299 | +------------------+ | | | 300 | | 5.Record Location| | | | 301 | | of MN2 | | | | 302 | +------------------+ | | | 303 | | 6.uplink data in tunnel | | 304 | |=========================>| | 305 | | | |7.uplink data| 306 | | | |============>| 307 | | 8. Ongoing traffic | | 308 |<===========>|<========================>|<===========>| 309 | | | | | 310 Figure 2. Optimized Routing 312 Figure 2 illustrates data delivery approaches of ePMIP for 313 Distributed Mobility Management. Except for the general assumptions 314 applied for section 4, two more assumptions are also applied in this 315 subsection as following: 317 - Mobile nodes (MN1 and MN2) attach to different eMAGs (eMAG1 and 318 eMAG4) respectively. 320 - Mobile nodes are registered with a same eLMA. 322 For other scenarios, such as mobile nodes are registered with 323 different eLMAs, refer to section 4.4. 325 After the initial registrations, both mobile nodes get their HNPes. 326 And eLMA maintains the mappings of HNP(es) and Proxy-CoAs of both 327 mobile nodes in binding cache entries for them respectively . 329 The communication between MN1 and MN2 is initiated by MN1 sending IP 330 packets to MN2 (i.e. uplink traffic). The destination IP address of 331 the uplink traffic is set to HoA of MN2. Upon receiving the initial 332 uplink traffic, eMAG1 should determine whether an optimized routing 333 can be established by the support of DRF on it. 335 The eMAG1 (DRF) should determine whether it holds the location (i.e. 336 CoA) of MN2 locally first. If not, eMAG1 (DRF) should determine the 337 location by initiating a query (i.e. sending a PMIP Binding Query 338 Request, PBQR) to eLMA (LMF) who holds the BCE for MN2. Based on HNP 339 of MN2 provided in the PBQR, eLMA (LMF) could derive the location of 340 MN2 (i.e. CoA) in a corresponding BCE and responses eMAG1 (DRF) with 341 an answer (i.e. sending a PMIP Binding Query Answer, PBQA) carrying 342 the location information. Upon receiving the PBQA, eMAG1 (DRF) 343 records the location of MN2 locally. 345 Upon the location of MN2 is determined, eMAG1 (DRF) sets up its 346 endpoint of a tunnel (e.g. IP in IP tunnel) to eMAG2 (DRF). And all 347 follow-up uplink traffic will be encapsulated by eMAG1 (DRF) and sent 348 to eMAG4 (DRF) in the established tunnel directly. 350 Before the optimized routing is established, eMAG1 could forward the 351 first few packets of the uplink traffic to eLMA via bi-directional 352 PMIP tunnel between the two as specified in RFC[5213]. In this case, 353 the routing of the first few packets is non-optimized, and the delay 354 of those packets may be a litter bit larger than the follow-up 355 traffic. Another alternative is that eMAG1 buffers those packets 356 until the optimized routing is set up. In this case, how to 357 determine capacity of the buffer should be carefully considered. 359 Upon receiving encapsulated packet in the eMAG-eMAG tunnel, the eMAG4 360 (DRF) needs to decapsulate the packet and forwards the uplink traffic 361 to MN2. As an alternative, eMAG4 (DRF) may parse the packet and 362 record the location of MN1. The location of MN1 can be derived from 363 the outer IP header of the encapsulated packet (i.e. the IP address 364 of the tunnel entry point). 366 Upon receiving downlink traffic from MN2 to MN1, eMAG4 (DRF) should 367 also set up its endpoint of a tunnel to eMAG1 (DRF) for the downlink 368 traffic when the location of MN1 is determined. At this moment, a 369 bi-directional tunnel between two eMAGs has been established for all 370 follow-up uplink and downlink traffic and an optimized routing for 371 MN1 and MN2 is set. 373 4.3. Handoff when Optimaized Routing is Established 375 MN1 may change its point of attachment from previously attached eMAG 376 (p-eMAG) to newly attached eMAG (n-eMAG) at any time after the 377 optimized routing has been established as described in section 4.2. 378 The routing shall still be remained optimized after handoff. 380 The [I-D Localized Routing for Proxy Mobile IPv6] also specifies a 381 method for re-establishing optimized routing after the handoff which 382 leverages another new trigger from LMA to both MAGs involved. The 383 consequence is to make the routing non-optimized during the handoff, 384 and optimized again after the handoff. The handoff approaches 385 specified here is much different from [I-D Localized Routing for 386 Proxy Mobile IPv6] specified approaches and may provide less latency 387 and jitter. 389 +---+ +--------+ +--------+ +-------+ +--------+ +---+ 390 |MN1| | p-eMAG | | n-eMAG | | eLMA | | eMAG4 | |MN2| 391 +---+ +--------+ +--------+ +-------+ +--------+ +---+ 392 | | | | | | 393 | | 1. Ongoing traffic | | 394 |<==========>|<==================================>|<=========>| 395 | | | | | | 396 | | 2.attach and PMIP Reg. | | | 397 |<----------------------->|<--------->| | | 398 | | 3.PBCI | | | | 399 | |<-----------| | | | 400 | | 4.PBCA | | | | 401 | |----------->| | | | 402 | 5. Uplink traffic | | | | 403 |========================>| | | | 404 | | +-----------------+ | | | 405 | | | 6.Determine the | | | | 406 | | | Location of MN2 | | | | 407 | | +-----------------+ | | | 408 | | | | | | 409 | | +--------------------------------------------+ 410 | | | 7. Process of uplink traffic is similar | 411 | | | with the approaches in figure 2 | 412 | | +--------------------------------------------+ 413 | | | | | | 414 | | | 8 . Downlink Traffic | | 415 | |<===================================|<==========| 416 | |===========>| | | | 417 |<========================| | | | 418 | | | 9. PBCI | | | 419 | |----------------------------------->| | 420 | | | | +----------------+ | 421 | | | | | 10. Update | | 422 | | | | | Location of MN1| | 423 | | | | +----------------+ | 424 | | | 11. PBCA | | | 425 | |<-----------------------------------| | 426 | | 12. Ongoing Downlink Traffic | | 427 |<========================|<======================|<==========| 428 | | | | | 430 Figure 3. Handoff When Optimized Routing is Established 432 Figure 3 illustrates approaches for handoff of MN1 from p-eMAG to 433 n-eMAG. During handoff, RFC[5213] specified procedures is performed 434 for MN1 to maintain its HNP(es) unchanged. The n-eMAG on new access 435 link, upon detecting MN1 on the link, assigns a new CoA for MN1 and 436 generates a PBU message to eLMA for updating the BCE for MN1. In 437 sequence, eLMA responses a PBA message to n-eMAG with one additional 438 new extension which includes the previous location of MN1 (i.e. CoA 439 of MN1 assigned by p-eMAG). 441 Further, n-eMAG (DMF) initiates an inform message (i.e. PMIP Binding 442 Change Inform, PBCI) to p-eMAG (DMF) with new location of MN1 (i.e. 443 CoA assigned by n-eMAG) based on the acquired previous location of 444 MN1. Sequencely, p-eMAG (DMF) updates the location of MN1 and 445 responses with an acknowledge message (i.e. PMIP Binding Change Ack, 446 PBCA) with all location information of the MN1's current 447 correspondent nodes (in figure3, the current correspondent node is 448 only MN2). 450 Upon uplink traffic arriving at n-eMAG instead of p-eMAG, n-eMAG 451 (DRF) can derive the location of MN2 locally and forwards the traffic 452 in an optimized way of routing (i.e. MN1->n-eMAG->eMAG4->MN2). 454 The most likely is that downlink traffic during the handoff is still 455 forwarded by eMAG4 (DRF) to p-eMAG (DRF) before location of MN1 456 stored in eMAG4 (DRF) locally is updated (i.e. MN2->eMAG4->p- 457 eMAG->MN1) and be discarded by p-eMAG (DRF). 459 For reducing packet loss, p-eMAG (DMF) is proposed to establish a 460 directional tunnel to n-eMAG (DMF) and forward any received downlink 461 traffic to n-eMAG (DMF) via the tunnel. Meanwhile, p-eMAG (DMF) is 462 also proposed to update the location of MN1 stored in eMAG4 (DRF) by 463 initiating a PBCI to eMAG4 (DRF) to indicate eMAG4 (DRF) to forward 464 follow-up downlink traffic to n-eMAG (DRF) directly: MN2->eMAG4->n- 465 eMAG->MN1. 467 4.4. Multiple eLMAs Consideration 469 As illustrated in figure 1, multiple eLMAs can be deployed. The most 470 likely is that the mobile node and its correspondent node (i.e. 471 another mobile node) are registered with different eLMAs. The 472 approaches described in subsection 4.2 and 4.3 simply assume both 473 mobile nodes are registered with one same eLMA (the same assumption 474 applied to [I-D Localized Routing for Proxy Mobile IPv6]), and this 475 section considers multiple eLMAs. 477 Announce PA Announce PB Announce PC and PD 478 \ | / \ | / \ | / 479 \ | / \ | / \ | / 480 +--------+ +--------+ +--------+ 481 | eLMA1 | | eLMA2 | | eLMA3 | 482 +-----+--+ +--------+ +---+----+ 483 | _______________| 484 / | 485 +---+----+ +----+---+ 486 | eMAG1 | | eMAG2 | 487 +---+----+ +---+----+ 488 | | 489 +--+-+ +-+--+ 490 | MN1| | MN2| 491 +----+ +----+ 493 Figure 4. Mobile node and its Correspondent Node are Registered with 494 Different eLMAs 496 As illustrated in figure 4, MN1 is registered with eLMA1 by eMAG1, 497 and MN2 is registered with eLMA3 by eMAG2 respectively. Based on 498 RFC[5213], only the LMA which is involved in PMIP registration for a 499 mobile node holds this mobile node's Binding Cache Entry. Therefore, 500 in figure 4, only eLMA1 holds the location information of MN1 and 501 only eLMA3 holds the location information of MN2. 503 As described in section 4.2, before establishing optimized routing 504 for the traffic, eMAG1 shall determine the location of MN2. In case 505 the location can not be determined locally, eMAG1 shall determine to 506 which eLMA it should send a PBQR message. 508 4.4.1. Determining eLMA Based on Configuration 510 As illustrated in figure 4, each eLMA manages a set of IPv6 prefixes 511 with which it uses to allocate home network prefixes or HoAs to the 512 MNs registered to that eLMA. For example, eLMA1 announces prefixes 513 PA to routing system and eLMA3 announces prefixes PC+PD. 515 If eMAGs could be aware of the IPv6 prefixes configurations of each 516 eLMA, e.g. from operator's management plane since they are in a same 517 administrative domain. The eMAG (DRF) can determine the 518 corresponding eLMA (LMF) to which it should send the PBQR, based on 519 the destination IPv6 address of the traffic and the configured 520 information. 522 For example, the destination IP address of the traffic from MN1 to 523 MN2 is MN2's HoA. Based on configuration information, eMAG1 (DRF) 524 can determine the HNP of MN2 is prefix PC and is managed by eLMA3. 526 Therefore, eMAG1 (DRF) can determine the eLMA3 (LMF) should be 527 queried when it wants to determine the location of MN2. 529 This solution looks simple, but it depends on static configured 530 information on every eMAGs. If configuration of a eLMA is changed 531 (e.g. add a prefix PE into eLMA1's IPv6 prefix set), the most likely 532 is that the configured information in all eMAGs in same 533 administrative domain needs update. It seems like that this solution 534 works well for a administrative domain with small number of eMAGs. 536 4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options Header 538 Announce PA Announce PB Announce PC and PD 539 \ | / \ | / \ | / 540 \ | / \ | / \ | / 541 eLMA1 eLMA2 eLMA3 542 + 543 /!\ 544 ,------- Router1-------- Router2 .| 545 | 546 | 547 eMAG1 549 eMAG1 initiates a query message (PBQR) carried in a IP 550 packet whose destination IP address is HoA of MN2. 551 The packet will be intercepted, processed and terminated by 552 eLMA3 who manages the prefix of the MN2's HoA based on 553 the mechanism of the Hop-by-Hop Option Header. 554 Figure 5. Determining eLMA Based on Hop-by-Hop Options Header 556 When constructing a PBQR message, eMAG1 can use HoA of MN2 as 557 destination IP address of this message and construct an appropriate 558 IPv6 Hop-by-Hop Option Header as extension header. The HoA of MN2 is 559 the destination IP address of the uplink traffic. 561 When IP packet which includes the PBQR message is sent into the 562 routing system, standard routing mechanism ensures the packet can 563 reach eLMA3 which manages the prefix of MN2's HoA. Depending on the 564 mechanism of the Hop-by-Hop Option Header, each router including 565 eLMA3 on the routing pass of this packet will intercept the packet 566 and check the Hop-by-Hop Option Header. 568 Based on the indication carried by the options in Hop-by-Hop Option 569 Header, eLMA3 determines whether the prefix of destination IP address 570 belongs to its management. If it does, eLMA3 shall treat itself as 571 destination of this message and let the LMF on it process the 572 message. 574 It seems like that, all common routers on the routing pass of this 575 packet will check the Hop-by-Hop Option Header and may cause some 576 delay. Another disadvantage is that it will take relative longer 577 time to make sure no location information of correspondent node can 578 not be determined (refer to section 5.1 for more details). 580 4.4.3. Determining eLMA Based on Interface Between eLMAs 582 +-----------------------------+ 583 | eLMA2 | 584 | | 585 | eLMA1--------------> eLMA3 | 586 | /|\ further query | 587 +-----+-----------------------+ 588 | 589 query | 590 | 591 eMAG1 593 Figure 6. Determining eLMA Based on Interface Between eLMAs 595 Interface between eLMAs which are located in a same administrative 596 domain is introduced for determining location information of a 597 particular mobile node. 599 When determining location of correspondent node, eMAG1 (DRF), in 600 figure 6, could simply send a PBRQ message to any random eLMA (LMF) 601 it considers convenient (e.g. eLMA1). The most likely is that the 602 eLMA (LMF) queried does not hold the relevant location information. 603 But the eLMA (LMF) can determine which eLMA (LMF) holds the 604 information (e.g. eLMA3). 606 For example, if IPv6 prefixes managed by each eLMA are awared of, the 607 eLMA1 (LMF) can determine which eLMA (LMF) should be queried further 608 and query it. It can be expected that the number of eLMA deployed in 609 a administrative domain will not be large (as illustrated in figure 610 1), therefore, depending on configuration is applicable. 612 5. CN Considerations 614 The assumption of section 4 is that the correspondent node is also a 615 mobile mode and is registered with eLMA by eMAG. Other scenarios, 616 such as correspondent node is a fixed node, or a mobile node but is 617 not registered with eLMA, are considered in this section. 619 5.1. CN Which is not Registered with eLMA 621 This section considers scenario that the correspondent node (e.g. 622 CN2 in figure 1) is a mobile node but not registered with eLMA. For 623 example, CN2 is registered with a legacy LMA by attaching to a legacy 624 MAG. For another example, CN2 just locates in common IPv6 625 environment. 627 When mobile node (MN1 in figure 1) initiates uplink traffic to 628 correspondent node (CN2 in figure 1), eMAG1 (DRF) to which MN1 629 attaches should initiate a query for determining location of CN2 as 630 described in section 4.2. 632 According to section 4.4.1, eMAG1 (DRF) can not determine to which 633 eLMA (LMF) it should send the query message, because CN2's prefix is 634 out of the management of any eLMA. In this case, eMAG1 (DRF) can 635 make sure no location information can be determined. 637 According to section 4.4.2, eMAG1 (DRF) should construct a query 638 message and set message's destination to IP address of CN2. The 639 query message will be routed to CN2 based on common routing mechanism 640 and no response is excepted. The eMAG1 (DRF) should wait for the 641 response until the related timer is timeout. Before eMAG1 (DRF) can 642 make sure no location information can be determined, one or more 643 query message may be re-sent by eMAG1 (DRF). Thus, it will take a 644 relative longer time to make sure no location information can be 645 determined. 647 According to section 4.4.3, eMAG1 (DRF) can send a query message to 648 any one of those eLMAs (LMF) and the eLMA (LMF) queried performs the 649 query among those eLMAs (LMF). In this case, eMAG1 (DRF) can make 650 sure no location information can be determined. 652 As described above, the failed queries are excepted and location 653 information of CN2 can not be determined by eMAG1 (DRF). In this 654 case, eMAG1 should behavior as a legacy MAG for this session and PMIP 655 specified routing mechanism shall be applied for the uplink traffic 656 (i.e. no optimized routing), e.g. MN->eMAG1->E-LMA->common 657 router->CN. 659 Of course, if the correspondent node itself is a fixed node, same 660 rules described above are also applicable. 662 5.2. Routing Optimization Considerations when CN is Fixed Node 664 As described above, if correspondent node is a fixed node, eMAG1 will 665 behavior as a legacy MAG and no optimized routing is enabled. 667 Most of correspondent nodes which are fixed nodes are deployed in a 668 centralized manner in most deployment, e.g. CDN/IDC/Web Servers and 669 etc. Those fixed nodes are generally converged by a couple of access 670 routers, although the topology within those fixed nodes may be very 671 complicate, to access operator's IP bearer network which is 672 illustrated in figure 7. If mechanism which providing optimized 673 routing cannot be applied when correspondent node are fixed nodes of 674 these kind, effect of this mechanism will be very limited. 676 __________ 677 / CN \ ,--------. 678 ((CDN\IDC\Web )---Access Router `. _.----------. 679 ( Server) ) ,--' `-'' eLMA : 680 \___________/ \ _.-------. ,--' 681 '-- eMAG-----'' `---' 682 | 683 | 684 MN1 686 Figure7. Correspondent Nodes are Fixed Nodes Cause Non-optimized 687 Routing 689 Refer to figure 7, it seems like that non-optimized routing (e.g. 690 between MN1 and CDN) will be a problem for this deployment as 691 discussed in [I-D DMM Problem Statement]. For purpose of eliminating 692 non-optimized routing, one implementation is to replace those common 693 access routers in figure 7 with routers which are implemented with 694 Distributed Routing Function (DRF). No Distributed Mobility Function 695 (DMF) is needed, since nodes attached are all fixed nodes. 697 ,-------. 698 ,' `-. 699 ( CDN\IDC\Web )-. _.----. 700 ( Server ) \ ,--_.--'' `-. 701 \____________' AR+DRF-' `-------. 702 ,-----------. / -. \ 703 ; Fixed User : ,' `- \ 704 : Equipments ;---AR+DRF ----LMF eLMA : 705 `-----------' \ ,- ; 706 AR+DRF--' ,----. ; 707 ,-----------. / `\ eMAG `--. ; 708 ; Fixed User : / -------------' | `-----' 709 : Equipments ;/ | 710 `-----------' | 711 | 712 MN1 713 Figure 8. Applying Optimized Routing when Correspondent Nodes are 714 fixed nodes 715 Additionally, one more LMF needs deployed as illustrated in figure 8. 716 The responsibility of that LMF is to response any received PBRQ 717 message with location of queried fixed node (e.g. IP address of one 718 of those AR+DRF). Method specified in section 4.2.2 may not be 719 applicable, because PBRQ will be routed to one of those AR+DRF 720 directly. No response will be expected, except that the AR+DRF is 721 also co-located with a LMF. 723 6. Handoff between eMAG and MAG 725 As illustrated in figure 1, ePMIP is deployed in PMIP domain (no 726 clear boundary), and belongs to a same administrative domain, e.g. a 727 same operator. The mobile node which is initial registered with eLMA 728 by attaching a eMAG may handoff to a legacy MAG and vice versa. By 729 supporting the handoff between eMAG and MAG , ePMIP can be deployed 730 in manner of incremental when assuming PMIP is well deployed. 732 As described above, eLMA is a legacy LMA implemented with LMF, and 733 eMAG is a legacy MAG implemented DAF (DRF+DMF). When a mobile node 734 which attaches to an eMAG handoff to a legacy MAG, the legacy MAG 735 will perform PMIP registration to the eLMA and establish a bi- 736 directional tunnel with the eLMA. In this case, PMIP routing 737 mechanism will be applied (i.e. no routing optimization). On the 738 other hand, when a mobile node which attaches to a legacy MAG handoff 739 to an eMAG, the eMAG will perform PMIP registration to the legacy LMA 740 and establish a bi-directional tunnel with the legacy LMA. In this 741 case, PMIP routing mechanism will also be applied (i.e. no routing 742 optimization). 744 7. Considerations for Other Implementation 746 As described in section 3.1, ePMIP can be implemented in many ways. 747 Section 3.1 also indicates one of those implementations, i.e. 748 deploying LMF in legacy LMA, and DAF in legacy MAG. This section 749 considers one alternative implementation. 751 7.1. One Alternative Implementation 753 One alternative implementation is to deploy DAF in legacy LMA, and 754 deploy LMF independently. When multiple LMFs are deployed, 755 interfaces between those LMFs are necessary as illustrated in figure 756 10. 758 _.---------------------. 759 ,---'' LMF2 `--- , 760 ,' _..-'' ``-.._ ; 761 ,-' LMF1 --------- LMF3 \ 762 / : Prefix ePMIP 763 / ( area1 )( area2 )( area3 )...( arean ) | / 764 | ( )( )( ) ( ) ; / ( arean+1) 765 : ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) BG+DRF --- ( ) 766 \ | | | / \ ( LMA ) 767 `-----+. | _.----+--ePIMP Area-----' \ | 768 | `------|' | | 769 | | | | 770 MAG1 MAG2 MAG3 MAG 771 | | 772 MN1 CN1 773 Figure 10. One Alternative Implementation of ePMIP 775 For routing consideration, a clear boundary seems necessary if ePMIP 776 takes this kind of implementation. A set of IPv6 prefixes which are 777 used for allocating HNP(es) or HoA(s) to mobile nodes should be 778 assigned to ePMIP area and each LMA manages part of them. The eLMAs 779 don't announce any IPv6 prefix to routing system. Instead, a border 780 gateway implemented with DRF (BG+DRF) which is located at the 781 boundary of this ePMIP area announces those set IPv6 prefix(es) to 782 outside as illustrated in figure 10. 784 The node inside ePMIP area could be a mobile node or a fixed node. 785 When a correspondent node located outside of ePMIP area sends IP 786 traffic to a node located inside ePMIP area, traffic will be routed 787 to BG+DRF which announces the management of the prefix of the 788 traffic's destination IP address. 790 7.2. Optimized Routing Consideration 792 Consider that a mobile node (MN1) is initiated in ePMIP area and 793 attaches to a legacy MAG, RFC[5213] specified PMIP registration 794 procedures will be performed. The MAG will select a local mobility 795 anchor (e.g. eLMA1) for MN1 and send a PBU to it. Note that, the LMA 796 selected by the MAG is actually an eLMA. MAGs cannot tell the 797 distinguishes between LMAs and eLMAs. 799 After successful PMIP registration, MN1 acquires its HNP(es) and 800 eLMA1 manages a binding cache entry for MN1 as specified in 801 RFC[5213]. Further, eLMA1 (DRF) has to inform a corresponding LMF 802 with the HNP(es) and location information of MN1 (i.e. IP address of 803 eLMA1 itself). LMF will manage the mapping between HNP(es) and 804 location. How to determine which LMF the eLMA1 (DRF) should inform, 805 refer to section 7.4. 807 Consider that correspondent node (CN1) of MN1 is also a mobile node 808 and is located in same ePMIP area (refer to section 7.3 for other 809 scenarios). 811 Upon receiving uplink traffic from MN1 to CN1 via the bi-directional 812 PMIP tunnel, eLMA1 (DRF) should determine whether it holds location 813 information of CN1 locally. If not, a corresponding LMF should be 814 queried by eLMA1 (DRF), and the required location (e.g. IP address 815 of eLMA3) should be stored by eLMA1 (DRF) locally. Upon determining 816 the location, eLMA1 (DRF) sets up a tunnel to eLMA3 (DRF) by using 817 the location of CN1 as tunnel endpoint, and forwards uplink traffic 818 to eLMA3 (DRF) directly. 820 Upon movement of MN1, a PMIP handoff from pMAG to nMAG will be 821 triggered. RFC[6097] provides a mechanism for LMA discovery, and 822 requires nMAG of a mobile node should discovery a same LMA with which 823 the pMAG has discovered for that mobile node. The nMAG in this draft 824 does not have to discover a same eLMA (i.e. eLMA1) but a best eLMA 825 (e.g. eLMA2) for MN1 and performs PMIP registration. The 826 implementation can take any method specified in RFC[6097] for 827 discovering the best eLMA. 829 The eLMA2 (DRF) should update LMF with new location information of 830 MN1 (e.g. IP address of eLMA2 itself) and eLMA2 (DMF) should also 831 inform eLMA1 with the new location. The approaches are quite similar 832 with those described in section 4.3. 834 7.3. Correspondent Node Consideration 836 Consider that correspondent node is located outside of ePMIP area 837 (could be a mobile node or a fixed node). In this case, the prefixes 838 of IP address of CN are not managed by ePMIP. Actually, the set of 839 IPv6 prefixes which are assigned to ePMIP can be configured in LMF. 840 In this case, when eLMA1 (DRF) queries LMF CN's location, the LMF 841 will response with IP address of BG+DRF. The routing will be: MN1 842 <-> MAG <-> eLMA <->BR+DRF <-> CN. 844 Consider that the correspondent node is a fixed node and is located 845 inside ePMIP area. It seems like that the traffic from CN to MN1 846 cannot be routed correctly, because CN doesn't have any idea of MN1's 847 location. 849 A simple approach is to let BG+DRF also announce the set of prefixes 850 which are assigned to ePMIP to routing system inside ePMIP area. In 851 this case, traffic will be routed to BG+DRF and further forwarded by 852 BG+DRF. But it seems that the BG+DRF could be overloaded easily and 853 routing will be no-optimal. 855 Another approach is to deploy multiple routers implemented with DRF 856 inside ePMIP area and let them announce same set of prefix(es) which 857 are assigned to ePMIP to routing system (as illustrated in figure 858 11). In this case, the anycast mechanism is used for attract traffic 859 from CN and optimized routing is enabled: CN <->Access Router <-> 860 Router+DRF <-> eLMA <-> MAG <-> MN 862 ,-------------- 863 / CN `------------. 864 ,' | LMF2 `---. 865 / | _..-'' ``-.._ `. 866 ; Access LMF1 --------- LMF3 `. 867 + Router `. 868 | \ 869 | \ | / Prefix ePMIP \ | / \ 870 | \ | / \ | / \ 871 : router+DRF router+DRF : 872 : / | \ / | \ | Prefix ePMIP 873 | / | \ / | \ | / 874 | | / 875 + ( area1 )( area2 )( area3 )...( arean ) BG+DRF--- 876 \ ( )( )( ) ( ) | \ 877 \ ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) | \ 878 ` --------------------------------------------; 880 Figure 11. Anycast Mechanism for Attracting Traffic From CN 882 7.4. Location Management Consideration 884 As illustrated in figure 11, multiple LMFs can be deployed in ePMIP 885 area. When a mobile node is registered with an eLMA, the eLMA (DRF) 886 needs to update location of this mobile node in a corresponding LMF. 887 And when eLMA (DRF) want to determine location information of a 888 mobile node, it need to query a corresponding LMF. 890 Interface between those LMFs is proposed in this draft. One 891 preferred LMF can be configured in every specific eLMAs (DRF). If 892 eLMA (DRF) need to update or query location of a mobile node (or 893 correspondent node), it can always sends a corresponding message to 894 that preferred LMF. Upon receiving the message, that preferred LMF 895 should determine which LMF is responsible for managing the location 896 for that mobile (or correspondent node) and relay the message to that 897 determined LMF. 899 Many methods can be used by preferred LMF for determining to which 900 LMF it should relay the message. For example, Hash algorithm 901 (hashing the HNP(es)), DHT algorithm and etc. 903 8. Security Consideration 905 9. Difference with Localize Routing 907 10. IANA Considerations 909 This document makes no request of IANA. 911 Note to RFC Editor: this section may be removed on publication as an 912 RFC. 914 11. References 916 11.1. Normative References 918 RFC5213 920 RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 922 11.2. Informative References 924 12. Normative References 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, March 1997. 929 Authors' Addresses 931 Dapeng Liu 932 China Mobile 934 Jun Song 935 ZTE 936 No.68,Zijinghua Road, 937 Nanjing, Yuhuatai District 210012 938 China 940 Phone: 941 Fax: 942 Email: song.jun@zte.com.cn 943 URI: 945 Wen Luo 946 ZTE 947 No.68,Zijinghua Road 948 Nanjing, Yuhuatai District 210012 949 China 951 Phone: 952 Fax: 953 Email: luo.wen@zte.com.cn 954 URI: