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