[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000
Internet Engineering Task Force                  R. Ramjee / T. La Porta
INTERNET-DRAFT                    S. Thuel / K. Varadhan / L. Salgarelli
draft-ietf-mobileip-hawaii-01.txt                       Lucent Bell Labs
7 Jul 2000
Expires:  7 Jan 2001

             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 7 Jan 01     [Page 1]


INTERNET-DRAFT     IP micro-mobility support using HAWAII    7  Jul 2000



Contents

1  Changes                                                             3
   1.1  Changes from version 00  . . . . . . . . . . . . . .. . . . .  3
   1.2  Changes from version ramjee-00 . . . . . . . . . . .. . . . .  3

2  Introduction                                                        4
   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  Interactions between Mobile IP HA and HAWAII                       28

8  Security                                                           29




















Ramjee/La Porta/Thuel/Varadhan/Salgarelli   Expires  7 Jan 01   [Page 2]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   1   Changes


   1.1   Changes from version 00

     o Added discussion on interactions between HAWAII DRR and Mobile IP
       Home Agent.



   1.2   Changes from version ramjee-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.txt to
       draft-ietf-mobileip-hawaii-00.txt



Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01     [Page 3]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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
   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




Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01     [Page 4]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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.



   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



Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01     [Page 5]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



     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

     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 7 Jan 01     [Page 6]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01     [Page 7]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01     [Page 8]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01     [Page 9]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 10]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 11]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 12]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



                                    |             (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 7 Jan 01    [Page 13]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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
   from the current base station towards the domain root router.
   Handoff updates (type 2) are sent from the old base station in the
   case of the Forwarding scheme, and from 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,





Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 14]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



                           Care-of address in Foreign domain
   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 7 Jan 01    [Page 15]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000

   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







Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 16]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   matches the mobile host's NAI, the mobile MUST register with the base
   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




Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 17]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   foreign agent functionality (without the decapsulation function) and
   originating HAWAII messages for processing within the domain.

   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
   --------------------------------------------------------------------




Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 18]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   Figure 6: HAWAII power up update processing at router
   --------------------------------------------------------------------
   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





Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 19]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   5.2  Update METRIC and forward message to next hop router in step 3.2
      endif
   --------------------------------------------------------------------
   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






Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 20]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 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 7 Jan 01    [Page 21]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 = A*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 7 Jan 01    [Page 22]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 23]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 24]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 25]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 26]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 27]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   7   Interactions between Mobile IP HA and

   HAWAII


   Many a dragon hides in the complexities of multi-protocol
   interaction.  HAWAII and Mobile IP operate in parallel at the domain
   root router to track the inter-domain mobility of the host.

   Recall that, in HAWAII, the domain root router acts as the HA for
   hosts that are in a foreign domain.  Therefore, HAWAII processing is
   required if the host is within the domain, and Mobile IP processing
   when it is roaming in a foreign domain.  The protocols should
   coordinate with each other to maintain forwarding entries for the
   mobile host, so that interleaved arrival of protocol messages do not
   leave the forwarding tables in an inconsistent state.

   After the domain root router has processed the Mobile IP registration
   message, indicating that the host has moved from its home to a
   foreign domain, HAWAII must ignore refresh messages for this host
   from downstream routers; these are stale refresh messages and will
   eventually be timed out.  Similarly, when the host has moved back
   from the foreign domain to its home domain, the domain root router
   should process the HAWAII update; however, Mobile IP should process
   any subsequent deregistration messages from the host only to remove
   its internal state, without affecting the forwarding entries.

   Another issue is that Mobile IP requires the home agent to add proxy
   arp entries for those mobile hosts that are in the foreign domain,
   and remove them when it receives an explicit deregistration message.
   The HA on the domain root router need not set such arp entries, since
   data packets will reach the domain root router based on the address
   allocation architecture of HAWAII. Moreover, such arp entries could
   interfere with connectivity when the host revisits its home domain;
   if the Mobile IP deregistration message is lost, the arp entry causes
   packets to be encapsulated and forwarded to the previous foreign
   domain by the HA. Thus, no packets can be sent to the mobile host
   until the Mobile IP state is removed following a timeout.  Hence, the
   home agent on the domain root router must disable its proxy arp
   processing as these are unnecessary when the host is in a foreign
   domain, and will interfere with HAWAII processing when the host
   revisits its home domain.  In the former case, all data packets for
   the mobile already traverse the domain root router, and can be
   forwarded to the mobile host.  When the host revisits its home
   domain, if the Mobile IP deregistration message is either lost or was
   never sent, the arp entry causes packets to the host to be
   encapsulated and forwarded to the previous foreign domain by the
   Mobile IP home agent.  Thus, no packets, including HAWAII
   acknowledgements, can be sent to the mobile host until the Mobile IP




Ramjee/La Porta/Thuel/Varadhan/Salgarelli  Expires 7 Jan 01    [Page 28]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   state is removed following a timeout.  Hence, the home agent on the
   domain root router should disable its proxy arp processing.



   8   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 7 Jan 01    [Page 29]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



   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 7 Jan 01    [Page 30]


INTERNET-DRAFT      IP micro-mobility support using HAWAII    7 Jul 2000



 [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 7 Jan 01    [Page 31]