One document matched: draft-ramjee-micro-mobility-hawaii-00.txt
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Internet Engineering Task Force R. Ramjee / T. La Porta
INTERNET-DRAFT S. Thuel / K. Varadhan
draft-ramjee-micro-mobility-hawaii-00.txt Lucent Bell Labs
19 February 1999
Expires: 19 August 1999
IP micro-mobility support using HAWAII
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
In this contribution, we present HAWAII: a domain-based approach for
supporting mobility. HAWAII uses specialized path setup schemes
which install host-based forwarding entries in specific routers to
support intra-domain micro-mobility and defaults to using Mobile-IP
for inter-domain macro-mobility. These path setup schemes deliver
excellent performance by reducing mobility related disruption to user
applications, and by operating locally, reduce the number of mobility
related updates. Also, in HAWAII, mobile hosts retain their network
address while moving within the domain, simplifying Quality of
Service support. Furthermore, reliability is achieved through the
use of soft-state forwarding entries for the mobile hosts, and the
elimination of foreign agents and, in some cases, the home agent.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 1]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Contents
1 Introduction 3
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Design Overview . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Network Architecture . . . . . . . . . . . . . . . . . 5
1.4.2 Path Setup Schemes . . . . . . . . . . . . . . . . . . 6
1.4.3 Soft-State . . . . . . . . . . . . . . . . . . . . . . 7
2 Path Setup Schemes 7
2.1 Forwarding Path Setup Scheme . . . . . . . . . . . . . . . 8
2.2 Non-Forwarding Path Setup Scheme . . . . . . . . . . . . . . 10
3 Protocol Processing 11
3.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Mobile Host Processing . . . . . . . . . . . . . . . . . . . 13
3.3 Base Station/Router Processing . . . . . . . . . . . . . . . 15
4 Design Implications 17
4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Quality of Service Support . . . . . . . . . . . . . . . . . 19
4.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Address Assignment 22
6 Security 23
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 2]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
1 Introduction
Mobile-IP is the current standard for supporting macro-mobility in IP
networks [6]. Mobile-IP defines two entities to provide mobility
support: a home agent (HA) and a foreign agent (FA). The HA is
statically assigned to a mobile host based on the permanent home IP
address of the mobile host. The FA is assigned to the mobile host
based on its current location. The FA has associated with it an IP
address called the care-of address. Packets sent to the mobile host
are intercepted by the HA and tunneled to the FA at the care-of
address. The FA then decapsulates the packets and forwards them
directly to the mobile host. Thus, Mobile-IP provides a good
framework for allowing users to roam outside their home networks.
When Mobile-IP is used for micro-mobility support, it results in high
control overhead due to frequent notifications to the HA. Also, in
the case of a Quality of Service (QoS) enabled mobile host, acquiring
a new care-of address on every handoff would trigger the
establishment of new QoS reservations from the HA to the FA even
though most of the path remains unchanged. Thus, while Mobile-IP
should be the basis for mobility management in wide-area wireless
data networks, it has several limitations when applied to wide-area
wireless networks with high mobility users that may require QoS. Our
aim is to extend Mobile IP to address these limitations using
Handoff-Aware Wireless Access Internet Infrastructure (HAWAII).
1.1 Goals
We have three design goals:
o Achieve good performance by reducing update traffic to home
agent and corresponding hosts, avoiding triangular routing where
possible, and limiting disruption to user traffic.
o Provide intrinsic support for QoS in the mobility management
solution, including allowing per flow QoS and limiting the
number of reservations that must be re-established when hosts
move.
o Enhance reliability. We require HAWAII to be no less fault
tolerant than existing Mobile-IP proposals, and we explore
additional mechanisms to improve the robustness of mobility
support.
1.2 Assumptions
Our proposal for supporting mobility hinges on the assumption that
most user mobility is local to a domain, in particular, an
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 3]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
administrative domain of the network. Since an administrative domain
is under the control of a single authority, it is possible to relax
the assumption that there is no special support for mobility
available in the domain infrastructure. Therefore, we consider
optimizations in routing and forwarding in the domain routers for
more efficient support of intra-domain mobility.
1.3 Terminology
Domain
A division of the wireless access network. It consists of one or
more routers and multiple base stations. It will appear as a
subnet to routers external to the domain.
Domain Root Router
The gateway router into a domain is called the domain root router.
Home Domain
Each mobile host is assigned a home domain based on its permanent
IP address.
Foreign Domain
Any domain that is not the mobile host's home domain is referred
to as its foreign domain.
Path Setup Scheme
A particular method of updating the routers in a domain so that
connectivity to the mobile host is maintained across handoffs.
1.4 Design Overview
In this section, we present the architecture of HAWAII. There are
three separate components to HAWAII: 1) To achieve maximum
transparency in mobility, we consider a two-level hierarchy along
domain boundaries, and define separate mechanisms for intra-domain
mobility and inter-domain mobility. We conjecture that mobility
across domains is likely to be a rare occurrence and default to using
Mobile-IP for inter-domain mobility. To provide straight-forward QoS
support, we assign a unique, co-located care-of address to the mobile
host; 2) To maintain end-to-end connectivity with little disruption
as the mobile host moves, we establish special paths to the mobile
host; and finally, 3) To provide a degree of tolerance to router or
link failures within the network, we use soft-state mechanisms for
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 4]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
maintaining forwarding state. We discuss each of these issues
separately in the following sections.
1.4.1 Network Architecture
___ ___
| | Internet | |
| | Core | |
|___| |___|
x\ /
x\ /
x\ ____/
x| | Regular IP Packets xxxxx
x | Encapsulated IP Packets @@@@@
|x___| Domain Boundaries *****
x /\
********************x / \*************************
* x /* *\ *
* Home x / ** \ Foreign *
* Domain _x_/ * \ ___ Domain *
* Root --->|x@@@@@@@@@@@@@@@ |<--Root *
* Router |x | * | @ | Router *
* |x__| * |_@_| *
* Home Domain x * @ Foreign Domain *
* x x x * @@@ *
* x x x * @ @ @ *
* x x x * @ @ @ *
* x x x * @ @ @ *
* x x x * @ @ @ *
* ___ x * ___ *
* | | * | | Mobile *
* | | * | | Host *
* |___|----->------->--*--->----->--->|___| *
* * *
* Movement Movement across domains Movement within *
* within domain (HA notified of co-located domain (no HA *
* (no HA involved) care-of address) notification) *
Figure 1: Hierarchy
A common approach for providing transparent mobility to correspondent
hosts is to divide the network into hierarchies. In HAWAII we define
a hierarchy based on domains. The network architecture is
illustrated in Figure 1. The gateway into each domain is called the
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 5]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
domain root router. Each host has an IP address and a home domain.
For the moment, we defer the discussion of how this address could be
assigned later (Section 5). When moving in its home domain, the
mobile host retains its IP address. Packets destined to the mobile
host reach the domain root router based on the subnet address of the
domain and are then forwarded over special dynamically established
paths to the mobile host. This allows the home domain to cover a
large area made up of hundreds of base stations, thereby increasing
the probability that a mobile host is in its home domain. For these
mobile hosts, a home agent is not involved in the data path,
resulting in enhanced reliability and efficient routing.
When the mobile host moves into a foreign domain, we revert to
traditional Mobile-IP mechanisms. If the foreign domain is also
based on HAWAII, then the mobile host is assigned a co-located
care-of address from its foreign domain. Packets are tunneled to the
care-of address by a home agent in its home domain. When moving
within the foreign domain, the mobile host retains its care-of
address unchanged (thus, the HA is not notified of these movements);
connectivity is maintained using dynamically established paths in the
foreign domain.
The design choices of using co-located care-of addresses and
maintaining the mobile host address unchanged within a domain
simplifies per flow QoS support as discussed in Section 4.2. This
choice also eliminates the need for a FA in the domain, thereby
enhancing reliability. Also, in Mobile-IPv6 [2], the FA is
eliminated and the co-located care-of address option is used. One
drawback of using the co-located care-of address option is the need
for two IP addresses for each mobile host that is away from its home
domain. This exacerbates the limited IP address availability
problem. One possible optimization is to adapt the ``dialup'' model
used by ISPs to wireless networks. This is discussed in Section 5.
1.4.2 Path Setup Schemes
As described above, HAWAII assigns a unique address for each mobile
host that is retained as long as the mobile host remains within its
current domain. In this context, maintaining end-to-end connectivity
to the mobile host requires special techniques for managing user
mobility. HAWAII uses path setup messages to establish and update
host-based routing entries for the mobile hosts in selective routers
in the domain so that packets arriving at the domain root router can
reach the mobile host. The choice of when, how, and which routers
are updated constitutes a particular path setup scheme. In
Section 2, we describe two such path setup schemes.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 6]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
One important question in using host-based forwarding in the domain
routers is scalability. It is because of scalability considerations
that we use Mobile-IP mechanisms for inter-domain mobility. In
Section 4.1, we present a numerical example showing how a single
domain in HAWAII can cover an area of approximately 1000Km2 without
any difficulty in processing mobility related updates.
1.4.3 Soft-State
The notion of ``soft-state'' refers to state established within
routers that needs to be periodically refreshed; otherwise, it is
removed automatically when a preset timer associated with that state
expires. The HAWAII path state within the routers is soft-state.
This increases the robustness of the protocol to router and link
failures.
Our protocol uses two types of control messages, updates and
refreshes, to establish and maintain the soft-state respectively.
Path setup updates are sent by the mobile host during power up and
following a handoff. These messages are explicitly acknowledged by
the recipient. Path setup refresh messages are sent periodically by
mobile hosts. Aggregate refresh messages are sent periodically by
base stations and routers in a hop-by-hop manner to the router
upstream of the mobile hosts. As we shall see in the following
sections, path messages are sent to only selected routers in the
domain, resulting in very little overhead associated with maintaining
soft-state.
2 Path Setup Schemes
Path setup update messages are sent by the mobile host during power
up and following a handoff. We first discuss the update procedure
for power up. We then describe two algorithms by which update
messages in HAWAII are used to re-establish path state after
handoffs.
When the mobile host powers up, it sends a path setup update message
to its nearest base station. This message propagates to the domain
root router. Each router in the path between the mobile host and the
domain root router adds a forwarding entry for the mobile host.
Finally, the domain root router sends back an acknowledgement to the
mobile host. At this time, when packets destined for the mobile host
arrive at the domain root router based on the subnet portion of the
mobile host's IP address, the packets are routed within the domain to
the mobile host using the host-based forwarding entries just
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 7]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
established. Note that other routers in the domain have no specific
knowledge of this mobile host's IP address. In the case of mobile to
mobile communication, packets arriving at a router that has no
specific host-based entry are routed using a default route. The
packets eventually reach an upstream router (in the worst case, the
domain root router) which has a forwarding entry for the mobile host.
We now describe the operations of two path setup schemes used to
re-establish path state when the mobile host moves from one base
station to another within the same domain. We assume a tree-based
topology for the discussion although the path setup schemes work with
any arbitrary topology. For the remaining subsections, let us define
the cross-over router as the router closest to the mobile host that
is at the intersection of two paths, one between the domain root
router and the old base station, and the second between the old base
station and the new base station. In both path setup schemes,
forwarding entries during handoff are added so that packets are
either forwarded from the old base station or diverted from the
cross-over router to the new base station. This property ensures us
against the possibility of persistent loops after the handoff update.
There are two variants of the path setup schemes, motivated by two
types of wireless networks. The Forwarding scheme is optimized for
networks where the mobile host is able to listen/transmit to only one
base station as in the case of a Time Division Multiple Access (TDMA)
network. The Non-Forwarding scheme is optimized for networks where
the mobile host is able to listen/transmit to two or more base
stations simultaneously for a short duration, as in the case of a
WaveLAN or Code Division Multiple Access (CDMA) network. These are
described below.
2.1 Forwarding Path Setup Scheme
In this path setup scheme, packets are first forwarded from the old
base station to the new base station before they are diverted at the
cross-over router.
The Forwarding scheme is illustrated in Figure 2. The forwarding
table entries are shown adjacent to the routers. These entries are
prepended with a message number indicating which message was
responsible for establishing the entry (a message number of zero
indicates a pre-existing entry). The letters denote the different
interfaces. The path setup message is first sent by the mobile host
to the old base station. The message contains the new base station's
address. The old base station performs a routing table lookup for
the new base station and determines the interface, interface A, and
next hop router, Router 1. The base station then adds a forwarding
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 8]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
entry for the mobile host's IP address with the outgoing interface
set to interface A. It then forwards the message to Router 1 (shown
as message 2 in Figure 2). Router 1 performs similar actions and
forwards the message to Router 0. Router 0, the cross-over router in
this case, adds forwarding entries that result in new packets being
diverted to the mobile host at the new base station. It then
forwards the message towards the new base station. Eventually the
message reaches the new base station (shown as message 5 in Figure
2). The new base station changes its forwarding entry and sends an
acknowledgement of the path setup message to the mobile host (shown
as message 6 in Figure 2).
| (0):1.1.1.1->B
--------- (3):1.1.1.1->C
| A |
ROUTER 0 | |
| B C |
@@@@@>--------- @@@@@
@ / @@@@ \ @
3 @ / @ @ \ @ 4
@ / @ @ \ @
@ / @ @ \ v
ROUTER 1---------@ @--------- ROUTER 2
| A |@ @| A |
(0):1.1.1.1->C | |@ @| | (0):Default->A
(2):1.1.1.1->A | B C |@ @| B C | (4):1.1.1.1->B
---------@ @---------
^ | @ @ | @
2 @ | @ @ | @ 5
@ | @ @ | @
@ | @ @ | v
OLD BS -----<@ @ ----- NEW BS
/ A \ @ / A \
(0):1.1.1.1->B | | @| | (0):Default->A
(1):1.1.1.1->A \ B / @ \ B / (5):1.1.1.1->B
----- 1 @ -----
@ @ 6
@ @
---- <@@@@@
MOBILE / \
USER \ /
----
IP:1.1.1.1
Figure 2: Forwarding path setup scheme
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 9]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Note that only the new and old base stations, and the routers
connecting them, are involved in processing the path setup message.
Also, only routers on the path between the new base station and the
domain root router will receive the periodic refresh messages.
Therefore, the entries in Router 1 and the old base station, which
are no longer on this path, will time-out, while the entries in
Routers 0 and 2, and the new base station will get refreshed.
2.2 Non-Forwarding Path Setup Scheme
| (0):1.1.1.1->B
--------- (3):1.1.1.1->C
| A |
ROUTER 0 | |
| B C |
@@@@@@---------<@@@@@
@ / @@@@ \ @
4 @ / @ @ \ @ 3
@ / @ @ \ @
v / @ @ \ @
ROUTER 1---------@ @--------- ROUTER 2
| A |@ @| A |
(0):1.1.1.1->C | |@ @| | (0):Default->A
(4):1.1.1.1->A | B C |@ @| B C | (2):1.1.1.1->B
---------@ @---------
@ | @ @ | ^
5 @ | @ @ | @ 2
@ | @ @ | @
v | @ @ | @
OLD BS ----- @ @ ----- NEW BS
/ A \ @ / A \
(0):1.1.1.1->B | | @| | (0):Default->A
(5):1.1.1.1->A \ B / 6 @ \ B / (1):1.1.1.1->B
----- @ --^--
@@ @
@ @ 1
--v- @@@@@@
MOBILE / \
USER \ /
----
IP:1.1.1.1
Figure 3: Non-Forwarding path setup scheme
In this path setup scheme, as the path setup message travels from the
new base station to the old base station, data packets are diverted
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 10]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
at the cross-over router to the new base station, resulting in no
forwarding of packets from the old base station.
The Non-Forwarding scheme is illustrated in Figure 3. In this case,
when the new base station receives the path setup message, it adds a
forwarding entry for the mobile host's IP address with the outgoing
interface set to the interface on which it received this message. It
then performs a routing table lookup for the old base station and
determines the next hop router, Router 2. The new base station then
forwards the path setup message to Router 2 (shown as message 2 in
Figure 3). This router performs similar actions and forwards the
message to Router 0. At Router 0, the cross-over router in this
case, forwarding entries are added such that new packets are diverted
directly to the mobile host at the new base station. Eventually the
message reaches the old base station (shown as message 5 in Figure
3). The old base station changes its forwarding entry and sends an
acknowledgement of the path setup message back to the mobile host
(shown as message 6 in Figure 3).
3 Protocol Processing
In this section, we describe the protocol processing details of
HAWAII path setup schemes. We first describe the format for the path
setup update and refresh messages. We then present the processing at
the mobile host and finally, the protocol processing at the base
stations/routers.
3.1 Message Formats
The format of an update path setup message sent by a mobile host is
shown below. The message is sent using the UDP protocol to a
reserved port. Power up updates (type 1) are sent to the current
base station. Handoff updates (type 2) are sent to the old base
station in the case of the Forwarding scheme, and to the new base
station in the case of the Non-Forwarding scheme. At present, we do
not have a power down update as we rely on the time out of the soft
state forwarding entries. It is conceivable to define an explicit
tear down message to handle this case.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 11]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Scheme | Reason +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Base Station |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Base Station |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Version 1
Type 1 (Power up update), 2 (handoff update),
3 (acknowledgement)
Scheme 1 (Forwarding), 2 (Non-Forwarding)
Reason Used only for Type 3 messages
0 accepted
1 poorly formatted message
2 authentication failed
3 Scheme not supported
Mobile host Address Home address in Home domain,
Care-of address in Foreign domain
Old Base Station Old Base Station IP address for Type 2
0.0.0.0 for Type 1
New Base Station New Base Station IP address for Type 2
Current Base Station for Type 1
Timestamp Timestamp formatted as in
Network Time Protocol [3].
Extensions Authentication field
Wireless link specific fields, for more study
The format for a refresh message is shown next. The message would
contain only one entry when sent by a mobile host and could contain
multiple entries as part of an aggregate refresh when sent by base
stations and routers to their upstream router.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 12]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Size | Reason +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address[N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp[N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Version 1
Type 4 (refresh)
Size Number of mobile host entries
Reason 0 (normal)
1 (triggered due to link/host failure)
Mobile host Address Host-entry address
Timestamp Host-entry timestamp
Extensions Authentication field
3.2 Mobile Host Processing
The processing requirements for a mobile host depends on whether it
is attached to its home domain or a foreign domain. When it is in
its home domain, the mobile host executes a HAWAII client process.
The operation of the HAWAII client is depicted in Figure 4.
When the HAWAII client process begins execution, it reads the host's
configuration parameters (such as its IP address) and sends a power
up update to the domain root router. It then waits for an
acknowledgement in the INIT state. If an acknowledgment is received,
the host enters the ATTACHED state, where it can send and receive
packets. If an acknowledgment is not received after a certain period
of time, the host resends the update message possibly multiple times
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 13]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
until it finally receives an acknowledgement or decides to abandon
executing the client process. If attachment is successful, the
mobile host periodically sends a refresh message to the base station
to which it is attached. The base station will, in turn, generate
hop-by-hop refresh messages upstream, as described earlier.
On startup, send
++++++++ power up update ++++++++ ____ On timeout,
+ +---------------> + +/ | resend power up
+ NULL + + INIT + | update
+ + <---------------+ + <--/
++++++++ Give up resends ++++++++
^ |
^ Give up Inter-domain | | Receive ack from
| resends handoff, send | | domain root router
On timeout, | power up update| |
resend | | v
updates | Receive ack from |
____ +++++++++ base station ++++++++++ ____
| \+ +---------------> + +/ | Send periodic
| + HANDOFF + + ATTACHED + | refreshes
\--> + + <---------------+ + <--/
+++++++++ Intra-domain ++++++++++
handoff, send
handoff update
Figure 4: HAWAII Client State Diagram
When the mobile host moves to a new base station, if a domain
boundary is crossed, the mobility client is notified that a
inter-domain handoff has occurred and it is also informed of the new
care-of address. The host then triggers the creation of host-based
forwarding entries in the new domain through a power up update. If
the mobile host moves to a new base station but does not cross a
domain boundary, then the HAWAII client is notified of a intra-domain
handoff. It is also informed of the IP address of the new
base-station. The client then triggers a handoff update message and
moves into the HANDOFF state. If the acknowledgement is received,
the host returns to the ATTACHED state. If not, the host continues
to send handoff update messages and wait for a reply until it
succeeds in getting a reply or decides to abandon executing the
client process.
There are several ways in which the handoff detection and
notification may be implemented. A typical solution is to have the
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 14]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
base stations send beacons periodically with their IP address and a
domain identifier. A mobile client monitoring these beacons can then
detect handoffs and it will have the necessary configuration
information for its operation. If it is necessary to interoperate
with existing base station beacons which do not contain information
regarding IP addresses or domain identifiers, then it is possible to
have the mobile client query the base station by sending link layer
point to point messages. The details of different query response
mechanisms are to be discussed.
As stated earlier, there are additional processing requirements when
the mobile host is in a foreign domain. The mobile host needs a
mechanism for acquiring a care-of address (such as a DHCP client) and
a co-located foreign agent as in Mobile-IP [6]. The mobile host must
first acquire its care-of address before the HAWAII client sends a
power up update in the new domain. After the update processing is
completed, the foreign agent will register the care-of address with
its home agent.
3.3 Base Station/Router Processing
The pseudo-code for processing an power up update message in both the
Forwarding and Non-forwarding schemes is shown in Figure 5. Each
base station simply adds an entry for the mobile host and forwards
the message to next hop router along its ``default'' route. Note
that we assume that the default route is the same as the route to a
domain root router (gateway). When the message reaches a domain root
router, an acknowledgement is sent to the mobile host.
--------------------------------------------------------------------
Figure 5: HAWAII power up Update processing for both schemes
--------------------------------------------------------------------
1. Receive Power Up Update message from mobile host on Interface 1
2. Message contains MH IP ADDRESS, TIMESTAMP
3. Add/Update entry {MH IP ADDRESS -> Interface 1}, set timer
4. If I am the Domain Root Router
Generate an acknowledgement back to the MH
else
Forward update to upstream neighbor along the default route
endif
--------------------------------------------------------------------
The pseudo-code for processing an update message in the Forwarding
and Non-Forwarding schemes is shown in Figure 6(a) and Figure 6(b)
respectively. The processing of an update message is fairly simple:
on receiving the message, modify the forwarding entry for the mobile
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 15]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
host in the kernel and forward the update message towards its
destination.
--------------------------------------------------------------------
Figure 6(a): HAWAII handoff processing for the Forwarding scheme
--------------------------------------------------------------------
1. Receive Update message from neighbor on Interface 1
2. Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP
3. If NEW BS ADDRESS matches one of my interface addresses then
Let Interface 2 be my wireless interface
else
Look up routing table for NEW BS ADDRESS and determine
next hop router and outgoing interface Interface 2
endif
4. If TIMESTAMP is newer then
Add/Update entry {MH IP ADDRESS -> Interface 2}, set timer
endif
5. If NEW BS ADDRESS matches one of my interface addresses then
Generate an acknowledgement back to the MH
else
Forward message to next hop router determined in step 3
endif
--------------------------------------------------------------------
Figure 6(b): HAWAII handoff processing for the Non-forwarding scheme
--------------------------------------------------------------------
1. Receive Update message from neighbor on Interface 1
2. Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP
3. If TIMESTAMP is newer then
Add/Update entry {MH IP ADDRESS -> Interface 1}, set timer
endif
4. If OLD BS ADDRESS matches one of my interface addresses then
Generate an acknowledgement back to the MH
else
Look up routing table to find next hop router for OLD BS ADDRESS
Forward message to next hop router
endif
--------------------------------------------------------------------
The soft-state refresh messages are sent independently by each of the
nodes on a hop by hop basis. The mobile host refreshes the base
station every TH seconds. The base stations and routers send
refreshes to their upstream routers (determined based on their
default route to the domain root router) every TR seconds. Typically
TH would be much larger than TR in order to conserve the limited
wireless bandwidth. When the refresh message is received, the expiry
timer corresponding to the refresh entry is updated. This involves
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 16]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
no update to the kernel routing table and can be done very
efficiently. Furthermore, a single refresh message can refresh
several mobile hosts, thus amortizing on the cost of
sending/receiving the message. The pseudo-code for processing a
refresh message is shown in Figure 7. One important point to note is
the need for a user-specific timestamp in the path setup messages.
The timestamp guards against a potential race-condition involving a
soft-state refresh from an old base station competing with a recent
update message from a new base station.
--------------------------------------------------------------------
Figure 7: HAWAII refresh processing for both schemes
--------------------------------------------------------------------
1. Receive Refresh message from authenticated neighbor on Interface 1
2. Message contains multiple tuples of {MH IP ADDRESS, TIMESTAMP}
3. For each tuple do
If entry exists for MH IP ADDRESS then
If TIMESTAMP is greater than timestamp in the entry then
If entry already has interface as Interface 1
/* Most common case - no failure */
reset timer on forwarding entry
else
/* interface changed failure,don't propagate up */
update entry {MH IP ADDRESS -> Interface 1}, set timer
endif
endif
else
/* Non-existent MH entry failure, propagate up */
Add entry {MH IP ADDRESS -> Interface 1}, set timer
Send immediate update (batched) using the default route
endif
4. Periodically send batch refresh upstream for all entries
5. When the default route changes
send batch refresh upstream for all entries
-------------------------------------------------------------------
4 Design Implications
In this section, we illustrate the advantages of the HAWAII approach
by studying the implications on scalability, QoS support, and
reliability.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 17]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
4.1 Scalability
In this section, we illustrate the advantages of HAWAII's local
mobility through a numerical example. Consider a domain with
configuration parameters as shown in Table 1. The domain is in the
form of a tree with three levels: at the highest level there is a
single domain router; at the second level there are seven
intermediate routers; at the third and lowest level, there are 140
base stations (twenty per router). We also assume that the coverage
area of a base station is a square with a given perimeter. For this
configuration, we compute the rate of mobility related messages for
two different approaches: 1) Mobile-IP approach where FAs are
present at each base station and are served by a HA and 2) the HAWAII
approach where the HA is at the domain root router.
Table 1: Domain Configuration values
--------------------------------------------------------------------
Item Type Value
--------------------------------------------------------------------
B Base stations per domain root router 140
R Second level router per domain root router=(B/S) 7
D User density (active users) 39 per sq km
V User speed 112 km/hr
TR Router refresh timer for HAWAII 30 seconds
Y No. of mobile host entries in refresh in HAWAII 25
TM Mobile-IP binding lifetime 300 seconds
Z Fraction of users in foreign domain in HAWAII 0.1
LB Perimeter of base station 10.6 km
A Coverage area of domain = B*LB*LB/16 = 980 sq km
LD Perimeter of domain = SquareRoot(A)*4 = 125.2 km
LR Perimeter of 2nd level router=SquareRoot(A/R)*4 47.3 km
N Number of users in domain = B*D = 38,720
--------------------------------------------------------------------
First note that the coverage area of this domain is quite large:
A = 980km2. If we need to scale to larger areas, we would use
Mobile-IP to handoff between these domains. The number of forwarding
entries at the domain root router in the case of the HAWAII approach
is the same as the total number of active users in the domain, and is
N = 38, 220. This is well within the capability of a modern router.
Furthermore, a majority of these entries are completely specified
entries of hosts from a particular domain/subnet. In this case,
perfect hashing is possible resulting in O(1) memory access for IP
route lookup. Thus, route lookup for data forwarding can be done
efficiently at the domain routers.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 18]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
We now compute the impact of mobility-related messages for the two
approaches. First consider a system based on Mobile-IP. Assuming the
direction of user movement is uniformly distributed over [0,2pi] and
using a fluid flow mobility model [5], the rate of mobile hosts
crossing a boundary of perimeter l at a speed V is given by
f(l)=(D*V*l)/(3600*pi). Since user handoffs between any two base
stations in the domain generates an update registration at the HA,
the number of mobility related updates at the HA from B base stations
is f(LB)*B. The rate of registration renewals for N users is N/TM
since every renewal period, each user send out one renewal request.
Now consider a system based on HAWAII. The domain root router, which
houses the home agent, is the most heavily loaded router in this
system as it has to process both path setup messages as well as
Mobile-IP messages. The rate of Mobile-IP registrations, which occur
only when user cross domain boundaries, is f(LD). The rate of
Mobile-IP registration renewals, which are sent by only those users
that are away from their home domain, is (Z*N)/TM. Path setup updates
at the domain root router are generated whenever a user is handed off
between base stations attached to two different second level routers.
Thus, the rate of path setup updates is f(LR)*R. Path setup refreshes
are aggregates, generated for each user. Thus, the rate of path
setup refreshes is (Ceiling(N/Y)/TR).
Table 2: Frequency of Mobility related messages (per second)
--------------------------------------------------------------------
Type HAWAII at Domain Root Router Mobile-IP at Home Agent
--------------------------------------------------------------------
HAWAII update 127.8 0
HAWAII refresh 51.3 0
Mobile-IP registration 48.4 574
Mobile-IP renewals 12.7 127.4
--------------------------------------------------------------------
Total 240.2 701.4
--------------------------------------------------------------------
The frequency of various mobility related messages for the
configuration shown in Table 1 is summarized in Table 2. The total
number of control messages received by a HA in Mobile-IP (701.4) is
almost three times the number of messages received by a domain root
router in HAWAII (240.2).
4.2 Quality of Service Support
The fact that HAWAII maintains the IP address of the mobile host
unchanged within a domain even as it moves simplifies the provision
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 19]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
of flow-based QoS. In this section, we illustrate the ease with which
the well-known resource reservation protocol, RSVP [9], is integrated
with HAWAII.
________________
|CORRESPONDENT |---
|HOST AS SENDER | |
|________________| ~
IP:2.2.1.1 ~ [1.1.1.1->C]*** 1
| * Asynchronous
--------- v notification
| A | {DEST, PHOP, NHOP}
ROUTER 0 | | {(0):2.2.1.1,A,B}
| B C | {(7):2.2.1.1,A,C}
------+--<+++++
/ @ \ +
/ @ \ + 7
/ 2 @ \ +
/ v \ +
ROUTER 1--------- --------- ROUTER 2
| A | | A |
[1.1.1.1->A] | | | | [1.1.1.1->B]
| B C | | B C |
--------- --------- {DEST, PHOP, NHOP}
| @ | ^ {(2):2.2.1.1,A,-}
| 3 @ | + 6 {(6):2.2.1.1,A,B}
| @ | +
| v | +
OLD BS ----- ----- NEW BS
/ A \ / A \
| | | |
[1.1.1.1->A] \ B / \ B / [1.1.1.1->B]
----- 4 @-^--
@@@@@@@ + {DEST, PHOP, NHOP}
@ + 5 {(3):1.1.1.1,A,-}
--v- ++++++ {(5):1.1.1.1,A,B}
MOBILE HOST / \
AS RECEIVER \ / @@@@@> PATH
---- +++++> RESV
IP:1.1.1.1
Figure 8: RSVP flows when mobile host is a receiver
RSVP inherently assumes that hosts have fixed addresses, which is
usually not the case for mobile hosts. When using Mobile-IP, the
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 20]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
mobile host's home address is fixed, but its care-of-address changes.
Since RSVP uses the destination address of the end node, i.e. the
mobile host, for identifying a session, one has to redo the resource
reservation along the entire path from the correspondent host (or HA)
to the mobile host on every handoff of the mobile user. This must be
performed even though most of the path is probably unchanged, as
handoff is a local phenomenon. This results in increased reservation
restoration latency and unnecessary control traffic.
In the case of HAWAII, support for QoS is straightforward since a
mobile host's address remains unchanged as long as the user remains
within a domain. The interaction between HAWAII and RSVP when the
mobile host is a receiver is shown in Figure 8. The state in the
square braces represents HAWAII forwarding state while the state in
the curly braces represents RSVP state. After Router 0 processes a
HAWAII path setup update, its RSVP daemon receives a path change
notification (PCN) (message 1) using the routing interface for
RSVP [8]. In standard RSVP, the router must now wait a time interval
before generating the RSVP PATH message to allow the route to
stabilize; this time interval is set to two seconds by default. In
HAWAII, the RSVP PATH message (message 2) can be triggered
immediatedly on receiving a PCN since the route to the mobile host is
stable at that point. This allows for a faster reconfiguration due
to mobility. The PATH message follows the new routing path (messages
2 and 3), installing PATH state on all the routers towards the new
base station. When this PATH message reaches the mobile host, a QoS
agent on the host generates an RSVP RESV message upstream that
follows the reverse forwarding path (messages 5, 6, and 7). Router 0
stops forwarding the RESV messages upstream since there is no change
in the reservation state to be forwarded. Thus, reservations are
restored locally in a timely manner. The case when the mobile host
is a sender is fairly simple. A RSVP PATH message is sent by the
mobile host after handoff as soon as the HAWAII path setup is
complete, resulting in reservations along the new path.
Note that the straightforward integration of RSVP and HAWAII is due
to the fact that RSVP was designed to blindly follow the routing path
established and maintained by an independent routing entity. The
HAWAII path setup messages for a mobile host handoff are no different
from any other routing changes to which RSVP was designed to respond.
Thus, intra-domain handoffs in HAWAII are handled efficiently; since
they are localized, they result in fast reservation restorations for
the mobile user. In the case of inter-domain handoffs, since HAWAII
defaults to Mobile-IP for mobility management, reservation
restorations would follow along the procedures elaborated by the
Mobile-IP working group.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 21]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
4.3 Reliability
Failure of Home Agents is a concern for any approach that is based on
Mobile-IP. In HAWAII as well as Mobile-IP, this failure could be
tackled through the configuration and advertisement of backup home
agents. Other approaches that rely on hot backups are also possible.
However, recall that in HAWAII, in the common case of a mobile host
not leaving its ``home'' domain, there is no HA involved. This
greatly reduces HAWAII's vulnerability to HA failure as compared to
the Mobile-IP schemes. Furthermore, HAWAII does not have any foreign
agents inside the network architecture, eliminating another source of
failure. Consequently, approaches in which the FA and the HA lie in
the data path between the correspondent host and the mobile host
suffer from reliability concerns not present in the HAWAII approach.
Link and router failures are handled through the soft-state refresh
mechanism in HAWAII. The routing daemon running at each router would
detect these failures and update its default route entry. This will
trigger an immediate soft-state refresh of all its host entries to a
new uplink router (see Figure 7 for details). This will result in
further propagation of soft-state refresh messages until a router
that has pre-existing entries for the affected mobile hosts is
notified (this will be the domain root router in the worst case).
Finally, we need to address the issue of failure of HAWAII process
itself without an accompanying router failure. To recover, the
HAWAII process must simply be restarted as the subsequent soft-state
refreshes correct the existing state. This may be addressed by
several means. For instance, a process monitor resident in the same
router as the HAWAII process could issue a restart upon detecting a
non-responsive process.
5 Address Assignment
So far we have not made specific assumptions about how each mobile
host acquires its IP addresses. In particular, we do not assume any
correlation between the domain topology hierarchy and the actual
address assignments to mobile hosts. Instead, we assume a flat
address assignment algorithm in the domain. To put it another way,
mobile hosts are assigned the next available address in the domain
when they request one.
Recall that, in HAWAII, each host potentially needs two IP addresses:
one to operate in its home domain, and (possibly) a second when it
moves outside its home domain. The first address can be assigned
statically by manual configuration, that then leaves open the
question of how inter-domain mobility should be handled.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 22]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Alternately, and this is the approach preferred by HAWAII, we could
use DHCP to acquire both the addresses dynamically. We explore each
of these options in the following paragraphs.
An option is manual configuration of the home address, but this has
implications when the host moves outside its home domain. In this
situation, when the host moves outside its home domain, it has to
either acquire a co-located care-of-address for itself through manual
configuration or other means. Alternately, it might use a foreign
agent in the new domain, and act as a ``vanilla'' mobile-IP agent;
however, it then needs to attach itself to a new foreign agent every
time it moves, even within the new domain, mitigating the gains
possible in using HAWAII.
The other option is to acquire both the home address and the
co-located care-of-address through DHCP [1]. The mobile can retain
the home address for the duration of its lifetime; we call this the
quasi-permanent address of the mobile. This domain also becomes the
mobile host's home domain. Because mobile hosts typically act as
clients, as they activate applications, their servers will learn
their IP addresses. If the mobile host moves into a different domain
while powered up, it is assigned a second IP address through DHCP in
the new domain. This address becomes the mobile host's co-located
care-of address. The mobile host still retains the quasi permanent
address assigned in its home network, and packets are tunneled
to/from a home agent in its home network to its current location. In
this way, mobility is transparent to the corresponding servers and
applications. When the host is powered down, it gives back all its
assigned addresses (permanent address and care-of address, if any).
This requires modifying the client side of DHCP so that the client
maintains leasing relationships with two different DHCP servers at
the same time. The exact nature of this modification and its
implications to DHCP are outside the scope of this specification.
The use of a quasi permanent address is similar to the ``dialup''
model of service provided by Internet Service Providers to fixed
hosts. The difference is that the users in HAWAII are mobile and the
home domain is determined by where the host is powered up rather than
which modem access number is dialed. Apart from requiring fewer IP
addresses, this optimization also results in optimal routing as long
as the user does not move out of a domain while powered up.
6 Security
There are two issues in security: user authentication by the DHCP
server during address assignment, that occurs during power up and
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 23]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
inter-domain moves; and security and authentication related to HAWAII
protocol messages.
This document does not specify solutions for addressing the security
issues related to DHCP server authentication of a mobile user.
Mechanisms such as the RADIUS protocol [7] could be used to perform
the authentication. After the IP address assignment phase, a user
specific key would be downloaded into the current base station.
A second issue is to disallow arbitrary users from sending path setup
messages, thereby subverting another host's traffic. The path setup
messages we propose can be made secure because they all require the
old base station to cooperate. The new base station can ensure that
all handoff update path setup messages are destined for some base
station. When the mobile host is handed off to a new base station,
the old base station approves of the path setup message only if the
mobile host is able to authenticate itself in the path setup message.
The user specific key can then be transferred from the user's old
base station to the new base station. An advantage of this approach
is that authentication is performed at the base stations (except
during power up) in a distributed fashion. This approach also
results in a natural protocol for key management where the
user-specific key is handed off with the user from one base station
to another. If the key management cannot be distributed, it is
possible to have a centralized authentication server and have the
base stations authenticate the path setup messages using this server.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 24]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Appendix A - Patent Issues
This is to inform you that Lucent Technologies has applied for and/or
has patent(s) that relates to the attached submission.
This submission is being made pursuant to the provisions of IETF IPR
Policy, RFC 2026, Sections 10.3.1 and 10.3.2.
Lucent Technologies Inc. will offer patent licenses for submissions
made by it which are adopted as a standard by your organization as
follows:
If part(s) of a submission by Lucent is included in a standard and
Lucent has patents and/or pending applications that are essential
to implementation of the included part(s) in said standard, Lucent
is prepared to grant - on the basis of reciprocity (grantback) - a
license on such included part(s) on reasonable, non-discriminatory
terms and conditions.
References
[1] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for
Comments 2131, Mar 1997.
[2] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet
Draft, Work in Progress, Nov 1998.
[3] G. Malkin, ``RIP Version 2 Carrying Additional Information,''
Request for Comments 1723, Nov 1994.
[4] D. Mills, "Network Time Protocol (Version 3): Specification,
Implementation and Analysis", RFC 1305, Mar 1992.
[5] S. Mohan and R. Jain, ``Two User Location Strategies for Personal
Communications Services,'' IEEE Personal Communications, Vol 1.,
No. 1, pp. 42-50.
[6] C.E. Perkins, ``IP Mobility Support,'' Request for Comments 2002,
Oct 1996.
[7] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote
Authentication Dial in User Service (RADIUS),'' Request for
Comments 2138, Apr 1997.
[8] D. Zappala and J. Kann., "RSRR: A Routing Interface for RSVP",
Internet Draft, Jul 1998
[9] B. Braden et. al., ``Resource Reservation Protocol (RSVP) -
Version 1 Functional Specification,'' Request for Comments 2205,
Sep 1997.
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 25]
INTERNET-DRAFT IP micro-mobility support using HAWAII 19 February 1999
Authors' Addresses
R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan
Bell Labs, Lucent Technologies,
101 Crawfords Corner Road,
Holmdel, NJ 07733 (USA)
Phone: 732-949-3306
Fax: 732-949-4513
Email: {ramjee,tlp,thuel,kvaradhan}@bell-labs.com
Ramjee/La Porta/Thuel/Varadhan Expires 19 August 99 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-21 20:32:19 |