We propose a framework for information management in ad hoc network ... In order to access a file, the node where the file is stored has to be located. ..... account, i.e., the successor might be the node at the other extreme of the network.
I NFORMATION M ANAGEMENT
IN
M OBILE A D H OC N ETWORKS
Mansoor Mohsin
Ravi Prakash
Department of Computer Science The University of Texas at Dallas Richardson, TX 75083-0688
{mmohsin,ravip}@utdallas.edu Abstract Over the past several years, there has been considerable research in the area of mobile ad hoc networks. Most of this research has focused on routing and MAC layer issues. As a result, there are several well known routing algorithms for ad hoc networks like DSDV, DSR, AODV, TORA, ZRP. Network services, on the other hand, still do not exist for ad hoc networks. These services are based on some sort of information management and include naming service, web service, directory service, etc. We propose a framework for information management in ad hoc network that is fault tolerant, robust and scalable. The performance of the proposed solutions is evaluated through simulation experiments.
1
I NTRODUCTION
A mobile ad hoc network (MANET) consists of a set of identical nodes communicating with each other via wireless links. There is no fixed infrastructure and the network is formed when the mobile nodes come in wireless range of each other. All nodes are not within wireless range of each other and intermediate nodes may have to relay packets between two nodes. Due to node mobility and node arrival and departure, the network topology is always in a flux. Over the past several years, there has been considerable research in the area of mobile ad hoc networks. Most of this research has focused on routing and MAC layer issues. As a result, there are several well known routing algorithms for ad hoc networks like DSDV, DSR, AODV, TORA, ZRP [10] [2] [11] [8] [9]. Information management in MANETs is an important problem, but has not received sufficient attention (only IP address allocation has been looked at in detail). This can be used to implement a number of network services like naming service, web service, directory service, etc. A mobile ad hoc network works in a truly distributed manner. Since we do not have a dedicated server, information about network resources has to be spread across all the nodes of the network. Every node will have to advertise the services it provides. Other nodes will try to discover the node offering the specific service they are looking for. Hence, besides mobility, dynamic node population, network partitioning and merging, this gives rise to the following two basic problems: 1. Information advertisement by server nodes. 2. Maintenance of information at clients. Recently, there has been some work on information management like quorum-based solutions for MANETs [4] [1]. This work suffers because all servers and quorums must be predefined and the idea works for a constant network population. Related work also exists for peer-to-peer systems [12] [14] [13]. When applied to MANETs, P2P solutions 1
may be an overkill. This is because they are designed for stable wired networks and use their own routing algorithm (application level routing) on top of IP routing, increasing overhead and complexity. Hence, we need to either combine the best of both the solution approaches given above, or come up with a new solution. Here is the basic idea of the proposed solution. We use a distributed hash table to index nodes that store information. This hash table is managed using a technique similar to the one used in [7]. Every node hashes onto a point in the hash space and manages the space in the vicinity of this point. Each piece of information is also hashed onto the same hash space, and the node managing that portion of the hash space stores pointers to this information. This way information can be retrieved by hashing onto the information key and contacting the node managing that portion of the hash space. Replication is used to withstand node failures. Given below are a few examples of information management: • Naming Service: This service provides name-to-machine mapping in a network. In traditional networks, this information is kept at dedicated DNS servers. In a MANET, there is no such dedicated server, so distributed management of information is required. One possible approach is that a subset of nodes act as name servers. New nodes joining the network, register themselves with these name servers. Other nodes that wish to locate a particular node given its name use these name servers to find the corresponding machine address. • Directory Service: In a distributed filesystem, different subtrees of the filesystem are kept at different machines. In order to access a file, the node where the file is stored has to be located. Unlike NFS and other static distributed filesystems, the filesystem structure is constantly changing in an ad hoc network and a file stored at a given node, might not be available with the same node in future due to node arrivals and departures. For example, suppose that a particular directory is mapped onto a mobile node. If that mobile node departs the network, then all the files in that directory are lost. Hence, there is a need for replication. Information management can be used to manage different replicas of a filesystem of a MANET. • Web Service: In a MANET web service, all the nodes (or a subset of nodes) can collectively act as a web server. The HTML files and other web content is distributed to all such nodes to share load. A single file might be replicated on more than one servers to withstand failures. The problem here is that given a URL, find the nearest server node that is hosting the requested webpage. An HTML page in turn be using CGI scripts or other software components, which must also be located using the same mechanism. • Network Services: In a practical MANET environment, we can envision a situation where the nodes joining the network will offer different network services to other nodes (e.g., printing server, web service, etc). Since this happens on the fly, there needs to be a mechanism where other nodes discover the services offered by a particular node. • IP Addresses: IP addresses are network resources that are assigned to new nodes when they join a MANET. Since there is no dedicated DHCP server, the MANET nodes will have to collectively decide which IP address to assign to a new coming node and how to collect the IP addresses of departing nodes. We need information management to manage information about IP address allocation in a MANET. By looking at the above examples, we can see that the difficulty of the problem arises due to the dynamic nature of a mobile ad hoc network. Whenever a new node joins a network, it injects some new information into the network; and whenever a node departs the network it takes away some information about the network. The goal is to efficiently maintain information in a MANET inspite of node failures, and purge old information about nodes when they depart the network. In this paper, we propose a framework for information management in ad hoc network that is fault tolerant, robust and scalable. The performance of the proposed solutions is evaluated through simulation experiments.
2
S YSTEM M ODEL
We consider an autonomous MANET working on its own. It has no gateway or connection to the external world. The network is formed by a group of nodes coming together. The nodes can join and leave the network any time and are 2
free to move around. Hence the size and topology of the network is dynamic and unpredictable in nature. There is no single information management server. Instead, all or some of the nodes collectively perform the functionality of an information management server. Ordinary nodes that do not act as servers are called client nodes. Note that a node being a server does not mean it is more powerful than ordinary nodes. It is a role associated with nodes, which might change over a long period of time, i.e., server nodes might become client nodes and vice versa. The role of a node as client or server is with respect to a particular service. For example, a node might be acting as a server for IP address assignment and at the same time it might be acting as a client for a naming service.
3
R ELATED W ORK
The research conducted so far in the area of information management has focused on traditional wired networks. The main area of focus has been keeping consistent copies of data in a distributed environment. The system model assumed is very stable and failures are rare. In the past, most of the research has been conducted in the context of distributed databases. Recently peer-to-peer networks have been studied in great detail about how to locate data objects with minimum effort. To our knowledge, there has been no research done on information management, focusing on mobile ad hoc networks as the system model. Solutions presented so far that are relevant to our topic can be broadly divided into two categories. The next subsections give an overview of these approaches.
3.1 Quorum Based Solutions In quorum based solutions, each server is part of one or more quorums. The quorums are chosen in such a way that there is always at least one common node between any two quorums. In this way, changes made to one quorum are propagated to other quorums (by means of the common node between the quorums) and ultimately to the entire network. A quorum based system for information dissemination in ad hoc networks is presented in [4]. In this solution, a subset of nodes act as servers. Information update is performed as follows: 1. Node x randomly selects a quorum and sends UPDATE message to all servers in the quorum. 2. The servers, on receiving the UPDATE message, overwrite their old copy of the data item with the new copy. Information query is performed as follow: 1. Node y randomly selects a quorum and sends a QUERY message to all servers in the quorum. 2. The servers, on receiving the QUERY message, send a REPLY containing the information. 3. Receiving all the REPLY messages, y selects the message with the greatest timestamp. Since two quorums always intersect, each query returns the latest value of the queried data item. Although the authors claim to handle network partitioning, but what if the network partitions in such a way that one partition does not contain any quorum? Clearly, the protocol will fail in this situation. Moreover, although node arrival and departure is handled, the overall network population is assumed to be constant. All servers and quorums are predefined. Load is balanced among servers by randomly selecting quorums, but load balancing is not handled in general. The nodes elected as servers continue performing as servers, doing more work then ordinary nodes. Uniform Quorum Systems (UQS) [1] is another approach proposed for mobility management. In UQS, the quorum size, the size of quorum intersection, and the number of quorums to which each database belongs are all fixed constants. 3
The paper studies the construction of quorums under different network traffic and mobility patterns. As long as one quorum remains, location updating and location querying are possible in the entire network. If the backbone node has been disconnected from the network for more than a threshold amount of time, a new node will be chosen as the replacement. The paper only deals with mobility information, but can be generalized to other type of information. All the disadvantages of quorum based systems discussed earlier also apply here. In addition, UQS incurs additional overhead to discover the nearest backbone node by an ordinary node (they use the idea of ZRP). The paper uses multicasting for querying a quorum, but we do not have a multicasting algorithm for MANETs. If a backbone node disconnects from the network, the location stored in its database is lost. From the time at which a location database detaches to the time of its replacement, the database is inaccessible to the network nodes. Additional overhead is incurred by backbone nodes to find out how many complete quorums are accessible at the time of location update or query.
3.2 Hashing Based Solutions In a hashing based solution, a distributed hash table is maintained by all the nodes of a network. Generally a consistent hash function is used to incorporate the dynamic behavior of the network. A consistent hash function is one which changes minimally as the range of the function changes [3]. Like most hashing schemes, consistent hashing assigns a set of items to buckets so that each bin receives roughly the same number of items. Unlike standard hashing schemes, a small change in the bucket set does not induce a total remapping of items to buckets In addition, hashing items into slightly different sets of buckets gives only slightly different assignments of items to buckets. Consistent hashing has the following consistency properties: • Smoothness When a machine is added to or removed from a set of caches, the expected fraction of objects that must be moved to a new cache is the minimum needed to maintain a balanced load across the caches. • Spread Over all the client views, the total number of different caches to which an object is assigned is small. • Load Over all the client views, the number of distinct objects assigned to a particular cache is small. Content-Addressable Network (CAN) [12] is based on the idea of a distributed hash table and consistent hashing. The basic operations performed on a CAN are the insertion, lookup, and deletion of (key, value) pairs. Each CAN node stores a chunk (called a zone) of the entire hash table. In addition, a node holds information about a small number of adjacent zones in the table. Requests (insert, lookup, or delete) for a particular key are routed by intermediate CAN nodes towards the CAN node whose zone contains the key. CAN’s design centers around a d-dimensional Cartesian coordinate space on a d-torus. At any point in time, the entire coordinate space is dynamically partitioned among all the nodes in the system such that every node owns its individual, distinct zone within the overall space. The virtual coordinate space is used to store (key, value) pairs as follows: to store a pair (K1 , V1 ), key K1 is deterministically mapped onto a point P in the coordinate space using a uniform hash function. The corresponding (key, value) pair is then stored at the node that owns the zone within which point P lies. To retrieve an entry corresponding to key K1 , any node can apply the same deterministic hash function to map K1 onto point P and then retrieve the corresponding value from point P. If the point P is not owned by the corresponding node or its immediate neighbors, the request is routed through the CAN infrastructure until it reaches the node in whose zone P lies. A CAN node maintains a coordinate routing table that holds the IP address of virtual coordinate zone of each of its immediate neighbors in the coordinate space. Using this neighbor coordinate set, a node routes a message towards its destination by simple greedy forwarding to the neighbor with coordinates closest to the destination coordinates. To allow CAN to grow incrementally, a new node that joins the system is allocated its own portion of the coordinate space. This is done by an existing node splitting its allocated zone in half, retaining half and handling the other half to the new node. 4
When a node leaves CAN, it hands over its zone and associated (key, value) database to one of its neighbors. If the zone of one of the neighbors can be merged with the departing node’s zone to produce a valid single zone, this this is done. If one or more nodes fail, an immediate takeover algorithm ensures that one of the failed node’s neighbors takes over the zone. However, in this case the (key, value) pairs held by the departing node are lost until the state is refreshed by the holders of the data. The algorithm is not robust enough to handle permanent node failures. It uses its own routing algorithm on top of IP routing, increasing overhead and complexity. It also does not handle network partitioning. Chord [14] is another solution based on the same idea. It provides support for data location by mapping a given key onto a node. It also uses consistent hashing to assign keys to Chord nodes. In the steady state, in an N-node system, each node maintains information about only O(log N) other nodes, and resolves all lookups via O(log N) messages to other nodes. Each node is identified by a m-bit identifier on an identifier circle modulo 2m , called the Chord ring. A key k is assigned to the first node whose identifier is equal to or follows (the identifier of) k in the identifier space. This node is called the successor node of key k. If identifiers are represented as a circle of numbers from 0 to 2m − 1, the successor of key k is the first node clockwise from k. When a node n joins the network, the keys for which n is a successor get assigned to n. When a node n leaves the network, all of its assigned keys are transferred to n’s successor. Lookups are implemented on a Chord ring with little per-node state. Each node only knows how to contact its current successor node on the identifier circle. Queries for a given identifier are passed around the circle via these successor pointers until they encounter a pair of nodes that straddle the desired identifier; the second in the pair is the node the query maps to. To accelerate lookups, each node n maintains a routing table with upto m entries, called the finger table. The ith entry in the table at node n contains the identity of the first node s that succeeds n by at least 2i−1 on the identifier circle, i.e., s = successor(n + 2i−1 ), where 1 ≤ i ≤ m (an all arithmetic is modulo 2m ). Chord uses a “stabilization” protocol that each node runs periodically in the background and which updates Chord’s finger tables and successor pointers. When a new node n first starts, it asks any known Chord node to find the immediate successor of n. Every node runs the stabilization protocol periodically. It asks its successor the successor’s predecessor p, and decides whether p should be n’s successor instead. this would be the case if p recently joined the network. Every node also periodically runs protocols to make sure its finger table entries are correct, and to reset the node’s predecessor pointer if the predecessor has failed; this allows it to accept a new predecessor. The correctness of the Chord protocol is compromised if nodes fail. To increase robustness, each Chord node maintains a successor list of size r, containing the node’s first r successors. If a node’s immediate successor does not respond, the node can substitute the second entry in its successor list. Chord also does not deal with network partitioning. The Chord ring does not take the spatial location of nodes into account, i.e., the successor might be the node at the other extreme of the network. Pastry [13] is a scalable distributed object location and routing substrate for wide-area peer-to-peer applications. Its design is closely related to Chord. Just as in Chord, each node in the Pastry network has a unique ID, which is used to indicate the node’s position in a circular node ID space. When presented with a message and a key, a Pastry node efficiently routes the message to the node with a node ID that is numerically closest to the key, among all currently live Pastry nodes. The expected number of routing steps is O(log N), which is the same as Chord. The advantage that Pastry has is that it takes into account network locality, i.e., it seeks to minimize the distance messages travel, according to a scalar proximity metric like the number of IP routing hops. In a network of N nodes, Pastry can route to the numerically closest node to a given key in less than log2b N steps under normal operation (b is a configuration parameter). This means that (as opposed to Chord), Pastry can make steps bigger than log N hops (b = 1 in Chord). Although Pastry is an improvement over Chord and presents a more general solution technique, it is also designed for peer-to-peer networks and suffers from the same problems as Chord and CAN when applied to MANETs. The only plus point is that Pastry takes network locality into account, but it only considers k numerically closest nodes when minimizing the distance. In MANET with node movement, this scheme is no better than not taking network distance into account. All these solutions are designed for peer-to-peer networks. Although a peer-to-peer network also lacks central control, it is quite different from a MANET for two main reasons. First, although nodes can join and leave a peer-to-peer network at will, its network topology is considerably stable when compared with a MANET because the nodes in
5
a peer-to-peer network are not mobile; and second, a peer-to-peer network usually consists of millions of nodes in contrast to a few thousand nodes in a MANET. Due to this huge size of a peer-to-peer network, it is not desirable to keep information about all other nodes at a given node, because of high memory requirements. Instead, information about only a subset of nodes is kept a given node. This subset is different for every node and arranged in such a manner that after a few hops of search the desired destination node is reached. This is called application level routing, which is in addition to the standard IP based routing. Most of the peer-to-peer network solutions reach the destination node using application level routing in O(log n) steps, where n is the size of the network. Because of the relatively stable network topology and high available bandwidth, application level routing does not impose considerable overhead in peer-to-peer networks. However, when the same solutions for peer-to-peer networks are used in a MANET, they suffer from performance degradation and do not give the intended result. The main reason for this poor performance is the overhead imposed by application level routing. While this might not be a disadvantage in a stable wired network, it imposes considerable overhead when applied in a MANET environment. Hence, solutions for peer-to-peer networks are too heavy weight for MANETs. We claim that by maintaining more state information at each node, we can minimize the need for application level routing. In fact, we can keep information about all other nodes at a given node, completely eliminating the need for application level routing. This idea works well in a MANET because of its small size. Hashing used with the buddy system [5] exploits this idea. We also note that the proposed solution is designed for MANETs and will not work well in a peer-to-peer network. This is because our solution requires every node to keep information about every other node. A MANET is considerably smaller in size than a peer-to-peer network, so the technique works well in MANET, but not in peer-to-peer networks. This reasoning is analogous to the reasoning between flat and hierarchical routing. A flat routing can work well in a MANET (because of its small size) but not in the Internet (because of its large size). On the other hand, hierarchical routing is more suitable for the Internet than a MANET.
4
P ROPOSED S OLUTION
The proposed solution for information management is based on the idea of a distributed hash table to index the nodes that store information. Unlike a standard hash table, where the entire table is stored at one node, a distributed hash table spreads over all the nodes of the network, each storing a small portion of the hash table.
4.1 Distributed Hash Table We assume that all the nodes are configured and have been assigned an IP address. In addition, every node knows who its neighbors are. We consider a hash space of size U (U >> N), where U is a power of 2 and N is the number of nodes in the system. Using a Uniform Hash Function (UHF), every node maps its IP address to some point in the hash space from 0 to U − 1 and gets a disjoint “chunk” of the space containing that point. The size of the hash space is large enough that the probability of two nodes mapping onto the same point is negligible. However, even if this happens, both the nodes get the same “chunk” from the hash space, and both the nodes store the same information about that “chunk” of hash space. This duplication is treated as replication (Section 4.3) and is useful to handle failures. At any instant, the union of the chunks of all nodes comprise the entire space of size U. The hash space is divided among nodes using a technique similar to the one used in the buddy system for IP address assignment [7]. In the beginning there is only one node and has the entire space from 0 to U − 1. When a second nodes comes in, the hash space is divided into two halves of equal size. One of the nodes gets the space from 0 to U/2 − 1 and the other gets the space from U/2 to U − 1, depending on the point in the space where their IP addresses map using the hash function. If the IP addresses of both the nodes map onto the same half in the hash space, then that half is divided into two more halves. This process is repeated until both the nodes get their separate chunks in the hash space. If two or more nodes concurrently request for the hash space, the requests are processed sequentially in the order they are received. All the new nodes get their portion of the space S using this technique. In this way, the hash table for the entire system gets distributed among all the nodes of the network. 6
Every node maintains its view of the global Hash Table which records the allocation of hash space to all the nodes. This table is kept consistent by periodic exchange of messages among all the nodes. Hence after some time, every node will have the same view of the global hash table. The number of entries in this table is equal to the number of nodes in the system. Since the size of each entry is a few bytes, the size of hash table does not impose considerable memory overhead. For example, for a MANET of 1000 nodes, the size of the hash table will be a few kilobytes. Moreover, the table is sorted with respect to the hash space and search for any point in the hash space can be performed efficiently in O(log n) time. The top level algorithm is described in Algorithm 1. The call to allocateHashSpace() is described in more detail in Algorithm 2. Algorithm 1 Hash Space Management. Node i is the new node which needs to get its portion of the hash space. Node j is a neighbor of node i. Node j informs node i that it can get its hash space from node k. Node i then contacts node k which assigns it a portion of the hash space. 1: key = i.hash(i.IPAddress) 2: j = i.getNeighbor() 3: k = j.lookupHashTable(key) 4: i.hashSpace = k.allocateHashSpace(i.key) As an example, suppose that we have a hash space of size 1024. The first node i gets the value 224 after hashing onto its IP address. Since there is no other node in the system, i will get the entire space from 0 to 1023 (Figure 1(a)). Now another node j joins the system, and after hashing onto its IP address, j gets the value 647. Node i will divide its space into two equal parts, keep the first half and give the second half to node j (Figure 1(b)). In the terminology of the buddy system, nodes i and j are said to be buddies of each other. Now a third node k arrives and gets the value 100 after hashing onto its IP address. In this case, after dividing the hash space of i into two halves, both the nodes i and k will be in the same half of the hash space. To make sure that every node gets its unique chunk of the hash space, the portion where both nodes i and k lie will be further divided into two halves. This process will be repeated until both nodes i and j get their individual chunks in the hash space (Figure 1(c)). Assigning chunks in this way leads to a situation where the hash space from 256 to 511 is not assigned to any node. Since node i’s hash space is adjacent to this unused space, node i will combine this unused space with its own. The same hash space is used as an index to store and retrieve any type of information. We assume that there is some key associated with every piece of information that can be mapped onto the space S using some hash function. In a naming system this key could be the host name, in file system this key could be the file name, and so on. When a node i has some information that it likes to share with others, it will hash onto the information name. This will give node i a key that it can use on its hash table to find node j managing that portion of hash space where the information name maps. It will then register the information with node j, which stores this information in an Information Table. Algorithm 3 outlines this procedure. If some other node i wants to retrieve the same information, it will get node j by hashing onto the information name. Since node j knows where that information is stored (at node k), the querying node will get access to the requested information. Algorithm 4 outlines this procedure.
4.2 Synchronization Lamport’s logical clocks [6] are used to achieve synchronization of the hash table among the nodes. Here is the outline of the synchronization process: • There is a sequence number associated with each each block of the hash space. Whenenver a block gets divided, the sequence number of the resulting blocks is one greater than the original block. Let x be a block which gets divided into blocks y and z. Let seqNo(x), seqNo(y), and seqNo(z) be the sequence numbers associated with blocks x, y, z respectively. Then
7
Algorithm 2 k.getHashTable(i.key) 1: while k.ad jacentSpaceList has more elements do 2: ad jacentSpace = k.ad jacentSpaceList.getNextElement() 3: if i.key ≥ ad jacentSpace.startIndex and i.key ≤ ad jacentSpace.endIndex then 4: i.hashSpace.startIndex = ad jacentSpace.startIndex 5: i.hashSpace.endIndex = ad jacentSpace.endIndex 6: k.ad jacentSpaceList.delete(ad jacentSpace) 7: return (i.hashSpace) 8: end if 9: end while 10: x = (k.hashSpace.startIndex + k.hashSpace.endIndex) / 2 11: if k.key < x and i.key ≥ x then 12: i.hashSpace.startIndex = x 13: i.hashSpace.endIndex = k.hashSpace.endIndex 14: i.hashSpace.endIndex = x − 1 15: return (i.hashSpace) 16: else if k.key ≥ x and i.key < x then 17: i.hashSpace.startIndex = k.hashSpace.startIndex 18: i.hashSpace.endIndex = x − 1 19: k.hashSpace.startIndex = x 20: return (i.hashSpace) 21: else if k.key < x and i.key < x then 22: if k.key < i.key then 23: i.addAd jacentSpace(x, k.hashSpace.endIndex) 24: else 25: k.addAd jacentSpace(x, k.hashSpace.endIndex) 26: end if 27: k.hashSpace.endIndex = x − 1 28: k.allocateHashSpace(i.key) 29: return (i.hashSpace) 30: else if k.key ≥ x and i.key ≥ x then 31: if k.key < i.key then 32: k.addAd jacentSpace(k.hashSpace.startIndex, x − 1) 33: else 34: i.addAd jacentSpace(k.hashSpace.startIndex, x − 1) 35: end if 36: k.hashSpace.startIndex = x 37: k.allocateHashSpace(i.key) 38: return (i.hashSpace) 39: end if Algorithm 3 Information Registration. Node i has some information which it registers with node j. 1: key = i.hash(in f ormationName) 2: j = i.lookupHashTable(key) 3: j.registerIn f ormation(in f ormationName) Algorithm 4 Information Retrieval. Node k makes a query about some information, node j knows where this information is stored, and node i has the requested information. 1: key = k.hash(in f ormationName) 2: j = k.lookupHashTable(key) 3: i = j.lookupIn f ormationTable(in f ormationName) 4: in f ormation = i.retrieve(in f ormationName)
8
UHF(i) 0
127
255
383
(a)
511
639
767
895
1023 Node
Hash Space
i
0 - 1023
Node
Hash Space
i
UHF(i) 0
127
UHF(j)
255
(b)
383
511
639
767
i
UHF(k) 0
1023 i
0 - 511
j
512 - 1023
Node
Hash Space
j
UHF(i)
127
895
UHF(j)
255
383
511
639
767
895
1023
k i
(c)
k
i
j
UHF(k) 0
(d)
127
0 - 127 128 - 255, 256 -511
j
512 - 1023
Node
Hash Space
UHF(j) 255
383
511
639
767
k
895
1023
j
k
0 - 511
j
512 - 1023
Figure 1: Distribution of the Hash Space among different nodes.
seqNo(y) = seqNo(x) + 1 seqNo(z) = seqNo(x) + 1 • When two blocks y and z merge to form a block x, its sequence number is calculated as follow: seqNo(x) = maxseqNo(y), seqNo(z) + 1 • nodes periodically send their hash table to their neighbors (local broadcast). Each node does this independently. • If a node receives two blocks with different sequence number, then the block with higher sequence number is chosen.
4.3 Handling Failures The buddy data structure is important here! When node departs, it hands over its chunk of space and Information Table to its buddy node, which merges the space and Information Table with its own, if possible (Figure 1(d)). If, however, there is a failure and one or more nodes get disconnected from the rest of the network, then this will be detected when the nodes will exchange messages to update their hash table. In this way, the lost hash space is recovered, but the information stored at the failed node is lost. In order to make the loss of information robust against node failures, we will have to introduce replication. One idea is to replicate the Information Table at k left and right nodes in the space S. Another idea is to use multiple hash functions to replicate every piece of information. Note that we are actually replicating pointers to the information, and not the information. Replicating the actual information is the responsibility of the hosting node, and depending on the nature of the information, it can decide the degree of replication and the protocol used for replication. 9
4.4 Partitioning and Merging When a network partitions into two or more partitions, the situation is handled by the synchronization component of the protocol (Section 4.3). Each partition is identified by a partition ID which is guranteed to be unique (it is generated using UUIDs). There is no significance of sequence numbers when partitions merge, because the sequence number for blocks in the partitions were generated independent of each other. In this case, nodes in one partition have to give up their hash space (and the information table associated with that hash space) and initialize themselves again.
4.5 Improvements We can improve the performance of the protocol in the following ways: 1. One might argue why do we have to go from node i to node j and then from node j to node k (Algorithm 4). What if we store the information at the node which has the information table (i.e., node j)? While it might not work in the general case, but if the size of the information is small, we can employ this strategy. An ideal situation where this can be used is the naming service, where the information is the name to address mapping. 2. Another improvement is based on the observation that a node makes a query only when it needs to retrieve the information. In algorithm 4, the querying node gets the IP address of the node that has the required information. It then goes and fetches this information from that node (k → j → k → i → k). If the intermediate node having the information table can forward the request to the node having the information, we can save one hop of latency and communication overhead (k → j → i → k). Moreover, since node i registers information with node j, so only node j can ask for information from node i. This allows nodes i and j to authenticate each other when registering and retrieving information, providing secure access to the information. 3. In the model we have described so far, we assume that all the nodes take part in the information management algorithm. Suppose that we want only a subset of nodes to act as information servers. In this case only the server nodes will maintain the distributed hash table, and their functionality will be the same as described above. However, since ordinary nodes no longer have a hash table with them, they will have to look for information in order to make a request. This can be done using an expanding ring method. After the information server is found, the rest of the process is the same as before. We can also use anycast to find the nearest information server and do load balancing among the servers.
5
S ALIENT F EATURES
OF THE
P ROPOSED S OLUTION
The two most important components of information management in ad hoc networks are information dissemination and lookup. Keeping this in mind, following are the salient features of the proposed information management system for MANETs: 1. Low Latency: A good information management system should allow fast information advertisement and discovery. Whenever a node wishes to provide a service to the network, it advertises this service. This advertisement should reach other nodes as fast as possible, so that they come to know of this new resource. Similarly, whenever a node wishes to discover a service and locate the node(s) offering that service, it should be able to do that quickly. In the proposed solution only one node is consulted to achieve both the above goals. 2. Low Overhead: Nodes in a mobile ad hoc network have limited storage capacity as well as limited battery. Hence it is desirable for any protocol to have low memory, communication and energy overhead. This overhead is in addition to the routing and other low level protocol overhead, so needs to be low. In the proposed solution,
10
every node keeps a table of size equal to the number of nodes in the network. Since each entry of the table is a few bytes and the maximum size of a MANET is about a few thousandss, the memory overhead is a few KB which is acceptable. 3. Fairness: Any information management system should make sure that all the nodes do an equal amount of work. In the proposed solution, each node has equal probability of managing some part of information, hence the load is distributed fairly to all the nodes. 4. Robustness: A MANET is very dynamic in nature. Nodes continuously join and leave the network, and link failures are very common. Under such extreme conditions, it is very important that the information management systems should be resilient to such network failures. This means that if a node providing a network service goes down then the information management system should be able to discover this and rectify any resulting problem. In the proposed solution, replication is used to make the protocol robust. Nodes periodically exchange messages to discover any failure and recover from it. 5. Independence from Low Level Protocols: Whenever designing an application level protocol for MANETs, we need to keep in mind that it will be running on top of routing, media access, and other protocols. Since a MANET is supposed to work in a heterogeneous environment, it is desirable that any application level protocol is independent of the routing and other low level protocols. In this way, applications will work no matter what underlying protocol the MANET is running on. The proposed solution satisfies all these properties.
6
S IMULATION
The proposed protocol was simulated using the ns-2 simulator. The simulation setup consists of a MANET of 32 nodes in an area of 500m × 500m. The nodes move with a maximum speed of 15m/s after a mean pause of 25s. The size of the hash space is 1024.
6.1 Load Distribution We assume that the rate at which nodes make requests is equal for all the nodes. Hence the criteria that determines the load on a node is the size of hash space managed by a node and the number of information keys stored at that node. If a node has more keys it is likely to receive more requests than a node with less keys. The simulation results show that the load is uniformally distributed as each node manages the same size of hash space and receives approximately equal number of keys. In the simulation, the nodes hashed onto their node IDs to get a portion of the hash space. As there were 32 nodes and the size of the has space was 1024, each node got a hash space of size 32. We used integers to represent information keys. These keys were chosen randomly by the nodes and registered with the servers managing them. These servers were determined by hashing onto the information keys. In the simulation, all the nodes had a total of 100 keys and each server stored either 3 or 4 keys. In this way, the number of keys managed by the server nodes was equally distributed.
6.2 Latency Latency is an important measure of the performance of any protocol. We usde the hop count as the measure of latency. First we found the hop count from the originator of a request to the information server, and then we found the hop count from the information server to the node containing the requested information. The average hop count in both cases was found to be the same. Table 6.2 summerizes the results. As shown in Table 6.2, most of the requests require just one hop, i.e., the target node is reached in a single step. Hence, for most cases a logical hop in the proposed solution is equal to a single physical hop. In contrast, the peer-to-peer 11
Hop Count 0 1 2 3
% Requests 1% 87% 18% 3%
Table 1: Hop Count
solutions require O(log N) logical steps, where each step could be one or more physical hops. This clearly shows that by maintaining more state information at each node, we can completely eliminate application level routing resulting in low latency of the protocol. Table 6.2 also shows that the hop count is zero for 1% of the nodes. This is the case when the requesting node is the information server itself, or when the information is stored at the same node as the information server. Moreover, although we did not encounter a case where the hop count is more than 3, but in principle the worst could be the diameter of the network.
7
C ONCLUSION
AND
F UTURE W ORK
We presented a solution for information management in MANETs. The proposed solution uses a distribted hash table. Both the node IDs and the information keys are mapped onto the same hash space. Each node gets a portion of the hash space and manages the information that hashes onto this portion of the space. The distributed hash table is managed using the idea of the buddy system. A couple of solutions based on the same idea exist for peer-to-peer networks. These solutions require application level routing in addition to IP level routing. The proposed solution completely eliminates application level routing by maintaing more state information at each node. Since the size of a MANET is considerably smaller than a peer-to-peer network, the extra information maintained at each node does not incur significant overhead. Simulation results show that the proposed solution performs better than other approaches when applied to MANETs. Work needs to be done in making the solution work despite network partitioning and merging. Partitioning can be detected using timeouts, however merging can lead to problems as there can be overlaps in the hash space and two or more nodes might be managing the same portion of hash space. Security is also an issue as a malicious node can corrupt the distributed hash table, resulting in complete collapse of the protocol. Cryptographic techniques can be used to encounter this problem.
R EFERENCES [1] Z. J. H AAS AND B. L IANG, Ad hoc mobility management with uniform quorum systems, IEEE/ACM Transactions on Networking, 7 (1999), pp. 228–240. [2] D. B. J OHNSON AND D. A. M ALTZ, Dynamic source routing in ad hoc wireless networks, in Mobile Computing, Imielinski and Korth, eds., vol. 353 of THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE, Kluwer Academic Publishers, 1996. [3] D. K ARGER , E. L EHMAN , T. L EIGHTON , M. L EVINE , D. L EWIN , AND R. PANIGRAHY, Consistent hashing and random trees: Distributed caching protocols for relieving hot spot on the world wide web, in 29th Annual ACM Symposium on Theory of Computing, El Paso, TX, May 1997, pp. 654–663. [4] G. K ARUMANCHI , S. M URALIDHARAN , AND R. P RAKASH, Information dissemination in partitionable mobile ad hoc networks, in Proceedings of the 18th IEEE Symposium on Reliable Distributed Systems (SRDS ’99), Washington - Brussels - Tokyo, Oct. 1999, IEEE, pp. 4–13. 12
[5] K. C. K NOWLTON, A fast storage allocator, Communications of the ACM, 8 (1965), pp. 623–625. [6] L. L AMPORT, Time, clocks, and the ordering of events in a distributed system, Communications of the ACM, 21 (1978), pp. 558–565. [7] M. M OHSIN AND R. P RAKASH, IP address assignment in a mobile ad hoc network, in IEEE Military Communications Conference (MILCOM 2002), vol. 3, IEEE, Oct. 2002, pp. 856–861. [8] V. D. PARK AND M. S. C ORSON, A highly adaptive distributed routing algorithm for mobile wireless networks, in IEEE Infocom ’97 - 16th Conference on Computer Communications, IEEE, 1997. [9] M. R. P EARLMAN AND Z. J. H AAS, Determining the optimal configuration for the zone routing protocol, IEEE Journal on Selected Areas in Communications, 17 (1999), pp. 1395–1414. [10] C. P ERKINS AND P. B HAGWAT, Routing over multihop wireless network of mobile computers, in SIGCOMM: Computer Communications Review, ACM, Oct. 1994, pp. 234–244. [11] C. P ERKINS AND E. ROYER, Ad hoc on-demand distance vector routing, in 2nd IEEE Workshop on Selected Areas in Communication, IEEE, Feb. 1999, pp. 90–100. [12] S. R ATNASAMY, P. F RANCIS , M. H ANDLEY, R. K ARP, AND S. S HENKER, A scalable Content-Addressable network, in Proceedings of the ACM SIGCOMM 2001 Conference (SIGCOMM-01), R. Guerin, ed., vol. 31, 4 of Computer Communication Review, New York, Aug. 27–31 2001, ACM Press, pp. 161–172. [13] A. ROWSTRON AND P. D RUSCHEL, Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems, Lecture Notes in Computer Science, 2218 (2001), pp. 329–350. [14] I. S TOICA , R. M ORRIS , D. K ARGER , F. K AASHOEK , AND H. BALAKRISHNAN, Chord: A scalable PeerTo-Peer lookup service for internet applications, in Proceedings of the ACM SIGCOMM 2001 Conference (SIGCOMM-01), R. Guerin, ed., vol. 31, 4 of Computer Communication Review, New York, Aug. 27–31 2001, ACM Press, pp. 149–160.
13
