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