INTERNET DRAFT K. El Malki, N. A. Fikouras, S. R. Cvetkovic
University of Sheffield
15th June 1999
Expires December 1999
Fast Handoff Method for Real-Time Traffic over
Scaleable Mobile IP Networks
<draft-elmalki-mobileip-fast-handoffs-01.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 document defines the operations to be performed by
scaleable Mobile IP [1] networks during handoffs in order to
support real-time traffic which has delay bounds. This method is
based on the Regionalized Tunnel Management [2] approach. A
method is described in this document which defines the operation
of Mobile Nodes, Foreign Agents and Hierarchical Proxy Foreign
Agents. This utilises multiple bindings in order to "multicast"
traffic to potential Mobile Node movement locations in order to
anticipate movement. This eliminates the service disruption
period which is currently present during handoffs in Mobile IP
networks due to registration delay. The information redundancy
lasts only for very short periods and the waste of bandwidth is
therefore minimal.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 1]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
Table of Contents
1.0 Introduction
1.1 Assumptions
1.2 Acronyms
2.0 Description of the Fast Handoff Method
2.1 Overall Method and Architecture
2.2 Mobile Node (MN) functionality for Fast Handoffs
2.3 Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top-
level Proxy Foreign Agent (TPFA) functionality for
Fast Handoffs
2.4 Support of "forward" and "backward" MN movement
2.5 Fast Handoffs applied to multiple BSs having
common wireless overlap regions.
3.0 Security Considerations
4.0 References
5.0 Author's Address
1. Introduction
Mobile Nodes (MNs) will vary their point of attachment to the
Internet frequently. MNs which move in this way suffer a period
of communication breakdown due to the time needed to update the
MNs' location information (i.e. registration with the Home
Agent). During these periods MNs experience a service disruption
which undermines the quality of real-time services.
In this document a Fast Handoff method is described. This method
eliminates the service disruption period due to handoffs by
anticipating the MN's movement and using multiple bindings to
direct the MN's traffic to the multiple locations which it may
move to.
Although some waste of bandwidth will occur, this is minor since
it will only last for the very short period in which a MN lies
in the wireless overlap region of two network access points. We
identify the movement between two access points as comprising
both a movement between BSs (Base Stations: layer 2 mobility)
and a movement between Mobility Agents (MAs). This method does
not rely on the assumption of single-MA networks, and is
applicable to multiple-MA networks. Finally, the Fast Handoff
method may be applied to scenarios in which a Mobile Node enters
the wireless overlap region of multiple BSs, and not only two as
considered above.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 2]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
1.1 Assumptions
This method makes use of hierarchical agents and the
Hierarchical Mobility Agent Extension [2]. It is also assumed
that a FA will send advertisements containing its address and
the addresses of all other PFAs in its hierarchical branch of
the network using the PFA IP address extension [2]. These will
be advertised in hierarchical order and this order cannot be
modified.
This method also assumes an underlying layer 2 protocol which
allows a mobile node to receive and transmit contemporarily
from/to multiple Base Stations (BSs) when in their wireless
overlap region. A particular pattern of MN movement is not
assumed, hence this method will provide seamless (loss-less)
service to MNs moving "forward" and "backward" into any number
of location and overlap regions.
No limit is assumed regarding the number of MA levels in a
hierarchy.
1.2 Acronyms
MN Mobile Node
FA Foreign Agent
HA Home Agent
PFA Proxy Foreign Agent
TPFA Top-level Proxy Foreign Agent
MA Mobility Agent. As such are described FAs, HAs, PFAs
and TFAs.
ISP Internet Service Provider
COA Care-of address
PM Prefix Matching
ECS Eager Cell Switching
LCS Lazy Cell Switching
NAI Network Access Identifier
2.0 Description of Fast Handoffs Mechanism
The Fast Handoff mechanism allows efficient handoffs for MNs. It
supports Local, Metropolitan and Wide-Area mobility. This method
is of greatest efficiency using Local and Metropolitan mobility,
which are the most frequent scenarios for a MN. Security is
considered in this method.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 3]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
2.1 Overall Method and Architecture
....................................................
. .
. GLOBAL INTERNET .
....................................................
/ \
/ \
+-------------------------+ +-------------------+
| ISP | | ISP |
| ----- | | ----- |
Top +---------|TPFA1|---------+ +-------|TPFA2|-----+
Level ----- -----
/ \ |
----- \ |
Local | PFA | \_______ |
----- \______ \ |
/ \ \ \ |
Lowest ----- ----- ----- ----- -----
Level | FA1 | | FA2 | | FA3 | | FA4 | | FA5 |
----- ----- ----- ----- -----
| | | | |
| ---------- | |
| | | |
BS BS BS BS
| | | |
MN -------> MN ------> MN ----------> MN
1 1ov2 2 2ov3 3 3ov4 4
Figure 1: Fast Handoff Network Topology
Key: xovy = overlap area between the BSs in Pos. x and y
The above diagram illustrates a general network architecture in
which ISPs connect users through the Internet. Both single-agent
and multiple-agent subnetworks are considered. In this scenario
each ISP will host a Top-level MA or a Top-level Proxy Foreign
Agent (TPFA). The function of a TPFA is to dynamically manage
regional tunnels. Private networks (i.e. company networks) may
have their own PFAs if they wish to manage tunnels locally.
TPFAs and PFAs can provide fast handoffs by establishing
multiple bindings (registrations) for moving MNs. The lowest
levels of the MA hierarchy are occupied by FAs which provide
network access to MNs. Although figure 1 presents only one level
of FAs, any number of FA levels may exist below a given PFA.
Furthermore, it is noted that FAs 1, 4 and 5 represent
subnetworks with a single FA (i.e. single-agent subnetworks)
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 4]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
while FAs 2 and 3 exist within the same subnetwork (i.e.
multiple-agent subnetworks). This configuration is typical of
private organisations where multiple departments (each having a
FA) are located within the same division or building floor and
thus share communication resources. It is assumed in figure 1
that the MN has a HA connected to a PHA which is located
anywhere on the Internet (as in [2]), but is not presented for
simplicity.
Link layer connectivity is provided by the BSs. Each BS can
service MNs within its area of coverage. The overlap of multiple
areas of coverage forms an overlap region. These regions are
labelled as xovy, identifying the overlap between the two
positions (i.e. x and y). It is assumed that a wireless
technology is available at Layer 2 which allows the MN to
communicate with N BSs when in the overlap region of their
coverage areas.
All FAs are required to include in their advertisements the PFA
IP address extension [2] which will list all PFA's and TPFA's in
the same hierarchical "branch" in descending order. Thus, in
figure 1 the TPFA is listed first in FA advertisements. MNs are
required to cache these lists in order to determine common
routes as they move.
Generally the TPFA is the single point of access to the Internet
for a hierarchy of PFAs. In Figure 1 a scenario is depicted
where a PFA denotes a local private or public administrative
domain. The PFA can identify an organisational/residential
network or it can provide network access to MNs on the street,
although this can be done by the TPFA as shown in Figure 1.
The following types of mobility are considered:
1)Local Mobilty (movements between Pos. 1 to Pos. 2) and
Metropolitan-Area mobility (movement between Pos. 2 and Pos. 3)
2)Wide-Area Mobility (movement between Pos. 3 to Pos. 4)
2.2 Mobile Node (MN) functionality for Fast Handoffs
The handoff mechanism is described in this section. Below is a
flowchart specifying the MN operations when performing a Fast
Handoff. As mentioned previously, TPFAs and PFAs are capable of
supporting multiple simultaneous bindings for a MN.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 5]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
It is assumed that the MN, upon movement from the Home network
to a Foreign network, will cache the TPFA/PFA address hierarchy
from the PFA IP address extension [2] present in FA agent
advertisements. In the case of FA1 the extension would include
the Local PFA and TPFA1.
Some FAs may choose to advertise only Local PFAs. For example,
an organisation comprising the Local PFA, FA1, FA2 and FA3 may
not want to advertise the TPFA or any other higher PFAs which
may exist in between. However this will prevent users from
performing seamless handoffs between the organisation's network
and the rest of the Internet. That is, fast and seamless
handoffs would not be available for movement from position 2 to
3 or 2 to 4.
In figure 1 it is assumed that the MN has powered up in position
1. Having no prior record of a hierarchy it operates as per [2]
and issues a Registration Request using as COA (Care-of-address)
the IP address of the TPFA. It is assumed that this Request
updates the HA's MN location information, that the MN is granted
network access and that the MN caches the list of PFAs (CURRENT
PFA list) received in the FA agent advertisement. The MA
activity in response to the Request is presented in section 2.3.
It is assumed that MNs keep record of all the FAs from which
they have received an agent advertisement ("known" Agents) even
if they belong to different subnetworks. Similarly, the MN keeps
record of "known" subnetworks. These are subnetworks in which
"known" Agents lie. Furthermore, MNs are required to keep record
of all established bindings. Optionally the MN may keep record
of PFA IP address lists.
Even though all "known" FAs hold the same status, only one FA is
the "primary" FA. The binding associated with that FA is always
updated by requesting a long lifetime and the PFA list
associated with the "primary" FA is considered as CURRENT.
Bindings associated with all the FAs, except for the "primary"
FA, are updated by requesting a short lifetime (3 *
advertisement rate). In this way the method is able to
distinguish between the primary traffic flow and auxiliary
traffic flows. The purpose of auxiliary flows is to anticipate
MN movement into a new subnetwork. In Figure 1, when the MN
moves from Position 1 to 1ov2, FA1 will be the "primary" FA
while FA2 will receive and provide the MN with the auxiliary
traffic flow.
"Known" FAs whose lifetime has expired are removed, and so is
all cached information associated with them (i.e. bindings,
entries in "known" subnetwork list and PFA IP address lists).
Using the list of "known" agents and subnetworks, in conjunction
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 6]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
with PM (Prefix Matching) and the NAI (Network Access
Identifier), can help detect MN movement into new subnetworks.
Since a MN may maintain simultaneous bindings with MAs, this
method assumes a hybrid LCS-ECS movement detection method with
PM or NAI support. That is, MNs are Eager to request
simultaneous bindings when movement is detected by PM or NAI
domain comparison, but are Lazy to abandon established bindings.
This behaviour has been integrated in the flowchart presented
below.
The following flowchart illustrates the Fast Handoffs procedure
for MNs when moving between FAs:
.-----------> .-> Has the lifetime of a "known" FA expired ? .NO
| | | |
| | |YES |
| | | |
| | Remove FA from the "known" FAs list. |
| | De-cache associated PFA list. |
| | Delete all associated bindings. |
| | (MN is Lazy to abandon bindings) |
| | | |
| | | |
| | | |
| | Has the "primary" FA expired ? ------------>|
| | | NO |
| | |YES |
| | | |
| | Use FA with longest outstanding lifetime |
| | as "primary" FA. |
/|\ /|\ Get a new CURRENT PFA IP address |
| | extension list. |
| | | |
| | | |
| | | |
| | Received any successful Registration <-----.
| | Replies ? ---------------------->.
| | | NO |
| | |YES |
| | | |
| | Cache associated binding and |
| | optionally PFA IP address list. |
| | Add FA to "known" FAs list. |
| | Add FA's subnet to "known" subnetworks list. |
| | | |
| | | |
| | | |
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 7]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
| | Are there any bindings about <---------.
| | to timeout ? ----------->.
| | | NO |
/|\ /|\ |YES |
| | | |
| | Update bindings by sending a |
| | Registration Request with the |
| | IP address of the corresponding PFA |
| | or TPFA as the COA. |
| | Do not set the S bit ON. |
| | | |
| | | |
| |<-- Received new FA Advertisements ? <-------.
| | NO (not a "known" FA)
| | |
| | |YES
| | |
| | Does PM or NAI comparison indicate
| .<---- discovery of a new subnet ?
| NO |
| |YES
| |
| Movement has been detected.
| Cache PFA IP address extension
| list (NEW PFA list).
/|\ |
| |
| Find Common PFA by comparing
| CURRENT and NEW PFA lists.
| |
| |
| Is there a Common PFA ?
| / \
| YES / \ NO
| / \
| Send a Registration Request Send a Registration Request
| using the Common PFA as COA using the TPFA as COA. Set the
| Set the S bit ON to request a S bit ON to request a simultaneous
| simultaneous binding. Use a binding. Use a short lifetime
| short lifetime (i.e. (i.e. 3 * advertisement rate).
| 3 * advertisement rate). The MN is Eager in establishing
| The MN is Eager in establishing new bindings.
| new bindings.
| | |
| | |
| | |
| \|/ \|/
.<------------------------------------------.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 8]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
When the MN moves into the overlapping region of multiple
subnetworks, it will receive agent advertisements containing the
PFA IP address extension lists. The MN will therefore be in the
position to determine if there is a Common PFA which could
potentially send traffic for the MN to both its old and new
location. If PM or NAI indicate movement into a new subnetwork
then the MN will send a Registration Request.
If there is a Common PFA the MN sends a Registration Request
with the Common PFA as COA (N.B. the TPFA could be the Common
PFA). Otherwise, if there is no Common PFA, the MN will use the
TPFA as the COA. The S bit is set ON only when a Common PFA is
found, such that the Common PFA maintains simultaneous bindings
with the MN. In this case the Common PFA will "multicast"
traffic to both MN's registered locations.
When the "primary" FA changes, a new Registration Request is
issued without setting the S bit. This causes the Common
PFA/TPFA to replace the simultaneous bindings held previously
with a single binding for the MN's current location.
2.3 Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top-level
Proxy Foreign Agent (TPFA) functionality for Fast Handoffs
Upon receipt of a Registration Request, the FA will add the
Hierarchical Mobility Extension. The FA will add its own address
to this extension. The FA is aware of the next higher PFA which
it already includes in its advertisements. It will therefore
send the packet to the next higher PFA. Intermediate FA levels
act as simple routers and relay the Request.
Each PFA will check whether its address corresponds to the COA.
If they do not correspond then the PFA adds its address to the
hierarchical agent extension list (hence forming the PFA IP
address extension list) and sends the Request onto the next
higher PFA which is known and included in all MA advertisements.
However, if the PFA's address corresponds to the Request's COA
then the PFA will authenticate the MN and terminate the Request.
If the Request has the S-bit set then the PFA will add a
simultaneous binding for the MN using the next lower level PFA
(or FA) as destination. If the S bit is not set then it will
replace the old binding it had for the MN with a new one using
the next lower level PFA (or FA) as destination.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 9]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
If the Request reaches the TPFA, and the TPFA is not the COA,
then the TPFA relays the registration to the PHA. However, if
the TPFA is the COA then it acts as a regular PFA.
Registration Requests that are accepted produce a Registration
Reply. All Registration Replies contain the PFA IP address
extension list (Hierarchical Mobility Agent extension). This is
the same extension received in the Request, but inverted. It is
always relayed to the next lower level PFA. Its address is known
since it is present at the top of the PFA IP address list of the
Registration Reply.
Upon receiving a Registration Reply the PFAs will check if their
address is contained in the PFA IP address extension list. If so
the PFA will add a binding for the MN using the next PFA (or FA)
address in the list as destination. It will then send the Reply
to the next lower PFA (or FA) by using the next PFA IP address
in the list.
In this way every TPFA/PFA in the hierarchy branch will create a
binding for the MN with a PFA below in the hierarchy. The
advantage of this approach is that when the MN traffic flow has
to change part of its route as a result of MN movement then this
will affect only certain TPFA/PFAs and not every MA in the
branch. The disadvantage of this approach is that every TPFA/PFA
is the tunnel endpoint for a MA above itself in the hierarchy
but also a tunnel startpoint for a MA below in the hierarchy. As
the process of detunneling and tunneling can prove very
demanding it is proposed that MAs will in this case avoid
detunneling. Instead it is preferred that the MA only change the
appropriate fields in the outer (encapsulation) header of
incoming encapsulated traffic. "Multicasting" can occur by
cloning that same encapsulated traffic.
The TPFA or PFA will authenticate the MN upon receiving its
Registration Request. If the Request cannot be authenticated
then the TPFA or PFA will issue a Registration Reply with a code
of 67 (MN failed authentication). (see 3.0)
2.4 Support of "forward" and "backward" MN movement
This method does not assume that the MN will only move "forward"
to a new network. The MN may move into the overlap region of
networks and then move back to its original position. Consider
the following MN movement:
Pos.1 --> Pos. 1ov2 --> Pos.1
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 10]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
When the MN moves to Pos. 1ov2, the Fast Handoff method will
cause the Local PFA to "multicast" traffic for the MN to both
FA1 and FA2. This is done by establishing a new auxiliary route
(simultaneous binding) between the Local PFA and FA2. This has a
short lifetime and will be renewed as long as the MN stays in
Pos. 1ov2. However, when the MN moves back to Pos. 1 the
lifetime of the binding between the Local PFA and FA2 will
elapse and the "multicasting" will stop.
The Fast Handoff method is therefore independent of particular
MN movement patterns.
2.5 Fast Handoffs applied to multiple subnetworks having a wireless
overlap region.
Let us consider a situation in which the MN lies in the overlap
region of multiple subnetworks. Moreover, let us assume that at
least one of the subnetworks consists of multiple advertising
MAs. Depending on the protocol that communicates PFA IP
addresses to all the MAs in the hierarchy and determines its
structure, it is possible that even MAs in the same subnet might
advertise different PFA IP address extension lists.
Normal ECS [3] operation would force the MN to request a binding
for every newly discovered MA. In the case presented this might
cause traffic "multicasting" at multiple PFAs in the hierarchy.
For this reason the presented method requires a "known"
subnetworks list and the use of PM [3] or NAI to distinguish
between advertisements coming in from known and unknown
subnetworks. Unknown subnetworks are only the ones for which a
MN should request a new binding.
In the described method this functionality is provided by
keeping a list of "known" FAs and subnetworks and using either
PM or NAI (tenth step in the flowchart). Thus, as the MN enters
a new multiple-agent subnetwork it will only request an
additional binding for the first encountered MA.
3.0 Security Considerations
It is assumed that there is a secure association between the
PFAs (including the TPFA) and all the FAs in its hierarchy, in
order to prevent intruders from impersonating as PFAs. Moreover,
a secure association between the TPFA and the HA or PHA as in
[2] is assumed.
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 11]
INTERNET-DRAFT Fast Handoff Method 15th June 1999
Potentially a MN can be authenticated by multiple PFAs/TPFA in a
hierarchy. A Registration Request that is positively
authenticated will result in a positive Registration Reply. As
the Reply is being relayed through all the PFAs in the hierarchy
new bindings are created and the MN authentication is recorded
for future reference. This means that in the future, when a PFA
receives a Registration Request with its IP address as COA it
may authenticate it and issue a Reply. Otherwise, if the Request
cannot be authenticated, a Reply with code 67 (MN failed
authentication) is issued.
On receipt of a positive Registration Reply, the FA which hosts
the MN may grant it with network access. If this Reply is not
received or is negative the FA will block network access to the
MN (this case is considered by RFC 2002).
It is assumed that encryption will exist on the wireless medium
at the link-layer. This will stop intruders from intercepting
data on the wireless segments.
4.0 References
[1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
1996.
[2] P. R. Calhoun, G. Montenegro, C.E. Perkins, "Mobile IP
Regionalized Tunnel Management", Internet draft (work in progress),
draft-ietf-mobileip-reg-tunnel-00.txt, November 1998.
[3] C.E. Perkins, "Mobile IP", Addison-Wesley, ISBN 0-201-63469-4,
1998.
5.0 Author's Address
Any query may be directed to:
Karim El Malki Nicholas A. Fikouras Srba R. Cvetkovic
Dept. of Computer Science Dept. of Computer Science Dept. of Computer Science
The University of Sheffield The University of Sheffield The University of Sheffield
211 Portobello Street 211 Portobello Street 211 Portobello Street
Sheffield S1 4DP, U.K. Sheffield S1 4DP, U.K. Sheffield S1 4DP, U.K.
Phone: +44-114-2221935 Phone: +44-114-2221873 Phone:+44 (0)114 222 1825
Fax: +44-114-2221810 Fax: +44-114-2221810 Fax: +44-114-2228299
E-Mail: karim@dcs.shef.ac.uk E-Mail: nick@dcs.shef.ac.uk E-mail: srba@dcs.shef.ac.uk
El Malki, Fikouras, Cvetkovic Expires December 1999 [Page 12]