MOBILE-IP Working Group Karim El Malki, Ericsson
INTERNET-DRAFT Hesham Soliman, Ericsson
Expires: March 2001 Sept 27, 2000
Fast Handoffs in Mobile IPv4
draft-elmalki-mobileip-fast-handoffs-03.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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This draft describes a method to achieve Fast Handoffs in Mobile
IPv4. Fast Handoffs are required in Mobile IPv4 in order to limit the
period of service disruption experienced by a wireless Mobile Node
when moving between Foreign Agents. This requirement becomes even
more important when supporting real-time services. Fast Handoffs
involve anticipating the movement of MNs by sending multiple copies
of the traffic to potential Mobile Node movement locations (i.e. FAs).
Both a flat and a Hierarchical Mobile IPv4 model are considered. The
Hierarchical MIPv4 model in Regional Tunnel Management [1] already
offers improvements to Mobile IP handoffs by providing local Home
Agent functionality. Some additions are made to the operation of this
existing Hierarchical model to achieve Fast Handoffs and limit or
avoid triangle routing within the hierarchical domain.
Karim El Malki and Hesham Soliman [Page 1]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
TABLE OF CONTENTS
1. Introduction..................................................2
2. Fast Handoffs.................................................4
2.1 Initiating Fast Handoffs through the "previous" FA............5
3. Hierarchical Mobile IPv4 Network..............................6
4. Fast Handoffs in Hierarchical MIPv4...........................8
5. Traffic Routing in Mobile IPv4 Hierarchies...................10
6. Regional Deregistration for Fast Handoffs....................12
7. Smooth Handoffs between Hierarchies (GFAs)...................12
8. L2 address considerations for Fast Handoffs..................13
9. IPv6 Considerations..........................................13
10. Security Considerations......................................13
11. Acknowledgements.............................................14
12. References...................................................14
13. Addresses....................................................14
1. Introduction
Fast Handoffs anticipate the movement of wireless Mobile Nodes (MNs)
by utilizing simultaneous bindings in order to send multiple copies
of the traffic to potential Mobile Node movement locations. In this
way, Fast Handoffs coupled to layer 2 mobility can help in achieving
seamless handoffs between Foreign Agents by eliminating the delay
period required to perform a Registration following a Mobile IP
handoff (i.e. following a handoff between subnets/FAs).
An alternative method to perform improved handoffs, namely Smooth
Handoffs, is described in [3]. The method for Fast Handoffs addresses
the need to support services having strict delay bounds
(i.e. real-time) which in certain cases may be hard to support if
traffic has to be forwarded between FAs using Smooth Handoffs. Also,
in the non-realtime case it may be possible that the new FA receives
both buffered traffic from the previous FA (smooth handoff) and
traffic from the HA which could cause some out-of-order and delayed
packets to be delivered to the MN. In some cases this may affect the
performance of higher level protocols (e.g. TCP). This same situation
will not arise using Fast Handoffs.
Karim El Malki and Hesham Soliman [Page 2]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
This draft considers both the normal Mobile IP model [2] and the
hierarchical Mobile IP model [1]. These are shown in Figure 1 where
the Access Points (APs) or Radio Access Networks (RANs) are used to
provide a MN with wireless L2 access.
Simultaneous bindings are described in [2] and may be achieved by
setting the "S" bit in the Mobile IP Registration Request message
sent by the MN. In this way, the receiving agent (HA, GFA or
Regional FA) will add a new binding for the MN without removing any
which are existing and have not expired.
_________ _________
| | | |
| HA |--------| (GFA) |________
|_________| |_________| \
/ | \ \
\
... ... ... \
\
______/_ _\______ |
| | | | |
| FA2 | | FA1 | |
|________| |________| |
____|___ ____|___ ____|___
| | | | | |
|AP/RAN 2| |AP/RAN 1| |AP/RAN 3|
|________| |________| |________|
| ____|___
| |
CN | MN |
|________|
Figure 1: Flat (HA only) and Hierarchical (HA and GFA) MIPv4 model
Fast Handoffs may be applied to normal Mobile IP by performing
registrations with the HA using simultaneous bindings. This is
described in [2] and the method to anticipate MN movement by
interacting with the wireless L2 is described later in this draft.
However, having multiple simultaneous bindings for MNs at the
HA will cause the HA to send multiple copies of data packets towards
mutliple FAs which may be in the same region or domain. In terms of
bandwidth usage this would not be efficient unless the HA is close
to the FAs in question, but this is not always the case. Also, if the
round-trip time between HA and FAs is not negligible this may slow
down the MN's new Registration and therefore the Mobile IP handoff.
The Hierarchical MIPv4 model addresses these problems.
Karim El Malki and Hesham Soliman [Page 3]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
The Hierarchical Mobile IPv4 scheme introduced in Regional Tunnel
Management [1] allows a Mobile Node to perform registrations locally
with a Gateway Foreign Agent (GFA) in order to reduce the number of
signalling messages to the home network. This achieves a reduction in
the signalling delay when a Mobile Node moves between Foreign Agents
and therefore improves the performance of such handoffs. This draft
describes Fast Handoffs in Hierarchical Mobile IPv4 using Regional
Registrations [1] and provides a method to avoid or minimise triangle
routing within the hierarchical domain. As for Mobile IPv4,
hierarchical networks utilizing Regional Tunnel management will
suffer from triangle routing. The worst case will involve
communication between Mobile Nodes connected to the same Foreign
Agent, or to any other Foreign Agent within the same hierarchy, since
packets will be routed through the respective home networks. In this
draft, triangle routing between nodes within the hierarchical domain
is eliminated by direct routing through Regional Foreign Agents (i.e.
FA2 and FA1 in Fig. 1) or alternatively reduced by routing through
the Gateway Foreign Agent (GFA).
This draft is applicable to multi-level Hierarchical Mobile IPv4
(HMIPv4) networks. HMIPv4 networks utilizing Regional Tunnel
Management with Fast Handoffs and local routing optimizations offer
advantages which are especially important for the support of
real-time services.
2. Fast Handoffs
Fast Handoffs address the need to achieve seamless Mobile IP
Handoffs when the MN moves between FAs. This is done by "bicasting"
traffic to the "previous" FA and "new" FA while the MN is moving
between them. The anticipation of the MN's movement is achieved by
tight coupling with Layer 2 functionality which is dependent on the
type of access technology used. "Bicasting" is achieved through
simultaneous bindings, where the MN activates the "S" bit in the
Registration Request. When a Registration Request has the "S" bit
set, the receiving HA, which has an existing binding for the MN,
will add the relevant new binding for the MN but will also maintain
any other existing bindings it had for the MN. Similarly, in HMIPv4,
when a Regional Registration Request has the "S" bit set, the
receiving FA/HA or GFA which has an existing binding with the MN
will add the relevant new binding for the MN but will also maintain
any other existing bindings it had for the MN.
When the MN has multiple active bindings with FAs, it may or may not
receive multiple copies of the same traffic directed to it. The use
of simultaneous bindings does not necessarily mean that the MN is
receiving packets contemporarily from multiple sources. This depends
on the characteristics of the access (L2) technology. The "bicasting"
of packets is used to anticipate the MN's movement and speed up
Karim El Malki and Hesham Soliman [Page 4]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
handoffs by sending a copy of the data to the FA which the MN is
moving to. Until the MN actually completes the L2 handoff to the new
FA, the data "copy" reaching this FA may be discarded. In this way
the total handoff delay is limited to the time needed to perform the
L2 handoff. Thus, Fast Handoffs coupled to the L2 access potentially
result in loss-less IP-layer mobility. As described in 2.1, depending
on the L2 characteristics, it is also possible for an MN to initiate
a Fast Handoff through the "previous" FA without having direct access
to the "new" FA.
2.1 Initiating Fast Handoffs through the "previous" FA
In the case in which the wireless L2 technology allows the MN to be
data-connected to multiple wireless access points simultaneously, the
MN may solicit advertisements from FAs before completing handoffs. In
this case "bicasting" may not be necessary.
Some existing wireless L2 technologies and their implementations do
not allow a MN to be data-connected to multiple wireless access
points simultaneously. Thus, in order to perform a Fast Handoff it
is necessary for some form of interworking between layers 2 and 3.
It should be noted that the method by which an FA determines when a
MN has initiated an L2 handoff is outside the scope of this draft
and may involve interaction with L2 messaging. Also, the interaction
between L2 and L3 (on the network side and/or MN-side) should allow
the Mobile Node to perform a L2 handoff only after having performed
the L3 Fast Handoff described in this draft. That is, the L2 handoff
may be performed after the MN's Registration with the "new" FA which
produces a simultaneous binding at the GFA/HA. This Registration may
be transmitted more than once to reduce the probability that it is
lost due to errors on the wireless link.
A Fast Handoff in this case requires the MN to receive "new" agent
advertisements through the "old" wireless access points, and to
perform a registration with the "new" FA through the "old" wireless
access point. Two ways of performing this follow.
I. Inter-FA Solicitation
This solution assumes that the FA with which the MN is currently
registered is aware of the IP address of the "new" FA which the MN is
moving to. The method by which the current FA is informed of this may
depend on interaction with L2 and is outside the scope of this draft.
Once the current FA is aware of the address of the FA which the MN
will move to, it will send the "new" FA an agent solicitation
message. The "new" FA will reply to the current FA by sending it an
Karim El Malki and Hesham Soliman [Page 5]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
agent advertisement with appropriate extensions. The current FA will
then send the agent advertisement to the MN's address. As a
consequence, the MN, being eager to perform new registrations, will
send a registration request to the "new" FA through the
"old" wireless access point served by the current FA.
II. Piggy-backing Advertisements on L2 messaging
Let us take Figure 1 as an example, where a MN initiates an L2
handoff from AP/RAN1 to AP/RAN2 (Note that it may not be the MN which
takes decisions on handoffs). It is assumed that when an L2 handoff
is initiated, AP/RAN1 and AP/RAN2 perform L2 messaging procedures to
negotiate the L2 handoff. Since the MN is not attached to AP/RAN2
yet, FA2 is unaware of the IP address of the MN and cannot send an
advertisement to it. Therefore it is necessary for the L2 procedures
(which must be common to AP/RAN1 and AP/RAN2) to interwork with
Mobile IP.
Once a L2 handoff is initiated, such that AP/RAN2 and AP/RAN1 are in
communication, it is possible for AP/RAN2 to solicit an advertisement
from FA2 and transfer it to AP/RAN1. Once this is received by the MN,
the MN can perform a registration directed to FA2 even though the MN has
no data-connection to AP/RAN2 yet.
The precise definition of such L2 procedures is outside the scope of
Mobile IP.
3. Hierarchical Mobile IPV4 Network
The Regional Tunnel Management draft [1] describes a two-level Mobile
IPv4 hierarchy (i.e. GFA and one level of FAs). In [1] Annex A
briefly describes the possibility of having multiple FA levels. In
the generic case, there may be multiple levels of FAs and one (or
more) "root" GFA within an administrative domain. The procedures
described in this draft do not limit the number of hierarchical
levels of FAs. In addition, a MN may be attached directly to any FA
within the hierarchy and may move between FAs from different levels
in the hierarchy. Figure 2 describes the Hierarchical MIPv4 network.
In Figure 2, Access Points (APs) or Radio Access Networks (RANs)
consisting of multiple access points, are used to provide a MN with
L2 access. These may be connected at any level of the hierarchy as
shown in the figure. It is important to note that there may be
multiple paths between a MN and the GFA (Gateway Foreign Agent).
FA1 and FA2 will be referred to as the lowest level regional FAs in
the hierarchy. Also, the "common route" regional FA is defined as
the first regional FA in common for the route of communication
between hosts connected to regional FAs. In Figure 2, FA3 is the
Karim El Malki and Hesham Soliman [Page 6]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
"common route" regional FA for communication between a host connected
to FA2 (i.e. CN) and a host connected to FA1 (i.e. MN). A regional FA
found in a hierarchical level between the GFA and the lowest level
FAs will be referred to as an intermediate regional FA.
________ ________
| | | |
| AAAL |------| GFA |______________________
|________| |________| \
/ | \ \
... ... ... \
____|___ \
| | \
| FA3 |_______________ \
|________| | |
______/_ _\______ | |
| | | | | |
| FA2 | | FA1 | | |
|________| |________| | |
____|___ ____|___ ____|___ ____|___
| | | | | | | |
|AP/RAN 2| |AP/RAN 1| |AP/RAN 3| |AP/RAN 4|
|________| |________| |________| |________|
| ____|___
CN | |
| MN |
|________|
Figure 2: A Multi-level Hierarchical MIPv4 domain
As described in [1], a regional FA announces itself and its GFA in
the Agent Advertisement; in the first and last address in the
care-of address field in the Mobility Agent Advertisement extension
[2]. If there is a hierarchy of foreign agents between the GFA and
the announcing foreign agent, the foreign agent MAY include the
corresponding addresses in order between its own address (first) and
the GFA address (last). For example, in Figure 2, FA1 MAY advertise
in the order: FA1, FA3 .. GFA.
This draft supplements [1] with the following for MIPv4:
- limitation of triangle routing for communication between hosts
within the administrative domain
- Fast Handoffs within the administrative domain
- Considerations on Regional Deregistration
Regional Tunnel Management allows Regional Registrations within an
administrative domain in order to avoid always having to perform
registrations through the Home Agent, which is often distant from the
Karim El Malki and Hesham Soliman [Page 7]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
Mobile Node's current location. However, it is also part of Regional
Tunnel Management that the Mobile Node's registration with the Home
Agent be renewed before its expiry. Therefore it is assumed that the
MN will send one or more Registrations (using the GFA address as
care-of address) to the Home Agent before the MN's Registration
lifetime with the Home Agent expires. As specified in Regional
Tunnel Management, the GFA's address always appears to the Home
Agent as the Mobile Node's care-of address. In this way, some of the
Home Agent's functionality is performed locally in the GFA. It is
assumed in this draft and in [1] that regional FAs and the GFA share
a common security association.
4. Fast Handoffs in Hierarchical MIPv4
When there is a hierarchy of foreign agents between the GFA and the
announcing foreign agent, the announcing foreign agent MAY include
the corresponding addresses in order between its own address (first)
and the GFA address (last) in the Mobility Agent Advertisement
extension of its Agent Advertisements. If there are only two
hierarchical levels, a foreign agent announces itself and a GFA in
the Agent Advertisement; in the first and last address in the
care-of address field in the Mobility Agent Advertisement extension.
There must be at least one care-of address in the Mobility Agent
Advertisement extension. If there is only one care-of address it
is the address of the GFA, and the MN is connected directly to it.
When the MN receives an Agent Advertisement with a Mobility Agent
extension and the "I" bit set, as specified in [1], it should perform
actions according to the following movement detection mechanisms. In
a Hierarchical Mobile IP network such as the one described in this
draft, the MN MUST be:
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
The above means that the MN will perform Regional Registrations with
any "new" FA from which it receives an advertisement (Eager). The
method by which the MN determines whether the FA is a "new" FA is
described in [2] and may make use of an FA-NAI extension. However
the MN should not release existing bindings until it no longer
receives advertisement from the relative FA and the lifetime of
its existing binding expires (Lazy).
It should be noted that the MN may add a Hierarchical FA extension
to Registration Requests in order to identify the exact FA path to
be followed by the Registration Request. This extension must not be
removed by regional FAs.
If the MN has at least one existing binding with a FA, additional
Karim El Malki and Hesham Soliman [Page 8]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
simultaneous regional registrations will be performed requesting a
short lifetime. This is done in order to limit the lifetime of
bindings which the MN only needs temporarily and therefore limit
bandwidth usage. This is the case when the MN is moving between FAs
and uses Fast Handoffs to achieve loss-less IP mobility. The
lifetime of additional "auxiliary" bindings needed for Fast Handoffs
is thus limited.
The remaining issue is the choice of the appropriate HA address in
the Regional Registration Request when the MN has at least an
existing active regional binding. Two options follow:
1) Mobility Agent extension advertises FA and GFA address only
In this case it is assumed that there is always a single path from
the MN to the GFA. The MN will always perform Regional Registrations
using the GFA address as HA address and the advertising FA as
care-of address. As the Regional Registration Request is relayed
towards the GFA, each FA receiving it will check whether it has an
existing binding with the MN and whether the Regional Registration
has the "S" bit set to request for simultaneous bindings. If this is
true and the Regional Registration is validated by the GFA, these FAs
will activate the simultaneous binding upon receiving the
(successful) Regional Registration Reply from the GFA. Therefore it
is not necessary to advertise to the MN all of the FA addresses in
the hierarchical branch, thus reducing bandwidth usage over wireless.
2) Mobility Agent Advertisement extension advertises complete order
of FAs in the branch
In specific cases where multiple regional FA levels and multiple
paths from the MN to the GFA are present and are advertised, it
may be necessary for the MN to identify the "common route" FA
using the complete list of FAs in the hierarchical branch. It is
assumed that the GFA advertises only one care-of address on all its
interfaces towards the MN.
The MN must cache the Mobility Agent Advertisement extensions for
its active bindings. When it receives an advertisement from a "new"
FA which has a different Mobility Agent Adv. extension, it will be
eager to perform a new binding. The MN compares the IP addresses in
the new Mobility Agent Adv. extension with the ones it has cached
for its active binding(s). If there is an IP address in common
between these extensions, named "common route" FA or GFA, the MN
will use that IP address as HA address and destination address of its
Regional Registration Request in which the "S" bit will be set. The
care-of address is the advertising FA's address. The MN may add a
Hierarchical FA extension to the Regional Registration Request, in
Karim El Malki and Hesham Soliman [Page 9]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
order to identify the regional FA path to be followed by the Request
up the hierarchy. A Regional FA receiving a Regional Registration
Request with it's own address as HA address may return a Regional
Registration Reply to the MN.
If there is no IP address in common between the extensions, then the
MN must have moved into a new hierarchy and the GFA advertised in the
new extension must be different from the one in the previously cached
extension(s). When the MN moves between administrative domains (i.e.
changes GFA) then the MN should use the new GFA's IP address as
care-of address in its new Registration Request to the HA and may add
the Hierarchical FA extension as described previously. If the MN has
at least one existing active binding when it moves to the new GFA, it
may perform a smooth handoff as explained in section 6.
The MN is able to perform this option to implement Fast Handoffs only
if its binding lifetime with the GFA or HA does not expire during the
period needed by the MN to complete its handoff. Intermediate
regional FAs are able to accept the MN's regional registration
(simultaneous binding) only if the intermediate regional FA has an
existing active binding for the MN. The resulting simultaneous
binding may therefore have a maximum possible lifetime equal to the
lifetime remaining in its previously existing active binding. Once
the registration lifetime with the GFA or HA is about to expire, the
MN must perform a new Mobile IP registration with the HA.
5. Traffic Routing in Mobile IPv4 Hierarchies
The GFA and intermediate regional FAs will hold a binding for a
registered MN to the "next" FA in the hierarchical branch towards
the MN. The Regional Registration Requests (and Regional Registration
Replies if the MN includes the Hierarchical Foreign Agent extension
in its Regional Registration Request) containing the Hierarchical
Foreign Agent extension [1] will allow a hop-by-hop route along this
branch to be created within the hierarchy for the MN. This procedure
is specified in [1]. The complete order of FAs in the branch MAY be
advertised to the MN in the Mobility Agent Advertisement extension.
In this case the Hierarchical Foreign Agent extension MAY be present
also in the Regional Registration Reply received by the intermediate
regional FAs in the branch and the MN, although the order of the
addresses is inverted with respect to that in the Regional
Registration Request.
If the packets for the MN are tunnelled from the HA, then the GFA
should change the source and destination IP address of the
encapsulating header to the "next" FA towards the MN. The "next" FA
may be the lowest level FA. The same procedure will be performed by
intermediate regional FAs if any are present. When packets reach the
Karim El Malki and Hesham Soliman [Page 10]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
lowest level FA they will be detunnelled and sent to the MN.
Otherwise, if the regional FAs or GFA receive packets for MNs which
are not tunnelled (i.e. sent by other hosts within the hierarchy),
then routing between MNs in the same hierarchy (or between any host
in the hierarchy and a MN in the same hierarchy) may be performed:
- through the Home Agent
- through the GFA
- through any regional FA (including the GFA)
In order to reduce triangle routing and the associated unnecessary
latency and tunnelling overhead for communication between hosts
within the same administrative domain, it is preferred to route using
the last two options, namely through the GFA or through any regional
FA. As an example of routing through any regional FA, in Figure 2 the
path of communication between the CN and the MN would go through FA2,
FA3 and FA1.
The most efficient routing is using the shortest path through any
regional FA. However the decision on which option to adopt depends on
the particular implementation and deployment. These two methods will
be described in the following sections.
I. Routing between nodes only through the GFA
Routing between MNs (or between a fixed host and a MN) in the same
hierarchy may be performed through the GFA. The GFA does this by
tunnelling packets for a MN to the appropriate "next" FA using the
information it has for the MN in its Regional binding. Therefore,
packets generated within the hierarchical domain and directed to
the MN's home address reach the GFA and are tunnelled by the GFA
to the "next" regional FA. Following this, the same hierarchical
routing procedure described previously for traffic coming from the
HA applies.
II. Routing between the nodes through any regional FA (shortest path)
Routing between MNs (or between a fixed host and a MN) in the same
hierarchy may be performed through any regional FA in the hierarchy.
Any number of levels of regional FAs may be present in the hierarchy.
Packets sent between MNs in the same hierarchy will be routed through
the shortest path of connected FAs in the hierarchy. This shortest
path goes through the closest regional FA that is able to
interconnect the nodes: the "common route" regional FA. In Figure 2,
this is FA3. It is possible that the closest regional FA able to
interconnect the nodes is the GFA.
If the regional FAs or GFA receives packets for the MN which are not
tunnelled (i.e. sent by other hosts within the hierarchy) then
Karim El Malki and Hesham Soliman [Page 11]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
routing will be performed using any existing active regional bindings
by tunnelling packets to the "next" regional FA towards the MN.
Following this, the same hierarchical routing procedure described
previously for traffic coming from the HA applies.
6. Regional Deregistration for Fast Handoffs
Regional deregistration is described in [1]. In this draft we apply
the deregistration procedure to Fast Handoffs. When the MN performs
a regional registration with a "new" regional FA, then a regional
deregistration must be performed with the MN's old location,
which may include all the FAs in its old regional branch. This is
necessary to avoid incorrect routing of packets (see section 3) by
the "previous" FA(s) in the old regional branch during the interval
in which the MN has moved but the "previous" FA(s)'s regional binding
lifetime for the MN has not yet expired.
The regional deregistration is performed by a regional FA upon the
first time it receives a valid Regional Registration Request, without
the "S" bit set, from a MN which had previously set the "S" bit in
its regional registration(s). This regional FA may respond with
a Registration reply and may perform the Regional deregistration by
sending a Binding Update with zero lifetime to the "next" regional FA
in the MN's old regional branch, setting the Binding Update's care-of
address to the the previous care-of address it had registered for the
MN (i.e. the "previous" lowest level FA). The Binding Update is
relayed down towards the previous care-of address, and each regional
foreign agent in the hierarchy receiving this notification removes
its binding for the MN. In this way, the MN updates all the Regional
FAs in the "old" hierarchical branch between the "common route" FA
and the "old" lowest level FA. It is assumed that GFA/FAs within
the same hierarchical domain share a Security Association which can
be used to perform this deregistration.
The MN will be able to perform regional deregistrations through
intermediate regional FAs if the GFA shares its GFA-MN security
association with the regional FAs (further described in Ch.9).
Otherwise the regional deregistration will be performed by the GFA.
7. Smooth Handoffs between Hierarchies (GFAs)
When the MN moves between domains it receives Mobility Agent
extensions containing a new GFA IP address. The MN registers with its
HA using the new GFA IP address as care-of address. In order to
improve inter-domain handoffs it may use the Previous Foreign Agent
extension in the Regional Registration Request [3]. This results in a
smooth handoff between the domains.
Karim El Malki and Hesham Soliman [Page 12]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
A new flag is required in the Binding Update message to perform a
smooth handoff while maintaining the existing binding in the
"previous" FA. This is the "S" bit for the simultaneous binding. This
simultaneous binding is necessary in the case in which the MN only
momentarily moves "forward" to the new domain, then returns back to
the "previous" FA (domain) before its "previous" binding expires. In
this case the binding for the MN with the "previous" FA must be
maintained. Following is the new Binding Update message with the "S"
flag added which replaces one bit of the Reserved space.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|I|M|G|S| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
8. L2 Address Considerations for Fast Handoffs
Networks utilising interfaces such as ethernet require an extension
to the Registration messages. Wireless networks often have specific
L2 interfaces between the FA and the wireless/cellular network in
which case this requirement may not hold. Such an extension is
required in Ethernet-based networks because the MN performing a
registration with a FA which is not its first-hop router needs to
communicate its L2 address to the FA. Therefore the FA must use the
L2 address in this extension for the MN instead of the L2 address on
the incoming Registration Request message as specified in RFC2002.
Such an extension will be specified in future versions of this draft
and will conform to the generalised extension format in MIER [5].
9. IPv6 Considerations
A Hierarchical model which supports the Fast Handoffs concept
for MIPv6 is described in [4].
Karim El Malki and Hesham Soliman [Page 13]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
10. Security Considerations
As in [1], it is assumed that the mobility agents within a
hierarchical domain (i.e. GFA and Regional FAs) share a security
association. The GFA address is the MN's global care-of-address
stored in the HA. The GFA may therefore authenticate the MN by
interacting with the AAAL and receives the MN-FA session key
information. Since FAs at all levels of the hierarchy should be able
to authenticate MN (Regional) Registrations, it should be possible
for the GFA to distribute this MN-FA key to other Regional FAs in the
path taken by the (Regional) Registration Reply message from GFA to
MN. This may be performed using the hierarchical domain's shared SA
and a new GFA-FA key extension added to the Regional Registration
Reply message sent by the GFA through Regional FAs to the MN. This
new extension should be added to the Registration Reply message by
the GFA, read by all Regional FAs in the path to the MN and removed
by the lowest-level FA before forwarding the Reply to the MN. This
new extension should is a subtype of the Generalized Key Reply
Extension and defined in [1].
11. Acknowledgements
This draft replaces the previous draft on Fast Handoffs
(draft-elmalki-mobileip-fast-handoffs-02). The authors thank the
participants of the v4 handoffs design team and especially Pete
McCann for pointing out the issue addressed in Section 8.
12. References
[1] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
Tunnel Management ", draft-ietf-mobileip-reg-tunnel-03.txt
(work in progress), July 2000.
[2] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
1996.
[3] C. Perkins and D. Johnson, "Route Optimization in Mobile IP",
draft-ietf-mobileip-optim-09.txt (work in progress), February
2000.
[4] H. Soliman, C. Castelluccia, K. El Malki and L. Bellier,
"Hierarchical MIPv6 Mobility Management",
draft-soliman-mobileip-hmipv6-01 (work in progress), Sept 2000
[5] M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura,
"Mobile IP Extensions Rationalization (MIER)",
draft-ietf-mobileip-mier-03 (work in progress), Dec. 1999
Karim El Malki and Hesham Soliman [Page 14]
INTERNET-DRAFT Fast Handoffs in MobileIPv4 Sept 27, 2000
13. Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola M/S M8-540
6000 Connection Drive 1501 West Shure Drive
Irving, TX 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
Questions about this memo can be directed to:
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vg 8
SE-126 25 Stockholm
SWEDEN
Phone: +46 8 7191954
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Hesham Soliman
Ericsson Australia
61 Rigall St., Broadmeadows
Melbourne, Victoria 3047
AUSTRALIA
Phone: +61 3 93012049
Fax: +61 3 93014280
E-mail: Hesham.Soliman@ericsson.com.au
This Internet-Draft expires in March 2001.
Karim El Malki and Hesham Soliman [Page 15]