Personal A. O'Neill G. Tsirtsis BT Internet Draft S. Corson Document: draft-oneill-handoff-state-00.txt Ansible Systems Category: Informational August 2000 Expires : February 2001 State transfer between Access Routes during 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 aims to document an issue raised in the Mobile IP working group related to fast handoff between Access Routers. The fast handoff work aims to rapidly enable IP service at the new access router. In Mobile IP this implies that Binding Updates at the network layer enable forwarding of packets to the new access router. However, it may also imply other network layer activities because the IP service given to the MN may depend on state which is presently located in the old access router. This draft aims to document the issue through examples so that the IETF can resolve how to approach this issue. INDEX 1. Introduction 2. State Examples 3. Conclusion O'Neill, Corson, Tsirtsis 1 Internet Draft State Transfer during Handoff August 2000 1. Introduction This draft aims to document an issue raised in the Mobile IP working group related to fast handoff between Access Routers. The fast handoff work aims to rapidly enable IP service at the new access router. In Mobile IP this implies that Binding Updates at the network layer enable forwarding of packets to the new access router (NAR). However, it may also imply other network layer activities because the IP service given to the MN may depend on state which is presently located in the old access router (OAR). This draft aims to document the issue through examples so that the IETF can resolve how to approach this issue. In many cases it may be perfectly acceptable for a MN to simply restart its sessions/protocols after handoff. However, a number of specific protocols that directly affect application performance will need to be maintained by immediately transferring the associated state to the new AR (seamless handoff). There are then a number of ways in which this could be achieved: a) the transfer may be possible using the protocol responsible for the state (eg RSVP updates the Int-serv state) b) the state could be transferred by the handoff protocol such as Mobile IP c) the state could be initialised by the MN using a tunnel to the NAR via the old link before handoff. d) a specialised protocol(s) could be designed to transmit the state. In many cases the protocol responsible for the state may not be suitable for a number of reasons (end-points, reliability, speed, security models etc). Using the handoff protocol seems poor because of the risk of loading the handoff protocol messages with significant data, and the handoff protocol designers would unlikely be experts in the protocol state to transfer. On the other hand it is clear that the handoff messages need to act as a trigger for the transfer so that it is timely. In addition, the handoff/mobility protocol can assist in securing the transfer given the essential security association that needs to be in place to secure the handoff. Finally, there may well be state which is essential to the correct and timely configuration of the new link which should probably be included in the handoff messaging. In the case of MN initiated handoff, the MN may have the opportunity to tunnel to the NAR and have sufficient time to initialise the required state at the NAR for the new link before handoff. The model implies that the MN sends the handoff request via the old link and receives a response over either link. The MN sends IGMP, RSVP etc updates in advance of the move over the tunnel to install the state in the NAR. This also enables the MN to investigate the service capabilities at a NAR before finally moving and could be used to O'Neill, Corson, Tsirtsis 2 Internet Draft State Transfer during Handoff August 2000 select from multiple NAR options. The clear problem with this approach though is that the timers associated with such protocols may be too large for seamless handoff to be possible in specific cellular systems for example. Therefore, a special meeting of the handoff draft authors recommended that the design and utilization of a specialised inter- AR handoff data transfer protocol may therefore be required. The timing of such transfers, should be triggered by the handoff signalling and the requested protocol elements could be configured by the MN, and constrained by the network, to meet their respective needs. The benefits and consequences of these data transfers on user performance is unclear as it will not be possible to instantaneously install and synchronize this protocol state. Prior negotiation of handoff-related capabilities between adjacent handoff neighboring access routers can significantly reduce the latency of such transfers (e.g. having pre-established security associations between handoff peer ARs). This would require a second protocol (occurring in the background) enabling inter-AR capability exchange. The next section provides a list of example protocol state that might be transferred which is by no means exhaustive. 2.1 Compressor State Header compression over the radio link necessarily implies synchronised state in the MN and AR. Movement to a new AR would then require a return to uncompressed headers to build the compressor state at the NAR which may affect seamlessness. The alternative would be to forward the compressor state from the OAR to the NAR during handoff. 2.2 IGMP IP multicast uses a group membership protocol which interacts with multicast routing to maintain the multicast tree. The IGMP messaging and associated multicast routing may not be sufficiently fast to provide seamless handoff of multicast applications. One way to speed this up would be to transfer IGMP and FIB state to the new AR and to immediately trigger core multicast routing updates. Checks need to be made on the multicast group scope and to deal with multi-homing and diversity (bicasting etc) during handoff. 2.3 Diff-serv Diff-serv aims to provide useful services to a MN through the marking, and differentiated treatment of IP packets in routers. Diff-serv places the onus on the network to police, account, and potentially mark incoming and outgoing diff-serv packets according to a diff-serv profile. This profile and the above data is typically O'Neill, Corson, Tsirtsis 3 Internet Draft State Transfer during Handoff August 2000 located in the Access Router at the border of the domain although diff-serv marking can be undertaken by the MN. This profile will typically be delivered by a QoS policy or signalling protocol such as COPS, RAP or RSVP, or may in addition by delivered through the AAA process. Seamless handoff may require the policer and marker profile to be transferred across to protect network resources, other users traffic, and to correctly mark the traffic of this user. It may also be required to transfer dynamic diff-serv state (policer/meter) to avoid transients in the users QoS or network usage. 2.4 Int-serv Integrated Services uses RSVP signalling to install specific per user state (which can be aggregated in specific cases) on the routed path from a traffic source towards that user. Each RSVP router has parameters installed which enable it to recognise and treat the packets of the user according to the requested service profile. The OAR which is on the path for both the received and sourced user traffic may therefore have Int-serv and RSVP data which needs to transferred across to the NAR. The soft-state nature of RSVP enables the host to instead potentially refresh the state at the NAR up to the cross-over router which is on the path to both OAR and NAR and would be required to be triggered by the handoff. Alternatively, the RSVP state could be immediately transferred across and then simply refreshed as normal by the MN RSVP state machine. In the case of both RSVP and diff-serv it is also clear that the MN could use a third model in which the MN includes the QoS profile in the handoff request so that the network can constrain subsequent handoff hints to NARs that can meet that QoS profile. 2.5 AAA The AAA profile is typically returned to the AR following exhaustive and secure AAA processes. These processes may be fully invoked on session start-up but should be minimized during handoff. One way to minimize is to transfer specific state between the OAR and NAR where the two share a security association, and the AAA parameters are agnostic to the specific AR. It would therefore be expected that session keys, accounting profile and dynamic firewall configuration should be transferred across. 2.6 IPSEC Gateway State In the case of network based security, where the ISP locates an IPSEC gateway at the AR, then the security state in the gateway must move to the NAR so that packets can be correctly authenticated, rejected and decrypted for the user. In addition, this movement is also required to ensure that outgoing packets are correctly processed. The timescales associated with renegotiation of security parameters using IKE would be too large to achieve seamless handoff and secure SA transfer may be possible. O'Neill, Corson, Tsirtsis 4 Internet Draft State Transfer during Handoff August 2000 2.7 Non Network layer State It is assumed for the purposes of this draft that higher state would not be located in the OAR and would not be required to be transferred for seamless handoff. 3. Conclusion There appears to be additional work required at the network layer for seamless handoff that is probably out of scope of the Mobile IP working group. The chairs have requested input on this issue from the working group and the consensus view of the handoff team is that this may be a suitable task for another working group, with the support of the working groups responsible for the specific protocol state which is deemed to be important for seamless handoff. The implications of this issue may well be that specific state needs to migrate to to the MN instead of existing in stateful access routers. This implies adoption of the SIM model from the cellular world, where mobile internet devices have secure and hardware/software into which user specific network state can be delivered and maintained during handoff. 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 george.tsirtsis@bt.com gtsirt@hotmail.com Copyright Notice Placeholder for ISOC copyright. O'Neill, Corson, Tsirtsis 5