One document matched: draft-oneill-handoff-state-00.txt

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
                     <draft-oneill-handoff-state-00.txt>

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