idnits 2.17.1 draft-wu-netext-local-ro-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1295 has weird spacing: '...Options conta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 12, 2010) is 5180 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) == Missing Reference: 'MAG2' is mentioned on line 345, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-pfmipv6-12 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-17 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-netext-pmip6-lr-ps-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft B. Sarikaya 4 Intended status: Standards Track Huawei 5 Expires: August 16, 2010 February 12, 2010 7 An Extension to Proxy Mobile IPv6 for Local Routing Optimization 8 draft-wu-netext-local-ro-05 10 Abstract 12 This document extends local routing in Proxy Mobile IPv6 (PMIPv6) and 13 defines a localized routing optimization protocol between Mobility 14 Access Gateways within a single provider domain. The protocol 15 supports operation over IPv4 transport networks, IPv4 home address 16 mobility and handover. The Local mobility anchor initiated and 17 mobile access gateway initiated local routing are allowed to setup 18 local routing path between the mobile and correspondent node by 19 sending messages to the corresponding mobile access gateway or local 20 mobility anchor. If the MN & CN are anchored with two different LMAs 21 then the MN-LMA must discover which LMA the CN is registered with 22 before an optimized local routing path can be established. Mobile 23 Access Gateways create and refresh bindings using proxy binding 24 update and acknowledgement messages. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, and it may not be 31 published except as an Internet-Draft. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on August 16, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. PMIP6 Local Routing OptimizationScenario Analysis . . . . . . 5 71 4. Local Routing Optimization Protocol Overview . . . . . . . . . 6 72 4.1. MAG-initiated Local Routing Optimization . . . . . . . . . 7 73 4.1.1. Handover Considerations . . . . . . . . . . . . . . . 9 74 4.2. LMA-initiated Local Routing Optimization . . . . . . . . . 10 75 4.2.1. Handover Considerations . . . . . . . . . . . . . . . 11 76 5. Processing Considerations . . . . . . . . . . . . . . . . . . 12 77 5.1. Mobile Access Gateway Considerations . . . . . . . . . . . 12 78 5.2. Local Mobility Anchor Considerations . . . . . . . . . . . 15 79 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1. IPv4 HoA Support . . . . . . . . . . . . . . . . . . . . . 17 81 6.2. IPv4 Transport Support . . . . . . . . . . . . . . . . . . 17 82 7. Inter-LMA Local Routing Considerations . . . . . . . . . . . . 18 83 7.1. MAG-initiated Inter-LMA Local Routing . . . . . . . . . . 18 84 8. Conceptual Data Structure Extensions . . . . . . . . . . . . . 19 85 8.1. Binding Update List Extensions . . . . . . . . . . . . . . 19 86 8.2. Binding Cache Entry Extensions . . . . . . . . . . . . . . 20 87 8.3. Routing Table Entry Extensions . . . . . . . . . . . . . . 20 88 9. Local Routing Optimization Message Format . . . . . . . . . . 21 89 9.1. Local Routing Optimization Mobility Option . . . . . . . . 21 90 9.2. The Local Routing Optimization Request (LROREQ) Message . 22 91 9.3. Local Routing Optimization Response Message (LRORSP) . . . 23 92 9.4. MN-CNs Pair Mobility Option . . . . . . . . . . . . . . . 24 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 98 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 99 Appendix A. Future Extension . . . . . . . . . . . . . . . . . . 28 100 A.1. LMA Route Optimization Start Message . . . . . . . . . . . 28 101 A.1.1. LMA Route Optimization Start Request Message . . . . . 28 102 A.1.2. LMA Route Optimization Start Response Message . . . . 29 103 A.2. LMA Initiated Inter-LMA Local Routing . . . . . . . . . . 30 104 A.2.1. IPv4 Support Consideration . . . . . . . . . . . . . . 31 105 A.3. LMA Initiated operation for Inter-LMA Local Routing . . . 31 106 Appendix B. Change Notes . . . . . . . . . . . . . . . . . . . . 32 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 109 1. Introduction 111 Proxy Mobile IPv6 (PMIP6) [RFC5213] allows the Mobility Access 112 Gateway (MAG) to optimize packet delivery by locally routing packets 113 within one MAG instead of reverse tunneling them to the mobile node's 114 Local Mobility Anchor (LMA). However, it does not address the 115 optimization of routing between two Mobile Access Gateways sharing 116 the same LMA or registered to different Local Mobility Anchors; nor 117 does it define how local routing optimization capability is detected, 118 the entity that initiates local routing optimization, or how to 119 determine whether local routing optimization is permitted. 121 This document defines local routing optimization mobility messages 122 and options for PMIPv6 that are intended to assist the Mobile Access 123 Gateways to negotiate and setup a local routing path between each 124 other. The new local routing optimization mobility options allow the 125 LMA and the MAG to discover whether local routing is allowed and, if 126 som what form it may take. The local routing optimization protocol 127 can be initiated by either of the PMIPv6 managed nodes and provides a 128 flexible negotiation mechanism for local routing. 130 As RFC 5213 [RFC5213] warns, use of local routing may affect 131 accounting and traffic policies relating to the mobile node, LMA 132 routing policies, and security policies. The general aim of the 133 proposals in this document is to provide better manageability of 134 local routing services and local routing service provisioning from 135 the point of view of both operators and service providers within one 136 Provider domain. 138 2. Terminology 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 The document uses the terminology specified in RFC 5213 [RFC5213]and 145 RFC 3775 [RFC3775] In addition, this document defines the following 146 terms: 148 Local routing (LR) 150 When local routing is active, traffic between the MN and the CN 151 does not pass through the LMA and is routed directly between the 152 MAG(s) to which the MN and CN are attached. Local routing may 153 only take place between Mobile Access Gateways within a single 154 provider domain. 156 Local Routing Optimization Request (LROREQ): 158 A message initiated by the MAG or LMA to which the Mobile Node is 159 attached requesting the MAG or LMA to which the Mobile Node or the 160 Correspondent Node is attached to establish a local routing path 161 between the MN and CN. 163 Local Routing Optimization Response (LRORSP): 165 A reply message from a MAG or LMA confirming the local routing 166 optimization results. 168 3. PMIP6 Local Routing OptimizationScenario Analysis 170 Figure 1 shows the reference architecture for PMIP6 local routing 171 optimization. In this architecture, local communication between 172 PMIPv6 managed nodes (i.e., MAGs) is constrained within a single 173 Provider domain, as described in [I-D.ietf-netext-pmip6-lr-ps]. In 174 the architecture, LMA1 and LMA2 may be the same LMA. 176 +---------+ 177 ============|LMA1/LMA2|============ 178 // +---------+ \\ 179 || || 180 || || 181 || +-----------+ 182 +-----------+ | IPv4/IPv6 | 183 | IPv4/IPv6 | | Network | 184 | Network | +-----------+ 185 +-----------+ || 186 || || 187 || +-----------+ || 188 +------+ |IPv4/IPv6 | +------+ 189 | MAG1 |=============================| MAG2 | 190 +------+ | Network | +------+ 191 | | +-----------+ | | 192 +-----+ +-----+ +-----+ +-----+ 193 | | | | 194 +----+ +-----+ +-----+ +-----+ 195 | MN | | CN1 | | CN2 | | CN3 | 196 +----+ +-----+ +-----+ +-----+ 198 {IPv4-MN-HoA1} {IPv4-CN1-HoA2} {IPv4-CN2-HoA3} {IPv6-CN3-HoA4} 199 {IPv6-MN-HoA1} {IPv6-CN2-HoA3} 201 Figure 1: Reference Architecture for PMIP6 Local Routing 203 Depending on how MN and CN are distributed into different provider 204 domains, three typical scenarios need to be considered as follows: 206 Scenario 1: Intra-MAG local routing 208 In this scenario, both the MN and CN are attached to the same MAG 209 and are anchored with the same LMA or different LMAs. 211 Scenario 2: Intra-LMA local routing 213 In this scenario, the MN and CN are attached to different MAGs and 214 are anchored with the same LMA. 216 Scenario 3: Inter-LMA local routing 218 In this scenario, the MN and CN are attached to different MAGs and 219 are anchored with different LMAs. 221 In all three scenarios, the MN is allowed to roam within the domain 222 in which its anchoring LMA is located or move from one domain to 223 another. The CN should stay with the MN in the same domain; e.g., 224 the MN moves to the visited domain to which the CN belongs. Another 225 example is if the MN and CN move to the same visited domain to which 226 MN's LMA or CN's LMA does not belong. 228 4. Local Routing Optimization Protocol Overview 230 The protocol specified here focuses on intra-MAG local routing and 231 intra-LMA local routing and assumes that 233 o the MAGs are situated in one Provider domain 235 o MN and CN are anchored with the same LMA. 237 o The MAG has the capability to perceive intra-MAG local routing 238 (i.e., the MAG can detect whether the mobile node and 239 correspondent node are attached to the same MAG). 241 o The LMA has the capability to perceive intra-LMA local routing 242 (i.e., the LMA can detect whether the MAGs to which the MN and CN 243 are attached belong to the same or different LMAs). 245 The decision to enable/disable detection of local routing should be 246 based on the policy configured on the MAG or LMA. The trigger for 247 detection of local routing may come from uplink or downlink datagram 248 forwarding or from the application layer. The specific details on 249 how this is achieved are beyond of the scope of this document. 250 Depending on how local routing is initiated, local routing 251 optimization can be categorized into: 253 o MAG-initiated local routing optimization 255 o LMA-initiated local routing optimization 257 4.1. MAG-initiated Local Routing Optimization 259 When the MAG is triggered and enabled to detect local routing, the 260 MAG can detect whether the MN and CN are attached to the same MAG by 261 looking at the source and destination address of outgoing packets and 262 checking the binding update list of the MN and CN. 264 If, upon receiving a packet from the MN or the CN, the MAG perceives 265 that the MN and CN are both attached to the same MAG, it can initiate 266 local routing optimization by asking the LMA to check the value of 267 the Intra-MAG LocalRouting flag (defined in Section 8.1). If the MAG 268 detects that the MN and CN are not attached to the same MAG but wants 269 to check whether intra-LMA routing is allowed (i.e., the MN and CN 270 are attached to different MAGs but anchored to the same LMA), it also 271 can initiate LR by sending a message to the LMA. The message may be 272 a Binding Update message which contains the Local Routing 273 Optimization Mobility Option (Section 9.1) and Home Network Prefix 274 Option [RFC5213] for the correspondent node or a newly defined local 275 routing optimization message. It will be used to negotiate with the 276 LMA to verify whether local routing is allowed and determine what 277 local routing optimization is supported between the mobile node and 278 correspondent node. If the LMA can not determine whether local 279 routing optimization is supported, it may ask AAA server to make 280 decision, and the AAA server may be used to authorize the use of 281 localized routing service for the MN. If LR is not authorized, the 282 LMA will respond to the MAG that local routing optimization is not 283 available. Otherwise, the LMA will set the Intra-MAG LocalRouting or 284 Intra-LMA LocalRouting flag on the MAG by sending a successful 285 response message with the Local Routing Optimization Indication (LRI) 286 field of the Local Routing Optimization Mobility Option set 287 appropriately. If the LMA can validate the Correspondent Node's Home 288 Network Prefix (HNP), the LMA may notify the MN's MAG of the MAG 289 address associated with the CN's HNP using the MN-CNs Pair Mobility 290 Option (Section 9.4) in the same response message. In the intra-MAG 291 local routing case, the MN-CNs Pair Mobility Option can be omitted 292 from the response message. The LMA may also set its own LocalRouting 293 flag to indicate local routing is in use and correlate it with the 294 binding cache entries corresponding to the MN and CN. Note that 295 setting the local routing flag is helpful for avoiding duplication of 296 local routing behavior initiated from the MAG and triggering the MAG 297 to setup a local routing path. Distinguishing between different 298 local routing types on the MAG helps the LMA to build the response 299 message efficiently. For example, when Local Routing Optimization 300 (LRI) field of the Local Routing Optimization Mobility Option is set 301 to the value of one, it means that MAG already knows that the MN and 302 CN are attached to the same MAG by checking binding update list, 303 therefore it is unnecessary to include the CN's MN-CNs Pair Mobility 304 Option; when the LRI field is not set to one, the MN-CNs Pair 305 Mobility Option MUST be included in the response message from LMA, 306 since only the LMA knows the address of the MAG to which the CN is 307 attached. 309 After the successful initiation of local routing optimization, if the 310 MN and CN attach to different MAGs (e.g., MAG1 and MAG2) and the 311 intra-LMA LocalRouting flag on MAG is set to value one, MAG1 may send 312 a PBU message to MAG2 setting the lifetime of the binding of the MN 313 at MAG2. Similarly, if the intra-LMA LocalRouting flag is set to 314 value one on MAG2, MAG2 sends a PBU message to MAG1. This PBU 315 message sets the lifetime of the binding of CN at MAG1. Each PBU 316 MUST be acknowledged with a PBA. With the PBU/PBA exchange, the 317 local data path between MAGs is established and the binding caches 318 associated with MN and CN are set up. A PBU-PBA exchange is repeated 319 to extend the lifetime of the binding. Subsequently the routing 320 table entry can be setup based on the binding caches established on 321 the MAGs. The PBU/PBA signaling is protected using IPsec 322 Encapsulation security payload [RFC4303] in transport mode with 323 mandatory integrity protection. 325 For data traffic, either of the MAGs can lookup the routing table 326 entry associated with the MN or CN and identify the tunnel to the 327 right MAG in terms of the destination address of an outgoing data 328 packet. If MN and CN attach to the same MAG, the traffic from the MN 329 will go directly to the CN via the MAG. If MN and CN attach to 330 different MAGs and register to the same LMA, the traffic from MN will 331 be forwarded directly by the MAG associated with the MN to the MAG 332 associated with the CN. 334 +--+ +------+ +-----+ +------+ +--+ 335 |MN| | MAG1 | | LMA | | MAG2 | |CN| 336 ++-+ +--+---+ +--+--+ +--+---+ +-++ 337 Attach to MAG1 | |Attach to MAG2 338 |---------->| | <------------+ 339 | Datagram | PBU'/LROREQ | | | 340 |==========>|(MN-CN Pair) | | | 341 | |------------->| | | 342 | | +---+-----+ | | 343 | | |BCE Check| | | 344 | PBA'/LRORSP +---------+ | | 345 | | [MAG2] | | | 346 | |<------------ | | | 347 | +-------+---------+ | | | 348 | |Enable Intra-LMA/| | | | 349 | |intra-MAG Routing| | | | 350 | +-------+---------+ | | | 351 | Bidirectional PBU/PBA between MAGs | 352 | |<--------------------------->| | 353 | +-------------+ | +-------------+ | 354 | |Setup Binding| | |Setup Binding| | 355 | |and Tunnel | | | and Tunnel | | 356 | +-------------+ | +-------------+ | 357 | Datagram | Datagram | Datagram | 358 |==========>|============================>|===========>| 359 | Datagram | Datagram | Datagram | 360 |<==========|<=============|==============|<===========| 361 | | | | | 362 | | | | | 364 Figure 2: MAG-initiated Local Routing Optimization 366 4.1.1. Handover Considerations 368 When the MN moves from the old MAG (e.g., pMAG1) in the previous 369 access network to a new MAG (e.g., nMAG1) in the new access network, 370 context information (including the MAG addresses of all the CNs which 371 are communicating with MN) for the MN in pMAG1 may be transferred to 372 nMAG1. The Context Request Option [I-D.ietf-mipshop-pfmipv6] can be 373 reused to carry the context information from pMAG1 to nMAG1. nMAG1 374 can use this data to send PBU messages to each of the MAGs connected 375 to a CN with which the MN was in communication via the provisional 376 secure data path, updating the binding in each MAG with which the MN 377 was in communication and re-establishing an optimal local routing 378 path between the MN and its CNs. 380 +-----+ +---------+ +---------+ 381 |pMAG1| |nMAG1(MN)| | MAG2(CN)| 382 +--+--+ +---+-----+ +---+-----+ 383 | | | 384 | HI/HACK | | 385 |<--------------->| | 386 |Predictive/Reactive | 387 | |Bidirectional PBU/PBA| 388 | |<------------------> | 389 | | | 390 | +------+------+ +-----+-------+ 391 | |UpdateBinding| |UpdateBinding| 392 | | and Tunnel | | and Tunnel | 393 | +------+------+ +-----+-------+ 394 | | Datagram | 395 | |<===================>| 397 Figure 3: MAG-initiated Local Routing During Handover 399 4.2. LMA-initiated Local Routing Optimization 401 When the LMA is triggered and enabled to detect local routing, the 402 LMA can detect whether the MN and CN are registered to the same LMA 403 by looking at the source and destination address of outgoing and 404 incoming packets and checking the binding update list of MN and CN. 406 Upon receiving a packet from the MN or CN and detecting that the MN 407 and CN are registered to the same LMA, it may set its intra-LMA 408 LocalRouting flag, correlating it with the binding cache entries 409 associated with the MN and CN. And then LMA initiates local routing 410 optimization to determine the value of Intra-LMA LocalRouting flag 411 (defined in Section 8.1) on the MAG, i.e., notify or enforce the 412 value of intra-LMA LocalRouting flag on the MAG associated with the 413 MN by means of a LROREQ/LRORSP message exchange. It will be used to 414 help LMA to determine whether the local routing optimization is 415 allowed. If local routing optimization is allowed, then LMA will be 416 responsible for enforcing local optimization on the MAG. The AAA 417 server serving the LMA may be used to authorize the use of localized 418 routing service for the MN. IF LR is not authorized,the LMA will 419 respond to the MAG with failure information indicating that intra-LMA 420 routing optimization is not allowed, otherwise, it will notify the 421 MAG to set the intra-LMA LocalRouting flag. The other procedures are 422 same as those described in Section 4.1. 424 +--+ +------+ +-----+ +------+ +--+ 425 |MN| | MAG1 | | LMA | | MAG2 | |CN| 426 ++-+ +--+---+ +--+--+ +--+---+ +-++ 427 Attach to MAG1 | |Attach to MAG2 428 |---------->| +-------+----------+ <------------+ 429 | | | BCE Check | | | 430 | | |Perceive MAG1 and | | | 431 | | |MAG2 register to | | | 432 | | |the same LMA | | | 433 | | +-------+----------+ | | 434 | | LROREQ | | | 435 | | (MAG2) | | | 436 | |<------------ | | | 437 | +-------+---------+ | | | 438 | |Enable Intra-LMA/| | | | 439 | | Routing | | | | 440 | +-------+---------+ | | | 441 | LRORSP | | | 442 | |------------->| | | 443 | Bidirectional PBU/PBA between MAGs | 444 | |<--------------------------->| | 445 | +-------------+ | +-------------+ | 446 | |Setup Binding| | |Setup Binding| | 447 | | and Tunnel | | | and Tunnel | | 448 | +-----+-------+ | +-----+-------+ | 449 | Datagram | Datagram | Datagram | 450 |==========>|============================>|===========>| 451 | Datagram | Datagram | Datagram | 452 |<==========|<============================|<===========| 454 Figure 4: LMA Initiated Local routing optimization 456 4.2.1. Handover Considerations 458 If the MN moves from the old MAG (e.g., pMAG1) in the previous access 459 network to the new MAG (e.g., nMAG1) in a new access network, nMAG1 460 may update the binding cache entry associated with MN at the LMA by 461 sending a normal PBU message. At the same time, the LMA may refresh 462 the binding update list associated with the MN and update the binding 463 of each MAG with which MN was in communication via the established 464 local route optimization path by sending a LROREQ message to each 465 MAG. Also pMAG1 can use a procedure similar to that described in 466 Section 4.1.1 to transfer MN's registration entry at pMAG1 to nMAG1. 468 +-----+ +---------+ +----------+ +---------+ 469 |pMAG1| |nMAG1(MN)| |LMA(MN,CN)| | MAG2(CN)| 470 +--+--+ +---+-----+ +----+-----+ +---+-----+ 471 | | Normal PBU | | 472 | |-------------->| | 473 | | | | 474 | | Normal PBA | | 475 | |<------------- | LROREQ | 476 | | |-------------->| 477 | | | | 478 | | | LRORSP | 479 | | |<------------- | 480 | Bidirectional PBU/PBA between MAGs 481 | |<----------------------------->| 482 | +------+------+ | +-----+-------+ 483 | |UpdateBinding| | |UpdateBinding| 484 | | and Tunnel | | | and Tunnel | 485 | +------+------+ Datagram +-----+-------+ 486 | |<=============================>| 487 | | | | 489 Figure 5: LMA-initiated Local Routing Optimization During Handover 491 5. Processing Considerations 493 5.1. Mobile Access Gateway Considerations 495 When the MAG sends a LROREQ or PBU to the LMA, it may include the 496 Routing Optimization Mobility and MN-CNs Pair Mobility Options in a 497 binding update message or create a new routing optimization request 498 message to include these two options: 500 o The Routing Optimization Mobility Option is used to negotiate what 501 kind of local routing optimization is available. If intra-MAG 502 local routing is allowed, the LRI field in the Routing 503 Optimization Mobility Option is set to one (1). If the intra-MAG 504 local routing is not available but the MAG would like to check 505 whether intra-LMA local routing is allowed, the MAG will set the 506 LRI field of the Routing Optimization Mobility Option to value 0 507 in the PBU or LROREQ message to the LMA, because the mobile node's 508 MAG does not know whether traffic between MN and CN can be locally 509 routed within one LMA. 511 o The MN-CNs Pair Mobility Option is used for the LMA to verify the 512 validity of the local routing optimization path end points (in the 513 intra-MAG local routing scenario) or to request the LMA to 514 determine the proxy CoA-Address of the Crrespondent Node for local 515 routing optimization (in the intra-LMA local routing scenario). 516 In the case of intra-MAG local routing, MAG should fill the MN-CNs 517 Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP and CN 518 Proxy CoA. In the case of intra-LMA local routing, the MAG only 519 fills MN-CN pairs mobility option with MN's HNP, MN's Proxy CoA 520 and CN's HNP. 522 When the MAG receives a binding acknowledgement message containing 523 the Routing Optimization Mobility Option or routing optimization 524 response message it will check the validity of all the fields, 525 including whether the sequence number value in the acknowledge/ 526 response message is identical to the sequence number value in the 527 corresponding request and whether the MN-CNs Pair Mobility Option is 528 present. If the message is valid, the MAG will extract the LRI field 529 from the Routing Optimization Mobility Option or routing optimization 530 response message and check the value. If the LRI field is zero, it 531 indicates the LMA does not support local routing optimization and the 532 MAG should set the intra-MAG LocalRouting flag to zero in the binding 533 update list extension; if the LRI field is one, it indicates that the 534 LMA allows local routing in one MAG and bypass the LMA and MAG should 535 set intra-MAG LocalRouting flag to value one in the binding update 536 list extension. If the LRI field is two, it indicates LMA has found 537 the Correspondent Node's MAG address in terms of the HNP of the CN. 538 In this case, the MAG should extract the Correspondent Node's MAG 539 address from the initial binding acknowledgement or routing 540 optimization response message and store it in a binding update list 541 extension with the Correspondent Node's HNP and set the intra-LMA 542 LocalRouting flag in the binding update list extension. 544 In LMA-initiated local routing, upon receiving a LROREQ message from 545 the LMA, the MAG extracts MN HNP from MN-CNs Pair Mobility Option and 546 searches the binding update list for a matching IPv6 home network 547 prefix in the list of prefixes it stores for each mobile node that 548 the MAG is serving. If a match is found, the MAG MUST send a PBU 549 message to the MAG of the Correspondent Node. PBU message lifetime 550 is set to the lifetime value in LROREQ message. Destination address 551 is the same as Proxy CoA field in the CN part of MN-CNs Pairs 552 Mobility Option included in LROREQ message. The MAG MUST send a PBU 553 message to the MAG of each Correspondent Node if the LROREQ message 554 contains more than one CN in the MN-CNs Pair Mobility Option. For 555 each PBU message sent to a MAG, a new binding update list entry MUST 556 be created if it has not already been created before, e.g. refresh 557 PBU. The fields in this entry are set as follows: 559 o Mobile Node information fields like MN-Identifier, link-layer 560 identifier, home network prefixes, etc., are copied from the entry 561 that was created during the initial PBU procedure. 563 o The IPv6 address of the LMA serving the attached mobile node is 564 replaced with the Proxy-CoA of the MAG to which the PBU was sent 565 and Proxy-CoA field in the Correspondent Node part of the MN-CN RO 566 Option is copied to this field. The IP address of the 567 Correspondent Node to which MN is communicating is set to the Home 568 Network Prefix field of the Correspondent Node part of the MN-CNs 569 Pair Mobility Option. If the P bit is set in the MN-CNs Pair 570 Mobility Option, this field is set to the IPv4 HoA field in the 571 Correspondent Node part of MN-CNs Pair Mobility Option. 573 o The initial value of the Binding Lifetime field is set to the 574 Lifetime field in the LROREQ message. 576 o A configuration variable called EnableLMALocalRouting is defined 577 at the MAGs to indicate whether or not the MAG is allowed to 578 enable local routing of the traffic exchanged between a visiting 579 MN that is locally connected to one of the interfaces of the 580 mobile access gateway and a CN that is locally connected to one of 581 the interfaces of another mobile access gateway that is connected 582 to the same LMA. Any LROREQ message received from LMA with 583 lifetime greater than zero enables the local routing at this MAG 584 and the MAG that receives LROREQ first time MUST set 585 EnableLMALocalRouting to 1. 587 When the Intra-MAG LocalRouting flag or Intra-LMA LocalRouting flag 588 are set on the MAGs, one MAG may send a Proxy Binding Update message 589 to another MAG to establish a corresponding binding cache associated 590 with the MN and CN. Upon receiving a Proxy Binding Update message, 591 the MAG checks if the LocalRouting flag is set to value one. If the 592 LocalRouting flag is not set to value one, the MAG MUST reject the 593 request and send a Proxy Binding Acknowledgement message with the 594 status field set to 129 (administratively prohibited). 596 Upon accepting a Proxy Binding Update request, the MAG MUST create a 597 Binding Cache entry. The Source address in the Proxy Binding Update 598 is copied to the Proxy CoA field of the binding cache entry. The 599 Mobile Node data (MN-Identifier, link-layer identifier, link-local 600 address, home network prefixes, etc.) are copied from the 601 corresponding fields of the proxy binding update. 603 Upon accepting a Proxy Binding Update request for the first time from 604 another MAG, the MAG MUST establish a bi-directional tunnel between 605 the two MAGs. The tunnel endpoints are the Proxy-CoA of the 606 receiving Mobile Access Gateway and the Proxy-CoA of the Mobile 607 Access Gateway that sent the PBU, which can be obtained from the 608 source address of the PBU message. This tunnel SHOULD be deleted 609 when there are no Mobile Nodes sharing it or when a Mobile Access 610 Gateway receives a PBU message from another MAG with lifetime set to 611 zero or when the MAG receives a LROREQ message from the corresponding 612 LMA with the lifetime set to zero. 614 In case of handover or detachment, if the MAG cannot detect the 615 presence of the mobile node on the connected link, the MAG SHOULD 616 terminate the binding of the MN by sending a PBU message to all CN's 617 MAGs that has established bindings. The MAG sends a PBU message to 618 each MAG with lifetime set to zero. Proxy-CoA of the MAG field in 619 each Binding update list entry determines the MAG address. If IPv4 620 transport is used, IPv4-Proxy-CoA is used. The MAG MUST also remove 621 each Binding Update List entry on all CN's MAGs created for that MN. 623 In order to re-establish the bindings of the MN that is involved in 624 local routing, i.e. with binding update list entries on the new MAG 625 other than the home (local mobility anchor registration), the 626 previous MAG MAY use a context transfer procedure to transfer the 627 local routing state to the new MAG. Each entry in the binding update 628 list for this MN other than the LMA entry can be transferred. After 629 handover is completed, the new MAG MUST send PBU messages to the MAG 630 (Proxy-CoA or IPv4-Proxy-CoA) associated with each Correspondent 631 Node. Another way to re-establish the bindings of the MN is to have 632 the new MAG trigger the LMA to notify all the CN's MAGs to update 633 binding update list on all CN's MAGs created for that MN. 635 For the data traffic between the MN and CN, on receiving a packet 636 from a MN connected to its access link, to a destination (i.e., CN) 637 that is directly connected or not directly connected to the same 638 access link, the MAG will check whether source/destination address 639 pairs in the routing table entry matches the source/destination 640 address in the outgoing data packet and identify the tunnel to the 641 right destination MAG. If the source address and destination address 642 in the packet match one of source/destination address pairs in the 643 routing entry, the packet must be tunneled to the Proxy CoA 644 corresponding to the destination address in the tunnel interface. 645 For the packet from a Mobile Node connected to its access link to a 646 destination that is also directly connected to the same access link, 647 the packet must go directly via the MAG. 649 5.2. Local Mobility Anchor Considerations 651 In the case of MAG initiating local routing, upon receiving a PBU or 652 routing optimization request message, the LMA will check the LRI 653 field in the Routing Optimization Mobility Option or routing 654 optimization message. If the LRI field is set to value one, the LMA 655 will check whether there exist a binding cache list for the CN and 656 whether the MN's proxy CoA address is same as the CN's proxy CoA 657 address. If LRI field is zero and the Correspondent Node's home 658 network prefix is included, the LMA will check whether there exists a 659 binding cache list for CN in terms of the correspondent node's home 660 network prefix. If one does, the LMA will fill the MN-CNs Pair 661 Mobility Option with the Proxy CoA and HNP of the CN and respond to 662 the MAG with LRI field set to value two. Otherwise, the LMA will 663 respond to the MAG with the LRI field set to zero to indicate the MAG 664 that local routing optimization is not available. 666 In the case of LMA-initiated local routing, the LMA may be 667 responsible for perceiving intra-LMA routing and correlate MN with CN 668 in the binding update list. Upon perceiving that intra-LMA local 669 routing is allowed between the MN and CN, the LMA fills the MN-CNs 670 Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP, CN Proxy CoA 671 and includes it in the Local Routing Optimization Request 672 message(LROREQ). In the message, the LRI field set to value two. 673 Then the LMA receives routing optimization reply message from the 674 corresponding MAG. 676 The LMA MUST send a LROREQ message to either or both of MAGs where MN 677 and CN are located. If CN (or MN) is not connected to the same LMA, 678 the LROREQ message MUST be sent to only to the MAG that is connected 679 to the LMA. The LROREQ message MUST contain at least one pair of MN- 680 CNs Pair Mobility Options. If the MN is communicating with more than 681 one CN which is regitered with the same LMA, the LMA MUST include 682 more than one CN in the MN-CNs Pair Mobility Option if local routing 683 will be enabled. Before the LROREQ is sent to a MAG, the LMA MUST 684 place the MN address information which is connected to this MAG first 685 in MN-CNs Pair Mobility Option. 687 The LMA MAY set the Lifetime field in the LROREQ message to a non- 688 zero value. Any non-zero lifetime value enables two MAG to start 689 local routing optimization for MN-CN traffic. The lifetime values 690 sent to two MAG MUST be the same. 692 The LMA MAY stop the local routing optimization operation any time it 693 wishes. In that case LMA MUST set the Lifetime field in LROREQ 694 message to zero. After receiving a LRORSP message from the MAG with 695 a matching sequence number field, the LMA-MAG tunnel needs to be re- 696 established separately for each MAG. 698 The LMA sets the sequence number field in LROREQ message to a nonzero 699 integer. This initial sequence number is incremented by one for the 700 next LROREQ message sent. The LMA MUST receive a LRORSP message with 701 the same sequence number as in the corresponding LROREQ message 702 previously sent. This message is acknowledged with a LROREQ message. 703 If no acknowledgement is received, the LMA MUST retransmit the LROREQ 704 message. 706 6. IPv4 Support 708 IPv4 support is needed in two cases: 710 o The MN is IPv4 enabled and receives an IPv4 home address and 712 o The transport network between the LMA and the MAG is an IPv4 713 network 715 In both two cases, the encapsulation mode as described in 716 [I-D.ietf-netlmm-pmip6-ipv4-support] is transparent to the MAG 717 concerned before setting up the localized routing path. This may 718 result in data packets being dropped by the egress/ingress tunnel end 719 points, i.e., the MAGs. 721 Therefore local route optimization can be supported only if the 722 encapsulated mode is aware or default configured during setting up 723 the localized routing path. 725 6.1. IPv4 HoA Support 727 If the MN is IPv4-enabled and receives an IPv4 home address, both the 728 MN and the CN configure global IPv4 home addresses by exchanging PBU/ 729 PBA between the MAG and the LMA as explained in 730 [I-D.ietf-netlmm-pmip6-ipv4-support]. 732 The LMA MUST include the IPv4 IPv4-MN-HoA in local routing 733 optimization messages for both MN and CN. The LMA MAY include the 734 Home Network Prefix in PBA if the MN or CN has been assigned one. 735 Both local routing optimization request and local routing 736 optimization response messages are IPv6 messages and are transported 737 over the LMA-MAG tunnel in the same fashion as the PBU and PBA 738 messages. 740 The PBU and PBA exchanged between the MAGs are IPv6 messages and are 741 transported as unencapsulated IPv6 messages between MAGs. For 742 simplification, we can assume the MAGs in communication are using the 743 default encapsulation mode. Data traffic between the MAGs after 744 local routing is established is transported in the IPv6 inner packet 745 as IPv4 payload. 747 6.2. IPv4 Transport Support 749 If IPv4 transport is used between the MAG and the LMA, the LROREQ, 750 LRORSP, PBU and PBA messages are transported as IPv6 messages using 751 IPv4 or IPv4-UDP-ESP encapsulation 752 [I-D.ietf-netlmm-pmip6-ipv4-support]. IPv4-UDP and IPv4-UDP-TLV 753 modes are not used because no NAT boxes are supported in this local 754 routing optimization protocol. IPv4 data packets are transported in 755 an IPv4 packet or encapsulated in IPv4-UDP-ESP encapsulation. 757 7. Inter-LMA Local Routing Considerations 759 In this section we concentrate on the case where the MN and CN are 760 served by two different LMAs in the same Provider domain, which is 761 not covered by Section 4and Section 5. 763 7.1. MAG-initiated Inter-LMA Local Routing 765 If the MAG to which the MN and CN are attached is registered to 766 different LMAs, it needs to initiate local routing optimization to 767 the different LMAs respectively. The message exchange for the 768 protocol is shown in Figure 6. LR is triggered at one of the MAGs 769 (e.g., MAG1) when a datagram is received on its upstream interface 770 whose destination address is a CN for which LMA2 has a binding cache 771 entry. MAG1 requests the address of LMA2 from LMA1 by sending a 772 LROREQ message containing the HNP of the CN. LMA1 processes the 773 LROREQ message and looks up the address of LMA2 based on the HNP or 774 HoA of the CN. There is one possible way to achieve this goal: 776 o LMA1 can exchange with a AAA server to retrieve the address of 777 LMA2. LMA1 sends the address of the CN and requests the address 778 of the LMA to which the CN is anchored. The AAA server responds, 779 sending the address of LMA2 to LMA1. See [I-D.wu-dime-pmip6-lr] 780 for further details. 782 Note that LMA2 address discovery is only performed once, i.e., when 783 LMA1 does not know LMA2 address at the first time. If discovery is 784 successful, the address of LMA2 will be correlated with the HNP of 785 the CN in the Mobile Nodes's binding update list for future use. 787 Upon retrieving the address of LMA2, LMA1 then delivers it to MAG1 by 788 means of an LRORSP message. MAG1 then sends LROREQ message 789 containing a MN-CNs Pair Mobility Option (defined in Section 9.4) to 790 LMA2. Note that MN-CNs Pair Mobility Option does not contain the CN 791 Proxy CoA. LMA2 processes the LROREQ message and looks up MAG2 792 address based on CN HNP or HoA extracted from the message. If the 793 lookup is successful, LMA2 responds to the MAG1 with the address of 794 the MAG to which the CN is attached (i.e., the address of MAG2). 795 MAG1 and MAG2 exchange PBU/PBA messages to establish binding cache 796 list between each other and the direct path between MAG1 and MAG2 797 will be set up. 799 +------+ +----------+ +---------+ +------+ 800 | MAG1 | | LMA1(MN) | | LMA2(CN)| | MAG2 | 801 +---+--+ +----+-----+ +----+----+ +---+--+ 802 | |LMA2 Discovery | | 803 | |-----> | | 804 | | | | 805 | LROREQ(CN) | | | 806 |--------------->| | | 807 | | | | 808 | LRORSP(LMA2) | | | 809 |<---------------+ | | 810 | LROREQ(MN,MAG1,CN) | | 811 |------------------------------->| | 812 | LRORSP(CN,MAG2) | | 813 |<-------------------------------| | 814 | | | | 815 |<------------MAGs Exchange PBU/PBA-------------->| 816 | | | | 818 Figure 6: MAG Initiated Inter-LMA Local routing 820 Editor's Note: 821 LMA-initiated Inter-LMA local routing is described in the Appendix 822 for future extension. In LMA-initiated Inter-LMA local routing, 823 the setup of a local routing path depends on LMA-LMA 824 communication. 826 8. Conceptual Data Structure Extensions 828 8.1. Binding Update List Extensions 830 Every Mobile Access Gateway maintains a Binding Update List. Each 831 Entry in the Binding Update List represents a mobile node's mobility 832 binding with its Local Mobility Anchor, as described in Section 6.1 833 of the PMIPv6 specification [RFC5213]. This specification extends 834 the Binding Update List Entry data structure with the following 835 additional fields: 837 Intra-MAG LocalRouting Flag 838 This flag indicates whether media delivery optimization is allowed 839 by locally routing packets within one MAG. The flag is set to the 840 value 1 if local media delivery optimization is allowed and 0 if 841 it is not. 843 Intra-LMA LocalRouting Flag 844 This flag indicates whether media delivery optimization is allowed 845 by locally routing packets from one MAG to another within one LMA. 846 The flag is set to the value 1 if local media delivery 847 optimization is allowed and 0 if it is not. 849 Inter-LMA LocalRouting Flag 850 This flag indicates whether media delivery optimization is allowed 851 by locally routing packets from a MAG served by one LMA to another 852 MAG served by a different LMA. The flag is set to the value 1 if 853 local media delivery optimization is allowed and 0 if it is not. 855 8.2. Binding Cache Entry Extensions 857 Every Local Mobility Anchor MUST maintain a Binding Cache Entry for 858 each currently registered mobile node. To support LR, the Binding 859 Cache Entry data structure needs to be extended with the following 860 additional fields: 862 Intra-LMA LocalRouting Flag 863 This flag indicates whether media delivery optimization is allowed 864 by locally routing packets from one MAG to another within one LMA. 865 The flag is set to the value 1 if local media delivery 866 optimization is allowed and 0 if it is not. 868 Inter-LMA LocalRouting Flag 869 This flag indicates whether media delivery optimization is allowed 870 by locally routing packets from a MAG served by one LMA to another 871 MAG served by a different LMA. The flag is set to the value 1 if 872 local media delivery optimization is allowed and 0 if it is not. 874 8.3. Routing Table Entry Extensions 876 Every mobile access gateway and local mobility anchor MUST maintain a 877 Routing Table entry for each currently registered mobile node: 879 o The Home Address assigned to the Correspondent Node 881 o The Home Address assigned to the Mobile Node 883 o The tunnel interface assigned to the data path between the Mobile 884 Node and the Correspondent Node 886 9. Local Routing Optimization Message Format 888 9.1. Local Routing Optimization Mobility Option 890 0 1 2 3 891 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Type = TBD | Length | Reserved |LRI| 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Figure 7: Local Routing Optimization Mobility Option 898 Type: 900 TBD 902 Length: 904 8-bit unsigned integer indicating the length of the option in 905 octets, excluding the Type and Length fields. This field MUST be 906 set to 2. 908 Reserved (R): 910 This 8-bit field is unused for now. The value MUST be initialized 911 to 0 by the sender and MUST be ignored by the receiver. 913 Local Routing Optimization Indication (LRI): 915 00: 917 Routing optimization state is unknown or routing optimization 918 is not available. 920 01: 922 The value of Intra-MAG LocalRouting 924 10: 926 The value of Intra-LMA LocalRouting 928 11: 930 The value of Inter-LMA LocalRouting 932 9.2. The Local Routing Optimization Request (LROREQ) Message 934 The Local Routing Optimization Request message is used by one PMIP6 935 managed node (LMA or MAG) to negotiate with another PMIP6 managed 936 node (MAG or LMA) whether and what local routing is allowed. 938 0 1 2 3 939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Sequence # | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |R|LRI|B| Reserved | Lifetime | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | | 946 ~ Mobility options ~ 947 | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Figure 8: Local Routing Optimization Request Message 952 Sequence Number: 954 A monotonically increasing integer. Set by a sending node in a 955 request message, and used to match a reply to the request. 957 'R' flag: 959 Set to 0, this flag indicates a routing optimization request 960 message. 962 Bulk Localized Routing Flag (B): 964 If the Bulk Localized Routing Flag (B) is set to 1, then the 965 LROREQ message is a message requesting the MAG or LMA to establish 966 local routing optimization paths between the MN and multiple CNs 967 which are communicating with the MN; the MN-CNs Pair Mobility 968 Option will be used to carry one MN and more than one CN. If the 969 bulk localized routing flag is set to 0, then the LROREQ message 970 is a message requesting the MAG or LMA to establish a local 971 routing optimization path between one MN and CN. 973 Local Routing Optimization Indication (LRI): 975 00: 977 Routing optimization state is unknown or routing optimization 978 is not available 980 01: 982 The value of Intra-MAG LocalRouting 984 10: 986 The value of Intra-LMA LocalRouting 988 11: 990 The value of Inter-LMA LocalRouting 992 Lifetime: 994 The requested period in seconds for which the sender wishes local 995 routing to be active. 997 9.3. Local Routing Optimization Response Message (LRORSP) 999 The Local Routing Optimization Response message is used to 1000 acknowledge the receipt of a Local Routing optimization Request 1001 message (described in Section 9.2). 1003 0 1 2 3 1004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Sequence # | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |R|LRI|B| Reserved | Lifetime | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | | 1011 ~ Mobility options ~ 1012 | | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 Figure 9: Local Routing Optimization Response Message 1017 Sequence Number: 1019 A monotonically increasing integer. Set by a sending node in a 1020 request message, and used to match a reply to the request. 1022 'R' flag: 1024 Set to 0, indicates it is an routing optimization request message. 1025 Set to 1, indicates it is an routing optimization response 1026 message. 1028 Bulk Localized Routing Flag (B): 1030 If the Bulk Localized Routing Flag (B) is set to 1, then the 1031 LROREQ message is a message requesting the MAG or LMA to establish 1032 local routing optimization paths between the MN and multiple CNs 1033 which are communicating with the MN; the MN-CNs Pair Mobility 1034 Option will be used to carry one MN and more than one CN. If the 1035 bulk localized routing flag is set to 0, then the LROREQ message 1036 is a message requesting the MAG or LMA to establish a local 1037 routing optimization path between one MN and CN. 1039 Local Routing Optimization Indication (LRI): 1041 00: 1043 Routing optimization state is unknown or routing optimization 1044 is not available 1046 01: 1048 The value of Intra-MAG LocalRouting 1050 10: 1052 The value of Intra-LMA LocalRouting 1054 11: 1056 The value of Inter-LMA LocalRouting 1058 Lifetime: 1060 The requested period in seconds for which the sender wishes local 1061 routing to be active. 1063 Mobility Options: 1065 The Local Routing Optimization Mobility Option described in 1066 Section 9.1 and MN-CNs Pair Mobility Option described in 1067 Section 9.4 can be included. 1069 9.4. MN-CNs Pair Mobility Option 1071 The MN-CNs Pair Mobility Option is defined for use with the Local 1072 Route Optimization Request Section 9.2 and Local Route Optimization 1073 Response Section 9.3 messages exchanged between the LMA and MAGs. 1074 This option is used by the PMIP6 managed node to enable local routing 1075 for MN to CNs path from the destination MAG that receives the request 1076 message towards CNs connected a different MAG. The addresses of the 1077 target Correspondent Nodes are given in the option. The option MUST 1078 be used in pairs including one MN, one or many CNs in communication 1079 with MN. The order is important. The LMA places the data for the MN 1080 first in the MN-CNs Pair Mobility Option. 1082 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Type | Length |P| Reserved |Prefix Length | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | | 1087 + + 1088 | | 1089 + Home Network Prefix + 1090 | | 1091 + + 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 + + 1096 | | 1097 + Proxy CoA + 1098 | | 1099 + + 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | IPv4 HoA | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | IPv4 Proxy CoA | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 Figure 10: MN-CNs Pair Mobility Option 1109 P Flag: 1111 The 'P' flag is set for IPv4 support. When set, the IPv4 HoA and 1112 IPv4 Proxy CoA fields MUST be included for the MN or CN. 1114 Reserved: 1116 This 7-bit field is unused for now. The value MUST be initialized 1117 to 0 by the sender and MUST be ignored by the receiver. 1119 Prefix Length: 1121 8-bit unsigned integer indicating the prefix length of the IPv6 1122 prefix contained in the option. 1124 Home Network Prefix: 1126 A sixteen-byte field containing the mobile or corresponding node's 1127 IPv6 Home Network Prefix. 1129 Proxy CoA: 1131 A sixteen-byte field containing the global address configured on 1132 the egress interface of the mobile access gateway to which the 1133 mobile or corresponding node is connected. 1135 IPv4 HoA: 1137 Optional 32-bit field containing the IPv4 home address of the 1138 mobile or corresponding node. 1140 IPv4 Proxy CoA: 1142 Optional 32-bit field containing the IPv4 address that is 1143 configured on the egress-interface of the mobile access gateway. 1145 10. Security Considerations 1147 The protocol specified in this document can use the security 1148 association between the LMA and the MAG to create security 1149 associations between MAGs to which MN and CN attach in the intra-LMA 1150 local routing scenario. As regarding the intra-MAG local routing 1151 scenario, integrity protection can be considered and confidentiality 1152 using IPsec is not necessary. 1154 In the handover case, the security association between the new MAG 1155 and a particular LMA should be pre-established when the MN arrives at 1156 the new MAG. A particular LMA can be any LMA serving the MN or CN. 1157 MAG initiated inter-LMA local routing may depend on the security 1158 association between MN's new MAG and CN's LMA during handover. 1160 In order to setup a local routing path, MN's MAG may exchange PBU/PBA 1161 with CN's MAG. CN's MAG needs to know that the prefix extracted from 1162 the MN-CNs Pair Mobility Option in the PBU is owned by the MN and 1163 that the MN's MAG is actually proxying this prefix. Prefix ownership 1164 validation may be required during PBU/BPA exchange to ensure that a 1165 valid routing state can be created on the CN's MAG. It is the same 1166 case when CN's MAG exchanges PBU/PBA with MN's MAG. 1168 11. IANA Considerations 1170 TBD. 1172 12. Acknowledgements 1174 The authors would like to thank Tom Taylor, Kent Leung, Sri 1175 Gundavelli, Jouni Korhonen, Mohana Jeyatharan, for their comments on 1176 this draft. Speically thanks to Glen Zorn for providing useful 1177 reviews. 1179 13. References 1181 13.1. Normative References 1183 [I-D.ietf-mipshop-pfmipv6] 1184 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 1185 Xia, "Fast Handovers for Proxy Mobile IPv6", 1186 draft-ietf-mipshop-pfmipv6-12 (work in progress), 1187 December 2009. 1189 [I-D.ietf-netlmm-pmip6-ipv4-support] 1190 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1191 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 1192 (work in progress), September 2009. 1194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1195 Requirement Levels", BCP 14, RFC 2119, March 1997. 1197 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1198 in IPv6", RFC 3775, June 2004. 1200 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1201 RFC 4303, December 2005. 1203 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1204 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1206 13.2. Informative References 1208 [I-D.ietf-netext-pmip6-lr-ps] 1209 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 1210 Routing Problem Statement", 1211 draft-ietf-netext-pmip6-lr-ps-02 (work in progress), 1212 January 2010. 1214 [I-D.wu-dime-pmip6-lr] 1215 Wu, W. and G. Zorn, "AAA Support for PMIP6 mobility 1216 entities Locating and Discovery during localized routing", 1217 draft-wu-dime-pmip6-lr-01 (work in progress), 1218 October 2009. 1220 Appendix A. Future Extension 1222 A.1. LMA Route Optimization Start Message 1224 A.1.1. LMA Route Optimization Start Request Message 1226 0 1 2 3 1227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Sequence Number | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Reserved | Lifetime | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | | 1234 . . 1235 . Mobility options . 1236 . . 1237 | | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 Figure A.1.1. LMA Route Optimization Start Request Message 1241 A new MH type should be assigned by IANA. 1243 Sequence Number 1244 16-bit unsigned integer. The LMA uses this field to match a 1245 returned LMAROStartRsp message. The LMA also uses this field to 1246 identify each new pairs of MN-CN to start local routing if the LMA 1247 received LMAStartRORsp message. 1249 Reserved 1250 This field is unused. It SHOULD be initialized to zero by the 1251 sender and MUST be ignored by the receiver. 1253 Lifetime 1254 16-bit unsigned integer. If non-zero, this fields indicates the 1255 initial lifetime of the MN to CN route optimization binding. If 1256 there are several MN-CN pairs, the same lifetime applies to each 1257 pair. 1259 Mobility Options 1260 As defined in section 6.1.7 of RFC 3775 [RFC3775]. 1262 This document defines a new mobility option: MN-CN RO option in 1263 Section 9.4. The sending LMA sends a pair of MN-RO Options. LMA 1264 sets Home Network Prefix value of the first MN-RO Option to HNP for 1265 MN and Proxy-CoA value to Proxy-CoA1. The LMA sets Home Network 1266 Prefix value of the second MN-RO Option to HNP of CN and Proxy-CoA 1267 value to zero. 1269 A.1.2. LMA Route Optimization Start Response Message 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Sequence Number | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Reserved | Lifetime | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | | 1277 . . 1278 . Mobility options . 1279 . . 1280 | | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Figure A.1.2. LMA Route Optimization Start Response Message 1284 A new MH type should be assigned by IANA. 1286 Status An 8-bit unsigned integer indicating the disposition of 1287 LMAROStartReq message by the receiving LMA. Values less than 128 1288 indicate that ROStartReq message was accepted by the LMA. Values 1289 greater than 128 indicate that LMAROStartReq message was rejected 1290 by LMA. 1292 Sequence number and Lifetime fields are as defined above for 1293 LMAROStartReq message. 1295 Mobility Options contain pairs of MN-CN RO Option as defined in 1296 Section 9.4. The LMA must copy this field from LMAROStartReq 1297 message when status field contains a value indicating success. 1298 The LMA MUST search its binding cache for the Home Network Prefix 1299 value of CN and find the corresponding MAG address, e.g. Proxy- 1300 CoA2. Th LMA MUST replace MAG address field set to zero by the 1301 sending LMA with Proxy- CoA2. 1303 A.2. LMA Initiated Inter-LMA Local Routing 1305 The message exchange for the protocol is shown in Figure A.2. Inter- 1306 LMA Local routing is triggered at one of the LMAs, e.g. LMA1 when a 1307 datagram is received on its upstream interface whose destination 1308 address is a MN, e.g. MN1 for which LMA1 has a binding cache entry. 1309 From the binding cache entry, LMA1 determines the MAG address, e.g. 1310 MAG1 (Proxy-CoA1). LMA1 checks the source address to find out if the 1311 datagram is coming from a MN located in the same Provider domain and 1312 if yes, its MAG address, e.g. MAG2 (Proxy-CoA2). There are several 1313 ways for doing this and the exact means is out of scope with the 1314 document. Below we will mention two different ways. 1316 (a) LMAs in the same Provider domain are configured with a table 1317 containing a list of /48, /32, etc. prefixes and the 1318 corresponding LMA address for all the LMAs in the domain. LMA1 1319 searches this table doing a longest prefix match based on the 1320 prefix part of the source address of MN2 and finds the 1321 corresponding LMA2 address. 1323 (b) LMA1 can exchange with the AAA server to retrieve LMA2 address. 1324 LMA1 sends MN2 address and asks LMA address this MN is attached 1325 to. LMA1 receives LMA2 address and MAG address (Proxy-CoA2) 1326 from AAA server, e.g.DIAMETER server. 1328 LMA1 sends LMAROStartRequest message to LMA2. LMAROStartRequest 1329 message contains MN1 and MN2 address and MAG1 address (Proxy-CoA1). 1330 MAG2 address is set to zero. LMA2 searches its BCE for MN2 and 1331 determines MAG2 address (Proxy-CoA2). LMA2 sends LMAROStartResponse 1332 message to LMA1. LMAROStartResponse message contains MN1 and MN2 1333 address and MAG1 address (Proxy-CoA1) and MAG2 address (Proxy-CoA2). 1335 LMA1 sends LROREQ message to MAG1 at Proxy-CoA1. LROREQ message 1336 contains MN address and Proxy- CoA1 and CN address, e.g. MN2 and 1337 Proxy-CoA2. LMA2 sends LROREQ message to MAG2 at Proxy-CoA2. LROREQ 1338 message contains CN address, e.g. MN2 and Proxy-CoA2 and MN address, 1339 e.g. MN1 and Proxy-CoA1. LROREQ messages enable both MAGs to modify 1340 their Binding Update Lists. The two MAGs respond LROREQ with LRORSP 1341 messages. 1343 The two MAGs, MAG1 and MAG2 exchange PBU/PBAs as described in 1344 Section 4. 1346 +------+ +----------+ +---------+ +------+ 1347 | MAG1 | | LMA1(MN) | |LMA2(CN) | | MAG2 | 1348 +---+--+ +----+-----+ +----+----+ +---+--+ 1349 | | | | 1350 | | LMAROStartReq | | 1351 | |-------------->| | 1352 | | | | 1353 | | LMARoStartRsp | | 1354 | |<------------- | | 1355 | LROREQ | | LROREQ | 1356 |<---------------| |--------------->| 1357 | | | | 1358 | LRORSP | | LRORSP | 1359 |--------------->| |<-------------- | 1360 | | | | 1361 |<--------------MAGs exchange PBU/PBA------------>| 1362 | | | | 1363 | | | | 1364 Figure A.2. LMA Initiated Inter-LMA Local routing 1366 A.2.1. IPv4 Support Consideration 1368 IPv4 support presented in Section 6 also applies here. In addition, 1369 we discuss IPv4 support issues related to LMAROStartRequest and 1370 LMAStartResponse messages. LMAROStartRequest and LMAStartResponse 1371 messages are IPv6 messages. These messages are transported in IPv6 1372 because LMAs support IPv6 and there is IPv6 transport established 1373 among LMAs in the same Provider domain. 1375 A.3. LMA Initiated operation for Inter-LMA Local Routing 1377 Local mobility anchor MUST send LMAROStartReq message to another 1378 local mobility anchor in the same Provider domain. LMAROStartReq 1379 message MUST contain at least one pair of MN-CN RO Option. Local 1380 mobility anchor MUST place the mobile node address information which 1381 is connected to this local mobility anchor first in MN-CN RO Option. 1383 Local mobility anchor MAY set lifetime field in LMAROStartReq message 1384 to a non zero value. Any nonzero lifetime value enables the 1385 receiving local mobility anchor to start local routing optimization 1386 for MN-CN traffic by sending LROReq message to the mobility access 1387 gateway to which CN is connected as the local mobility anchor 1388 determines by searching its binding cache. 1390 After receiving LRORes from the mobile access gateway, the local 1391 mobility anchor MUST send LMAROStartRes to the originating local 1392 mobility anchor. LMAROStartRes MUST contain MN-CN Option RO pair in 1393 which the first contains MN and its mobility access gateway address 1394 info which is copied from LMAROStartReq message and the second 1395 contains CN address which is copies from LMAROStartReq and its 1396 mobility access gateway address which this local mobility gateway 1397 provides. 1399 Local mobility anchor MAY set lifetime field in LMAROStartRes to the 1400 same value as LMAROStartReq lifetime field value. Local mobility 1401 anchor MAY set lifetime field in LMAROStartRes to a different value. 1402 The lifetime field in LMAROStartRes becomes the final value and local 1403 mobility anchor MUST set lifetime value in LROReq message that it 1404 sends to MN's mobility access gateway. 1406 In case the simplified route optimization involves two local mobility 1407 gateways, the initiating local mobility anchor MAY stop the route 1408 optimization any time it wishes. The initiating local mobility 1409 anchor MUST send LMAROStartReq message to the destination local 1410 mobility anchor with lifetime field set to zero. The destination 1411 local mobility anchor sends LMAROStartRes with lifetime set to zero. 1412 Both local mobility anchors send LROReq messages to the corresponding 1413 mobility access gateways with lifetime set to zero. Both local 1414 mobility anchors reestablish the tunnel with mobility access gateways 1415 for MN and CN, respectively. 1417 Local mobility anchor sets the sequence number field in LMAROStartReq 1418 message to a nonzero integer. This initial sequence number is 1419 incremented by one for the next LMAROStartReq message sent. Local 1420 mobility anchor MUST receive LMAROStartRes message with the same 1421 sequence number as in LMAROStartReq message previously sent. This 1422 message acknowledges LMAROStartReq message. If no ack is received 1423 local mobility anchor MUST retransmit LMAROStartReq message. In a 1424 normal mode of operation local mobility anchor has one outstanding 1425 LMAROStartReq messages because they are sent to the other local 1426 mobility anchor in the same Provider domain. 1428 Appendix B. Change Notes 1430 Changes in version 04. 1432 o Move LMA Initiated inter-LMA local routing to appendix A 1434 o Some Editorial Revision. 1436 o Additional text about MAG operation and LMA operation in section 5 1437 and appendix A.3. 1439 o Remove NAT Aspect and private IPv4 aspect in this document. 1441 o Additional text about Routing Table extension and Bulk localized 1442 routing Flag. 1444 Changes in version 05. 1446 o Some Editorial changes. 1448 o Consistent with I-D.ietf-netext-pmip6-lr-ps on terminology using 1450 o Incorporate prefix ownsership validation into the section of 1451 "security consideration". 1453 Authors' Addresses 1455 Qin Wu 1456 Huawei Technologies Co.,Ltd 1457 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 1458 Nanjing, Jiangsu 21001 1459 China 1461 Phone: +86-25-84565892 1462 Email: Sunseawq@huawei.com 1464 Behcet Sarikaya 1465 Huawei Technologies Co.,Ltd 1466 1700 Alma Drive, Suite 500 1467 Plano, TX 75075 1468 USA 1470 Email: sarikaya@ieee.org