idnits 2.17.1 draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2440. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2446), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1199 has weird spacing: '...) HRqst v...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document 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 2004) is 7254 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) == Unused Reference: '14' is defined on line 2406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 3012 (ref. '7') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-08 -- Possible downref: Normative reference to a draft: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '15') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '17') (Obsoleted by RFC 4306) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. El Malki, Editor 3 INTERNET-DRAFT Ericsson 4 Expires: December 2004 June 2004 6 Low Latency Handoffs in Mobile IPv4 7 9 Status of this memo 11 By submitting this Internet-Draft, I (we) certify that any applicable 12 patent or other IPR claims of which I am (we are) aware have been 13 disclosed, and any of which I (we) become aware will be disclosed, in 14 accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I (we) accept the provisions of 17 Section 4 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF MIP4 WG. Comments should be 35 directed to the MIP4 WG mailing list, mip4@ietf.org. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs 44 between subnets served by different Foreign Agents. In certain 45 cases, the latency involved in these handoffs can be above the 46 threshold required for the support of delay-sensitive or real-time 47 services. The aim of this document is to present two methods to 48 achieve low-latency Mobile IP handoffs. In addition, a combination 49 of these two methods is described. The described techniques allow 50 greater support for real-time services on a Mobile IPv4 network by 51 minimising the period of time when a Mobile Node is unable to send or 52 receive IP packets due to the delay in the Mobile IP Registration 53 process. 55 TABLE OF CONTENTS 57 1. Introduction.....................................................3 58 1.1. Terminology.................................................4 59 1.2. The Techniques..............................................5 60 1.3. L2 triggers.................................................7 61 1.4. Requirements language.......................................9 62 2. Requirements.....................................................9 63 3. The PRE-REGISTRATION Handoff Method..............................9 64 3.1. Operation..................................................10 65 3.2. Network-Initiated Handoff..................................12 66 3.3. Mobile-Initiated Handoff...................................14 67 3.4. Obtaining and Proxying nFA Advertisements..................15 68 3.4.1. Inter-FA Solicitation.................................15 69 3.4.2. Tunneled nFA Advertisements...........................16 70 3.5. Caching Router Advertisements..............................16 71 3.6. Movement Detection and MN Considerations...................17 72 3.7. L2 Address Considerations..................................18 73 3.8. Applicability of PRE-REGISTRATION Handoff..................19 74 4. The POST-REGISTRATION Handoff Method............................20 75 4.1. Two Party Handoff..........................................20 76 4.2. Three Party Handoff........................................25 77 4.3. Renewal or Termination of Tunneling Service................30 78 4.4. When will the MN perform a Mobile IP Registration?.........30 79 4.5. Handoff Request (HRqst) Message format.....................32 80 4.6. Handoff Reply (HRply) Message..............................33 81 4.7. Handoff To Third (HTT) Message.............................35 82 4.8. Applicability of POST-REGISTRATION Handoff Method..........36 83 5. Combined Handoff Method.........................................37 84 6. Layer 2 and Layer 3 Handoff timing Considerations...............37 85 7. Reverse Tunneling Support.......................................38 86 8. Handoff Signaling Failure Recovery..............................38 87 8.1. PRE-REGISTRATION Signaling Failure Recovery................38 88 8.1.1. Failure of ProxyRtSol and ProxyRtAdv..................39 89 8.1.2. Failure of Inter-FA solicitation and advertisement....39 90 8.2. POST-REGISTRATION Signaling Failure Recovery...............39 91 8.2.1. HRqst Message Dropped.................................39 92 8.2.2. HRply Message Dropped.................................40 93 9. Generalized Link Layer Address Extension........................41 94 9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension..42 95 9.2. 3GPP IMSI Link Layer Address Extension.....................42 96 9.3. Ethernet Link Layer Address Extension......................43 97 9.4. Access Point Identifier Extension..........................45 98 10. IANA Considerations............................................45 99 10.1. New Extension values......................................45 100 10.2. New Message Type and Code.................................46 101 11. Security Considerations........................................47 102 12. Contributing Authors...........................................49 103 13. Acknowledgements...............................................48 104 14. Editor's Address...............................................48 105 15. References.....................................................49 106 15.1. Normative References......................................49 107 15.2. Informative References....................................50 108 Intellectual Property Statement....................................50 109 Copyright Statement................................................51 110 Disclaimer of Validity.............................................51 111 Appendix A - Gateway Foreign Agents................................52 112 Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......53 114 1. Introduction 116 Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer 117 handoff between subnets served by different Foreign Agents (FAs). In 118 certain cases, the latency involved in handoff can be above the 119 threshold required for the support of delay-sensitive or real-time 120 services. The aim of this document is to present two methods to 121 achieve low-latency Mobile IP handoff during movement between FAs. 122 The presented techniques allow greater support for real-time services 123 on a Mobile IPv4 network by minimising the period of time when a MN 124 is unable to send or receive IP packets due to the delay in the 125 Mobile IP Registration process. 127 In the rest of this section, terminology used throughout the document 128 is presented, the handoff techniques are briefly described, and the 129 use of link layer information is outlined. In Section 2, a brief 130 description of requirements is presented. Section 3 describes the 131 details of the PRE-REGISTRATION handoff technique, while Section 4 132 describes the details of the POST-REGISTRATION handoff technique. In 133 Section 5, a combined method using the two handoff techniques 134 together is presented. Section 6 discusses Layer 2 and Layer 3 135 handoff timing considerations. Section 7 discusses reverse tunneling 136 support, Section 8 describes mechanisms to recover from message 137 failures while Section 9 describes protocol extensions required by 138 the handoff techniques. Sections 10 and 11 discuss IANA and security 139 considerations. Finally the two appendices discuss additional 140 material related to the handoff techniques. Appendix A gives a short 141 introduction to Regional Registrations [11] which can be used 142 together with low latency handoffs. Appendix B discusses low latency 143 handoff when a MN has multiple wireless L2 interfaces, in which case 144 the techniques in this document may not be necessary. 146 1.1. Terminology 148 This section presents a few terms used throughout the document. 150 oFA - old Foreign Agent (FA), the FA involved in handling the 151 care of address of a Mobile Node (MN) prior to a Layer 3 152 (L3) handoff. 154 nFA - new Foreign Agent, the FA anticipated to be handling a 155 MN's care of address after completion of an L3 handoff. 157 aFA - anchor Foreign Agent, the FA that is currently handling 158 the network end of the tunnel in POST-REGISTRATION. 160 L2 handoff - Movement of a MN's point of Layer 2 (L2) 161 connection from one wireless access point to another. 163 L3 handoff - Movement of a MN between FAs which involves 164 changing the care-of address (CoA) at Layer 3 (L3). 166 L2 trigger - Information from L2 that informs L3 of particular 167 events before and after L2 handoff. The descriptions of L2 168 triggers in this document are not specific to any particular 169 L2, but rather represent generalizations of L2 information 170 available from a wide variety of L2 protocols. 172 L2-MT - An L2 trigger that occurs at the MN informing of 173 movement to a certain nFA (Mobile Trigger). 175 L2-ST or source trigger - An L2 trigger that occurs at oFA, 176 informing the oFA that L2 handoff is about to occur. 178 L2-TT or target trigger - An L2 trigger that occurs at nFA, 179 informing the nFA that a MN is about to be handed off to 180 nFA. 182 L2-LU - An L2 trigger that occurs at the MN or nFA, informing 183 that the L2 link between MN and nFA is established. 185 L2-LD - An L2 trigger that occurs at the oFA, informing the oFA 186 that the L2 link between MN and oFA is lost. 188 low latency handoff - L3 handoff in which the period of time 189 during which the MN is unable to receive packets is 190 minimized. 192 low loss handoff - L3 handoff in which the number of packets 193 dropped or delayed is minimized. Low loss handoff is often 194 called smooth handoff. 196 seamless handoff - L3 handoff that is both low latency and low 197 loss. 199 bi-directional edge tunnel (BET) - A bidirectional tunnel 200 established between two FAs for purposes of temporarily 201 routing a MN's traffic to/from it on a new subnet without 202 requiring the MN to change CoA. 204 ping-ponging - Rapid back and forth movement between two 205 wireless access points often due to failure of L2 handoff. 206 Ping-ponging can occur if radio conditions for both the old 207 and new access points are about equivalent and less than 208 optimal for establishing a good, low-error L2 connection. 210 network-initiated handoff - L3 handoff in which oFA or nFA 211 initiates the handoff. 213 mobile-initiated handoff - L3 handoff in which the MN initiates 214 the handoff. 216 IP address identifier - An IP address of a MN or FA, or an L2 217 identifier that allows an FA to deduce the IP address of a 218 MN or FA. If the IP address identifier is an L2 identifier, 219 it may be specific to the L2 technology. 221 1.2. The Techniques 223 Mobile IP was originally designed without any assumptions about the 224 underlying link layers over which it would operate so that it could 225 have the widest possible applicability. This approach has the 226 advantage of facilitating a clean separation between L2 and L3 of the 227 protocol stack, but it has negative consequences for handoff latency. 228 The strict separation between L2 and L3 results in the following 229 built-in sources of delay: 231 - The MN may only communicate with a directly connected FA. This 232 implies that a MN may only begin the registration process after 233 an L2 handoff to nFA (new FA) has completed. 235 - The registration process takes some non-zero time to complete as 236 the Registration Requests propagate through the network. During 237 this period of time the MN is not able to send or receive 238 IP packets. 240 This document presents techniques for reducing these built-in delay 241 components of Mobile IP. The techniques can be divided into two 242 general categories, depending on which of the above problems they 243 are attempting to address: 245 - Allow the MN to communicate with the nFA while still connected 246 to the oFA. 248 - Provide for data delivery to the MN at the nFA even before the 249 formal registration process has completed. 251 The first category of techniques allows the MN to "pre-build" its 252 registration state on the nFA prior to an underlying L2 handoff. 253 The second category of techniques allow for service to continue 254 uninterrupted while the handoff is being processed by the network. 256 Three methods are presented in this draft to achieve low-latency L3 257 handoff, one for each category described above and one as a 258 combination of the two: 260 - PRE-REGISTRATION handoff method, 262 - POST-REGISTRATION handoff method, 264 - combined handoff method. 266 The PRE-REGISTRATION handoff method allows the MN to be involved in 267 an anticipated IP-layer handoff. The MN is assisted by the network 268 in performing an L3 handoff before it completes the L2 handoff. The 269 L3 handoff can be either network-initiated or mobile-initated. 270 Accordingly, L2 triggers are used both in the MN and in the FA to 271 trigger particular L3 handoff events. The PRE-REGISTRATION method 272 coupled to L2 mobility helps to achieve seamless handoffs between 273 FAs. The basic Mobile IPv4 concept involving advertisement followed 274 by registration is supported and the PRE-REGISTRATION handoff method 275 relies on Mobile IP security. No new messages are proposed, except 276 for an extension to the Agent Solicitation message in the 277 mobile-initiated case. 279 The POST-REGISTRATION handoff method proposes extensions to the 280 Mobile IP protocol to allow the oFA (old FA) and nFA (new FA) to 281 utilize L2 triggers to set up a bi-directional tunnel between oFA and 282 nFA that allows the MN to continue using its oFA while on nFA's 283 subnet. This enables a rapid establishment of service at the new 284 point of attachment which minimizes the impact on real-time 285 applications. The MN must eventually perform a formal Mobile IP 286 registration after L2 communication with the new FA is established, 287 but this can be delayed as required by the MN or FA. Until the MN 288 performs registration, the FAs will setup and move bidirectional 289 tunnels as required to give the MN continued connectivity. 291 The combined method involves running a PRE-REGISTRATION and a 292 POST-REGISTRATION handoff in parallel. If the PRE-REGISTRATION 293 handoff can be performed before the L2 handoff completes, the 294 combined method resolves to a PRE-REGISTRATION handoff. However, if 295 the PRE-REGISTRATION handoff does not complete within an access 296 technology dependent time period, the oFA starts forwarding traffic 297 for the MN to the nFA as specified in the POST-REGISTRATION handoff 298 method. This provides for a useful backup mechanism when completion 299 of a PRE-REGISTRATION handoff cannot always be guaranteed before the 300 L2 handoff completion. 302 It should be noted that the methods described in this document may be 303 applied to MNs having a single interface (e.g. Wireless LAN 304 interface) or multiple interfaces (e.g. one WLAN and one cellular 305 interface). However, the case of multiply-interfaced MNs needs 306 special consideration, since the handoff methods described in this 307 document may not be required in all cases (see Appendix B). 309 1.3. L2 triggers 311 An L2 trigger is a signal of an L2 event. In this document, the L2 312 events relate to the L2 handoff process. One possible event is early 313 notice of an upcoming change in the L2 point of attachment of the 314 mobile node to the access network. Another possible event is the 315 completion of relocation of the mobile node's L2 point of attachment 316 to a new L2 access point. This information comes from L2 317 programmatically or is derived from L2 messages. Although the 318 protocols outlined in this document make use of specific L2 319 information, Mobile IP should be kept independent of any specific L2. 320 L2 triggers are an abstraction mechanism for a technology specific 321 trigger. Therefore, an L2 trigger that is made available to the 322 Mobile IPv4 stack is assumed to be generic and technology 323 independent. The precise format of these triggers is not covered in 324 this document, but the information required to be contained in the L2 325 triggers for low latency handoffs is specified. 327 In order to properly abstract from the L2, it is assumed that one of 328 the three entities - the MN, oFA, or nFA - is made aware of the need 329 for an L2 handoff, and that the nFA or MN can optionally also be made 330 aware that an L2 handoff has completed. A specific L2 will often 331 dictate when a trigger is received and which entity will receive it. 332 Certain L2s provide advance triggers on the network-side, while 333 others provide advance triggers on the MN. Also, the particular 334 timing of the trigger with respect to the actual L2 handoff may 335 differ from technology to technology. For example, some wireless 336 links may provide such a trigger well in advance of the actual 337 handoff. In contrast, other L2s may provide little or no 338 information in anticipation of the L2 handoff. 340 An L2 trigger may be categorized according to whether it is 341 received by the MN, oFA, or nFA. Table 1 gives such a 342 categorization along with information expected to be contained in the 343 trigger. The methods presented in this document operate based on 344 different types of L2 triggers as shown in Table 1. Once the L2 345 trigger is received, the handoff processes described hereafter are 346 initiated. The three triggers: L2-ST, L2-TT and L2-MT are 347 independent of each other and MUST NOT occur together since each will 348 trigger a different type of handoff behaviour. 350 +-------------+----------------------+------------------------------+ 351 | L2 trigger | Mobile | Source | 352 | | Trigger | Trigger | 353 | | (L2-MT) | (L2-ST) | 354 +-------------+----------------------+------------------------------+ 355 | Recipient | MN | oFA | 356 +-------------+----------------------+--------------+---------------+ 357 | Method | PRE | PRE | POST | 358 | | mobile- | network- | source | 359 | | initiated | initiated | trigger | 360 +-------------+----------------------+--------------+--------------- 361 | When? | sufficiently before | sufficiently | sufficiently | 362 | | the L2 handover | before L2 | before L2 | 363 | | so that MN can | handover for | handover for | 364 | | solicit ProxyRtAdv | FA to send | oFA & nFA to | 365 | | from oFA. | proxyRtAdv | exchange | 366 | | | to MN. | HRq/HRy. | 367 +-------------+----------------------+--------------+---------------+ 368 | Parameters | nFA IP address | nFA IP address identifier | 369 | | identifier | MN IP address identifier | 370 | | | | 371 +-------------+----------------------+------------------------------+ 373 +------------+------------------------+-------------+---------------+ 374 | L2 trigger | Target | Link-Up | Link-Down | 375 | | Trigger | (L2-LU) | (L2-LD) | 376 | | (L2-TT) | | | 377 |------------+------------------------+-------------+---------------+ 378 | Recipient | nFA | MN or nFA | oFA | 379 |------------+------------+-----------+-------------+---------------+ 380 | Method | PRE | POST | PRE & POST | POST | 381 | | network | target | | | 382 | | initiated | trigger | | | 383 |------------+------------------------+-------------+---------------+ 384 | When? | | when radio | when radio | 385 | | same as | link between| link between | 386 | | source trigger | MN & nFA is| MN and oFA | 387 | | | established | is lost | 388 |------------+------------------------+-------------+---------------+ 389 | Parameters | oFA IP address id | @MN: nFA IP | MN IP address | 390 | | MN IP address id. | or L2 addr. | identifier | 391 |------------+------------------------+-------------+---------------+ 393 Table 1 - L2 Trigger 395 1.4. Requirements language 397 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 398 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 399 described in [2]. 401 2. Requirements 403 The following requirements are applicable to low-latency handoff 404 techniques and are supported by the methods in this document: 406 - to provide low-latency and low loss handoff for real time services, 408 - to have no dependence on a wireless L2 technology, 410 - to support inter- and intra-access technology handoffs, 412 - to limit wireless bandwidth usage. 414 3. The PRE-REGISTRATION Handoff Method 416 The PRE-REGISTRATION handoff method is based on the original concept 417 of Mobile IP handoff as specified in [1], in which: 419 - an advertisement for an FA is received by an MN, 421 - the advertisement allows the MN to perform movement detection, 423 - the MN registers with the FA. 425 It reuses the basic messages specified in [1]. The PRE-REGISTRATION 426 method allows both the MN and FA to initiate handoff. In both cases, 427 abiding by the basic Mobile IP handoff concept allows the MN to 428 choose with which FA to register. The PRE-REGISTRATION method can 429 make use of L2 triggers on either the FA or MN side, depending on 430 whether network-initiated or mobile-initiated handoff occurs. 431 PRE-REGISTRATION also supports both the normal Mobile IP model [1] in 432 which the MN is receiving packets from a Home Agent (HA) and the 433 Regional Registration model [11] in which the MN receives packets 434 from a Gateway Foreign Agent (GFA). It also supports movement where 435 a new AAA transaction must occur to authenticate the MN with the new 436 domain. 438 3.1. Operation 440 The overall PRE-REGISTRATION Handoff mechanism is summarised in 441 Figure 1 below: 443 +---------+ 444 | HA (GFA)|<---------+ 445 +---------+ | 4. (Reg)RegReq 446 | 5. (Reg)RegReply 447 v 448 +-----+ 1a. RtSol +-----+ 449 | | -----------------> | nFA | 450 | oFA | 1b. RtAdv | | 451 +-----+ <----------------- +-----+ 452 ^ | ^ 453 (2a. ProxyRtSol)| | 2b | 454 | | ProxyRtAdv | 3. (Reg)RegReq 455 | | | 456 | v --------------------+ 457 +-----+ / 458 | MN | 459 +-----+ - - - - - -> 460 Movement 462 Figure 1 - PRE-REGISTRATION Handoff Protocol 464 The following steps provide more detail on the protocol: 466 1. Messages 1a is a Router Solicitation (RtSol) from oFA to nFA. 467 Message 1b is a Router (Agent) Advertisement (RtAdv) from nFA 468 to oFA. These messages SHOULD occur in advance of the 469 PRE-REGISTRATION Handoff in order not to delay the handoff. 470 For this to occur, oFA SHOULD solicit and cache 471 advertisements from neighbouring nFAs, thus decoupling the 472 timing of this exchange from the rest of the PRE-REGISTRATION 473 Handoff. When the L3 handoff is initiated by a target L2 474 trigger at nFA (L2-TT), message 1b equals message 2b and is 475 sent unsolicited directly to MN (tunneled by nFA to MN 476 through oFA) instead of being relayed by oFA. 478 2. Message 2a is a Proxy Router Solicitation (PrRtSol). It is 479 different from a normal Router Solicitation since it is 480 actually soliciting an advertisement from a router different 481 from the one receiving this message. The presence of message 482 2a indicates that the handoff is mobile-initiated and its 483 absence means that the handoff is network-initiated. In 484 mobile-initiated handoff, message 2a occurs if there is an L2 485 trigger in the MN to solicit for a Proxy Router Advertisement 486 (PrRtAdv). When message 2a is received by the oFA, the oFA 487 MUST return the Proxy Router Advertisement (Agent 488 Advertisement) in message 2b. In network-initiated handoff, 489 the L2 trigger occurs at oFA and oFA MUST relay the Agent 490 Advertisement in message 2b without the need for the MN to 491 solicit. Note that it is also possible for nFA to advertise 492 directly to the MN in the network-initiated target-trigger 493 case (section 3.2). In all cases message 2b is simply nFA's 494 agent advertisement. 496 3. The MN performs movement detection upon receipt of either a 497 solicited or unsolicited Agent Advertisement and, if 498 appropriate, it sends a Registration Request (RegReq) message 499 [1] in message 3 to nFA. When a local Gateway Foreign Agent 500 (GFA) is present this message MAY be a Regional Registration 501 Request (RegRegReq) [11]. Message 3 is routed through oFA 502 since the MN is not directly connected to nFA prior to the L2 503 handoff. 505 4. Messages 4 and 5 complete the standard Mobile IP Registratio 506 [1] or Regional Registration [11] initiated with message 3. 507 In the network-initiated target-triggered case, the 508 Registration Reply in message 5 SHOULD be sent by nFA to the 509 MN both through oFA and directly on-link. This is necessary 510 since the MN may have to detach from oFA, due to the wireless 511 L2 connection, before it received the Reply. Figures 2 and 3 512 illustrate this tunneling, though it is not shown in Figure 513 1. Tunneling can take place either at L3 or L2. In the 514 mobile-initiated and network-initiated source-triggered cases 515 the nFA will not have the oFA's address. Therefore the Reply 516 MUST be unicast by nFA to the MN on-link as soon as the MN 517 connects to nFA (L2-UP). The MN's L2 address is obtained 518 using the extensions in Section 9, as described in 3.7. 520 5. If the Registration is successful then packets for the MN are 521 now tunnelled from the HA (or GFA) to the nFA where the MN 522 has moved to. 524 PRE-REGISTRATION is not dependent on Regional Registration extensions 525 [11]. However if the HA is at a distance (in terms of delay) from 526 the nFA, the use of a local GFA reduces the time required for the 527 handoff procedure to complete. 529 The time at which the L2 trigger is received by the oFA or MN, 530 thereby triggering the PRE-REGISTRATION handoff, compared to the time 531 at which the actual L2 handoff occurs is important for the optimal 532 performance of the low latency handoff. That is, in the optimal case 533 the L2 trigger will be received, the four messaging steps of PRE-REG 534 described above will be completed (i.e. Registration Request 535 processed by HA or GFA) and the first packet redirected by the HA (or 536 GFA) to nFA will reach the MN at the moment in which the MN's L2 link 537 to nFA is fully established. The MN would therefore not suffer any 538 disruption due to the L3 handoff. This may require particular 539 implementation techniques and deployment, such as L2 techniques, 540 buffering and bicasting, but these are outside the scope of this 541 document. In addition further handoff smoothing considerations may 542 be required to prevent the loss of packets in-flight between HA (or 543 GFA) and oFA while the MN performs a PRE-REGISTRATION handoff. These 544 are also outside the scope of this document. 546 Figures 2, 3, and 4 contain message timing diagrams for both the 547 network-initiated and mobile-initiated PRE-REGISTRATION handoff 548 procedures. 550 3.2. Network-Initiated Handoff 552 As described in Table 1, a PRE-REGISTRATION handoff can be initated 553 at oFA by a source trigger or at nFA by a target trigger. A 554 source-triggered network-initiated handoff occurs when an L2 trigger 555 is received at the oFA informing it of a certain MN's upcoming 556 movement from oFA to nFA. The L2 trigger contains information such 557 as the MN's IP address identifier (i.e. the IP address itself or an 558 identifier which can be resolved to the IP address) and the nFA's IP 559 address identifier. An identifier may be specific to the wireless 560 technology (e.g. Access Point ID). A target-triggered 561 network-initiated handoff occurs when an L2 trigger is received at 562 the nFA informing it of a certain MN's upcoming movement from oFA. 563 This type of trigger is also shown in Table 1. The L2 trigger 564 contains information such as the MN's IP address identifier and the 565 oFA's IP address identifier. 567 In a source-triggered handoff, when oFA receives the trigger (L2-ST) 568 it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to 569 the MN. The PrRtAdv is nFA's agent advertisement [1] with one of the 570 link-layer extensions described in sections 9.3 or 9.6. The use of 571 the contents of this extension is described in section 3.7. Messages 572 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is 573 received (see section 3.4.1). Message 2a is not used. In a 574 target-triggered handoff, when nFA receives the trigger (L2-TT) it 575 MUST tunnel an Agent Advertisement to the MN through oFA to initiate 576 the L3 handoff. The inner Advertisement is unicast by nFA to MN, 577 thus nFA treats the target-trigger as a Router Solicitation. This 578 Advertisement is tunneled to oFA which functions as a normal router, 579 decapsulating the Advertisement and forwarding it to the MN. This 580 messages MUST be authenticated to prevent attacks (see section 581 3.4.2). 583 Figures 2 and 3 contain message timing diagrams describing the 584 PRE-REGISTRATION network-initiated handoff for source and target 585 triggers. 587 MN oFA nFA HA/GFA 588 | |<~~~~~~ L2-Source | | 589 | | Trigger | | 590 |<--------------------| | | 591 | ProxyRtAdv | | | 592 | | | | 593 |---------------------------------------->| | 594 | RegReq or | | | 595 | RegRegReq | |------------------->| 596 | (routed via oFA) | | RegReq or RegRegReq| 597 | | | | 598 | | |<-------------------| 599 | | | (Reg)RegReply | 600 |<----------------------------------------| | 601 | | (Reg)RegReply | | 602 | | (sent to MN when it attaches to nFA) | 604 Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram 605 (Network-Initiated, Source Trigger) 607 MN oFA nFA HA/GFA 608 | | L2-Target~~~~~~~~>| | 609 | | Trigger | | 610 | | | | 611 | |...................| | 612 |<--------------------------------------- | | 613 | (ProxyRtAdv) |...................| | 614 | | Tunneled Agent | | 615 | | Advertisement | | 616 | | | | 617 |---------------------------------------->| | 618 | RegReq. or | | | 619 | RegRegReq | |------------------->| 620 | (routed via oFA) | | RegReq or RegRegReq| 621 | | | | 622 | | |<-------------------| 623 | | | (Reg)RegReply | 624 |<----------------------------------------| | 625 | | (Reg)RegReply | | 626 | | (sent to MN when it attaches to nFA) | 628 Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram 629 (Network-Initiated, Target Trigger) 631 3.3. Mobile-Initiated Handoff 633 As shown in Table 1, a mobile-initiated handoff occurs when an L2 634 trigger is received at the MN informing that it will shortly move to 635 nFA. The L2 trigger contains information such as the nFA's IP 636 address identifier (i.e. nFA's IP address or an identifier which can 637 be resolved to the nFA's IP address). The message timing diagram is 638 shown in Figure 4. 640 MN oFA nFA HA/GFA 641 |<~~~~~ L2-Trigger | | | 642 | | | | 643 |-------------------->| | | 644 | ProxyRtSol | | | 645 | | | | 646 |<--------------------| | | 647 | ProxyRtAdv | | | 648 | | | | 649 |---------------------------------------->| | 650 | RegReq or | | | 651 | RegRegReq | |------------------->| 652 | (routed via oFA) | | RegReq or RegRegReq| 653 | | | | 654 | | |<-------------------| 655 | | | (Reg)RegReply | 656 |<----------------------------------------| | 657 | | (Reg)RegReply | | 658 | | (sent to MN when it attaches to nFA) | 660 Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram 661 (Mobile-Initiated) 663 As a consequence of the L2 trigger (L2-MT) the MN MUST send message 664 1a, the Proxy Router Solicitation (PrRtSol). This message is a 665 unicast agent solicitation to oFA for a Proxy Router Advertisement 666 (PrRtAdv). This solicitation MUST have a TTL as in [1]. The Proxy 667 Router Advertisement Solicitation unicast to oFA is an agent 668 solicitation with a special extension. The solicitation MUST have an 669 extension containing an IP address identifier because the MN is 670 soliciting another specific FA's advertisement from the oFA. This 671 specific FA will be the MN's nFA. The IP address identifier contains 672 the IP address of the nFA or an identifier that can be used by the 673 oFA to resolve to nFA's IP address. If the identifier is not an IP 674 address, it MAY be specific to the underlying wireless technology, 675 for example, an Access Point or Base Station ID. The extension is a 676 subtype of the Generalised Link-Layer Address extension described in 677 Section 9. Two extension subtypes have been defined to contain the 678 nFA's IP address and an access point identifier. They are called the 679 Solicited Agent IP Address Extension and the Access Point Identifier 680 Extension, and are described in Sections 9.5 and 9.6. These two 681 extensions SHOULD NOT be present in the same PrRtSol message. 683 When oFA receives the PrRtSol message it MUST reply to the MN with 684 the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is 685 simply the agent advertisement for the requested nFA, proxied by oFA. 686 In order to expedite the handoff, the actual nFA advertisement SHOULD 687 be cached by the oFA following a previous exchange with nFA, shown in 688 messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message 689 MUST contain the nFA's L2 address (using the LLA extension in 9.2). 690 This is further described in section 3.7. 692 3.4. Obtaining and Proxying nFA Advertisements 694 Since L2 triggers are involved in initiating PRE-REGISTRATION 695 handoff, the trigger timing SHOULD be arranged such that a full L3 696 PRE-REGISTRATION handoff can complete before the L2 handoff process 697 completes. That is, the L2 handoff should be completed after the 698 MN's Registration with the nFA is performed (message 3 in Fig.1). 699 The Registration SHOULD be transmitted more than once to reduce the 700 probability that it is lost due to errors on the wireless link. This 701 would not apply to reliable wireless links where retransmissions are 702 performed at layer 2 in case of error to guarantee packet delivery. 704 A PRE-REGISTRATION handoff in this case requires the MN to receive an 705 agent advertisement from the nFA through the old wireless access 706 point. How to achieve this is discussed in the following 707 subsections. Messages exchanged between FAs MUST be authenticated to 708 prevent attacks. The minimal requirement is that all FAs involved in 709 low latency handoffs MUST support manual pre-configuration of 710 security associations with other neighbouring FAs, involving shared 711 keys and the default algorithms of [1] (see the Security 712 Considerations section). 714 3.4.1. Inter-FA Solicitation 716 This applies to the network-initiated source-triggered (L2-ST) and 717 mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes 718 that oFA has access to the IP address of the nFA. The IP address of 719 nFA is obtained by means of an L2 trigger at oFA in the 720 network-initiated case (see Section 3.2) or by means of the extension 721 to the Proxy Router Solicitation (PrRtSol) from the MN in the 722 mobile-initiated case (see Section 3.3). 724 Once the oFA receives an L2 trigger and obtains the address of the 725 nFA for a specific MN, it MUST send a unicast agent solicitation to 726 nFA. The nFA replies to the oFA by unicasting an Agent Advertisement 727 with appropriate extensions. This method removes the TTL limitation 728 of [1] for Mobile IP messages (i.e. TTL=1 is not applicable here). 730 The TTL limitation cannot be applied since oFA and nFA may be more 731 than one hop away and since it is unnecessary for a secured unicast 732 message. The ICMP solicitations and advertisements MUST be 733 authenticated and integrity protected. These messages MUST be 734 protected using ESP [10] to prevent attacks (see Security 735 Considerations section). An FA MUST NOT accept ICMP solicitations or 736 advertisements from sources which are not authenticated. 738 As a practical matter, oFA SHOULD pre-solicit and cache 739 advertisements from known neighboring FAs (see section 3.5), in order 740 to prevent having to perform the above solicitation during an actual 741 handoff procedure. 743 3.4.2. Tunneled nFA Advertisements 745 This applies to the network-initiated target-triggered (L2-TT) case 746 only. Following a target trigger (L2-TT) the nFA MUST send a 747 tunneled agent advertisement to the MN through oFA. Tunneling nFA 748 advertisments assumes that the nFA is aware of the IP address for oFA 749 and the MN. These IP addresses are obtained by means of the IP 750 address identifiers in an L2 trigger at nFA in the network-initiated 751 case (see Section 3.2). However in [1] the TTL must be 1 on Agent 752 Advertisements from the nFA. Therefore tunneling advertisements is 753 applicable if the TTL limitation of [1] is relaxed. For this 754 purpose, a pre-established security association between oFA and nFA 755 MUST be in place to authenticate this message and relax the TTL 756 limitation. If the implementation requires this, a tunnel SHOULD be 757 configured when the inter-FA security association is established. 758 The tunneled ICMP advertisement MUST be secured using tunnel mode ESP 759 [10] between nFA and oFA. An FA MUST NOT accept tunneled packets 760 from sources which are not authenticated. 762 3.5. Caching Router Advertisements 764 In the mobile-initiated (L2-MT) case and the network-initiated 765 source-triggered (L2-ST) case, the message exchange 1 in Figure 1 766 could impose an additional latency on the L3 handoff process if done 767 as part of the handoff procedure. In order to remove this source of 768 latency, the inter-FA Router Solicitation and Advertisement exchange 769 SHOULD be performed in advance of handoff. A process SHOULD be in 770 place at the oFA to solicit its neighbouring nFAs at a predefined 771 time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT 772 be set too small to avoid unnecessary consumption of network 773 bandwidth and nFA processing resources. The minimum value of 774 MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response 775 mechanism in [7] is used then the MIN_SOLICITATION_INTERVAL MUST be 776 set to a value smaller then the window of time in which a challenge 777 remains valid so that the nFA challenge does not expire before the MN 778 issues the Registration Request. Therefore the recommended default 779 value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's 780 CHALLENGE_WINDOW * nFA's Agent advertisement interval). The 781 CHALLENGE_WINDOW and Agent advertisement interval are defined in [7] 782 and [1] respectively. The minimum requirement is that the 783 MIN_SOLICITATION_INTERVAL MUST be manually configurable, while 784 possible autoconfiguration mechanisms are outside the scope of this 785 document. To allow advertisement caching in certain implementations 786 and in cases where the nFA advertisement interval is very small, it 787 MAY be necessary for the implementation in nFA to allow different 788 CHALLENGE_WINDOW and agent advertisement interval settings for its 789 nFA-oFA interface. 791 The oFA SHOULD cache the most recent advertisement from its 792 neighbouring nFAs. This advertisement MUST be sent to the MN in 793 message 2b with a TTL. The oFA SHOULD also have a mechanism in 794 place to create a list of neighbouring nFAs. The minimum requirement 795 for each FA is that it SHOULD allow manual configuration of a list of 796 nFA addresses which an MN could possibly perform an L3 handoff to. 797 The FA addresses in this list will depend on deployment and radio 798 coverage. It is also possible to specify another protocol to achieve 799 nFA discovery, but it is outside the scope of this document. 801 3.6. Movement Detection and MN Considerations 803 When the MN receives an Agent Advertisement with a Mobility Agent 804 extension, it performs actions according to the following movement 805 detection mechanism: the MN SHOULD be "Eager" to perform new 806 bindings. This means that the MN SHOULD perform Registrations with 807 any new FA from which it receives an advertisement (i.e. MN is 808 Eager), as long as there are no locally-defined policies in the MN 809 that discourage the use of the discovered FA. For example, the MN 810 could have a policy based on the cost of service. The method by 811 which the MN determines whether the FA is a new FA is described in 812 [1] and MAY use an FA-NAI extension [11]. By being "Eager" to perform 813 Registrations the MN can get the most benefits in terms of reducing 814 latency times. 816 The MN also needs to change its default router from oFA to nFA. The 817 MN MUST change its default router to nFA as soon as the 818 PRE-REGISTRATION procedure has completed (Registration Reply is 819 received) as described in [1]. 821 Overall the MN behaves as described in [1] with the following 822 additions: the specified movement detection mechanism mentioned above 823 and the ability to use the L2-MT to initiate an agent solicitation 824 with a special extension (PrRtSol). 826 When moving from a PRE-REGISTRATION network to a normal Mobile IP [1] 827 network the MN will no longer receive PrRtAdv messages (agent 828 advertisements with the LLA extension). If the MN still receives 829 L2-MTs then it will attempt to send PrRtSol messages. The FA will 830 either ignore the solicitation or will reply with a normal agent 831 advertisement [1]. In the absence of a PrRtSol, when receiving a 832 normal agent advertisement the MN MUST resort to normal Mobile IP 833 behaviour [1]. If the MN does not receive a PrRtAdv in reply to its 834 PrRtSol, it SHOULD retransmit the PrRtSol message once after 835 PRE_SOL_INTERVAL seconds and then for another PRE_SOL_ATTEMPTS times 836 with exponential backoff of the transmission interval. If a PrRtAdv 837 is not received within PRE_SOL_INTERVAL seconds after the last 838 PrRtSol attempt, the MN MUST resort to normal Mobile IP behaviour 839 [1]. The default values for PRE_SOL_ATTEMPTS is 2 and the default 840 value for PRE_SOL_INTERVAL is 1 second. It should be noted that the 841 performance of the movement detection mechanism mandated in 842 PRE-REGISTRATION MAY have sub-optimal behaviour on the other Mobile 843 IP [1] network. Instead when the MN moves from a normal Mobile IP 844 [1] network to a PRE-REGISTRATION network, the MN will start 845 receiving L2-MTs or PrRtAdv messages. When the MN receives L2-MTs or 846 PrRtAdv messages it MUST follow the PRE-REGISTRATION procedure. If 847 there is uncertainty as to which mode to choose (e.g. MN receives 848 messages from both PRE-REGISTRATION and normal FAs) the MN SHOULD 849 choose PRE-REGISTRATION. 851 3.7. L2 Address Considerations 853 Some special considerations should be taken with respect to the 854 wireless system on which this handoff method is being implemented. 855 Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In 856 PRE-REGISTRATION the MN is registering with an FA (nFA) that is not 857 its current first-hop router, therefore the L2 address of the 858 Ethernet frame containing the MN's Registration Request reaching the 859 nFA is not the MN's address. Therefore the FA MUST NOT use the 860 Ethernet address of the incoming Registration Request as the MN's L2 861 address as specified in [1]. This applies to the cases where the 862 wireless access points are bridges or routers and independently of 863 whether the FA is implemented in the wireless access points 864 themselves. In this case the MN's Registration Request (or Regional 865 Registration Request) MUST use an L2 address extension to the 866 Registration message when the MN is performing a registration. Such 867 an L2 address is either the same L2 address that remains constant as 868 the MN moves, or it is the MN's L2 address at nFA. To communicate 869 its L2 address, the MN includes a Generalised Link Layer Extension 870 (see Section 9.3) with its Registration Request (or Regional 871 Registration Request) message. If this extension is present the FA 872 MUST use the L2 address contained in the extension to communicate 873 with the MN. For the same reasons, the MN MUST NOT use the source L2 874 address of the Agent Advertisement message (PrRtAdv) as its default 875 router's L2 address. Therefore the oFA/nFA MUST include a 876 Generalised Link Layer Extension (see Section 9.3) with its Agent 877 Advertisement (PrRtAdv) messages. 879 If a particular wireless L2 technology has defined a special L2 880 interface to the wireless network that allows the FA to resolve the 881 mapping between an MN's IP address and an L2 address without the need 882 to use the extension, the L2 address extension would not be needed. 884 3.8. Applicability of PRE-REGISTRATION Handoff 886 The PRE-REGISTRATON Handoff method is applicable to scenarios where a 887 period of service disruption due to layer 3 is not acceptable, for 888 example when performing real-time communications, and therefore where 889 an anticipation of the layer 3 handoff is required. Security for the 890 PRE-REGISTRATION handoff method is based on the same security model 891 as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION 892 is that the FA or MN are able to obtain an L2 trigger informing them 893 of a pending L2 handoff procedure. The target of the L2 handoff is 894 another access point or radio network that is in the coverage area of 895 a new FA. The L2 trigger information may be in the form of IP 896 address identifiers which may need to be resolved to IP addresses 897 using methods that may be specific to the wireless network and are 898 not considered here. If, for example, the oFA or MN determines that 899 the IP address of the new FA is oFA's address then the 900 PRE-REGISTRATION handoff SHOULD NOT be initiated. 902 The L2 trigger must allow enough time for the PRE-REGISTRATION 903 handoff procedure to be performed. In many wireless L2 technologies, 904 the L2 handoff procedure involves a number of message exchanges 905 before the effective L2 handoff is performed. For such technologies, 906 PRE-REGISTRATION handoff can be initiated at the beginning of the L2 907 handoff procedure and completed before the L2 handoff is completed. 908 It is efficient to engineer the network such that this succession of 909 events is ensured. 911 The PRE-REGISTRATION Handoff method is applicable in the following 912 cases: 914 - when the MN has locally defined policies that determine a 915 preference for one access over another, for example due to service 916 cost within the same or different technology, and therefore where 917 it is necessary to allow the MN to select the appropriate FA with 918 which to connect, 920 - when L2 security between the MN and the FA is either not present 921 or cannot be relied upon to provide adequate security, 923 - when the trigger to initiate the handoff is received at the MN. 925 In the first case it is necessary to involve eventual local MN 926 policies in the movement detection procedure as described in 3.6. 928 4. The POST-REGISTRATION Handoff Method 930 The POST-REGISTRATION handoff method uses bi-directional edge tunnels 931 (BETs) or unidirectional tunnels to perform low latency change in the 932 L2 point of attachment for the MN without requiring any involvement 933 by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff. 935 Following a successful Mobile IP Registration between MN and oFA, the 936 oFA becomes the mobility anchor point for the MN, called the anchor 937 FA (aFA). When the MN moves from oFA to nFA, rather than performing 938 signaling over the wireless link to register with the nFA, the MN can 939 defer the L3 handoff and continue to use its aFA (i.e. oFA in this 940 case). If the MN moves to a third FA before registering with the 941 nFA, in certain cases described later, the third FA signals aFA to 942 move the wireless link end of the BET from nFA to it. The network 943 end of the BET remains anchored at aFA until the MN performs the 944 Mobile IP Registration. 946 +------+ 947 | CN | 948 +------+ 949 | 950 ... 951 | 952 +------+ BET +------+ 953 | aFA |==========| nFA | 954 +------+ +------+ 955 | wireless link 956 | 957 movement +------+ 958 ---------> | MN | 959 +------+ 961 Figure 5 - POST-REGISTRATION Concept 963 Messages between oFA/aFA and nFA MUST be authenticated. The minimal 964 requirement is that all FAs involved in low latency handoffs MUST 965 support manual pre-configuration of security associations with other 966 neighbouring FAs, involving shared keys and the default algorithms of 967 [1]. POST-REGISTRATION FAs MUST implement the inter-FA 968 authentication extension (FA-FA authentication extension) specified 969 in [11] and MAY additionally use other security mechanisms. 971 4.1. Two Party Handoff 973 Two party handoff occurs when the MN moves from oFA, where the MN 974 performed a Mobile IP Registration, to nFA. In the normal case, this 975 movement would result in a new Mobile IP Registration at nFA. 976 However in POST-REGISTRATION, the MN and nFA MAY delay this but 977 maintain connectivity using the BET (or alternatively unidirectional 978 tunnel) between oFA and nFA. The protocol is shown in Figure 6. 980 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT 981 | oFA |<-------->| nFA | 982 4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU 983 ^ ^ 984 old L2 | | new L2 985 +-------+ +-----+ 986 | | 987 | | 988 V V 989 +------+ movement 990 4c) L2-LU ---> | MN | ---------> 991 +------+ 993 Figure 6 - Two Party Handoff (POST-REGISTRATION) 995 The following describes the progress of a two party handoff. The 996 numbered items refer to steps in Figure 6. To identify the 997 difference between a source triggered HRqst/HRply message for tunnel 998 creation, a target triggered HRqst/HRply message for tunnel creation 999 and HRqst/HRply to extend or terminate a BET (or unidirectional 1000 tunnel), the message will be identified respectively by (s), (t) and 1001 (r). 1003 1) Either the oFA or nFA receives an L2 trigger informing it that a 1004 certain MN is about to move from oFA to nFA. The two cases are: 1006 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 1007 trigger contains the MN's L2 address and an IP address 1008 identifier (the IP address itself or an L2 address that 1009 can be resolved to the IP address) for nFA. 1011 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 1012 trigger contains the MN's L2 address and an IP address 1013 identifier for oFA. 1015 2) The FA receiving the trigger sends a Handoff Request (HRqst) to 1016 the other FA. There are two cases: 1018 a) If oFA is sending the HRqst, the H bit is set and the N 1019 bit is unset, indicating it is an HRqst(s). The HRqst(s) 1020 contains the lifetime of the tunnel the oFA is willing to 1021 support, the home network IP address of the MN, the MN's 1022 HA address and an LLA option with the MN's L2 address. If 1023 the lifetime is zero and the T bit is not set, the oFA is 1024 not willing to tunnel any packets for MN. A positive 1025 lifetime and a set T bit indicate that the oFA is willing 1026 to tunnel for the indicated time. Section 4.6 describes 1027 the HRqst(s) and Section 9 describes the LLA option. 1029 b) If nFA is sending the HRqst, the N bit is set and the H 1030 bit is unset, indicating it is an HRqst(t). If the T bit 1031 is set, nFA has requested a reverse tunnel and the 1032 HRqst(t) contains the lifetime of the tunnel the nFA is 1033 requesting. The HRqst(t) also contains an LLA option with 1034 the MN's L2 address. The MN's home network IP address and 1035 HA address are not sent, unless they are discovered by 1036 some means outside the scope of this document (for 1037 example, as part of the L2-TT). Section 4.6 describes the 1038 HRqst(t). 1040 3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the 1041 other FA. There are two cases: 1043 a) If oFA is sending the HRply, the N bit is set and the H 1044 and R bits are unset, indicating that the reply is in 1045 response to a HRqst(t), i.e. it is an HRply(t). If the T 1046 bit is set, the HRply(t) contains the tunnel lifetime the 1047 oFA is willing to provide, otherwise, the tunnel lifetime 1048 is set to zero, indicating that the oFA is not willing to 1049 provide tunnel service. If both HRply(t) and HRqst(t) 1050 have the T bit set and non-zero lifetime a BET is 1051 established. The HRply(t) also contains the MN's home 1052 subnet IP address, the MN's HA address, and an LLA option 1053 containing the MN's L2 address. Section 4.7 describes the 1054 HRply(t). 1056 b) If nFA is sending the HRply, the H bit is set and the N 1057 and R bits are unset, indicating the reply is in response 1058 to a HRqst(s), i.e. it is an HRply(s). If the T bit is 1059 set, the nFA indicates that it requests a reverse tunnel, 1060 and the lifetime field is set with the requested tunnel 1061 lifetime. The T Bit can be set in HRply only if the oFA 1062 had set the T bit in the corresponding HRqst or if the nFA 1063 requires to reverse tunnel incoming packets to oFA because 1064 ingress filtering is enabled on its network. This 1065 establishes a BET. The tunnel lifetime requested by the 1066 nFA must be less than or equal to the tunnel lifetime 1067 offered by oFA in the HRqst(s). Section 4.7 describes the 1068 HRply(s). 1070 4) The point during the L2 handoff in which the MN is no longer 1071 connected on a certain link is signaled by an L2-LD trigger at 1072 oFA and MN. Completion of L2 handoff is signaled by an L2-LU 1073 trigger at nFA and MN. Each node handles the trigger in the 1074 following way: 1076 a) When the oFA receives the L2-LD trigger, it begins 1077 forwarding MN-bound packets through the forward tunnel to 1078 nFA. 1080 b) When the nFA receives the L2-LU trigger, it begins 1081 delivering packets tunneled from the oFA to the MN and 1082 forwards any outbound packets from MN to the next hop 1083 using normal routing mechanisms or through the reverse 1084 tunnel to oFA or HA. 1086 c) When the MN receives the L2-LU, it MAY intiate the Mobile 1087 IP Registration process by soliciting an Agent 1088 Advertisement as described in [1]. If the Registration is 1089 successful the nFA takes over the role of anchor FA (aFA) 1090 from the oFA. Alternatively the MN MAY defer the Mobile 1091 IP Registration (see section 4.4). 1093 5) The oFA becomes an aFA if the MN moves to a third FA before 1094 having performed a Mobile IP Registration with nFA. 1096 6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a 1097 ping-pong situation arise, the oFA may be able to determine this 1098 case through the trigger mechanism (i.e. FA sees successive 1099 L2-ST/L2-TT followed by L2-LD and then L2-LU). The FA which 1100 originated the HRqst can in this case cancel the tunnel by 1101 sending an HRqst(r) to the other FA with lifetime zero. It will 1102 then simply continue delivering packets to MN exactly as if no 1103 handoff had been pending. Section 4.6 describes the HRqst(r). 1105 If the oFA sets the B bit in HRqst/HRply and the nFA has not 1106 requested a reverse tunnel by setting the T bit, the nFA SHOULD 1107 tunnel outgoing packets from the MN to the HA because the MN has 1108 requested this service from the oFA. The nFA SHOULD offer this 1109 service only if no security between the nFA and the MN's HA is 1110 required, or if there is an existing nFA-HA security association in 1111 place. 1113 The actual timing of BET or unidirectional tunnel placement depends 1114 on the available L2 triggers. The forward tunnel from oFA to nFA is 1115 constructed using one of the tunneling procedures described in [1] 1116 for the HA to FA tunnel with the difference that the ends of the 1117 tunnel are at the oFA and nFA, respectively. The reverse tunnel from 1118 nFA to oFA is constructed as described in [3] with the difference 1119 that the network end of the tunnel is at the oFA instead of the HA. 1120 If both forward and reverse tunnels are established then a BET has 1121 been established. With optimal L2 trigger information, as described 1122 above, the FAs can setup the BET immediately when the L2 handoff is 1123 initiated, start tunneling MN-bound data when the link to the MN goes 1124 down and the nFA can use the link up trigger to start delivering 1125 packets. In the absence of optimal L2 trigger information, the HRply 1126 can act as the trigger to start tunneling MN-bound data, but in this 1127 case, the period of packet delivery disruption to the MN could still 1128 be present and additional measures may be required to provide 1129 uninterrupted service. Additonally, particular implementation and 1130 deployment scenarios could require that techniques be employed to 1131 smooth handoff by providing a means to convey packets arriving during 1132 the L2 handoff. The exact techniques involved in smoothing are 1133 currently under discussion by the working group and are outside the 1134 scope of this document. 1136 Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and 1137 target trigger (L2-TT) two party handoff, respectively. 1139 MN nFA oFA 1140 | | | 1141 | | HRqst(s) |<~~~ L2-ST 1142 | |<------------------| 1143 | | HRply(s) | 1144 | |------------------>| 1145 | | | 1146 --------------------------------------------<~~~ L2-LD 1147 L2 Handoff 1148 --------------------------------------------<~~~ L2-LU 1149 | | | 1150 |<------------------->| | 1151 | MN's traffic | | 1153 Figure 7 - Two Party Source Trigger Handoff Timing 1155 MN nFA oFA 1156 | | | 1157 | L2-TT ~~~>| HRqst(t) | 1158 | |------------------>| 1159 | | HRply(t) | 1160 | |<------------------| 1161 | | | 1162 --------------------------------------------<~~~ L2-LD 1163 L2 Handoff 1164 --------------------------------------------<~~~ L2-LU 1165 | | | 1166 |<------------------->| | 1167 | MN's traffic | | 1169 Figure 8 - Two Party Target Trigger Handoff Timing 1171 Once the tunnel between aFA and the current FA is in place, it is 1172 torn down by one of the following events: 1174 1) The aFA decides to stop tunneling because the lifetime it sent 1175 expires and was not renewed, or the aFA or current FA decide to 1176 terminate tunnel service prematurely for some other reason 1177 (refer to section 4.3). 1179 2) The MN completes the process by performing a Mobile IP 1180 Registration with the current FA. This may be initiated by the 1181 FA which sends an Agent Advertisement or by the MN which 1182 solicits for an Agent Advertisement as in [1]. 1184 3) The MN moves to a third FA (see section 4.2) 1186 4.2. Three Party Handoff 1188 Three party handoff is applicable when an MN that has already 1189 established an aFA and is receiving tunneled packets through its 1190 current FA moves to a new FA without performing a Mobile IP 1191 Registration. 1193 +------+ 1194 +--->| aFA |<---+ 1195 | +------+ | 1196 4b) HRqst(r) | | 3) HRqst(t) 1197 HRply(r) | | HRply(t) 1198 | | 1199 v 2a) HRqst v 1200 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT 1201 | oFA |<-------->| nFA | 1202 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU 1203 ^ HRply ^ 1204 old L2 | | new L2 1205 +-------+ +-----+ 1206 | | 1207 | | 1208 V V 1209 +------+ movement 1210 5b) L2-LU ~~~> | MN | ---------> 1211 +------+ 1213 Figure 9 - Three Party Handoff 1215 The need for the Three Party Handoff function depends on the wireless 1216 system in which POST-REGISTRATION is being implemented. For radio L2 1217 protocols in which it is possible for the MN to move so rapidly from 1218 one FA to another such that a probability exists that the Mobile IP 1219 Registration with nFA will not complete before the MN moves on, HTT 1220 (Handoff To Third) SHOULD be implemented. Certain wireless systems 1221 and implementations do not allow such fast movement between FAs and 1222 may force the Mobile IP Registration to occur soon after L2 handoff, 1223 in which case three party handoff is not applicable. If this three 1224 party handoff feature is not implemented, the FA SHOULD send an Agent 1225 Advertisement to the MN after L2 handoff has completed (L2-LU at nFA) 1226 and/or the MN SHOULD solicit a Router Advertisement after L2 handoff 1227 (L2-LU at MN). 1229 The L3 handoff can be deferred either because of a decision by the 1230 MN/FA (i.e. MN does not send Router Solicitations and FA does not 1231 send Agent Advertisements) or it may result from rapid movement 1232 between oFA and nFA that does not allow enough time for the 1233 registration to complete. This scenario is shown in Figure 9. In 1234 this case, oFA must inform nFA (i.e. the third FA) to contact aFA 1235 about moving the radio end of the tunnel. This is performed with the 1236 HTT message. 1238 The general idea behind the three party handoff procedure is that the 1239 oFA supplies nFA with the same information it would have obtained via 1240 an L2-TT if handoff had occurred from aFA to nFA, then the nFA 1241 performs an HRqst(t)/HRply(t) sequence with aFA in order to move the 1242 BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) 1243 to aFA to terminate the previous BET. 1245 The following describes the progress of a three party handoff. The 1246 numbered items refer to steps in Figure 9. 1248 1) Either the oFA or nFA receives an L2 trigger informing it that a 1249 certain MN is about to be moved. The two cases are: 1251 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 1252 trigger contains the MN's L2 address and an IP address 1253 identifier (IP address or L2 address that can be mapped to 1254 an IP address) for nFA. 1256 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 1257 trigger contains the MN's L2 address and an IP address 1258 identifier for oFA. 1260 2) The oFA and nFA exchange a HTT/HRply or HRqst/HTT pair. HTT is 1261 indicated by setting both the H and N bits in the HRqst or 1262 HRply. The HTT message MUST NOT have any tunnel flags set, 1263 because the tunnel is negotiated between the aFA and nFA, not 1264 oFA and nFA. There are two cases: 1266 a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA 1267 containing the MN's home IP address, the MN's HA address, 1268 an LLA containing the aFA's IP address, and an LLA 1269 containing the L2 address of the MN. This is enough 1270 information for nFA to perform a target triggered handoff 1271 with aFA. The nFA responds with a HRply(s). Section 4.8 1272 describes the HTT. 1274 b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA 1275 ,exactly as if a two party handoff were occurring. The 1276 oFA responds with HTT containing the same information as 1277 in a) above. This is enough information for nFA to 1278 perform a target triggered handoff with aFA. 1280 3) Upon receipt of the HTT, the nFA first checks its Visitor Cache 1281 to see whether it is already tunneling for MN. If so, Step 6 is 1282 performed. If not, nFA performs a target triggered handoff with 1283 aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t) 1284 pair. Because aFA receives no L2 trigger indicating when L2 1285 handoff starts, it may start tunneling to nFA upon transmission 1286 of the HRply(t). 1288 4) Once the L2 handoff is underway and the MN gets disconnected at 1289 L2, aFA and oFA exchange messages canceling tunnel service 1290 between aFA and oFA and allowing aFA to start the tunnel with 1291 nFA. 1293 a) The point in the L2 handoff process where the MN gets 1294 disconnected from oFA is signaled at oFA by L2-LD. 1296 b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime 1297 zero with aFA. This cancels tunnel service between oFA 1298 and aFA. If aFA has not already established a tunnel to 1299 nFA, it must do so immediately upon receipt of the 1300 HRqst(r). The aFA provides tunneling service exactly as 1301 described in Section 4.1 Step 4a. 1303 5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA 1304 and/or MN. The nFA and MN handle the trigger as follows: 1306 a) The nFA provides packet delivery service to the MN exactly 1307 as described in Section 4.1, Step 4b. 1309 b) The MN either defers or initiates Mobile IP Registration 1310 when it receives the L2-LU, as in Section 4.1 1312 6) In the special case where nFA and aFA are the same (i.e. the MN 1313 is moving back to the original anchor FA), aFA recognizes that 1314 it is tunneling to oFA when it checks its Visitor Cache in Step 1315 3. In this case, there is no need for aFA to send the 1316 HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger 1317 on handoff completion, the aFA begins routing packets to MN and 1318 the tunnel to nFA is torn down. The oFA still exchanges the 1319 HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a 1320 priori that aFA and nFA are the same, but they are redundant. 1322 Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and 1323 target trigger (L2-TT) three party handoff, respectively. 1325 MN nFA oFA aFA 1326 | | | | 1327 | | L2-ST ~~~~~> | | 1328 | | | | 1329 | |<-------------| | 1330 | | HTT | | 1331 | | | | 1332 | |------------->| | 1333 | | HRply(s) | | 1334 | | | | 1335 | |------------------------------>| 1336 | | HRqst(t) | | 1337 | | | | 1338 | |<------------------------------| 1339 | | HRply(t) | | 1340 | | | | 1341 ----------------------------------<~~~ L2-LD | 1342 |--------------->| 1343 L2 Handoff | HRqst(r) | 1344 | | 1345 |<---------------| 1346 | HRply(r) | 1347 | | 1348 ----------------------------------<~~~ L2-LU | 1349 | | | | 1350 |<-------------->| | | 1351 | MN's traffic | | | 1352 | | | | 1354 Figure 10 - Three Party Source Trigger Handoff Timing 1356 MN nFA oFA aFA 1357 | | | | 1358 | |<~~~ L2-TT | | 1359 | | | | 1360 | |------------->| | 1361 | | HRqst(t) | | 1362 | | | | 1363 | |<-------------| | 1364 | | HTT | | 1365 | | | | 1366 | |------------------------------>| 1367 | | HRqst(t) | | 1368 | | | | 1369 | |<------------------------------| 1370 | | HRply(t) | | 1371 | | | | 1372 ----------------------------------<~~~ L2-LD | 1373 |--------------->| 1374 L2 Handoff | HRqst(r) | 1375 | | 1376 |<---------------| 1377 | HRply(r) | 1378 | | 1379 ----------------------------------<~~~ L2-LU | 1380 | | | | 1381 | | | | 1382 |<-------------->| | | 1383 | MN's traffic | | | 1384 | | | | 1386 Figure 11 - Three Party Target Trigger Handoff Timing 1388 Unlike two party handoff, the timing of BET establishment between aFA 1389 and nFA cannot fully depend on the availability of L2 trigger 1390 information because aFA does not receive an L2 trigger signalling L2 1391 handoff. The two timing extremes at which aFA can place the BET with 1392 nFA are: 1394 1) At the earliest, aFA MAY start tunneling packets using the BET 1395 to nFA after sending the HRply(t) to nFA in response to the 1396 request for target-triggered handoff 1398 2) At the latest, aFA MAY start tunneling packets using the BET to 1399 nFA and tear down the BET with oFA when receiving the HRqst(r) 1400 from oFA indicating the MN has disconnected. 1402 In addition, aFA MAY continue tunneling to oFA if 1) is selected, 1403 until the HRqst(r) is received. In this case, the result may be 1404 duplicated packets at the MN because the MN will receive packets 1405 through oFA on the old L2 until it disconnects (L2-LD). If 2) is 1406 selected, the additional latency will add to the MN's L3 service 1407 disruption period. Of course, aFA can choose to place the BET some 1408 time between 1) and 2) if reliable bounds are available on the 1409 duration of time between L2-ST/L2-TT and the MN's disconnection 1410 (L2-LD). The exact selection of when to establish the BET is likely 1411 to be influenced by network engineering and implementation 1412 considerations, including whether a handoff smoothing solution is 1413 used, and is beyond the scope of this specification. 1415 4.3. Renewal or Termination of Tunneling Service 1417 To prevent a BET from expiring when its lifetime runs out, the MN's 1418 current FA signals the aFA to either renew or terminate the BET. 1419 This may be the case when the MN defers Mobile IP Registration. If 1420 no such signal is received, the aFA will terminate the BET when the 1421 lifetime expires. In addition, the current FA or aFA may need to 1422 terminate the BET prior to the lifetime expiring. In order to avoid 1423 error conditions in which tunnels do not expire even though the MN to 1424 which they apply is no longer reachable, FAs SHOULD set the tunnel 1425 lifetime field to some value other that 0xffff, which indicates "good 1426 until cancelled". 1428 Figure 12 illustrates the message exchange that occurs between the FA 1429 needing to terminate or extend the tunnel (designated FA(1) in the 1430 figure) and the other FA (designated FA(2) in the figure). The 1431 HRqst(r)/HRply(r) is indicated by setting the R bit in the 1432 HRqst/HRply messages. If the HRqst(r) is renewing a BET then it 1433 contains a non-zero lifetime, otherwise if the lifetime is set to 1434 zero it indicates tunnel termination. The aFA has complete control 1435 over whether a tunnel is extended or terminated, and it MAY reply to 1436 a request for extension with a shorter lifetime than was requested. 1438 HRqst(r) 1439 +------+ <-------- +------+ 1440 | FA(2)| ---------> | FA(1)| 1441 +------+ HRply(r) +------+ 1443 Figure 12 - BET Renewal or Termination 1445 4.4. When will the MN perform a Mobile IP Registration? 1447 The MN/FA have control over when to perform the Mobile IP 1448 Registration. Although the MN/FA may decide to defer Mobile IP 1449 Registration for a certain period, three possible events can lead to 1450 the need to terminate tunneling service. If this occurs the MN MUST 1451 perform the Mobile IP Registration. These events are: 1453 1) The end of life for the BET is pending and a request by the 1454 current FA to aFA for renewal has been denied, or alternatively 1455 the current FA or aFA needs to terminate the BET prematurely. 1456 The FA in this case MUST initiate the Mobile IP Registration by 1457 sending an Agent Advertisement to the MN as in [1]. 1459 2) The MN itself decides to perform a Mobile IP Registration and 1460 initiates it by sending an Agent solicitation as in [1]. 1462 3) During a source triggered handoff, the oFA attempts to perform 1463 BET handoff but nFA is not capable of performing it. The FA in 1464 this case MUST initiate the Mobile IP Registration by sending 1465 the MN an Agent Advertisement as in [1]. Note that this 1466 situation will never arise during target triggered handoff 1467 because an HRqst(t) will not be sent to oFA by an nFA that 1468 doesn't support POST-REGISTRATION. 1470 Some detailed scenarios relating to case 2) will be described 1471 hereafter. According to [1], when using an FA care-of address the MN 1472 MAY use the FA as its default router. Otherwise it MUST choose its 1473 default router from those advertised in the ICMP Router Advertisement 1474 portion of the Agent Advertisement. Here we assume that the FA 1475 router is also the MN's default router. In POST-REGISTRATION, when 1476 both a forward and reverse tunnel are established between oFA and nFA 1477 (i.e. a BET) and the MN has moved to nFA, the oFA MUST continue 1478 sending Router Advertisements to the MN. This is to refresh the MN's 1479 default router entry. The Router Advertisements are tunnelled from 1480 oFA to nFA through the forward tunnel and MUST be unicast to the MN. 1481 Similarly to PRE-REGISTRATION, tunneling of Advertisements is 1482 possible only if the TTL limitation of [1] is relaxed. If this is 1483 not possible then the nFA MUST advertise to the MN as soon as it's 1484 link to the nFA is up (L2-UP). The MN MUST perform a Mobile IP 1485 registration [1] when it receives an Agent Advertisement following a 1486 POST-REGISTRATION handoff. 1488 Instead, when the forward tunnel is established but not the reverse 1489 tunnel, oFA MUST NOT advertise to the MN. In this case, as described 1490 previously, it is possible that the MN will not receive Router 1491 Advertisements for extended periods of time. According to [8] hosts 1492 will remove default router entries if the lifetime of the Router 1493 Advertisement expires and no further advertisements are received. 1494 Note that the ICMP Router Advertisement lifetime is not related to 1495 the Registration Lifetime in the Mobility Agent Advertisement 1496 extension [1]. To avoid this disruption the MN MUST solicit the 1497 default router (i.e. FA) before the lifetime of its active default 1498 router entry runs out, or alternatively the FA MUST advertise as soon 1499 as the MN-nFA link is up (L2-UP). This effectively means that the MN 1500 will at most be able to defer Mobile IP Registration for as long as 1501 the remaining lifetime of the active default router, as configured in 1502 the ICMP Router Advertisements. The MN MUST perform a Mobile IP 1503 registration [1] when it receives an Agent Advertisement following a 1504 POST-REGISTRATION handoff. 1506 4.5. Handoff Request (HRqst) Message format 1508 This is a new Mobile IP message carried on UDP (destination port 434) 1509 [1]. The UDP header is followed by the fields below. 1511 0 1 2 3 1512 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 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Type |H|N|R|M|G|T|B| Reserved | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Lifetime | Reserved | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | MN Home Address | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | HA Address | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | 1523 + Identification + 1524 | | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Extensions ... 1527 +-+-+-+-+-+-+-+- 1529 Type TBD (Handoff Request) 1531 H Source triggered handoff request. When set and 1532 the N bit is unset, indicates that the request 1533 was the result of an L2-ST at oFA. 1535 N Target triggered handoff request. When set and 1536 the H bit is unset, indicates that the request 1537 was the result of an L2-TT at nFA. 1539 R Set if the request is an HRqst(r), i.e. a request 1540 to renew the tunnel. Neither the H nor the N bit 1541 are set. 1543 M The FA issuing the HRqst will use Minimal 1544 Encapsulation as defined in [1,5] for the tunnel. 1546 G The FA issuing the HRqst will use GRE [4] 1547 Encapsulation as defined in [1,5] for the tunnel. 1548 When this flag is set the HRqst may require 1549 extensions containing the GRE type and key 1550 fields, but they are outside the scope of this 1551 document. 1553 T For an HRqst(s), indicates that the oFA is 1554 willing to support both forward and reverse 1555 tunnel service. For an HRqst(t), indicates that 1556 the nFA is requesting reverse tunnel service. 1558 B When sent in an HRqst(s), indicates that the MN 1559 has requested a reverse tunnel to the HA and that 1560 the nFA SHOULD use reverse tunnel to the HA if it 1561 will not be reverse tunneling to the oFA. 1563 Lifetime The lifetime, in seconds, for which tunnel 1564 service for the MN will be maintained. If this 1565 is an HRqst(t), then the lifetime represents a 1566 request by nFA for a reverse tunnel. If this is 1567 an HRqst(s), then the lifetime represents the 1568 maximum amount of time that oFA is willing to 1569 maintain the both the forward and reverse tunnel. 1570 If this is an HRqst(r), then the lifetime 1571 Represents a request for the amount of time to 1572 renew the tunnel's lifetime. A value of 0 on an 1573 HRqst(s) indicates that the oFA is unwilling to 1574 grant any tunnel service. A value of 0 on an 1575 HRqst(t) indicates that the nFA does not require 1576 reverse tunnel service. A value of 0 on an 1577 HRqst(r) indicates that the tunnel should be 1578 terminated immediately. A value of 0xffff 1579 indicates infinity. 1581 MN Home Address For HRqst(s), the home address of the MN. 1583 HA Addr For HRqst(s), the HA address of the mobile node. 1585 Identification As in defined in [1]. 1587 Extensions The Message MUST include an LLA (see Section 9) 1588 containing the MN's L2 address and an L2 address 1589 that can be mapped to an IP address for the FA. 1590 This Message MUST contain the FA-FA 1591 Authentication Extension [11] that is used to 1592 secure the HRqst message. 1594 4.6. Handoff Reply (HRply) Message 1596 This is a new Mobile IP message carried on UDP (destination port 434) 1597 [1]. The UDP header is followed by the fields below. 1599 0 1 2 3 1600 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 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Type |H|N|R|M|G|T|B| Reserved | Code | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Lifetime | Reserved | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | MN Home Address | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | HA Address | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | | 1611 + Identification + 1612 | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Extensions ... 1615 +-+-+-+-+-+-+-+- 1617 Type TBD (Handoff Reply) 1619 Code A value indicating the result of the Handoff 1620 Request. Only two codes are currently supported, 1621 0, indicating success, and 1, indicating that the 1622 handoff cannot be performed. The remaining values 1623 are for future use. 1625 Lifetime The lifetime, in seconds, for which the 1626 bi-directional tunnel for the MN will be 1627 maintained. If this is an HRply(s), then the 1628 lifetime represents a request by nFA, and it can 1629 be any value up to the maximum value sent in the 1630 HRqst(s). Larger values are assumed to default 1631 to OFA's maximum. If this is an HRply(t), then 1632 the lifetime represents the maximum amount of 1633 time that the oFA will grant to the nFA. If this 1634 is a HRply(r), then the lifetime represents the 1635 amount of time by which the tunnel life will be 1636 extended. If the Code field indicates that 1637 handoff failed, the Lifetime field will be 1638 ignored and SHOULD be set to zero. A value of 1639 0 on an HRply(t) indicates that the oFA is 1640 unwilling to grant service. A value of 0 on an 1641 HRply(s) indicates that the nFA does not require 1642 service. A value of 0 on HRply(r) indicates that 1643 the tunnel lifetime will be terminated. A value 1644 of 0xffff indicates infinite lifetime. 1646 H Source triggered handoff reply. When set and 1647 the N bit is unset, indicates that the 1648 reply is in response to an HRqst(s). 1650 N Target triggered handoff reply. When set and 1651 the H bit is unset, indicates that the 1652 reply is in response to an HRqst(t). 1654 R Set if the reply is an HRply(r). Neither 1655 the H nor the N bit are set. 1657 M The FA issuing the HRqst will use Minimal 1658 Encapsulation as defined in [1,5] for 1659 the tunnel. 1661 G The FA issuing the HRqst will use GRE [4] 1662 Encapsulation as defined in [1,5] for the tunnel. 1663 When this flag is set the HRply may require 1664 extensions containing the GRE type and key 1665 fields, but they are outside the scope of this 1666 document. 1668 T For an HRply(s), indicates that the nFA is 1669 Requesting to reverse tunnel service. For an 1670 HRply(t), indicates that the oFA is willing to 1671 provide both forward and reverse tunnel service. 1673 B When sent in an HRply(t), indicates that the MN 1674 has requested a reverse tunnel to the HA and that 1675 the nFA SHOULD use reverse tunnel to the HA if 1676 it will not be reverse tunneling to the oFA. It 1677 can be set in HRply(t) only if the T bit was 1678 unset in the corresponding HRqst(t). 1680 MN Home Address For HRply(t), the home address of the MN. 1682 HA Addr For HRply(t), the HA address of the mobile node. 1684 Identification As in defined in [1]. 1686 Extensions This Message MUST contain the FA-FA 1687 Authentication Extension [11] that is used to 1688 secure the HRply message. 1690 4.7. Handoff To Third (HTT) Message 1692 The Handoff to Third message has the same format as the Handoff 1693 Request and Handoff Reply Messages, except both the H and N bits are 1694 set. If the HTT message is in response to a L2-ST and is sent to 1695 initiate a handoff, then, with the exception of the H and N bits, the 1696 message has the same fields set and includes the same extensions as 1697 an HRqst(s). If the HTT message is sent in response to an HRqst(t), 1698 then, with the exception of the H and N bits, the message has the 1699 same fields set and includes the same extensions as an HRply(t). The 1700 tunnel bits MUST NOT be set in the HTT message because BET 1701 construction is not negotiated between oFA and nFA, it is negotiated 1702 between nFA and aFA in the ensuing HRqst(t)/HRply(t). 1704 In addition, the HTT MUST contain the following extensions in the 1705 specified order: 1707 Solicited IP Address Option: containing aFA's Address 1709 LLA Option: containing the L2 address of the MN. 1711 4.8. Applicability of POST-REGISTRATION Handoff Method 1713 The POST-REGISTRATION handoff approach allows FAs to communicate 1714 directly about a pending handoff, and does not require any IP layer 1715 messages to be sent to or from a MN prior to the L2 handoff event. 1716 Therefore, it eliminates a possible source of handoff latency. This 1717 may be required when the link layer imposes hard deadlines on the 1718 time at which a handoff must occur, such as when a MN is rapidly 1719 moving out of a radio coverage area. Consequently, POST-REGISTRATION 1720 is primarily of interest in handoff between FAs that support the same 1721 radio access technology. Handoff between heterogeneous radio 1722 technologies will, of necessity, require interaction between the MN 1723 and the network, and so is not a domain of applicability for 1724 POST-REGISTRATION. 1726 Because a POST-REGISTRATION handoff is triggered by an unspecified 1727 mechanism that informs the oFA or nFA that an L2 handoff is pending, 1728 the POST-REGISTRATION approach is only applicable to networks where 1729 such a mechanism is available. For example, an L2 may provide 1730 indications of radio signal quality that cause the oFA or nFA to send 1731 the POST-REGISTRATION handoff messages. Any such indications must 1732 also provide each FA involved in the handoff with the identity of the 1733 other, so that messages can be sent to the right place. This may 1734 involve mapping L2 information onto FA IP addresses. Also, the FAs 1735 involved in a handoff must have pre-provisioned security arrangements 1736 so that the POST-REGISTRATION messages can be authenticated. If a 1737 handoff is to be completed as a result of the POST-REGISTRATION 1738 messaging, any L2 handoff indications must also be securely 1739 authenticated so that traffic to the old point of attachment is not 1740 improperly halted. 1742 POST-REGISTRATION handoff is appropriate in the following cases: 1744 - L2 triggers are available on the network to indicate that L2 1745 handoff is pending. 1747 - Pre-provisioned security mechanisms are in place to allow fast 1748 and secure messaging between the FAs and between the MN and an FA. 1750 - Access point choice by the MN is not a concern or choice requires 1751 user intervention and therefore is not on the critical path for 1752 handoff. 1754 5. Combined Handoff Method 1756 The combined method uses both PRE-REGISTRATION and POST-REGISTRATION 1757 handoff by running the PRE-REGISTRATION method and in parallel 1758 exchanging the POST-REGISTRATION handoff messages between oFA and 1759 nFA. The only case not considered already in the POST-REGISTRATION 1760 method is mobile-initiated handoff. In the mobile-initiated case, 1761 the Handoff Request message is initated by the oFA or nFA when it 1762 receives the Registration Request from the MN. 1764 The combined method follows the PRE-REGISTRATION Handoff when it is 1765 successful before the completion of the MN's L2 handoff. However, if 1766 PRE-REGISTRATION does not complete prior to the expiration of a timer 1767 on one or the other of the FAs, POST-REGISTRATION handoff is used. 1768 Using POST-REGISTRATION handoff insulates the MN from delays caused 1769 by errors such as loss of one of the Mobile IP messages involved in 1770 PRE-REGISTRATION. 1772 The start of POST-REGISTRATION is gated by the expiration of a timer 1773 on the FAs. The timer is started at oFA following a source-trigger, 1774 at nFA following the target-trigger, or at oFA and nFA following the 1775 receipt of the Registration Request from the MN in the 1776 mobile-initiated case. The timer is reset if the Registration Reply 1777 message is received by the appropriate FA and sent to the MN. 1779 Although the POST-REGISTRATION Handoff Request and Handoff Reply 1780 messages are exchanged in advance, no forwarding of traffic between 1781 oFA and nFA is performed unless the timer expires. The timer should 1782 be set to a value that allows forwarding between oFA and nFA to begin 1783 before the MN completes the L2 handoff to nFA. 1785 6. Layer 2 and Layer 3 Handoff timing Considerations 1787 In the optimal cases considered in the PRE-REGISTRATION and 1788 POST-REGISTRATION handoffs it was assumed that a timely L2 trigger 1789 would be received in such a way that packets could be delivered to 1790 the MN via its nFA immediately upon connection. In this way the MN 1791 would not suffer disruption due to the L3 handoff. However such 1792 precise timing of the L2 trigger and handoff mechanism with respect 1793 to the actual L2 handoff event will not be possible in all wireless 1794 systems and may depend on particular implementation techniques. 1795 Therefore some uncertainty may exist at L3 as to exactly when the L2 1796 connection between the MN and the nFA becomes fully established and 1797 can be used for L3 traffic. It is possible that in certain 1798 implementations traffic will be re-routed too early or too late with 1799 respect to the moment when the connection between the MN and the nFA 1800 becomes fully established. The techniques which will solve this 1801 problem and allow the MN to receive traffic independently of the 1802 timing of the L2 handoff event are currently under study, including 1803 bicasting and buffering, but are outside the scope of this document. 1805 7. Reverse Tunneling Support 1807 The handoff methods all support reverse tunneling. The MN may 1808 request reverse tunneling [3] by setting the 'T' bit in its 1809 Registration Request. In the case of POST-REGISTRATION, if the MN 1810 had requested Reverse Tunneling previously at oFA, the Handoff 1811 message from oFA (see Section 4) includes the 'T' bit enabled to 1812 inform nFA to establish a BET for the visitor entry. Typically, the 1813 'T' bit will always be set to ensure that any delays in the MN 1814 receiving its new care of address do not result in any delay in 1815 uplink packet transmission from the MN, but local policies and 1816 particular L2 technologies may allow the reverse tunnel to be turned 1817 off unless the MN specifically requests it. 1819 8. Handoff Signaling Failure Recovery 1821 In general and to a greater extent in wireless networks, packets 1822 carrying handoff signaling may be dropped or lost due to errors on 1823 the link. In this section, we consider mechanisms for recovery from 1824 handoff signaling failures. 1826 8.1. PRE-REGISTRATION Signaling Failure Recovery 1828 Failure of PRE-REGISTRATION signaling breaks down into three cases: 1830 1) Loss of messages ProxyRtSol and ProxyRtAdv on the air link. 1832 2) Loss of the solicitation by an FA to obtain another neighbouring 1833 FA's Advertisment or loss of the neighbouring FA's 1834 advertisement. 1836 3) Failure of the standard Mobile IP Registration. 1838 Of these, case 3) is handled by standard Mobile IP mechanisms 1839 described in [1]. Case 2) is relatively unlikely because spontaneous 1840 packet drop rates on the fixed network are caused by congestion or 1841 router failure and likely to be low. Since bit error rates on 1842 wireless links are higher than on fixed links, case 1) is more likely 1843 to occur. In the following subsections, the cases 1) and 2) are 1844 considered. 1846 8.1.1. Failure of ProxyRtSol and ProxyRtAdv 1848 PRE-REGISTRATION handoff can fail in network-initiated handoff when 1849 the ProxyRtAdv sent by oFA in response to the source trigger (L2-ST) 1850 or the advertisement sent by nFA in response to the target trigger 1851 (L2-TT) fails to reach the MN. PRE-REGISTRATION handoff can also 1852 fail in mobile-initiated handoff when either the ProxyRtSol sent from 1853 the MN or return ProxyRtAdv sent from the oFA are dropped. To reduce 1854 the probability that ProxyRtAdv and ProxyRtSol are lost the MN and FA 1855 MAY transmit multiple copies of these messages. Should these 1856 messages fail anyway, in both cases the MN connects to the nFA 1857 without having received any prior signaling. When this happens the 1858 MN MUST solicit an FA Advertisement when it connects to nFA at L2 1859 (L2-UP) and perform standard Mobile IP registration on the nFA as 1860 specified in [1]. 1862 8.1.2. Failure of Inter-FA solicitation and advertisement 1864 The solicitation from an FA to another neighbouring FA may fail or 1865 the corresponding advertisement from the neighbouring FA may be lost. 1866 To reduce the probability that these messages are lost, the FAs MAY 1867 transmit multiple copies of these messages. If a failure occurs 1868 anyway, the FA soliciting the Agent Advertisment is unable to send a 1869 ProxyRtAdv in response to a source trigger or to a mobile-initiated 1870 ProxyRtSol. In these cases, when the MN does not receive a 1871 notification or confirmation of a PRE-REGISTRATION handoff, the MN 1872 MUST perform a standard Mobile IP registration as soon as it connects 1873 to the nFA (L2-UP) as specified in 8.1.1 and [1]. 1875 8.2. POST-REGISTRATION Signaling Failure Recovery 1877 Failure occurs in POST-REGISTRATION when either the HRqst or HRply 1878 message is dropped. The effects of the failure and the recovery 1879 procedure depend on which message is dropped, and whether the 1880 handover is source or target triggered. Since all of the 1881 POST-REGISTRATION signaling is going over the fixed network, it can 1882 be expected that spontaneous dropping of packets in the absence of 1883 congestion and router failure should be a relatively rare event. 1884 Nevertheless, failure recovery mechanisms SHOULD be implemented. 1886 8.2.1. HRqst Message Dropped 1888 If the HRqst message is dropped, the effect is the same for both 1889 source and target-triggered handoff. In either case, the FA to which 1890 the HRqst was destined will never respond with an HRply message. If 1891 the handoff is source-triggered, then the nFA never learns of the 1892 handoff, and the oFA never receives confirmation. If the handoff is 1893 target-triggered, then the oFA never learns of the handoff, and the 1894 nFA never receives confirmation. 1896 The recovery procedure in this case is as follows: the oFA MUST NOT 1897 construct a forward tunnel when the MN moves off-link (L2-LD) if the 1898 handoff is source-triggered, and the nFA MUST NOT construct a reverse 1899 tunnel if the handoff is target-triggered. If the nFA was not 1900 informed of the handoff by an HRqst message (corresponding to failure 1901 of source-triggered handoff) or if the handoff was not confirmed by 1902 an HRply message (corresponding to failure of target-triggered 1903 handoff) the nFA MUST unicast an Agent Advertisement to the MN as 1904 soon as its L2 connection is established (L2-LU at nFA). 1906 8.2.2. HRply Message Dropped 1908 If the HRply message is dropped, the FA sending the HRply will assume 1909 that the handoff has been confirmed, but the FA that is expecting to 1910 receive the HRply does not receive confirmation. In this case, the 1911 failure recovery procedure is different for source-triggered and 1912 target-triggered handoffs. 1914 In a target-triggered handoff, the oFA assumes the handoff is 1915 confirmed because it has sent the HRply, but the nFA has not received 1916 it so it does not have confirmation. The oFA starts tunneling 1917 packets to the nFA when the MN moves from its link (L2-LD). The nFA 1918 MUST send a FA Advertisement to the MN as soon as its L2 link is up 1919 (L2-UP at nFA) and MAY drop the tunneled packets. The nFA SHOULD 1920 send an ICMP Destination Unreachable [9] message to the oFA. When 1921 the oFA receives this message it will terminate the tunnel and stop 1922 forwarding packets. If reverse tunneling was requested the nFA MUST 1923 NOT reverse tunnel because it has not received confirmation of the 1924 handoff. 1926 In source-triggered handoff, the nFA assumes the handoff is confirmed 1927 because it has sent the HRply, but the oFA has not received it so it 1928 does not have confirmation. Without failure recovery, the MN could 1929 move to the nFA without the oFA being able to start the forward 1930 tunnel for the MN's packets, and the MN would not be able to initiate 1931 a Mobile IP registration because it does not know that the handoff 1932 has failed. In this situation, the oFA MUST send out a HRqst message 1933 to the nFA with lifetime zero as soon as the MN leaves its link 1934 (L2-LD). The oFA SHOULD continue to retransmit the HRqst message, 1935 with exponential backoff for CONFIG-HFAIL seconds or until it 1936 receives an HRply acknowledging the request to cancel the tunnel. 1937 The default value for CONFIG-HFAIL is 10 seconds. When the nFA 1938 receives the HRqst, it MUST immediately send an Agent Advertisement 1939 to the MN, as is the case whenever a tunnel is cancelled. In 1940 addition, the oFA MUST also drop any packets received through the 1941 reverse tunnel from the nFA. The oFA SHOULD NOT send the ICMP 1942 Destination Unreachable message to the nFA because the nFA has been 1943 informed by the HRqst message to cancel the tunnel. However, if the 1944 nFA receives an ICMP Destination unreachable message for the tunnel 1945 prior to receiving the HRqst canceling the tunnel, it MUST send an FA 1946 Advertisement to the MN and cancel the tunnel. 1948 9. Generalized Link Layer Address Extension 1950 This section defines the Generalized Link Layer Address (LLA) 1951 Extension, used by any node that needs to communicate Link Layer 1952 Addresses. The format of the extension relies on sub-types, where 1953 each sub-type defines its own sub-structure. This draft defines six 1954 sub-types. Future RFCs should allocate their own sub-type and define 1955 their own address formats. 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Type | Length | Sub-Type | LLA ... 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 Type 1965 TBD (skippable) [1] - when used for Mobile IP Registrations 1966 TBD (skippable) [1] - when used for Router Advertisements 1968 Length 1970 The length of the Link Layer Address + the one octet Sub-Type 1971 field 1973 Sub-Type 1975 This field contains the Link Layer sub-type identifier 1977 LLA 1979 Contains the Link Layer Address 1981 In this document, six subtypes are defined: 1983 1 3GPP2 International Mobile Station Identity and 1984 Connection ID [13] 1985 2 3GPP International Mobile Subscriber Identity [16] 1986 3 Ethernet 48 bit MAC address [5] 1987 4 64 bit Global ID, EUI-64 [6] 1988 5 Solicited IP Address 1989 6 Access Point Identifier 1991 The following subsections describe the extensions. 1993 9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension 1995 The IMSI Link Layer Address Extension contains the International 1996 Mobile Station Identity. 1998 0 1 2 3 1999 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 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | Type | Length | Sub-Type | IMSI ... 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 Type 2006 TBD (skippable) [1] 2008 Length 2010 The length of the IMSI field + the one octet Sub-Type field 2012 Sub-Type 2014 1 2016 IMSI 2018 Contains the IMSI, in the form: 2020 : 2021 Where the is an ASCII-based representation of the 2022 International Mobile Station Identifier, most significant 2023 digit first, ":" is ASCII 0x3a, and the Connection ID is the 2024 ASCII representation of a small, decimal number used for 2025 distinguishing different link-layer connections from the 2026 same device. 2028 9.2. 3GPP IMSI Link Layer Address Extension 2030 The IMSI Link Layer Address Extension contains the International 2031 Mobile Station Identity. 2033 0 1 2 3 2034 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 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Type | Length | Sub-Type | IMSI ... 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 Type 2040 TBD (skippable) [1] 2042 Length 2044 The length of the IMSI field + the one octet Sub-Type field 2046 Sub-Type 2048 2 2050 IMSI 2052 Contains the IMSI, a number composed of 15-digits or less, 2053 coded as described in [16]. 2055 9.3. Ethernet Link Layer Address Extension 2057 The Ethernet Link Layer Address Extension contains the 48 bit 2058 Ethernet MAC Address, as defined in [5]. 2060 0 1 2 3 2061 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 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Type | Length | Sub-Type | MAC ... 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 Type 2068 TBD (skippable) [1] 2070 Length 2072 7 (includes the Sub-Type field) 2074 Sub-Type 2076 3 2078 MAC 2080 Contains the 48 bit Ethernet MAC Address. 2082 9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension 2084 The 64-Bit Global Identifier (EUI-64) Address Extension contains the 2085 64 bit address, as defined in [6]. 2087 0 1 2 3 2088 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 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Type | Length | Sub-Type | MAC ... 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 Type 2095 TBD (skippable) [1] 2097 Length 2099 9 (includes the Sub-Type field) 2101 Sub-Type 2103 4 2105 MAC 2107 Contains the 64-Bit Global Identifier Address. 2109 9.5. Solicited IP Address Extension 2111 The 32-bit Solicited IP Address Extension contains the IP address of 2112 the agent (FA) being solicited. This extension MAY be present in an 2113 ICMP Agent Solicitation as explained in Section 3.3. 2115 0 1 2 3 2116 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 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Type | Length | Sub-Type | IP addr ... 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 Type 2123 TBD (skippable) [1] 2125 Length 2127 5 (includes the Sub-Type field) 2129 Sub-Type 2131 5 2133 IP Address 2135 Contains the 32-Bit IP Address of the solicited node. 2137 9.4. Access Point Identifier Extension 2139 The 32-bit Access Point Identifier Extension contains an Identifier 2140 of the Access Point to which the MN will move. This may be a 2141 wireless L2 identifier. The MN is able to solicit an advertisement 2142 from the FA servicing a certain Access Point by using this extension 2143 with Agent Solicitations as explained in Section 3.3. 2145 0 1 2 3 2146 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 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Type | Length | Sub-Type | AP ID... 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 Type 2153 TBD (skippable) [1] 2155 Length 2157 5 (includes the Sub-Type field) 2159 Sub-Type 2161 6 2163 AP ID 2165 Contains the 32-Bit Access Point Identifier. 2167 10. IANA Considerations 2169 This document defines one new extension to the Mobile IP Registration 2170 message and one new extension to the Router Advertisement message 2171 both defined in RFC 3344 [1]. This document also defines a new Mobile 2172 IP message type to be used between FAs. To ensure correct 2173 interoperation based on this specification, IANA must reserve values 2174 in the Mobile IP number space for two new extensions and one new 2175 message type. IANA must also manage the numbering spaces created by 2176 the two new extensions, the message type and its associated Code 2177 field. 2179 10.1. New Extension values 2181 Section 9 introduces two extensions. 2183 Generalized Link Layer Address Advertisement Extension: A new Mobile 2184 IP extension that follows after the Mobility Agent Advertisement 2185 Extension to ICMP Router Advertisements. The type value of this 2186 extension belongs to the Mobile IP number space for extension to 2187 Router Advertisements defined in RFC3344 [1]. The value assigned by 2188 IANA is TBD. This new extension also creates its own "Link Layer 2189 Identifier" Sub-Type numbering space that requires IANA management. 2190 This specification makes use of the Sub-type values 1-6, and all 2191 other values other than zero (0) are available for assignment via 2192 IETF consensus [15]. The six Sub-type values defined in this 2193 specification are: 2195 1 3GPP2 International Mobile Station Identity and 2196 Connection ID [13] 2197 2 3GPP International Mobile Subscriber Identity [16] 2198 3 Ethernet 48 bit MAC address [5] 2199 4 64 bit Global ID, EUI-64 [6] 2200 5 Solicited IP Address 2201 6 Access Point Identifier 2203 Generalized Link Layer Address Registration Extension: A new Mobile 2204 IP extension appended to Registration Request messages. The type 2205 value of this extension belongs to the Mobile IP number space for 2206 extensions to Mobile IP Registration messages defined in RFC 3344 2207 [1]. It MUST be in the skippable (128-255) range as defined in [1]. 2208 The value assigned is TBD by IANA. This new extension also creates 2209 its own "Link Layer Identifier" Sub-Type numbering space that 2210 requires IANA management. This specification makes use of the 2211 Sub-type values 1-6, and all other values other than zero (0) are 2212 available for assignment via IETF consensus [15]. The six Sub-type 2213 values defined in this specification are: 2215 1 3GPP2 International Mobile Station Identity and 2216 Connection ID [13] 2217 2 3GPP International Mobile Subscriber Identity [16] 2218 3 Ethernet 48 bit MAC address [5] 2219 4 64 bit Global ID, EUI-64 [6] 2220 5 Solicited IP Address 2221 6 Access Point Identifier 2223 10.2. New Message Type and Code 2225 Sections 4.4 and 4.5 define two new Mobile IP message types: Handoff 2226 Request and Handoff Reply. These require two type numbers to be 2227 assigned by IANA from the Mobile IP control message type address 2228 space. The Handoff Reply message also introduces its own Code field 2229 that requires IANA to manage a new Code address space. This 2230 specification makes use of the Code values 0-1, where 0 identifies a 2231 successful Handoff and 1 defines a generic handoff failure. All other 2232 values are available for assignment via IETF consensus [15]. 2234 11. Security Considerations 2236 For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA 2237 and nFA MUST share a security association to authenticate and 2238 integrity protect messages transported between them. In addition oFA 2239 must be authorized to solicit nFA based on the security association. 2240 The minimal requirement to establish a security association between 2241 FAs is that both FAs support manual pre-configuration of security 2242 associations involving shared keys. Other mechanisms to establish 2243 security associations using IKE [17] based on shared and public keys 2244 may also be used. The inter-FA ICMP messages (solicitations and 2245 advertisements) MUST be authenticated and integrity protected using 2246 ESP [10]. The default ESP authentication algorithm for use in this 2247 specification is HMAC-SHA1 [12]. The absence of this security would 2248 allow denial of service attacks from malicious nodes at any distance 2249 from the FA. Otherwise, to secure Registration Request and Reply 2250 messages, PRE-REGISTRATION uses the security mechanisms already 2251 described in [1] and [11]. 2253 POST-REGISTRATION introduces a new change to Mobile IP, which is the 2254 possibility that a MN may receive packets from an FA with which it 2255 has not yet performed a Mobile IP Registration. In the event that 2256 the MN does not wish to receive packets from unknown FAs, it MAY drop 2257 them. In a similar way to PRE-REGISTRATION, oFA and nFA MUST share a 2258 security association required to protect the Handoff Request and 2259 Reply messages. The minimal requirement to establish a security 2260 association between FAs is that the FAs support manual 2261 pre-configuration of security associations involving shared keys. 2262 Other mechanisms to establish security associations using IKE [17] 2263 based on shared and public keys may also be used. The Handoff 2264 Request and Reply messages MUST be authenticated using the FA-FA 2265 authentication extension [11] that uses the default algorithm 2266 specified in [7]. The absence of this security would allow 2267 impersonation attacks and denial of service attacks. 2269 The minimal requirement is that all FAs involved in low latency 2270 handoffs MUST support manual pre-configuration of security 2271 associations with neighbouring FAs, involving shared keys and are 2272 already required to support the default algorithms of [1]. 2274 Since the techniques outlined in this document depend on particular 2275 L2 information (triggers) to optimize performance, some level of L2 2276 security is assumed. Both PRE and POST-REGISTRATION techniques 2277 depend on L2 triggers, but the L2 security implications are different 2278 for the two techniques. 2280 In particular, in POST-REGISTRATION the L2 triggers initiate the 2281 establishment of tunnels which route IP packets for the MN to its new 2282 location. Therefore the L2 triggers MUST be secured against any 2283 tampering by malicious nodes, either mobile or within the wired 2284 network. The L2 addresses or IP addresses for the MN and the FAs 2285 that appear in the L2 triggers MUST correspond to the actual nodes 2286 that are participating in the handover. If there is any possibility 2287 that tampering may occur, the recipient of an L2 trigger MUST have 2288 some way of authenticating the L2 information. Wireless networks 2289 that do not provide such features will be subject to impersonation 2290 attacks, where malicious nodes could cause FAs to believe that a MN 2291 has moved to other service areas or to allow a bogus MN to obtain 2292 unauthorized service from an FA prior to performing a Mobile IP 2293 registration. In POST-REGISTRATION the L2 triggers would be 2294 typically sent between a wireless base station and the FA. No 2295 standard protocol exists at this time to communicate the L2 trigger 2296 information but it is important that any future protocol used for 2297 this purpose provides adequate security. If the wireless base station 2298 and FA are integrated then this security threat would not apply. 2299 Also the layer-2 control messages on the wireless link must be 2300 secured appropriately to prevent a malicious node from running 2301 impersonation attacks and causing unwanted L2 triggers to be 2302 generated. This depends on the L2 security of the wireless link. 2303 For example in cellular technologies the control messages are secured 2304 but this is not typically the case in WLAN IEEE 802.11 networks. 2306 In PRE-REGISTRATION the security of L2 triggers has different 2307 implications. The PRE-REGISTRATION technique depends on Mobile IP 2308 security between MN and FA, so the same security considerations in 2309 [1] apply. Should malicious nodes be able to generate or modify L2 2310 trigger information (i.e. L2-ST or L2-TT), this would cause 2311 advertisements to be sent to the MN. They would consume wireless 2312 resources and processing in the MN, but would not allow an 2313 impersonation attacks. In order to prevent such denial of service 2314 attacks, there should be a limit on the number of advertisements that 2315 an FA (oFA) will relay to the MN as a result of the reception of L2 2316 triggers. This number will depend on the L2 technology and the 2317 default limit is 10 per second. 2319 12. Acknowledgements 2321 The authors would like to thank the Mobile IP WG chairs, Phil Roberts 2322 and Basavaraj Patil, for their input and Jonathan Wood for valuable 2323 comments on PRE-REGISTRATION. 2325 13. Editor's Address 2327 Karim El Malki 2328 Ericsson 2329 LM Ericssons Vag. 8 2330 126 25 Stockholm, Sweden 2331 Phone: +46 8 7195803 2332 E-mail: karim.el-malki@ericsson.com 2334 14. Contributing Authors 2336 Pat Calhoun, Black Storm Networks 2337 2339 Tom Hiller, Lucent Technologies 2340 2342 James Kempf, NTT DoCoMo USA Labs 2343 2345 Peter J. McCann, Lucent Technologies 2346 2348 Ajoy Singh, Motorola 2349 2351 Hesham Soliman, Flarion 2352 2354 Sebastian Thalanany, Motorola 2355 2357 15. References 2359 15.1. Normative References 2361 [1] C. Perkins, Editor, "IP Mobility Support for IPv4", RFC 3344, 2362 August 2002. 2364 [2] S. Bradner. "Key words for use in RFCs to Indicate 2365 Requirement Levels". BCP 14, RFC 2119, March 1997. 2367 [3] G. Montenegro, "Reverse Tunneling for Mobile IP, revised", RFC 2368 3024, January 2001. 2370 [4] D. Farinacci, T. Li, S. Hanks, and P. Traina, "Generic 2371 Routing Encapsulation (GRE)", RFC 2784, Internet Engineering 2372 Task Force, March 2000. 2374 [5] D. Plummer, "An Ethernet Address Resolution Protocol - or 2375 Converting Network Protocol Addresses to 48.bit Ethernet 2376 Address for Transmission on Ethernet Hardware", RFC 826, 2377 November 1982. 2379 [6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 2380 Registration Authority", 2381 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 2382 March 1997. 2384 [7] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 2385 Extensions", RFC 3012, November 2000. 2387 [8] S. Deering, "ICMP Router Discovery", RFC 1256, September 1991 2389 [9] J. Postel, "Internet Control Message Protocol," RFC 792, 2390 September 1981. 2392 [10] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 2393 (ESP)", RFC 2406, November 1998. 2395 [11] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional 2396 Tunnel Management", draft-ietf-mobileip-reg-tunnel-08 (work in 2397 progress), November 2003. 2399 [12] C. Madson and R. Glenn, "The Use of HMAC-SHA1-96 within ESP 2400 and AH", RFC 2404, November 1998. 2402 15.2. Informative References 2404 [13] TIA/EIA/IS-2000. 2406 [14] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier 2407 Extension", RFC 2794, March 2000. 2409 [15] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA 2410 Considerations Section in RFCs", BCP 26, RFC 2434, October 2411 1998. 2413 [16] 3GPP TS 23.003 (www.3gpp.org). 2415 [17] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 2416 RFC 2409, November 1998. 2418 Intellectual Property Statement 2420 The IETF takes no position regarding the validity or scope of any 2421 Intellectual Property Rights or other rights that might be claimed to 2422 pertain to the implementation or use of the technology described in 2423 this document or the extent to which any license under such rights 2424 might or might not be available; nor does it represent that it has 2425 made any independent effort to identify any such rights. Information 2426 on the IETF's procedures with respect to rights in IETF Documents can 2427 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 2429 Copies of IPR disclosures made to the IETF Secretariat and any 2430 assurances of licenses to be made available, or the result of an 2431 attempt made to obtain a general license or permission for the use of 2432 such proprietary rights by implementers or users of this 2433 specification can be obtained from the IETF on-line IPR repository at 2434 http://www.ietf.org/ipr. 2436 The IETF invites any interested party to bring to its attention any 2437 copyrights, patents or patent applications, or other proprietary 2438 rights that may cover technology that may be required to implement 2439 this standard. Please address the information to the IETF at 2440 ietf-ipr@ietf.org. 2442 Copyright Statement 2444 Copyright (C) The Internet Society (2004). This document is subject 2445 to the rights, licenses and restrictions contained in BCP 78, and 2446 except as set forth therein, the authors retain all their rights. 2448 Disclaimer of Validity 2450 This document and the information contained herein are provided on an 2451 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2452 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2453 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2454 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2455 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2458 Appendix A - Gateway Foreign Agents 2460 The Mobile IP Regional Registration specification [11] introduces the 2461 Gateway Foreign Agent (GFA), as a mobility agent that two FAs 2462 providing service to a MN have in common. Figure A.1 provides an 2463 example of a MN's initial registration through the GFA. If this is 2464 the first registration message, the message MUST be forwarded to the 2465 HA. All packets destined for the mobile will be delivered to the 2466 GFA, which in turn will forward the packets to the FA servicing the 2467 MN. 2469 Reg Req +-----+ Reg Req 2470 +----------->| oFA |--------------+ 2471 | +-----+ | 2472 | v 2473 +----+ +-----+ Reg Req +----+ 2474 | MN | | GFA |<------->| HA | 2475 +----+ +-----+ +----+ 2477 +-----+ 2478 | nFA | 2479 +-----+ 2481 Figure A.1 - Initial Registrations through GFA 2483 If the MN moves to a nFA that is serviced by a GFA common with oFA, 2484 the MN MAY issue a Regional Registration Request (see Figure A.2). 2485 The Regional Registration message does not need to be forwarded to 2486 the HA, since the MN's traffic can still be delivered to the same 2487 GFA. This optimized approach effectively reduces the latency 2488 involved in the registration process. 2490 +-----+ 2491 | oFA | 2492 +-----+ 2494 +----+ +-----+ +----+ 2495 | MN | | GFA | | HA | 2496 +----+ +-----+ +----+ 2497 | ^ 2498 | +-----+ | 2499 +------------>| nFA |-------------+ 2500 Regional Reg +-----+ Regional Reg 2502 Figure A.2 - Regional Registration through GFA 2504 Note that the GFA may also be the MN's first-hop router. 2506 Appendix B - Low Latency Handoffs for Multiple-Interface MNs 2508 For MNs that have two wireless network interfaces, either on the same 2509 wireless network or on wireless networks having different wireless L2 2510 technologies, the techniques discussed in this document may be 2511 unnecessary if the Mobile IP stack on the MN allows switching an IP 2512 address binding between interfaces. This Appendix discusses how 2513 multiple wireless interfaces can aid low latency handoff. 2515 Figure B.1 illustrates the normal and hierarchical MIPv4 models. As 2516 shown in the figure, assume that the MN is connected to Radio Network 2517 1 (RN1) and is registered with oFA through which it is receiving 2518 traffic. Suppose MN enters the coverage area of RN2 and nFA and that 2519 it prefers connectivity to this network for reasons beyond the scope 2520 of this document (e.g. user preferences, cost, QoS available etc.). 2521 The MN activates the interface to RN2 but continues communicating 2522 through RN1. The MN may solicit advertisements from nFA through the 2523 interface connected to RN1 to speed up the handoff process, provided 2524 there is no TTL restriction, or it can solicit advertisements through 2525 the interface connected to RN2 if it has been configured for IP 2526 traffic. 2528 +------+ +---------+ 2529 | HA |--------| (GFA) | 2530 +------+ +---------+ 2531 / \ 2532 / \ 2533 ... ... 2534 / \ 2535 / \ 2536 +------+ +------+ 2537 | oFA | | nFA | 2538 +------+ +------+ 2539 | | 2540 +------+ +------+ 2541 | RN1 | | RN2 | 2542 +------+ +------+ 2544 +------+ 2545 | MN | ---------> 2546 +------+ 2548 Movement 2550 Figure B.1 - Network Model for Mobile IPv4 With Multi-Access 2552 Once the MN is registered with nFA and is successfully receiving and 2553 transmitting through the new network, it tears down the interface to 2554 RN1. If the MN has enough time to complete this procedure without 2555 incurring degraded service or disconnection, the MN would experience 2556 a seamless multi-access handoff but it may not be possible in all 2557 cases, due to network coverage or for other reasons. Should multiple 2558 interface handoff be possible then the low latency methods described 2559 in this document are not necessary. 2561 In order to support the possible failure of the connectivity with the 2562 new network (RN2/nFA) in the short period following handoff, the MN 2563 may use the "S" bit in its Mobile IP Registration Request to maintain 2564 simultaneous bindings both its existing (HA or GFA) binding with oFA 2565 and a new binding with nFA.