idnits 2.17.1 draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt: -(102): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(510): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(529): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(548): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(549): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(555): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(557): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(629): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(630): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(631): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(664): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(672): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(683): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(847): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(851): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(861): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(927): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1747): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2457): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 23 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document.' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 1603 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([15], [2], [16], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [1,5], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 339: '... MUST NOT occur togeth...' RFC 2119 keyword, line 461: '.... These messages SHOULD occur in advan...' RFC 2119 keyword, line 463: '...is to occur, oFA SHOULD solicit and ca...' RFC 2119 keyword, line 480: '... MUST return the Proxy...' RFC 2119 keyword, line 482: '...rs at oFA and oFA MUST relay the Agent...' (125 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1196 has weird spacing: '...) HRqst v...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7614 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 section? '1' on line 2240 looks like a reference -- Missing reference section? '11' on line 2414 looks like a reference -- Missing reference section? '2' on line 2243 looks like a reference -- Missing reference section? '10' on line 2271 looks like a reference -- Missing reference section? '7' on line 2263 looks like a reference -- Missing reference section? '3' on line 2246 looks like a reference -- Missing reference section? '8' on line 2266 looks like a reference -- Missing reference section? '5' on line 2253 looks like a reference -- Missing reference section? '4' on line 2249 looks like a reference -- Missing reference section? '9' on line 2268 looks like a reference -- Missing reference section? '12' on line 2280 looks like a reference -- Missing reference section? '16' on line 2292 looks like a reference -- Missing reference section? '6' on line 2258 looks like a reference -- Missing reference section? '15' on line 2288 looks like a reference -- Missing reference section? '13' on line 2282 looks like a reference -- Missing reference section? '14' on line 2285 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Karim El Malki (Editor) 3 INTERNET-DRAFT Pat R. Calhoun 4 Expires: Dec 2003 Tom Hiller 5 James Kempf 6 Peter J. McCann 7 Ajoy Singh 8 Hesham Soliman 9 Sebastian Thalanany 11 June 2003 13 Low Latency Handoffs in Mobile IPv4 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is a product of the Mobile IP WG. 38 Abstract 40 Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs 41 between subnets served by different Foreign Agents. In certain cases, 42 the latency involved in these handoffs can be above the threshold 43 required for the support of delay-sensitive or real-time services. 44 The aim of this document is to present two methods to achieve low- 45 latency Mobile IP handoffs. In addition, a combination of these two 46 methods is described. The described techniques allow greater support 47 for real-time services on a Mobile IPv4 network by minimising the 48 period of time when a Mobile Node is unable to send or receive IP 49 packets due to the delay in the Mobile IP Registration process. 51 TABLE OF CONTENTS 53 1. Introduction....................................................3 54 1.1. Terminology................................................3 55 1.2. The Techniques.............................................5 56 1.3. L2 triggers................................................7 57 1.4. Requirements language......................................9 58 2. Requirements....................................................9 59 3. The PRE-REGISTRATION Handoff Method.............................9 60 3.1. Operation..................................................9 61 3.2. Network-Initiated Handoff.................................12 62 3.3. Mobile-Initiated Handoff..................................14 63 3.4. Obtaining and Proxying nFA Advertisements.................15 64 3.4.1. Inter-FA Solicitation................................15 65 3.4.2. Tunneled nFA Advertisements..........................16 66 3.5. Caching Router Advertisements.............................16 67 3.6. Movement Detection and MN Considerations..................17 68 3.7. L2 Address Considerations.................................18 69 3.8. Applicability of PRE-REGISTRATION Handoff.................19 70 4. The POST-REGISTRATION Handoff Method...........................20 71 4.1. Two Party Handoff.........................................20 72 4.2. Three Party Handoff.......................................25 73 4.3. Renewal or Termination of Tunneling Service...............29 74 4.4. When will the MN perform a Mobile IP Registration?........30 75 4.5. Handoff Request (HRqst) Message format....................31 76 4.6. Handoff Reply (HRply) Message.............................33 77 4.7. Handoff To Third (HTT) Message............................35 78 4.8. Applicability of POST-REGISTRATION Handoff Method.........35 79 5. Combined Handoff Method........................................36 80 6. Layer 2 and Layer 3 Handoff timing Considerations..............37 81 7. Reverse Tunneling Support......................................37 82 8. Handoff Signaling Failure Recovery.............................37 83 8.1. PRE-REGISTRATION Signaling Failure Recovery...............37 84 8.1.1. Failure of ProxyRtSol and ProxyRtAdv.................38 85 8.1.2. Failure of Inter-FA solicitation and advertisement...38 86 8.2. POST-REGISTRATION Signaling Failure Recovery..............38 87 8.2.1. HRqst Message Dropped................................39 88 8.2.2. HRply Message Dropped................................39 89 9. Generalized Link Layer Address Extension.......................40 90 9.1. 3GPP2 IMSI Link Layer Address and Connection ID Ext......41 91 9.2. 3GPP IMSI Link Layer Address Extension...................41 92 9.3. Ethernet Link Layer Address Extension....................42 93 9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Ext.......43 94 9.5. Solicited IP Address Extension...........................43 95 9.6. Access Point Identifier Extension........................44 97 10. IANA Considerations............................................44 98 11. Security Considerations........................................45 99 12. Acknowledgements...............................................46 100 13. Normative References...........................................46 101 14. Informative References.........................................47 102 15. Authors� Addresses.............................................47 103 16. Full Copyright Statement.......................................49 104 Appendix A - Gateway Foreign Agents................................50 105 Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......51 107 1. Introduction 109 Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer 110 handoff between subnets served by different Foreign Agents (FAs). In 111 certain cases, the latency involved in handoff can be above the 112 threshold required for the support of delay-sensitive or real-time 113 services. The aim of this document is to present two methods to 114 achieve low-latency Mobile IP handoff during movement between FAs. 115 The presented techniques allow greater support for real-time services 116 on a Mobile IPv4 network by minimising the period of time when a MN 117 is unable to send or receive IP packets due to the delay in the 118 Mobile IP Registration process. 120 In the rest of this section, terminology used throughout the document 121 is presented, the handoff techniques are briefly described, and the 122 use of link layer information is outlined. In Section 2, a brief 123 description of requirements is presented. Section 3 describes the 124 details of the PRE-REGISTRATION handoff technique, while Section 4 125 describes the details of the POST-REGISTRATION handoff technique. In 126 Section 5, a combined method using the two handoff techniques 127 together is presented. Section 6 discusses Layer 2 and Layer 3 128 handoff timing considerations. Section 7 discusses reverse tunneling 129 support, Section 8 describes mechanisms to recover from message 130 failures while Section 9 describes protocol extensions required by 131 the handoff techniques. Sections 10 and 11 discuss IANA and security 132 considerations. Finally the two appendices discuss additional 133 material related to the handoff techniques. Appendix A gives a short 134 introduction to Regional Registrations [11] which can be used 135 together with low latency handoffs. Appendix B discusses low latency 136 handoff when a MN has multiple wireless L2 interfaces, in which case 137 the techniques in this document may not be necessary. 139 1.1. Terminology 141 This section presents a few terms used throughout the document. 143 oFA - old Foreign Agent, the FA involved in handling a MN's 144 care of address prior to an L3 handoff. 146 nFA - new Foreign Agent, the FA anticipated to be handling a 147 MN's care of address after completion of an L3 handoff. 149 aFA - anchor Foreign Agent, the FA that is currently handling 150 the network end of the BET in POST-REGISTRATION. 152 L2 handoff - Movement of a MN's point of Layer 2 (L2) 153 connection from one wireless access point to another. 155 L3 handoff - Movement of a MN between FAs which involves 156 changing the care-of address (CoA) at Layer 3 (L3). 158 L2 trigger - Information from L2 that informs L3 of particular 159 events before and after L2 handoff. The descriptions of L2 160 triggers in this document are not specific to any particular 161 L2, but rather represent generalizations of L2 information 162 available from a wide variety of L2 protocols. 164 L2-MT - An L2 trigger that occurs at the MN informing of 165 movement to a certain nFA (Mobile Trigger). 167 L2-ST or source trigger - An L2 trigger that occurs at oFA, 168 informing the oFA that L2 handoff is about to occur. 170 L2-TT or target trigger - An L2 trigger that occurs at nFA, 171 informing the nFA that a MN is about to be handed off to 172 nFA. 174 L2-LU - An L2 trigger that occurs at the MN or nFA, informing 175 that the L2 link between MN and nFA is established. 177 L2-LD - An L2 trigger that occurs at the oFA, informing the oFA 178 that the L2 link between MN and oFA is lost. 180 low latency handoff - L3 handoff in which the period of time 181 during which the MN is unable to receive packets is 182 minimized. 184 low loss handoff - L3 handoff in which the number of packets 185 dropped or delayed is minimized. Low loss handoff is often 186 called smooth handoff. 188 seamless handoff - L3 handoff that is both low latency and low 189 loss. 191 bi-directional edge tunnel (BET) - A bidirectional tunnel 192 established between two FAs for purposes of temporarily 193 routing a MN's traffic to/from it on a new subnet without 194 requiring the MN to change CoA. 196 ping-ponging - Rapid back and forth movement between two 197 wireless access points often due to failure of L2 handoff. 198 Ping-ponging can occur if radio conditions for both the old 199 and new access points are about equivalent and less than 200 optimal for establishing a good, low-error L2 connection. 202 network-initiated handoff - L3 handoff in which oFA or nFA 203 initiates the handoff. 205 mobile-initiated handoff - L3 handoff in which the MN initiates 206 the handoff. 208 IP address identifier - An IP address of a MN or FA, or an L2 209 identifier that allows an FA to deduce the IP address of a 210 MN or FA. If the IP address identifier is an L2 identifier, 211 it may be specific to the L2 technology. 213 1.2. The Techniques 215 Mobile IP was originally designed without any assumptions about the 216 underlying link layers over which it would operate so that it could 217 have the widest possible applicability. This approach has the 218 advantage of facilitating a clean separation between L2 and L3 of the 219 protocol stack, but it has negative consequences for handoff latency. 220 The strict separation between L2 and L3 results in the following 221 built-in sources of delay: 223 - The MN may only communicate with a directly connected FA. This 224 implies that a MN may only begin the registration process after 225 an L2 handoff to nFA (new FA) has completed. 227 - The registration process takes some non-zero time to complete as 228 the Registration Requests propagate through the network. During 229 this period of time the MN is not able to send or receive 230 IP packets. 232 This document presents techniques for reducing these built-in delay 233 components of Mobile IP. The techniques can be divided into two 234 general categories, depending on which of the above problems they 235 are attempting to address: 237 - Allow the MN to communicate with the nFA while still connected 238 to the oFA. 240 - Provide for data delivery to the MN at the nFA even before the 241 formal registration process has completed. 243 The first category of techniques allows the MN to "pre-build" its 244 registration state on the nFA prior to an underlying L2 handoff. 245 The second category of techniques allow for service to continue 246 uninterrupted while the handoff is being processed by the network. 248 Three methods are presented in this draft to achieve low-latency L3 249 handoff, one for each category described above and one as a 250 combination of the two: 252 - PRE-REGISTRATION handoff method, 254 - POST-REGISTRATION handoff method, 256 - combined handoff method. 258 The PRE-REGISTRATION handoff method allows the MN to be involved in 259 an anticipated IP-layer handoff. The MN is assisted by the network in 260 performing an L3 handoff before it completes the L2 handoff. The L3 261 handoff can be either network-initiated or mobile-initated. 262 Accordingly, L2 triggers are used both in the MN and in the FA to 263 trigger particular L3 handoff events. The PRE-REGISTRATION method 264 coupled to L2 mobility helps to achieve seamless handoffs between 265 FAs. The basic Mobile IPv4 concept involving advertisement followed 266 by registration is supported and the PRE-REGISTRATION handoff method 267 relies on Mobile IP security. No new messages are proposed, except 268 for an extension to the Agent Solicitation message in the mobile- 269 initiated case. 271 The POST-REGISTRATION handoff method proposes extensions to the 272 Mobile IP protocol to allow the oFA (old FA) and nFA (new FA) to 273 utilize L2 triggers to set up a bi-directional tunnel between oFA and 274 nFA that allows the MN to continue using its oFA while on nFA's 275 subnet. This enables a rapid establishment of service at the new 276 point of attachment which minimizes the impact on real-time 277 applications. The MN must eventually perform a formal Mobile IP 278 registration after L2 communication with the new FA is established, 279 but this can be delayed as required by the MN or FA. Until the MN 280 performs registration, the FAs will setup and move bidirectional 281 tunnels as required to give the MN continued connectivity. 283 The combined method involves running a PRE-REGISTRATION and a POST- 284 REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can 285 be performed before the L2 handoff completes, the combined method 286 resolves to a PRE-REGISTRATION handoff. However, if the PRE- 287 REGISTRATION handoff does not complete within an access technology 288 dependent time period, the oFA starts forwarding traffic for the MN 289 to the nFA as specified in the POST-REGISTRATION handoff method. This 290 provides for a useful backup mechanism when completion of a PRE- 291 REGISTRATION handoff cannot always be guaranteed before the L2 292 handoff completion. 294 It should be noted that the methods described in this document may be 295 applied to MNs having a single interface (e.g. Wireless LAN 296 interface) or multiple interfaces (e.g. one WLAN and one cellular 297 interface). However, the case of multiply-interfaced MNs needs 298 special consideration, since the handoff methods described in this 299 document may not be required in all cases (see Appendix B). 301 1.3. L2 triggers 303 An L2 trigger is a signal of an L2 event. In this document, the L2 304 events relate to the L2 handoff process. One possible event is early 305 notice of an upcoming change in the L2 point of attachment of the 306 mobile node to the access network. Another possible event is the 307 completion of relocation of the mobile node's L2 point of attachment 308 to a new L2 access point. This information comes from L2 309 programmatically or is derived from L2 messages. Although the 310 protocols outlined in this document make use of specific L2 311 information, Mobile IP should be kept independent of any specific L2. 312 L2 triggers are an abstraction mechanism for a technology specific 313 trigger. Therefore, an L2 trigger that is made available to the 314 Mobile IPv4 stack is assumed to be generic and technology 315 independent. The precise format of these triggers is not covered in 316 this document, but the information required to be contained in the L2 317 triggers for low latency handoffs is specified. 319 In order to properly abstract from the L2, it is assumed that one of 320 the three entities - the MN, oFA, or nFA - is made aware of the need 321 for an L2 handoff, and that the nFA or MN can optionally also be made 322 aware that an L2 handoff has completed. A specific L2 will often 323 dictate when a trigger is received and which entity will receive it. 324 Certain L2s provide advance triggers on the network-side, while 325 others provide advance triggers on the MN. Also, the particular 326 timing of the trigger with respect to the actual L2 handoff may 327 differ from technology to technology. For example, some wireless 328 links may provide such a trigger well in advance of the actual 329 handoff. In contrast, other L2s may provide little or no information 330 in anticipation of the L2 handoff. 332 An L2 trigger may be categorized according to whether it is 333 received by the MN, oFA, or nFA. Table 1 gives such a categorization 334 along with information expected to be contained in the trigger. The 335 methods presented in this document operate based on different types 336 of L2 triggers as shown in Table 1. Once the L2 trigger is received, 337 the handoff processes described hereafter are initiated. The three 338 triggers: L2-ST, L2-TT and L2-MT are independent of each other and 339 MUST NOT occur together since each will trigger a different type of 340 handoff behaviour. 342 +-------------+----------------------+------------------------------+ 343 | L2 trigger | Mobile | Source | 344 | | Trigger | Trigger | 345 | | (L2-MT) | (L2-ST) | 346 +-------------+----------------------+------------------------------+ 347 | Recipient | MN | oFA | 348 +-------------+----------------------+--------------+---------------+ 349 | Method | PRE | PRE | POST | 350 | | mobile- | network- | source | 351 | | initiated | initiated | trigger | 352 +-------------+----------------------+--------------+---------------+ 353 | When? | sufficiently before | sufficiently | sufficiently | 354 | | the L2 handover | before L2 | before L2 | 355 | | so that MN can | handover for | handover for | 356 | | solicit ProxyRtAdv | FA to send | oFA & nFA to | 357 | | from oFA. | proxyRtAdv | exchange | 358 | | | to MN. | HRq/HRy. | 359 +-------------+----------------------+--------------+---------------+ 360 | Parameters | nFA IP address | nFA IP address identifier | 361 | | identifier | MN IP address identifier | 362 | | | | 363 +-------------+----------------------+------------------------------+ 365 +------------+------------------------+-------------+---------------+ 366 | L2 trigger | Target | Link-Up | Link-Down | 367 | | Trigger | | | 368 | | (L2-TT) | | | 369 | | | (L2-LU) | (L2-LD) | 370 |------------+------------------------+-------------+---------------+ 371 | Recipient | nFA | MN or nFA | oFA | 372 |------------+------------+-----------+-------------+---------------+ 373 | Method | PRE | POST | PRE & POST | POST | 374 | | network | target | | | 375 | | initiated | trigger | | | 376 |------------+------------------------+-------------+---------------+ 377 | When? | | when radio | when radio | 378 | | same as | link between| link between | 379 | | source trigger | MN & nFA is| MN and oFA | 380 | | | established | is lost | 381 |------------+------------------------+-------------+---------------+ 382 | Parameters | oFA IP address id | @MN: nFA IP | MN IP address | 383 | | MN IP address id. | or L2 addr. | identifier | 384 |------------+------------------------+-------------+---------------+ 386 Table 1 - L2 Triggers 388 1.4. Requirements language 390 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 391 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 392 described in [2]. 394 2. Requirements 396 The following requirements are applicable to low-latency handoff 397 techniques and are supported by the methods in this document: 399 - to provide low-latency and low loss handoff for real time services, 401 - to have no dependence on a wireless L2 technology, 403 - to support inter- and intra-access technology handoffs, 405 - to limit wireless bandwidth usage. 407 3. The PRE-REGISTRATION Handoff Method 409 The PRE-REGISTRATION handoff method is based on the original concept 410 of Mobile IP handoff as specified in [1], in which: 412 - an advertisement for an FA is received by an MN, 414 - the advertisement allows the MN to perform movement detection, 416 - the MN registers with the FA. 418 It reuses the basic messages specified in [1]. The PRE-REGISTRATION 419 method allows both the MN and FA to initiate handoff. In both cases, 420 abiding by the basic Mobile IP handoff concept allows the MN to 421 choose with which FA to register. The PRE-REGISTRATION method can 422 make use of L2 triggers on either the FA or MN side, depending on 423 whether network-initiated or mobile-initiated handoff occurs. PRE- 424 REGISTRATION also supports both the normal Mobile IP model [1] in 425 which the MN is receiving packets from a Home Agent (HA) and the 426 Regional Registration model [11] in which the MN receives packets 427 from a Gateway Foreign Agent (GFA). It also supports movement where a 428 new AAA transaction must occur to authenticate the MN with the new 429 domain. 431 3.1. Operation 433 The overall PRE-REGISTRATION Handoff mechanism is summarised in 434 Figure 1 below: 436 +---------+ 437 | HA (GFA)|<---------+ 438 +---------+ | 4. (Reg)RegReq 439 | 5. (Reg)RegReply 440 v 441 +-----+ 1a. RtSol +-----+ 442 | | -----------------> | nFA | 443 | oFA | 1b. RtAdv | | 444 +-----+ <----------------- +-----+ 445 ^ | ^ 446 (2a. ProxyRtSol) | | 2b / 447 | | ProxyRtAdv / 3. (Reg)RegReq 448 | | / 449 | v --------------- 450 +-----+ / 451 | MN | 452 +-----+ - - - - - -> 453 Movement 455 Figure 1 - PRE-REGISTRATION Handoff Protocol 457 The following steps provide more detail on the protocol: 459 1. Messages 1a is a Router Solicitation (RtSol) from oFA to nFA. 460 Message 1b is a Router (Agent) Advertisement (RtAdv) from nFA 461 to oFA. These messages SHOULD occur in advance of the PRE- 462 REGISTRATION Handoff in order not to delay the handoff. For 463 this to occur, oFA SHOULD solicit and cache advertisements 464 from neighbouring nFAs, thus decoupling the timing of this 465 exchange from the rest of the PRE-REGISTRATION Handoff. When 466 the L3 handoff is initiated by a target L2 trigger at nFA 467 (L2-TT), message 1b equals message 2b and is sent unsolicited 468 directly to MN (tunneled by nFA to MN through oFA) instead of 469 being relayed by oFA. 471 2. Message 2a is a Proxy Router Solicitation (PrRtSol). It is 472 different from a normal Router Solicitation since it is 473 actually soliciting an advertisement from a router different 474 from the one receiving this message. The presence of message 475 2a indicates that the handoff is mobile-initiated and its 476 absence means that the handoff is network-initiated. In 477 mobile-initiated handoff, message 2a occurs if there is an L2 478 trigger in the MN to solicit for a Proxy Router Advertisement 479 (PrRtAdv). When message 2a is received by the oFA, the oFA 480 MUST return the Proxy Router Advertisement (Agent 481 Advertisement) in message 2b. In network-initiated handoff, 482 the L2 trigger occurs at oFA and oFA MUST relay the Agent 483 Advertisement in message 2b without the need for the MN to 484 solicit. Note that it is also possible for nFA to advertise 485 directly to the MN in the network-initiated target-trigger 486 case (section 3.2). In all cases message 2b is simply nFA�s 487 agent advertisement. 489 3. The MN performs movement detection upon receipt of either a 490 solicited or unsolicited Agent Advertisement and, if 491 appropriate, it sends a Registration Request (RegReq) message 492 [1] in message 3 to nFA. When a local Gateway Foreign Agent 493 (GFA) is present this message MAY be a Regional Registration 494 Request (RegRegReq) [11]. Message 3 is routed through oFA 495 since the MN is not directly connected to nFA prior to the L2 496 handoff. 498 4. Messages 4 and 5 complete the standard Mobile IP Registration 499 [1] or Regional Registration [11] initiated with message 3. 500 In the network-initiated target-triggered case, the 501 Registration Reply in message 5 SHOULD be sent by nFA to the 502 MN both through oFA and directly on-link. This is necessary 503 since the MN may have to detach from oFA, due to the wireless 504 L2 connection, before it received the Reply. Figures 2 and 3 505 illustrate this tunneling, though it is not shown in Figure 506 1. Tunneling can take place either at L3 or L2. In the 507 mobile-initiated and network-initiated source-triggered cases 508 the nFA will not have the oFA's address. Therefore the Reply 509 MUST be unicast by nFA to the MN on-link as soon as the MN 510 connects to nFA (L2-UP). The MN�s L2 address is obtained 511 using the extensions in Section 9, as described in 3.7. 513 5. If the Registration is successful then packets for the MN are 514 now tunnelled from the HA (or GFA) to the nFA where the MN 515 has moved to. 517 PRE-REGISTRATION is not dependent on Regional Registration extensions 518 [11]. However if the HA is at a distance (in terms of delay) from the 519 nFA, the use of a local GFA reduces the time required for the handoff 520 procedure to complete. 522 The time at which the L2 trigger is received by the oFA or MN, 523 thereby triggering the PRE-REGISTRATION handoff, compared to the time 524 at which the actual L2 handoff occurs is important for the optimal 525 performance of the low latency handoff. That is, in the optimal case 526 the L2 trigger will be received, the four messaging steps of PRE-REG 527 described above will be completed (i.e. Registration Request 528 processed by HA or GFA) and the first packet redirected by the HA (or 529 GFA) to nFA will reach the MN at the moment in which the MN�s L2 link 530 to nFA is fully established. The MN would therefore not suffer any 531 disruption due to the L3 handoff. This may require particular 532 implementation techniques and deployment, such as L2 techniques, 533 buffering and bicasting, but these are outside the scope of this 534 document. In addition further handoff smoothing considerations may be 535 required to prevent the loss of packets in-flight between HA (or GFA) 536 and oFA while the MN performs a PRE-REGISTRATION handoff. These are 537 also outside the scope of this document. 539 Figures 2, 3, and 4 contain message timing diagrams for both the 540 network-initiated and mobile-initiated PRE-REGISTRATION handoff 541 procedures. 543 3.2. Network-Initiated Handoff 545 As described in Table 1, a PRE-REGISTRATION handoff can be initated 546 at oFA by a source trigger or at nFA by a target trigger. A source- 547 triggered network-initiated handoff occurs when an L2 trigger is 548 received at the oFA informing it of a certain MN�s upcoming movement 549 from oFA to nFA. The L2 trigger contains information such as the MN�s 550 IP address identifier (i.e. the IP address itself or an identifier 551 which can be resolved to the IP address) and the nFA�s IP address 552 identifier. An identifier may be specific to the wireless technology 553 (e.g. Access Point ID). A target-triggered network-initiated handoff 554 occurs when an L2 trigger is received at the nFA informing it of a 555 certain MN�s upcoming movement from oFA. This type of trigger is also 556 shown in Table 1. The L2 trigger contains information such as the 557 MN�s IP address identifier and the oFA�s IP address identifier. 559 In a source-triggered handoff, when oFA receives the trigger (L2-ST) 560 it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to 561 the MN. The PrRtAdv is nFA's agent advertisement [1] with one of the 562 link-layer extensions described in sections 9.3 or 9.6. The use of 563 the contents of this extension is described in section 3.7. Messages 564 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is 565 received (see section 3.4.1). Message 2a is not used. In a target- 566 triggered handoff, when nFA receives the trigger (L2-TT) it MUST 567 tunnel an Agent Advertisement to the MN through oFA to initiate the 568 L3 handoff. The inner Advertisement is unicast by nFA to MN, thus nFA 569 treats the target-trigger as a Router Solicitation. This 570 Advertisement is tunneled to oFA which functions as a normal router, 571 decapsulating the Advertisement and forwarding it to the MN. This 572 messages MUST be authenticated to prevent attacks (see section 573 3.4.2). 575 Figures 2 and 3 contain message timing diagrams describing the PRE- 576 REGISTRATION network-initiated handoff for source and target 577 triggers. 579 MN oFA nFA HA/GFA 580 | |<~~~~~~ L2-Source | | 581 | | Trigger | | 582 |<--------------------| | | 583 | ProxyRtAdv | | | 584 | | | | 585 |---------------------------------------->| | 586 | RegReq or | | | 587 | RegRegReq | |------------------->| 588 | (routed via oFA) | | RegReq or RegRegReq| 589 | | | | 590 | | |<-------------------| 591 | | | (Reg)RegReply | 592 | | | | 593 |<----------------------------------------| | 594 | | (Reg)RegReply | | 595 | | (sent to MN when it attaches to nFA) | 597 Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram 598 (Network-Initiated, Source Trigger) 600 MN oFA nFA HA/GFA 601 | | L2-Target~~~~~~~~>| | 602 | | Trigger | | 603 | | | | 604 | |...................| | 605 |<--------------------------------------- | | 606 | (ProxyRtAdv) |...................| | 607 | | Tunneled Agent | | 608 | | Advertisement | | 609 | | | | 610 |---------------------------------------->| | 611 | RegReq. or | | | 612 | RegRegReq | |------------------->| 613 | (routed via oFA) | | RegReq or RegRegReq| 614 | | | | 615 | | |<-------------------| 616 | | | (Reg)RegReply | 617 | | | | 618 |<----------------------------------------| | 619 | | (Reg)RegReply | | 620 | | (sent to MN when it attaches to nFA) | 622 Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram 623 (Network-Initiated, Target Trigger) 625 3.3. Mobile-Initiated Handoff 627 As shown in Table 1, a mobile-initiated handoff occurs when an L2 628 trigger is received at the MN informing that it will shortly move to 629 nFA. The L2 trigger contains information such as the nFA�s IP address 630 identifier (i.e. nFA�s IP address or an identifier which can be 631 resolved to the nFA�s IP address). The message timing diagram is 632 shown in Figure 4. 634 MN oFA nFA HA/GFA 635 |<~~~~~ L2-Trigger | | | 636 | | | | 637 |-------------------->| | | 638 | ProxyRtSol | | | 639 | | | | 640 |<--------------------| | | 641 | ProxyRtAdv | | | 642 | | | | 643 |---------------------------------------->| | 644 | RegReq or | | | 645 | RegRegReq | |------------------->| 646 | (routed via oFA) | | RegReq or RegRegReq| 647 | | | | 648 | | |<-------------------| 649 | | | (Reg)RegReply | 650 |<----------------------------------------| | 651 | | (Reg)RegReply | | 652 | | (sent to MN when it attaches to nFA) | 654 Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram 655 (Mobile-Initiated) 657 As a consequence of the L2 trigger (L2-MT) the MN MUST send message 658 1a, the Proxy Router Solicitation (PrRtSol). This message is a 659 unicast agent solicitation to oFA for a Proxy Router Advertisement 660 (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The Proxy 661 Router Advertisement Solicitation unicast to oFA is an agent 662 solicitation with a special extension. The solicitation MUST have an 663 extension containing an IP address identifier because the MN is 664 soliciting another specific FA�s advertisement from the oFA. This 665 specific FA will be the MN's nFA. The IP address identifier contains 666 the IP address of the nFA or an identifier that can be used by the 667 oFA to resolve to nFA's IP address. If the identifier is not an IP 668 address, it MAY be specific to the underlying wireless technology, 669 for example, an Access Point or Base Station ID. The extension is a 670 subtype of the Generalised Link-Layer Address extension described in 671 Section 9. Two extension subtypes have been defined to contain the 672 nFA�s IP address and an access point identifier. They are called the 673 Solicited Agent IP Address Extension and the Access Point Identifier 674 Extension, and are described in Sections 9.5 and 9.6. These two 675 extensions SHOULD NOT be present in the same PrRtSol message. 677 When oFA receives the PrRtSol message it MUST reply to the MN with 678 the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is 679 simply the agent advertisement for the requested nFA, proxied by oFA. 680 In order to expedite the handoff, the actual nFA advertisement SHOULD 681 be cached by the oFA following a previous exchange with nFA, shown in 682 messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message 683 MUST contain the nFA�s L2 address (using the LLA extension in 9.2). 684 This is further described in section 3.7. 686 3.4. Obtaining and Proxying nFA Advertisements 688 Since L2 triggers are involved in initiating PRE-REGISTRATION 689 handoff, the trigger timing SHOULD be arranged such that a full L3 690 PRE-REGISTRATION handoff can complete before the L2 handoff process 691 completes. That is, the L2 handoff should be completed after the MN's 692 Registration with the nFA is performed (message 3 in Fig.1). The 693 Registration MAY be transmitted more than once to reduce the 694 probability that it is lost due to errors on the wireless link. 696 A PRE-REGISTRATION handoff in this case requires the MN to receive an 697 agent advertisement from the nFA through the old wireless access 698 point. How to achieve this is discussed in the following subsections. 699 Messages exchanged between FAs MUST be authenticated to prevent 700 attacks. The minimal requirement is that all FAs involved in low 701 latency handoffs MUST support manual pre-configuration of security 702 associations with other neighbouring FAs, involving shared keys and 703 the default algorithms of [1]. 705 3.4.1. Inter-FA Solicitation 707 This applies to the network-initiated source-triggered (L2-ST) and 708 mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes 709 that oFA has access to the IP address of the nFA. The IP address of 710 nFA is obtained by means of an L2 trigger at oFA in the network- 711 initiated case (see Section 3.2) or by means of the extension to the 712 Proxy Router Solicitation (PrRtSol) from the MN in the mobile- 713 initiated case (see Section 3.3). 715 Once the oFA has access to the address of the nFA for a specific MN, 716 it MUST send a unicast agent solicitation to nFA. The nFA replies to 717 the oFA by unicasting an Agent Advertisement with appropriate 718 extensions. This method removes the TTL limitation of [1] for Mobile 719 IP messages (i.e. TTL=1 is not applicable here). The TTL limitation 720 cannot be applied since oFA and nFA may be more than one hop away and 721 since it is unnecessary for a secured unicast message. The ICMP 722 solicitations and advertisements MUST be authenticated. These 723 messages MUST be protected using ESP [10] to prevent attacks. An FA 724 MUST NOT accept ICMP solicitations or advertisements from sources 725 which are not authenticated. 727 As a practical matter, oFA SHOULD pre-solicit and cache 728 advertisements from known neighboring FAs (see section 3.5), in order 729 to prevent having to perform the above solicitation during an actual 730 handoff procedure. 732 3.4.2. Tunneled nFA Advertisements 734 This applies to the network-initiated target-triggered (L2-TT) case 735 only. Following a target trigger (L2-TT) the nFA MUST send a tunneled 736 agent advertisement to the MN through oFA. Tunneling nFA 737 advertisments assumes that the nFA is aware of the IP address for oFA 738 and the MN. These IP addresses are obtained by means of the IP 739 address identifiers in an L2 trigger at nFA in the network-initiated 740 case (see Section 3.2). However in [1] the TTL must be 1 on Agent 741 Advertisements from the nFA. Therefore tunneling advertisements is 742 applicable if the TTL limitation of [1] is relaxed. For this purpose, 743 a pre-established security association between oFA and nFA MUST be in 744 place to authenticate this message and relax the TTL limitation. If 745 the implementation requires this, a tunnel SHOULD be configured when 746 the inter-FA security association is established. The tunneled ICMP 747 advertisement MUST be secured using tunnel mode ESP [10] between nFA 748 and oFA. An FA MUST NOT accept tunneled packets from sources which 749 are not authenticated. 751 3.5. Caching Router Advertisements 753 In the mobile-initiated (L2-MT) case and the network-initiated 754 source-triggered (L2-ST) case, the message exchange 1 in Figure 1 755 could impose an additional latency on the L3 handoff process if done 756 as part of the handoff procedure. In order to remove this source of 757 latency, the inter-FA Router Solicitation and Advertisement exchange 758 SHOULD be performed in advance of handoff. A process SHOULD be in 759 place at the oFA to solicit its neighbouring nFAs at a predefined 760 time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT 761 be set too small to avoid unnecessary consumption of network 762 bandwidth and nFA processing resources. The minimum value of 763 MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response 764 mechanism in [7] is used then the MIN_SOLICITATION_INTERVAL MUST be 765 set to a value smaller then the window of time in which a challenge 766 remains valid so that the nFA challenge does not expire before the MN 767 issues the Registration Request. Therefore the 768 MIN_SOLICITATION_INTERVAL in oFA MUST be set to a value equal to (0.5 769 * nFA's CHALLENGE_WINDOW * nFA's Agent advertisement interval). The 770 CHALLENGE_WINDOW and Agent advertisement interval are defined in [7] 771 and [1] respectively. The minimum requirement is that the 772 MIN_SOLICITATION_INTERVAL MUST be manually configurable, while 773 possible autoconfiguration mechanisms are outside the scope of this 774 document. To allow advertisement caching in certain implementations 775 and in cases where the nFA advertisement interval is very small, it 776 MAY be necessary for the implementation in nFA to allow different 777 CHALLENGE_WINDOW and agent advertisement interval settings for its 778 nFA-oFA interface. 780 The oFA SHOULD cache the most recent advertisement from its 781 neighbouring nFAs. This advertisement MUST be sent to the MN in 782 message 2b with a TTL=1. The oFA SHOULD also have a mechanism in 783 place to create a list of neighbouring nFAs. The minimum requirement 784 for each FA is that it SHOULD allow manual configuration of a list of 785 nFA addresses which an MN could possibly perform an L3 handoff to. 786 The FA addresses in this list will depend on deployment and radio 787 coverage. It is also possible to specify another protocol to achieve 788 nFA discovery, but it is outside the scope of this document. 790 3.6. Movement Detection and MN Considerations 792 When the MN receives an Agent Advertisement with a Mobility Agent 793 extension, it performs actions according to the following movement 794 detection mechanism: the MN MUST be "Eager" to perform new bindings. 795 This means that the MN MUST perform Registrations with any new FA 796 from which it receives an advertisement (i.e. MN is Eager), as long 797 as there are no locally-defined policies in the MN that discourage 798 the use of the discovered FA. For example, the MN could have a policy 799 based on the cost of service. The method by which the MN determines 800 whether the FA is a new FA is described in [1] and MAY use an FA-NAI 801 extension [11]. 803 The MN also needs to change its default router from oFA to nFA. The 804 MN MUST change its default router to nFA as soon as both the PRE- 805 REGISTRATION procedure has completed (Registration Reply is received) 806 as described in [1]. 808 Overall the MN behaves as described in [1] with the following 809 additions: the specified movement detection mechanism mentioned above 810 the ability to use the L2-MT to initiate an agent solicitation with a 811 special extension (PrRtSol). 813 When moving from a PRE-REGISTRATION network to a normal Mobile IP [1] 814 network the MN will no longer receive PrRtAdv messages (agent 815 advertisements with the LLA extension). If the MN still receives L2- 816 MTs then it will attempt to send PrRtSol messages. The FA will either 817 ignore the solicitation or will reply with a normal agent 818 advertisement [1]. In the absence of a PrRtSol, when receiving a 819 normal agent advertisement the MN MUST resort to normal Mobile IP 820 behaviour [1]. If the MN does not receive a PrRtAdv in reply to its 821 PrRtSol, it SHOULD retransmit the PrRtSol message once after 822 PRE_SOL_INTERVAL seconds and then for another PRE_SOL_ATTEMPTS times 823 with exponential backoff of the transmission interval. If a PrRtAdv 824 is not received within PRE_SOL_INTERVAL seconds after the last 825 PrRtSol attempt, the MN MUST resort to normal Mobile IP behaviour 826 [1]. The default values for PRE_SOL_ATTEMPTS is 2 and the default 827 value for PRE_SOL_INTERVAL is 1 second. It should be noted that the 828 performance of the movement detection mechanism mandated in PRE- 829 REGISTRATION MAY have sub-optimal behaviour on the other Mobile IP 830 [1] network. Instead when the MN moves from a normal Mobile IP [1] 831 network to a PRE-REGISTRATION network, the MN will start receiving 832 L2-MTs or PrRtAdv messages. When the MN receives L2-MTs or PrRtAdv 833 messages it MUST follow the PRE-REGISTRATION procedure. If there is 834 uncertainty as to which mode to choose (e.g. MN receives messages 835 from both PRE-REGISTRATION and normal FAs) the MN SHOULD choose PRE- 836 REGISTRATION. 838 3.7. L2 Address Considerations 840 Some special considerations should be taken with respect to the 841 wireless system on which this handoff method is being implemented. 842 Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In 843 PRE-REGISTRATION the MN is registering with an FA (nFA) that is not 844 its current first-hop router, therefore the L2 address of the 845 Ethernet frame containing the MN's Registration Request reaching the 846 nFA is not the MN's address. Therefore the FA MUST NOT use the 847 Ethernet address of the incoming Registration Request as the MN�s L2 848 address as specified in [1]. This applies to the cases where the 849 wireless access points are bridges or routers and independently of 850 whether the FA is implemented in the wireless access points 851 themselves. In this case the MN�s Registration Request (or Regional 852 Registration Request) MUST use an L2 address extension to the 853 Registration message when the MN is performing a registration. Such 854 an L2 address is either the same L2 address that remains constant as 855 the MN moves, or it is the MN's L2 address at nFA. To communicate its 856 L2 address, the MN includes a Generalised Link Layer Extension (see 857 Section 9.3) with its Registration Request (or Regional Registration 858 Request) message. If this extension is present the FA MUST use the L2 859 address contained in the extension to communicate with the MN. For 860 the same reasons, the MN MUST NOT use the source L2 address of the 861 Agent Advertisement message (PrRtAdv) as its default router�s L2 862 address. Therefore the oFA/nFA MUST include a Generalised Link Layer 863 Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv) 864 messages. 866 If a particular wireless L2 technology has defined a special L2 867 interface to the wireless network that allows the FA to resolve the 868 mapping between an MN's IP address and an L2 address without the need 869 to use the extension, the L2 address extension would not be needed. 871 3.8. Applicability of PRE-REGISTRATION Handoff 873 The PRE-REGISTRATON Handoff method is applicable to scenarios where a 874 period of service disruption due to layer 3 is not acceptable, for 875 example when performing real-time communications, and therefore where 876 an anticipation of the layer 3 handoff is required. Security for the 877 PRE-REGISTRATION handoff method is based on the same security model 878 as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION 879 is that the FA or MN are able to obtain an L2 trigger informing them 880 of a pending L2 handoff procedure. The target of the L2 handoff is 881 another access point or radio network that is in the coverage area of 882 a new FA. The L2 trigger information may be in the form of IP address 883 identifiers which may need to be resolved to IP addresses using 884 methods that may be specific to the wireless network and are not 885 considered here. If, for example, the oFA or MN determines that the 886 IP address of the new FA is oFA's address then the PRE-REGISTRATION 887 handoff SHOULD NOT be initiated. 889 The L2 trigger must allow enough time for the PRE-REGISTRATION 890 handoff procedure to be performed. In many wireless L2 technologies, 891 the L2 handoff procedure involves a number of message exchanges 892 before the effective L2 handoff is performed. For such technologies, 893 PRE-REGISTRATION handoff can be initiated at the beginning of the L2 894 handoff procedure and completed before the L2 handoff is completed. 895 It is efficient to engineer the network such that this succession of 896 events is ensured. 898 The PRE-REGISTRATION Handoff method is applicable in the following 899 cases: 901 - when the MN has locally defined policies that determine a 902 preference for one access over another, for example due to service 903 cost within the same or different technology, and therefore where 904 it is necessary to allow the MN to select the appropriate FA with 905 which to connect, 907 - when L3 cannot rely upon L2 security between the MN and the FA to 908 make modifications to IP routing and therefore authenticated 909 Mobile IP messages are required, 911 - when the trigger to initiate the handoff is received at the MN. 913 In the first case it is necessary to involve eventual local MN 914 policies in the movement detection procedure as described in 3.6. 916 4. The POST-REGISTRATION Handoff Method 918 The POST-REGISTRATION handoff method uses bi-directional edge tunnels 919 (BETs) or unidirectional tunnels to perform low latency change in the 920 L2 point of attachment for the MN without requiring any involvement 921 by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff. 923 Following a successful Mobile IP Registration between MN and oFA, the 924 oFA becomes the mobility anchor point for the MN, called the anchor 925 FA (aFA). When the MN moves from oFA to nFA, rather than performing 926 signaling over the wireless link to register with the nFA, the MN can 927 defer the L3 handoff and continue to use it�s aFA (i.e. oFA in this 928 case). If the MN moves to a third FA before registering with the nFA, 929 in certain cases described later, the third FA signals aFA to move 930 the wireless link end of the BET from nFA to it. The network end of 931 the BET remains anchored at aFA until the MN performs the Mobile IP 932 Registration. 934 +------+ 935 | CN | 936 +------+ 937 | 938 ... 939 | 940 +------+ BET +------+ 941 | aFA |==========| nFA | 942 +------+ +------+ 943 | wireless link 944 | 945 movement +------+ 946 ---------> | MN | 947 +------+ 949 Figure 5 - POST-REGISTRATION Concept 951 Messages between oFA/aFA and nFA MUST be authenticated. The minimal 952 requirement is that all FAs involved in low latency handoffs MUST 953 support manual pre-configuration of security associations with other 954 neighbouring FAs, involving shared keys and the default algorithms of 955 [1]. POST-REGISTRATION FAs MUST implement the inter-FA authentication 956 extension (FA-FA authentication extension) specified in [11] and MAY 957 additionally use other security mechanisms. 959 4.1. Two Party Handoff 961 Two party handoff occurs when the MN moves from oFA, where the MN 962 performed a Mobile IP Registration, to nFA. In the normal case, this 963 movement would result in a new Mobile IP Registration at nFA. However 964 in POST-REGISTRATION, the MN and nFA MAY delay this but maintain 965 connectivity using the BET (or alternatively unidirectional tunnel) 966 between oFA and nFA. The protocol is shown in Figure 6. 968 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT 969 | oFA |<-------->| nFA | 970 4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU 971 ^ ^ 972 old L2 | | new L2 973 +-------+ +-----+ 974 | | 975 | | 976 V V 977 +------+ movement 978 4c) L2-LU ---> | MN | ---------> 979 +------+ 981 Figure 6 - Two Party Handoff (POST-REGISTRATION) 983 The following describes the progress of a two party handoff. The 984 numbered items refer to steps in Figure 6. To identify the difference 985 between a source triggered HRqst/HRply message for tunnel creation, a 986 target triggered HRqst/HRply message for tunnel creation and 987 HRqst/HRply to extend or terminate a BET (or unidirectional tunnel), 988 the message will be identified respectively by (s), (t) and (r). 990 1) Either the oFA or nFA receives an L2 trigger informing it that a 991 certain MN is about to move from oFA to nFA. The two cases are: 993 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 994 trigger contains the MN's L2 address and an IP identifier 995 (the IP address itself or an L2 address that can be 996 resolved to the IP address) for nFA. 998 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 999 trigger contains the MN's L2 address and an IP identifier 1000 for oFA. 1002 2) The FA receiving the trigger sends a Handoff Request (HRqst) to 1003 the other FA. There two cases: 1005 a) If oFA is sending the HRqst, the H bit is set and the N 1006 bit is unset, indicating it is an HRqst(s). The HRqst(s) 1007 contains the lifetime of the tunnel the oFA is willing to 1008 support, the home network IP address of the MN, the MN's 1009 HA address and an LLA option with the MN's L2 address. If 1010 the lifetime is zero and the T bit is not set, the oFA is 1011 not willing to tunnel any packets for MN. A positive 1012 lifetime and a set T bit indicate that the oFA is willing 1013 to tunnel for the indicated time. Section 4.6 describes 1014 the HRqst(s) and Section 9 describes the LLA option. 1016 b) If nFA is sending the HRqst, the N bit is set and the H 1017 bit is unset, indicating it is an HRqst(t). If the T bit 1018 is set, nFA has requested a reverse tunnel and the 1019 HRqst(t) contains the lifetime of the tunnel the nFA is 1020 requesting. The HRqst(t) also contains an LLA option with 1021 the MN's L2 address. The MN's home network IP address and 1022 HA address are not sent, unless they are discovered by 1023 some means outside the scope of this document (for 1024 example, as part of the L2-TT). Section 4.6 describes the 1025 HRqst(t). 1027 3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the 1028 other FA. There are two cases: 1030 a) If oFA is sending the HRply, the N bit is set and the H 1031 and R bits are unset, indicating that the reply is in 1032 response to a HRqst(t), i.e. it is an HRply(t). If the T 1033 bit is set, the HRply(t) contains the tunnel lifetime the 1034 oFA is willing to provide, otherwise, the tunnel lifetime 1035 is set to zero, indicating that the oFA is not willing to 1036 provide tunnel service. If both HRply(t) and HRqst(t) have 1037 the T bit set and non-zero lifetime a BET is established. 1038 The HRply(t) also contains the MN's home subnet IP 1039 address, the MN's HA address, and an LLA option containing 1040 the MN's L2 address. Section 4.7 describes the HRply(t). 1042 b) If nFA is sending the HRply, the H bit is set and the N 1043 and R bits are unset, indicating the reply is in response 1044 to a HRqst(s), i.e. it is an HRply(s). If the T bit is 1045 set, the nFA indicates that it requests a reverse tunnel, 1046 and the lifetime field is set with the requested tunnel 1047 lifetime. The T Bit can be set in HRply only if the oFA 1048 had set the T bit in the corresponding HRqst or if the nFA 1049 requires to reverse tunnel incoming packets to oFA because 1050 ingress filtering is enabled on its network. This 1051 establishes a BET. The tunnel lifetime requested by the 1052 nFA must be less than or equal to the tunnel lifetime 1053 offered by oFA in the HRqst(s). Section 4.7 describes the 1054 HRply(s). 1056 4) The point during the L2 handoff in which the MN is no longer 1057 connected on a certain link is signaled by an L2-LD trigger at 1058 oFA and MN. Completion of L2 handoff is signaled by an L2-LU 1059 trigger at nFA and MN. Each node handles the trigger in the 1060 following way: 1062 a) When the oFA receives the L2-LD trigger, it begins 1063 forwarding MN-bound packets through the forward tunnel to 1064 nFA. 1066 b) When the nFA receives the L2-LU trigger, it begins 1067 delivering packets tunneled from the oFA to the MN and 1068 forwards any outbound packets from MN to the next hop 1069 using normal routing mechanisms or through the reverse 1070 tunnel to oFA or HA. 1072 c) When the MN receives the L2-LU, it MAY intiate the Mobile 1073 IP Registration process by soliciting an Agent 1074 Advertisement as described in [1]. If the Registration is 1075 successful the nFA takes over the role of anchor FA (aFA) 1076 from the oFA. Alternatively the MN MAY defer the Mobile IP 1077 Registration (see section 4.4). 1079 5) The oFA becomes an aFA if the MN moves to a third FA before 1080 having performed a Mobile IP Registration with nFA. 1082 6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a ping- 1083 pong situation arise, the oFA may be able to determine this case 1084 through the trigger mechanism (i.e. FA sees successive L2-ST/L2- 1085 TT followed by L2-LD and then L2-LU). The FA which originated 1086 the HRqst can in this case cancel the tunnel by sending an 1087 HRqst(r) to the other FA with lifetime zero. It will then simply 1088 continue delivering packets to MN exactly as if no handoff had 1089 been pending. Section 4.6 describes the HRqst(r). 1091 If in the HRqst/HRply the oFA has set the B bit and the nFA has not 1092 requested a reverse tunnel by setting the T bit, the nFA SHOULD 1093 tunnel outgoing packets from the MN to the HA because the MN has 1094 requested this service from the oFA. The nFA SHOULD offer this 1095 service only if either no security between the nFA and the MN's HA is 1096 required, or there is an existing nFA-HA security association in 1097 place. 1099 The actual timing of BET or unidirectional tunnel placement depends 1100 on the available L2 triggers. The forward tunnel from oFA to nFA is 1101 constructed using one of the tunneling procedures described in [1] 1102 for the HA to FA tunnel with the difference that the ends of the 1103 tunnel are at the oFA and nFA, respectively. The reverse tunnel from 1104 nFA to oFA is constructed as described in [3] with the difference 1105 that the network end of the tunnel is at the oFA instead of the HA. 1106 If both forward and reverse tunnels are established then a BET has 1107 been established. With optimal L2 trigger information, as described 1108 above, the FAs can setup the BET immediately when the L2 handoff is 1109 initiated, start tunneling MN-bound data when the link to the MN goes 1110 down and the nFA can use the link up trigger to start delivering 1111 packets. In the absence of optimal L2 trigger information, the HRply 1112 can act as the trigger to start tunneling MN-bound data, but in this 1113 case, the period of packet delivery disruption to the MN could still 1114 be present and additional measures may be required to provide 1115 uninterrupted service. Additonally, particular implementation and 1116 deployment scenarios could require that techniques be employed to 1117 smooth handoff by providing a means to convey packets arriving during 1118 the L2 handoff. The exact techniques involved in smoothing are 1119 currently under discussion by the working group and are outside the 1120 scope of this document. 1122 Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and 1123 target trigger (L2-TT) two party handoff, respectively. 1125 MN nFA oFA 1126 | | | 1127 | | HRqst(s) |<~~~ L2-ST 1128 | |<------------------| 1129 | | HRply(s) | 1130 | |------------------>| 1131 | | | 1132 --------------------------------------------<~~~ L2-LD 1133 L2 Handoff 1134 --------------------------------------------<~~~ L2-LU 1135 | | | 1136 |<------------------->| | 1137 | MN's traffic | | 1139 Figure 7 - Two Party Source Trigger Handoff Timing 1141 MN nFA oFA 1142 | | | 1143 | L2-TT ~~~>| HRqst(t) | 1144 | |------------------>| 1145 | | HRply(t) | 1146 | |<------------------| 1147 | | | 1148 --------------------------------------------<~~~ L2-LD 1149 L2 Handoff 1150 --------------------------------------------<~~~ L2-LU 1151 | | | 1152 |<------------------->| | 1153 | MN's traffic | | 1155 Figure 8 - Two Party Target Trigger Handoff Timing 1157 Once the tunnel between aFA and the current FA is in place, it is 1158 torn down by one of the following events: 1160 1) The aFA decides to stop tunneling because the lifetime it sent 1161 expires and was not renewed, or the aFA or current FA decide to 1162 terminate tunnel service prematurely for some other reason 1163 (refer to section 4.3). 1165 2) The MN completes the process by performing a Mobile IP 1166 Registration with the current FA. This may be initiated by the 1167 FA which sends an Agent Advertisement or by the MN which 1168 solicits for an Agent Advertisement as in [1]. 1170 3) The MN moves to a third FA (see section 4.2) 1172 4.2. Three Party Handoff 1174 Three party handoff is applicable when an MN that has already 1175 established an aFA and is receiving tunneled packets through its 1176 current FA moves to a new FA without performing a Mobile IP 1177 Registration. The need for this function depends on the wireless 1178 system in which POST-REGISTRATION is being implemented. For radio L2 1179 protocols in which it is possible for the MN to move so rapidly from 1180 one FA to another such that a probability exists that the Mobile IP 1181 Registration with nFA will not complete before the MN moves on, HTT 1182 SHOULD be implemented. Certain wireless systems and implementations 1183 do not allow such fast movement between FAs and may force the Mobile 1184 IP Registration to occur soon after L2 handoff, in which case three 1185 party handoff is not applicable. If this three party handoff feature 1186 is not implemented, the FA SHOULD send an Agent Advertisement to the 1187 MN after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD 1188 solicit a Router Advertisement after L2 handoff (L2-LU at MN). 1190 +------+ 1191 +--->| aFA |<---+ 1192 | +------+ | 1193 4b) HRqst(r) | | 3) HRqst(t) 1194 HRply(r) | | HRply(t) 1195 | | 1196 v 2a) HRqst v 1197 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT 1198 | oFA |<-------->| nFA | 1199 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU 1200 ^ HRply ^ 1201 old L2 | | new L2 1202 +-------+ +-----+ 1203 | | 1204 | | 1205 V V 1206 +------+ movement 1207 5b) L2-LU ~~~> | MN | ---------> 1208 +------+ 1210 Figure 9 - Three Party Handoff 1212 The L3 handoff can be deferred either because of a decision by the 1213 MN/FA (i.e. MN does not send Router Solicitations and FA does not 1214 send Agent Advertisements) or it may result from rapid movement 1215 between oFA and nFA that does not allow enough time for the 1216 registration to complete. This scenario is shown in Figure 9. In this 1217 case, oFA must inform nFA (i.e. the third FA) to contact aFA about 1218 moving the radio end of the tunnel. This is performed with the 1219 Handoff To Third (HTT) message. 1221 The general idea behind the three party handoff procedure is that the 1222 oFA supplies nFA with the same information it would have obtained via 1223 an L2-TT if handoff had occurred from aFA to nFA, then the nFA 1224 performs an HRqst(t)/HRply(t) sequence with aFA in order to move the 1225 BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to 1226 aFA to terminate the previous BET. 1228 The following describes the progress of a three party handoff. The 1229 numbered items refer to steps in Figure 9. 1231 1) Either the oFA or nFA receives an L2 trigger informing it that a 1232 certain MN is about to be moved. The two cases are: 1234 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 1235 trigger contains the MN's L2 address and an IP identifier 1236 (IP address or L2 address that can be mapped to an IP 1237 address) for nFA. 1239 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 1240 trigger contains the MN's L2 address and an IP identifier 1241 for oFA. 1243 2) The oFA and nFA exchange a HTT/HRply or HRqst/HTT pair. HTT is 1244 indicated by setting both the H and N bits in the HRqst or 1245 HRply. The HTT message MUST NOT have any tunnel flags set, 1246 because the tunnel is negotiated between the aFA and nFA, not 1247 oFA and nFA. There are two cases: 1249 a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA 1250 containing the MN's home IP address, the MN's HA address, 1251 an LLA containing the aFA's IP address, and an LLA 1252 containing the L2 address of the MN. This is enough 1253 information for nFA to perform a target triggered handoff 1254 with aFA. The nFA responds with a HRply(s). Section 4.8 1255 describes the HTT. 1257 b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA, 1258 exactly as if a two party handoff were occurring. The oFA 1259 responds with HTT containing the same information as in a) 1260 above. This is enough information for nFA to perform a 1261 target triggered handoff with aFA. 1263 3) Upon receipt of the HTT, the nFA first checks its Visitor Cache 1264 to see whether it is already tunneling for MN. If so, Step 6 is 1265 performed. If not, nFA performs a target triggered handoff with 1266 aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t) 1267 pair. Because aFA receives no L2 trigger indicating when L2 1268 handoff starts, it may start tunneling to nFA upon transmission 1269 of the HRply(t). 1271 4) Once the L2 handoff is underway and the MN gets disconnected at 1272 L2, aFA and oFA exchange messages canceling tunnel service 1273 between aFA and oFA and allowing aFA to start the tunnel with 1274 nFA. 1276 a) The point in the L2 handoff process where the MN gets 1277 disconnected from oFA is signaled at oFA by L2-LD. 1279 b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime 1280 zero with aFA. This cancels tunnel service between oFA and 1281 aFA. If aFA has not already established a tunnel to nFA, 1282 it must do so immediately upon receipt of the HRqst(r). 1283 The aFA provides tunneling service exactly as described in 1284 Section 4.1 Step 4a. 1286 5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA 1287 and/or MN. The nFA and MN handle the trigger in the following 1288 ways: 1290 a) The nFA provides packet delivery service to the MN exactly 1291 as described in Section 4.1, Step 4b. 1293 b) The MN either defers or initiates Mobile IP Registration 1294 when it receives the L2-LU, as in Section 4.1 1296 6) In the special case where nFA and aFA are the same (i.e. the MN 1297 is moving back to the original anchor FA), aFA recognizes that 1298 it is tunneling to oFA when it checks its Visitor Cache in Step 1299 3. In this case, there is no need for aFA to send the 1300 HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger 1301 on handoff completion, the aFA begins routing packets to MN and 1302 the tunnel to nFA is torn down. The oFA still exchanges the 1303 HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a 1304 priori that aFA and nFA are the same, but they are redundant. 1306 Unlike two party handoff, the timing of BET establishment between aFA 1307 and nFA cannot fully depend on the availability of L2 trigger 1308 information because aFA does not receive an L2 trigger signalling L2 1309 handoff. The two timing extremes at which aFA can place the BET with 1310 nFA are: 1312 1) At the earliest, aFA MAY start tunneling packets using the BET 1313 to nFA after sending the HRply(t) to nFA in response to the 1314 request for target-triggered handoff 1316 2) At the latest, aFA MAY start tunneling packets using the BET to 1317 nFA and tear down the BET with oFA when receiving the HRqst(r) 1318 from oFA indicating the MN has disconnected. 1320 In addition, aFA MAY continue tunneling to oFA if 1) is selected, 1321 until the HRqst(r) is received. If 1) is selected and the aFA 1322 continues to tunnel to oFA, the result may be duplicated packets at 1323 the MN, because the MN will receive packets through oFA on the old L2 1324 until it disconnects (L2-LD). If 2) is selected, the additional 1325 latency will add to the MN's L3 service disruption period. Of course, 1326 aFA can choose to place the BET some time between 1) and 2) if 1327 reliable bounds are available on the duration of time between L2- 1328 ST/L2-TT and the MN's disconnection (L2-LD). The exact selection of 1329 when to establish the BET is likely to be influenced by network 1330 engineering and implementation considerations, including whether a 1331 handoff smoothing solution is deployed, and is beyond the scope of 1332 this specification. 1334 Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and 1335 target trigger (L2-TT) three party handoff, respectively. 1337 MN nFA oFA aFA 1338 | | | | 1339 | | L2-ST ~~~~~> | | 1340 | | | | 1341 | |<-------------| | 1342 | | HTT | | 1343 | | | | 1344 | |------------->| | 1345 | | HRply(s) | | 1346 | | | | 1347 | |------------------------------>| 1348 | | HRqst(t) | | 1349 | | | | 1350 | |<------------------------------| 1351 | | HRply(t) | | 1352 | | | | 1353 ----------------------------------<~~~ L2-LD | 1354 |--------------->| 1355 L2 Handoff | HRqst(r) | 1356 | | 1357 |<---------------| 1358 | HRply(r) | 1359 | | 1360 ----------------------------------<~~~ L2-LU | 1361 | | | | 1362 |<-------------->| | | 1363 | MN's traffic | | | 1364 | | | | 1366 Figure 10 - Three Party Source Trigger Handoff Timing 1368 MN nFA oFA aFA 1369 | | | | 1370 | |<~~~ L2-TT | | 1371 | | | | 1372 | |------------->| | 1373 | | HRqst(t) | | 1374 | | | | 1375 | |<-------------| | 1376 | | HTT | | 1377 | | | | 1378 | |------------------------------>| 1379 | | HRqst(t) | | 1380 | | | | 1381 | |<------------------------------| 1382 | | HRply(t) | | 1383 | | | | 1384 ----------------------------------<~~~ L2-LD | 1385 |--------------->| 1386 L2 Handoff | HRqst(r) | 1387 | | 1388 |<---------------| 1389 | HRply(r) | 1390 | | 1391 ----------------------------------<~~~ L2-LU | 1392 | | | | 1393 | | | | 1394 |<-------------->| | | 1395 | MN's traffic | | | 1396 | | | | 1398 Figure 11 - Three Party Target Trigger Handoff Timing 1400 4.3. Renewal or Termination of Tunneling Service 1402 To prevent a BET from expiring when its lifetime runs out, the MN's 1403 current FA signals the aFA to either renew or terminate the BET. This 1404 may be the case when the MN defers Mobile IP Registration. If no such 1405 signal is received, the aFA will terminate the BET when the lifetime 1406 expires. In addition, the current FA or aFA may need to terminate the 1407 BET prior to the lifetime expiring. In order to avoid error 1408 conditions in which tunnels do not expire even though the MN to which 1409 they apply is no longer reachable, FAs SHOULD set the tunnel lifetime 1410 field to some value other that 0xffff, which indicates "good until 1411 cancelled". 1413 Figure 12 illustrates the message exchange that occurs between the FA 1414 needing to terminate or extend the tunnel (designated FA(1) in the 1415 figure) and the other FA (designated FA(2) in the figure). The 1416 HRqst(r)/HRply(r) is indicated by setting the R bit in the 1417 HRqst/HRply messages. If the HRqst(r) is renewing a BET then it 1418 contains a non-zero lifetime, otherwise if the lifetime is set to 1419 zero it indicates tunnel termination. The aFA has complete control 1420 over whether a tunnel is extended or terminated, and it MAY reply to 1421 a request for extension with a shorter lifetime than was requested. 1423 HRqst(r) 1424 +------+ <-------- +------+ 1425 | FA(2)| ---------> | FA(1)| 1426 +------+ HRply(r) +------+ 1428 Figure 12 - BET Renewal or Termination 1430 4.4. When will the MN perform a Mobile IP Registration? 1432 The MN/FA have control over when to perform the Mobile IP 1433 Registration. Although the MN/FA may decide to defer Mobile IP 1434 Registration for a certain period, three possible events can lead to 1435 the need to terminate tunneling service. If this occurs the MN MUST 1436 perform the Mobile IP Registration. These events are: 1438 1) The end of life for the BET is pending and a request by the 1439 current FA to aFA for renewal has been denied, or alternatively 1440 the current FA or aFA needs to terminate the BET prematurely. 1441 The FA in this case MUST initiate the Mobile IP Registration by 1442 sending an Agent Advertisement to the MN as in [1]. 1444 2) The MN itself decides to perform a Mobile IP Registration and 1445 initiates it by sending an Agent solicitation as in [1]. 1447 3) During a source triggered handoff, the oFA attempts to perform 1448 BET handoff but nFA is not capable of performing it. The FA in 1449 this case MUST initiate the Mobile IP Registration by sending 1450 the MN an Agent Advertisement as in [1]. Note that this 1451 situation will never arise during target triggered handoff 1452 because an HRqst(t) will not be sent to oFA by an nFA that 1453 doesn't support POST-REGISTRATION. 1455 Some detailed scenarios relating to case 2) will be described 1456 hereafter. According to [1], when using an FA care-of address the MN 1457 MAY use the FA as its default router. Otherwise it MUST choose its 1458 default router from those advertised in the ICMP Router Advertisement 1459 portion of the Agent Advertisement. Here we assume that the FA router 1460 is also the MN's default router. In POST-REGISTRATION, when both a 1461 forward and reverse tunnel are established between oFA and nFA (i.e. 1462 a BET) and the MN has moved to nFA, the oFA MUST continue sending 1463 Router Advertisements to the MN. This is to refresh the MN's default 1464 router entry. The Router Advertisements are tunnelled from oFA to nFA 1465 through the forward tunnel and MUST be unicast to the MN. Similarly 1466 to PRE-REGISTRATION, tunneling of Advertisements is possible only if 1467 the TTL limitation of [1] is relaxed. If this is not possible then 1468 the nFA MUST advertise to the MN as soon as it's link to the nFA is 1469 up (L2-UP). The MN MUST perform a Mobile IP registration [1] when it 1470 receives an Agent Advertisement following a POST-REGISTRATION 1471 handoff. 1473 Instead, when the forward tunnel is established but not the reverse 1474 tunnel, oFA MUST NOT advertise to the MN. In this case, as described 1475 previously, it is possible that the MN will not receive Router 1476 Advertisements for extended periods of time. According to [8] hosts 1477 will remove default router entries if the lifetime of the Router 1478 Advertisement expires and no further advertisements are received. 1479 Note that the ICMP Router Advertisement lifetime is not related to 1480 the Registration Lifetime in the Mobility Agent Advertisement 1481 extension [1]. To avoid this disruption the MN MUST solicit the 1482 default router (i.e. FA) before the lifetime of its active default 1483 router entry runs out, or alternatively the FA MUST advertise as soon 1484 as the MN-nFA link is up (L2-UP). This effectively means that the MN 1485 will at most be able to defer Mobile IP Registration for as long as 1486 the remaining lifetime of the active default router, as configured in 1487 the ICMP Router Advertisements. The MN MUST perform a Mobile IP 1488 registration [1] when it receives an Agent Advertisement following a 1489 POST-REGISTRATION handoff. 1491 4.5. Handoff Request (HRqst) Message format 1493 This is a new Mobile IP message carried on UDP (destination port 434) 1494 [1]. The UDP header is followed by the fields below. 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Type |H|N|R|M|G|T|B| Reserved | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Lifetime | Reserved | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | MN Home Address | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | HA Address | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | | 1508 + Identification + 1509 | | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Extensions ... 1512 +-+-+-+-+-+-+-+- 1514 Type TBD (Handoff Request) 1516 H Source triggered handoff request. When set and 1517 the N bit is unset, indicates that the request 1518 was the result of an L2-ST at oFA. 1520 N Target triggered handoff request. When set and 1521 the H bit is unset, indicates that the request 1522 was the result of an L2-TT at nFA. 1524 R Set if the request is an HRqst(r), i.e. a request 1525 to renew the tunnel. Neither the H nor the N bit 1526 are set. 1528 M The FA issuing the HRqst will use Minimal 1529 Encapsulation as defined in [1,5] for the tunnel. 1531 G The FA issuing the HRqst will use GRE [4] 1532 Encapsulation as defined in [1,5] for the tunnel. 1533 When this flag is set the HRqst may require 1534 extensions containing the GRE type and key 1535 fields, but they are outside the scope of this 1536 document. 1538 T For an HRqst(s), indicates that the oFA is 1539 willing to support both forward and reverse 1540 tunnel service. For an HRqst(t), indicates that 1541 the nFA is requesting reverse tunnel service. 1543 B When sent in an HRqst(s), indicates that the MN 1544 has requested a reverse tunnel to the HA and that 1545 the nFA SHOULD use reverse tunnel to the HA if it 1546 will not be reverse tunneling to the oFA. 1548 Lifetime The lifetime, in seconds, for which tunnel 1549 service for the MN will be maintained. If this is 1550 an HRqst(t), then the lifetime represents a 1551 request by nFA for a reverse tunnel. If this is 1552 an HRqst(s), then the lifetime represents the 1553 maximum amount of time that oFA is willing to 1554 maintain the both the forward and reverse tunnel. 1555 If this is an HRqst(r), then the lifetime 1556 Represents a request for the amount of time to 1557 renew the tunnel's lifetime. A value of 0 on an 1558 HRqst(s) indicates that the oFA is unwilling to 1559 grant any tunnel service. A value of 0 on an 1560 HRqst(t) indicates that the nFA does not require 1561 reverse tunnel service. A value of 0 on an 1562 HRqst(r) indicates that the tunnel should be 1563 terminated immediately. A value of 0xffff 1564 indicates infinity. 1566 MN Home Address For HRqst(s), the home address of the MN. 1568 HA Addr For HRqst(s), the HA address of the mobile node. 1570 Identification As in defined in [1]. 1572 Extensions The Message MUST include an LLA (see Section 9) 1573 containing the MN's L2 address and an L2 address 1574 that can be mapped to an IP address for the FA. 1575 This Message MUST contain the FA-FA 1576 Authentication Extension [11] that is used to 1577 secure the HRqst message. 1579 4.6. Handoff Reply (HRply) Message 1581 This is a new Mobile IP message carried on UDP (destination port 434) 1582 [1]. The UDP header is followed by the fields below. 1584 0 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Type |H|N|R|M|G|T|B| Reserved | Code | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Lifetime | Reserved | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | MN Home Address | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | HA Address | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | | 1596 + Identification + 1597 | | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Extensions ... 1600 +-+-+-+-+-+-+-+- 1602 Type TBD (Handoff Reply) 1604 Code A value indicating the result of the Handoff 1605 Request. Only two codes are currently supported, 1606 0, indicating success, and a nonzero value, 1607 indicating that the handoff cannot be performed. 1609 Lifetime The lifetime, in seconds, for which the 1610 bi-directional tunnel for the MN will be 1611 maintained. If this is an HRply(s), then the 1612 lifetime represents a request by nFA, and it can 1613 be any value up to the maximum value sent in the 1614 HRqst(s). Larger values are assumed to default to 1615 OFA's maximum. If this is an HRply(t), then the 1616 lifetime represents the maximum amount of time 1617 that the oFA will grant to the nFA. If this is a 1618 HRply(r), then the lifetime represents the 1619 amount of time by which the tunnel life will be 1620 extended. If the Code field indicates that 1621 handoff failed, the Lifetime field will be 1622 ignored and SHOULD be set to zero. A value of 1623 0 on an HRply(t) indicates that the oFA is 1624 unwilling to grant service. A value of 0 on an 1625 HRply(s) indicates that the nFA does not require 1626 service. A value of 0 on HRply(r) indicates that 1627 the tunnel lifetime will be terminated. A value 1628 of 0xffff indicates infinite lifetime. 1630 H Source triggered handoff reply. When set and 1631 the N bit is unset, indicates that the 1632 reply is in response to an HRqst(s). 1633 N Target triggered handoff reply. When set and 1634 the H bit is unset, indicates that the 1635 reply is in response to an HRqst(t). 1637 R Set if the reply is an HRply(r). Neither 1638 the H nor the N bit are set. 1640 M The FA issuing the HRqst will use Minimal 1641 Encapsulation as defined in [1,5] for 1642 the tunnel. 1644 G The FA issuing the HRqst will use GRE [4] 1645 Encapsulation as defined in [1,5] for the tunnel. 1646 When this flag is set the HRply may require 1647 extensions containing the GRE type and key 1648 fields, but they are outside the scope of this 1649 document. 1651 T For an HRply(s), indicates that the nFA is 1652 Requesting to reverse tunnel service. For an 1653 HRply(t), indicates that the oFA is willing to 1654 provide both forward and reverse tunnel service. 1656 B When sent in an HRply(t), indicates that the MN 1657 has requested a reverse tunnel to the HA and that 1658 the nFA SHOULD use reverse tunnel to the HA if 1659 it will not be reverse tunneling to the oFA. It 1660 can be set in HRply(t) only if the T bit was 1661 unset in the corresponding HRqst(t). 1663 MN Home Address For HRply(t), the home address of the MN. 1665 HA Addr For HRply(t), the HA address of the mobile node. 1667 Identification As in defined in [1]. 1669 Extensions This Message MUST contain the FA-FA 1670 Authentication Extension [11] that is used to 1671 secure the HRply message. 1673 4.7. Handoff To Third (HTT) Message 1675 The Handoff to Third message has the same format as the Handoff 1676 Request and Handoff Reply Messages, except both the H and N bits are 1677 set. If the HTT message is in response to a L2-ST and is sent to 1678 initiate a handoff, then, with the exception of the H and N bits, the 1679 message has the same fields set and includes the same extensions as 1680 an HRqst(s). If the HTT message is sent in response to an HRqst(t), 1681 then, with the exception of the H and N bits, the message has the 1682 same fields set and includes the same extensions as an HRply(t). The 1683 tunnel bits MUST NOT be set in the HTT message because BET 1684 construction is not negotiated between oFA and nFA, it is negotiated 1685 between nFA and aFA in the ensuing HRqst(t)/HRply(t). 1687 In addition, the HTT MUST contain the following extensions in the 1688 specified order: 1690 Solicited IP Address Option: containing aFA's Address 1692 LLA Option: containing the L2 address of the MN. 1694 4.8. Applicability of POST-REGISTRATION Handoff Method 1696 The POST-REGISTRATION handoff approach allows FAs to communicate 1697 directly about a pending handoff, and does not require any IP layer 1698 messages to be sent to or from a MN prior to the L2 handoff event. 1699 Therefore, it eliminates a possible source of handoff latency. This 1700 may be required when the link layer imposes hard deadlines on the 1701 time at which a handoff must occur, such as when a MN is rapidly 1702 moving out of a radio coverage area. Consequently, POST-REGISTRATION 1703 is primarily of interest in handoff between FAs that support the same 1704 radio access technology. Handoff between heterogeneous radio 1705 technologies will, of necessity, require interaction between the MN 1706 and the network, and so is not a domain of applicability for POST- 1707 REGISTRATION. 1709 Because a POST-REGISTRATION handoff is triggered by an unspecified 1710 mechanism that informs the oFA or nFA that an L2 handoff is pending, 1711 the POST-REGISTRATION approach is only applicable to networks where 1712 such a mechanism is available. For example, an L2 may provide 1713 indications of radio signal quality that cause the oFA or nFA to send 1714 the POST-REGISTRATION handoff messages. Any such indications must 1715 also provide each FA involved in the handoff with the identity of the 1716 other, so that messages can be sent to the right place. This may 1717 involve mapping L2 information onto FA IP addresses. Also, the FAs 1718 involved in a handoff must have pre-provisioned security arrangements 1719 so that the POST-REGISTRATION messages can be authenticated. If a 1720 handoff is to be completed as a result of the POST-REGISTRATION 1721 messaging, any L2 handoff indications must also be securely 1722 authenticated so that traffic to the old point of attachment is not 1723 improperly halted. 1725 POST-REGISTRATION handoff is appropriate in the following cases: 1726 - L2 triggers are available on the network to indicate that L2 1727 handoff is pending. 1729 - Pre-provisioned security mechanisms are in place to allow fast 1730 and secure messaging between the FAs and between the MN and an FA. 1732 - Access point choice by the MN is not a concern or choice requires 1733 user intervention and therefore is not on the critical path for 1734 handoff. 1736 5. Combined Handoff Method 1738 The combined method uses both PRE-REGISTRATION and POST-REGISTRATION 1739 handoff by running the PRE-REGISTRATION method and in parallel 1740 exchanging the POST-REGISTRATION handoff messages between oFA and 1741 nFA. The only case not considered already in the POST-REGISTRATION 1742 method is mobile-initiated handoff. In the mobile-initiated case, the 1743 Handoff Request message is initated by the oFA or nFA when it 1744 receives the Registration Request from the MN. 1746 The combined method follows the PRE-REGISTRATION Handoff when it is 1747 successful before the completion of the MN�s L2 handoff. However, if 1748 PRE-REGISTRATION does not complete prior to the expiration of a timer 1749 on one or the other of the FAs, POST-REGISTRATION handoff is used. 1750 Using POST-REGISTRATION handoff insulates the MN from delays caused 1751 by errors such as loss of one of the Mobile IP messages involved in 1752 PRE-REGISTRATION. 1754 The start of POST-REGISTRATION is gated by the expiration of a timer 1755 on the FAs. The timer is started at oFA following a source-trigger, 1756 at nFA following the target-trigger, or at oFA and nFA following the 1757 receipt of the Registration Request from the MN in the mobile- 1758 initiated case. The timer is reset if the Registration Reply message 1759 is received by the appropriate FA and sent to the MN. 1761 Although the POST-REGISTRATION Handoff Request and Handoff Reply 1762 messages are exchanged in advance, no forwarding of traffic between 1763 oFA and nFA is performed unless the timer expires. The timer should 1764 be set to a value that allows forwarding between oFA and nFA to begin 1765 before the MN completes the L2 handoff to nFA. 1767 6. Layer 2 and Layer 3 Handoff timing Considerations 1769 In the optimal cases considered in the PRE-REGISTRATION and POST- 1770 REGISTRATION handoffs it was assumed that a timely L2 trigger would 1771 be received in such a way that packets could be delivered to the MN 1772 via its nFA immediately upon connection. In this way the MN would not 1773 suffer disruption due to the L3 handoff. However such precise timing 1774 of the L2 trigger and handoff mechanism with respect to the actual L2 1775 handoff event will not be possible in all wireless systems and may 1776 depend on particular implementation techniques. Therefore some 1777 uncertainty may exist at L3 as to exactly when the L2 connection 1778 between the MN and the nFA becomes fully established and can be used 1779 for L3 traffic. It is possible that in certain implementations 1780 traffic will be re-reouted too early or too late with respect to the 1781 moment when the connection between the MN and the nFA becomes fully 1782 established. The techniques which will solve this problem and allow 1783 the MN to receive traffic independently of the timing of the L2 1784 handoff event are currently under study by the Mobile IP WG but are 1785 outside the scope of this document. 1787 7. Reverse Tunneling Support 1789 The handoff methods all support reverse tunneling. The MN may request 1790 reverse tunneling [3] by setting the 'T' bit in its Registration 1791 Request. In the case of POST-REGISTRATION, if the MN had requested 1792 Reverse Tunneling previously at oFA, the Handoff message from oFA 1793 (see Section 4) includes the 'T' bit enabled to inform nFA to 1794 establish a BET for the visitor entry. Typically, the 'T' bit will 1795 always be set to ensure that any delays in the MN receiving its new 1796 care of address do not result in any delay in uplink packet 1797 transmission from the MN, but local policies and particular L2 1798 technologies may allow the reverse tunnel to be turned off unless the 1799 MN specifically requests it. 1801 8. Handoff Signaling Failure Recovery 1803 In general and to a greater extent in wireless networks, packets 1804 carrying handoff signaling may be dropped or lost due to errors on 1805 the link. In this section, we consider mechanisms for recovery from 1806 handoff signaling failures. 1808 8.1. PRE-REGISTRATION Signaling Failure Recovery 1810 Failure of PRE-REGISTRATION signaling breaks down into three cases: 1812 1) Loss of messages ProxyRtSol and ProxyRtAdv on the air link. 1814 2) Loss of the solicitation by an FA to obtain another neighbouring 1815 FA's Advertisment or loss of the neighbouring FA's 1816 advertisement. 1818 3) Failure of the standard Mobile IP Registration. 1820 Of these, case 3) is handled by standard Mobile IP mechanisms 1821 described in [1]. Case 2) is relatively unlikely because spontaneous 1822 packet drop rates on the fixed network are caused by congestion or 1823 router failure and likely to be low. Since bit error rates on 1824 wireless links are higher than on fixed links, case 1) is more likely 1825 to occur. In the following subsections, the cases 1) and 2) are 1826 considered. 1828 8.1.1. Failure of ProxyRtSol and ProxyRtAdv 1830 PRE-REGISTRATION handoff can fail in network-initiated handoff when 1831 the ProxyRtAdv sent by oFA in response to the source trigger (L2-ST) 1832 or the advertisement sent by nFA in response to the target trigger 1833 (L2-TT) fails to reach the MN. PRE-REGISTRATION handoff can also fail 1834 in mobile-initiated handoff when either the ProxyRtSol sent from the 1835 MN or return ProxyRtAdv sent from the oFA are dropped. To reduce the 1836 probability that ProxyRtAdv and ProxyRtSol are lost the MN and FA MAY 1837 transmit multiple copies of these messages. Sholuld these messages 1838 fail anyway, in both cases the MN connects to the nFA without having 1839 received any prior signaling. When this happens the MN MUST solicit 1840 an FA Advertisement when it connects to nFA at L2 (L2-UP) and perform 1841 standard Mobile IP registration on the nFA as specified in [1]. 1843 8.1.2. Failure of Inter-FA solicitation and advertisement 1845 The solicitation from an FA to another neighbouring FA may fail or 1846 the corresponding advertisement from the neighbouring FA may be lost. 1847 To reduce the probability that these messages are lost, the FAs MAY 1848 transmit multiple copies of these messages. If a failure occurs 1849 anyway, the FA soliciting the Agent Advertisment is unable to send a 1850 ProxyRtAdv in response to a source trigger or to a mobile-initiated 1851 ProxyRtSol. In these cases, when the MN does not receive a 1852 notification or confirmation of a PRE-REGISTRATION handoff, the MN 1853 MUST perform a standard Mobile IP registration as soon as it connects 1854 to the nFA (L2-UP) as specified in 8.1.1 and [1]. 1856 8.2. POST-REGISTRATION Signaling Failure Recovery 1858 Failure occurs in POST-REGISTRATION when either the HRqst or HRply 1859 message is dropped. The effects of the failure and the recovery 1860 procedure depend on which message is dropped, and whether the 1861 handover is source or target triggered. Since all of the POST- 1862 REGISTRATION signaling is going over the fixed network, it can be 1863 expected that spontaneous dropping of packets in the absence of 1864 congestion and router failure should be a relatively rare event. 1865 Nevertheless, failure recovery mechanisms SHOULD be implemented. 1867 8.2.1. HRqst Message Dropped 1869 If the HRqst message is dropped, the effect is the same for both 1870 source and target-triggered handoff. In either case, the FA to which 1871 the HRqst was destined will never respond with an HRply message. If 1872 the handoff is source-triggered, then the nFA never learns of the 1873 handoff, and the oFA never receives confirmation. If the handoff is 1874 target-triggered, then the oFA never learns of the handoff, and the 1875 nFA never receives confirmation. 1877 The recovery procedure in this case is as follows: the oFA MUST NOT 1878 construct a forward tunnel when the MN moves off-link (L2-LD) if the 1879 handoff is source-triggered, and the nFA MUST NOT construct a reverse 1880 tunnel if the handoff is target-triggered. If the nFA was not 1881 informed of the handoff by an HRqst message (corresponding to failure 1882 of source-triggered handoff) or if the handoff was not confirmed by 1883 an HRply message (corresponding to failure of target-triggered 1884 handoff) the nFA MUST unicast an Agent Advertisement to the MN as 1885 soon as its L2 connection is established (L2-LU at nFA). 1887 8.2.2. HRply Message Dropped 1889 If the HRply message is dropped, the FA sending the HRply will assume 1890 that the handoff has been confirmed, but the FA that is expecting to 1891 receive the HRply does not receive confirmation. In this case, the 1892 failure recovery procedure is different for source-triggered and 1893 target-triggered handoffs. 1895 In a target-triggered handoff, the oFA assumes the handoff is 1896 confirmed because it has sent the HRply, but the nFA has not received 1897 it so it does not have confirmation. The oFA starts tunneling packets 1898 to the nFA when the MN moves from its link (L2-LD). The nFA MUST send 1899 a FA Advertisement to the MN as soon as its L2 link is up (L2-UP at 1900 nFA) and MAY drop the tunneled packets. The nFA SHOULD send an ICMP 1901 Destination Unreachable [9] message to the oFA. When the oFA receives 1902 this message it will terminate the tunnel and stop forwarding 1903 packets. If reverse tunneling was requested the nFA MUST NOT reverse 1904 tunnel because it has not received confirmation of the handoff. 1906 In source-triggered handoff, the nFA assumes the handoff is confirmed 1907 because it has sent the HRply, but the oFA has not received it so it 1908 does not have confirmation. Without failure recovery, the MN could 1909 move to the nFA without the oFA being able to start the forward 1910 tunnel for the MN's packets, and the MN would not be able to initiate 1911 a Mobile IP registration because it does not know that the handoff 1912 has failed. In this situation, the oFA MUST send out a HRqst message 1913 to the nFA with lifetime zero as soon as the MN leaves its link (L2- 1914 LD). The oFA SHOULD continue to retransmit the HRqst message, with 1915 exponential backoff for CONFIG-HFAIL seconds or until it receives an 1916 HRply acknowledging the request to cancel the tunnel. The default 1917 value for CONFIG-HFAIL is 10 seconds. When the nFA receives the 1918 HRqst, it MUST immediately send an Agent Advertisement to the MN, as 1919 is the case whenever a tunnel is cancelled. In addition, the oFA MUST 1920 also drop any packets received through the reverse tunnel from the 1921 nFA. The oFA SHOULD NOT send the ICMP Destination Unreachable message 1922 to the nFA because the nFA has been informed by the HRqst message to 1923 cancel the tunnel. However, if the nFA receives an ICMP Destination 1924 unreachable message for the tunnel prior to receiving the HRqst 1925 canceling the tunnel, it MUST send an FA Advertisement to the MN and 1926 cancel the tunnel. 1928 9. Generalized Link Layer Address Extension 1930 This section defines the Generalized Link Layer Address (LLA) 1931 Extension, used by any node that needs to communicate Link Layer 1932 Addresses. The format of the extension relies on sub-types, where 1933 each sub-type defines its own sub-structure. This draft defines six 1934 sub-types. Future RFCs should allocate their own sub-type and define 1935 their own address formats. 1937 0 1 2 3 1938 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 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Type | Length | Sub-Type | LLA ... 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 Type 1945 TBD (skippable) [1] - when used for Mobile IP Registrations 1946 TBD (skippable) [1] - when used for Router Advertisements 1948 Length 1950 The length of the Link Layer Address + the one octet Sub-Type 1951 field 1953 Sub-Type 1955 This field contains the Link Layer sub-type identifier 1957 LLA 1959 Contains the Link Layer Address 1961 In this document, six subtypes are defined: 1963 1 3GPP2 International Mobile Station Identity and 1964 Connection ID [12] 1965 2 3GPP International Mobile Subscriber Identity [16] 1966 3 Ethernet 48 bit MAC address [5] 1967 4 64 bit Global ID, EUI-64 [6] 1968 5 Solicited IP Address 1969 6 Access Point Identifier 1971 The following subsections describe the extensions. 1973 9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension 1975 The IMSI Link Layer Address Extension contains the International 1976 Mobile Station Identity. 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Type | Length | Sub-Type | IMSI ... 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Type 1986 TBD (skippable) [1] 1988 Length 1990 The length of the IMSI field + the one octet Sub-Type field 1992 Sub-Type 1994 1 1996 IMSI 1998 Contains the IMSI, in the form: 2000 : 2002 Where the is an ASCII-based representation of the 2003 International Mobile Station Identifier, most significant 2004 digit first, ":" is ASCII 0x3a, and the Connection ID is the 2005 ASCII representation of a small, decimal number used for 2006 distinguishing different link-layer connections from the 2007 same device. 2009 9.2. 3GPP IMSI Link Layer Address Extension 2011 The IMSI Link Layer Address Extension contains the International 2012 Mobile Station Identity. 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Type | Length | Sub-Type | IMSI ... 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 Type 2022 TBD (skippable) [1] 2024 Length 2026 The length of the IMSI field + the one octet Sub-Type field 2028 Sub-Type 2030 2 2032 IMSI 2034 Contains the IMSI, a number composed of 15-digits or less, 2035 coded as described in [16]. 2037 9.3. Ethernet Link Layer Address Extension 2039 The Ethernet Link Layer Address Extension contains the 48 bit 2040 Ethernet MAC Address, as defined in [5]. 2042 0 1 2 3 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Type | Length | Sub-Type | MAC ... 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 Type 2050 TBD (skippable) [1] 2052 Length 2054 7 (includes the Sub-Type field) 2056 Sub-Type 2058 3 2060 MAC 2062 Contains the 48 bit Ethernet MAC Address. 2064 9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension 2066 The 64-Bit Global Identifier (EUI-64) Address Extension contains the 2067 64 bit address, as defined in [6]. 2069 0 1 2 3 2070 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 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Type | Length | Sub-Type | MAC ... 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 Type 2077 TBD (skippable) [1] 2079 Length 2081 9 (includes the Sub-Type field) 2083 Sub-Type 2085 4 2087 MAC 2089 Contains the 64-Bit Global Identifier Address. 2091 9.5. Solicited IP Address Extension 2093 The 32-bit Solicited IP Address Extension contains the IP address of 2094 the agent (FA) being solicited. This extension MAY be present in an 2095 ICMP Agent Solicitation as explained in Section 3.3. 2097 0 1 2 3 2098 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 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | Type | Length | Sub-Type | IP addr ... 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 Type 2105 TBD (skippable) [1] 2107 Length 2109 5 (includes the Sub-Type field) 2111 Sub-Type 2113 5 2115 IP Address 2117 Contains the 32-Bit IP Address of the solicited node. 2119 9.6. Access Point Identifier Extension 2121 The 32-bit Access Point Identifier Extension contains an Identifier 2122 of the Access Point to which the MN will move. This may be a wireless 2123 L2 identifier. The MN is able to solicit an advertisement from the FA 2124 servicing a certain Access Point by using this extension with Agent 2125 Solicitations as explained in Section 3.3. 2127 0 1 2 3 2128 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 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | Type | Length | Sub-Type | AP ID... 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 Type 2135 TBD (skippable) [1] 2137 Length 2139 5 (includes the Sub-Type field) 2141 Sub-Type 2143 6 2145 AP ID 2147 Contains the 32-Bit Access Point Identifier. 2149 10. IANA Considerations 2151 Section 9 introduces the Generalized Link Layer Address Extension 2152 numbering space that requires IANA management. This specification 2153 makes use of the subtype values 1-6, and all other values other than 2154 zero (0) are available for assignment via IETF consensus [15]. The 2155 numbers for the Generalized Link Layer Address Extension are taken 2156 from the numbering space defined for Mobile IP registration and 2157 Router Advertisement extensions in [1]. The same Generalized Link 2158 Layer Address Extensions are used in both Mobile IP Registration and 2159 Router Advertisement messages, which have different extension 2160 numbering spaces defined in [1]. Therefore two separate Generalized 2161 Link Layer Address Extension numbering spaces are required having the 2162 same sub-type values. The Generalized Link Layer Address Extension 2163 numbering MUST NOT conflict with any numbers used in [1], [3], [7], 2165 [13] and [14]. 2167 In the POST-REGISTRATION Handoffs method, Sections 4.4 and 4.5 2168 require numbers assigned from the Mobile IP control message type 2169 address space. The numbers assigned MUST NOT conflict with [1] and 2170 [11]. 2172 11. Security Considerations 2174 A security consideration for PRE-REGISTRATION method, as discussed in 2175 Section 3.8, is that oFA and nFA MUST share a security association to 2176 authenticate messages transported between them and oFA must be 2177 authorized to solicit nFA. The inter-FA messages (solicitations and 2178 advertisements) MUST be authenticated using ESP [10]. The absence of 2179 this security would allow denial of service attacks from malicious 2180 nodes at any distance from the FA. Otherwise, PRE-REGISTRATION uses 2181 the security mechanisms described in [1] and [11]. 2183 POST-REGISTRATION introduces a new change to Mobile IP, which is the 2184 possibility that a MN may receive packets from an FA with which it 2185 has not yet registered. In the event that the MN does not wish to 2186 receive packets from unknown FAs, it MAY drop them. In a similar way 2187 to PRE-REGISTRATION, oFA and nFA MUST share a security association 2188 required to protect the Handoff Request and Reply messages. The 2189 Handoff Request and Reply messages MUST be authenticated using the 2190 FA-FA authentication extension [11]. The absence of this security 2191 would allow impersonation attacks and denial of service attacks. 2193 The minimal requirement is that all FAs involved in low latency 2194 handoffs MUST support manual pre-configuration of security 2195 associations with neighbouring FAs, involving shared keys and the 2196 default algorithms of [1]. 2198 Since the techniques outlined in this document depend on particular 2199 L2 information (triggers) to optimize performance, some level of L2 2200 security is assumed. Both PRE and POST-REGISTRATION techniques depend 2201 on L2 triggers, but the L2 security implications are different for 2202 the two techniques. In particular, in POST-REGISTRATION the L2 2203 triggers initiate the establishment of tunnels which route IP packets 2204 for the MN to its new location. Therefore the L2 triggers MUST be 2205 secured against any tampering by malicious nodes, either mobile or 2206 within the wired network. The L2 addresses or IP addresses for the MN 2207 and the FAs that appear in the L2 triggers MUST correspond to the 2208 actual nodes that are participating in the handover. If there is any 2209 possibility that tampering may occur, the recipient of an L2 trigger 2210 MUST have some way of authenticating the L2 information. Provided the 2211 L2 triggers are so secured, the nodes involved in a handover can 2212 reject any traffic from a node whose L2 address or IP address was not 2213 received in a trigger, yet tries to send traffic. Wireless networks 2214 that do not provide such features will be subject to impersonation 2215 attacks, where malicious nodes could cause FAs to believe that a MN 2216 has moved to other service areas or to allow a bogus MN to obtain 2217 unauthorized service from an FA prior to performing a Mobile IP 2218 registration. In PRE-REGISTRATION the security of L2 triggers has 2219 different implications. The PRE-REGISTRATION technique depends on 2220 Mobile IP security between MN and FA, so the same security 2221 considerations in [1] apply. Should malicious nodes be able to 2222 generate or modify L2 trigger information (i.e. L2-ST or L2-TT), this 2223 would cause advertisements to be sent to the MN. They would consume 2224 wireless resources and processing in the MN, but would not allow an 2225 impersonation attack. In order to prevent such denial of service 2226 attacks, there should be a limit on the number of advertisements that 2227 an FA (oFA) will relay to the MN as a result of the reception of L2 2228 triggers. This number will depend on the L2 technology. In order to 2229 prevent any such denial of service attacks the L2 triggers SHOULD be 2230 secured. 2232 12. Acknowledgements 2234 Thanks to the Mobile IP WG chairs, Phil Roberts and Basavaraj Patil, 2235 for their input and to Jonathan Wood for valuable comments on PRE- 2236 REGISTRATION. 2238 13. Normative References 2240 [1] C. Perkins, Editor, "IP Mobility Support for IPv4", RFC 3220, 2241 January 2002. 2243 [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement 2244 Levels". BCP 14, RFC 2119, March 1997. 2246 [3] G. Montenegro, "Reverse Tunneling for Mobile IP, revised", RFC 2247 3024, January 2001. 2249 [4] D. Farinacci, T. Li, S. Hanks, and P. Traina, "Generic 2250 Routing Encapsulation (GRE)", RFC 2784, Internet Engineering 2251 Task Force, March 2000. 2253 [5] D. Plummer, "An Ethernet Address Resolution Protocol - or 2254 Converting Network Protocol Addresses to 48.bit Ethernet 2255 Address for Transmission on Ethernet Hardware", RFC 826, 2256 Symbolics,Inc., November 1982. 2258 [6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 2259 Registration Authority", 2260 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 2261 March 1997. 2263 [7] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 2264 Extensions", RFC 3012, November 2000. 2266 [8] S. Deering, "ICMP Router Discovery", RFC 1256, September 1991 2268 [9] J. Postel, "Internet Control Message Protocol," RFC 792, 2269 September 1981. 2271 [10] S.Kent, R. Atkinson, "IP Encapsulating Security Payload 2272 (ESP)", RFC 2406, November 1998. 2274 [11] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional 2275 Tunnel Management ", draft-ietf-mobileip-reg-tunnel-06 (work 2276 in progress), March 2002. 2278 14. Informative References 2280 [12] TIA/EIA/IS-2000. 2282 [13] G. Montenegro and V. Gupta, "Sun's SKIP Firewall Traversal for 2283 Mobile IP", RFC 2356, June 1998. 2285 [14] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier 2286 Extension", RFC 2794, March 2000. 2288 [15] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA 2289 Considerations Section in RFCs", BCP 26, RFC 2434, October 2290 1998. 2292 [16] 3GPP TS 23.003 (www.3gpp.org). 2294 15. Authors� Addresses 2296 The document editor and authors may be contacted at the addresses 2297 below: 2299 Karim El Malki 2300 Ericsson Radio Systems AB 2301 LM Ericssons Vag. 8 2302 126 25 Stockholm 2303 SWEDEN 2304 Phone: +46 8 7195803 2305 E-mail: Karim.El-Malki@ericsson.com 2307 Pat Calhoun 2308 Black Storm Networks 2309 250 Cambridge Ave. Suite 200 2310 Palo Alto, CA 94306 2311 USA 2312 Phone: +1 650 617 2932 2313 E-mail: pcalhoun@bstormnetworks.com 2315 Tom Hiller 2316 Lucent Technologies 2317 Rm 2F-218 2318 263 Shuman Blvd 2319 Naperville, IL 60566-7050 2320 USA 2321 Phone: +1 630 979 7673 2322 Fax: +1 630 979 7673 2323 E-Mail: tom.hiller@lucent.com 2325 James Kempf 2326 NTT DoCoMo USA Labs 2327 181 Metro Drive, Suite 300 2328 San Jose, CA 95110 2329 USA 2330 Phone: +1 408 451 4711 2331 EMail: kempf@docomolabs-usa.com 2333 Peter J. McCann 2334 Lucent Technologies 2335 Rm 2Z-305 2336 263 Shuman Blvd 2337 Naperville, IL 60566-7050 2338 USA 2339 Phone: +1 630 713 9359 2340 Fax: +1 630 713 4982 2341 E-Mail: mccap@lucent.com 2343 Ajoy Singh 2344 Motorola 2345 1501 West Shure Drive 2346 Arlington Heights, IL � 60004 2347 USA 2348 Phone: +1 847 632 6941 2349 E-mail: asingh1@email.mot.com 2351 Hesham Soliman 2352 Ericsson Radio Systems 2353 Torshamnsgatan 23, Kista 2354 Stockholm 2355 SWEDEN 2356 Phone: +46 8 4046619 2357 Fax: +46 8 4043630 2358 E-mail: Hesham.Soliman@era.ericsson.se 2360 Sebastian Thalanany 2361 Motorola 2362 1475 West Shure Drive 2363 Arlington Heights, IL - 60004 2364 USA 2365 Phone: +1 847 435 9296 2366 E-mail: sthalan1@email.mot.com 2368 The working group can be contacted via the current chairs: 2370 Basavaraj Patil Phil Roberts 2371 Nokia Corporation Megisto Systems Inc. 2372 6000 Connection Drive Suite 120, 20251 Century Blvd 2373 Irving, TX 75039 Germantown MD 20874 2374 USA USA 2375 Phone: +1 972-894-6709 Phone: +1 847-202-9314 2376 EMail: Raj.Patil@nokia.com EMail: proberts@megisto.com 2377 Fax : +1 972-894-5349 2379 16. Full Copyright Statement 2381 Copyright (C) The Internet Society (2003). All Rights Reserved. 2383 This document and translations of it may be copied and furnished to 2384 others, and derivative works that comment on or otherwise explain it 2385 or assist in its implementation may be prepared, copied, published 2386 and distributed, in whole or in part, without restriction of any 2387 kind, provided that the above copyright notice and this paragraph are 2388 included on all such copies and derivative works. However, this 2389 document itself may not be modified in any way, such as by removing 2390 the copyright notice or references to the Internet Society or other 2391 Internet organizations, except as needed for the purpose of 2392 developing Internet standards in which case the procedures for 2393 copyrights defined in the Internet Standards process must be 2394 followed, or as required to translate it into languages other than 2395 English. 2397 The limited permissions granted above are perpetual and will not be 2398 revoked by the Internet Society or its successors or assigns. 2400 This document and the information contained herein is provided on an 2401 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2402 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2403 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2404 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2405 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2407 Acknowledgement 2409 Funding for the RFC Editor function is currently provided by the 2410 Internet Society. 2412 Appendix A - Gateway Foreign Agents 2414 The Mobile IP Regional Registration specification [11] introduces the 2415 Gateway Foreign Agent (GFA), as a mobility agent that two FAs 2416 providing service to a MN have in common. Figure A.1 provides an 2417 example of a MN's initial registration through the GFA. If this is 2418 the first registration message, the message MUST be forwarded to the 2419 HA. All packets destined for the mobile will be delivered to the GFA, 2420 which in turn will forward the packets to the FA servicing the MN. 2422 Reg Req +-----+ Reg Req 2423 +----------->| oFA |--------------+ 2424 | +-----+ | 2425 | v 2426 +----+ +-----+ Reg Req +----+ 2427 | MN | | GFA |<------->| HA | 2428 +----+ +-----+ +----+ 2430 +-----+ 2431 | nFA | 2432 +-----+ 2434 Figure A.1 - Initial Registrations through GFA 2436 If the MN moves to a nFA that is serviced by a GFA common with oFA, 2437 the MN MAY issue a Regional Registration Request (see Figure A.2). 2438 The Regional Registration message does not need to be forwarded to 2439 the HA, since the MN's traffic can still be delivered to the same 2440 GFA. This optimized approach effectively reduces the latency involved 2441 in the registration process. 2443 +-----+ 2444 | oFA | 2445 +-----+ 2447 +----+ +-----+ +----+ 2448 | MN | | GFA | | HA | 2449 +----+ +-----+ +----+ 2450 | ^ 2451 | +-----+ | 2452 +------------>| nFA |-------------+ 2453 Regional Reg +-----+ Regional Reg 2455 Figure A.2 - Regional Registration through GFA 2457 Note that the GFA may also be the MN�s first-hop router. 2459 Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs 2461 For MNs that have two wireless network interfaces, either on the same 2462 wireless network or on wireless networks having different wireless L2 2463 technologies, the techniques discussed in this document may be 2464 unnecessary if the Mobile IP stack on the MN allows switching an IP 2465 address binding between interfaces. This Appendix discusses how 2466 multiple wireless interfaces can aid low latency handoff. 2468 Figure B.1 illustrates the normal and hierarchical MIPv4 models. As 2469 shown in the figure, assume that the MN is connected to Radio Network 2470 1 (RN1) and is registered with oFA through which it is receiving 2471 traffic. Suppose MN enters the coverage area of RN2 and nFA and that 2472 it prefers connectivity to this network for reasons beyond the scope 2473 of this document (e.g. user preferences, cost, QoS available etc.). 2474 The MN activates the interface to RN2 but continues communicating 2475 through RN1. The MN may solicit advertisements from nFA through the 2476 interface connected to RN1 to speed up the handoff process, provided 2477 there is no TTL restriction, or it can solicit advertisements through 2478 the interface connected to RN2 if it has been configured for IP 2479 traffic. 2481 +------+ +---------+ 2482 | HA |--------| (GFA) | 2483 +------+ +---------+ 2484 / \ 2485 / \ 2486 ... ... 2487 / \ 2488 / \ 2489 +------+ +------+ 2490 | oFA | | nFA | 2491 +------+ +------+ 2492 | | 2493 +------+ +------+ 2494 | RN1 | | RN2 | 2495 +------+ +------+ 2497 +------+ 2498 | MN | ---------> 2499 +------+ 2501 Movement 2503 Figure B.1 - Network Model for Mobile IPv4 With Multi-Access 2505 Once the MN is registered with nFA and is successfully receiving and 2506 transmitting through the new network, it tears down the interface to 2507 RN1. If the MN has enough time to complete this procedure without 2508 incurring degraded service or disconnection, the MN would experience 2509 a seamless multi-access handoff but it may not be possible in all 2510 cases, due to network coverage or for other reasons. Should multiple 2511 interface handoff be possible then the low latency methods described 2512 in this document are not necessary. 2514 In order to support the possible failure of the connectivity with the 2515 new network (RN2/nFA) in the short period following handoff, the MN 2516 may use the "S" bit in its Mobile IP Registration Request to maintain 2517 simultaneous bindings both its existing (HA or GFA) binding with oFA 2518 and a new binding with nFA.