INTERNET-DRAFT IP micro-mobility support using HAWAII 25 Jun 1999 Internet Engineering Task Force R. Ramjee / T. La Porta INTERNET-DRAFT S. Thuel / K. Varadhan / L. Salgarelli draft-ietf-mobileip-hawaii-00.txt Lucent Bell Labs 25 Jun 1999 Expires: 25 Dec 1999 IP micro-mobility support using HAWAII Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In this contribution, we present HAWAII: a domain-based approach for supporting mobility. HAWAII uses specialized path setup schemes which install host-based forwarding entries in specific routers to support intra-domain micro-mobility and defaults to using Mobile-IP for inter-domain macro-mobility. These path setup schemes deliver excellent performance by reducing mobility related disruption to user applications, and by operating locally, reduce the number of mobility related updates. Also, in HAWAII, mobile hosts retain their network address while moving within the domain, simplifying Quality of Service support. Furthermore, reliability is achieved through 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]
