idnits 2.17.1 draft-oneill-craps-handoff-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 Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 886 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 198 has weird spacing: '...ork can const...' -- 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 (August 2000) is 8645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-dommety-mobileip-anchor-handoff-01 == Outdated reference: A later version (-03) exists of draft-elmalki-mobileip-fast-handoffs-02 == Outdated reference: A later version (-01) exists of draft-ietf-mobileip-hawaii-00 ** Obsolete normative reference: RFC 2002 (ref. 'MobileIP') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-09 == Outdated reference: A later version (-03) exists of draft-calhoun-mobileip-proactive-fa-00 -- No information found for draft-ietf-koodli-smoothv6 - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 G. Tsirtsis 3 BT 4 Internet Draft S. Corson 5 Document: draft-oneill-craps-handoff-00.txt Ansible Systems 6 Category: Informational August 2000 7 Expires: February 2001 9 Generalized IP Handoff 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft describes a generalized IP handoff model that supports 34 edge mobility such as that encountered in cellular systems and 35 Internet roaming. The model is mobile-controlled and network- 36 constrained. The model is generic in that it permits both planned 37 and unplanned handoff (i.e. proactive and reactive) and supports 38 both make-before-break and break-before-make link layers. It also 39 supports movement within and between technologies, as well as within 40 and between domains. Finally, it is -equally applicable to routed 41 mobility and to tunneled mobile IP-based mobility. 43 O'Neill, Corson, Tsirtsis 1 44 INDEX 46 1. Introduction 47 1.1 Inter-technology Handoff Scenario's. . . . . . . . . . . 48 2. The Handoff Model 49 2.1 Handoff Preparation--the Forward protocol. . . . . . . . 50 2.2 Handoff Completion--the Reverse protocol . . . . . . . . 51 2.3 Benefits of the Approach. . .. . . . . . . . . . . . . . 52 3. Legacy Handoff 53 4. References 55 1. Introduction 57 This draft describes a generalized IP handoff model that supports 58 edge mobility such as that encountered in cellular systems and 59 Internet roaming. The handoff model is network-constrained/mobile- 60 controlled. The model is generic in that it permits both planned 61 and unplanned handoff (i.e. proactive and reactive) and supports 62 both make-before-break and break-before-make link layers. It also 63 supports movement within and between technologies, as well as within 64 and between domains. Finally, it is equally applicable to routed 65 mobility and to tunneled mobile IP-based mobility. This is necessary 66 to ensure that intra-domain mobile routing can make use of Mobile IP 67 services where appropriate and Mobile IP can utilize mobile routing 68 to limit vertical and direct signalling to the Home Agent, Gateway 69 Foreign Agent and CN's. It also enables the MN to be isolated from 70 the mobility support deployment decisions of the domain operator. 72 Agreement is being reached within the Mobile IP working group that a 73 'smooth' handoff is one that occurs without packet loss. A 'fast' 74 handoff is one that occurs with no discernable latency. Here we 75 define a 'seamless' handoff as one that is both smooth and fast. The 76 generalized handoff model attempts to support seamless IP handoff. 78 1.1 Inter-technology Handoff Scenario's 80 Intra-technology handoff is both well understood and already 81 supported, especially in the case of cellular systems. A generalized 82 IP handoff model needs to be both applicable and complementary to 83 these systems. In addition, there are a number of scenarios in which 84 an ISP would wish to support a planned handoff between two different 85 access technologies, especially in the situation where the two 86 access technologies are attached to the same ISP. In the case of a 87 change of ISP, which equates to an inter-domain handoff, the 88 facility is driven by the need for partnerships between single 89 access owners to compete with the ISP with multiple access services. 91 Here are some example scenarios to help highlight the need for the 92 different characteristics of the handoff model advocated by this 94 O'Neill, Corson, Tsirtsis 2 95 draft. The model itself, however, is not tied to any specific 96 scenario and is instead intended to be generic and independent from 97 specific business cases. 99 Residential Handoff 100 A MN is able to access a home network and associated fixed WAN 101 Internet access infrastructure through either an RF interface 102 (e.g.: Bluetooth) on a mobile terminal or a network connected 103 cradle. At the same time the MN has access to cellular resources 104 that overlap the home network area. Preference may be given to the 105 home resources due to the improved bandwidth, cost, performance 106 characteristics. When moving out of range of these home resources 107 and when subsequently returning home to those resources, the user 108 would wish to undertake a seamless handoff to maintain application 109 performance. In the case of a change of ISP it is likely that AAA 110 processes, middleware-based preferences and user action would all 111 likely be required to affect this handoff. In the case of an intra- 112 ISP handoff, service based preferences in the network and MN will 113 likely be sufficient. 115 Office Handoff 116 In this scenario, the user has desktop access to 100Mbit ethernet 117 and in addition has an 802.11b PCMCIA card which provides access to 118 scarcer radio resources whilst in transit or away from fixed 119 resources. When leaving or returning to the desktop facility, the 120 user would be necessarily plugging and unplugging the fixed ethernet 121 connection, and the user would wish again to maintain ongoing 122 application performance without additional activity. Again, it is 123 clear that some user action is required but the fixed link loss 124 should be sufficient to automatically trigger the handoff to the 125 radio layer. 127 Corporate Handoff 128 This is an example of an inter-domain handoff and supports the 129 transition between public resources and corporate resources. The MN 130 is entering the corporate facilities and is on a call, with the 131 service being paid for by the corporate on behalf of the user. The 132 corporate can provide the service cheaper than the public facility 133 so would wish to trigger a handoff when its staff are in range of 134 corporate facilities. The handoff should be seamless if possible to 135 avoid staff simply delaying entering the handoff area whilst on a 136 call, and hence defeating the aim of reducing cost. Non seamless 137 handoff may be permissible for specific applications and terminal 138 types, particularly in exchange for better performance once the 139 handoff has occurred. 141 Handoff timing observation 142 In the general case handoffs should be delayed as their occurrence 143 increases signalling overhead. Ideally they should only be 144 undertaken when they decrease the probability of service 145 interruption. Thus, for example, a MN coming in range of a new AR 146 does not mean that the MN should immediately handoff to this AR. 147 Instead, more sophisticated policies accounting for MN-AR Signal 149 O'Neill, Corson, Tsirtsis 3 150 Interference Ratio (SIR) levels, MN QoS considerations and AR air 151 interface loading issues should form the basis of handoff timing. In 152 some cases "early" handoffs may be required for network efficiency 153 reasons; in others handoff may be delayed. Equally QoS/service 154 policy in the MN may require an early handoff to another technology 155 as in the examples above. 157 2. The Handoff Model 159 The handoff model consists of two principle mechanisms--proactive 160 (or forward) and reactive (or reverse)--that work together to 161 achieve seamless handoffs. The first mechanism is optional, 162 preparatory in nature, and can be viewed as a performance 163 optimization. It may be invoked when either the network (i.e. some 164 notional network controller entity (NC)) or the mobile host has 165 advance knowledge of a pending handoff. After this (and possibly 166 without it), the reverse mechanism is invoked to complete handoff. 167 This mechanism is always mobile-initiated. The resultant messaging 168 sequence partially depends upon whether or not the forward mechanism 169 has occurred. 171 The handoff model separates the horizontal signalling (dealing with 172 handoff) from the vertical signalling (dealing with routing) because 173 there are substantial differences in the vertical plane between 174 Mobile IP and intra-domain mobile (host) routing solutions, whilst 175 there is great commonality in the horizontal plane. The horizontal 176 plane is associated with the desire to locally support the movement 177 of the MN between the OAR and the NAR using local authentication, 178 temporary tunneling of packets, and the transfer of critical 179 protocol state, to the NAR, to minimize service disruption. The 180 vertical plane either causes a routing update which maintains the 181 utility of the existing Care of Address (CoA) in the domain by 182 transferring its route to the NAR, or in the case of MobileIP, the 183 vertical plane causes a Binding Update to either the Home Agent or 184 the Gateway Foreign Agent to bind the Home Address (HoA) to the new 185 CoA at the NAR. Both options are generalised by the Update (UPD) and 186 Update Acknowledge (UPDack) messages from/to the NAR. 188 The model is network constrained, mobile controlled such that the 189 network constrains the MN's choices for the handoff NAR, between 190 multiple offered NAR's, with the MN being in control of the final 191 selection. The network is viewed as providing guidance and hints to 192 the MN as to the timing of the handoff and choices between different 193 handoff destinations. The timing could vary between 'immediate' in 194 the case of rapid movement / link degradation, through to 195 'undefined'. These hints can be triggered autonomously by network 196 processes that track and manage resources and policies. In addition, 197 the hints can be triggered by MN handoff requests and actions, which 198 the network can constrain, modify and/or supplement to enable it 199 to police and optimize system resources. 201 O'Neill, Corson, Tsirtsis 4 202 The MN must always ultimately be in control of the handoff. This is 203 to avoid the inevitable situation in which the network cannot fully 204 appreciate the application needs and/or personal circumstance of a 205 user, or user process, at a given time. The user should be able to 206 view any assistance as providing useful automation that can be 207 overridden based on local preferences, knowledge or actions. A good 208 example is in the case of overlapping service areas covered by 209 multiple disconnected networks, both of which only see their own 210 view of the situation and would wish to impose conflicting 211 instructions to a MN. The process of constraining the timing and 212 handoff locations should be sufficient for the network to protect 213 and manage its resources whilst enabling the MN to recover from 214 network control problems and to utilize facilities from multiple 215 disconnected layer 2 networks. 217 The full message set is shown in Figure 1. 219 +----+ 220 | NC | ^ | 221 +----+ | | 222 \ ^ (2,4)(3,5) 223 (0)N-TIN (1)N-HD UPD UPDAck 224 \ \ | | 225 v \ | v 226 +-----+ +-----+ 227 | | ------>(3)HI/HD ----> | | 228 | OAR | <------(2)HR <------- | NAR | 229 |_ __| ------>(1)TIN ------> |_ __| 230 +-----+ +-----+ 231 | ^ ^ | | 232 | | | | | 233 |(0)H-TIN (1,3)|(2) 234 | | H-HR | HH 235 | | +----+ | | | 236 | +---------| MN |----------+ | | 237 +---(1)H-HD-->| |<---(4)HAck--+ | 238 +----+<--------------+ 239 Fig1: All messages 241 Entities 242 NC = Network Controller 243 OAR = Old Access Router 244 NAR = New Access Router 245 MN = Mobile Node 247 Messages 248 TIN = Tunnel INitiation 249 H-TIN = Host TIN 250 H-HD = Host Handoff Denial 251 N-TIN = Network TIN 252 N-HD = Network Handoff Denial 253 UPD = Update 255 O'Neill, Corson, Tsirtsis 5 256 UPDAck = UPD Ack 257 HI = Handoff Initiation 258 HD = Handoff Denial 259 HH = Handoff Hint 260 HR = Handoff Request 261 H-HR = Host HR 262 HAck = Handoff Ack 264 2.1 Handoff Preparation--the Forward protocol 266 We assume the OAR is receiving the IP flows for delivery over the 267 old link. The old link is used for data forwarding as long as 268 necessary (or possible). The forward protocol is initiated by the 269 "Tunnel INitiation" (TIN) Message and is shown in Figure 2. If 270 mobile-initiated, the message originates at a mobile host and is 271 called a "Host Tunnel INitiation" (H-TIN) message. If network- 272 assisted, the message originates at a NC entity and is called a 273 "Network Tunnel INitiation" (N-TIN) message. An H-TIN or N-TIN is 274 sent to the OAR instructing it to prepare for possible handoff to a 275 NAR. The message might be generated for a number of reasons, 276 including policy, prior knowledge of movement and other parameters 277 (outside the scope of this draft) known to the MN or NC. The OAR may 278 deny either a H-TIN or N-TIN based on local information resulting in 279 an optional H-HD or N-HD message back to the MN or NC, respectively. 280 This deny is semantically equivalent to the HD message discussed 281 later. 283 Arrival of a H-TIN or N-TIN message at the OAR instructs it to build 284 a temporary tunnel to the NAR for the possible forwarding of data 285 packets during handoff. The OAR then sends a TIN message to the 286 NAR. The TIN effectively conveys the state necessary to achieve 287 seamless handoff to the NAR. On TIN arrival at the NAR, the NAR 288 establishes the necessary tunnel and optional buffer state for 289 possible reception of packets. This tunnel is used if the old link 290 is lost in either an unpredictable or predictable manner, and 291 therefore provides both a safety net and an IP layer make-before- 292 break capability to supplement break-before-make link layers or user 293 activities. The tunnel transit time and any resultant session / flow 294 buffering at a NAR can provide additional time for the new link to 295 be initialized. 297 The OAR continues to deliver over the old link and may optionally 298 forward a copy of the data via one or more virtual links to the 299 potential NAR(s) to assist with seamlessness. The decision to 300 forward may depend on the H/C-TIN request contents and may be 301 modified by the OAR based on policy. Here we term the replicated 302 delivery of packets to multiple NARs for possible forwarding to the 303 MN as IP diversity. This differs from and should not be confused 304 with physical radio layer "macro diversity" which is orthogonal to, 305 but supplemented by IP diversity. 307 O'Neill, Corson, Tsirtsis 6 308 +----+ 309 | NC | 310 +----+ 311 ^ \ 312 (0)N-TIN \ 313 \ (1)N-HD 314 \ v 315 +-----+ +-----+ 316 | | | | 317 | OAR | | NAR | 318 |_ __| ----->(1)TIN -----> |_ __| 319 +-----+ +-----+ 320 | ^ | 321 | | | 322 |(0)H-TIN (2) 323 | | HH 324 | | +----+ | 325 | +---------| MN |<-----------+ 326 +---(1)H-HD-->+----+ 328 Fig2: Forward Messages 330 The NAR may send a "Handoff Hint" (HH) to the mobile if a layer 3 331 link to the mobile is present at the NAR. It is triggered by the TIN 332 and therefore tells the MN that a TIN has succeeded. During movement 333 it is possible that multiple tunnels may be built to multiple 334 potential NARs. Some tunnels may be mobile-initiated. Others may 335 be network-initiated. The mobile may receive multiple hints from 336 these potential NARs that the network deems suitable for handoff. 337 The HH is therefore sent from each NAR that the network is prepared 338 to offer as a handoff point. In a dumb network, this set will be the 339 same as the set of H-TINs sent by the MN because the network is 340 unconstrained. In a 'clever' network, the set may be reduced or 341 modified based on the networks needs. 343 The HH may report the state of any requirements and facilities 344 requested by the MN or advertised by the NC. HHs may therefore 345 include performance and preference information from the network 346 perspective to assist the MN to rank NARs. If the TIN is MN 347 initiated, the MN may in addition provide input to this process in 348 terms of its own preferences and priorities. 350 A HH can indicate the status of the 'hint' that can range from 351 mandatory/suggested/optional, and the lifetime of the handoff window 352 during which this NAR will accept the handoff (immediate, time 353 window). The associated processing in the MN will depend on the MN 354 service privileges and the nature of the handoff (inter/intra 355 domain/technology). The MN may receive mandatory immediate messages 356 from multiple disconnected control systems with overlapping coverage 357 which illustrates another case where the MN must be in final charge 358 to resolve disconnects in network intelligence. 360 O'Neill, Corson, Tsirtsis 7 361 The HH also indicates whether or not replicated data is available at 362 the NAR. If the MN requested replication and it was successful, then 363 replicated packets may be delivered by the NAR to the MN in advance 364 of handoff as soon as the new link is available. Alternatively it 365 may only be forwarded after reception of the H-HR at the NAR. 367 A HH may never arrive due to failures, such as the loss of the TIN. 368 Therefore the MN can request handoff independently over the new link 369 (unplanned) on receipt of periodic or locally triggered Agent 370 Solicitation (AS), Agent Advertisement (AA), Router Solicitation 371 (RS) and Router Advertisement (RA) messaging. 373 If the N/C-TIN is rejected for administrative reasons, such as lack 374 of resources, authorization or any other reason a "Network-Handoff 375 Denial" (N-HD)or "Host-Handoff Denial" (H-HD ) message may be send 376 back to the NC or the MN. 378 2.2 Handoff Completion--the Reverse protocol 380 The mobile is ultimately responsible for completing handoff. The old 381 link is used as long as necessary. At some time it determines it 382 should handoff to a NAR. The timing of this decision is beyond the 383 scope of this document but will involve both NAR and MN processes. 384 This handoff may or may not be towards a NAR from which it has 385 received an HH message. Clearly, the absence/suppression of an HH 386 from a NAR may indicate that a handoff is not available to that NAR, 387 and any handoff attempt may therefore fail. A MN should therefore 388 prioritize NARs advertising an HH above those simply advertising 389 asynchronous NAR advertisements. Regardless, the mobile initiates 390 handoff by sending a "Host Handoff Request" (H-HR) to the selected 391 NAR as shown in Figure 3. 393 ^ | 394 | | 395 (4) (5) 396 UPD UPDAck 397 | | 398 | v 399 +-----+ +-----+ 400 | | ------>(3)HI/HD ----> | | 401 | OAR | <------(2)HR <------- | NAR | 402 |_ __| |_ __| 403 +-----+ +-----+ 404 ^ | | 405 | | | 406 (1) |(2) 407 H-HR | HH 408 +----+ | | | 409 | MN |----------+ | | 410 | |<---(4)HAck--+ | 411 +----+<--------------+ 413 Fig3: Reverse Messages 415 O'Neill, Corson, Tsirtsis 8 416 On H-HR arrival at the NAR, the NAR checks to see if preparatory 417 handoff state for the mobile is present (this may include AAA 418 information and other handoffs-specific state sent in conjunction 419 with tunnel establishment). If not (in the case of an unplanned 420 handoff) a Handoff Request (HR) message is sent from the NAR to the 421 OAR. This message likely carries the mobile's credentials to be 422 checked at the OAR. 424 On HR arrival at the OAR, the OAR performs an authentication check 425 on the mobile. If everything is in order it sends a Handoff 426 Initiation (HI) to the NAR and creates the forwarding tunnel and 427 buffer state in both the OAR and the NAR. Otherwise it sends a 428 Handoff Denial (HD) packet to the NAR. The information carried in a 429 forward TIN message as well as other information not normally sent 430 in a TIN (e.g. authorization) comes across in an HI message. 432 On HI arrival at the NAR, the NAR declares the handoff request a 433 success and initiates the vertical activity which may include either 434 a MIP HoA/CoA binding update to the Home Agent/Gateway Foreign Agent 435 or a routing update in the case of intra-domain mobile routing. 436 Alternatively on HD arrival at the NAR, the NAR declares handoff 437 failure. If the mobile has requested handoff notification in its 438 HHR, the NAR then sends an HAck (or HNack) accordingly. 440 The above unplanned handoff can be further optimized if the NAR is 441 in a position to locally authorize and execute the handoff rather 442 than having to query the OAR for authentication, authorization and 443 routing/binding information. In this case the NAR can initiate the 444 horizontal and vertical handoff activity in parallel with each other 445 so avoiding the round trip delay to the OAR. The OAR to NAR tunnel 446 is still useful and the completion of the horizontal phase as normal 447 efficiently manages resources and enables the system to be resilient 448 to vertical messaging failures and delays. 450 In the case of a planned handoff, where a successful forward phase 451 has previously occurred, then the tunnel and handoff state will be 452 in place at the NAR. The mobile is therefore immediately cleared for 453 handoff to the NAR which triggers the vertical activity, and a HAck 454 is returned to the mobile if so requested by the mobile. In 455 addition, the reverse protocol continues to the OAR to ensure 456 consistent behavior and state management in all elements independent 457 of whether the handoff is planned or unplanned. 459 It can be seen that the de-coupling (asynchronous timing of 460 messaging and state manipulation) of the forward and reverse phases 461 enables the MN to recover from forward handoff messaging and network 462 failures / delays by reverting to an unplanned handoff. The model is 463 also resilient to vertical messaging problems as the horizontal 464 tunnel is always installed but often never used. 466 O'Neill, Corson, Tsirtsis 9 467 2.3 Benefits of the Approach 469 The approach permits proactively guided/constrained handoff in the 470 forward direction. This is useful for intra-technology handoffs 471 (e.g. cellular) where handoff planning is desired for spectrum 472 efficiency and system load balancing. A NC element can prepare one 473 or more NARs for handoff and signal the relative desirability of 474 handoff to these various NARs to the mobile. Ultimately the mobile 475 must decide to which NAR it will handoff. The network can exert 476 additional indirect control over mobiles by denying handoffs if 477 necessary at any time. 479 3G to WLAN handoff is an example of where a generalized IP handoff 480 model must be mobile controlled. A 3G network would be unaware of 481 the existence of the WLAN and of the mobile's desire to perform an 482 inter-technology handoff. 484 The mobile-controlled reverse mechanism works on failure of (or in 485 the absence of) any preparatory forward handoff processing. Thus it 486 provides a way for a mobile to recover from any failure of planned 487 handoffs, and to control handoffs across technologies. This 488 includes movement between wired and unwired technologies. 490 Establishment of a temporary tunnel from the OAR to NAR effectively 491 establishes a virtual link to the NAR for data forwarding. On 492 unexpected loss of the link between the OAR and the mobile, any data 493 packets hitting the OAR can be tunneled to the NAR for the mobile 494 (and buffered if necessary while awaiting the mobile's arrival). 495 This effectively permits layer 3 "make-before-break" operation over 496 systems that operate at layer 2 in a "break-before-make" mode. This 497 is accomplished by putting the necessary intelligence only at the 498 edge routers, and does not rely on intelligent network elements 499 deeper (or higher) in the network. 501 The handoff model is orthogonal to the means by which data is routed 502 to the mobile. Mobile IP [MobileIP], natively-routed micro-mobility 503 [EMA-MIP,CellularIPdraft,HAWAIIdraft] or some combination of these 504 schemes may be in use. 506 2.4 Mapping the Generalized Model to MobileIP 508 The full message set suggested in this draft is shown in Figure 1 509 and is mapped to some existing Mobile IP draft messages in table 1. 511 O'Neill, Corson, Tsirtsis 10 512 Messages/Draft Proactive PFANE Anchor Smooth EMA:MIP 513 TIN FBU SHPSH FBUack 514 H-TIN FBU 515 N-TIN FBU 516 HH HORQ FBUack 517 UPD RREQ RREQ BU UDU 518 UPDAck RREP RREP BUAck UDUack 519 HR BU RREQ SHREQ RBUack 520 HI RREP SHREP RBUack 521 HD SHREP RBUnack 522 H-HR RREQ RREQ RREQ SHIN/BU RBU 523 HAck RREP RREP RREP SHACK RBUAck 525 Table 1: Generalized IP Handoff Mappings 527 The original EMA handoff work, covered most recently but 528 incompletely in the [EMA-MIP] draft reflects all the messages in the 529 generalized handoff model. In [EMA-MIP] the MIP signalling messages 530 are used for the horizontal tunnel, state management, 531 authentication/authorization and error control. This is supplemented 532 by additional piggybacked messages to convey the EMA routing update 533 information for the mobile routing update in the vertical plane as a 534 replacement for the vertical MIP HA/GFA binding updates and 535 registrations. The EMA:MIP horizontal MIP messaging model uses 536 existing MIP features in a novel way to provide a comprehensive 537 handoff model with similarities to other MIP work. For example, the 538 proactive [Proactive] and PFANE [PFANE] drafts have forward 539 messaging, but lack a reverse mechanism. The anchor draft [Anchor] 540 has reverse messaging, but lacks a forward component. The recent 541 smooth draft [Smooth] has adopted both components, but still lacks 542 explicit forward messages from the host or NC to initiate handoff, 543 as well as a message acting as a hint for the mobile to handoff. 545 The smooth draft also has a different method of signaling 546 interaction with the NAR, preferring IPv6 tunnels over the IPv6 547 Routing Option approach used in [EMA:MIP]. Further exploration of 548 this difference is required to establish the preferred method given 549 ALL requirements. Table 1 only reflects recent Mobile IP handoff 550 drafts similar to the generalized model. Others diverge somewhat 551 from the generalized model. For instance, the fast handoffs draft 552 [FastHandoffs] has the MN register with the NAR via the OAR which is 553 acknowledged via the OAR as opposed to the NAR in our model. This 554 may be a useful optimization in break before make link layers which 555 do not have a L2 make before break signaling plane (which is not the 556 case in most cellular systems). Other drafts diverge more 557 significantly from this generalized model but the reasons for this 558 divergence is unclear. 560 O'Neill, Corson, Tsirtsis 11 561 3. Legacy Handoff 563 Legacy (cellular) networks support a network controlled handoff 564 model. This model assumes a relatively "dumb" MN that has no control 565 over the handoff process and which may, at most, assist in the 566 handoff procedure. The NC always knows which is the next appropriate 567 NAR for the MN. 569 In the model described here, to support such mobiles, the NC can 570 send a N-TIN to the OAR as shown in Figure 4. The OAR then sends the 571 TIN to the NAR and sets-up the temporary tunnel for the MN. The TIN 572 also carries AAA info for the MN so the NAR does not have to 573 authenticate the MN. The NAR sends an HH to the MN indicating a 574 mandatory handoff and effectively changes the state of the MN so 575 that it is now attached to the NAR. In some cases, IP connectivity 576 between the MN and the NAR has not yet established, in which case 577 the HH might be send from the OAR over the existing link. At the 578 same time the NAR can send the UPD in the network to appropriately 579 reconfigure the routing. This approach may be useful for very small 580 and unintelligent devices and is supported by the generalized 581 handoff model. 583 +----+ 584 | NC | ^ | 585 +----+ | | 586 \ (2,4)(3,5) 587 (0)N-TIN UPD UPDAck 588 \ | | 589 \ | v 590 +-----+ +-----+ 591 | | | | 592 | OAR | | NAR | 593 |_ __| ------>(1)TIN ------> |_ __| 594 +-----+ +-----+ 595 | | 596 | | 597 (1) (2) 598 HH HH 599 | +----+ | 600 +--------->| MN | | 601 +----+<------------+ 603 Fig4: Legacy handoff support 605 O'Neill, Corson, Tsirtsis 12 606 4. References 608 [Anchor] G. Dommety, T. Ye, "Local and Indirect Registration for 609 Anchoring Handoffs", draft-dommety-mobileip-anchor-handoff-01.txt, 610 July 2000. 612 [EMA-MIP] A. O'Neill, S. Corson, G. Tsirtsis, "EMA Enhanced Mobile 613 IPv6/IPv4", Internet-Draft,draft-oneill-ema-mip-00.txt, July 2000. 615 [CellularIPdraft] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi and 616 A.Valko, "Cellular IP", Internet-Draft (work in progress), draft- 617 valko-cellularip-01.txt, October 1999. 619 [FastHandoffs] K. El Malki, H. Soliman, "Fast Handoffs in Mobile 620 IPv4", draft-elmalki-mobileip-fast-handoffs-02.txt, July 2000. 622 [HAWAIIdraft] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and 623 L.Salgarelli, ``IP micro-mobility support using HAWAII," Internet- 624 Draft (work in progress), draft-ietf-mobileip-hawaii-00.txt, June 625 1999. 627 [MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002, 628 Oct 1996. 630 [PFANE] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 631 draft-ietf-mobileip-optim-09.txt, February 2000. 633 [Proactive] J. Kempf, P. Calhoun, "Foreign Agent Assisted Hand-off", 634 draft-calhoun-mobileip-proactive-fa-00.txt, January 2000. 636 [Smooth] R. Koodli, C.E. Perkins, " A Framework for Smooth Handovers 637 with Mobile IPv6", draft-ietf-koodli-smoothv6-00.txt, July 2000. 639 Author's Addresses 641 Alan O'Neill 642 BT 643 (+44) 1473-646459 644 alan.w.oneill@bt.com 646 M. Scott Corson 647 University of Maryland 648 Ansible Systems 649 (+1) 301-405-6630 650 corson@isr.umd.edu 652 George Tsirtsis 653 BT 654 (+44) 020 88260073 656 O'Neill, Corson, Tsirtsis 13 657 george.tsirtsis@bt.com 658 gtsirt@hotmail.com 660 O'Neill, Corson, Tsirtsis 14 661 Copyright Notice 663 Placeholder for ISOC copyright. 665 O'Neill, Corson, Tsirtsis 15