Personal A. O'Neill G. Tsirtsis BT Internet Draft S. Corson Document: draft-oneill-craps-handoff-00.txt Ansible Systems Category: Informational August 2000 Expires: February 2001 Generalized IP Handoff Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes a generalized IP handoff model that supports edge mobility such as that encountered in cellular systems and Internet roaming. The model is mobile-controlled and network- constrained. The model is generic in that it permits both planned and unplanned handoff (i.e. proactive and reactive) and supports both make-before-break and break-before-make link layers. It also supports movement within and between technologies, as well as within and between domains. Finally, it is -equally applicable to routed mobility and to tunneled mobile IP-based mobility. O'Neill, Corson, Tsirtsis 1 Internet Draft Generalized IP Handoff August 2000 INDEX 1. Introduction 1.1 Inter-technology Handoff Scenario's. . . . . . . . . . . 2. The Handoff Model 2.1 Handoff Preparation--the Forward protocol. . . . . . . . 2.2 Handoff Completion--the Reverse protocol . . . . . . . . 2.3 Benefits of the Approach. . .. . . . . . . . . . . . . . 3. Legacy Handoff 4. References 1. Introduction This draft describes a generalized IP handoff model that supports edge mobility such as that encountered in cellular systems and Internet roaming. The handoff model is network-constrained/mobile- controlled. The model is generic in that it permits both planned and unplanned handoff (i.e. proactive and reactive) and supports both make-before-break and break-before-make link layers. It also supports movement within and between technologies, as well as within and between domains. Finally, it is equally applicable to routed mobility and to tunneled mobile IP-based mobility. This is necessary to ensure that intra-domain mobile routing can make use of Mobile IP services where appropriate and Mobile IP can utilize mobile routing to limit vertical and direct signalling to the Home Agent, Gateway Foreign Agent and CN's. It also enables the MN to be isolated from the mobility support deployment decisions of the domain operator. Agreement is being reached within the Mobile IP working group that a 'smooth' handoff is one that occurs without packet loss. A 'fast' handoff is one that occurs with no discernable latency. Here we define a 'seamless' handoff as one that is both smooth and fast. The generalized handoff model attempts to support seamless IP handoff. 1.1 Inter-technology Handoff Scenario's Intra-technology handoff is both well understood and already supported, especially in the case of cellular systems. A generalized IP handoff model needs to be both applicable and complementary to these systems. In addition, there are a number of scenarios in which an ISP would wish to support a planned handoff between two different access technologies, especially in the situation where the two access technologies are attached to the same ISP. In the case of a change of ISP, which equates to an inter-domain handoff, the facility is driven by the need for partnerships between single access owners to compete with the ISP with multiple access services. Here are some example scenarios to help highlight the need for the different characteristics of the handoff model advocated by this O'Neill, Corson, Tsirtsis 2 Internet Draft Generalized IP Handoff August 2000 draft. The model itself, however, is not tied to any specific scenario and is instead intended to be generic and independent from specific business cases. Residential Handoff A MN is able to access a home network and associated fixed WAN Internet access infrastructure through either an RF interface (e.g.: Bluetooth) on a mobile terminal or a network connected cradle. At the same time the MN has access to cellular resources that overlap the home network area. Preference may be given to the home resources due to the improved bandwidth, cost, performance characteristics. When moving out of range of these home resources and when subsequently returning home to those resources, the user would wish to undertake a seamless handoff to maintain application performance. In the case of a change of ISP it is likely that AAA processes, middleware-based preferences and user action would all likely be required to affect this handoff. In the case of an intra- ISP handoff, service based preferences in the network and MN will likely be sufficient. Office Handoff In this scenario, the user has desktop access to 100Mbit ethernet and in addition has an 802.11b PCMCIA card which provides access to scarcer radio resources whilst in transit or away from fixed resources. When leaving or returning to the desktop facility, the user would be necessarily plugging and unplugging the fixed ethernet connection, and the user would wish again to maintain ongoing application performance without additional activity. Again, it is clear that some user action is required but the fixed link loss should be sufficient to automatically trigger the handoff to the radio layer. Corporate Handoff This is an example of an inter-domain handoff and supports the transition between public resources and corporate resources. The MN is entering the corporate facilities and is on a call, with the service being paid for by the corporate on behalf of the user. The corporate can provide the service cheaper than the public facility so would wish to trigger a handoff when its staff are in range of corporate facilities. The handoff should be seamless if possible to avoid staff simply delaying entering the handoff area whilst on a call, and hence defeating the aim of reducing cost. Non seamless handoff may be permissible for specific applications and terminal types, particularly in exchange for better performance once the handoff has occurred. Handoff timing observation In the general case handoffs should be delayed as their occurrence increases signalling overhead. Ideally they should only be undertaken when they decrease the probability of service interruption. Thus, for example, a MN coming in range of a new AR does not mean that the MN should immediately handoff to this AR. Instead, more sophisticated policies accounting for MN-AR Signal O'Neill, Corson, Tsirtsis 3 Internet Draft Generalized IP Handoff August 2000 Interference Ratio (SIR) levels, MN QoS considerations and AR air interface loading issues should form the basis of handoff timing. In some cases "early" handoffs may be required for network efficiency reasons; in others handoff may be delayed. Equally QoS/service policy in the MN may require an early handoff to another technology as in the examples above. 2. The Handoff Model The handoff model consists of two principle mechanisms--proactive (or forward) and reactive (or reverse)--that work together to achieve seamless handoffs. The first mechanism is optional, preparatory in nature, and can be viewed as a performance optimization. It may be invoked when either the network (i.e. some notional network controller entity (NC)) or the mobile host has advance knowledge of a pending handoff. After this (and possibly without it), the reverse mechanism is invoked to complete handoff. This mechanism is always mobile-initiated. The resultant messaging sequence partially depends upon whether or not the forward mechanism has occurred. The handoff model separates the horizontal signalling (dealing with handoff) from the vertical signalling (dealing with routing) because there are substantial differences in the vertical plane between Mobile IP and intra-domain mobile (host) routing solutions, whilst there is great commonality in the horizontal plane. The horizontal plane is associated with the desire to locally support the movement of the MN between the OAR and the NAR using local authentication, temporary tunneling of packets, and the transfer of critical protocol state, to the NAR, to minimize service disruption. The vertical plane either causes a routing update which maintains the utility of the existing Care of Address (CoA) in the domain by transferring its route to the NAR, or in the case of MobileIP, the vertical plane causes a Binding Update to either the Home Agent or the Gateway Foreign Agent to bind the Home Address (HoA) to the new CoA at the NAR. Both options are generalised by the Update (UPD) and Update Acknowledge (UPDack) messages from/to the NAR. The model is network constrained, mobile controlled such that the network constrains the MN's choices for the handoff NAR, between multiple offered NAR's, with the MN being in control of the final selection. The network is viewed as providing guidance and hints to the MN as to the timing of the handoff and choices between different handoff destinations. The timing could vary between 'immediate' in the case of rapid movement / link degradation, through to 'undefined'. These hints can be triggered autonomously by network processes that track and manage resources and policies. In addition, the hints can be triggered by MN handoff requests and actions, which the network can constrain, modify and/or supplement to enable it to police and optimize system resources. O'Neill, Corson, Tsirtsis 4 Internet Draft Generalized IP Handoff August 2000 The MN must always ultimately be in control of the handoff. This is to avoid the inevitable situation in which the network cannot fully appreciate the application needs and/or personal circumstance of a user, or user process, at a given time. The user should be able to view any assistance as providing useful automation that can be overridden based on local preferences, knowledge or actions. A good example is in the case of overlapping service areas covered by multiple disconnected networks, both of which only see their own view of the situation and would wish to impose conflicting instructions to a MN. The process of constraining the timing and handoff locations should be sufficient for the network to protect and manage its resources whilst enabling the MN to recover from network control problems and to utilize facilities from multiple disconnected layer 2 networks. The full message set is shown in Figure 1. +----+ | NC | ^ | +----+ | | \ ^ (2,4)(3,5) (0)N-TIN (1)N-HD UPD UPDAck \ \ | | v \ | v +-----+ +-----+ | | ------>(3)HI/HD ----> | | | OAR | <------(2)HR <------- | NAR | |_ __| ------>(1)TIN ------> |_ __| +-----+ +-----+ | ^ ^ | | | | | | | |(0)H-TIN (1,3)|(2) | | H-HR | HH | | +----+ | | | | +---------| MN |----------+ | | +---(1)H-HD-->| |<---(4)HAck--+ | +----+<--------------+ Fig1: All messages Entities NC = Network Controller OAR = Old Access Router NAR = New Access Router MN = Mobile Node Messages TIN = Tunnel INitiation H-TIN = Host TIN H-HD = Host Handoff Denial N-TIN = Network TIN N-HD = Network Handoff Denial UPD = Update O'Neill, Corson, Tsirtsis 5 Internet Draft Generalized IP Handoff August 2000 UPDAck = UPD Ack HI = Handoff Initiation HD = Handoff Denial HH = Handoff Hint HR = Handoff Request H-HR = Host HR HAck = Handoff Ack 2.1 Handoff Preparation--the Forward protocol We assume the OAR is receiving the IP flows for delivery over the old link. The old link is used for data forwarding as long as necessary (or possible). The forward protocol is initiated by the "Tunnel INitiation" (TIN) Message and is shown in Figure 2. If mobile-initiated, the message originates at a mobile host and is called a "Host Tunnel INitiation" (H-TIN) message. If network- assisted, the message originates at a NC entity and is called a "Network Tunnel INitiation" (N-TIN) message. An H-TIN or N-TIN is sent to the OAR instructing it to prepare for possible handoff to a NAR. The message might be generated for a number of reasons, including policy, prior knowledge of movement and other parameters (outside the scope of this draft) known to the MN or NC. The OAR may deny either a H-TIN or N-TIN based on local information resulting in an optional H-HD or N-HD message back to the MN or NC, respectively. This deny is semantically equivalent to the HD message discussed later. Arrival of a H-TIN or N-TIN message at the OAR instructs it to build a temporary tunnel to the NAR for the possible forwarding of data packets during handoff. The OAR then sends a TIN message to the NAR. The TIN effectively conveys the state necessary to achieve seamless handoff to the NAR. On TIN arrival at the NAR, the NAR establishes the necessary tunnel and optional buffer state for possible reception of packets. This tunnel is used if the old link is lost in either an unpredictable or predictable manner, and therefore provides both a safety net and an IP layer make-before- break capability to supplement break-before-make link layers or user activities. The tunnel transit time and any resultant session / flow buffering at a NAR can provide additional time for the new link to be initialized. The OAR continues to deliver over the old link and may optionally forward a copy of the data via one or more virtual links to the potential NAR(s) to assist with seamlessness. The decision to forward may depend on the H/C-TIN request contents and may be modified by the OAR based on policy. Here we term the replicated delivery of packets to multiple NARs for possible forwarding to the MN as IP diversity. This differs from and should not be confused with physical radio layer "macro diversity" which is orthogonal to, but supplemented by IP diversity. O'Neill, Corson, Tsirtsis 6 Internet Draft Generalized IP Handoff August 2000 +----+ | NC | +----+ ^ \ (0)N-TIN \ \ (1)N-HD \ v +-----+ +-----+ | | | | | OAR | | NAR | |_ __| ----->(1)TIN -----> |_ __| +-----+ +-----+ | ^ | | | | |(0)H-TIN (2) | | HH | | +----+ | | +---------| MN |<-----------+ +---(1)H-HD-->+----+ Fig2: Forward Messages The NAR may send a "Handoff Hint" (HH) to the mobile if a layer 3 link to the mobile is present at the NAR. It is triggered by the TIN and therefore tells the MN that a TIN has succeeded. During movement it is possible that multiple tunnels may be built to multiple potential NARs. Some tunnels may be mobile-initiated. Others may be network-initiated. The mobile may receive multiple hints from these potential NARs that the network deems suitable for handoff. The HH is therefore sent from each NAR that the network is prepared to offer as a handoff point. In a dumb network, this set will be the same as the set of H-TINs sent by the MN because the network is unconstrained. In a 'clever' network, the set may be reduced or modified based on the networks needs. The HH may report the state of any requirements and facilities requested by the MN or advertised by the NC. HHs may therefore include performance and preference information from the network perspective to assist the MN to rank NARs. If the TIN is MN initiated, the MN may in addition provide input to this process in terms of its own preferences and priorities. A HH can indicate the status of the 'hint' that can range from mandatory/suggested/optional, and the lifetime of the handoff window during which this NAR will accept the handoff (immediate, time window). The associated processing in the MN will depend on the MN service privileges and the nature of the handoff (inter/intra domain/technology). The MN may receive mandatory immediate messages from multiple disconnected control systems with overlapping coverage which illustrates another case where the MN must be in final charge to resolve disconnects in network intelligence. O'Neill, Corson, Tsirtsis 7 Internet Draft Generalized IP Handoff August 2000 The HH also indicates whether or not replicated data is available at the NAR. If the MN requested replication and it was successful, then replicated packets may be delivered by the NAR to the MN in advance of handoff as soon as the new link is available. Alternatively it may only be forwarded after reception of the H-HR at the NAR. A HH may never arrive due to failures, such as the loss of the TIN. Therefore the MN can request handoff independently over the new link (unplanned) on receipt of periodic or locally triggered Agent Solicitation (AS), Agent Advertisement (AA), Router Solicitation (RS) and Router Advertisement (RA) messaging. If the N/C-TIN is rejected for administrative reasons, such as lack of resources, authorization or any other reason a "Network-Handoff Denial" (N-HD)or "Host-Handoff Denial" (H-HD ) message may be send back to the NC or the MN. 2.2 Handoff Completion--the Reverse protocol The mobile is ultimately responsible for completing handoff. The old link is used as long as necessary. At some time it determines it should handoff to a NAR. The timing of this decision is beyond the scope of this document but will involve both NAR and MN processes. This handoff may or may not be towards a NAR from which it has received an HH message. Clearly, the absence/suppression of an HH from a NAR may indicate that a handoff is not available to that NAR, and any handoff attempt may therefore fail. A MN should therefore prioritize NARs advertising an HH above those simply advertising asynchronous NAR advertisements. Regardless, the mobile initiates handoff by sending a "Host Handoff Request" (H-HR) to the selected NAR as shown in Figure 3. ^ | | | (4) (5) UPD UPDAck | | | v +-----+ +-----+ | | ------>(3)HI/HD ----> | | | OAR | <------(2)HR <------- | NAR | |_ __| |_ __| +-----+ +-----+ ^ | | | | | (1) |(2) H-HR | HH +----+ | | | | MN |----------+ | | | |<---(4)HAck--+ | +----+<--------------+ Fig3: Reverse Messages O'Neill, Corson, Tsirtsis 8 Internet Draft Generalized IP Handoff August 2000 On H-HR arrival at the NAR, the NAR checks to see if preparatory handoff state for the mobile is present (this may include AAA information and other handoffs-specific state sent in conjunction with tunnel establishment). If not (in the case of an unplanned handoff) a Handoff Request (HR) message is sent from the NAR to the OAR. This message likely carries the mobile's credentials to be checked at the OAR. On HR arrival at the OAR, the OAR performs an authentication check on the mobile. If everything is in order it sends a Handoff Initiation (HI) to the NAR and creates the forwarding tunnel and buffer state in both the OAR and the NAR. Otherwise it sends a Handoff Denial (HD) packet to the NAR. The information carried in a forward TIN message as well as other information not normally sent in a TIN (e.g. authorization) comes across in an HI message. On HI arrival at the NAR, the NAR declares the handoff request a success and initiates the vertical activity which may include either a MIP HoA/CoA binding update to the Home Agent/Gateway Foreign Agent or a routing update in the case of intra-domain mobile routing. Alternatively on HD arrival at the NAR, the NAR declares handoff failure. If the mobile has requested handoff notification in its HHR, the NAR then sends an HAck (or HNack) accordingly. The above unplanned handoff can be further optimized if the NAR is in a position to locally authorize and execute the handoff rather than having to query the OAR for authentication, authorization and routing/binding information. In this case the NAR can initiate the horizontal and vertical handoff activity in parallel with each other so avoiding the round trip delay to the OAR. The OAR to NAR tunnel is still useful and the completion of the horizontal phase as normal efficiently manages resources and enables the system to be resilient to vertical messaging failures and delays. In the case of a planned handoff, where a successful forward phase has previously occurred, then the tunnel and handoff state will be in place at the NAR. The mobile is therefore immediately cleared for handoff to the NAR which triggers the vertical activity, and a HAck is returned to the mobile if so requested by the mobile. In addition, the reverse protocol continues to the OAR to ensure consistent behavior and state management in all elements independent of whether the handoff is planned or unplanned. It can be seen that the de-coupling (asynchronous timing of messaging and state manipulation) of the forward and reverse phases enables the MN to recover from forward handoff messaging and network failures / delays by reverting to an unplanned handoff. The model is also resilient to vertical messaging problems as the horizontal tunnel is always installed but often never used. O'Neill, Corson, Tsirtsis 9 Internet Draft Generalized IP Handoff August 2000 2.3 Benefits of the Approach The approach permits proactively guided/constrained handoff in the forward direction. This is useful for intra-technology handoffs (e.g. cellular) where handoff planning is desired for spectrum efficiency and system load balancing. A NC element can prepare one or more NARs for handoff and signal the relative desirability of handoff to these various NARs to the mobile. Ultimately the mobile must decide to which NAR it will handoff. The network can exert additional indirect control over mobiles by denying handoffs if necessary at any time. 3G to WLAN handoff is an example of where a generalized IP handoff model must be mobile controlled. A 3G network would be unaware of the existence of the WLAN and of the mobile's desire to perform an inter-technology handoff. The mobile-controlled reverse mechanism works on failure of (or in the absence of) any preparatory forward handoff processing. Thus it provides a way for a mobile to recover from any failure of planned handoffs, and to control handoffs across technologies. This includes movement between wired and unwired technologies. Establishment of a temporary tunnel from the OAR to NAR effectively establishes a virtual link to the NAR for data forwarding. On unexpected loss of the link between the OAR and the mobile, any data packets hitting the OAR can be tunneled to the NAR for the mobile (and buffered if necessary while awaiting the mobile's arrival). This effectively permits layer 3 "make-before-break" operation over systems that operate at layer 2 in a "break-before-make" mode. This is accomplished by putting the necessary intelligence only at the edge routers, and does not rely on intelligent network elements deeper (or higher) in the network. The handoff model is orthogonal to the means by which data is routed to the mobile. Mobile IP [MobileIP], natively-routed micro-mobility [EMA-MIP,CellularIPdraft,HAWAIIdraft] or some combination of these schemes may be in use. 2.4 Mapping the Generalized Model to MobileIP The full message set suggested in this draft is shown in Figure 1 and is mapped to some existing Mobile IP draft messages in table 1. O'Neill, Corson, Tsirtsis 10 Internet Draft Generalized IP Handoff August 2000 Messages/Draft Proactive PFANE Anchor Smooth EMA:MIP TIN FBU SHPSH FBUack H-TIN FBU N-TIN FBU HH HORQ FBUack UPD RREQ RREQ BU UDU UPDAck RREP RREP BUAck UDUack HR BU RREQ SHREQ RBUack HI RREP SHREP RBUack HD SHREP RBUnack H-HR RREQ RREQ RREQ SHIN/BU RBU HAck RREP RREP RREP SHACK RBUAck Table 1: Generalized IP Handoff Mappings The original EMA handoff work, covered most recently but incompletely in the [EMA-MIP] draft reflects all the messages in the generalized handoff model. In [EMA-MIP] the MIP signalling messages are used for the horizontal tunnel, state management, authentication/authorization and error control. This is supplemented by additional piggybacked messages to convey the EMA routing update information for the mobile routing update in the vertical plane as a replacement for the vertical MIP HA/GFA binding updates and registrations. The EMA:MIP horizontal MIP messaging model uses existing MIP features in a novel way to provide a comprehensive handoff model with similarities to other MIP work. For example, the proactive [Proactive] and PFANE [PFANE] drafts have forward messaging, but lack a reverse mechanism. The anchor draft [Anchor] has reverse messaging, but lacks a forward component. The recent smooth draft [Smooth] has adopted both components, but still lacks explicit forward messages from the host or NC to initiate handoff, as well as a message acting as a hint for the mobile to handoff. The smooth draft also has a different method of signaling interaction with the NAR, preferring IPv6 tunnels over the IPv6 Routing Option approach used in [EMA:MIP]. Further exploration of this difference is required to establish the preferred method given ALL requirements. Table 1 only reflects recent Mobile IP handoff drafts similar to the generalized model. Others diverge somewhat from the generalized model. For instance, the fast handoffs draft [FastHandoffs] has the MN register with the NAR via the OAR which is acknowledged via the OAR as opposed to the NAR in our model. This may be a useful optimization in break before make link layers which do not have a L2 make before break signaling plane (which is not the case in most cellular systems). Other drafts diverge more significantly from this generalized model but the reasons for this divergence is unclear. O'Neill, Corson, Tsirtsis 11 Internet Draft Generalized IP Handoff August 2000 3. Legacy Handoff Legacy (cellular) networks support a network controlled handoff model. This model assumes a relatively "dumb" MN that has no control over the handoff process and which may, at most, assist in the handoff procedure. The NC always knows which is the next appropriate NAR for the MN. In the model described here, to support such mobiles, the NC can send a N-TIN to the OAR as shown in Figure 4. The OAR then sends the TIN to the NAR and sets-up the temporary tunnel for the MN. The TIN also carries AAA info for the MN so the NAR does not have to authenticate the MN. The NAR sends an HH to the MN indicating a mandatory handoff and effectively changes the state of the MN so that it is now attached to the NAR. In some cases, IP connectivity between the MN and the NAR has not yet established, in which case the HH might be send from the OAR over the existing link. At the same time the NAR can send the UPD in the network to appropriately reconfigure the routing. This approach may be useful for very small and unintelligent devices and is supported by the generalized handoff model. +----+ | NC | ^ | +----+ | | \ (2,4)(3,5) (0)N-TIN UPD UPDAck \ | | \ | v +-----+ +-----+ | | | | | OAR | | NAR | |_ __| ------>(1)TIN ------> |_ __| +-----+ +-----+ | | | | (1) (2) HH HH | +----+ | +--------->| MN | | +----+<------------+ Fig4: Legacy handoff support O'Neill, Corson, Tsirtsis 12 Internet Draft Generalized IP Handoff August 2000 4. References [Anchor] G. Dommety, T. Ye, "Local and Indirect Registration for Anchoring Handoffs", draft-dommety-mobileip-anchor-handoff-01.txt, July 2000. [EMA-MIP] A. O'Neill, S. Corson, G. Tsirtsis, "EMA Enhanced Mobile IPv6/IPv4", Internet-Draft,draft-oneill-ema-mip-00.txt, July 2000. [CellularIPdraft] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi and A.Valko, "Cellular IP", Internet-Draft (work in progress), draft- valko-cellularip-01.txt, October 1999. [FastHandoffs] K. El Malki, H. Soliman, "Fast Handoffs in Mobile IPv4", draft-elmalki-mobileip-fast-handoffs-02.txt, July 2000. [HAWAIIdraft] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.Salgarelli, ``IP micro-mobility support using HAWAII," Internet- Draft (work in progress), draft-ietf-mobileip-hawaii-00.txt, June 1999. [MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002, Oct 1996. [PFANE] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", draft-ietf-mobileip-optim-09.txt, February 2000. [Proactive] J. Kempf, P. Calhoun, "Foreign Agent Assisted Hand-off", draft-calhoun-mobileip-proactive-fa-00.txt, January 2000. [Smooth] R. Koodli, C.E. Perkins, " A Framework for Smooth Handovers with Mobile IPv6", draft-ietf-koodli-smoothv6-00.txt, July 2000. Author's Addresses Alan O'Neill BT (+44) 1473-646459 alan.w.oneill@bt.com M. Scott Corson University of Maryland Ansible Systems (+1) 301-405-6630 corson@isr.umd.edu George Tsirtsis BT (+44) 020 88260073 O'Neill, Corson, Tsirtsis 13 Internet Draft Generalized IP Handoff August 2000 george.tsirtsis@bt.com gtsirt@hotmail.com O'Neill, Corson, Tsirtsis 14 Internet Draft Generalized IP Handoff August 2000 Copyright Notice Placeholder for ISOC copyright. O'Neill, Corson, Tsirtsis 15