One document matched: draft-ietf-mobileip-hawaii-00.txt
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
maintaining soft-state forwarding entries for the mobile hosts and
leveraging fault detection mechanisms built in existing intra-domain
routing protocols.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 1]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
Contents
1 Changes from version 00 3
2 Introduction 3
2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Design Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Network Architecture . . . . . . . . . . . . . . . . . 7
2.4.2 Path Setup Schemes . . . . . . . . . . . . . . . . . . 8
2.4.3 Soft-State . . . . . . . . . . . . . . . . . . . . . . 9
3 Path Setup Schemes 9
3.1 Forwarding Path Setup Scheme . . . . . . . . . . .. . . . . 11
3.2 Non-Forwarding Path Setup Scheme . . . . . . . . . . . . . . 12
4 Protocol Processing 13
4.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Mobile Host Processing . . . . . . . . . . . . . . . . . . . 16
4.3 Base Station and Router Processing . . . . . . . . . . . . 17
5 Design Implications 21
5.1 Scalability . . . . . . . . . . . . . . . . . . . . .. . . . 22
5.2 Quality of Service Support . . . . . . . . . . . . . . . . . 23
5.3 Reliability . . . . . . . . . . . . . . . . . . . . .. . . . 26
6 Address Assignment 26
7 Security 28
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 2]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
1 Changes from version 00
o HAWAII is now transparent to hosts that are compatible with
Mobile-IP with route optimization, challenge/response and NAI
extensions. The mobile host simply sends regular Mobile-IP
registration messages and HAWAII is triggered transparently
inside the domain. One important benefit of this approach is
that the Mobile-IP security model is now directly applicable for
authenticating all messages from the mobile host. A second
benefit is that movement between Mobile-IP networks and HAWAII
domains is seamless.
o Clarified how HAWAII path setup updates will work in topologies
where there are multiple paths between the mobile host and the
domain root router.
o Clarified that the assumption in the draft that base stations
have IP addresses is used only for discussion purposes.
Mobile-IP and HAWAII handoff procedures are only activated when
the mobile host's next hop IP node is changed during the
handoff; this next hop may or may not be a base station.
o Clarified the discussion on the reliability mechanisms of
HAWAII. The emphasis is on leveraging fault detection mechanisms
from existing intra-domain routing protocols for increased
reliability rather than defining special purpose recovery
mechanisms for mobility agents.
o Added a metric field to HAWAII messages in order to distinguish
alternate paths in certain non-tree topologies.
o Added routing-lifetime field to HAWAII refresh message to
accurately synchronize soft-state timers.
o Added a constraint on the size of HAWAII aggregate refresh
messages to 4KB.
o Draft name changed from
draft-ramjee-micro-mobility-hawaii-00.tex to
draft-ietf-mobileip-hawaii-01.tex
2 Introduction
Mobile-IP is the current standard for supporting macro-mobility in IP
networks [11]. 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
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 3]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
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 and high
latency and disruption during handoff. 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).
HAWAII operates entirely within the administrative domain of the
wireless access network. In order to keep HAWAII transparent to
mobile hosts, the mobile host runs the standard Mobile-IP protocol
with NAI, route optimization and challenge/response extensions. To
reduce the frequency of updates to the HA and avoid high latency and
disruption during handoff, in HAWAII, we split the processing and
generation of Mobile-IP registration messages into two parts:
between the mobile host and the base station and between the base
station and the HA. Note that this separation is needed for any
approach that desires to reduce updates to the HA. For example,
similar separation at the foreign agent is proposed in the Mobile IP
Regionalized Tunnel Management approach as well [4].
Another issue concerning the integration of HAWAII and Mobile-IP
protocols is the choice of a co-located care-of address (CCOA) option
in HAWAII. As we shall see later, the use of a CCOA option has
several advantages in terms of QoS support. On the other hand, in
basic Mobile-IP, hosts that use CCOA are expected to always contact
the HA directly. Again, this is in conflict with reducing the
frequency of updates to the HA. We advocate that the mobile hosts be
able to register with a base station even while using the CCOA
option. The base station helps reduce the frequency of updates to
the HA by processing the registrations locally and also ensures
smooth handoff by forwarding packets if necessary. This approach
also allows networks to enforce security and authentication measures
in their domain. Thus, in our approach, data packets are sent
directly from the HA to the mobile host while registrations are
processed in two stages at the base station and the HA.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 4]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
2.1 Goals
We have three design goals in HAWAII:
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.
2.2 Assumptions
Our proposal for supporting mobility hinges on the assumption that
most user mobility is local to a domain, in particular, an
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.
2.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 user is assigned a home domain based on its Network
Access identifier(NAI). The NAI [5] field in the registration
message will help identify the mobile host's domain.
Foreign Domain
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 5]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
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.
2.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
maintaining forwarding state. We discuss each of these issues
separately in the following sections.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 6]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
2.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
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 to Section 6. When moving in its home domain, the mobile
host retains its IP address. Packets destined to the mobile host
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 7]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
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 5.2. 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 6.
2.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 3, we describe two such path setup schemes.
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 5.1, we present a numerical example showing how a single
domain in HAWAII can cover an area of approximately 1000Km2 for
typical network configuration values, without any difficulty in
processing mobility related updates.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 8]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
2.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 triggered at the base station following
Mobile-IP registrations sent by the mobile host during power up and
following handoffs. These messages are explicitly acknowledged by
the recipient. Note that the HAWAII handoff procedures are only
activated when the mobile host's next hop IP node is changed during
the handoff. Thus, for discussion, we assume base stations have IP
routing functionality in this draft. In actual deployed networks,
the mobile host's next hop IP node may or may not be a base station.
The mobile host also sends periodic Mobile-IP renewal registrations
to the base station. The base stations and routers, in turn, send
HAWAII aggregate refresh messages periodically in a hop-by-hop manner
to the routers upstream of the mobile hosts. As we shall see in the
following sections, HAWAII messages are sent to only selected routers
in the domain, resulting in very little overhead associated with
maintaining soft-state.
3 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 Mobile-IP registration
message to its nearest base station. The base station then
propagates a HAWAII path setup update message to the domain root
router using a configured default route. 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 base station which then sends a
Mobile-IP registration reply 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
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 9]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
host-based forwarding entries just established. These host-based
forwarding entries are soft-state entries that are kept alive by
periodic hop-by-hop refresh messages.
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.
When the topology has multiple paths between the base station and the
domain root router, the base station and routers will have multiple
routes for the domain root router (or multiple default routes). Each
base station and router can choose any of these routes to forward the
path setup message for a particular mobile host that has powered up.
In this case, the base station or router must ensure that subsequent
refreshes for a given mobile host always goes through the same route.
Thus, all the packets for a particular mobile host will arrive on the
same path from the domain root router resulting in no re-ordering.
At the same time, multiple paths between the domain root router and
the base station are utilized for the different users attached to a
base station.
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.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 10]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
3.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.
| (0):1.1.1.1->B
--------- (4):1.1.1.1->C
| A |
ROUTER 0 | |
| B C |
@@@@@>--------- @@@@@
@ / @@@@ \ @
4 @ / @ @ \ @ 5
@ / @ @ \ v
ROUTER 1---------@ @--------- ROUTER 2
| A |@ @| A |
(0):1.1.1.1->B | |@ @| | (0):Default->A
(3):1.1.1.1->A | B |@ @| B | (5):1.1.1.1->B
---------@ @---------
^ | @ @ | @
3 @ | @ @ | @ 6
@ | @ 2 @ | v
OLD BS -----<@ @ ----- NEW BS
/ A \ @/ A \
(0):1.1.1.1->B | | | | (0):Default->A
(2):1.1.1.1->A \ B / \ B / (6):1.1.1.1->B
----- 1 $$>-----
$ $ 7
$ $
---- <$$$$$
MOBILE / \
USER \ / $: Mobile-IP messages
---- @: HAWAII messages
IP:1.1.1.1
Figure 2: Forwarding path setup scheme
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. A Mobile-IP registration is first sent by the mobile
host to the new base station. The message contains the old base
station's address as part of the Previous Foreign Agent Notification
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 11]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
Extension (PFANE) [12]. The new base station then sends a path setup
update to the old base station. 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 entry for the mobile host's IP address
with the outgoing interface set to interface A. It then forwards the
message to Router 1 (message 3). 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 (message 6). The
new base station changes its forwarding entry and sends a Mobile-IP
registration reply to the mobile host (message 7).
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.
3.2 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
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 a Mobile-IP registration with the
PFANE field, 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 (identified using the PFANE field in the
registration message) and determines the next hop router, Router 2.
The new base station then forwards the path setup message to Router 2
(message 2). 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 (message 5). The old base
station changes its forwarding entry and sends an acknowledgement of
the path setup message back to the new base station which then sends
a Mobile-IP registration reply to the mobile host (message 7).
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 12]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
| (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->B | |@ @| | (0):Default->A
(4):1.1.1.1->A | B |@ @| B | (2):1.1.1.1->B
---------@ @---------
@ | @ @ | ^
5 @ | @ 6 @ | @ 2
v | @ @ | @
OLD BS ----- @ v---- NEW BS
/ A \ / A \
(0):1.1.1.1->B | | | | (0):Default->A
(5):1.1.1.1->A \ B / 7 \ B / (1):1.1.1.1->B
----- $$$--^--
$ $
$ $ 1
--v- $$$$$$
MOBILE / \
USER \ / $: Mobile-IP messages
---- @: HAWAII messages
IP:1.1.1.1
Figure 3: Non-Forwarding path setup scheme
4 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.
4.1 Message Formats
In this section, we discuss the message formats for the HAWAII
messages sent between base stations and routers within a domain. The
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 13]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
format for messages sent between the mobile hosts and base stations
follow the Mobile IP standard with the extensions described later.
The format of a HAWAII update path setup message sent by base
stations and routers 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.
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 | Reason | Scheme +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rsv |S|B|D|M|G|V|rsv| Mobile IP Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | Routing Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Base Station |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Base Station |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Version 1
Type 1 (Power up update), 2 (handoff update),
3 (acknowledgement)
Reason Used only for Type 3 messages
0 accepted
1 poorly formatted message
2 authentication failed
3 Scheme not supported
4 Resource not available
Scheme 1 (Forwarding), 2 (Non-Forwarding)
Mobile host Address Home address in Home domain,
Care-of address in Foreign domain
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 14]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
rsv Reserved, sent as 0
S,B,D,M,G,V Flags from Mobile IP registration
Mobile IP lifetime Lifetime field in Mobile IP registration
Metric Distance to the mobile host in hops
Routing Lifetime Soft state timer value
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 [9].
Extensions Authentication field
Wireless link specific fields, for study
The format for a refresh message is shown next. The message could
contain multiple entries as part of an aggregate refresh when sent by
base stations and routers to their upstream router. However, the
message size MUST not exceed 4KB.
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 | Reason | Size +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric[1] | Routing Lifetime[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address[N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric[N] | Routing Lifetime[N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp[N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 15]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
Version 1
Type 4 (refresh)
Reason 0 (normal)
1 (triggered due to link/host failure)
Size Number of mobile host entries
Mobile host Address Host-entry address
Metric Distance to the mobile host in hops
Routing Lifetime Soft state timer value (remaining)
Timestamp Host-entry timestamp
Extensions Authentication field
4.2 Mobile Host Processing
Since the mobile host is only aware of Mobile-IP and not HAWAII, it
executes a regular Mobile-IP client state machine and issues
Mobile-IP registration messages with the various extensions discussed
below. Our goal is to ensure that there is sufficient information at
the mobile host and the base station so that seamless mobility
between HAWAII and Mobile-IP domains is possible.
Recall that HAWAII divides the access network into domains. We
propose to use Network Access Identifiers (NAI's) [1] to identify the
different HAWAII domains. Also, each mobile host in HAWAII is
associated with a home domain and the Mobile-IP Home Agent is
involved only when the mobile host is visiting a foreign domain.
However, even while the mobile host is moving in the HAWAII home
domain, we require that the host send registrations to the base
station on every handoff so that the HAWAII host-based entries are
re-established locally. This is accomplished as follows.
Let us assume that each mobile host (user) is configured (either
statically or dynamically) with a NAI, home address, netmask, and a
home domain. The netmask at the mobile host is setup (for example, a
netmask of all 1's) so that every base station advertisement appears
to the mobile host as though it is served by a foreign network as far
as the Mobile-IP client is concerned. In this scenario, whenever the
host detects a change of base station it MUST issue a Mobile IP
registration request to the new base station. We use these
registrations to trigger HAWAII path setup schemes inside the domain.
Another issue is the need for a mobile host to acquire a co-located
care-of address when the host is in a HAWAII foreign domain and use
its home address in the HAWAII home domain. We compare the NAI
advertised by the base station with the mobile host's NAI to
distinguish whether a mobile host is in its HAWAII home domain or a
HAWAII foreign domain. If the NAI advertised by the base station
matches the mobile host's NAI, the mobile MUST register with the base
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 16]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
station using the advertised (non co-located) COA; otherwise, the
mobile host MUST register with the base station using a co-located
COA (CCOA). In the latter case, the mobile MUST be prepared to
decapsulate packets arriving at its interface. Note that, in either
case, this registration is used for establishing host-based entries
in the domain and updating the home agent on inter-domain handoffs;
the base station in HAWAII does not perform any decapsulation.
Whether the mobile host is using a co-located COA or not, the request
MUST include a Previous-Foreign Agent Notification extension [12]
(PFANE) unless this is the first registration after being powered up.
The registration MUST also include all the mandatory extensions
defined in [RFC2002], the mobile-foreign authentication extension,
the mobile-challenge-response extension [14] and the NAI
extension [5].
Furthermore, the mobile host MUST be prepared to receive registration
replies generated by the base station without the involvement of the
HA, thus not including the mobile-home authentication extension.
Nevertheless, such registration replies MUST include a valid
mobile-foreign authentication extension.
The details of processing at the mobile host are shown in Figure 4.
--------------------------------------------------------------------
Figure 4: Mobile host processing
--------------------------------------------------------------------
1. If the OLD BS and NEW BS' NAI match /* intra-domain move */
If the mobile host's NAI matches the NEW BS advertised NAI
/* HAWAII home domain */
1.1 send Mobile-IP registration to NEW BS using advertised COA.
else /* HAWAII foreign domain */
1.2 send Mobile-IP registration to NEW BS using previous CCOA.
endif
else /* inter-domain move */
1.3 acquire CCOA through DHCP
1.4 send Mobile-IP registration to NEW BS using new CCOA.
endif
--------------------------------------------------------------------
4.3 Base Station and Router Processing
We now describe base station and router processing of HAWAII
messages. While routers process only HAWAII messages, base stations
have the additional responsibility of implementing the Mobile-IP
foreign agent functionality (without the decapsulation function) and
originating HAWAII messages for processing within the domain.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 17]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
The base stations periodically issue agent advertisement messages,
and reply to agent-solicitation messages. Agent advertisement
messages MUST include the foreign-agent-challenge extension [14] and
the NAI of the administrative domain to which the base station
belongs. The base station authenticates the mobile host's request
using the challenge mechanisms defined in [14] in addition to the
authentication mechanisms defined in basic Mobile IP.
On receipt of a registration request with a valid mobile-foreign
authentication and a valid challenge-response, the base station MUST
check whether the mobile host's NAI present in the request matches
the NAI of the domain to which it belongs. If the two match, the
base station SHOULD reject any request that is registering the mobile
with a co-located COA. If the registration is valid, the base station
generates HAWAII power-up or handoff update messages based on whether
the PFANE field is present or not. When necessary, the base station
is also responsible for registering with the home agent (see Figures
5 and 7 for the details).
The pseudo-code for processing power up update messages is shown in
Figures 5 and 6. Each node 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 base station which
generates a registration replay to the mobile host.
--------------------------------------------------------------------
Figure 5: Power up processing at base station
--------------------------------------------------------------------
1. Receive registration message from a new mobile host on Interface A
(The PFANE is not present since this is the first registration)
2. If mobile host's NAI matches domain's NAI
/* This domain is the host's home domain */
2.1 Authenticate message: if failure, abort with a negative reply
2.2 Add/Update entry {MH IP ADDRESS -> Interface A}, set timer
2.3 Send HAWAII Power up update message to upstream neighbor
along one of the default routes
else /* This domain is the host's foreign domain */
2.4 Send message to the mobile host's home agent
2.5 If registration is accepted by home agent, execute 2.2
endif
3. If HAWAII ack is received, send registration accept reply with
mobile-foreign authentication extension
--------------------------------------------------------------------
Figure 6: HAWAII power up update processing at router
--------------------------------------------------------------------
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 18]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
1. Receive Power Up Update message from mobile host on Interface A
Message contains MH IP ADDRESS, METRIC, TIMESTAMP
2. Add/Update entry {MH IP ADDRESS -> Interface A}, set timer
3. If I am the Domain Root Router
3.1 Generate an acknowledgement back to the base station
else
3.2 Update METRIC and forward update to upstream neighbor
along one of the default routes
endif
--------------------------------------------------------------------
The pseudo-code for processing a update message during handoff in the
Forwarding and Non-Forwarding schemes is shown in Figure 7(a) and
Figure 7(b) respectively. The basic processing of an update message
at a router is fairly simple: on receiving the message, modify the
forwarding entry for the mobile host in the kernel and forward the
update message towards the new or the old base station depending on
whether the Forwarding or Non-Forwarding schemes are used.
--------------------------------------------------------------------
Figure 7(a): HAWAII handoff processing for the Forwarding scheme
--------------------------------------------------------------------
1. If Registration message with PFANE extension is received,
If mobile host's NAI matches domain's NAI /* intra-domain */
1.1 send an Update message to Old base station.
else /* inter-domain */
1.2 send registration to home agent
1.3 If registration is accepted by home agent, execute 1.1
endif
endif
2. Receive Update message on Interface A
Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP
3. If NEW BS ADDRESS matches one of local interface addresses then
3.1 Let Interface B be the local interface
else
3.2 Look up routing table for NEW BS ADDRESS and determine
next hop router and outgoing interface Interface B
endif
4. If TIMESTAMP is newer or METRIC is smaller for same TIMESTAMP then
Add/Update entry {MH IP ADDRESS -> Interface B}, set timer
endif
5. If NEW BS ADDRESS matches one of local interface addresses then
5.1 Update Mobile-IP lifetime and generate registration reply to MH
else
5.2 Update METRIC and forward message to next hop router in step 3.2
endif
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 19]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
--------------------------------------------------------------------
Figure 7(b): HAWAII handoff processing for the Non-forwarding scheme
--------------------------------------------------------------------
1. If Registration message with PFANE extension is received,
If mobile host's NAI matches domain's NAI /* intra-domain */
1.1 obtain MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP
else /* inter-domain */
1.2 send registration to home agent
1.3 If registration is accepted by home agent, execute 1.1
endif
go to step 3.
endif
2. Receive Update message from neighbor on Interface A
Message contains MH IP ADDRESS, OLD BS ADDRESS, TIMESTAMP
3. If TIMESTAMP is newer or METRIC is smaller for same TIMESTAMP then
Add/Update entry {MH IP ADDRESS -> Interface A}, set timer
endif
4. If OLD BS ADDRESS matches one of local interface addresses then
4.1 Generate an acknowledgement back to the NEW BS
else
4.2 Look up routing table to find next hop router for OLD BS ADDRESS
Update METRIC and forward/generate message to next hop router
endif
5. If HAWAII ack is received
Update Mobile-IP lifetime and generate registration reply to MH
--------------------------------------------------------------------
The soft-state refresh messages are sent independently by each of the
nodes on a hop-by-hop basis. The mobile host sends Mobile-IP
registration renewals to the base station every TH seconds. The base
station is responsible for keeping alive the mobile's registration
with its home-agent, generating registration requests on behalf of
the mobile. Such surrogate requests [4] do not contain a valid
mobile-home authentication extension, but MUST contain a valid
foreign-home authentication extension. Such registrations are
generated by the base station when the lifetime of the mobile host's
registration with its HA is due to expire.
The base stations and routers also send HAWAII 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 no update to the
kernel routing table and can be done very efficiently. Furthermore,
a single refresh message can refresh several mobile hosts, thus
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 20]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
amortizing on the cost of sending/receiving the message. The
pseudo-code for processing a refresh message is shown in Figure 8.
One important point to note is the need for a user-specific timestamp
and metric 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. The metric resolves cases in non-tree topologies where race
conditions between two independent refreshes with the same timestamp
can be resolved.
--------------------------------------------------------------------
Figure 8: HAWAII refresh processing for both schemes
--------------------------------------------------------------------
1. Receive Refresh message from authenticated neighbor on Interface A
Message contains multiple tuples of {MH IP ADDRESS, TIMESTAMP}
2. For each tuple do
If entry exists for MH IP ADDRESS
If TIMESTAMP is greater than or equal to timestamp in entry
If entry already has interface as Interface A
/* Most common case - no failure */
2.1 reset timer on forwarding entry
else if METRIC is not greater
/* interface change failure, don't propagate up */
2.2 update entry {MH IP ADDRESS -> Interface A}, set timer
endif
endif
else
/* Non-existent MH entry failure, propagate up */
2.3 Add entry {MH IP ADDRESS -> Interface A}, set timer
2.4 Send immediate update (batched) using the default route
endif
3. Periodically send batch refresh upstream for all entries
4. When the default route changes
send batch refresh upstream for all entries
-------------------------------------------------------------------
5 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/Salgarelli Expires 25 Dec 99 [Page 21]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
5.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/Salgarelli Expires 25 Dec 99 [Page 22]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 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 [10], 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).
5.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/Salgarelli Expires 25 Dec 99 [Page 23]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
of flow-based QoS. In this section, we illustrate the ease with which
the well-known resource reservation protocol, RSVP [17], 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):1.1.1.1,A,B}
| B C | {(7):1.1.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):1.1.1.1,A,-}
| 3 @ | + 6 {(6):1.1.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 9: 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/Salgarelli Expires 25 Dec 99 [Page 24]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 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 9. 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 [16]. 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
immediately 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/Salgarelli Expires 25 Dec 99 [Page 25]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
5.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.
Link and router failures are handled through the soft-state refresh
mechanism in HAWAII. A standard routing daemon, such as RIP or OSPF,
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 8
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). Note that failures of domain root routers
are also handled similarly; the one difference is that inter-domain
routing protocols such as BGP will also be involved in order to
redirect packets from outside the domain to a different domain root
router. Thus, reliability is achieved through maintaining soft-state
forwarding entries for the mobile hosts and leveraging fault
detection mechanisms built in existing intra-domain routing
protocols.
As in any wireless system, in HAWAII, base station failures results
in loss of connectivity to mobile users served by it.
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.
6 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,
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 26]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
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 address used by the mobile host
in its home domain can be statically or dynamically assigned. We
explore each of these options in the following paragraphs. Note that
the co-located address used by the mobile host outside its home
domain will always be dynamically assigned.
If a mobile host is given its home address via manual configuration,
when it moves outside its home domain, it has to either acquire a
co-located care-of-address for itself or use a FA care-of address in
the new domain, and act as a ``vanilla'' mobile-IP agent. If it
acquires a co-located address, the benefits of HAWAII will be
directly applicable. On the other hand, if the mobile host uses a FA
terminated address, then the mobile host acts as a basic Mobile-IP
client, potentially foregoing the advantages of HAWAII.
The second option is to acquire both the home address and the
co-located care-of-address through DHCP [6]. 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.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 27]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
7 Security
There are two issues in security: user authentication by the DHCP
server during address assignment that occurs during power up and
inter-domain moves; and security and authentication related to
Mobile-IP and 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 [15] could be used to perform
the authentication.
Regarding Mobile-IP messages, we assume a trust model and postulate
the existence of a security infrastructure similar to the ones
assumed in [4] and [14]. In particular, mobile-hosts must be able to
trust registration replies generated by foreign agents, without the
intervention of the home agent; also, home agents must be able to
trust registrations generated by foreign agents, without the
intervention of the mobile-host. This assumes the existence of a a
verification and key-management infrastructure, to distribute
temporary session-keys to the mobile host, the foreign-agents and the
home-agent. In addition, the same infrastructure would serve the
purpose to verify that a particular set of base stations is allowed
by a HA to serve its mobile-hosts. All the protocol messages and the
mechanisms to perform key distribution, identity verification and
authorization are not explained in this document. However, refer
to [2] and [3] for an example of a protocol capable of carrying out
such operations.
Authentication of HAWAII protocol messages is not a difficult issue
since these messages are generated and processed only by nodes within
a single administrative domain. A simple approach such as a password
field as used in the Routing Information Protocols [8] can be used if
necessary.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 28]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 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] B. Aboba and M. A. Beadles, ``The network access identifier,''
Internet draft, Work in Progress, Nov 1998.
[2] P. Calhoun and C.E. Perkins, ``DIAMETER Mobile IP Extensions,''
Internet draft, Work in Progress, Nov 1998.
[3] P. Calhoun and A. Rubens, ``DIAMETER Base Protocol,'' Internet
draft, Work in Progress, Nov 1998.
[4] P. Calhoun, G. Montenegro, and C. E. Perkins, ``Mobile IP
Regionalized Tunnel Management,'' Internet draft, Work in
Progress, Nov 1998.
[5] P. Calhoun and C.E. Perkins, ``Mobile IP Network Access
Identifier Extension," Internet Draft, Work in Progress, May
1999.
[6] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for
Comments 2131, Mar 1997.
[7] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet
Draft, Work in Progress, Nov 1998.
[8] G. Malkin, ``RIP Version 2 Carrying Additional Information,''
Request for Comments 1723, Nov 1994.
[9] D. Mills, "Network Time Protocol (Version 3): Specification,
Implementation and Analysis", RFC 1305, Mar 1992.
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 29]
INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999
[10] S. Mohan and R. Jain, ``Two User Location Strategies for Personal
Communications Services,'' IEEE Personal Communications, Vol 1.,
No. 1, pp. 42-50.
[11] C.E. Perkins, ``IP Mobility Support,'' Request for Comments 2002,
Oct 1996.
[12] C.E. Perkins, and D.B. Johnson, ``Route Optimization in Mobile
IP,'' Internet Draft, November 1997.
[13] C.E. Perkins and D. Johnson, "Registration keys for route
optimization," Internet Draft, December 1997.
[14] C.E. Perkins and P. Calhoun, ``Mobile IP Challenge/Response
Extensions," Internet Draft, Work in Progress, May 1999.
[15] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote
Authentication Dial in User Service (RADIUS),'' Request for
Comments 2138, Apr 1997.
[16] D. Zappala and J. Kann., "RSRR: A Routing Interface for RSVP",
Internet Draft, Jul 1998
[17] B. Braden et. al., ``Resource Reservation Protocol (RSVP) -
Version 1 Functional Specification,'' Request for Comments 2205,
Sep 1997.
Authors' Addresses
R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli
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,lsalgarelli}@bell-labs.com
Ramjee/La Porta/Thuel/Varadhan/Salgarelli Expires 25 Dec 99 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-21 09:50:26 |