Flexible Network Support for Mobile Hosts

Mobile Networks and Applications 6, 137–149, 2001 2001 Kluwer Academic Publishers. Manufactured in The Netherlands.

Flexible Network Support for Mobile Hosts

XINHUA ZHAOComputer Science Department, Stanford University, Stanford, CA 94305, USA

CLAUDE CASTELLUCCIAINRIA Rhone-Alpes, 38330 Montbonnot Saint Martin, France

MARY BAKERComputer Science Department, Stanford University, Stanford, CA 94305, USA

Abstract. Fueled by the large number of powerful light-weight portable computers, the expanding availability of wireless networks, andthe popularity of the Internet, there is an increasing demand to connect portable computers to the Internet at any time and in any place.However, the dynamic nature of a mobile host’s connectivity and its use of multiple network interfaces require more flexible networksupport than has typically been available for stationary workstations.

This paper introduces two flow-oriented mechanisms, in the context of Mobile IP [25], to ensure a mobile host’s robust and efficientcommunication with other hosts in a changing environment. One mechanism supports multiple packet delivery methods (such as regularIP or Mobile IP) and adaptively selects the most appropriate one to use according to the characteristics of each traffic flow. The othermechanism enables a mobile host to make use of multiple network interfaces simultaneously and to control the selection of the mostdesirable network interfaces for both outgoing and incoming packets for different traffic flows. We demonstrate the usefulness of thesetwo network layer mechanisms and describe their implementation and performance.

Keywords: Mobile IP, mobility support, multiple packet delivery methods, multiple network interfaces, Mobile Policy Table

1. Introduction

Light-weight portable computers, the spread of wireless net-works and services, and the popularity of the Internet com-bine to make mobile computing an attractive goal. Withthese technologies, users should be able to connect to theInternet at any time and in any place, to read email, querydatabases, retrieve information from the web, or entertainthemselves.

To achieve the above goal, a mobile host requires a uniqueunchanging address, despite the fact that as it switches fromone communication medium to another, or from one net-work segment to another, the IP address associated withits network interface must change accordingly. The IP ad-dress must change because IP [27] assumes that a host’sIP address uniquely identifies the segment of the networkthrough which a host is attached to the Internet. Unfor-tunately, changing the address will break ongoing networkconversations between a mobile host and other hosts, be-cause connection-oriented protocols such as TCP [5] use theIP addresses of both ends of a connection to identify the con-nection. Therefore, Mobile IP [25], or another similar mech-anism that allows a host to be addressed by a single address,is needed to accommodate host mobility within the Internet.

However, due to the dynamic nature of a mobile host’sconnectivity and its use of multiple interfaces, providing net-work support for a mobile host can be a much more complextask than for its stationary counterparts. Mobile IP takes animportant step towards supporting mobility and is the con-text for our work, but through day-to-day experience using

the MosquitoNet [17] mobile network, we have found that itis desirable to have finer control over the network traffic of amobile host on a per flow basis than is provided by Mobile IP.The work presented in this paper is mainly motivated by thefollowing observations on the unique characteristics of a mo-bile host:

• Duality. The mobile host has two roles as both a host vir-tually connected to its home network and as a normal hoston the network it is visiting. In this sense, we can con-sider the mobile host to be virtually multi-homed. Thisduality brings along increased complexity as well as op-portunities for optimization.

• Dynamically changing point of attachment.We connecta portable to various networks, such as our office networkwhile at work, the network of a wireless Internet accessservice provider while on the road, or another network athome or elsewhere. Different networks may have differ-ent policies for dealing with packets from mobile hosts.Depending on where a mobile host currently operates andwith whom it communicates, it may need to use differentpacket delivery methods that are either more robust ormore efficient.

• Multiple network interfaces.To achieve connectivity inany place at any time, mobile hosts will likely requiremore than one type of network device. For example, ourmobile hosts use Ethernet or WaveLAN [18] when in asuitably equipped office or home, but they use a slowerwireless packet radio network such as Metricom Rico-chet [20] elsewhere.

138 X. ZHAO ET AL.

There is no single network device that can provide thedesired quality of service (QoS) all the time. Thereis always a tradeoff among coverage, performance, andprice. There are even times when multiple network de-vices need to be used at the same time (such as a satel-lite connection for downlink and a modem connection foruplink). In this case, the mobile host is physically multi-homed as well. Making use of these network interfacessimultaneously for different flows of traffic is a challenge.

Our goal is to enable a mobile host to communicate bothrobustly and efficiently with other hosts as it moves fromplace to place. While there are ways to satisfy one goal orthe other, satisfying both at once is a challenge. For exam-ple, we can treat a mobile host as virtually connected to itshome network by always tunneling packets between the mo-bile host and its home agent. Although robust, this is obvi-ously not efficient. Achieving efficiency as well requires amobile host to have more flexibility than has been providedby previously existing mechanisms.

This paper addresses the following two issues in provid-ing the flexibility desirable for a mobile host. First is theneed at the network routing layer to support multiple packetdelivery methods (such as whether to use regular IP or Mo-bile IP). At the network layer, we have developed a general-purpose mechanism, the Mobile Policy Table, which sup-ports multiple packet delivery methods simultaneously fordifferent flows and adaptively selects the most appropriatemethod according to the characteristics of each traffic flow.Second is the need to make use of multiple network inter-faces simultaneously and to control the interface selectionof both outgoing and incoming packets for different trafficflows. This is achieved by extending the base Mobile IPprotocol to control the choice of interfaces to use for incom-ing traffic to a mobile host. We also amend the routing tablelookup to enable the use of multiple network interfaces foroutgoing traffic flows from a mobile host. The result is asystem that applies Mobile IP more flexibly by taking intoconsideration traffic characteristics on a flow-by-flow basis.

The rest of the paper is organized as follows. In sec-tion 2, we give a brief description of Mobile IP, the context inwhich our work is done. In section 3, we illustrate scenariosfor the use of multiple packet delivery methods for differentflows of traffic. In section 4, we detail the general-purposemechanism that supports this use of multiple packet deliv-ery methods. In section 5, we describe the simultaneous useof multiple network interfaces. In section 6, we report theimplementation status of the system and present the resultsof system performance measurements obtained from our ex-periments. In section 7, we list related work. In section 8,we consider the applicability and potential of our work withIPv6. Finally, we present conclusions together with somefuture and continuing work in section 9.

2. Background: Mobile IP

Mobile IP [25] is a mechanism for maintaining transparentnetwork connectivity to mobile hosts. Mobile IP allows a

mobile host to be addressed by the IP address it uses in itshome network (home IP address), regardless of the networkto which it is currently physically attached. Figure 1 illus-trates the operation of basic Mobile IP.

The Mobile IP specification allows for two types of at-tachment for a mobile host visiting a “foreign” network (anetwork other than the mobile host’s home network). For thefirst type of attachment, the mobile host can connect to theforeign network through a “foreign agent”, an agent presentin the foreign network, by registering the foreign agent’sIP address with its home agent. The home agent then tun-nels [24] packets to the foreign agent, which decapsulatesthem and sends them to the mobile host via link-level mech-anisms.

Although our Mobile IP implementation supports the useof foreign agents, our work is more focused on the secondtype of attachment, which provides a mobile host with itsown “co-located” care-of address in the foreign network. Inthis scenario, the mobile host receives an IP address to usewhile it visits the network, via DHCP [7] or some other pro-tocol or policy. It registers this address with its home agent,which then tunnels packets directly to the mobile host at thisaddress. The disadvantage of this scenario is that the mobilehost has to decapsulate packets itself and more IP addressesare needed in the foreign network, one for each visiting mo-bile host. The advantage is that the mobile host also becomesmore directly responsible for the addressing and routing de-cisions for the packets it sends out, and it therefore has morecontrol over such operations.

While Mobile IP has laid the groundwork for Internet mo-bility, there are still many challenges to tackle, as seen fromon-going efforts in this area. These efforts include route op-timization [14], firewall traversal [22], and “bi-directionaltunneling” (or “reverse-tunneling”) [21] to allow packets tocross security-conscious boundary routers. This last prob-lem, as described in section 3.2, is one of our motivationsfor making it possible for mobile hosts to choose dynam-ically between different packet addressing and routing op-

Figure 1. Basic Mobile IP protocol. Packets from the correspondent host tothe mobile host are always sent to the mobile host’s home network first, andthen forwarded (tunneled) by the home agent to the mobile host’s currentpoint of attachment (care-of address). Packets originating from the mobilehost are sent directly to the correspondent host, thus forming a triangularroute. The thick line indicates that the original packet is encapsulated in

another IP packet when forwarded, and is therefore of a larger size.

FLEXIBLE NETWORK SUPPORT FOR MOBILE HOSTS 139

tions. We believe that these efforts make evident the inher-ent need for mobile hosts to use different techniques underdifferent circumstances.

3. Supporting multiple packet delivery methods

Supporting multiple packet delivery methods is the first areain which we have increased the flexibility of mobile hosts.By avoiding a single method of delivery, the mobile hostonly pays for the extra cost of mobility support or securityperimeter traversal when it is truly needed.

We illustrate some of the situations for which we havefound such flexibility to be beneficial in practice. Althoughfigure 2 only shows the examples we have implemented sofar, the mechanism we propose here can be extended to sup-port other delivery methods when other choices become de-sirable.

3.1. Providing transparent mobility support only whennecessary

The transparent mobility support of Mobile IP is importantfor long-lived connection-oriented traffic or for incomingtraffic initiated by correspondent hosts. However, this trans-parent mobility support does not come without cost. In theabsence of route optimization for Mobile IP, packets des-tined to a mobile host are delivered to its home network andthen forwarded to the mobile host’s current care-of addressin the network it is visiting. If a mobile host is far away fromhome but relatively close to its correspondent host, the pathtraversed by these packets is significantly longer than thepath traveled if the mobile host and the correspondent hosttalk to each other directly. The extra path length not only in-creases latency but also generates extra load on the Internet.It even increases load on the home agent, potentially con-tributing to a communication bottleneck if the home agent isserving many mobile hosts simultaneously.

It would be ideal to use Mobile IP route optimiza-tion [14]. However, since Mobile IP route optimization re-quires extra support on correspondent hosts in addition tosupport on the mobile host and its home agent, it requireswidespread changes throughout the Internet, which is unre-alistic for the near future.

Fortunately, there are certain types of traffic for which amobile host may not require Mobile IP support. Examplesare most web browsing traffic and communication with localservices discovered by the mobile host. Web connections areusually short-lived, so it is unlikely that a mobile host willchange its foreign network address in the midst of a connec-tion (exceptions are web push technology and HTTP 1.1 [9],which can potentially use persistent transport connections).Even if it does, the user can simply press reload, and the webtransfer will be retried. With such traffic, we can avoid theextra cost associated with mobility support.

3.2. Supporting bi-directional tunnels and triangle routes

When communication requires transparent mobility, therestill remains a choice of packet delivery methods. An impor-tant example is communication that must traverse security-conscious boundary routers.

As a result of IP address spoofing attacks and in accor-dance with a CERT advisory [4], more routers are filter-ing on the source address (ingress filtering) [8] and willdrop a packet whose address is not “topologically correct”(whose originating network cannot be the one identified bythe source address). In the presence of such routers, the tri-angle route as specified in the basic Mobile IP protocol willfail. Figure 3 illustrates an example of this problem.

As another example, if the boundary router is in the do-main visited by the mobile host, it may drop packets thatare received from inside but claim to originate from outside;these packets look as if they are “transit traffic”, and not allnetworks will carry transit traffic.

Figure 2. Simultaneous use of multiple packet delivery methods. This figure summarizes the different packet delivery choices (in rectangle boxes) wehaveimplemented so far. Listed in the circles are example uses for each packet delivery choice. The policy decisions to be made are in diamonds.

140 X. ZHAO ET AL.

Figure 3. The problem with source IP address filtering at a security-conscious boundary router. When the mobile host sends packets directlyto the correspondent host in its home domain with the source IP addressof the packets set to the mobile host’s home IP address, these packets willbe dropped by the boundary router, because they arrive from outside of the

institution and yet claim to originate from within.

Figure 4. Solution to the ingress filtering problem. To address the prob-lem caused by source IP address filtering on security-conscious boundaryrouters, the mobile host sends packets by tunneling along the reverse pathas well. Since the encapsulated packets in the tunnel from the mobile hostto its home agent use the mobile host’s care-of address as their source IPaddress (which is topologically correct), these packets will no longer be

dropped by the security-conscious boundary routers.

To address the above problems, we can tunnel packetssent by the mobile host through its home agent to its cor-respondent hosts, in much the same way we tunnel packetssent to the mobile host. This is called “bi-directional tunnel-ing” [21]. Figure 4 illustrates the solution.

This bi-directional tunneling addresses the problem re-lated with ingress filtering routers, but again, this comeswith increased cost. If a mobile host visits a network faraway from home and tries to talk to a correspondent host ina nearby network, packets originating from the mobile hostwill now have to travel all the way home and then back tothe correspondent host, increasing the length of this reversepath.

However, not all the packets need to be sent this way. It isunnecessary to force all traffic through a bi-directional tun-nel just because some ingress filtering routers would droptraffic sent to specific destinations. Such tunneling may beunnecessary for a large part of the traffic for which the topo-logically incorrect source IP address in packet headers is nota problem. Therefore, it is important to support the use ofboth triangle routing and bi-directional tunneling simultane-ously, so that only those traffic flows that truly need to usebi-directional tunneling pay for this extra cost.

3.3. Joining multicast groups in different ways

The final packet delivery mechanism we have experimentedwith is to allow a mobile host to choose to join multicastgroups either remotely (through its home network), usingits home IP address, or locally, using its co-located care-ofaddress in the foreign network. This flexibility is necessarybecause multicast traffic is often limited to a particular siteby scoping [6]. Also, there are advantages and disadvantagesto either choice [1] even if scoping is not an issue.

• Joining locally: in this respect the mobile host is not dif-ferent from any normal host on the same subnet. Theadvantage is that the delivery of multicast traffic to themobile host is more efficient. The disadvantages are thatit requires the existence of a multicast-capable router inthe foreign network, and those mobile hosts actively par-ticipating in the multicast session will have to re-identifythemselves within the group when they move to anothernetwork.

• Joining through the home network: all multicast traffichas to be tunneled bi-directionally between the mobilehost and its home agent. The advantages of this choiceare that it does not require multicast support on the for-eign network, and the mobile host will retain its mem-bership as it moves around. The disadvantage is that theroute is less efficient. Although there are optimizationsthat allow a single copy of multiple packets to be tunneledto a foreign agent serving multiple mobile hosts [10], thehome agent still must tunnel a copy of a multicast packetto each foreign network that has one of its mobile hostsvisiting.

We can choose either option for different multicastgroups. To join a multicast group locally, we add an entry inthe Mobile Policy Table instructing traffic destined to certainmulticast addresses to use conventional IP support. To joina multicast group remotely, we add an entry in the MobilePolicy Table to use bi-directional tunneling for traffic des-tined to these multicast groups. The mobile host also needsto notify its home agent, in a registration packet, to forwardmulticast traffic to it.

4. A general-purpose mechanism for flexible routing

In this section, we describe the mechanism used to achievethe flexibility features described in the previous section. Thisgeneral-purpose mechanism is centered around the idea ofintroducing a Mobile Policy Table in the routing layer ofthe network software stack. The IP route lookup routineip_rt_route is augmented to take the Mobile Policy Ta-ble into consideration together with the normal routing tablein determining how a packet should be sent.

4.1. Support in the network layer

We choose to add our support for multiple packet deliverymethods to the network layer due to its unique position in


the network software stack. By modifying the layer throughwhich packets converge and then diverge, we avoid a pro-liferation of modifications. Relatively fewer changes needto be made in the kernel network software, and both theupper layer protocol modules (such as TCP or UDP) andlower layer drivers for different network devices remain un-changed.

We further identify the route lookup routine as a naturalplace to add such support. Along with normal route selec-tion, the enhanced route lookup also makes decisions forchoosing among multiple ways to deliver packets, as neces-sitated by the changing environment of a mobile host.

4.2. The Mobile Policy Table

The Mobile Policy Table specifies how the packets shouldbe sent and received for each traffic flow matching certaincharacteristics. The routing and addressing policy decisionscurrently supported in the Mobile Policy Table are:

• whether to use transparent mobility support (Mobile IP)or regular IP;

• whether to use triangular routing or bi-directional tunnel-ing, if using Mobile IP.

These policies are specified through two types of entries:“per-socket” entries and “generic” entries, with per-socketentries taking precedence. While the Mobile Policy Tableonly contains generic entries, a per-socket entry kept withinthe socket data structure allows any application to overridethe general rules. Without a per-socket entry, traffic is sub-ject only to generic entries in the policy table, which specifythe delivery policy for all traffic matching the given charac-teristics.

For generic entries, the Mobile Policy Table lookup cur-rently determines which policy entry to use based on twotraffic characteristics: the correspondent address and portnumber (for TCP and UDP). The correspondent address isuseful, because we often want to treat flows to different des-tinations differently. The port number is useful as well, be-cause there are many reserved port numbers that indicate thenature of the traffic, such as TCP port 23 for telnet, or port 80for HTTP traffic. While these are the characteristics cur-rently taken into consideration, we can extend the techniqueto include other characteristics in the future.

Table 1 shows, as an example, the Mobile Policy Tablecurrently used on our mobile hosts when visiting places out-side of their home domain. The Mobile Policy Table lookupoperation always chooses the most specifically matched en-tries (those with more restricted netmask and/or port numberspecifications) over more general ones.

4.3. How it works

Figure 5 illustrates the use of the Mobile Policy Table androuting table within the Linux kernel. The modification tothe kernel is mainly limited to the route lookup function. For

Table 1A sample Mobile Policy Table. This mobile policy table specifies thatall traffic destined back to the mobile host’s home domain should use bi-directional tunneling, to satisfy the boundary routers at its home institution(first row); all traffic to port 80 (web traffic) should avoid using transpar-ent mobility support (second row); and the remaining traffic should by de-fault use Mobile IP with a regular triangular route (third row). The secondentry applies to all traffic with a destination port number of 80, even fordestinations matching the first entry, since port number specification takes

precedence.

Destination Netmask PortNum Mobility Tunneling

171.64.0.0 255.255.0.0 0 Yes Yes

0.0.0.0 0.0.0.0 80 No N/A

0.0.0.0 0.0.0.0 0 Yes No

Figure 5. This figure shows where the Mobile Policy Table (MPT) fits intothe link, network, and transport layers of our protocol stack. The MPT re-sides in the middle (network) layer, consulted by the IP route lookup func-tion in conjunction with the normal routing table to determine how packetsshould be sent. The bottom (link) layer shows the device interfaces, withvifbeing a virtual interface that handles encapsulation and tunneling of pack-ets. The top (transport) layer shows TCP and UDP, along with an IP-within-IP processing module. The arrows depict the passing of data packets downthe layers. The shaded boxes indicate that the IPIP andvif modules haveoverlapping functionalities. The bold bi-directional arc shows the need to

pass packets between the two modules.

backward compatibility, the normal routing table remains in-tact. During a route lookup, extra arguments such as othercharacteristics of the traffic flow (currently only the TCP orUDP port number) and the source IP address chosen are usedin addition to the correspondent host’s address for decidinghow the packet should be sent.

The new route lookup function uses the specified sourceIP address to determine if the packet is subject to policy deci-sions in the Mobile Policy Table. If the source IP address hasalready been set to the IP address associated with one of thephysical network interfaces, this indicates that no mobilitydecision should be made for the packet. Packets may havetheir source address set either after they are looped back bythe virtual interface (described below), since a mobility deci-sion has already been made by that time, or by certain appli-cations. An example of such an application is the mobilehost daemon handling registration and deregistration withthe home agent; this daemon needs to force a packet through

142 X. ZHAO ET AL.

a particular real interface using regular IP. In cases where thesource IP address is already set, only the normal routing ta-ble is consulted based upon the destination address, and theresulting route entry is returned. For the rest of the pack-ets, the Mobile Policy Table needs to be consulted to chooseamong multiple packet delivery methods.

The virtual interface (“vif”) handles packets that need tobe encapsulated and tunneled. It provides the illusion thatthe mobile host is still in its home network. Packets sentthroughvif are encapsulated and then looped back to theIP layer (as shown by the wide bi-directional arc in the fig-ure) for delivery to the home agent. This time, however, thesource IP address of the encapsulating packet has alreadybeen chosen, so it will now be sent through one of the phys-ical interfaces. Accordingly, packets being tunneled to themobile host by its home agent are also looped by the IPIPmodule tovif, so that they appear to have arrived at the mo-bile host as if it were connected to its home network.

To maintain reasonable processing overhead, policy tableentries are cached in a manner similar to routing table en-tries. If the characteristics of the traffic match a cached entry,the software uses the cached entry to speed up the process ofpolicy lookup. Otherwise, a new policy table lookup will becarried out. Whenever the mobile policy table is modified,the cached entries are flushed.

We believe this is a general-purpose mechanism, becauseit can be easily extended to take other traffic characteristicsinto consideration and to add more policy decisions if it be-comes desirable to do so. For instance, if particular corre-spondent hosts have the ability to decapsulate packets them-selves, we could note this information in the Mobile Pol-icy Table for those destinations, and the mobile host couldsend encapsulated packets directly to these hosts, bypass-ing the home agent yet still providing the robustness of abi-directional tunnel.

4.4. Dynamic adaptation of the Mobile Policy Table

The entries in the Mobile Policy Table can be changed atruntime to specify a different policy. We currently have thefollowing two mechanisms to adjust entries in the MobilePolicy Table dynamically.

First, we can swap in a new set of entries for the MobilePolicy Table whenever a mobile host changes its care-of ad-dress. When a mobile host changes its point of attachment tothe Internet, the best way to communicate with other hostsoften changes accordingly. For example, when our mobilehosts move from within the Stanford domain to a foreignnetwork outside, they need to switch to using reverse tunnel-ing for traffic back to their home domain due to the ingressfiltering routers present at the boundary of Stanford’s do-main. For foreign networks frequently visited by a mobilehost, we use predefined configuration files that contain theset of entries to use in the Mobile Policy Table so that a suit-able set of policies can be put in place quickly when a mobilehost changes location. For previously unknown foreign net-works, a default set of policies will be used.

In addition, we make it possible to change specific entriesin the Mobile Policy Table dynamically. For instance, wesupport adaptively selecting between the most robust packetdelivery method (i.e. bi-directional tunneling) and a more ef-ficient packet delivery method (i.e. triangular routing). Thismechanism helps when a current setting in the Mobile Pol-icy Table fails or when it is simply impossible to specifythe right policy beforehand. The adaptation applies only tocached entries, i.e. we only adjust those entries that are ac-tually in use.

To implement this mechanism, we automatically dispatcha separate process that probes each destination address bysending ICMP echo requests using triangular routing, withthe interval between probes being increased exponentiallyup to a preconfigured maximum value. For a flow usingreverse tunneling, if a reply to any of the probes is suc-cessfully received, the Mobile Policy Table entry for thisflow will be changed from bi-directional tunneling to usethe more efficient triangular routing. For a flow using tri-angular routing, the Mobile Policy Table entry is changedback to use bi-directional tunneling if a certain number ofprobes (currently, five) have failed in a row. After the initialstage, this separate process keeps probing in the backgroundwith the maximum probe interval. If a series of probes failswhile a flow is using triangular routing, we switch to usebi-directional tunneling. If a probe succeeds while a flow isusing bi-directional tunneling, the Mobile Policy Table en-try will be changed to use triangular routing immediately. Inall other cases, no action is necessary. This way, a flow isable to select adaptively the most efficient packet deliverymethod.

5. Supporting the use of multiple network interfacessimultaneously

The use of multiple network interfaces is different on mobilehosts than on typical stationary machines. Stationary hostswith multiple network interfaces are usually routers, for-warding packets with different destination addresses throughdifferent network interfaces. On a mobile host, these net-work devices instead represent different ways this single mo-bile host can communicate with the outside world. For ex-ample, we may want to use two different interfaces (one fortelnet and another for file downloading) for communicationwith the same host.

Although some operating systems can direct broadcastor multicast traffic out through a particular network inter-face to its immediately connected subnets, all these operat-ing systems (except for Linux) make routing decisions bydestination addresses alone, without taking other traffic flowcharacteristics into consideration. The standard Linux distri-bution includes our contribution that enables each socket tochoose among different simultaneously active network inter-faces for outgoing traffic to destinations beyond the directlyconnected subnets. Our goal is to enable a mobile host tomake use of multiple active network interfaces simultane-ously for different flows of traffic in a more general way.


5.1. Motivation for multiple interfaces

We find the support for the use of multiple active interfacesuseful for the following reasons:

1. Smoother handoffs.With the ability to use multiple net-work interfaces simultaneously, a mobile host can probethe usability of other interfaces beyond its directly con-nected subnet without disturbing the interface currentlyin use. The current network interface can remain in useuntil the new care-of address on the new network can besuccessfully registered with the home agent. This elim-inates unnecessary packet loss when switching care-ofaddresses.

2. Quality of service (QoS).The different physical net-works to which a user has access may offer differentQoS guarantees. For example, a mobile user may havesimultaneous access to a GSM data network [28] thathas low bandwidth but relatively low latency, as wellas to a Metricom Ricochet network that offers higherbandwidth but has higher and more variable latency.The mobile host might decide to use the GSM networkfor its low-bandwidth interactive flows (such as its tel-net traffic) which require low latency for user satisfac-tion, while using the Metricom network for its bulk datatransfer flows (such as ftp traffic) which require highbandwidth but do not demand as low a latency. Thecombination of these different types of networks can de-liver a larger range of QoS to mobile users.

3. Link asymmetry.Some networks only provide unidi-rectional connectivity. This is the case for many satel-lite systems, which usually provide downlinks only. Inthese systems, connectivity in the reverse direction isprovided via a different means, such as a SLIP or PPPdialup line, a cellular modem, or a CDPD [2] device.Being able to specify the incoming and outgoing inter-faces explicitly in a natural manner is a useful feature.

4. Cost and billing. The cost of accessing different net-works may be a decisive factor in interface selection.Users might select different interfaces according to theidentity of the bill payer. For example, they mightchoose a cheaper and lower quality access network forpersonal communications and a more expensive and bet-ter quality one for business communications.

5. Privacy and security.Privacy and security may also beof considerable importance in interface selection. Usersmay trust some networks more than others and preferto use them for confidential and important communi-cations. They might also want, for privacy reasons,to choose different networks for business and personalcommunications.

The following sections explain how to support this featurefor packet transmission and reception.

5.2. Supporting multiple interfaces in transmission

For a mobile host to use multiple network interfaces simulta-neously to send packets, we have devised the following twotechniques. The first is to make use of the metric field in theexisting routing table entry so that multiple routes throughdifferent interfaces can be associated with a certain destina-tion specification. Usually the normal default route has ametric of one. Routes through other interfaces with metricsgreater than one can coexist with the normal default routein the routing table. A route lookup that does not specify aparticular interface will thus find the normal default route,maintaining backwards compatibility, since the lookup al-ways chooses the matching route with the smallest metric.

The second technique we provide is a “bind-to-device”socket option that applications can call to associate a specificdevice with a certain socket. The route lookup routine hasbeen modified so that when a device selection is specified,only those route entries associated with the particular devicewill be considered. Therefore, different applications runningsimultaneously can each choose different network interfacesto use for sending packets.

5.3. Supporting multiple interfaces in reception

5.3.1. Overview of the schemeA mobile host with multiple interfaces running standard Mo-bile IP cannot receive different flows of packets on differentinterfaces simultaneously. With Mobile IP, a mobile hostsends location updates that indicate its current〈home ad-dress, care-of address〉 binding to its home agent and pos-sibly to its correspondent hosts. As a result, all packets ad-dressed to a mobile host are sent over the same interface orpossibly over multiple interfaces all at the same time if the“S” (simultaneous binding) flag is set in the registration.

We have extended Mobile IP to allow a mobile host to usedifferent interfaces to receive different flows. In our work,we define a flow as a triplet:〈the mobile host’s home IPaddress, the correspondent host’s IP address, the port num-ber on the correspondent host〉. Our definition is differentfrom typical flow definitions in that we do not include cer-tain fields such as the port number on the mobile host. Thisactually makes certain flows from the same mobile host in-distinguishable from each other. However, since our currentgoal is to treat traffic flows differently based on whom a mo-bile host is talking to and the nature of the communication(for example, whether it is interactive traffic or bulk trans-fer), we believe that this triplet is sufficient in capturing theessential traffic flow characteristics to serve this purpose.

In our framework, a mobile host may choose to receivethe packets belonging to a given flow on any of its interfacesby sending a Flow-to-Interface binding to its home agent.This Flow-to-Interface binding specifies the mobile host’scare-of address that the home agent should use to forwardpackets belonging to the flow.

Upon reception of a Flow-to-Interface binding, a homeagent updates its extended binding list, which contains en-

144 X. ZHAO ET AL.

Figure 6. Supporting multiple incoming interfaces. Packets belonging toany flows addressed to the mobile host arrive on the home network via stan-dard IP routing. The home agent intercepts packets and tunnels them to thecare-of address selected based on the packets’ destination addresses, sourceaddresses and source ports. Packets of Flow1 are tunneled to Care-of Ad-

dress1, while packets of Flow2 are tunneled to Care-of Address2.

tries that associate a particular flow specification with a mo-bile host’s care-of address. Thereafter, when the home agentreceives a packet addressed to a mobile host it is serving,it searches in its extended binding list for an entry match-ing the corresponding fields of the packet and forwards thepacket to the associated care-of address. If no entry is found,the packet is forwarded to the mobile host’s default care-ofaddress.

Figure 6 illustrates the routing of datagrams to a mobilehost away from home, once the mobile host has registeredseveral Flow-to-Interface bindings with its home agent. It isworth noting that since the port number on a correspondenthost is a factor in distinguishing between different flows, thehome agent must treat already fragmented packets to mobilehosts specially. Currently, we reassemble these fragmentedpackets at the home agent before forwarding them to mobilehosts. Since all packets pass through the home agent, we donot suffer from the problem normally associated with doingreassembly at intermediate routers (wherein the routers arenot guaranteed to see all the fragments). As we describe insection 8, the use of IPv6 flow label will eliminate the needfor de-fragmentation.

The Flow-to-Interface bindings are registered to the homeagent via two new extensions of the Mobile IP registrationmessages. The following sections review briefly the MobileIP registration procedure and detail the new extensions wehave devised.

5.3.2. The Mobile IP registration procedureA mobile host and its home agent exchange Mobile IP reg-istration request and reply messages in UDP packets. Theformat of the registration request packet is shown in figure 7.The fixed portion of the registration request is followed byextensions, a general mechanism to allow optional informa-tion and protocol extensibility. We use this general mecha-nism to extend the Mobile IP protocol so that different flowsto a mobile host can be associated with different networkinterfaces on that host.

Figure 7. Mobile IP registration request. A registration request is used by amobile host to create, on its home agent, a mobility binding from the staticIP address at its home network (i.e. its home address) to its current care-of address. A general extension mechanism is defined for extending the

protocol.

Figure 8. Flow-to-Interface binding extension. The CH (correspondenthost) Address and the CH Port fields in this extension together with themobile host’s home address define the flow that should now be associated

with the care-of address specified in the Flow Care-of Address field.

Figure 9. Flow-to-Interface binding update extension. All flows previouslybound to the old care-of address should now be redirected to the new care-of

address.

5.3.3. The Flow-to-Interface binding extensionA mobile host may ask a home agent to register a numberof Flow-to-Interface bindings by appending to a registrationrequest a list of Flow-to-Interface extensions, each defininga Flow-to-Interface binding to be registered. The Flow-to-Interface binding extension format is shown in figure 8.

5.3.4. The Flow-to-Interface binding update extensionA mobile host may ask a home agent to redirect certain ex-isting flow bindings to a different care-of address by usingthe Flow-to-Interface binding update extension. The bind-ing update extension format is detailed in figure 9. This ex-tension is useful when a mobile host changes the point ofattachment of one of its interfaces and obtains a new care-ofaddress for this interface.

5.3.5. Some compatibility issuesWe want to ensure that unmodified mobile hosts are able touse our enhanced home agent, and that our enhanced mobilehosts work properly with unmodified home agents. The first


scenario is not an issue, since the enhanced home agent canprocess both regular registration messages as well as thosewith our new extensions. However, the second scenario re-quires further consideration.

According to the Mobile IP specification [25], when anextension numbered within the range 0–127 is encounteredbut not recognized, the message containing that extensionmust be silently discarded. When an extension numbered inthe range 128–255 is encountered but not recognized, onlythat particular extension is ignored, but the rest of the exten-sions and the message must still be processed. We chooseto number our new extensions within the range 128–255,since it is undesirable to have registration packets silentlydiscarded, causing the system to wait for timeouts instead.

When a mobile host sends a Flow-to-Interface bindingregistration to a home agent that does not support Flow-to-Interface bindings, the packets will still be processed. This issafe, since the registration message is a normal registrationmessage excluding the Flow-to-Interface binding extension.However, to distinguish these unsuspecting home agentsfrom the enhanced home agents, we make the enhancedhome agents use different return codes in reply to registra-tion requests with Flow-to-Interface extensions. If the regis-tration is accepted, the home agent returns the code 2 insteadof 0. The return code 3 (instead of 1) will be used if the reg-istration is accepted and simultaneous mobility binding isgranted. Therefore, if a mobile host sends out registrationrequests with Flow-to-Interface binding extensions but getsa return code 0 or 1 in reply, it should stop sending Flow-to-Interface binding extensions to its home agent, since contin-uing to send them will just waste bandwidth.

6. Implementation status and experiments

6.1. Implementation status

We have implemented the support for multiple packet deliv-ery methods and simultaneous use of multiple network in-terfaces on top of our Mobile IP implementation [3] underLinux (currently kernel version 2.2.14). Some core functionsof our Mobile IP implementation reside within the kernel,such as packet encapsulation and forwarding. Other func-tions, such as sending and receiving registration messages,are implemented in a user-level daemon.

A mobile host can choose the use of either Mobile IP orregular IP and the use of either bi-directional tunneling ortriangular routing for different flows of traffic all at the sametime. We also provide mobility-aware applications with theflexibility to choose incoming and outgoing interfaces. Weuse two new socket options to bind flows to given interfaces:

• SO_BINDTODEVICE1: this option is used by an appli-

1 The name SO_BIND_OUTFLOW_TO_INTERFACE would be more ap-propriate, and the next socket option should also be named accordingly.Unfortunately, our original name SO_BINDTODEVICE is already in thestandard Linux distribution.

Figure 10. Setup of the test environment for experiments on multiple packetdelivery methods. The mobile host visits the campus residence network asa foreign network. The mobile host is a Thinkpad 560, and the home agent

is a 90 MHz Pentium. They are both running Linux.

cation to bind the outgoing flows of a socket to an inter-face.

• SO_BIND_FLOWTODEVICE: this option is used by anapplication to bind the incoming flows of a socket to agiven interface.

6.2. Experiments with multiple packet delivery methods

6.2.1. BenefitsThe choice of delivery method has a performance impact ontraffic flows. We look at a mobile host in one particular realscenario to illustrate the potential benefits certain flows willbe able to receive when they can use the more efficient deliv-ery methods made possible by our flexible mechanism. Notethat other scenarios could see very different results depend-ing on the actual network latency between the mobile host,the home agent and the correspondent host.

We evaluate the latency improvement resulting from us-ing the most direct route possible under the circumstances.For these experiments, the mobile host connects to a foreignnetwork in one of our campus residences, which is also onEthernet, and registers its current care-of address with itshome agent. The setup of the test scenario is illustrated infigure 10. The mobile host sends ping (ICMP echo request)packets to the default gateway (acting as its correspondenthost) of its local subnet and we measure the round-trip la-tency using the following three delivery methods, switchingbetween them by manipulating the Mobile Policy Table:

• regular IP (no transparent mobility support);

• triangular delivery (the default behavior in Mobile IP);

• bi-directional tunneling (for security-conscious boundaryrouters).

We collect the data by repeating the above test 100 timeswith an interval of two seconds for each delivery method.The results are shown in table 2 for small packets and ta-ble 3 for large packets. For this experimental setup, ourflexible mechanism reduces the latency by one half for bothsmall and large packets when choosing regular IP over thedefault Mobile IP behavior. Even when mobility support isnecessary, this flexible mechanism still reduces the latency

146 X. ZHAO ET AL.

by about one third for small and large packets when we canchoose the triangular route over the robust but more costlybi-directional tunnel.

6.2.2. CostWe measure both the time spent in doing regular routelookup and the time spent in doing route lookup with a Mo-bile Policy Table lookup on a mobile host. We then examinethe difference to determine the added latency in making pol-icy decisions according to the Mobile Policy Table.

The results are shown in table 4. The overhead of consult-ing the Mobile Policy Table in route lookups is small, lessthan 20µs even when the entries are not currently cached.This is less than one percent of the round-trip time betweentwo hosts on the same Ethernet segment (typically around2 ms).

6.3. Experiments with multiple active interfaces

The main possible source of overhead for supporting multi-ple interfaces is the flow demultiplexing processing on thehome agent, which may affect both the latency and thethroughput. The goal of the experiments described in thissection is to evaluate the latency cost of this demultiplex-ing, i.e. the extra time it takes for a home agent to forward apacket addressed to a mobile host.

The setup of our test environment is illustrated in fig-ure 11. For these experiments, the mobile host connectsto a foreign network on one of our department’s Ethernets

Table 2Latency comparison when using small packets. Using 64 bytes of ICMPdata (i.e. the default ping packet size), the test for each delivery method is

repeated 100 times with an interval of 2 s.

Delivery method Min (ms) Max (ms) Avg (ms) Standard deviation

Bi-directional tunneling 7.3 9.3 7.9 0.36Triangular route 4.5 6.2 5.0 0.35Regular IP 2.0 4.0 2.4 0.35

Table 3Latency comparison when using large packets. Using 1440 bytes of ICMPdata, the test for each delivery method is repeated 100 times with an interval

of 2 s.

Delivery method Min (ms) Max (ms) Avg (ms) Standard deviation

Bi-directional tunneling 37.4 42.4 38.4 1.2Triangular route 24.6 30.9 25.4 1.0Regular IP 11.5 14.5 12.4 0.6

and registers its current care-of address with its home agent.The correspondent host sendsping packets to the mobilehost. We measure the flow binding demultiplexing timeat the home agent by monitoring the code using the Linuxdo_gettimeofday kernel function. We consider twocases: when the home agent has no Flow-to-Interface bind-ings, regular Mobile IP is used; when the home agent con-tains Flow-to-Interface bindings, it must search the list ofbindings before forwarding a packet to the mobile host.

We collect the data by repeating the above test 10 timeseach as the number of bindings in the home agent’s list in-creases from 0 to 60. Table 5 displays the results.

These results for the flow binding demultiplexing costmay seem large compared to the demultiplexing time in-curred with regular Mobile IP on the home agent (2.1µs),but the extra cost is a small additional factor when comparedto the round-trip time between the mobile host and the corre-spondent host, which is approximately 5400µs in this exper-imental setup. The flow binding demultiplexing cost variesfrom 2.3µs for one binding to 9.2µs for 60 bindings.

Note that the cost per flow binding decreases as the num-ber of flow bindings in the list increases, with the result con-verging to about 0.12µs. This result is explained by thestructure of the flow binding lookup function. This func-tion is composed of two parts. The first part takes a fixedamount of time to locate an entry for the mobile host in the

Figure 11. Setup of the test environment for experiments on flow demulti-plexing. The Mobile Host is a Gateway2000 (486DX2-40 processor) andthe Home Agent is a Toshiba Tecra (Pentium 133 MHz), both of which havean Ethernet interface as well as a Metricom radio interface. The Correspon-

dent Host is a 90 MHz Pentium. All machines are running Linux.

Table 4Cost to support the simultaneous use of multiple packet delivery methods. This experiment measures boththe time needed for the regular route lookup and the time spent to do the modified route lookup with MobilePolicy Table (MPT) consultation. Each measurement is repeated 10 times. We tested cases for both a cache

hit and a cache miss when looking up routes.

Cached Uncached

Experiment Time (µs) Standard deviation Time (µs) Standard deviation

Regular route lookup 18.5 0.8 100.1 0.9Route lookup with MPT 23.5 0.7 116.5 1.2


Table 5Flow binding demultiplexing cost. The packet processing column displays the total time spent by the homeagent in deciding how to forward a packet to the mobile host. The demultiplexing by flow column displays

the cost of flow demultiplexing which is part of the total packet processing time.

Packet processing Demultiplexing by flow

Flow bindings Time (µs) Standard deviation Cost (µs) Per binding (µs)

0 2.1 0.30 N/A1 2.3 0.45 0.2 0.202 2.7 0.30 0.6 0.30

10 3.9 0.30 1.8 0.1820 4.7 0.46 2.6 0.1330 5.3 0.46 3.2 0.1140 6.7 0.64 4.6 0.1260 9.2 0.40 7.1 0.12

mobility binding table on the home agent by hashing on themobile host’s home IP address. The second part searchesinto a list for a flow binding corresponding to the incomingpacket. When the number of bindings in the list is small, thecost of the first part dominates. On the other hand, when thenumber of bindings in the list is large, the cost of the firstpart is amortized, and its effect becomes negligible.

7. Related work

There are several projects focusing on providing flexibilitysupport for mobile hosts at different layers of the networksoftware stack.

Work at Oregon Graduate Institute and Portland StateUniversity [12] concentrates on lower network layers thanours. It addresses the flexibility needs of a mobile host inthe face of physical media changes, mainly dealing with IPreconfiguration issues. The focus is on a model that deter-mines the set of available network devices and dynamicallyreconfigures a mobile system in response to changes in thelink-layer environment.

The CMU Monarch project [13] aims at enabling mobilehosts to communicate with each other and with stationary orwired hosts transparently and adaptively, making the mostefficient use of the best network connectivity available to themobile host at any time. It has an overall goal similar to ours,although the project currently does not support the use ofmultiple packet delivery methods simultaneously. Monarchalso focuses on ad hoc networking, which we currently donot support.

The CMU Odyssey project [23] extends the Unix systemcall interface to support adaptation at the application layer.Odyssey exposes resources to applications by allowing themto specify a bound of tolerance for a resource. When the be-havior of the resource moves outside the tolerance window,the application is informed via an up-call.

Making simultaneous use of multiple interfaces is alsoan important goal of the work by Maltz and Bhagwat [19].Their approach provides transport layer mobility by split-ting each TCP session between a mobile host and a serverinto two separate TCP connections at the proxy, throughwhich all packets between the mobile host and the server will

travel. It allows a mobile host to change its point of attach-ment to the Internet by rebinding the mobile-proxy connec-tion while keeping the proxy-server connection unchanged.It can control which network interfaces are used for differentkinds of data leaving from and arriving at the mobile host.However, their work differs from ours in that it does not useMobile IP and it selects the interface by explicitly pickingthe corresponding IP addresses to use on a per session basis,while with our enhancement to Mobile IP, we can select dif-ferent interfaces to use for different flows even if the mobilehost always assumes its static home address.

The BARWAN project [15] at UC Berkeley also providesnetwork layer mechanisms to support mobile hosts, but witha different focus. It aims at building mobile information sys-tems upon heterogeneous wireless overlay networks to sup-port services allowing mobile applications to operate acrossa wide range of networks. They concentrate on providinglow-latency handoffs among multiple network devices.

The use of a Mobile Policy Table is similar to the Secu-rity Policy Database (SPD) in IPsec [16], which needs to beconsulted in processing all traffic. While the Mobile PolicyTable is used to direct the addressing and routing decisions insending packets, the SPD deals with the security aspects oftraffic control. Another difference is that the Mobile PolicyTable is only in effect for outgoing traffic. It affects the in-coming traffic through the selection of the source IP addressfor the outgoing traffic and/or through coordination with thehome agent. The SPD is in effect for both inbound and out-bound traffic all the time.

In summary, our approach focuses on the network layer,providing increased support for a mobile host to control howit sends and receives packets. Our work differs from otherwork in the combination of the following features:

1. Mobile IP is an integral part of our system. We addressthe issue of how Mobile IP can be used most efficientlyand flexibly on mobile hosts.

2. Our system provides support for multiple packet deliv-ery methods.

3. Our system enables the use of multiple active interfacessimultaneously.

148 X. ZHAO ET AL.

8. IPv6 considerations

With IPv6 [11] a mobile host will always be able to obtain aco-located care-of address in the network it is visiting. How-ever, the fact that a mobile host will always have both a homerole (acting as a host still connected to its home network) anda local role (acting as a normal host in the visited network)simultaneously will still be an issue. An example is in mul-ticast scoping. A mobile host needs to assume its home roleif it wants to join the multicast group scoped within its homedomain, while it needs to assume its local role to join themulticast group scoped within the visited domain. There-fore, because of the duality of the roles a mobile host canassume, there is always the need for a mobile host to selectdifferent packet delivery methods for different traffic flows.

With regard to multiple interface management underIPv6, we have the following observations:

1. Mobile IPv6 [26] provides route optimization. As a re-sult, the correspondent hosts can send packets directlyto the mobile host without going through the homeagent. Therefore, the Flow-to-Interface binding exten-sions need to be sent to the correspondent hosts as well.

2. The IPv6flow label field can be very useful for pro-viding multiple interface support. The flow label is afield of the IPv6 header that is set by the source of thepacket and used by routers to identify flows. This flowlabel field could be used by the Home Agent to demulti-plex packets and forward them on the appropriate inter-faces without looking into the transport layer field forthe port information to identify a flow. This also sim-plifies the handling of fragmented packets on the homeagent by eliminating the need to reassemble them beforeforwarding them to the mobile host.

3. IPv6 provides apriority (class) field used by routers toprovide different services to different types of packets.This field can potentially be used in our proposal by thehome agent in determining the most appropriate inter-faces through which to forward packets addressed to amobile host in the absence of Flow-to-Interface bindingregistrations.

9. Conclusions and future work

Because of a mobile host’s use of multiple interfaces andthe dynamic environment in which it may operate, a mobilehost using Mobile IP demands flexibility in the way it sendsand receives packets. Fine granularity control of networktraffic on a per flow basis is needed. Our experiments showthat with reasonable overhead we can address the flexibilityneeds of a mobile host by maintaining a balance between therobustness and efficiency needs of packet delivery.

It is desirable to choose different packet delivery methodsaccording to the characteristics of different traffic flows. Wehave devised a general-purpose mechanism at the network

routing layer to make this possible by coupling the consulta-tion of a Mobile Policy Table with the regular routing tablelookup.

It is also desirable for a mobile host to be able to make useof multiple network interfaces simultaneously for differentflows of traffic. For this, we have added two new socketoptions and have extended the Mobile IP protocol with newregistration extensions so that a mobile host has more controlover which interface to use to send and receive packets.

Acknowledgements

We thank Petros Maniatis, Kevin Lai, Mema Roussopoulos,and Diane Tang of MosquitoNet Group for discussions andfeedback on the ideas presented in this paper. Ajay Bakreand Charlie Perkins provided thoughtful comments and sug-gestions on an earlier version of the paper. We are also grate-ful to the anonymous reviewers for their extremely detailedcomments.

This work was supported in part by a student fellowshipfrom Xerox PARC, a Terman Fellowship, a grant from NTTDoCoMo, and a grant from the Keio Research Institute atSFC, Keio University and the Information-Technology Pro-motion Agency, Japan.

References

[1] A. Acharya, A. Bakre and B. Badrinath, IP multicast extensions formobile internetworking, in:Proceedings of the IEEE INFOCOM’96(1996).

[2] J. Agosta and T. Russell,Cellular Digital Packet Data Standards andTechnology(McGraw-Hill, 1996).

[3] M. Baker, X. Zhao, S. Cheshire and J. Stone, Supporting mobilityin MosquitoNet, in: Proceedings of the Annual USENIX TechnicalConference(1996).

[4] Computer Emergency Response Team (CERT), IP spoofing attacksand hijacked terminal connections, in:CA-95:01(1995).

[5] DARPA Internet program, Transmission Control Protocol, RFC 793(1981).

[6] S. Deering and D. Cheriton, Multicast routing in datagram internet-works and extended LANs, ACM Transactions on Computer Systems8(2) (1990) 85–110.

[7] R. Droms, Dynamic host configuration protocol, RFC 2131 (March1997).

[8] P. Ferguson and D. Senie, Network ingress filtering: Defeating de-nial of service attacks which employ IP source address spoofing, RFC2267 (1998).

[9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, Hy-pertext Transfer Protocol – HTTP/1.1, RFC 2068 (1997).

[10] T.G. Harrison, C.L. Williamson, W.L. Mackrell and R.B. Bunt, Mo-bile multicast (MoM) protocol: Multicast support for mobile hosts,in: Proceedings of the Third Annual ACM/IEEE International Con-ference on Mobile Computing and Networking(1997).

[11] C. Huitema,IPv6: The New Internet Protocol(Prentice Hall, 1997).[12] J. Inouye, J. Binkley and J. Walpole, Dynamic network reconfigura-

tion support for mobile computers, in:Proceedings of the Third An-nual ACM/IEEE International Conference on Mobile Computing andNetworking(1997).

[13] D.B. Johnson and D.A. Maltz, Protocols for adaptive wireless andmobile networking, IEEE Personal Communications 3(1) (1995) 34–42.


[14] D.B. Johnson and C. Perkins, Route optimization in Mobile IP,Internet draftdraft-ietf-mobileip-optim-10.txt (2000)(work in progress).

[15] R.H. Katz and E.A. Brewer, The case for wireless overlay networks,in: Proceedings of the SPIE Conference on Multimedia and Network-ing (1996).

[16] S. Kent and R. Atkinson, Security architecture for the Internet Proto-col, RFC 2401 (1998).

[17] K. Lai, M. Roussopoulos, D. Tang, X. Zhao and M. Baker, Expe-riences with a mobile testbed, in:Proceedings of the Second Inter-national Conference on Worldwide Computing and its Applications(WWCA’98)(1998).

[18] Lucent Technologies, WaveLAN support (2000),http://www.wavelan.com/support/index.html

[19] D.A. Maltz and P. Bhagwat, MSOCKS: An architecture for transportlayer mobility, in:Proceedings of the IEEE INFOCOM’98(1998).

[20] Metricom, The Ricochet wireless network overview (2000),http://www.metricom.com/ricochet_advantage/tech_overview/index.html

[21] G. Montenegro, Reverse tunneling for Mobile IP, RFC 2344 (1998).[22] G. Montenegro and V. Gupta, Sun’s SKIP firewall traversal for Mobile

IP, RFC 2356 (1998).[23] B. Noble, M. Satyanarayanan, D. Narayanan, J.E. Tilton, J. Flinn and

K. Walker, Agile application-aware adaptation for mobility, in:Pro-ceedings of the 16th ACM Symposium on Operating System Principles(1997).

[24] C. Perkins, IP encapsulation within IP, RFC 2003 (1996).[25] C. Perkins, IP mobility support, RFC 2002 (1996).[26] C.E. Perkins and D.B. Johnson, Mobility support in IPv6, in:Pro-

ceedings of the Second Annual ACM/IEEE International Conferenceon Mobile Computing and Networking(1996).

[27] J. Postel, Internet protocol, RFC 791 (1981).[28] S.H. Redl, M.K. Weber and M.W. Oliphant,An Introduction to GSM

(Artech House, 1995).

Xinhua Zhao is a Ph.D. candidate in computer sci-ence at Stanford University. His research interestsare in the areas of mobile and wireless computing,computer networks, and distributed systems. Hereceived his B.S. degree in computer science fromUniversity of Science and Technology of China andhis M.S. degree in computer science from StanfordUniversity. He is a student member of ACM andIEEE.E-mail: [email protected]

WWW: http://mosquitonet.stanford.edu/˜zhao

Claude Castelluccia is a Research Scientist atINRIA (Institut National de Recherche en Informa-tique et Automatique), France, in the High SpeedNetworking group. He received a MS in electri-cal engineering from FAU (Florida Atlantic Univer-sity) and a PhD in computer science from INRIASophia-Antipolis. His research interests includenetwork protocols, mobile computing and digitalsignal processing.

Mary Baker is an Assistant Professor in the De-partments of Computer Science and Electrical En-gineering at Stanford University. Her interests in-clude operating systems, distributed systems, andsoftware fault tolerance. She is now leading the de-velopment of the MosquitoNet mobile and wirelesscomputing project and the Mobile People Architec-ture. Baker received a BA degree in mathematics in1984 from the University of California at Berkeley,and MS and PhD degrees in computer science in

1988 and 1994 also from University of California, Berkeley. Baker is a re-cipient of an Alfred P. Sloan Research Fellowship, a Terman Fellowship, anNSF Faculty Career Development Award, and an Okawa Foundation grant.She is a member of the ACM, the IEEE, and USENIX.

Documents

Flexible Network Support for Mobile Hosts