idnits 2.17.1 draft-oulai-netext-opt-local-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the MAG accepts to apply local routing, it sends a LRA message to the LMA to acknowledge the Local Routing. At this point, the LMA MUST not modify the binding of the MN as other communications MAY still go through the LMA. The LMA MUST record that there is an ongoing Local Routing session and also the involved MAGs and MNs. How the charging is done when local routing is in place is out of scope of this document. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the target MAG is different from MAG2, MAG2 sends a refresh PBU message to the LMA containing a new flag indicating a possible movement. When receiving this PBU, the LMA MUST not update the BCE but rather abort the Local Routing sessions by sending a deregistration LRI message to MAG1. Therefore, MAG1 switches back the traffic towards the LMA. At this time, the traffic is asymmetric as the local routing from MAG2 to MAG1 is unaffected. When the LMA receives the PBU indicating the new attach point of MN2, it can start over a new Local Routing session between MN1 and MN2. Figure 3 shows this mechanism. Even if we refer to this method as non-optimized, it allows to reduce packet loss and handover delay. Another option could be for the LMA to send to MAG1 a LRI to directly set up the tunnel towards MAG3. -- The document date (October 26, 2009) is 5295 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-pfmipv6-09 == Outdated reference: A later version (-06) exists of draft-ietf-netext-pmip6-lr-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-netext-pmip6-lr-ps (ref. 'I-D.ietf-netext-pmip6-lr-ps') ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext Working Group D. Oulai 3 Internet-Draft S. Krishnan 4 Intended status: Standards Track Ericsson 5 Expires: April 29, 2010 October 26, 2009 7 Optimized Local Routing for PMIPv6 8 draft-oulai-netext-opt-local-routing-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Base Proxy Mobile IPv6 requires all communications to go through the 47 local mobility anchor. As this can be suboptimal, local routing has 48 been defined to allow mobile nodes attached to the same or different 49 mobile access gateways to exchange traffic by using local forwarding 50 or a direct tunnel between the gateways. This document proposes an 51 initiation method and fast handover mechanisms for local routing. 52 The solutions aim at reducing handover delay and packet loss. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Local Routing Initialization . . . . . . . . . . . . . . . 7 61 4.2. Handover . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2.1. Non optimized handover . . . . . . . . . . . . . . . . 8 63 4.2.2. Optimized handover . . . . . . . . . . . . . . . . . . 11 64 4.3. IPv4 considerations . . . . . . . . . . . . . . . . . . . 12 65 5. Messages formats . . . . . . . . . . . . . . . . . . . . . . . 13 66 5.1. Local Routing Indication message . . . . . . . . . . . . . 13 67 5.2. Local Routing Acknowledge message . . . . . . . . . . . . 14 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 73 1. Introduction 75 Base Proxy Mobile IPv6 requires all communications to go through the 76 LMA [RFC5213]. In the case where both endpoints are located in the 77 same PMIPv6 domain, this can be suboptimal and results in higher 78 delay and congestion in the network. Moreover, it increases 79 transport costs and traffic load at the LMA. 81 To overcome this situation, local routing has been defined to allow 82 nodes attached to the same or different mobile access gateways to 83 exchange traffic by using local forwarding or a direct tunnel between 84 the gateways. [I-D.ietf-netext-pmip6-lr-ps] details the local 85 routing problem statement. 87 +----+ 88 +------------|LMA |----------+ 89 | +----+ | 90 | | | 91 | | | 92 | | | 93 | | | 94 +----+ +----+ +----+ 95 |MAG1|==========|MAG2| |MAG3| 96 +----+ +----+ +----+ 97 | | 98 ============================= 99 +----+ +----+ 100 |MN1 | |MN2 | --------> 101 +----+ +----+ 103 Figure 1: Local Routing Scenario 105 Figure 1 defines a scenario where local routing could be used. MN1 106 and MN2 are communicating and are attached to the same PMIPv6 domain. 107 MN1 is attached to MAG1 and MN2 is initially attached to MAG2. The 108 LMA triggers the local routing by exchanging messages with the MAGs. 109 A tunnel is created between MAG1 and MAG2. 111 Regarding handover, suppose MN2 moves from MAG2 to MAG3. Based on 112 PMIPv6 specification, MN2 does an attach on MAG3. MAG3 performs 113 authentication then sends a PBU to the LMA. If there is no local 114 routing, the traffic is switched towards MAG3 at this point. 115 However, local routing imply that traffic from MN1 do not reach LMA 116 but is routed directly towards MAG2. Therefore, the LMA has to send 117 a message to MAG1 in order to switch traffic. This results in worst 118 handover performance than base PMIPv6. 120 This document proposes an initiation method and two fast handover 121 mechanisms for PMIPv6 local routing. The solutions aim at reducing 122 handover delay and packet loss. They reused some PFMIPv6 concepts 123 [I-D.ietf-mipshop-pfmipv6] . 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Terminology 133 All the general mobility-related terms used in this document are to 134 be interpreted as defined in the Mobile IPv6 [RFC3775] and Proxy 135 Mobile IPv6 [RFC5213] specifications as well as in 136 [I-D.ietf-netext-pmip6-lr-ps]. 138 Local Routing Indication (LRI): message sent to the MAG by the LMA or 139 a peer MAG in a local routing session. This message triggers local 140 routing. 142 Local Routing Acknowledgement (LRA): message sent by the MAG to the 143 LMA or a peer MAG in a local routing session. This message 144 acknowledge a LRI message. 146 4. Operations 148 The operations described here are based on the scenario presented in 149 Figure 1. 151 4.1. Local Routing Initialization 153 When the LMA notices that Local Routing should be initiated between 154 two MNs, it sends one LRI message to each MAG where the MNs are 155 attached. The LRI messages contains information to identify both 156 MNs, the target MAG which will be the other endpoint of the tunnel 157 and some data needed to establish a security association between the 158 MAGs. Note that we can have pre-established security associations 159 between the MAGs of the same PMIPv6 domain. The LRI MAY also 160 includes GRE Keys and a Tunnel mode option to indicate which type of 161 tunneling SHOULD be used between the MAGs. The Tunnel mode is 162 determined based on the information the LMA have on the MAGs 163 capabilities. Note that the tunnel mode MAY also be preconfigured 164 between MAGs. 166 If the MAG accepts to apply local routing, it sends a LRA message to 167 the LMA to acknowledge the Local Routing. At this point, the LMA 168 MUST not modify the binding of the MN as other communications MAY 169 still go through the LMA. The LMA MUST record that there is an 170 ongoing Local Routing session and also the involved MAGs and MNs. 171 How the charging is done when local routing is in place is out of 172 scope of this document. 174 Note also that this initiation mechanism can be extended to work in 175 scenarios where the MAGs are attached to different LMAs. In this 176 case, extra signalling will be required between the LMAs before they 177 initiate the local routing process. How the LMAs discover each 178 others is out of scope of this document. 180 +----+ +----+ +----+ +----+ +----+ +----+ 181 |MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA | 182 +----+ +----+ +----+ +----+ +----+ +----+ 183 | | | | | | 184 | data | | data | | 185 |<--------------------->|<------------------------------------->| 186 | | | | | | 187 | | data | data | 188 | |<--------------------->|<------------------------->| 189 | | | | | LR decision 190 | | | LRI(MN1,MN2,MAG2,Security,Tun_mode,GRE_Keys) 191 | | |<--------------------------------------| 192 | | | | | | 193 | | | LRI(MN2,MN1,MAG1,Security,Tun_mode,GRE_Keys) 194 | | | |<--------------------------| 195 | | | | | | 196 | | | | LRA(MN1,MN2,MAG2) | 197 | | |-------------------------------------->| 198 | | | | | | 199 | | | | LRA(MN2,MN1,MAG1) | 200 | | | |-------------------------->| 201 | | | | | | 202 | data | data | | | 203 |<--------------------->|<--------->| | | 204 | | | | | | 205 | | data | | | 206 | |<--------------------->| | | 207 | | | | | | 208 | | | | | | 210 Figure 2: Local Routing Initialization 212 4.2. Handover 214 The handover mechanisms proposed here are proactive. They are based 215 on the fact that the moving MN is able to send information to the MAG 216 it is still attached to about the target access point or MAG. Those 217 information are used by the old MAG to identify the target MAG. Note 218 that a MN which does not support this specification performs base 219 PMIPv6 handover and the LMA has to restart the Local Routing session 220 later. 222 4.2.1. Non optimized handover 224 In this mechanism, before moving to MAG3, MN2 sends a Handover 225 Initiate message to MAG2. This message MAY be L2 or L3 specific and 226 MUST provide MAG2 with useful information to resolve MAG3's address. 227 For example, in 3GPP LTE networks, the Mobility Management Entity 228 (MME) may generate this message towards the old Serving Gateway with 229 the result that no modification is needed on the MN side. The 230 details of this message is out of scope for this document. 232 If the target MAG is different from MAG2, MAG2 sends a refresh PBU 233 message to the LMA containing a new flag indicating a possible 234 movement. When receiving this PBU, the LMA MUST not update the BCE 235 but rather abort the Local Routing sessions by sending a 236 deregistration LRI message to MAG1. Therefore, MAG1 switches back 237 the traffic towards the LMA. At this time, the traffic is asymmetric 238 as the local routing from MAG2 to MAG1 is unaffected. When the LMA 239 receives the PBU indicating the new attach point of MN2, it can start 240 over a new Local Routing session between MN1 and MN2. Figure 3 shows 241 this mechanism. Even if we refer to this method as non-optimized, it 242 allows to reduce packet loss and handover delay. Another option 243 could be for the LMA to send to MAG1 a LRI to directly set up the 244 tunnel towards MAG3. 246 Note also that this method can be applied without any specific fast 247 mobility mechanisms. The difference will be that instead of 248 resolving MAG3's address, MAG2 detects MN2's detach and send a 249 deregistration PBU as recommended by [RFC5213]. 251 +----+ +----+ +----+ +----+ +----+ +----+ 252 |MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA | 253 +----+ +----+ +----+ +----+ +----+ +----+ 254 | | | | | | 255 | data | data | | | 256 |<-------------------->|<--------->| | | 257 | | data | | | 258 | |<--------------------->| | | 259 | HO decision | | | | 260 | HO_Init (MAG3 or Access Point) | | 261 | |---------------------->| | | 262 | | | | PBU | 263 | | | |---------------------->| 264 | | | | | | 265 | | | Dereg LRI(MN1,MN2,MAG2) | 266 | | |<----------------------------------| 267 | | | LRA(MN1,MN2,MAG2) | 268 | | |---------------------------------->| 269 | data | | data | | 270 |--------------------->|---------------------------------->| 271 | | data | data | 272 | |<----------------------|<----------------------| 273 | | data | | | 274 | |---------------------->| | | 275 | data | data | | | 276 |<---------------------|<----------| | | 277 | | | | | | 278 | | | Attach | | | 279 | |<--------------------------------->| | 280 | | | | | PBU | 281 | | | | |---------->| 282 | | | | | | 283 | | | LRI(MN1,MN2,MAG3,Security,Tun_mode,GRE_Keys) 284 | | |<----------------------------------| 285 | | | LRA(MN1,MN2,MAG3) | 286 | | |---------------------------------->| 287 | | | LRI(MN2,MN1,MAG1,Security,Tun_mode,GRE_Keys) 288 | | | | |<----------| 289 | | | | LRA(MN1,MN2,MAG1) 290 | | | | |---------->| 291 | data | data | | 292 |<-------------------->|<--------------------->| | 293 | | | data | | | 294 | |<--------------------------------->| | 295 | | | | | | 297 Figure 3: Non optimized handover 299 4.2.2. Optimized handover 301 We assume here that Local Routing sessions MUST be maintained after 302 handover. Before moving to MAG3, MN2 sends a Handover Initiate 303 message to MAG2. MAG2 resolves MAG3 address. Then it sends a LRI 304 message to inform MAG1 that MN2 will be attached to MAG3. It also 305 sends a LRI message to inform MAG3 to start a Local Routing session 306 with MAG1. To perform this, there need to be SA between each MAG and 307 all its neighbour which support Local Routing and where a MN may 308 move. This SA is used to exchange LRI/LRA messages between MAG2 and 309 MAG3. After this, the Local Routing session is established between 310 MAG1 and MAG3. MN2 can resume communications right after attachment 311 with MAG3 if MAG3 advertises MN2's prefix before completing the PBU/ 312 PBA exchange or packet may be buffered until the PBA is received by 313 MAG3. Figure 4 shows this mechanism. If this mechanism is used, 314 MAG3 MUST include an indication in the PBU to let the LMA know that 315 the LR session is now between MAG1 and MAG3. 317 In this method, MAG2 suggest a tunnelling mode and GRE Keys to MAG1 318 and MAG3. MAG2 SHOULD suggest the same tunnelling mode and GRE keys 319 he was using unless he has specific information allowing a more 320 accurate choice. In any case, if MAG1 and MAG3 rejects the 321 suggestion of MAG2, they MUST directly negotiate the tunnelling mode 322 and the GRE keys. 324 Another option could be for the MAG2 to send a LRI only to MAG3 in 325 order to establish temporary Local Routing session between MAG2 and 326 MAG3. Therefore, packets follow the path MAG1-MAG2-MAG3 during 327 handover and the normal Local Routing path is restored after 328 handover. However, this imply an additional tunnelling step and 329 requires the LMA to establish a direct LR session between MAG1 and 330 MAG3. 332 In case the MAGs are attached to different LMAs, extra inter-LMA 333 signalling is required to updated the LR states in each LMA. 335 +----+ +----+ +----+ +----+ +----+ +----+ 336 |MN1 | |MN2 | |MAG1| |MAG2| |MAG3| |LMA | 337 +----+ +----+ +----+ +----+ +----+ +----+ 338 | | | | | | 339 | data | data | | | 340 |<-------------------->|<--------->| | | 341 | | | | | | 342 | | data | | | 343 | |<--------------------->| | | 344 | HO decision | | | | 345 | HO_Init (MAG3 or Access Point) | | 346 | |---------------------->| | | 347 | | LRI(MN1,MN2,MAG3,Security,Tun_mode,GRE_Keys) | 348 | | |<----------| | | 349 | | LRI(MN1,MN2,MAG1,Security,Tun_mode,GRE_Keys) 350 | | | |--------->| | 351 | | LRA(MN1,MN2,MAG3) | | 352 | | |---------->| | | 353 | | | LRA(MN1,MN2,MAG1) | 354 | | | |<---------| | 355 | | | Attach | | | 356 | |<-------------------------------->| | 357 | data | data | | 358 |<-------------------->|<-------------------->| | 359 | | | | | | 360 | | | data | | | 361 | |<-------------------------------->| | 362 | | | | | PBU | 363 | | | | |---------->| 364 | | | | | PBA | 365 | | | | |<----------| 366 | | | | | | 368 Figure 4: Optimized handover 370 4.3. IPv4 considerations 372 In case of IPv4 Home Addresses used over IPv6 transport, the proposed 373 mechanisms works well and the chosen tunnelling mode MUST be IPv4 374 over IPv6. The GRE Keys MUST also be present to differentiate 375 private IPv4 HoAs. 377 If IPv4 transport is involved, the tunnelling mode suggested by MAG2 378 MAY not be accurate as NATs may be involved. In this case, unless 379 there are preconfigured tunnels, the MAGs MUST directly negotiate the 380 tunnelling mode. 382 5. Messages formats 384 This protocol requires two new messages, Local Routing Indication 385 (LRI) and Local Routing Acknowledgement (LRA) messages. They use MH 386 type (IANA-TBD). Figure 5 shows the MH. If the Local Routing type 387 is set to 1, it is a Local Routing Indication message (Section 5.1). 388 If it is set to 2, it is a Local Routing Acknowledgement message 389 Section 5.2). 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Payload Proto | Header Len | MH Type | Reserved | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Checksum | LR Type | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 398 | | 399 . Local Routing Message Data . 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 5: Local Routing Message 405 Local Routing Type 407 8-bit unsigned integer. It defines the type of Local Routing 408 message. Assigned values are: 410 0 Reserved 411 1 Local Routing Indication Message 412 2 Local Routing Acknowledgement Message 414 Local Routing Message Data 416 It follows the format defined for the specific Local Routing 417 message (Section 5.1 and Section 5.2). 419 5.1. Local Routing Indication message 421 The LR type is set to 1. The format of the corresponding Local 422 Routing Message Data is depicted in Figure 6. There is a 2n 423 alignment for this message. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | LR Type = 1 |A| Reserved | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Sequence # | Lifetime | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 . . 434 . Mobility options . 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 6: Local Routing Indication Message 440 Acknowledge bit (A) 442 Set to 1 to request a LRA message from the target MAG. 444 Reserved 446 Unused bits. Must be set to 0. 448 Sequence # 450 A 16-bit unsigned integer used by the LMA or a MAG to match a LRI 451 message with a LRA message. 453 Lifetime 455 A 16-bit unsigned integer used to define the lifetime of the Local 456 Routing session. 458 Mobility options 460 Variable length field. The Mobility header MUST be an integer 461 multiple of 8 octets long. There MUST be at least options present 462 to provide the source MN's address, the destination MN's address 463 and the target MAG address. This field can include options for 464 security and tunneling mode indication. 466 5.2. Local Routing Acknowledge message 468 The LRA is sent by the target MAG in response to a LRI message with 469 the A bit set. The LR type is set to 2. The format of the 470 corresponding Local Routing Message Data is depicted in Figure 7. 471 There is a 2n alignment for this message. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | LR Type = 2 | Reserved | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Sequence # | Lifetime | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 . . 482 . Mobility options . 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 7: Local Routing Acknowledgement Message 488 Reserved 490 Unused bits. Must be set to 0. 492 Sequence # 494 A 16-bit unsigned integer used by the requesting entity to match a 495 LRI message with a LRA message. MUST be copied from the sequence 496 # receive in the LRI message. 498 Lifetime 500 A 16-bit unsigned integer. MUST be copied from the lifetime 501 receive in the LRI message. 503 Mobility options 505 Variable length field. The Mobility header MUST be an integer 506 multiple of 8 octets long. The options present in the LRI message 507 MUST be copied in the LRA message. 509 6. Security Considerations 511 Message between the LMA and the MAGs MUST be exchanged using the 512 security associations existing for PBU/PBA messages. If inter-MAG 513 signaling messages are used, there MUST be a SA between the MAGs as a 514 malicious node can trigger a Local Routing session update. 516 7. IANA Considerations 518 This specification requires type to be assigned for LRI and LRA 519 message. 521 8. Normative References 523 [I-D.ietf-mipshop-pfmipv6] 524 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 525 Xia, "Fast Handovers for Proxy Mobile IPv6", 526 draft-ietf-mipshop-pfmipv6-09 (work in progress), 527 September 2009. 529 [I-D.ietf-netext-pmip6-lr-ps] 530 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 531 Routing Problem Statement", 532 draft-ietf-netext-pmip6-lr-ps-00 (work in progress), 533 September 2009. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 539 in IPv6", RFC 3775, June 2004. 541 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 542 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 544 Authors' Addresses 546 Desire Oulai 547 Ericsson 548 8400 Blvd Decarie 549 Town of Mount Royal, Quebec 550 Canada 552 Email: desire.oulai@ericsson.com 554 Suresh Krishnan 555 Ericsson 556 8400 Blvd Decarie 557 Town of Mount Royal, Quebec 558 Canada 560 Email: Suresh.Krishnan@ericsson.com