A Protocol Independent Internet Gateway for Ad ... - Semantic Scholar

2 downloads 442 Views 298KB Size Report
provides Internet access by acting as both a Service ..... IP services field that denotes that this node offers ... Services field - The services that are offered by the.
A Protocol Independent Internet Gateway for Ad Hoc Wireless Networks A. Striegel, R. Ramanujan, J. Bonney Architecture Technology Corporation Minneapolis, MN USA [email protected] [email protected] [email protected]

Abstract

of AWLANs include wireless networks for disaster recovery operations and law enforcement, wireless home and office area networks, and data collection networks for factory floors. Unlike commercial cellular networks, AWLANs do not require dedicated base stations. All nodes communicate on a peer-to-peer basis for forwarding packets through the network, thereby eliminating single points of failure and making AWLANs more robust than cellular networks. Thus, the mobile nodes in an AWLAN, in addition to executing user applications, may also have to perform packet routing functions. We use the term nomadic router to refer to the function within the mobile computers that performs packet routing in AWLANs. In order to be useful in a wide range of tactical environments, the routing protocol implemented by the nomadic router must have the capabilities that are listed and described below.

An autonomous wireless local area network (AWLAN) is a collection of wireless computers that can be rapidly deployed as an ad hoc network without the aid of any established infrastructure or centralized administration. However, existing routing protocols for such networks neither scale nor function on the Internet. Therefore, a solution is required that provides a gateway between the ad hoc network and the Internet. In this paper, we propose a protocol-independent Internet gateway for ad hoc networks, the Cluster Gateway (CG). The proposed Cluster Gateway (CG) provides Internet access by acting as both a Service Access Point and a Mobile IP Foreign Agent for ad hoc networks. In this paper, we describe the requirements for supporting the CG in any ad hoc routing protocol, the messages sent in order to provide CG support, and several optional enhancements for the CG. Finally, we briefly describe an implementation of the CG over an existing ad hoc routing protocol.

• Self healing routes: In an AWLAN, an existing route between two nodes may fail when any of the nodes on the path between these end nodes fails or moves out of the wireless transmission range of the next or previous hop along the route. Alternatively, the node may not be able to communicate with the next or previous hop for some other reason such as interference or terrain masking. When route failures happen, the routing protocol must be able to dynamically adapt (or repair) the routes by finding an alternate route if one exists.

1. Introduction An autonomous wireless local area network (AWLAN) is a collection of wireless computers (e.g., wearables) that can be rapidly deployed as a multihop packet radio network (or ad hoc network) without the aid of any established infrastructure or centralized administration and without any user-initiated configuration actions. Thus, such networks can be deployed and operated entirely by the end users without relying on any service provider. AWLANs are ideal for establishing an instant tactical communication network needed by emerging military applications such as situational awareness systems for maneuvering warfighters and distributed tactical robots. Civilian applications

• Support for asymmetric network environments: In a tactical network, it is not uncommon to encounter asymmetric (i.e., unidirectional) wireless links. For instance, a node A may be able to receive transmissions from a node B but the reverse may not be true. Such asymmetry in the wireless communication may be induced by several factors such as varying propagation characteristics of the transmission signals or differences 1

in the transmission power of the nodes (e.g., node B in the above example may use high-power transmissions that reach A but the latter relies on lowpower transmissions that cannot reach B). It is therefore necessary for a routing protocol in a tactical AWLAN to operate correctly and generate valid routes in a wireless network with asymmetric (unidirectional) links.

for AWLAN environments is the residual overhead of the protocol associated with routing data packets. As the length of the route increases, the size of the data packet also becomes larger. When compared to hop-byhop routing, the source routing approach used by DSR incurs larger steady state routing overhead in terms of the CPU cycles used and the power consumed by a node to forward a packet. Also, the source route information carried within the data packets consumes additional network bandwidth when compared to packets routed using hop-by-hop schemes. The WINGS effort under DARPA’s GloMo initiative has developed a wireless IP router (i.e., WINGS) that uses an ad hoc routing protocol called the Wireless Internet Routing Protocol (WIRP) from UCSC [5, 6]. WIRP does not support policy routing or operation in networks with unidirectional links. Furthermore, WINGS currently does not support mobility of wireless nodes from one ad hoc cluster to another. SPARROW, a follow-on effort to WINGS, extends the latter’s capabilities in terms of security and QoS support. However, the QoS aware SPARROW protocols are targeted for MAC technologies that support channel reservations. The Source Initiated Routing Protocol (SARA) [7] addresses many of the weaknesses of the proposed MANET protocols. SARA was initially proposed for adaptive QoS of multimedia streams in best-effort wireless environments such as 802.11. Unlike the previously mentioned protocols, SARA meets the necessary requirements as mentioned earlier for an AWLAN routing protocol.

• “Lightweight” implementation: The mobile computing devices in a tactical AWLAN are generally resource constrained in terms of processing power and battery life. Such devices must be built to stringent size, weight, and power specifications. Therefore, the routing protocol must permit a “lightweight” implementation within such nodes that conserves usage of memory, processing, and power at the nodes. • Policy routing: Traditionally, routing algorithms are designed to generate routes that minimize the number of hops taken by messages to reach a destination. In a tactical network, applications may desire routes that optimize metrics such as the amount of power consumed in transporting a packet, the throughput of the route, or the signal stability of the links in the route. Different applications running at a node may use different route metrics. Hence, the routing algorithm in a tactical AWLAN must facilitate the generation of routes optimized to application specific metrics.

1.1. Ad Hoc Routing Protocols

1.2. Motivation

The Mobile and Ad Hoc Networking (MANET) working group of the IETF is currently investigating a number of routing algorithms for ad hoc wireless networks. The candidate protocols include the Ad Hoc On-Demand Distance Vector (AODV) protocol [1], the Temporally Ordered Routing Algorithm (TORA) [2], the Zone Routing Protocol (ZRP) [3], and the Dynamic Source Routing (DSR) protocol [4]. AODV, TORA, and ZRP are all designed for networks with bidirectional links and may produce invalid routes in networks with unidirectional links. Furthermore, they do not support application directed policy routing. The DSR protocol uses source routing where every data packet to be routed carries in its header the complete ordered list of nodes that the packet must traverse from source to destination. In contrast to other MANET protocols, DSR is designed to operate correctly in networks with unidirectional links. The protocol as defined currently does not allow application directed policy routing. However, it can be extended to support this capability. The major drawback of DSR

Although the routing protocols make some semblance of order among the ad hoc network nodes, these routing protocols are not necessarily scalable to the global Internet. Thus, in order to provide Internet access to ad hoc networks, a solution is required that routes traffic between the Internet and the AWLAN. However, a simple bridge will not suffice as the two sides of the respective bridge operate on drastically different premises. Whereas the Internet operates in a hierarchical fashion, location is not necessarily predetermined in the ad hoc network. Therefore, in order for a device on the ad hoc network to communicate with the Internet, a gateway should exist that maps addresses from one network to the other network. This device is responsible for understanding both the hierarchical routing nature of the Internet as well as the particular ad hoc routing protocol of the AWLAN. Solutions for mobile Internet access as Mobile IP [8] were designed for single hop wireless networks. In [9], 2

Mobile IP was extended to ad hoc networks through the use of RIP (Routing Information Protocol [10]). However, although the solution does provide Internet access for ad hoc networks, the solution does not meet the goals for an AWLAN network as specified earlier. In addition, this approach is highly dependent upon the RIP protocol and thus not compatible with other ad hoc routing protocols. Although a significant body of research has been done on ad hoc routing, these protocols do not scale well to the Internet. However, the extension of existing Internet protocols (RIP) or one-hop solutions such as Mobile IP do not necessarily take into account the unique aspects of the wireless environment. Therefore, an ideal solution would provide Internet access to ad hoc networking while taking into account the unique aspects that wireless and ad hoc networking may entail. This introduces the motivation for our paper. In our paper, we propose a routing protocol independent Internet gateway model for ad hoc wireless networks, the Cluster Gateway (CG) model. The CG model provides a framework for development which is independent of the underlying ad hoc routing protocol while providing a uniform set of services to nodes on the ad hoc network. The CG model works together with existing ad hoc routing protocols (SARA, etc.) as well as Mobile IP to provide seamless Internet access for mobile nodes. Thus, the CG model is able to take advantage of existing research on ad hoc networking protocols while being fully aware of the unique aspects of wireless ad hoc networking. Although several changes may be required for most existing routing protocols, we believe the changes are justified by the inclusion of Mobile IP support and the standard set of services offered by the CG model. In Section 2, we outline our basic Cluster Gateway model. In Section 3, we outline the interactions between nodes on the wireless network and the CG. Next, in Section 4, we outline several enhancements to the model that can be applied at both the application and routing level. Following this, in Section 5, we discuss several concerns regarding handoffs, security, and IPv6. Then, in Section 6, we outline an implementation of the CG over an existing ad hoc routing protocol. Finally, in Section 7, we make some concluding remarks.

SAP

Home Agent Internet Interface

Internet

CG Application

Mobile IP

Host

Applications

CG Translation (optional)

TCP,UDP/IP CG

Routing Protocol

Routing Protocol

AWLAN Interface

CG Node

CG

AWLAN User 2

AWLAN Interface User 1

non-CG Node

Figure 1. Internet Access via the Cluster Gateway

the CG application module is responsible for promiscuously monitoring, responding (ARP requests), and forwarding the appropriate packets to the AWLAN. These packets may be bound to a group of addresses (care-of, co-located, or NAT) which correlate to specific nodes in the AWLAN. For packets from the AWLAN side of the CG node, the CG application module is responsible for monitoring a specific type of packets as outlined by the services offered by the CG. These packets may include registration messages, advertisement solicitations, location requests, and encapsulated data packets. The actual translation of the routing protocol messages to CG messages does not take place in the application. Rather, the translation takes place in the CG node support module. Thus, the CG application module and the services offered by the CG are kept independent of the routing protocol. The other module for the CG model is the node support module. The node support module is responsible for connecting the node to the CG application. Each node in the AWLAN (including the CG node) that desires Internet access must run a CG node support module. The CG node support module is responsible for registration with the CG node, locational queries1 , and data forwarding to the CG (for nodes external to the AWLAN). The CG node support module may be implemented in a variety of fashions. Depending upon the underlying routing protocol, the behavior of nodes in the network (location of destination nodes), and the type of services required, the CG support module may be built into the actual routing protocol module or constructed on top of the routing protocol module (independent).

2. Model The Cluster Gateway model consists of two modules, the application module and node support module. The CG application module is responsible for routing packets between the AWLAN and the Internet. For packets from the Internet side (see Figure 1) of the CG node,

1 The process of discovering the location of a node in relation to the AWLAN, i.e. internal or external to the AWLAN.

3

For the dependent case, a translation is done at the CG node between the routing protocol messages and CG messages. This translation reduces the CG messages across the AWLAN and reduces the requirements of non-CG nodes for CG support. In contrast, in the independent support module scheme, the CG support module is independent, thus allowing CG messages to flow across the AWLAN like normal data messages. This approach requires minimal changes to the routing protocol but requires a separate CG module at each node which is location-aware since no translation occurs at the CG node in the network. Since an AWLAN can be dynamic, a given AWLAN may or may not posses a route to a CG. All non-CG nodes are expected to try to seek out potential CGs. Once a CG is detected, all nodes in the AWLAN should attempt to register with the CG. Registration allows the CG to appropriately allocate resources and to perform location resolution in a routing protocol independent manner.

For simple nodes or nodes that desire basic Internet access (outgoing traffic only), it may not be necessary for the node to implement full Mobile IP support. Example users of this service would be for a mobile user whose company does not possess a Home Agent (HA) or a user that does not require the authentication features of Mobile IP. The second reason for using the SAP service of the Cluster Gateway is to eliminate the triangle routing aspect of Mobile IP. Although it is possible under Mobile IP for nodes to eliminate the triangle routing through bindings between the host and the Foreign Agent, such optimization are currently unavailable for the majority of Internet hosts. However, it is our belief that such optimizations will probably not be deployed on a large scale until IPv6, due to the inclusion of authentication requirement in IPv6. Thus, by selecting the SAP service, the traffic or connection for the AWLAN node is routed directly between the host and the node due to the NAT done by the CG.

2.1. CG Services

2.1.2

Under the CG model, a node may select two broad classes of service, a simple Service Access Point (SAP) service or Mobile IP [8] service. The Service Access Point service allows an AWLAN node to use the CG as a simple Internet access point whereby packets are intelligently translated and forwarded to the Internet. Conversely, in the Mobile IP service mode, Internet access is provided through Mobile IP support by the CG which acts as a Foreign Agent (FA). The majority of the multicast requirements for underlying ad hoc routing protocols are included in order to provide Mobile IP support. Although the CG model is closely interwoven with Mobile IP for compatibility and efficiency, Mobile IP is not required under the CG model if only SAP service is desired.

For companies or institutions that desire a higher level of security, the Mobile IP service is offered to nodes with Mobile IP clients. These node may desire additional authentication, mobile access to company resources, or the ability for remote accessibility from the Internet. In the Mobile IP service mode, the CG node acts as a Foreign Agent (FA) for the node on the AWLAN. The FA component of the CG may be independent of the CG application itself. Thus, the registration with the CG is entirely independent from the Mobile IP registration. Although Mobile IP was originally intended for a single hop environment, it can be extended to ad hoc networks by the support for several key components of Mobile IP. These components are discussed in the next section along with the messages associated with the CG model.

2.1.1

Service Access Point (SAP) Service

Mobile IP Service

3. CG Protocol Messages

The Service Access Point (SAP) service offered by the CG is a lightweight service for nodes that desire simple Internet access. This service is offered for nodes that desire one of the following features:

In order for an AWLAN node to communicate through the CG to the Internet, the basic requirements for the interaction between the AWLAN node and the CG are as follows:

• The node does not want to implement Mobile IP. • The node desires to eliminate the triangle routing of Mobile IP.

• Advertisement: A CG must be able to advertise to the entire AWLAN regarding its presence and availability. Consequently, a node should also be able to decipher and recognize the availability of the CG. • Registration: In order to use any services of the CG, the node must register with the CG to re-

For this service, the CG will perform a Network Address Translation (NAT) for all outgoing packets from the node in order to assure proper routing from the global Internet. Thus, for this service, all connections must be initiated by nodes inside the AWLAN. 4

Address 224.0.0.1 224.0.0.2 255.255.255.255

Description All-systems b-cast All-routers b-dcast Limited b-cast

Address Type CG Advertise CG Solicit CG Solicit

Table 1. AWLAN-wide broadcasts

serve the necessary resources the node requires (IP addresses, buffer space, etc.) • Node Location: Since a node may now be found outside of the AWLAN, a node should be able query the CG to determine if the node can be found externally or internally. • Data: In order to communicate with a node that is found externally on the Internet, the data from a node must be appropriately routed to the CG. This may be done in a location-aware or locationunaware fashion.

3.1. Routing Protocol Requirements

CG for its appropriate ad hoc network. Once a node has recognized that a CG is available, a node should register with CG, regardless of whether its requires any services from the CG or not. • Support for Location Requests: In order to support the notion of an AWLAN and an Internet gateway, the routing protocol may support the notion of internal and external nodes. This may be done in two fashions, either location-aware or locationunaware. In the location-aware method, each individual node keeps track of whether a node can be found internally or externally to the network. Thus, each node is responsible for querying the CG for node locations as well as appropriately routing data to the CG. In the location-unaware method, a module at the CG is responsible for translating (see Figure 1) messages between the routing protocol and the CG application. Under this method, AWLAN nodes are unaware of node location (internal/external) and the CG appears only as another hop in the path to the destination node.

3.2. CG Message Types In order to support the requirements outlined above as well as the necessary service requirements, the underlying ad hoc routing protocol for the AWLAN must support several key features. These features include:

In order to describe the messages that are passed during the lifetime of a session, the following sequence of events detail the basic lifecycle of a node session with a CG:

• Support for AWLAN-wide broadcasts: The underlying routing protocol must support a scheme whereby the CG is able to broadcast its advertisement information to the entire AWLAN. Although it is possible to do CG advertisements via node-tonode propagation, node-to-node propagation will not function in a traditional Mobile IP environment without special modifications. Table 1 lists the multicast addresses that must be supported by the routing protocol. These broadcasts are of a fairly infrequent periodic nature (i.e. once per 2 minutes).

1. A node initially learns of a CG through either a CG Advertisement or a routing-protocol specific message. 2. A node attempts to register with the CG for the services it requires. 3. The node receives a message (CG Registration Response) regarding its registration with the CG. If the response is successful, the node is considered registered for the given registration lifetime. Otherwise, the node may try again either immediately or after a given time period. 4. If the node wishes to send a message to a destination, the node must determine how to get to the destination. The node may either contact the CG (location-aware) via an explicit message (CG Route Request), or the node may receive the information via special support within the routing protocol (location-unaware). 5. The node receives a response either from the CG or from the routing protocol itself. 6. The node begins data transmission to the host which is routed through the CG to the Internet. The message may be routed via encapsulation (location-aware) or by the routing protocol (location-unaware).

• Support a special CG node: In order to maintain the protocol-independence of the CG protocol, a special node exist that closes the gap between the routing protocol and the CG. This special node is responsible for recognizing CG messages at the routing protocol level and appropriately passing them to the CG. Depending on the location-awareness of the nodes, this requirement may be entirely met through the CG application. Nodes on the AWLAN are responsible for recognizing this node as the CG via the CG Advertisement message. • Support for CG registration: Each node on the ad hoc network is responsible for recognizing the 5

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

type

length

registration lifetime

Type

sequence number R B H F MG V

reserved

Length

Reserved

Requested Services

Error Code

Requested Lifetime

C

zero or more care-of addresses CG IP Max Registration

MN F R I m

Figure 3. CG Registration Message

Figure 2. CG Advertisement Message

CG Solicitation: The CG Solicitation message is the same as the Mobile IP Agent Solicitation message. Upon receiving a CG Solicitation message, the CG may do one of the two following options. If the CG has only a few or limited number of nodes registered, the CG may respond with an AWLAN-wide broadcast since the effect of an AWLAN-wide broadcast would have a minimal impact on the AWLAN. The other option is for the CG to reply with a unicast response to the node. However, for CG Solicitation messages, there is one small caveat. Whereas under the initial Mobile IP architecture, each node was only one hop away, the ad hoc network allows nodes to be more than one hop away. Thus, a CG Solicitation (Mobile IP Agent Solicitation) to the all-routers address (224.0.0.2) or allsystems address (255.255.255.255) will be broadcast across the entire network. For AWLANs with a small number of nodes, this may not present a problem. However, as the number of nodes in the AWLAN increases, this technique does not scale well due to the increase in AWLAN-wide broadcasts. This problem can be solved by at least two methods. The first method is to restrict CG Solicitation messages to a minimum such that a node may only learn about a CG through a CG Advertisement message. This method may be enhanced by offering a routing protocol level enhancement to improve CG detection time (See Section 4.1). The other method is to restrict AWLAN-wide broadcasts to a certain timeframe, i.e. only one broadcast for a CG Solicitation per X seconds. If a non-CG node detects a CG Solicitation message, the non-CG node resets its CG Solicitation timer to try again X seconds later. Thus, an AWLAN with N nodes will only have N total CG Solicitation messages ever X seconds.

7. A node renews its registration information with the CG or lets the registration information expire. 3.2.1

Rsvd

Services

CG Advertisement

The CG Advertisement component consists of two messages, namely, the actual advertisement from the CG itself (CG Advertisement) and a request for an advertisement from a node on the network (CG Solicitation). For each of these messages, the actual makeup of these messages is tied closely to Mobile IP in order to eliminate redundant messages on the AWLAN. Essentially, the CG information is added on to the Mobile IP information via a CG extension header. CG Advertisement: The CG Advertisement message originates from the CG node on the network. This message is the same message as the Agent Advertisement message in Mobile IP with an additional CG extension (see Figure 2). This message is broadcast to all nodes on the AWLAN via the all-nodes multicast address (224.0.0.1). Since this message is simply an extension of the Mobile IP Agent Advertisement, the message may simply be passed in its entirety to the Mobile IP module for processing after the routing protocol has processed the message. The reason why a routing protocol must support an AWLAN-wide broadcast of this message is to allow CG Advertisement messages to propagate across the entire AWLAN just as Mobile IP Agent Advertisements propagate across the entire one hop network. The CG Advertisement contains the following fields in addition to the Mobile IP Agent Advertisement: • C bit - The C bit is a special bit in the Mobile IP services field that denotes that this node offers CG support. • Services field - The services that are offered by the CG (see Section 3.2.2).

3.2.2

CG Registration

Once a node has successfully detected a CG, the node should attempt to register with the CG. Figure 3 details the contents of the CG Registration which has the

• Maximum registration time - The maximum registration time in seconds that a node may register for. 6

Field Length Type Reserved Error Code Services Lifetime

Description Length of the reg. info 0 (Registration Request) 1 (Registration Response) All zeros Zeros (Request) Specified Value (Response) See Table 3 Requested reg. lifetime (seconds)

Mobile IP. CG Registration Response: After processing the registration request from a node, the CG will send a unicast response to the node detailing the status of the registration. The registration response lists a code that is indicative of either success or the cause of the registration failure. If the registration to the CG fails, the node should take an appropriate course of action based on the registration response. This response will be dependent upon the service requirements of the node and the nature of the registration failure. In addition to replaying the initial registration message, the response message will also contain the lifetime of the registration. This value is defined as the minimum of the granted CG registration time and the requested CG registration time. CG Registration Renewal: Since the network is assumed to be dynamically changing, the underlying registration subsystem for the CG is based on a soft state system such that each registration is only valid for a given lifetime. Therefore, each node is responsible for renewing its registration before its registration expires in order to avoid service disruption. The CG Registration Renewal message is identical to the CG Registration Request message with the only difference being that the node is already registered at the CG.

Table 2. CG Registration Message Fields Field M R N E F ME

Description Mobile IP Renew Registration NAT service Use IP in IP encapsulation Fast Circuit Location Buffered location search Use minimal encapsulation

Table 3. CG Service Field Bits same format for both the CG Registration Request and CG Registration Response messages. The fields in the message are defined in Table 2 and Table 3. CG Registration Request: Based on the information received from a CG Advertisement message or other appropriate method (see Section 4), a node will attempt to register for an appropriate level of service. In addition to specifying its service requirements, a node must also specify the length of time it desires for the registration. This message is a simple unicast message between the node and the CG. Since only a relatively few messages are exchanged between the node and the CG (Registration, Location Request), all communication between the node and CG should use the UDP protocol with port 435 (Mobile IP + 1). Upon receiving a CG Registration Request, the CG will determine if it has the necessary resources to support the registration request. For Mobile IP connections, no resources are required as the CG is simply acting as a Foreign Agent (FA). For SAP connections, the CG must determine if it has an appropriate amount of addresses remaining to support the new node. If the node requires only internal AWLAN communication, the node may register with the services field set to zero. Note that when using Mobile IP, a node will actually have two registrations, one registration at the CG level and one registration at the Mobile IP level. This is due to the fact that not all nodes may require or implement

3.2.3

CG Location Request

Under a typical ad hoc routing protocol, a node may either be found within the AWLAN or the node is not reachable by the AWLAN. With the introduction of the CG, AWLAN members may now reach nodes on the Internet that are external to the AWLAN. Thus, the AWLAN members can reach two types of nodes, nodes internal to the AWLAN and nodes external to the AWLAN. As outlined earlier, the CG is responsible for providing a service for making this determination. Under this service, the node or routing protocol (via translation) may query the CG regarding the location of a node via the CG Location Request message. The CG will then determine (using its current knowledge) whether the node can be found internally within the AWLAN or externally on the Internet. This is not an easy task as the IP address provides little insight beyond being a unique identifier. Thus, whereas this is a difficult task at a node level, the CG provides a central location service for all nodes in the AWLAN. An simple scheme to support location determination is as follows: 1. Is the node in the registration list? If yes, then the node can be found internally. 7

Field Type Length R Q

Description (2) Location Request Length of initial header 1 if routing state extension is present 1 if QoS extension is present

Field Reserved Target IP Source IP Extra Info

Result

0-Internal,1-External 2-Unknown

QoS Extension

Description All zeros IP address in question Source of request Length of routing extension, followed by routing extension Length of QoS extension, followed by QoS extension

Table 4. CG Location Request Fields

2. If the node is not found internally, attempt to ping the destination IP address. 3. If a successful response is received, the node can be found externally. 4. If a successful response is not received (timeout), the node may be found either externally or internally. The problem with sending an ICMP Echo message [13] is that not all nodes on the Internet may necessarily respond to the ‘ping’. Thus, the actual location of the node cannot be determined unless alternative methods are employed. The actual implementation of the CG Location service may be done in several different fashions. The translation approach is used in the location-unaware method whereas the remaining four methods are used in the location-aware method. • Translation Approach (Local) - The routing protocol module at the CG node will recognize and translate routing queries by the routing protocol and pass those routing queries to the CG application module. The routing protocol module will also repackage the route response as a routing protocol response. This requires no change to the routing protocol beyond the translation component as the CG application simply looks like another hop on the ad hoc network. • Parallel Query (CG + Local) - When a route request is initiated on the network, a CG Location Query is sent in parallel with the actual routing query of the routing protocol. Under this case, the ping from the CG and the routing protocol scheme are allowed to operate in parallel, thus reducing the route determination time. • Sequential (CG,Local) - A route request is sent first to the CG and upon an unsuccessful CG Location Response, a routing request is sent locally on the AWLAN. This method reduces the amount of messages from the Parallel Query method and is ideally suited for networks where the majority of communications are directed towards the Internet.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type

Length

RQ

Reserved

Target IP Address Source IP Address (Request) Routing Info Length

Routing Info Rounting Info

QoS Length

QoS Extension QoS Extension

Figure 4. CG Location Request

• Sequential (Local,CG) - Conversely, a route request may be sent first on the local AWLAN and upon an unsuccessful local routing request, the route request is sent to the CG. This method again costs less than the Parallel Query method and is ideally suited for networks where the majority of communications are directed on the AWLAN. • Buffered (CG) - The buffered (fast circuit) approach relies entirely on the CG for all location operations. This method employs a technique similar to fast circuit switching in high-speed networking whereby the routing request is immediately followed by the data. A node sends the CG Location Request message and forwards all data to the CG. The CG is responsible for buffering the data until a suitable route is found. Thus, in this scheme, an additional field is required in the CG Registration Request message due to the additional resources required by the CG application for buffering. CG Location Request: If a node needs to determine whether destination node can be found internally or externally to the Internet, the node may send a CG Location Request message to the CG in a unicast fashion (UDP, Port=435). Alternatively, the node may depend on the CG support module to translate a routing request for the CG application module as well. 8

The contents of the CG Location Request message are shown in Figure 4. Table 4 describes the contents of the CG Location Request message. In addition to the required fields, the CG Location Request message contains optional extensions for storing routing state information and QoS information. The Routing Info field is included to allow the underlying routing protocol to store state information in the message to the CG application. The CG should preserve this information and return this information in the CG Location Response message. The actual contents of the Routing Info field are left to the designer of the CG support module for each routing protocol. The other variable length field, the QoS Extension field, follows the same format as the Routing Info field whereby a length is given followed by the actual information. CG Location Response: The CG Location Response message is identical to the CG Location Request message with the result field appropriately populated by the CG. Based on this message, the routing protocol or node can take an appropriate course of action in regards to the location of the destination node. 3.2.4

the communication. Second, it may be desirable for nodes to share routing state information between them. If the nodes in the AWLAN are communicating with a group of similar external sites, the savings in location request messages may outweigh the scalability issues for each node maintaining its own routing state information.

4. Routing Protocol Enhancements 4.1. Enhanced CG Detection In order to accelerate the detection of a CG, the routing protocol may include additional enhancements to relay CG information to nodes that were not in range during a CG Advertisement message. This information could be relayed during periodic or aperiodic state information exchanges between nodes.

4.2. Adaptation to Unicast Solicitations Although a CG Solicitation message must always be propagated to a CG since a CG may only initiate a CG Advertisement, a node that is aware of a CG may change a CG Solicitation message from an AWLANwide broadcast to a unicast message directed towards a CG. Thus, a node may use its knowledge of a CG to prevent the unnecessary propagation of an AWLANwide broadcast.

CG Data Message

The method for sending data messages from a node to the Internet will vary depending on the location awareness of the node. However, although the method for transporting data messages across the AWLAN may vary, the service offered by the CG remains constant. For any packets that are destined for nodes outside the AWLAN, such packets must be tunnelled to the CG via either IP in IP Encapsulation [11] or Minimal Encapsulation [12] . The location-awareness of the AWLAN is responsible for determining the length of the tunnel. For location-aware nodes, the packets are tunnelled from the node to the CG. The tunnelling requires additional communication overhead at the savings of routing state information. The savings in routing state information arises from the fact that the CG and the source node are the only two nodes that need to be aware of the location of the destination. This method is ideal for networks which communicate with a large number of external sites that are fairly disjoint between individual nodes on the network. However, the location-unaware method does have its advantages as well. First, the length of the tunnel involved is reduced to a zero-hop tunnel. The tunnel under the location-unaware method exists only between the translation module and the CG application. Thus, the tunnel only runs between the routing protocol and the CG application. This results in a communications bandwidth savings along the entire AWLAN path of

4.3. Instant Location One of the key services offered by the CG is the location query service which determines if a node is internal or external to the AWLAN. A potential optimization for this service is to require that all nodes be registered with the CG. Because of this registration requirement, any node which is not registered with the CG can therefore be determined to not exist on the local network. As a result, the CG may instantly respond to CG Location Request according only to its registration list rather than attempting to ping the potentially external node.

5. Other Concerns 5.1. Handoffs The main problem that is unique to the AWLAN is determining the validity of potential CG nodes on the AWLAN. In traditional Mobile IP, only one link exists between the Foreign Agent and the Mobile Node. In 9

7. Conclusion

contrast, an AWLAN may posses many dynamic links between the node and the CG. Thus, a node may move in and out of range of the CG due to actions not only of the node itself, but of nodes that make up links connecting the node to the CG. However, since this topic is a topic almost unto itself, it is left for future research.

In this paper, we proposed a routing protocolindependent gateway for Internet access for ad hoc networks. Our Cluster Gateway (CG) model provides Internet access via either Service Access Point service or Mobile IP service. Many of the CG messages co-exist with Mobile IP messages, thus providing efficient CG and Mobile IP service to nodes. For the CG model, we outlined the necessary requirements and messages for any ad hoc routing protocol to support the CG model as well as various optimizations that can occur on the routing protocol level. Finally, we briefly described an implementation of our Cluster Gateway for both the Windows NT and Linux platforms.

5.2. Security In order to maintain the routing protocol independence of the CG protocol, it is our intention that the authentication and security should exist in the ad hoc routing protocol. As a result, the current CG protocol does not include any provisions for authentication or security. Thus, the CG protocol assumes a certain level of trust between the nodes on the AWLAN and the CG. The SAP service of the CG complicates the security of the CG model as well. The SAP service mode does not interact well with IPSec [14, 15] due to the changing of the IP source address field as well as possible other packet changes.

References [1] C. Perkins and E. Royer, “Ad hoc On-Demand Distance Vector Routing,” Proc. of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, pp. 90-100, February 1999. [2] V. Park and M. S. Corson, “A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks,” Proceedings of IEEE INFOCOM, 1997. [3] Z.J. Haas and M. Pearlman, “A New Routing Protocol for the Reconfigurable Wireless Networks”, ICUPC’97, 1997.

6. Implementation

[4] J. Broch, D. Maltz, and D. Johnson, “Supporting Hierarchy and Heterogeneous Interfaces in Multi-Hop Wireless Ad Hoc Networks,” Proc. I-SPAN, June 1999.

The Cluster Gateway has been successfully implemented on top of SARA (Source-initiated Ad hoc Routing Algorithm) [7] on both the Windows NT and Linux platforms. The testbed consisted of four machines for the AWLAN, three notebook computers and one desktop computer (CG). All computers were equipped with a Lucent WaveLAN card operating in ad hoc mode at 11 Mbps. The notebooks were a mixture of Linux/Windows NT configurations and the desktop was a purely Windows NT machine. The actual implementation of the CG can be broken down into two major components, the CG application and the ad hoc routing protocol support. The CG application was developed for the Windows NT platform along with integrated Mobile IP Foreign Agent support. The application receives information from SARA via translation and tunnelling from the device driver. Hence, all translation from SARA is done at the device driver level, thus leaving the CG application independent of the actual routing protocol. The SARA driver was modified for both the Linux and Windows platforms to provide CG support. In addition to the required CG support, the SARA device driver also incorporated several of the optimizations discussed in Section 4. Mobile IP support for the client side was provided separately from the SARA driver.

[5] J.J. Garcia-Luna-Aceves, C.L. Fullmer, E. Madruga, D. Beyer, and T. Frivold, “Wireless Internet Gateways (WINGS),” Proc. of MILCOM’97, Oct. 1997. [6] S.Murthy and J.J. Garcia-Luna-Aceves, “An Efficient Routing Protocol for Wireless Networks,” ACM Mobile Networks and Applications Journal, 1996. [7] R.Ramanujan, S. Takkella, J. Bonney, K. Thurber, “Source-Initiated Adaptive Routing Algorithm (SARA) for Autonomous Wireless Local Area Networks,” Proc. of the 23rd IEEE Conference on Computer Networks, Oct. 1998. [8] C. Perkins, “IP Mobility Support,” RFC 2002, Oct. 1996. [9] H. Lei and C. Perkins, “Ad Hoc Networking with Mobile IP,” Proc. of EPMCC, 1997. [10] C. Hedric, “Routing Information Protocol,” RFC 1058, Jun. 1988. [11] C. Perkins, “IP Encapsulation within IP,” RFC 2003, Oct. 1996. [12] C. Perkins, “Minimal Encapsulation within IP,” RFC 2004, Oct. 1996. [13] J. Postel, “Internet Control Message Protocol,” RFC 792, Sept. 1981. [14] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP),” RFC 2406, IETF, Nov. 1998. [15] S. Kent and R. Atkinson, “IP Authentication Header,” RFC 2402, IETF, Nov. 1998.

10