idnits 2.17.1 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 743 has weird spacing: '...ssisted desig...' == 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 (February 23, 2001) is 8435 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) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-03 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-10 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2344 (ref. '5') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '6') == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-05 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 3012 (ref. '11') (Obsoleted by RFC 4721) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '12') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group MIPv4 Handoffs Design Team 2 INTERNET-DRAFT Karim El Malki (Editor) 3 Expires: August 2001 Pat R. Calhoun 4 Tom Hiller 5 James Kempf 6 Peter J. McCann 7 Ajoy Singh 8 Hesham Soliman 9 Sebastian Thalanany 11 February 23, 2001 13 Low latency Handoffs in Mobile IPv4 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Abstract 41 Mobile IP (RFC2002) describes how a Mobile Node (MN) can perform IP- 42 layer handoffs between Foreign Agent (FA) subnets. In certain cases, 43 the latency involved in these handoffs can be above the threshold 44 required for the support of delay-sensitive or real-time services. 45 The aim of this document is to present two methods to achieve low- 46 latency Mobile IP handoffs (movement between FA subnets). These allow 47 greater support for real-time services on a Mobile IPv4 network by 48 minimising the period of service disruption due to the delay in the 49 Mobile IP Registration process. 51 TABLE OF CONTENTS 53 1. Introduction....................................................3 54 1.1 Requirements language........................................4 56 2. Requirements....................................................4 58 3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff 59 Method..........................................................4 60 3.1 Initiating NAMONC Handoffs through the "previous" FA.........9 61 I. Inter-FA Solicitation .....................................10 62 II. Piggy-backing Advertisements on L2 messaging.............10 63 3.2 Movement Detection and MN Considerations.....................10 64 3.3 Regional Deregistration for NAMONC Handoffs..................13 65 3.4 Smooth Handoffs between Hierarchies (GFAs)...................13 66 3.5 L2 Address Considerations for NAMONC Handoffs................14 67 3.6 Advantages and Applicability of NAMONC Handoff Method........15 69 4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method....15 70 4.1 Registration Latency........................................16 71 4.2 Movement Detection..........................................17 72 4.3 Ping-Pong effect............................................19 73 4.4 Reverse Tunneling Support...................................20 74 4.5 Security Relationships......................................20 75 4.6 Operation...................................................21 76 4.6.1 Foreign Agent Considerations...........................21 77 4.6.2 Gateway Foreign Agent Considerations...................24 78 4.7 Handoff Request Message.....................................24 79 4.8 Handoff Reply Message.......................................26 80 4.9 Error Values................................................27 81 4.10 Security Considerations.....................................27 82 4.11 Advantages and Applicability of NIMOT Handoff Method....... 28 84 5. Generalized Link Layer Address Extension.......................29 85 5.1 IMSI Link Layer Address Extension...........................29 86 5.2 Ethernet Link Layer Address Extension.......................30 87 5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension....31 89 6. IANA Considerations.............................................31 91 7. References......................................................32 93 8. Authors' Addresses..............................................33 95 Appendix A - Gateway Foreign Agents................................36 96 Appendix B - Bicasting Applicability Statement.....................37 98 1. Introduction 100 Mobile IPv4 (RFC2002) describes how a Mobile Node (MN) can perform 101 IP-layer handoffs between Foreign Agent (FA) subnets. In certain 102 cases, the latency involved in these handoffs can be above the 103 threshold required for the support of delay-sensitive or real-time 104 services. The aim of this document is to present two methods to 105 achieve low-latency Mobile IP handoffs (movement between FA subnets). 106 These allow greater support for real-time services on a Mobile IPv4 107 network by minimising the period of service disruption due to the 108 delay in the Mobile IP Registration process. 110 The two methods presented in this draft to achieve low-latency IP- 111 layer handoffs are: 113 - Network Assisted, Mobile and Network Controlled (NAMONC) Handoffs 114 - Network Initiated, Mobile Terminated (NIMOT) Handoffs 116 The Network Assisted, Mobile and Network Controlled (NAMONC) Handoff 117 method allows the MN to be involved in an anticipated IP-layer 118 handoff procedure. The MN is therefore assisted by the network in 119 performing an anticipated L3 handoff before it completes the L2 120 handoff. Information from L2 (L2 triggers) may be used both in the MN 121 and in the FA. This method proposes the use of simultaneous bindings 122 in order to send multiple copies of the traffic to potential Mobile 123 Node movement locations before MN movement occurs. Therefore, the 124 Mobile-Assisted Handoff method coupled to layer 2 mobility may help 125 in achieving seamless (low latency + low loss) handoffs between 126 Foreign Agents. However L2 connectivity may cause packet losses. In 127 addition to handling the simple case of a MN, FA, and Home Agent, the 128 NAMONC Handoff method also allows the use of Regional Registrations 129 [2]. The Mobile IPv4 concept (Advertisement-Registration) is 130 supported and NAMONC handoffs rely on Mobile IP security. No new 131 messages are proposed. In cases where the MN is able to activate 132 multiple interfaces and thus be data-connected to multiple access 133 points simultaneously, the MN may not need to support anticipated 134 simultaneous bindings and may achieve seamless handoffs simply by 135 establishing connectivity through registrations with the new FA 136 before disconnecting from the current interface. 138 The Network Initiated, Mobile Terminated (NIMOT) handoffs method 139 proposes extensions to the Mobile IP protocol to allow the old FA 140 and new FA to utilize information from layer 2 (the L2 "trigger") to 141 set up a kind of "pre-registration" prior to receiving a formal 142 Registration Request from the Mobile Node. This enables a very rapid 143 establishment of service at the new point of attachment so that the 144 effect of the handoff on real-time applications is minimized, 145 although the MN must eventually perform a formal Mobile IP 146 registration. The proposed extensions make a few minimal assumptions 147 about support available from the link layer. Although the assumptions 148 address the kinds of link layer support available in existing radio 149 link layers, the assumptions are not based on any specific radio link 150 protocol. Security is handled by standard Mobile IP mechanisms, and 151 both intra-domain and inter-domain handoff are supported. The 152 technique can be used for inter-technology handoff but it requires 153 the active involvement by the mobile to switch from one network 154 interface to another. This technique covers a handoff scenario not 155 addressed by RFC 2002, namely a pro-active, network-assisted handoff. 157 Each method may be better suited for certain access network 158 characteristics and the features and advantages of each method will 159 be described later. NAMONC and NIMOT handoffs may be implemented 160 independently. It is up to the implementor, based on the link-layer 161 characteristics of the specific implementation and the features of 162 each method supplied in this document to decide upon which is most 163 appropriate for that case. 165 1.1 Requirements language 167 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 168 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 169 described in [3]. 171 2. Requirements 173 The following requirements are applicable to low-latency handoffs and 174 are supported by both methods: 176 - Support delay-sensitive (real-time) services in domain 177 - Support back-and-forth movement of MN between FAs (ping-pong) 178 - No dependency on a wireless L2 technology 179 - Support Inter and Intra-access technology handoffs 180 - Limit wireless bandwidth usage 182 3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff 183 Method 185 This method is intended to support low latency IP-layer handoffs for: 187 - Multi-access mobility 188 (different access technologies; MN and network controlled) 189 - Single-access mobility 190 (same access technology; MN and network controlled) 192 This method considers both the normal Mobile IP model [1] and the 193 Regional (hierarchical) Mobile IP model [2]. These are shown in 194 Figure 1 where the Access Points (APs) or Radio Networks (RNs) are 195 used to provide a MN with wireless or wired L2 access. Both inter and 196 intra-domain (AAA-assisted) mobility is considered. 198 The additional features for this method are: 200 - Support MN-control of L3 handoff (as RFC2002) 201 MN controls its registrations and there are no proxy registrations 202 on MN's behalf. 204 - Support network(FA)-control of L3 handoff (as RFC2002) 205 FA controls advertisements (which cause MN handoff) and can 206 accept/reject registrations. 208 - No new messages 210 - Maintain RFC2002 concept thus allowing MN to determine which FA it 211 will register with(advertisement->movement detection->registration) 213 - Rely on existing Mobile IP security model MN-FA-HA (e.g. using 214 AAA) but make no assumption on L2 security 216 - No L3 knowledge of exact L2 handoff timing (but this method can 217 make use of handoff indications or triggers from L2 on either the 218 network or terminal side depending on the initiator) 220 Figure 1 illustrates the normal and hierarchical MIPv4 models. In the 221 simplest multi-access or single-access case where the MN is able to 222 activate more than one interface (corresponding to different or the 223 same access technologies) and thus be data-connected to multiple 224 access points simultaneously it is possible to achieve low-latency 225 handoffs in a relatively simple manner. Assume that the MN is 226 connected to RN2 and is registered with FA2 through which it is 227 receiving traffic. The MN may enter the coverage area of RN1 and FA1 228 and decide that it prefers connectivity to this network for reasons 229 beyond the scope of this document (e.g. user preferences, cost, QoS 230 available etc.). The MN would then activate the interface to RN1 as 231 well as continue communicating through RN2. The MN may solicit 232 advertisements from FA1 to speed up the handoff process. Once it is 233 registered with FA1 and is successfully receiving and transmitting 234 through the new network it may then tear down the interface to RN2. 235 If the MN has enough time to complete this procedure without 236 incurring degraded service or disconnection then it would provide the 237 MN with a seamless multi-access handoff. In order to support the 238 possible failure of the connectivity with the new network (RN1/FA1) 239 in the short period following handoff the MN MAY use the "S" bit in 240 its Mobile IP Registration Request to maintain both its existing (HA 241 or GFA) binding with FA2 and a new binding with FA1 (i.e. 242 simultaneous bindings). The use of simultaneous bindings is not 243 necessary in most of the cases belonging to this scenario. 245 _________ _________ 246 | | | | 247 | HA |--------| (GFA) |________ 248 |_________| |_________| \ 249 / | \ \ 250 \ 251 ... ... ... \ 252 \ 253 ______/_ _\______ | 254 | | | | | 255 | FA2 | | FA1 | | 256 |________| |________| | 257 ____|___ ____|___ ____|___ 258 | | | | | | 259 | AP/RN 2| | AP/RN 1| | AP/RN 3| 260 |________| |________| |________| 261 | ____|___ 262 | | 263 CN | MN | 264 |________| 266 Figure 1 - Normal(HA only) and Hierarchical(HA and GFA) MIPv4 model 268 In the remaining part of the description of the NAMONC Handoffs 269 method, the scenarios for single and multi-access handoffs will be 270 considered. In these scenarios the MN is unable to activate and 271 communicate over more than one interface or connection to the 272 network. This may be due to limitations imposed by the access 273 technology or configuration of the mobile node. In these cases it is 274 necessary to anticipate the IP-layer handoff before the MN's movement 275 actually happens in order to achieve a seamless mobility effect as 276 close as possible to that described previously. 278 In Figure 1, using normal Mobile IP (no GFA) the MN MAY perform 279 registrations with the HA using simultaneous bindings. This is 280 described in [1] and the method to anticipate MN movement by 281 interacting with the wireless L2 is described later in this draft. 282 Simultaneous bindings are used to decouple the IP-layer handoff from 283 the L2 handoff by having data reaching the multiple possible MN 284 locations before the MN moves there since the details of the L2 285 handoff timing are unknown to L3. "Bicasting" or simultaneous 286 bindings are also useful to support "ping-pong" or fast back-and- 287 forth MN movement between FAs due to fast mobility or handoff 288 failures. 290 An alternative method to perform improved handoffs, namely Smooth 291 Handoffs, is described in [4]. The method for NAMONC Handoffs 292 addresses the need to support services having strict delay bounds 293 (i.e. real-time) which in certain cases may be hard to support if 294 traffic has to be forwarded between FAs using Smooth Handoffs. This 295 is especially true if the two FAs are not directly connected. If 296 there is a common router or router network connecting the two FAs and 297 the HA, forwarding traffic between FAs would cause twice the 298 bandwidth usage on the common router/s and a considerable increase in 299 delay. Also, in the non-realtime case it may be possible that the new 300 FA receives both buffered traffic from the previous FA (smooth 301 handoff) and traffic from the HA which could cause some delayed and 302 possibly out-of-order packets to be delivered to the MN. This could 303 affect the performance of higher level protocols (e.g. TCP). The same 304 situation will not arise using NAMONC Handoffs. 306 However, having multiple simultaneous bindings for MNs at the HA will 307 cause the HA to send multiple copies of data packets towards mutliple 308 FAs which may be in the same region or domain. In terms of bandwidth 309 usage this would not be efficient unless the HA is close to the FAs 310 in question, however this is not always the case. Also, if the round- 311 trip time between HA and FAs is not negligible this may slow down the 312 MN's new Registration and therefore the Mobile IP handoff. The 313 Hierarchical MIPv4 model addresses these problems. 315 The Regional (Hierarchical) Mobile IPv4 scheme introduced in Regional 316 Registrations [2] allows a Mobile Node to perform registrations 317 locally with a Gateway Foreign Agent (GFA) in order to reduce the 318 number of signalling messages to the home network. This achieves a 319 reduction in the signalling delay when a Mobile Node moves between 320 Foreign Agents and therefore improves the performance of such 321 handoffs. This draft is applicable to single-level (GFA only with no 322 regional FAs) and multi-level Hierarchical Mobile IPv4 networks 323 described in Regional Registrations [2]. Networks utilizing Regional 324 Registrations with NAMONC Handoffs offer advantages which are 325 especially important for the support of real-time services. As 326 mentioned previously, the GFA may well be the first-hop router for 327 the MN. 329 In the Regional (Hierarchical) Mobile IP case the NAMONC Handoff is 330 achieved by "bicasting" traffic from the GFA to the previous FA and 331 new FA while the MN is moving between them. The anticipation of the 332 MN's movement is achieved by tight coupling with Layer 2 333 functionality in the FA which is dependent on the type of access 334 technology used. Bicasting is achieved through simultaneous bindings, 335 where the MN activates the "S" bit in the Registration Request 336 (described in [1]). In a hierarchical MIPv4 network, when a Regional 337 Registration Request has the "S" bit set, the receiving regional FA 338 or GFA which has an existing binding with the MN will add the 339 relevant new binding for the MN but will also maintain any other 340 existing bindings it had for the MN. 342 When the MN has multiple active bindings with FAs, it MAY receive 343 multiple copies of the same traffic directed to it. The use of 344 simultaneous bindings does not necessarily mean that the MN is 345 receiving packets contemporarily from multiple sources. This depends 346 on the characteristics of the access (L2) technology. The bicasting 347 of packets is used to anticipate the MN's movement and speed up 348 handoffs by sending a copy of the data to the FA which the MN is 349 moving to. Until the MN actually completes the L2 handoff to the new 350 FA, the data "copy" reaching this FA may be discarded. In this way 351 the total handoff delay is limited to the time needed to perform the 352 L2 handoff. Thus, NAMONC Handoffs coupled to the L2 access 353 potentially result in loss-less IP-layer mobility. As described in 354 3.1, depending on the L2 characteristics, it is also possible for an 355 MN to initiate a NAMONC Handoff through the "previous" FA without 356 having direct access to the "new" FA. 358 The overall NAMONC Handoff mechanism is summarised in Figure 2 below: 360 +-----+ 361 | GFA |<---------+ 362 +-----+ | 4. RegRegReq. 363 | 5. RegRegReply 364 v 365 +-----+ (1a RtSol) +-----+ 366 | | -----------------> | nFA | 367 | oFA | 1b.RtAdv | | 368 +-----+ <----------------- +-----+ 369 ^ | ^ 370 (2a. RtSol) | | 2b. / 371 | | ProxyRtAdv / 3. RegRegReq 372 | | / 373 | v --------------- 374 +-----+ / 375 | MN | 376 +-----+ - - - - - -> 377 Movement 379 Figure 2 - NAMONC Handoff Message exchange 381 Messages 1a and 1b (Router Solicitation and Router Advertisement) 382 should occur in advance of the NAMONC Handoff and should not delay 383 the sending of message 2b. For this purpose the old FA (oFA) MAY 384 solicit and cache advertisements from the new FA (nFA), thus 385 decoupling the timing of this exchange from the rest of the NAMONC 386 Handoff. Message 2a occurs if there is an L2 trigger in the MN to 387 solicit for a router advertisement. In network-controlled wireless 388 systems the L2 trigger will be in the network and will reach oFA 389 which will transmit the Proxy Router Advertisement (message 2b). This 390 is simply nFA's advertisement relayed by oFA. The MN will perform 391 movement detection and, if appropriate, send a Regional Registration 392 Request message [2] (message 3) to nFA requesting a simultaneous 393 binding. Message 3 may be routed through oFA since the MN is not 394 directly connected to nFA at this point. Messages 3, 4 and 5 are 395 described in [2]. The Regional Registration Reply (message 5) needs 396 to be forwarded by nFA to the MN. Unless the system is engineered 397 such that the MN may not detach from oFA until it has received the 398 Reply, the MN may at this time have disconnected. Therefore the Reply 399 should be copied by nFA to the MN's old location (tunnelling the 400 Regional Registration Reply to oFA) and to the MN's new location. The 401 MN's new L2 address may be obtained using the extensions in section 402 5, as described in 3.5. At this moment it may still not be known at 403 L3 whether the MN has detached and connected to nFA. Even if it was 404 known at the exact instant, in most wireless systems there would not 405 be enough time for L3 to react and forward traffic to the MN's new 406 location by the time the MN has attached. For this reason, to 407 maintain L3 connectivity, simultaneous binding are used. Therefore 408 for a short time interval from the moment the Regional Registration 409 Reply is sent by the from GFA to nFA, the GFA will start bicasting 410 traffic for the MN to both oFA and nFA. Therefore the MN will be able 411 to receive traffic independently of the exact L2 handoff timing. 412 Also, should the L2 handoff procedure fail or terminate abruptly, the 413 use of simultaneous bindings allows the MN to maintain L3 414 connectivity with oFA. The same stands for the case in which the MN 415 performs "ping-pong" or fast back-and-forth movement between FAs, 416 where simultaneous bindings allow continued L3 connectivity without 417 the need to continuously receive advertisements and send registration 418 messages. This reduces the signalling load over the air interface. 419 Note that this method can be applied to the case where multiple 420 possible nFAs are identified by oFA. 422 3.1 Initiating NAMONC Handoffs through the "previous" FA 424 Some existing wireless L2 technologies and their implementations do 425 not allow a MN to be data-connected to multiple wireless access 426 points simultaneously. In order to perform a NAMONC Handoff it is 427 necessary for some form of interworking between layers 2 and 3 to 428 determine when a L3 handoff should be triggered by a L2 handoff. It 429 should be noted that the method used by an FA to determine when a MN 430 has initiated an L2 handoff (L2 trigger) for which the FA should 431 initate a NAMONC Handoff is outside the scope of this draft and may 432 involve interaction with L2 messaging. If the FA determines from the 433 L2 trigger that movement between FAs will not occur then the NAMONC 434 Handoff should not be initiated. When this is not the case, the 435 interaction between L2 and L3 (on the network side and/or MN-side) 436 should allow the Mobile Node to complete a L2 handoff (resulting in 437 movement between FAs) after having performed the L3 NAMONC Handoff 438 described in this draft. That is, the L2 handoff should be completed 439 after the MN's Registration with the "new" FA which produces a 440 simultaneous binding at the GFA/HA. This Registration may be 441 transmitted more than once to reduce the probability that it is lost 442 due to errors on the wireless link. 444 A NAMONC Handoff in this case requires the MN to receive "new" agent 445 advertisements through the "old" wireless access points, and to 446 perform a registration with the "new" FA through the "old" wireless 447 access point. This procedure should be performed before the layer-2 448 handoff event. Two ways of performing this follow. 450 I. Inter-FA Solicitation 452 This solution assumes that the FA with which the MN is currently 453 registered is aware of the IP address of the "new" FA which the MN is 454 moving to. The method by which the current FA is informed of this may 455 depend on interaction with L2 and is outside the scope of this draft. 457 Once the current FA is aware of the address of the FA which the MN 458 will move to, it will send the "new" FA an agent solicitation 459 message. The "new" FA will reply to the current FA by sending it an 460 agent advertisement with appropriate extensions. The current FA will 461 then send the agent advertisement to the MN's address. As a 462 consequence, the MN, being eager to perform new registrations, will 463 send a registration request to the "new" FA through the "old" 464 wireless access point served by the current FA. 466 II. Piggy-backing Advertisements on L2 messaging 468 Using Figure 1, consider a case where an MN initiates an L2 handoff 469 from AP/RN1 to AP/RN2 (Note that it may not be the MN which takes 470 decisions on L2 handoffs). It is assumed that when an L2 handoff is 471 initiated, AP/RN1 and AP/RN2 perform L2 messaging procedures to 472 negotiate the L2 handoff. Since the MN is not attached to AP/RN2 yet, 473 FA2 is unaware of the IP address of the MN and cannot send an 474 advertisement to it. Therefore it is necessary for the L2 procedures 475 (which must be common to AP/RN1 and AP/RN2) to interwork with Mobile 476 IP. 478 Once a L2 handoff is initiated, such that AP/RN2 and AP/RN1 are in 479 communication, it is possible for AP/RN2 to solicit an advertisement 480 from FA2 and transfer it to AP/RN1. Once this is received by the MN, 481 the MN can perform a registration directed to FA2 even though the MN 482 has no data-connection to AP/RN2 yet. 484 The precise definition of such L2 procedures is outside the scope of 485 Mobile IP. 487 3.2 Movement Detection and MN Considerations 489 When there is a hierarchy of foreign agents between the GFA and the 490 announcing foreign agent, the announcing foreign agent MAY include 491 the corresponding addresses in order between its own address (first) 492 and the GFA address (last) in the Mobility Agent Advertisement 493 extension of its Agent Advertisements. If there are only two 494 hierarchical levels, a foreign agent announces itself and a GFA in 495 the Agent Advertisement; in the first and last address in the care-of 496 address field in the Mobility Agent Advertisement extension. There 497 must be at least one care-of address in the Mobility Agent 498 Advertisement extension. If there is only one care-of address it is 499 the address of the GFA, and the MN is connected directly to it. 501 When the MN receives an Agent Advertisement with a Mobility Agent 502 extension and the "I" bit set, as specified in [2], it should perform 503 actions according to the following movement detection mechanisms. In 504 a Hierarchical Mobile IP network such as the one described in this 505 draft, the MN MUST be: 507 - "Eager" to perform new bindings 508 - "Lazy" in releasing existing bindings 510 The above means that the MN MUST perform Regional Registrations with 511 any "new" FA from which it receives an advertisement (Eager) as long 512 as there are no locally-defined policies in the MN which discourage 513 the use of this FA (e.g. cost of service). The method by which the MN 514 determines whether the FA is a "new" FA is described in [1] and may 515 make use of an FA-NAI extension. However the MN MUST NOT release 516 existing bindings until it no longer receives advertisement from the 517 relative FA and the lifetime of its existing binding expires (Lazy). 519 It should be noted that the MN may add a Hierarchical FA extension to 520 Registration Requests in order to identify the exact FA path to be 521 followed by the Registration Request. This extension must not be 522 removed by regional FAs. 524 If the MN has at least one existing binding with a FA, additional 525 simultaneous regional registrations will be performed requesting a 526 short lifetime. This is done in order to limit the lifetime of 527 bindings which the MN only needs temporarily and therefore limit 528 bandwidth usage. This is the case when the MN is moving between FAs 529 and uses NAMONC Handoffs to achieve loss-less IP mobility. The 530 lifetime of additional "auxiliary" bindings needed for NAMONC 531 Handoffs is thus limited. This may also be useful to support eventual 532 the MN's "ping-pong" movement between FAs which would otherwise 533 require continuous registrations and thus handoff delays. 535 The remaining issue is the choice of the appropriate HA address in 536 the Regional Registration Request when the MN has at least an 537 existing active regional binding. Two options follow: 539 1) Mobility Agent extension advertises FA and GFA address only 541 In this case it is assumed that there is always a single path from 542 the MN to the GFA. The MN will always perform Regional Registrations 543 using the GFA address as HA address and the advertising FA as care-of 544 address. As the Regional Registration Request is relayed towards the 545 GFA, each FA receiving it will check whether it has an existing 546 binding with the MN and whether the Regional Registration has the "S" 547 bit set to request for simultaneous bindings. If this is true and the 548 Regional Registration is validated by the GFA, these FAs will 549 activate the simultaneous binding upon receiving the (successful) 550 Regional Registration Reply from the GFA. Therefore it is not 551 necessary to advertise to the MN all of the FA addresses in the 552 hierarchical branch, thus reducing bandwidth usage over wireless. 554 2) Mobility Agent Advertisement extension advertises complete order 555 of FAs in the branch 557 In specific cases where multiple regional FA levels and multiple 558 paths from the MN to the GFA are present and are advertised, it may 559 be necessary for the MN to identify the "common route" FA using the 560 complete list of FAs in the hierarchical branch. It is assumed that 561 the GFA advertises only one care-of address on all its interfaces 562 towards the MN. 564 The MN must cache the Mobility Agent Advertisement extensions for its 565 active bindings. When it receives an advertisement from a "new" FA 566 which has a different Mobility Agent Adv. extension, it will be eager 567 to perform a new binding. The MN compares the IP addresses in the new 568 Mobility Agent Adv. extension with the ones it has cached for its 569 active binding(s). If there is an IP address in common between these 570 extensions, named "common route" FA or GFA, the MN will use that IP 571 address as HA address and destination address of its Regional 572 Registration Request in which the "S" bit will be set. The care-of 573 address is the advertising FA's address. The MN may add a 574 Hierarchical FA extension to the Regional Registration Request, in 575 order to identify the regional FA path to be followed by the Request 576 up the hierarchy. A Regional FA receiving a Regional Registration 577 Request with it's own address as HA address may return a Regional 578 Registration Reply to the MN. 580 If there is no IP address in common between the extensions, then the 581 MN must have moved into a new hierarchy and the GFA advertised in the 582 new extension must be different from the one in the previously cached 583 extension(s). When the MN moves between administrative domains (i.e. 584 changes GFA) then the MN should use the new GFA's IP address as care- 585 of address in its new Registration Request to the HA and may add the 586 Hierarchical FA extension as described previously. If the MN has at 587 least one existing active binding when it moves to the new GFA, it 588 may perform a smooth handoff as explained in section 3.4. 590 The MN is able to perform this option to implement NAMONC Handoffs 591 only if its binding lifetime with the GFA or HA does not expire 592 during the period needed by the MN to complete its handoff. 593 Intermediate regional FAs are able to accept the MN's regional 594 registration (simultaneous binding) only if the intermediate regional 595 FA has an existing active binding for the MN. The resulting 596 simultaneous binding may therefore have a maximum possible lifetime 597 equal to the lifetime remaining in its previously existing active 598 binding. Once the registration lifetime with the GFA or HA is about 599 to expire, the MN must perform a new Mobile IP registration with the 600 HA. 602 3.3 Regional Deregistration for NAMONC Handoffs 604 Regional deregistration is described in [2]. In this draft we apply 605 the deregistration procedure to NAMONC Handoffs. When the MN performs 606 a regional registration with a "new" regional FA, then a regional 607 deregistration must be performed with the MN's old location, which 608 may include all the FAs in its old regional branch. This is necessary 609 to avoid incorrect routing of packets by the "previous" FA(s) in the 610 old regional branch during the interval in which the MN has moved but 611 the "previous" FA(s)'s regional binding lifetime for the MN has not 612 yet expired. 614 The regional deregistration is performed by a regional FA upon the 615 first time it receives a valid Regional Registration Request, without 616 the "S" bit set, from a MN which had previously set the "S" bit in 617 its regional registration(s). This regional FA may respond with a 618 Registration reply and may perform the Regional deregistration by 619 sending a Binding Update with zero lifetime to the "next" regional FA 620 in the MN's old regional branch, setting the Binding Update's care-of 621 address to the the previous care-of address it had registered for the 622 MN (i.e. the "previous" lowest level FA). The Binding Update is 623 relayed down towards the previous care-of address, and each regional 624 foreign agent in the hierarchy receiving this notification removes 625 its binding for the MN. In this way, the MN updates all the Regional 626 FAs in the "old" hierarchical branch between the "common route" FA 627 and the "old" lowest level FA. It is assumed that GFA/FAs within the 628 same hierarchical domain share a Security Association which can be 629 used to perform this deregistration. 631 The MN will be able to perform regional deregistrations through 632 intermediate regional FAs if the GFA shares its GFA-MN security 633 association with the regional FAs. Otherwise the regional 634 deregistration will be performed by the GFA. 636 3.4 Smooth Handoffs between Hierarchies (GFAs) 638 When the MN moves between domains it receives Mobility Agent 639 extensions containing a new GFA IP address. The MN registers with its 640 HA using the new GFA IP address as care-of address. In order to 641 improve inter-domain handoffs it may use the Previous Foreign Agent 642 extension in the Regional Registration Request [4]. This results in a 643 smooth handoff between the domains. 645 A new flag is required in the Binding Update message to perform a 646 smooth handoff while maintaining the existing binding in the 647 "previous" FA. This is the "S" bit for the simultaneous binding. This 648 simultaneous binding is necessary in the case in which the MN only 649 momentarily moves "forward" to the new domain, then returns back to 650 the "previous" FA (domain) before its previous binding expires. In 651 this case the binding for the MN with the "previous" FA must be 652 maintained. Following is the new Binding Update message with the "S" 653 flag added which replaces one bit of the Reserved space. The "S" flag 654 is described below. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type |A|I|M|G|S| Rsv | Lifetime | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Mobile Node Home Address | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Care-of Address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | | 666 + Identification + 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Extensions ... 670 +-+-+-+-+-+-+-+- 672 S Simultaneous Bindings flag (see [1]). When set (1) it 673 indicates that this binding for the MN must be added to 674 the binding list and MUST NOT replace existing bindings 675 for that MN. 677 3.5 L2 Address Considerations for NAMONC Handoffs 679 MNs connected to networks utilising interfaces such as ethernet (e.g. 680 between FAs and wireless access points) MAY use an L2 extension to 681 the Registration messages. Such an extension is required in Ethernet- 682 based networks when the MN performing a registration with a FA which 683 is not its first-hop router needs to communicate its L2 address to 684 that FA. Therefore the FA must use the L2 address in this extension 685 to communicate with the MN instead of the L2 source address of the 686 incoming Registration Request message as specified in RFC2002. Such 687 an extension is described in section 5 of this draft. In many cases 688 wireless standards have defined special L2 interfaces to the wireless 689 network which allows these networks to resolve the mapping between MN 690 IP address and L2 address without the need to use these extensions. 691 Therefore such extensions would not be needed. 693 3.6 Advantages and Applicability of NAMONC Handoff Method 695 The NAMONC Handoff method is applicable to scenarios where Mobile IP 696 Registrations are supported by the mobile nodes and the network. This 697 method is compatible with RFC2002 and therefore is based on the same 698 security model including the use of AAA. It is assumed that FAs are 699 able to obtain L2 triggers from the wireless network which inform the 700 FA that an L2 handoff procedure is being initated for a certain MN to 701 another access point or radio network having a certain ID. The FA 702 must be able to determine the IP address of the new FA from this ID 703 using methods which may be specific to the wireless network and are 704 not considered here. If the FA determines that the ID is within its 705 coverage area then NAMONC Handoff should not be initiated. This 706 "anticipated" L2 trigger must allow enough time for the NAMONC 707 Handoff procedure to be performed. In many wireless systems the L2 708 handoff procedure involves a number of message exchanges before the 709 effective L2 handoff is performed. Therefore the NAMONC Handoff 710 method can be initiated at the beginning of the L2 handoff procedure 711 and completed before the L2 handoff is completed. It may be necessary 712 to engineer the system such that this succession of events is 713 ensured. 715 The NAMONC Handoff method provides advantages in the following cases: 717 - When the MN has locally defined policies that determine a 718 preference for one access over another (e.g. service cost) and 719 therefore where it is necessary to allow the MN to select the 720 appropriate FA to connect to. 722 - When L3 cannot rely upon L2 security (between MN and FA) to make 723 modifications to IP routing and therefore authenticated Mobile IP 724 messages are required. 726 In the first case it is necessary to involve eventual local MN 727 policies in the movement detection procedure as described in 3.2. 729 4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method 731 As discussed in the Introduction, in the Network-Assisted Handoff 732 method, the FA makes use of information from layer 2 to optimize 733 handoff by doing a fast "pre-registration" prior to the formal Mobile 734 IP registration done by the MN. The goal of the Network-Assisted 735 Handoff design is to take maximum advantage of layer 2 information 736 without specifying particular layer 2 technologies. Thus the design 737 depends on abstract L2 _triggers_ that have a very broad set of 738 characteristics exhibited by many radio layer 2 protocols. In RFC 739 2002, no assumptions are made about the existence of any layer 2 740 support for handoff. In pursuit of the lowest latency possible given 741 such layer 2 information, the Network-Assisted design proposes taking 742 maximum advantage of any layer 2 information available, and therfore 743 that RFC 2002 requires enhancement. The Network-Assisted design 744 proposes new messages that work together with standard Mobile-IP 745 handoff to reduce handoff latency. 747 In this document, we will assume that the link-layer events are 748 signaled to the Foreign Agent as "triggers". We assume that any such 749 triggers will be sufficient to derive the IP addresses of the Foreign 750 Agents that will receive or send the hand-off. If such a trigger is 751 not available or if the MN decides on its own that a hand-off is to 752 take place, then one of the FAs can often still derive the identity 753 (IP address) of the other from link-layer messages or through 754 preconfiguration. 756 In order for the Mobile IP protocol to provide low-latency hand-off, 757 the following problems must be addressed: 759 1. Reducing the latency involved in the registration process. 760 Although optimization of the Registration process is not typically 761 considered a Hand-Off problem, this proposal assumes that such a 762 mechanism is in place. 763 2. Reducing the latency involved in the Mobile Node's movement 764 detection process. 765 3. "Bi-casting" the Mobile Node's traffic to two (or more) points 766 of attachment, ensuring that the mobile's traffic is delivered as 767 soon as the link layer hand-off is completed. 768 4. Support for Reverse Tunneling, which MAY be required for private 769 addresses. 770 5. The Security Relationships between the mobility entities for 771 inter-domain hand-offs. 772 6. Does not increase mobile power consumption 774 4.1 Registration Latency 776 The Mobile IP protocol [1] requires that a Mobile Node registers with 777 a Foreign Agent, and subsequently its Home Agent, in order to have 778 its packets delivered to its current point of attachment. The Mobile 779 IP Regional Registration [2] specification proposes optimized 780 registration approaches using Gateway Foreign Agents (GFAs), which 781 are mobility agents that act as concentration points for Foreign 782 Agents within an Administrative Domain. GFAs allow a Mobile Node's 783 registration message to be processed by a Mobility Agent in the local 784 domain, eliminating the need to contact the Home Agent, which MAY be 785 topologically distant. 787 4.2 Movement Detection 789 The Mobile IP protocol [1] and the Regional Registration extension 790 [2] require Mobile Nodes to listen for, or solicit, advertisements in 791 order to detect that a movement to a new IP subnet has occurred. This 792 movement detection mechanism introduces significant latency into the 793 hand-off process, which causes service degradation, especially for 794 real-time services. Service is further impacted given the additional 795 latency introduced through the registration process that follows the 796 movement detection, since the mobile's traffic can only be delivered 797 once all of the registration has completed. 799 There have been many solutions proposed to solve this problem, 800 including increasing the advertisement frequency. In networks where 801 radio spectrum is expensive or bandwidth is limited, the additional 802 signaling required for increasing advertisement frequency is a 803 serious issue impacting deployability. 805 In this document, we propose that the Foreign Agent take a pro-active 806 approach and issue the Handoff messages on behalf of the Mobile Node 807 (acting as a surrogate of sorts). When a Foreign Agent is aware that 808 a hand-off is occurring at the link-layer, a trigger is sent to the 809 Mobile IP protocol stack. 811 +-----+ 812 | GFA | 813 +-----+ 814 ^ | 815 3. Regional | | 4. Regional 816 Reg Request | | Reg Reply 817 | v 818 +-----+ 1. Handoff Request +-----+ 819 | | -----------------> | | 820 | oFA | | nFA | 821 | | 2. Handoff Reply | | 822 +-----+ <----------------- +-----+ 824 +-----+ Movement +-----+ 825 | MN | - - - - - - - - -> | MN | 826 +-----+ +-----+ 828 Figure 3 - Source Trigger Pro-Active Handoff 830 A source trigger (see Figure 3) is one that is obtained by the old 831 Foreign Agent (oFA) once the link layer detects that the Mobile Node 832 is departing its coverage area. A target trigger (see Figure 4), on 833 the other hand, is one that is obtained by the new Foreign Agent 834 (nFA) once the link layer detects that the Mobile Node is arriving in 835 its coverage area. Note that both triggers may be available before 836 the actual completion of the link layer handoff. 838 The messages depicted in both Figures 3 and 4 are very similar. The 839 main difference is the initiator of the Handoff Request message. In 840 both examples, an optional Gateway Foreign Agent is used, which 841 requires the use of the Regional Registration messages [2]. In both 842 the source and target triggers, a Foreign Agent obtains link-layer 843 information, such as power measurements, that indicate the necessity 844 of a handoff to the new Foreign Agent. In the event of a source 845 trigger, oFA transmits a Handoff Request message to nFA. The Handoff 846 Request MUST include the Mobile Node's Home Address, Home Agent 847 Address, remaining registration lifetime, as well as the Link-Layer 848 Address Extension (see Section 5). The GFA's identity MUST also be 849 present, if one was used for the Mobile Node's registration. Upon 850 receipt of the message, nFA MUST create the Mobile Node's visitor 851 entry, and respond with the Handoff Reply message. 853 +-----+ 854 | GFA | 855 +-----+ 856 ^ | 857 3. Regional | | 4. Regional 858 Reg Request | | Reg Reply 859 | v 860 +-----+ 1. Handoff Request +-----+ 861 | | <----------------- | | 862 | oFA | | nFA | 863 | | 2. Handoff Reply | | 864 +-----+ -----------------> +-----+ 866 +-----+ Movement +-----+ 867 | MN | - - - - - - - - -> | MN | 868 +-----+ +-----+ 870 Figure 4 - Target Trigger Pro-Active Handoff 872 In target triggers, the trigger occurs on nFA, which results in the 873 transmission of a Handoff Request to oFA. The Handoff Request message 874 MUST include the Mobile Node's Link-Layer Address (see Section 5) in 875 order for oFA to correctly identify the Mobile Node. The request 876 message MAY include additional Mobile Node information, if such 877 information was provided by the link layer. Upon receipt of the 878 request, oFA MUST respond with the Handoff Reply message, which 879 includes the Mobile Node's Home Address, Home Agent Address, 880 remaining registration lifetime and Link-Layer Address Extension. If 881 a GFA was used in the Mobile Node's registration, it's address MUST 882 be supplied. Regardless of the direction of the Handoff Request, if 883 nFA receives GFA information within the message from oFA, it SHOULD 884 issue a Regional Registration Request with the GFA, which will 885 respond with the Regional Registration Reply. 887 4.3 Ping-Pong effect 889 Some link-layers are subject to rapid motion of MNs between two FAs. 890 For example, even though link-layer power measurements may indicate 891 that a hand-off is necessary, the mobile may fail to attach to the 892 new point of attachment, and return almost immediately to its old 893 point of attachment. This event is known as a "ping-pong" effect. 895 Data +-----+ Data +----+ 896 +-------------| oFA |<--------------------------| HA | 897 | +-----+ +----+ 898 v ^ | 899 +----+ Handoff | | Data 900 | MN | Request | | 901 +----+ | | 902 ^ v v 903 | +-----+ 904 +-------------| nFA | 905 Data +-----+ 907 Figure 5 - Bi-Casting by the Anchor Foreign Agent 909 Figure 5 provides an example of bi-casting a Mobile Node's through 910 both the old and new Foreign Agents. Bi-casting is established when 911 the oFA issues a successful Handoff Reply to nFA, or receives a 912 successful Handoff Reply from nFA. This causes oFA to forward all of 913 the Mobile Node's traffic to the nFA, as well as to the Mobile Node, 914 if a link-layer channel exists. 916 Figure 6 provides an example where bi-casting is performed on the 917 Gateway Foreign Agent, which is initiated by nFA setting the 'S' bit 918 (Simultaneous Binding) in the Regional Registration Request. 920 Data +-----+ Data 921 +-------------| oFA |<-------------+ 922 | +-----+ | 923 v | 924 +----+ +-----+ Data +----+ 925 | MN | | GFA |<--------| HA | 926 +----+ +-----+ +----+ 927 ^ | 928 | +-----+ | 929 +-------------| nFA |<-------------+ 930 Data +-----+ Data 932 Figure 6 - Bi-Casting by the Gateway Foreign Agent 934 When simultaneous bindings are in effect, and a ping-pong event 935 occurs, the mobile's service is guaranteed not to experience any 936 additional latency beyond that imposed by the link-layer handoff. 938 4.4 Reverse Tunneling Support 940 In the event the Mobile Node requested Reverse Tunneling [5] support, 941 by setting the 'T' bit in its Registration Request, the Handoff 942 message from oFA (see Sections 4.7 and 4.8) includes the 'T' bit 943 enabled to inform nFA to establish a bi-directional tunnel for the 944 visitor entry. 946 4.5 Security Relationships 948 The Mobile IP Regional Registration specification [2] requires that 949 the communicating Mobility Agents exchange authenticated messages. 950 This imposes a requirement for Mobility Agents to share a pre- 951 established security association. This assumption is valid for intra- 952 domain mobility (mobility within an Administrative Domain). However, 953 such a requirement introduces a scaling problem when the Mobility 954 Agents are owned by separate Administrative Domains (ADs). 956 Given that the existing AAA infrastructure is used to establish 957 dynamic security associations between Foreign and Home Agents in 958 different ADs, the same infrastructure could be used to establish the 959 required security association for the purposes of inter-domain hand- 960 offs (see Figure 7). 962 +-----+ +-----+ 963 | AAA |-------------->| AAA | 964 +-----+ +-----+ 965 ^ | 966 | | 967 | AAA | 968 | Hand-Off | 969 | Req | 970 | v 971 +-----+ +-----+ 972 | oFA | | nFA | 973 +-----+ +-----+ 975 +-----+ Movement +-----+ 976 | MN | - - - - - - > | MN | 977 +-----+ +-----+ 979 Figure 7 - Inter-FA communication using AAA 981 Note that it is possible for geographically neighboring Foreign 982 Agents owned by different Administrative Domains to have a pre- 983 established security association, which would reduce the latency 984 introduced by the AAA infrastructure traversal. Given that such 985 geographically neighboring FAs MAY be small in number, such an 986 approach MAY be reasonable. 988 4.6 Operation 990 A Foreign Agent can receive two different types of triggers informing 991 it of a handoff (The event that causes the trigger may be derived via 992 link layer messaging assistance from the network or from the mobile): 994 - a "source trigger" is when the old FA is informed of an 995 upcoming link-layer handoff, 996 - a "target trigger" occurs at the new FA when it is informed 997 that a link layer handoff is in progress. 999 The method by which such triggers occur are link-layer specific, and 1000 are outside the scope of this document. It is also possible that a 1001 particular kind of link layer technology can support both source and 1002 target triggers. 1004 4.6.1 Foreign Agent Considerations 1006 Upon receipt of a trigger event, a Foreign Agent MAY issue a Handoff 1007 request message to the Foreign Agent the mobile is being handed off 1008 to/from. If the message is the result of a target trigger, the Type 1009 Of Trigger bit MUST be set and the Link-Layer Address Extension (see 1010 Section 5) MUST be present. The message's Home Address and Home Agent 1011 Address fields MAY be set to NULL if this information is not known at 1012 the time the message is transmitted. 1014 Upon receipt of a Handoff Request message with the Type Of Trigger 1015 bit set, a Foreign Agent MUST respond with the Handoff Reply message. 1016 The Handoff Reply MUST include both the Mobile Node's Home Address 1017 and Home Agent Address in the message header. The remaining mobile's 1018 registration lifetime MUST be included in the Reply's lifetime field. 1020 Furthermore, the Foreign Agent MAY include any security associations 1021 that were dynamically created. If a Gateway Foreign Agent was used in 1022 the Mobile's registration, the GFA's identity MUST be included in the 1023 Gateway Foreign Agent Address Extension [2] MUST be present. 1025 A Foreign Agent that issues such a Handoff Reply with the Code field 1026 set to success (zero value) MUST "bi-cast" all packets destined to 1027 the Mobile Node to both the Mobile Node and to the new Foreign Agent. 1029 The Foreign Agent that receives a successful Handoff Reply message 1030 (one that includes a zero value in the Code field), a visitor entry 1031 is created with the information found in the message. The Foreign 1032 Agent MUST be prepared to deliver packets to the Mobile Node prior to 1033 receiving a Registration Request [1] from the Mobile Node. 1035 Note that it is possible for the encapsulation method used between 1036 oFA and nFA to be different from the one requested by the Mobile Node 1037 during its Registration process. When this occurs, the respective 1038 Foreign Agents MUST perform encapsulation translation. 1040 A Foreign Agent that receives a source trigger, it MUST send a 1041 Handoff Request message with the Type Of Trigger bit disabled. The 1042 message MUST also include the Mobile Node's Home Address and Home 1043 Agent Address in the message header. The remaining mobile 1044 registration lifetime MUST be included in the lifetime field. The 1045 Foreign Agent MAY also include any security associations that were 1046 dynamically created. If a Gateway Foreign Agent was used for the 1047 mobile, it's identity MUST be included in the Gateway Foreign Agent 1048 Address Extension [2]. 1050 Upon receipt of a Handoff Request with the Type Of Trigger bit 1051 disabled, a Foreign Agent MUST process the packet and respond with 1052 the Handoff Reply message. If successfully processed, the Foreign 1053 Agent MUST create a Visitor Entry for the Mobile Node, and be 1054 prepared to deliver packets received by the initiator of the Handoff 1055 Request destined for the Mobile Node. The Handoff Reply message MUST 1056 include the Home Address, Home Agent Address, lifetime value, and the 1057 Link-Layer Address Extension (see Section 5). 1059 A Foreign Agent that receives a Handoff Reply with the Code field set 1060 to success (zero value) MUST "bi-cast" all packets destined to the 1061 Mobile Node to both the Mobile Node and to the new Foreign Agent. If 1062 the message received by the new Foreign Agent contained a GFA IP 1063 Address Extension [2], and it shares a security association with the 1064 GFA, it MUST issue a Regional Registration Request to the GFA. The 1065 Regional Registration Request's Care-Of address field MUST be set to 1066 the local Foreign Agent's address, while the GFA IP Address MUST be 1067 set to the address of the recipient of the request. The request's 1068 lifetime field is set to an administratively configured value. A 1069 successful Regional Registration Reply MUST cause the Foreign Agent 1070 to create a visitor entry for the Mobile Node. 1072 If a Regional Registration Reply message is received with the code 1073 field set to DO_NOT_SERVICE_MN (Section 4.9), the Foreign Agent 1074 SHOULD NOT provide service to the Mobile Node. The Foreign Agent MAY 1075 enforce this by closing the Link-Layer connection (if possible), not 1076 issuing any Mobility Advertisements to the Mobile Node (assuming a 1077 point-to- point Link Layer), or simply denying all Registration 1078 Requests with the error code set to 65 (Administratively Prohibited) 1079 [1]. 1081 Once a visitor entry has been created, and the Mobile Node 1082 establishes a link layer channel with the Foreign Agent, its traffic 1083 will be immediately delivered, along with a Mobility Advertisement 1084 message [1]. A Mobile Node MUST issue a Registration Request when it 1085 receives a Mobility Advertisement from a new Foreign Agent. 1087 Note that Foreign Agents MAY delay in sending Mobility 1088 Advertisements, especially to reduce noticeable service disruption 1089 during a ping-pong effect. However, when doing so, the Foreign Agent 1090 MAY need to re-issue a new Handoff Request to oFA (and optionally the 1091 Regional Registration message to GFA), to extend the visitor entry's 1092 lifetime. 1094 Delaying Mobility Advertisements MAY also be done in wireless 1095 technologies that support dormant mobiles. When this is done, a 1096 Foreign Agent would typically wait to send the advertisement until 1097 the mobile is no longer in the dormant mode. When data is received by 1098 the Foreign Agent for a dormant Mobile Node, it SHOULD initiate the 1099 link-layer mechanism that causes the mobile to "wake-up" (this is 1100 typically known as paging). 1102 The above procedures require that Foreign Agents issue Handoff 1103 Requests as a result of Link-Layer triggers. However, the discovery 1104 of the identity of the Foreign Agents to which the Handoff messages 1105 must be sent is outside the scope of this document. 1107 In the event that a Foreign Agent handling a particular Mobile Node's 1108 visitor entry is soon to expire, and the Mobile Node has not yet 1109 issued a Registration Request, the FA has the option to transmit a 1110 new Handoff Request message to the old Foreign Agent (and the 1111 optional Regional Registration Request to the GFA). Whether the 1112 renewal is performed on behalf of the Mobile Node is a policy 1113 decision up to the network administrator. 1115 A Foreign Agent MAY receive packets for a Mobile Node to which it 1116 does not have a direct link layer connection. At this point, the 1117 Foreign Agent MAY: 1119 1. Drop all packets for the Mobile Node 1120 2. Buffer packets for the Mobile Node 1121 3. Attempt to establish a link-layer connection with the mobile 1122 4. Issue a Regional Registration Request with a zero lifetime 1124 Given that a Mobile Node's packets will be delivered prior to 1125 registration, a Mobile Node is free to discard all packets received 1126 from Foreign Agents with which it hasn't registered. 1128 When the new Foreign Agent receives the Mobile Node's Registration 1129 Request [1], its Anchor Foreign Agent (GFA as first-hop router) 1130 changes to the new Foreign Agent. The Foreign Agent MUST transmit a 1131 Handoff Request message to the old Foreign Agent with the lifetime 1132 field set to zero. A Foreign Agent that receives a Handoff Request 1133 with the lifetime field set to zero is being informed that it is no 1134 longer the anchor point for the mobile. It MAY issue a Handoff 1135 Request to the new Foreign Agent in the future if it wishes to keep 1136 receiving the mobile's packets for possible delivery. 1138 When a Foreign Agent determines that it is no longer servicing a 1139 Mobile Node, it SHOULD issue a Regional Registration Request message 1140 with the lifetime field set to zero (0). This will cause the visitor 1141 entry associated with the Foreign Agent's Care-Of address on the GFA 1142 to be deleted. Foreign Agents MAY decide to not issue this message 1143 immediately when a link-layer trigger is received, in order to 1144 support smooth service during a ping-pong event. 1146 4.6.2 Gateway Foreign Agent Considerations 1148 Upon receipt of a Regional Registration Request, a GFA MUST create a 1149 visitor entry indicating the Mobile Node's current point of 1150 attachment. In the event that a visitor entry already exists, the 1151 GFA SHOULD be able to create multiple visitor entries for the same 1152 Mobile Nodes with different Care-Of addresses. If the 'S' bit was 1153 enabled in the Regional Registration Request, the GFA MUST be able to 1154 forward the mobile's packets to all Foreign Agents in the visitor 1155 entries. 1157 When constructing the Regional Registration Reply, the GFA SHOULD 1158 include the FA-FA authentication extension [2], and set the lifetime 1159 field to the lesser of: 1161 1. number of seconds before the Mobile Node's Registration with 1162 its Home Agent will expire. 1163 2. The lifetime of the locally created Visitor Entry. 1165 In the event that the Regional Registration Request's lifetime field 1166 was set to zero (0), the GFA MUST remove the visitor entry associated 1167 with the Care-Of address in the message. 1169 Should the GFA decide that the Foreign Agent is not to provide 1170 service to the Mobile Node, it MUST issue a Regional Registration 1171 Reply message, with the code field set to DO_NOT_SERVICE_MN (see 1172 Section 4.9). 1174 4.7 Handoff Request Message 1176 The Handoff Request message is used to inform a peer that a pro- 1177 active handoff is being initiated. The Handoff Request message can be 1178 used for both source and target triggers, through the Type of Trigger 1179 'I' bit in the message flags. When sent as a result of a target 1180 trigger, the Home Address and Home Agent fields MAY be set to zero 1181 (unless this information was communicated by the link layer, which is 1182 outside the scope of this document). 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Type |S|x|I|M|G|r|T|x| Lifetime | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | MN Home Address | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Home Agent Address | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | | 1194 + Identification + 1195 | | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Extensions ... 1198 +-+-+-+-+-+-+-+- 1200 Type TBD (Handoff Request) 1202 S When set, and when no GFA address extension is 1203 present, it indicates that both oFA and nFA will 1204 attempt to deliver datagrams directly to MN, if 1205 a link-layer connection exists. If a GFA 1206 address extension is present, it implies that 1207 nFA should set the 'S' bit in its regional 1208 registration. 1210 I Type of Trigger. A value of zero is a source 1211 trigger (sent by oFA), while a value of one is a 1212 target trigger (sent by nFA). 1214 M, G, T As defined in [1,5]. This refers to the 1215 tunnel between oFA and nFA, or, if GFA IP 1216 address extension is present, to the parameters 1217 that should be requested in the Regional Reg 1218 Req. 1220 Lifetime The requested Lifetime for which nFA will serve 1221 the MN on behalf of oFA, without requiring a new 1222 registration. 1224 MN Home Address The home address of the mobile node. When using 1225 a private address, the G and T flags must be 1226 sent and a GRE Key extension must be included. 1228 Home Agent Addr The home agent address of the mobile node. 1230 Identification As in defined in [1]. 1232 Extensions The Message MUST include LLA (see Section 5), 1233 the FA-FA Authentication Extension [2], and MAY 1234 include GFA IP address. 1236 4.8 Handoff Reply Message 1238 The Handoff Reply message is sent in response to the Handoff Request 1239 message. When a source trigger caused the Handoff Request message to 1240 be sent, this message is sent with a successful code if the Visitor 1241 Entry was successfully created. When a target trigger caused the 1242 Handoff Request message, receipt of this message with a successfuly 1243 code SHOULD cause the Visitor Entry to be created. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Type | Code | Lifetime | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 |S|x|I|M|G|r|T|x| Reserved | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | MN Home Address | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Home Agent Address | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | | 1257 + Identification + 1258 | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Extensions ... 1261 +-+-+-+-+-+-+-+- 1263 Type TBD (Handoff Reply) 1265 Code A value indicating the result of the Handoff 1266 Request. See below for a list of currently 1267 defined Code values. 1269 Lifetime If the Code field indicates that the 1270 registration was accepted, the Lifetime field is 1271 set to the number of seconds remaining before 1272 the registration is considered expired. A value 1273 of zero indicates that the mobile node has been 1274 deregistered. A value of 0xffff indicates 1275 infinity. If the Code field indicates that the 1276 registration was denied, the contents of the 1277 Lifetime field are unspecified and MUST be 1278 ignored on reception. 1280 S When set, and when no GFA address extension is 1281 present, it indicates that both oFA and nFA will 1282 attempt to deliver datagrams directly to MN, if 1283 a link-layer connection exists. If a GFA 1284 address extension is present, it implies that 1285 nFA should set the 'S' bit in its regional 1286 registration. 1288 I Type of Trigger. A value of zero is a source 1289 trigger (sent by oFA), while a value of one is a 1290 target trigger (sent by nFA). 1292 M, G, T As defined in [1,5]. This refers to the 1293 tunnel between oFA and nFA, or, if GFA IP 1294 address extension is present, to the parameters 1295 that should be requested in the Regional Reg 1296 Req. 1298 MN Home Address The home address of the mobile node. When using 1299 a private address, the G and T flags must be 1300 sent and a GRE Key extension must be included. 1302 Home Agent Addr The home agent address of the mobile node. 1304 Lifetime The requested Lifetime for which nFA will serve 1305 the MN on behalf of oFA, without requiring a new 1306 registration. 1308 Identification As in defined in [1]. 1310 Extensions The Message MUST include LLA (see Section 5) 1311 and the FA-FA Authentication Extension [2]. 1313 4.9 Error Values 1315 The following table contains the name of Code [6] to be returned in a 1316 Registration Reply, the value for the Code, and the section in which 1317 the error is first mentioned in this specification. 1319 Error Name Value Section of Document 1320 ---------------------- ----- ------------------- 1321 DO_NOT_SERVICE_MN TBD 4.6.1 1323 4.10 Security Considerations 1325 Similar to [2], this specification assumes that the local Foreign 1326 Agent, and the GFA inherently trust each other. This MAY be achieved 1327 through the use of a long lived security association. 1329 This specification introduces a new change to Mobile IP, which is the 1330 ability for a Mobile Node to receive packets from a Foreign Agent to 1331 which it has not yet registered. In the event that the Mobile Node 1332 does not wish to receive packets from unknown Foreign Agents, it MAY 1333 drop them. 1335 Although this document does not specify how Foreign Agents can 1336 identify, or track, Mobile Nodes, it is assumed that the wireless 1337 link layer be sufficiently secure in order to correctly identify a 1338 Mobile Node. Wireless networks that do not provide such features will 1339 be subjected to impersonation attacks, where malicious nodes could 1340 cause the Foreign Agents to believe that a Mobile Node has moved to 1341 other service areas. 1343 4.11 Advantages and Applicability of NIMOT Handoff Method 1345 The NIMOT handoff approach allows foreign agents to communicate 1346 directly about a pending handoff, and does not require any IP layer 1347 messages to be sent to or from a mobile node prior to the link layer 1348 handoff event. Therefore, it does not place the mobile node's IP 1349 stack or Mobile IP client implementation on the critical path after a 1350 need for handoff is recognized but before the handoff can take place. 1351 This separation is necessary when the link layer (or the laws of 1352 physics) imposes hard deadlines on the time at which a handoff must 1353 occur, such as when a mobile node is rapidly moving out of a radio 1354 coverage area, but when the mobile node's IP stack is not implemented 1355 as a hard real-time system. 1357 Because a NIMOT handoff is triggered by some unspecified mechanism 1358 that informs the old or new foreign agent that a handoff is needed, 1359 the NIMOT approach is only applicable to networks where such a 1360 mechanism is available. For example, a link layer may provide power 1361 measurements or other indications of radio signal quality that cause 1362 the old or new foreign agent to send the NIMOT handoff messages. Any 1363 such indications must also provide each foreign agent involved in the 1364 handoff with the identity of the other, so that messages can be sent 1365 to the right place. This may involve mapping link layer information 1366 onto foreign agent identities. Also, the foreign agents involved in 1367 a handoff must have pre-provisioned security arrangements so that the 1368 NIMOT messages can be authenticated. If a handoff is to be completed 1369 as a result of the NIMOT messaging without continuing to bicast 1370 traffic to both the old and new coverage areas, then any link layer 1371 handoff indications must also be securely authenticated so that 1372 traffic to the old point of attachment is not improperly halted. 1374 5. Generalized Link Layer Address Extension 1376 This section defines the Generalized Link Layer Address (LLA) 1377 Extension, used by any that needs to communicate Link Layer 1378 Addresses. The format of the extension follows MIER [7], and each 1379 sub-type of link-layer address defines its own sub-structure. This 1380 draft defines two sub-types, the IMSI and the Ethernet Address. 1381 Future RFCs should allocate their own sub-type and define their own 1382 address formats. 1384 0 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Type | Length | Sub-Type | LLA ... 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Type 1392 TBD (skippable) [1] 1394 Length 1396 The length of the Link Layer Address + the one octet Sub-Type 1397 field 1399 Sub-Type 1401 This field contains the Link Layer sub-type identifier 1403 LLA 1405 Contains the Link Layer Address 1407 In this document, two subtypes are defined: 1409 1 International Mobile Station Identity (e.g. [8]) 1410 2 Ethernet 48 bit MAC address [9] 1411 3 64 bit Global ID, EUI-64 [10] 1413 5.1 IMSI Link Layer Address Extension 1415 The IMSI Link Layer Address Extension contains the International 1416 Mobile Station Identity. 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Type | Length | Sub-Type | IMSI ... 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Type 1425 TBD (skippable) [1] 1427 Length 1429 The length of the IMSI field + the one octet Sub-Type field 1431 Sub-Type 1433 1 1435 IMSI 1437 Contains the IMSI, in the form: 1439 : 1441 Where the is an ASCII-based representation of the 1442 International Mobile Station Identifier, most significant digit 1443 first, ":" is ASCII 0x3a, and the Connection ID is the ASCII 1444 representation of a small, decimal number used for 1445 distinguishing different link-layer connections from the same 1446 device. 1448 5.2 Ethernet Link Layer Address Extension 1450 The Ethernet Link Layer Address Extension contains the 48 bit 1451 Ethernet MAC Address, as defined in [9]. 1453 0 1 2 3 1454 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 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Type | Length | Sub-Type | MAC ... 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Type 1461 TBD (skippable) [1] 1463 Length 1465 7 (includes the Sub-Type field) 1467 Sub-Type 1469 2 1471 MAC 1472 Contains the 48 bit Ethernet MAC Address. 1474 5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension 1476 The 64-Bit Global Identifier (EUI-64) Address Extension contains the 1477 64 bit address, as defined in [10]. 1479 0 1 2 3 1480 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 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Type | Length | Sub-Type | MAC ... 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Type 1487 TBD (skippable) [1] 1489 Length 1491 7 (includes the Sub-Type field) 1493 Sub-Type 1495 3 1497 MAC 1499 Contains the 64-Bit Global Identifier Address. 1501 6. IANA Considerations 1503 The number for the Generalized Link Layer Address Extension in 1504 section 5 is taken from the numbering space defined for Mobile IP 1505 registration extensions defined in RFC 2002 [1]. These MUST NOT 1506 conflict with any numbers used in RFC 2002[1], RFC 2344 [5], RFC 2356 1507 [12], RFC 2794 [13] and RFC 3012 [11]. 1509 In the NIMOT Handoffs method, the Code values specified for errors, 1510 listed in section 4.9, MUST NOT conflict with any other code values 1511 listed in RFC 2002 [1], RFC 2344 [5], RFC 2356 [12], RFC 2794 [13] 1512 and RFC 3012 [11]. Also Sections 4.7 and 4.8 require numbers assigned 1513 from the Mobile IP control message type address space. The numbers 1514 assigned MUST NOT conflict with [1] and [2]. 1516 7. References 1518 [1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1519 1996. 1521 [2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional 1522 Tunnel Management ", draft-ietf-mobileip-reg-tunnel-03.txt 1523 (work in progress), July 2000. 1525 [3] S. Bradner. "Key words for use in RFCs to Indicate Requirement 1526 Levels". BCP 14. RFC 2119. March 1997. 1528 [4] C. Perkins and D. Johnson, "Route Optimization in Mobile 1529 IP",draft-ietf-mobileip-optim-10.txt (work in progress), 1530 November 2000. 1532 [5] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, 1533 May 1998. 1535 [6] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1536 Encapsulation (GRE). Request for Comments (Informational) 1537 1701, Internet Engineering Task Force, October 1994. 1539 [7] M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura, "Mobile IP 1540 Extensions Rationalization (MIER)", draft-ietf-mobileip-mier- 1541 05 (work in progress), Dec. 1999 1543 [8] TIA/EIA/IS-95-B 1545 [9] D. Plummer, "An Ethernet Address Resolution Protocol - or 1546 Converting Network Protocol Addresses to 48.bit Ethernet 1547 Address for Transmission on Ethernet Hardware", RFC 826, 1548 Symbolics,Inc., November 1982. 1550 [10] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1551 Registration Authority", 1552 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 1553 March 1997. 1555 [11] C. Perkins, P. Calhoun, Mobile IP Challenge/Response 1556 Extensions. RFC 3012, November 2000. 1558 [12] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal 1559 for Mobile IP", RFC 2356, June 1998. 1561 [13] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier 1562 Extension", RFC 2794, March 2000. 1564 8. Authors' Addresses 1566 The authors may be contacted at the addresses below: 1568 Karim El Malki 1569 Ericsson Radio Systems AB 1570 LM Ericssons Vag. 8 1571 126 25 Stockholm 1572 SWEDEN 1574 Phone: +46 8 7195803 1575 Fax: +46 8 7190170 1576 E-mail: Karim.El-Malki@era.ericsson.se 1578 Pat R. Calhoun 1579 Network and Security Research Center, Sun Labs 1580 Sun Microsystems, Inc. 1581 15 Network Circle 1582 Menlo Park, California, 94025 1583 USA 1585 Phone: +1 650 786 7733 1586 Fax: +1 650 786 6445 1587 E-mail: pcalhoun@eng.sun.com 1589 Tom Hiller 1590 Lucent Technologies 1591 Rm 2F-218 1592 263 Shuman Blvd 1593 Naperville, IL 60566-7050 1594 USA 1596 Phone: +1 630 979 7673 1597 Fax: +1 630 979 7673 1598 E-Mail: tom.hiller@lucent.com 1600 James Kempf 1601 Network and Security Research Center, Sun Labs 1602 Sun Microsystems, Inc. 1603 15 Network Circle 1604 Menlo Park, California, 94025 1605 USA 1607 Phone: +1 650 786 5890 1608 Fax: +1 650 786 6445 1609 E-mail: james.kempf@eng.sun.com 1610 Peter J. McCann 1611 Lucent Technologies 1612 Rm 2Z-305 1613 263 Shuman Blvd 1614 Naperville, IL 60566-7050 1615 USA 1617 Phone: +1 630 713 9359 1618 Fax: +1 630 713 4982 1619 E-Mail: mccap@lucent.com 1621 Ajoy Singh 1622 Motorola 1623 1501 West Shure Drive 1624 Arlington Heights, IL o 60004 1625 USA 1627 Phone: +1 847 632 6941 1628 E-mail: asingh1@email.mot.com 1630 Hesham Soliman 1631 Ericsson Radio Systems 1632 Torshamnsgatan 29, Kista 1633 Stockholm 1634 SWEDEN 1636 Phone: +46 8 7578162 1637 Fax: +46 8 4043630 1638 E-mail: Hesham.Soliman@era.ericsson.se 1640 Sebastian Thalanany 1641 Motorola 1642 1475 West Shure Drive 1643 Arlington Heights, IL - 60004 1644 USA 1646 Phone: +1 847 435 9296 1647 E-mail: sthalan1@email.mot.com 1649 The working group can be contacted via the current chairs: 1651 Basavaraj Patil Phil Roberts 1652 Nokia Corporation Motorola M/S M8-540 1653 6000 Connection Drive 1501 West Shure Drive 1654 Irving, TX 75039 Arlington Heights, IL 60004 1655 USA USA 1656 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1657 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 1658 Fax : +1 972-894-5349 1660 9. Full Copyright Statement 1662 Copyright (C) The Internet Society (2000). All Rights Reserved. 1664 This document and translations of it may be copied and furnished to 1665 others, and derivative works that comment on or otherwise explain it 1666 or assist in its implementation may be prepared, copied, published 1667 and distributed, in whole or in part, without restriction of any 1668 kind, provided that the above copyright notice and this paragraph are 1669 included on all such copies and derivative works. However, this 1670 document itself may not be modified in anyway, such as by removing 1671 the copyright notice or references to the Internet Society or other 1672 Internet organizations, except as needed for the purpose of 1673 developing Internet standards in which case the procedures for 1674 copyrights defined in the Internet Standards process must be 1675 followed, or as required to translate it into languages other than 1676 English. The limited permissions granted above are perpetual and will 1677 not be revoked by the Internet Society or its successors or assigns. 1678 This document and the information contained herein is provided onan 1679 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1680 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1681 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1682 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1683 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1685 Appendix A - Gateway Foreign Agents 1687 The Mobile IP Regional Registration specification [2] introduces the 1688 Gateway Foreign Agent (GFA), as a mobility agent that two Foreign 1689 Agents providing service to a Mobile Node have in common. Figure 1 1690 provides an example of a Mobile's initial registration, through the 1691 GFA. Given this is the first registration message, the message MUST 1692 be forwarded to the Home Agent. All packets destined for the mobile 1693 will be delivered to the GFA, which in turn will forward the packets 1694 to the Foreign Agent servicing the Mobile Node. 1696 Reg Req +-----+ Reg Req 1697 +----------->| oFA |--------------+ 1698 | +-----+ | 1699 | v 1700 +----+ +-----+ Reg Req +----+ 1701 | MN | | GFA |<------->| HA | 1702 +----+ +-----+ +----+ 1704 +-----+ 1705 | nFA | 1706 +-----+ 1708 Figure A.1 - Initial Registrations through GFA 1710 In the event that the mobile moves to a new Foreign Agent that is 1711 serviced by a GFA that is common with oFA, the Mobile Node MAY issue 1712 a Regional Registration Request (see Figure A.2). The Regional 1713 Registration message does not need to be forwarded to the Home Agent, 1714 since the mobile's traffic can still be delivered to the same GFA. 1715 This optimized approach effectively reduces the latency involved in 1716 the registration process. 1718 +-----+ 1719 | oFA | 1720 +-----+ 1722 +----+ +-----+ +----+ 1723 | MN | | GFA | | HA | 1724 +----+ +-----+ +----+ 1725 | ^ 1726 | +-----+ | 1727 +------------>| nFA |-------------+ 1728 Regional Reg +-----+ Regional Reg 1730 Figure A.2 - Regional Registration through GFA 1732 Note that the GFA may also be the MN's first-hop router. 1734 Appendix B - Bicasting Applicability Statement 1736 Both NAMONC and NIMOT Handoffs propose using bicasting as a technique 1737 for delivering packets to the MN through both the old and new FA. 1738 Bicasting is used in order to avoid dropping packets while the 1739 handoff is in progress and to decouple the handoff process from layer 1740 2 handoff timing. Other techniques, for example buffering, have been 1741 proposed for smooth handoff [4]. Since the interaction between TCP 1742 and bicasting has not been fully studied, bicasting should be 1743 considered only in cases where layer 2 support is available to co- 1744 ordinate handoff such that duplicate packet delivery to the MN can be 1745 reduced or avoided, until the interactions between TCP and bicasting 1746 are more clearly understood. Neither low latency handoff technique is 1747 dependent on the use of bicasting for low-loss handoffs, though a 1748 low-loss handoff technique is required for a fully seamless solution.