Implementation and Evaluation of Internet Connectivity forMobile Ad hoc Networks

Erik Nordstrom Per Gunningberg Christian Tschudin∗

Department of Information Technology, Uppsala University

{erikn|perg}@it.uu.se

Abstract

We describe how we have implemented and evaluatedways to provide robust Internet connectivity for mobile adhoc networks. In such dynamic networks, the occurrenceof multiple gateways, high mobility and lack of consis-tent addressing put new demands on the strategies to movedata between the ad hoc network and the Internet. Withindividual node mobility, a network wide shared state inthe form of a default route might not be the most efficientstrategy. Nodes might need to select their own gatewaydepending on their mobility and topological placement inthe network. This can be achieved by using source rout-ing or tunneling. We have implemented a system whichcombines AODV and Mobile IP and that uses tunnelingto select gateways on a per flow basis. We compare thisto using default routes and show the flexibility and effi-ciency of the tunneling approach by extensive evaluationin simulation. Based on this result we have implementeda real prototype system using LinkSys routers that com-bines Mobile IP and AODV with tunneling. A versionof this prototype was successfully demonstrated at Mobi-Com 2004.

1 Introduction

The IETF Mobile Ad hoc NETworks (MANET) workinggroup [3] has for many years worked towards standardiz-ing IP-based routing in ad hoc networks. But to this date,the charter has not dealt with the integration of ad hocnetworks with fixed networks, e.g., the Internet. How-ever, with increasing maturity of MANET routing, In-ternet connectivity is gaining interest. The present workfirst evaluates the state of the art and then describes anintegrated system that combines ad hoc routing and Mo-bile IP to provide robust Internet connectivity for ad hocnetworks. We have evaluated this system in simulationand also implemented it using LinkSys WRT54G wirelessrouters.

∗Computer Science Department, University of Basel,christian.tschudin@unibas.ch

Two of the most important issues to be solved for seam-less Internet connectivity is address configuration andgateway discovery. Effectiveness of different approachesto gateway discovery have been extensively evaluated in[11, 16, 17], and address configuration issues in [20, 21].Our work is complementing that work on address con-figuration and gateway discovery. We look at the impacton MANET routing by alternative forwarding strategiesto gateways. Forwarding packets to external destinationsis non-trivial because MANETs may have flat addressing(i.e., nodes do not have any address prefixes). Thereforethe MANET protocols are not in general able to resolveroutes to destinations outside the ad hoc network. An-other likely situation is that there may be multiple gate-ways, multiple hops away. It may then be necessary totrack gateways to do hand-over without interrupting con-nections. Other reasons for multiple gateways could befor efficiency, to exploit multi-homing or for load balanc-ing. We show in this paper that default routes, common intraditional LANs, do not work well in such environments,despite being suggested in [6, 9, 21]. Instead we find thatadding an indirection header where we can address a gate-way explicitly, in form of encapsulation (tunneling) [11]or using source routing [10], is more efficient and supportsmultiple gateways.

For the purpose of the discussion we use a scenario withMobile IP (MIP) derived from [11, 4, 19, 22, 21]. Thescenario network is illustrated in Figure 1. In this set-ting, MIP provides topologically correct addressing fornodes in the ad hoc network by hiding topologically in-correct addresses behind one or more care-of addresses.This allows nodes to keep their home network addresseswhen visiting a foreign network (without additional ad-dress configuration), while still enjoying full Internet con-nectivity. In other words, MIP solves the problem of howto route to addresses that are not located at the correctplace in the Internet’s hierarchy. However, with multi-hop ad hoc edge networks, MIP only solves half of theproblem - how to get traffic into the ad hoc network. Re-active routing protocols, e.g., AODV [15] and DSR [10]have problems resolving routes to nodes external to the adhoc network.

The purpose of this paper is to compare forwarding

strategies with respect to efficiencies and to suggest im-provements. We evaluate the approaches in simulationand then describe a real world prototype system usingAODV and the tunneling approach. Our testbed usesLinkSys routers that are foreign agent gateways runningthe Dynamics Mobile IP implementation [2].

130.238.12.5 63.3.5.23

142.67.8.24510.0.4.2

130.238.12.1

192.168.6.1

65.43.32.1

66.35.250.151

192.168.1.1

130.238.8.1MIP Tunnel

HA

FA

MN

Internet

Figure 1: A wireless multi-hop ad hoc edge networkwith “random” addresses and gateways acting as MobileIP Home Agent (HA) and Foreign Agent (FA). MobileNodes (MN) move between gateways.

The contribution of this paper is the comparison of twogateway forwarding principles; default routes and tunnel-ing. They are compared with respect to transparency toMANET protocols, ability to handle multiple gateways,the overhead and performance. The forwarding strategiesare performance evaluated in ns-2 simulations. We showthat default routes do not work correctly with multiplegateways. Our conclusion is that tunneling is simpler toimplement, is more architecturally appealing, is transpar-ent, is more efficient than default routes and works wellwith multiple gateways. Early results from this work waspresented in poster form at MobiHoc 2004 [14].

The rest of the paper is structured as follows. In section2 we discuss related work. Section 3 introduces problemswith forwarding to gateways. We continue in section 4with discussing suggested modifications to improve de-fault routes in multi-hop ad hoc network scenarios. Insection 5 we explore tunneling to gateways and report insection 6 on our prototype system for Internet connectiv-ity and describe our experimental setup. Section 7 reportson results from evaluating default routes and tunnels insimulation and briefly looks at proof-of-concept resultsfrom our real world experimental testbed. Section 8 con-cludes the paper.

2 Related Work

In this section we review the main proposals for mobilead hoc network Internet connectivity.

Belding-Royer et al. proposes Globalv4 [4] which inte-grates Mobile IP with the AODV routing protocol. Glob-alv4 assumes flat addressing. This means that AODVmust do a local search for the destination in the ad hocnetwork before it searches for a gateway. If no route re-ply is received from the local search it is assumed that thedestination is on the Internet. This solution suffers fromrelative long route discovery delays and lacks route aggre-gation. Furthermore, for transparency sequence numbersmust be maintained for foreign destinations although theydo not exist in the local ad hoc network. A similar sys-tem is described and evaluated by Sun et al. in [17]. Theyexamine the effect of varying the agent beaconing inter-val for different network sizes. They also study the per-formance in terms of average packet latency and AODVoverhead. Similar solutions for integrating MIP with adhoc networks can be found in [19, 22].

Globalv6 by Wakikawa et al. [21], can also work withMobile IP, but it is not mandatory. Globally routable IPaddresses can be acquired by IPv6’s auto-configurationmechanism. Globalv6 employs a similar technique asGlobalv4 to determine the locality of destinations. Rout-ing towards the gateway is done on a hop-by-hop basisusing a default route. In [13], Nilsson et al. describes howsuch a solution can suffer from cascading route requests.This means that each intermediate node (along the path tothe gateway) must flood the network with a fresh route re-quest and hence the solution quickly becomes inefficient.However, in Globalv6, these cascading effects are avoidedby requiring intermediate nodes to configure host routeentries in the route setup phase. The consequence of thisrequirement is that route aggregation is lost. Maintain-ing host route entries in this way also suffers from a statereplication problem. Missing host route states at nodesseverely impacts the performance and correct operationof this default route solution, as we show in section 7.

Cha et al. proposes an Internet connectivity system forAODV [6] which integrates several different forwardingstrategies. The idea is to be able to chose between hostroute, default route or tunnel forwarding depending onapplicability. Such a system has drawbacks in terms ofcomplexity as it is necessary for nodes to support all threemodes of forwarding.

Jelger et al. [9] propose a system that ensures pre-fix continuity for MANETs that connect to the Internetthrough one or more gateways. All gateways announcetheir prefixes into the ad hoc network. Nodes carefullyselect addresses within the prefix of, e.g., the closest gate-way, creating disjoint stub networks that share the sameprefix. These stub networks contain a routing tree suchthat nodes can restrict themselves to storing a single de-fault route. Such a system works best with proactive rout-ing protocols using IPv6 and targets specific scenarioswhere prefix continuity is important (e.g., Hotspot opera-tors).

2

Jonsson et al. studies in [11] the integration of Mo-bile IP in MANETs. They describe a system calledMIPMANET where Mobile IP is adapted to work withMANETs running the AODV routing protocol. Tunnel-ing from ad hoc nodes to the foreign agent is proposed asa way to achieve default route like behavior. However,the main result presented is the effect of using unicastor broadcast transmissions for periodic agent advertise-ments. We believe that periodic agent advertisements arenot suitable for ad hoc networks using reactive routing.

Ratanchandani et al. suggest in [16] a similar solutionto MIPMANET. However, they also study the efficiencyof agent discovery and suggest a hybrid approach wherethe TTL of agent announcements is used to limit propa-gation to a n-hop neighborhood. Nodes further away needto send agent solicitation messages to discover agents. Insimulation they experimentally derive an optimal TTL forthis approach.

Gateway discovery in on-demand MANETs is studiedin [7], where Engelstad et al. examines problems withgateway proxy route replies in the presence of NetworkAddress Translation (NAT). They find that tunneling togateways is one way to avoid race conditions from proxyroute replies when there are multiple gateways. This isin line with our findings as well. In fact, they used ourAODV-UU [1] tunneling implementation for their study.

Some of the work in this paper was presented in posterform at MobiHoc 2004 [14]. There we reported on prob-lems with default routes and TCP in the presence of mul-tiple gateways. Later Engelstad, Tønnesen, Hafslund andEgeland [8] reported on similar results in their study of In-ternet connectivity in multi-homed proactive ad hoc net-works. They also suggest tunneling to the gateways as asolution. However, their work focuses on proactive rout-ing, which because of its global knowledge of the ad hocnetwork makes it easier to support Internet connectivity.

The Dynamic Source Routing protocol (DSR) [10] isinteresting because it uses source routing and thereforesupports the type of indirection that tunnels provide to op-erate efficiently with (multiple) gateways. Tunnels wouldtransparently work also with DSR, but it would be an un-necessary addition.

We also point to the LUNAR protocol [18] which tun-nels all network traffic directly over the wireless linklayer. LUNAR uses a kind of ARP forwarding as routerequest messages to discover destination nodes. The ARPreply corresponds to a route reply message and is usedto build a data delivery tunnel between the involved mo-bile nodes. Because LUNAR creates a complete one-hopillusion to the IP layer, gateway connectivity is easy tosupport.

3 Gateways in Mobile Ad hoc Net-works

In this section we discuss the main challenges and possi-ble solutions for forwarding to gateways in multi-hop adhoc networks. The intention is to give the reader a bet-ter understanding of the intricate problems that can occurin interaction between MANETs and fixed networks (e.g.,the Internet). We focus on a network with flat addressingand reactive routing (Figure 1), but sometimes compareto situations with prefix-based addressing and proactiverouting. We base our argumentation around using AODV,although some of the problems we discuss are not sharedby all reactive routing protocols (e.g., source routed).

3.1 Determining a Destination’s Location

In Internet connected MANETs, whenever an ad hoc nodewants to communicate with another host, it first needs tofind out the whether the destination is currently in the adhoc network or a host on the Internet. If all nodes in thead hoc network share an address prefix the source node aswell as a gateway can decide by themselves whether a des-tination is local or not by just inspecting the address pre-fix. Similarly, with a proactive routing protocol all mobilenodes are known as well as the gateway, so in that casethe source can determine from its routing table whetherthe destination is part of the ad hoc network or not.

On the other hand, if the network runs a reactive proto-col like AODV [15], an ad hoc network wide flooding ofroute requests for the destination must be launched. Forfixed Internet destinations there should be no route repliesaccording to the default operation of the protocol. Thelack of replies can be used by the source node as an indi-cation that the destination potentially resides in the fixedInternet, as is suggested in [11, 21].

A more efficient approach than timing out on thesource’s route request is suggested by Broch et al [5].They propose that the gateway can, in response to a routerequest, send a proxy route reply to signal that it can takecare of the forwarding to the requested destination. Be-fore sending such a reply the gateway must ensure itselfthat the destination is not in the ad hoc network. This canbe done in different ways, including flooding the networkwith a new route request, by keeping a list of currentlyknown active nodes (visitor list) or by pinging the desti-nation on the gateway’s network interface attached to theInternet.

Such an approach may also have additional benefits inthat gateways can selectively reply to route requests de-pending on specific policies. For example, a network op-erator might not want to announce its gateway services tosome nodes or an overloaded gateway might stop replyingwhen the load reaches a certain threshold.

3

3.2 Gateway Discovery

MANET nodes can discover available gateways in differ-ent ways. In proactive routing, the most efficient way is toembed gateway announcements in for example link-stateupdate messages. For reactive routing, a number of ap-proaches are available. For Mobile IP integration manysuggest periodic agent advertisement into the ad hoc net-work [11, 17, 22, 16]. However, for reactive routing itmakes more sense to also have reactive gateway or agentdiscovery. With a proxy route reply solution, as describedabove, this can be integrated with the route discoverymechanism of the routing protocol to make it more effi-cient.

3.3 Forwarding using Host Routes

In a flat address MANET, routing protocols use hostroutes to forward packets within the network. Host routescan also be used to forward traffic to external destina-tions through a gateway. However, this requires oneroute entry for each destination on the Internet. Therouting tables will grow and all routes must be inde-pendently maintained. This might not be optimal forsmall devices with limited memory capabilities (in a re-active routing approach it is also necessary to maintainsoft state and timers associated with each routing tablestate). As we discussed in related work, this approachrequires that external addresses are “imported” into theMANET, and for some routing protocols (e.g., AODV),destination sequence numbers must be maintained forthose routes although the destinations do not actually ex-ist in the MANET. Furthermore, with hop by hop rout-ing it is not possible to track which gateway packets areforwarded to, since a gateway can not be explicitly ad-dressed. An unannounced gateway change (the routingprotocol finds a shorter route leading to another gateway)could be a problem for MIP which requires registrationwhen switching agent or for NATs that keep state in thegateway.

3.4 Forwarding using Default Routes

In a general IP routing context, a default route is a routingtable entry that matches any address prefix. In a tradi-tional LAN, the next hop is an Internet gateway and alladdresses outside the local network’s subnet is mapped tothe default route to achieve route aggregation. However,in multi-hop ad hoc networks a default route must some-times be created over multiple hops. In combination withreactive routing, addresses can not simply be mapped to adefault route because there is no subnet and routing tablesonly contain destinations in active communication. Thismapping problem can cause cascading route look-ups, aswe explained in section 2. Repeated route discoveries ateach intermediate node on the path to the gateway makes

for a very inefficient approach. Similar to host routes, de-fault routes are hop by hop and consistent paths to gate-ways are hard to maintain.

3.5 Multi-homing

Today it is not uncommon that mobile devices have morethan one network interface to connect to the Internetthrough different access networks. For example, a lap-top may have both a GPRS and a WiFi interface. Thesemulti-homed devices may need to route packets over bothinterfaces at the same time to achieve smooth hand-overor load balancing. Or, in multi-homed sites there might beonly one network interface, but multiple gateways in thesame network (e.g., as in Figure 1). For similar reasons,connections to multiple gateways might be beneficial.

However, neither host route nor default route forward-ing easily (or at all) support this kind of operation. Bothare hop by hop and when forwarding a packet it is hardto guarantee that the transient host mapping at each hopconsistently points to the same gateway. Furthermore, adefault route (by definition) only points to one gateway.One solution is to slightly change the concept and config-ure multiple default routes pointing to different gatewaysand then on the source node map Internet destinations tothe desired default routes. However, the transient defaultroute mapping makes it impossible for an intermediatenode – although it knows about both gateways – to in-fer which default route the source intended the packet tobe forwarded on.

Although host routes and default routes are suggestedin many proposals for MANET Internet connectivity [4,6, 21] , there are many limitations with these forwardingapproaches when we have to deal with multiple gatewaysto exploit multi-homing and hand-over. In the next sectionwe will look at modifications to default routes that havebeen suggested in related work that aim to overcome someof the problems and limitations discussed.

4 Default Routes and Mobile Adhoc Routing

In this section we analyze suggested modifications to thedefault route concept that aim to make it work betterin MANETs. However, despite these modifications wehave found two serious problems with this approach thatseverely affects its ability to function properly, especiallywith multiple gateways.

4.1 Routing Table Configuration

In a single hop LAN environment, the default route entrypoints to the default gateway that a host uses to forwardpackets to the Internet. In a multi-hop environment, we

4

can chose different meanings for a default route. Considernode MN’s (Figure 1) routing table. In Figure 2 we haveeither:

(a) the default route indicates the next hop to the defaultgateway, or

(b) it indicates which gateway is currently selected to bethe default.

With one hop to the gateway the two views are thesame, but in the multi-hop case there are important dif-ferences. In (a) the default route maps to the next hop

Destination Next Hop Hop Cnt

default 366.35.250.151

192.168.1.1 63.3.5.2363.3.5.23 63.3.5.23

default192.168.1.1

_

31

Destination Next Hop Hop Cnt63.3.5.2363.3.5.23

66.35.250.151default

default63.3.5.23

1_

3

(b)(a)

Figure 2: Two different routing table configurations to thesame end. The address 66.35.250.151 is a destination onthe Internet.

(63.3.5.23) and there is no explicit entry for the gate-way. There is no way to know which gateway this de-fault route ends at. In (b), suggested in the Globalv6 pro-posal [21], the default route maps to the gateway address(192.168.1.1) and this gateway entry is used to find outthe corresponding next hop. Here it is possible to knowwhich gateway the default route leads to, but this mappingstate must also be consistent at each hop to the gateway.

Note that (a) may require two routing table accessesand (b) in worst case three. Route look-ups may be neces-sary at each intermediate node on the path to the gatewayand might prove costly. Additionally, nodes have to con-figure an extra host route entry for the destination to avoidsubsequent route discoveries with reactive routing proto-cols. Although it is possible to pre-compute these seriesof mappings so that only one look-up is needed, these en-tries are usually soft states (as in the case of AODV) andneed to be refreshed for each forwarded packet.

Another advantage with the routing table in Figure 2 (b)is that it simplifies destination sequence number handlingfor routing protocols that require it. It is not necessary tokeep a sequence number for the default route since it isjust a mapping to a (gateway) host entry. In Figure 2 (a),however, the default route is a “destination” and thereforeneeds a sequence number of its own.

However, there are some advantages with a defaultroute approach. In case the locality of a destination couldbe determined by a prefix check or from the fact thatthe network use proactive routing, the default route en-try could function in the traditional way without the oth-erwise required host route entry. Another advantage isthat each intermediate node keeps default route state andtherefore a default route can be updated to point to a new

gateway without the update messages having to backtrackall the way back to the source node furthest away fromthe gateway. However, at the same time this is also one ofthe main disadvantages of default routes as we shall seein section 4.3.

4.2 State Replication Problem

Consider the routing table configuration in Figure 2 (b).Whenever a route to a gateway is updated, intermediatenodes that were not part of the path before the update,must gather the mapping state (host → default route) ofall nodes that use that route. Otherwise, they will not beable to forward any packets to those destinations.

SA SASA SASA

A B CA B GWGWC

D D

(b)(a)

Figure 3: State replication problem with default routes.Note how the intermediate node D is missing the stateof node A when node B repairs the default route (to thegateway) after a link break between B and C.

Figure 3 illustrates one possible (and simple) configu-ration where this problem can occur. In Figure 3 (a), adefault route has been configured to the gateway GW bya route discovery for an Internet destination initiated bynode A. In the route setup phase A’s host route state (SA)for the destination is added to all the intermediate nodes(e.g., entry 66.35.250.151 in Figure 2). In (b), a link breakhas occurred between node B and C. B repairs the defaultroute to the gateway, but the host route entry state SA isnot replicated on the new intermediate node D since thatnode only saw the request for the gateway. An alternativewould be that B requests the Internet destination indicatedby the state SA. However, this would not work if node Ahas several host entries that map to the default route orif there are several upstream nodes that also require theirstates to be replicated. All these destinations would haveto be requested.

A solution to this problem would be to gather all themapping state of upstream nodes in the route request. Butthis would almost certainly require changes to the ad hocrouting protocol and currently we do not know an efficientsolution for this.

4.3 Gateway Tracking Problem

In previous sections, we have discussed problems withkeeping track of which gateway packets are forwarded to.With MIP, gateways must be tracked for agent registra-tion to work or stale NAT state needs to be avoided after a

5

gateway switch. With a routing table like the one in Figure2 (a), it is impossible for a node to track which gateway adefault route currently leads to. A control message (routereply) can switch the default route to another gateway atan intermediate node on the path to the gateway (node Cin Figure 4).

GW2

A

B

C

RREP GW1

GW2

A

B

C

mismatch

GW1

GW2

A

B

C

Default route pointing to GW1 Default route pointing to GW2

RREQ GW1

Figure 4: A route request (RREQ) and route reply (RREP)may create “broken” default routes. A source node (B)may not be notified of a gateway change.

One example of how this problem can occur is depictedin Figure 4. Assume AODV routing and and that gatewayssend proxy route replies for Internet destinations [5]. Adefault route is configured between node B and gateway 2(GW2). Node A sends a request for an Internet destina-tion that the intermediate node C rebroadcasts to GW1and GW2. A collision (or some other transmission fail-ure) occurs at GW2. Therefore, only a route reply fromGW1 will reach node C. Before forwarding the route re-ply to node A, C updates its default route to point to GW1,all according to the information in the route reply. Pack-ets from B are now redirected to GW1 without B beingnotified. In section 7 we will show by simulation that thisis a problem when the gateways act as Mobile IP agents.This would also break NATs.

With a routing table like the one in Figure 2 (b) an in-termediate node is in a position to drop control messagesthat conflict with the currently configured default route,because there is a mapping to the currently used gateway.We show in section 7.1.3 that this can help in scenarioswith multiple gateways and two-way traffic (e.g., TCP).

5 Tunneling to Gateways

We have described how default routes suffer from prob-lems in MANETs. In this section we examine tunnel-ing – proposed by Jonsson et al in [11] – as an alternativeapproach to default routes. Tunneling has the architec-turally appealing property that it can be used by two endpoints to create a one hop illusion over many hops in thereal network. In this context, tunneling achieves limitedsource routing capability for legacy applications. There-fore, many of the benefits of tunneling packets to gate-ways are also achieved by using routing headers, e.g., asin source routing.

5.1 Unidirectional Tunneling

We limit ourselves to unidirectional tunnels. Unidirec-tional tunneling is achieved by taking packets for Inter-net destinations and encapsulating them with a gateway’saddress as destination. Packets are routed in the ad hocnetwork without changes to the ad hoc routing protocol.Figure 5 depicts one possible routing table configurationof the source node, gateway and intermediate nodes. Theimmediate benefit is that intermediate nodes only have tomaintain a host route to the gateway. The transient hop byhop mappings that have problems with multiple gateways,seen with host routes and default routes, do not exist here.Instead the gateway mappings are carried in the packetsand are decided by the source nodes only.

Tunneling in the reverse direction is optional becausepackets entering the ad hoc network from the fixed In-ternet will be translated to a local address by the addresstranslation or will have to source node’s home address ifthe gateway is a MIP home or foreign agent. Thus, theextra indirection step is not needed. Tunneling incurs asmall overhead per packet due to the encapsulation.

5.2 Benefits

Tunneling exhibits the following desirable properties:

Protocol transparency. The tunneling concept is trans-parent with existing routing protocols. The minimum re-quired modifications are extra routing table states in thesource and gateway nodes which do not affect the pro-tocol. There is no need for new state in intermediatenodes. This means that intermediate nodes can be un-aware of gateways and tunnels, an important characteris-tic for legacy nodes.

No cascading route requests. Cascading effects are nota problem with tunneling because only the source nodeand the gateway need to know about the destination in thefixed Internet. Inside the ad hoc network these packets areexplicitly addressed for a gateway.

Route aggregation. Tunneling achieves route aggrega-tion at intermediate nodes since all Internet destinationsare encapsulated by gateway addresses instead of oneentry for each destination which is the case for defaultroutes.

Stability. Once a source node has configured a tunnel toa gateway, that tunnel will not be diverted to another gate-way unless connectivity with the gateway is completelylost. In that case the source node will be notified and cantake proper actions. For example, to re-register at a newgateway in case the source node is using Mobile IP.

6

Next Hop Hop Count FlagsDestination Next Hop Hop Count FlagsDestination

Next Hop Hop Count FlagsDestination

Internet

66.35.250.151 192.168.1.1

63.3.5.23

63.3.5.23

1

1

3 G

I 192.168.4.3

63.3.5.23

192.168.1.1

65.3.5.23

63.3.5.23

192.168.1.1

2

1

1

192.168.4.3 192.168.4.3

65.43.32.165.43.32.1

192.168.1.1 65.43.32.1

1

1

2

192.168.4.3 65.43.32.1

65.43.32.165.43.32.1

3

1

FlagsHop CountNext HopDestination

63.3.5.23

192.168.1.1

66.35.250.151

63.3.5.23

130.238.12.5Ad hoc src node

192.168.1.1130.238.8.1

Gateway

Tunnel

Encapsulation 63.42.32.1

Decapsulation

Figure 5: Tunnel forwarding with routing tables at each node. Because of the encapsulation, intermediate nodes onlyhave to maintain the gateway route, which reduces the shared state in the network compared to default routes.

Multiple gateways. Source nodes can maintain routesto multiple gateways for fault tolerance and load balanc-ing. Tunneling allow Internet traffic bound for differ-ent gateways over a common intermediate hop, which isnot the case for default route forwarding (see Figure 6).Redundant tunnels can be used as as backup routes if the

(a) (b) (c)

Figure 6: Multiple gateway support: (a) A default routepoints to only one gateway at once. (b) With tunnelingtwo nodes can share an intermediate hop while still main-taining tunnels to different gateways, (c) or one node canhave tunnels to two gateways at once.

connectivity to one gateway is lost. This principle willavoid route request floods for all its current Internet desti-nations at connectivity loss. Furthermore, tunnels to mul-tiple gateways are useful when a node wants to do a softhand-over between gateways.

Efficient forwarding. In terms of routing table look-ups, tunneling is more efficient than the default routecounterpart. A source node needs to perform two look-ups in the routing table. On intermediate nodes, only oneregular look-up is needed, which is a clear advantage overthe default route approach that most likely needs threerouting table accesses, both at the source node as well asat intermediate nodes.

Potential for optimization. In order to increase the ef-ficiency of tunneling, intermediate nodes could be madegateway aware. An extra flag can be used to mark gatewayroutes in the routing tables. This can potentially avoidroute requests if the source node directly can determine

that its own packets should be tunneled to the Internet,e.g., by using a local prefix address.

6 Prototype System Design

In this section we give a brief description of our proto-type system for gateway connectivity using the AODV adhoc routing protocol. AODV is a routing protocol thatdiscovers routes on-demand by flooding the network withroute request packets (RREQs). Route replies (RREPs)are sent back by the destination itself or by nodes with anactive route to the destination. Routes setup through thisprocess are only maintained as long as packets are beingforwarded. Routing loops are avoided by the use of desti-nation sequence numbers.

Our AODV-UU implementation [1] was used as the ba-sis for our modifications.

6.1 Implementation Details

We chose to implement the same type of gateway discov-ery and route setup mechanisms for both default routesand tunneling, so that a comparison would be as fair aspossible. We adopted a proxy RREP solution (as sug-gested by Broch et al [5]) where the route discovery pro-cedure of AODV is slightly extended to unify gatewaydiscovery and route setup. This modification integrateswell with AODV’s reactiveness, is backwards compati-ble and efficient. A node initiates a route discovery byflooding the network with RREQs as it would normallydo when it does not have a route to a destination. A gate-way that receives this RREQ determines address locality(i.e., whether the destination is an Internet host or an adhoc node) and will send a RREP to the ad hoc source nodeif the destination is an Internet host. The address local-ity check at the gateway is implemented through a prefixcheck or using a visitor list. The gateway’s proxy RREPcarries an extra AODV extension with the IP address ofthe requested Internet host for which an ad hoc network

7

node issued a RREQ. The RREP itself looks like a re-sponse to a RREQ for the gateway. This extended RREPis used to configure the default route or tunnel state at thesame time as the gateway route is configured.

In the source node’s routing table, gateways are markedwith a G flag. Although not used for any purpose at thispoint, this flag could be used to indicate backup tunnelsfor faster hand-off. The RREP extension received fromthe gateway is used to configure an Internet host entry onthe source node only. This entry points to the gateway,is marked with an I flag and has a limited life time. Itmaps fixed Internet addresses to the appropriate gatewayaddresses and represent tunnel entries (Figure 5).

Our tunneling approach has been integrated into ourAODV-UU implementation. This code runs in both insimulation (ns-2) and on Linux systems. For the Linuxversion we use Minimal IP encapsulation (RFC 2004),which translates to an overhead of 8 bytes for each datapacket sent through a gateway.

We chose to implement default routes according to theGlobalv6 draft [21]. Routing tables look like the one inFigure 2 (b). Host route entries on intermediate nodes arenecessary to avoid cascading route look-ups. As an optionwe have also implemented RREP dropping (described insection 4.3) to mitigate the gateway tracking problem.

Some optimizations still remain. At this point thetunneling implementation does not support intermediatenode reply for Internet destinations. Another optimiza-tion would be to enable the use of backup tunnels. AnInternet destination marked with an I flag, could easilybe re-pointed to the next active tunnel that is marked witha G flag, without the need for a new RREQ flood.

6.2 Experimental Testbed

As a proof of concept we have implemented an experi-mental testbed using the tunneling approach and MobileIP. Our mobile host (MH) is a IBM T30 2.0 GHz laptoprunning Fedora Core 2 while the rest of the ad hoc net-work nodes and the correspondent host (CH) are AST As-centia P series 133 MHz Pentium machines running ourAPE testbed [12] with Linux kernel 2.4.26. The foreignagents (FAs) are LinkSys WRT54G routers running theOpenWRT Linux distribution with kernel 2.4.20. All adhoc nodes (MN, FAs and AST machines) run the AODV-UU implementation with tunneling. The Home agent(HA) is a 2.4 GHz Pentium 4 desktop machine also run-ning Fedora Core 2. To provide continuous reachabilityfor the MH, Mobile IP is used to redirect the MHs returntraffic whenever it changes its location, i.e., registers witha new FA. The HUT Dynamics Mobile IP implementa-tion [2] was chosen for this purpose. We had to makeslight modifications to the Mobile IP implementation tointeroperate better with the AODV ad hoc routing.

Fortunately, Dynamics has a nice Unix socket based

HA

MH

FA FA

CHHA

MH

FA FA

CH

Figure 7: Experimental testbed setup using LinkSysrouters. The mobile host (MH) has two hop gatewayconnectivity over the ad hoc network. Communicationwith the correspondent host (CH) is established througha bidirectional tunnel between a foreign agent (FA) andthe home agent (HA). When a new gateway is discovered,the MH re-registers with the FA at that gateway and thebidirectional tunnel is re-pointed to the new FA.

API that can be used to communicate with the Mobile IPcode. This allowed us to keep the modifications to boththe Mobile IP and the AODV code to a minimum. Al-though this approach is not optimal we found it sufficientfor our initial testing purposes. The integration of AODVand Mobile IP was implemented as follows. We disabledall proactive agent advertisements in the FAs. Wheneverthe MH floods the network with a AODV route request,the FAs will answer with an extended route reply (de-scribed in the previous section) indicating that this Inter-net destination can be reached through the FA. Immedi-ately after this reply, the AODV daemon on the FA trig-gers the MIP daemon to send an agent advertisement tothe MH on the newly established route. The AODV dae-mon on the MH will force its Mobile IP daemon to selectthe FA that matches the gateway selected by AODV. Whenthe MH receives the agent advertisement it will send a reg-istration message to the selected FA that will configure abidirectional tunnel between the FA and the HA. The ex-perimental testbed configuration is illustrated in figure 7.

7 Evaluation

In this section we start by presenting simulation resultsthat compare the performance of default route and tun-nel forwarding using constant bit rate (CBR) UDP traf-fic and (FTP) TCP traffic. We show that tunnel forward-ing constantly performs better than the default route routecounterpart. The simulations provide the main result ofthis paper. We then continue to present results from ourexperimental testbed. The purpose is to provide a proof-of-concept of how the tunneling approach can functiontogether with AODV and Mobile IP in a real system.

8

70

75

80

85

90

95

100

8 10 12 14 16 18 20

Del

iver

y ra

tio (

%)

Number of mobile nodes

TunnelingDefault routes

Default routes mod. 0

2

4

6

8

10

12

8 10 12 14 16 18 20

Con

trol

traf

fic /

data

(%

)

Number of mobile nodes

TunnelingDefault routes

Default routes mod.

Figure 8: CBR Delivery ratio and normalized control traffic overhead using 2 CBR sources and increasing path lengths.

7.1 Simulations

We use ns-2 version 2.26 and the ns-2 AODV-UU im-plementation of AODV. We have gateway forwarding forboth default routes and tunneling.

We chose to evaluate gateway forwarding in networkscenarios where we scale the number of nodes from 10to 20 mobile nodes, incrementing by two at a time. Twogateways are used in the simulations. We keep node den-sity fixed at 2× 10−5 nodes per m2. Thus, the area size(with an x:y ratio of 1:2) grows with increased number ofnodes. We found this density to be a good balance be-tween network size and number of nodes. We have onemobile node per 223 m square (the two gateway nodesexcluded) and with the default ns-2 transmission radiusof 250m (using the “TwoRayGround” model), we havereasonable coverage as indicated by the performance fig-ures. With a fixed density, routes on average are likely tobe longer as the number of nodes and area size increase.This allows us to evaluate forwarding behavior with in-creasing path length. The ad hoc nodes move in the simu-lated area according to the random waypoint model with amax speed of 20 m/s. We randomly generated 50 move-ment pattern files for each network size (i.e., number ofnodes and area size). One movement run lasts for 200seconds. These 50 patterns were used for all experimentswith default routes and tunneling to ensure that the resultswere comparable. Performance averages were taken overall 50 runs for each network size and forwarding strategy.

7.1.1 CBR Performance

In our first experiment we examine CBR performance be-cause the traffic is predictable and there is no feedbackloop, i.e., no acknowledgments like in TCP. This alsomeans that it does not matter to which gateway the trafficis forwarded, since there is no return traffic. We wouldtherefore not expect dramatic differences between strate-gies. Two CBR sources, sending 512 byte packets at a rate

of 10 per second, is randomly selected among the ad hocnodes. They will start to communicate with a host on thefixed network by randomly choosing one out of two possi-ble. The CBR sources start 5 seconds into the simulationand continue until the end at 200 seconds.

In Figure 8 we see a comparison of aggregated deliv-ery ratios (data packets received divided by data packetstransmitted) for tunnel forwarding and default route for-warding. Although the variance for each point in the di-agram is quite high, the differences between curves aresignificant. The variance is caused by the randomnessin movement patterns. As can be seen from the left fig-ure the delivery ratio decreases with the number of nodes.This is expected since the number of hops to the gatewaywill also increase with the size. Hence will the probabil-ity of connectivity loss also increase with hop length andconsequently the control traffic will increase to handle thelosses. This overall pattern occur in all our measurements.

We note that tunnel forwarding consistently achievesbetter delivery ratio than the default route approach. Ourhypotheses is that the default route solution occasion-ally suffers from the state replication problem (incorrectlyreplicated or missing state on the nodes along a defaultroute). If there is missing state, the AODV protocol willsend a route error message to upstream nodes to invali-date their default routes and force them to be rediscov-ered. This would explain the larger amount of controlmessage overhead of default route forwarding comparedto tunneling in the right graph of Figure 8. It is likely thatmissing state is more frequent when we have more nodesand a larger simulated area, thus on the average longerroutes. The delivery ratio in Figure 8 supports this view,since the gap between tunnel forwarding and default routeforwarding increases with more nodes.

To verify our hypotheses we changed the AODV im-plementation so that it always forwards packets on a con-figured default route. This will work because we onlyhave traffic for the two fixed hosts and it provides a ref-

9

0

0.1

0.2

0.3

0.4

8 10 12 14 16 18 20

TC

P T

hrou

ghpu

t (M

bps)

Number of mobile nodes

TunnelingDefault routes

Default routes mod. 0.95

0.96

0.97

0.98

0.99

1

8 10 12 14 16 18 20

TC

P G

oodp

ut

Number of mobile nodes

TunnelingDefault routes

Default routes mod.

Figure 9: TCP throughput and goodput using 2 TCP sources and increasing path lengths.

erence for how default routes should work without statereplication problems (section 4.2). To mitigate the gate-way tracking problem (section 4.3), the modification alsodrops route replies that try to reconfigure an existing de-fault route. The simulations with this modification (called“default route mod.” in the figures) show that the modifi-cation brings the CBR delivery ratio much closer to tunnelforwarding as we expected.

7.1.2 TCP Performance

For TCP, it is important that the return traffic (i.e., the ac-knowledgments) from the fixed network is sent throughthe same gateway as the forward traffic. Otherwise TCPacknowledgments might get lost in case they are sent to agateway which does not have connectivity with the sourcenode. To support this we modified ns-2’s Mobile IP towork with the AODV implementation. Mobile IP’s agentdiscovery was removed and replaced with AODV’s RREQmechanism just to simplify the set-up. For other partsMobile IP works as specified. Whenever a mobile adhoc node selects or switches gateway it will register withthe agent at that gateway so that return traffic is deliveredthere.

For this experiment, our scenario’s two gateways areassigned as Home Agent (HA) and Foreign Agent (FA),respectively. The scenario configuration otherwise re-mains the same. We created two FTP sources. The aggre-gated throughput of these two is limited by the gatewaycapacity.

In Figure 9, we see that the expected drop in per-formance with the number of nodes, caused by the in-creased probability of losing connections. When com-paring strategies we see that tunnel forwarding constantlyachieves a higher TCP throughput than default route for-warding. The lower throughput for default routes is likelycaused by a change in the default route → gateway map-ping somewhere on the path to a gateway without the

0

1

2

3

4

5

6

7

8

9

10

8 10 12 14 16 18 20

Con

trol

traf

fic /

data

(%

)

Number of mobile nodes

TunnelingDefault routes

Default routes mod.

Figure 10: Normalized control traffic overhead in TCPscenario.

source node being notified (see section 4.3). Conse-quently, the source node never registers at the new gate-way and the acknowledgments might be lost, resulting ina TCP timeout.

The TCP goodput (ratio of TCP packets successfullydelivered to the total number of TCP packets transmit-ted) in the right figure and the control traffic overheadin Figure 10 supports this view. Surprisingly, the good-put of tunnel forwarding is slightly lower than that of de-fault route forwarding. Although the difference is smallenough to fall within the error margin, one explanationis that with less timeouts for tunneling it will send morepackets than default route and thus also retransmit morepackets. This would reduce the goodput of tunnelingwhile it still has a higher throughput than default route. Atthe same time, default route forwarding is not retransmit-ting that much, indicating that the decreased throughputis caused by timeouts. Control traffic is also likely to in-crease, since with tunnel forwarding, AODV spends moretime delivering packets than idle in timeouts. In combi-

10

nation this will give less goodput for tunneling. Interest-ing is that the modified default route forwarding does notshow a similarly strong improvement in this experiment asin the CBR case. This is in line with our assumptions thatdefault route forwarding does not work well with TCP inmultiple gateway scenarios. We will explore this issuefurther in the next section.

7.1.3 The Effect of the Gateway Tracking Problem

In section 3 and 4.3 we described the inability to trackgateways with default routes. With Mobile IP, return traf-fic should be sent to the gateway at which the ad hocsource node is currently registered. If this is a differentgateway from the one that forward traffic is sent over, theTCP acknowledgments might be stuck there if there is noalternative path. This could explain why TCP with de-fault route forwarding seems to spend more time idle intimeouts.

We wanted to verify with an experiment that the lowthroughput is caused by timeouts and whether droppingconflicting route replies solves the problem. We con-structed a scenario where the routing protocol is subjectedto frequent gateway changes. A mobile node (MN) com-municating with a host on the fixed network moves backand forth, forcing change in connectivity between twogateways (a HA and a FA). Connectivity with the gate-ways are always possible through intermediate nodes sothat the hop count to the closest gateway is always three.

MN will initiate an FTP file transfer to the fixed host atthe start of the simulation and lasts 200 seconds. Duringthis time MN will move back and forth twice, with equalconnectivity to both gateways at times 25, 75, 125 and175 seconds. Thus a gateway change should be triggeredaround those times. The other nodes remain stationaryand will forward traffic to and from the gateways.

Figure 11 shows a TCP sequence number trace of asimulation run. In this scenario we expected to see timegaps in between sequence numbers corresponding to han-dover points. Tunnel forwarding reaches the highest se-quence number at 200 seconds. There are expected gapsfor tunneling during gateway changes, but they are notso visible due to random effects on TCP. The unmodifieddefault route forwarding on the other hand has two longperiods where there are no packets sent at all and TCPtimeouts. The first timeout corresponds well to the timeof the first gateway change and the other with the thirdgateway change. It seems as if traffic is only forwardedover one of the gateways (the home agent).

We wanted to find out the exact cause of this behav-ior and therefore examined our log files. We found thefollowing explanation: With unmodified default routes,route replies from both gateways at hand-over installsconflicting state, updating the gateway mapping on in-termediate nodes while not propagating correctly to MN.

MN believes the Internet host can be reached through theHA, when in reality the packets are forwarded through theFA. Since the forwarding to the fixed host still works, MNwill keep and continue refreshing its default route point-ing to the HA. MN incorrectly concludes that it does nothave to register at the FA, causing the acknowledgmentsto be lost at HA. This will continue until MN loses theconnectivity to the FA and regains connectivity with theHA. Thus, TCP will go into a timeout.

0

1000

2000

3000

4000

5000

6000

7000

0 20 40 60 80 100 120 140 160 180 200

Seq

uenc

e N

umbe

r

Time (s)

Sequence Number Trace

Tunneling

Default routes

D. route drop RREP

Figure 11: Sequence number trace showing how defaultroutes have problems with multiple gateways.

Modified default routes drop route replies conflictingwith a configured default route. In the resulting sequencenumber trace we see that this solves the problem as ex-pected. In this isolated case the route reply is the culprit.However, dropping these conflicting route replies seemsto have little effect in the general case as we experiencedfrom the CBR and TCP simulations. Thus we concludethat the state replication problem has a bigger impact onthe performance than the gateway tracking problem.

7.2 Experiments

In this section we present results from our real worldtestbed using AODV with tunneling and Mobile IP. Thepurpose is to provide a proof-of-concept that illustratesthe feasibility of tunnel forwarding in AODV to main-tain continuous gateway connectivity without interruptedcommunication. The experimental setup was described insection 6.2. We performed several experiments using aconstant bit rate Ping (10 pkt/s) with the record route op-tion. Ping measures the round trip time (RTT) and sincethe traffic is bidirectional (request and reply) it is possibleto verify the actual route taken in both directions usingthe record route option. This way we could verify that thepackets are properly re-routed over the new gateway afterregistering with a new foreign agent. Experiments wereperformed with one and two hops to the gateways.

11

0

5

10

15

20

25

30

0 5 10 15 20 25 30 35 40 45 50

RT

T (

ms)

Time (s)

Ping (10 pkts/s)

Reply RTT

Figure 12: Ping RTTs showing one and two hop connec-tivity with the gateways.

Figure 12 shows the RTTs of ping replies received bythe MH during communication with the CH for one ofour experiments (a couple of packets with RTT > 30 mswhere left out of the picture to make it more clear). TheMH initially had one hop connectivity with the first FA.After about 10 seconds the MH switched to a two hoproute to the same FA. This route was kept until around40 seconds where the MH lost connection with the firstFA and at the same time established direct communicationwith the second FA. We could verify from the record routeoption in our logs that the packets were routed correctlyover the two FAs and that the MH were able to registerproperly when the route to the first FA was lost and theroute to the second FA discovered.

8 Conclusions

We have studied and compared approaches to attach adhoc networks to Internet gateways. In regular LANs, adefault route is used for forwarding packets to the Inter-net. Ad hoc networks have different characteristics whichmake the concept default route inefficient and in some sit-uations it will work incorrectly. We have compared thearchitectural aspects of default routes with tunneling togateways. Our conclusion is that addressing gateways ex-plicitly in data packets, by the means of tunneling or sim-ilar techniques, is preferred over setting up generic de-livery paths that increases the shared state in the network.This is in line with classical network design principles likethe end-to-end argument. From our comparison, imple-mentation experience and evaluations we conclude that:

• the default route concept is not easily integratedwith MANETs as it operates incorrectly with multi-ple gateways and suffers from state replication prob-lems,

• tunneling will work with multiple gateways and willprovide fault tolerance and load balancing,

• tunneling is architecturally simple compared to de-fault routes and do not require any changes to the adhoc routing protocols or to intermediate nodes. Onlya simple indirection step in the source node’s routingtable is needed,

• the performance of tunneling is better or at leastcomparable to default routes in our simulation sce-narios,

• tunnels have double destination IP addresses whichmay create a substantial overhead for very smallpackets which is not the case for default routes.

We believe that this presents a strong argument forsource node control over gateway selection as enabled bytunneling or source routing approaches. As a proof-of-concept, we have implemented the tunneling approach ina real experimental testbed system and demonstrated theviability of tunneling together with AODV and Mobile IPto provide continuous and uninterrupted Internet connec-tivity in multi-hop ad hoc networks. This solution alsointegrates well with the on-demand behavior of AODV.

Items for future work include how to handle DNS look-up for source and gateway nodes. There are severalways and algorithms to solve the locality problem at thegateway and they should be evaluated. Better interac-tion between Mobile IP and the routing protocols can beachieved and likewise improvements in hand-over perfor-mance. The possibility to use multi-homing for soft hand-over would also be interesting to explore further. Thereexists techniques for compressing headers that may be at-tractive to explore whether they work for this ad hoc en-vironment.

References

[1] The AODV-UU implementation. http://www.docs.uu.se/scanet/aodv.

[2] Dynamics Mobile IP. http://dynamics.sourceforge.net.

[3] The official IETF MANET working group web-page. http://www.ietf.org/html.charters/manet-charter.html.

[4] E. Belding-Royer, Y. Sun, and C. Perkins. Globalconnectivity for IPv4 mobile ad hoc networks,November 2001. IETF Internet Draft, draft-royer-manet-globalv4-00.txt, (work in progress).

[5] J. Broch, D. A. Maltz, and D. B. Johnson. Support-ing hierarchy and heterogeneous interfaces in multi-hop wireless ad hoc networks. In Proceedings of theWorkshop on Mobile Computing. IEEE, 1999.

12

[6] H.-W. Cha, J.-S. Park, and H.-J. Kim. Sup-port of internet connectivity for AODV, February2004. IETF Internet Draft, draft-cha-manet-AODV-internet-00.txt.

[7] P. Engelstad and G. Egeland. NAT-based Internetconnectivity for on-demand ad hoc networks. InWONS 2004, pages 344–358, 2004.

[8] P. Engelstad, A. Tønnesen, A. Hafslund, and G. Ege-land. Internet connectivity for multi-homed proac-tive ad hoc networks. In The IEEE InternationalConference on Communications (ICC) 2004, June2004.

[9] C. Jelger, T. Noel, and A. Frey. Gateway and addressautoconfiguration for ipv6 adhoc networks, Octo-ber 2003. IETF Internet Draft, draft-jelger-manet-gateway-autoconf-v6-01.txt.

[10] D. B. Johnson, D. A. Maltz, and Y. Hu. The dynamicsource routing protocol for mobile ad hoc networks(DSR), April 2003. IETF Internet Draft, draft-ietf-manet-dsr-09.txt, (work in progress).

[11] U. Jonsson, F. Alriksson, T. Larsson, P. Johansson,and G. Q. Maguire Jr. MIPMANET - Mobile IP forMobile Ad hoc Networks. In 1st ACM internationalsymposium on Mobile ad hoc networking and com-puting (Mobihoc’00), 2000.

[12] H. Lundgren, D. Lundberg, J. Nielsen, E. Nord-strom, and C. Tschudin. A large-scale testbed for re-producible ad hoc protocol evaluations. In Proceed-ings of IEEE Wireless Communications and Net-working Conference 2002 (WCNC’02), March 2002.

[13] A. Nilsson, C. E. Perkins, A. J. Touminen,R. Wakikawa, and J. T. Malinen. AODV and IPv6Internet access for ad hoc networks. Mobile Com-puter and Communications Review, 6(3):102–103.

[14] E. Nordstrom, P. Gunningberg, and C. Tschudin.Poster: Comparison of forwarding strategies in in-ternet connected manets. In MobiHoc, May 2004.

[15] C. Perkins, E. Belding-Royer, and S. Das. Ad hocon-demand distance vector (AODV) routing, July2003. IETF Internet RFC 3561.

[16] P. Ratanchandani and R. Kravets. A hybrid approachto internet connectivity for mobile ad hoc networks.In IEEE WCNC, 2003.

[17] Y. Sun, E. M. Belding-Royer, and C. E. Perkins.Internet connectivity for ad hoc mobile networks.International Journal of Wireless Information Net-works, 9(2):75–88, April 2002.

[18] C. Tschudin. Lightweight Underlay Network Adhoc Routing (LUNAR) Protocol. IETF Inter-net draft, draft-tschudin-manet-lunar-00.txt, March2004.

[19] Y.-C. Tseng, C.-C. Shen, and W.-T. Chen. Integrat-ing mobile IP with ad hoc networks. Computer,(5):48–55, 2003.

[20] N. H. Vaidya. Weak duplicate address detection inmobile ad hoc networks. In Proceedings of MOBI-HOC’02, June 2002.

[21] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson,and A. Tuominen. Global connectivity for IPv6 mo-bile ad hoc networks, (work in progress), October2003. IETF Internet Draft, draft-wakikawa-manet-globalv6-03.txt.

[22] C. Ahlund and A. Zaslavsky. Software solutionsto Internet connectivity in mobile ad hoc networks.In 4th International Conference on Product FocusedSoftware Process Improvement (PROFES), 2002.

13