Merging and partitioning in ad hoc networks M. Fazio, M. Villari, A. Puliafito Universit`a di Messina, Dipartimento di Matematica Contrada Papardo, Salita Sperone, Messina, Italy apulia{mfazio, mvillari}@ingegneria.unime.it Abstract
ery process is started. According to this process, a Request packet containing the source and destination ID is sent in broadcast. The nodes that receive this message save the information about source and destination, and then rebroadcast it. Thus, when the request reaches its destination, it can send a Reply packet to the source, in order to specify the path to be used for the data transfer. In order to make a correct routing, each node must be univocally identified, e.g with an IP address. All nodes in an ad hoc network have the same computational potential and the same probability of disconnecting or migrating. Thus, a new automatic and distributed autoconfiguration protocol must be implemented. Aipac [5] is a protocol of autoconfiguration of IP addresses. It gives an initial IP address to the nodes that connect to the network, and provides an effective management of the issues due to the overlapping of different networks. In fact, if new nodes are switched on or the existing ones are moved, some ad-hoc networks may get in contact. Thus, several nodes with the same IP address are made visible. The consequence can be a mistake in the informations routing. Aipac is a reactive protocol, which monitors and solves any address duplication only if the nodes need to exchange data. For this purpose, Aipac uses the procedures of the underlayer reactive routing protocols used by the nodes. This way, the traffic can be minimized on the wireless communication channels and we can also optimize the use of the resources of the devices that form the ad hoc nodes. Aipac implements the Gradual Merging procedures. These procedures allow the nodes to change slowly their configuration, so to obtain a single system, if more networks tend to overlap. This way, the evolution of the system topology can be dynamically followed, and the peaks of traffic can be avoided on the communication channels. In this paper we provide some implementation details for our protocol and we show its performance evalua-
We present the Aipac protocol, which allows nodes in an ad hoc network to configure their own IP address automatically. Due to the mobility of nodes, different networks can overlap, and nodes with the same address can accidentally get in contact. Our protocol offers an innovative management of such merging of networks. In fact, it makes use of the features of reactive routing protocol to minimize the configuration and maintenance of unique address traffic. Moreover, it implements a Gradual Merging procedure that causes the merging process of networks according to their evolution. That allows to avoid to generate a huge amount of traffic on the wireless channels. We used the ns2 simulator to show that the protocol works correctly, and so as to analyze its performance. Keywords: ad hoc network, MANET, IP address, autoconfiguration, network configuration
1. Introduction An ad-hoc network is a communication infrastructure in a dynamic environment, where the nodes that form the network cannot rely either on a fixed infrastructure or on a central coordinating entity. This means that users can communicate notwithstanding the previous agreements, and can connect, disconnect or move in the surrounding space. In order to assure the exchange of information among users, specific routing protocols must be created. Such protocols route the packets in multi-hop paths and consider possible changes in the network topology. Several routing protocols are available today. They are very different, and can be classified in proactive, reactive, and hybrid [3]. In particular the reactive protocols determine the path between two nodes of the network only when this is really necessary. Such informations are only kept for the time needed for the data transfer. Each time a node needs to send data, the Route Discov-
0-7803-8623-X/04/$20.00 ©2004 IEEE
164
fier (NetID), which locates each ad-hoc network. The NetID allows to detect the overlapping of networks. The second identifier is the Host Identifier (HID), that locates a node without a valid IP address that wishes to connect to the network. This node will use the HID until it gets the configuration parameters from the network. The problem of the self-configuration of the node address in AIPAC has been divided in four parts:
tion done with the ns-2 simulator.
2. Related works Some solutions were presented in literature to solve the problem of the IP address automatic configuration in ad hoc networks. When an isolated node wishes to connect to an ad hoc network, it needs to configure an IP address. There are three ways to do that: in the first one, the node can use an identifier (ID) that just him can have to couple with the IP address. This identifier can be the Mac address or a Key with a big numbers of bit selected at random [11]. In this way when different networks overlap, all nodes can be distinguished. The disavantages of this approach are that the selected IDs cannot certainly be unique and the large use of storage and communication resources. In fact both the additional ID and the IP address have to be present in the packet’s header and in the routing tables. The advantage of this approach is that the networks merging management is not necessary. The second way to configure an IP address is that the new node is able to select an available address. The available address can be choosen at random and a query has to be sent through a broadcast message, in order to check whether the address is already in use [10][8]. Otherwise the node can calculate a mathematical expression to find the address to be used, as proposed in [4]. The third way to configure an IP address is through an existing node which acts in order to find a valid address [7]. In the second and third type of solutions, even if the nodes are correctly configurated, a Duplicated Address Detection (DAD) procedure must be enabled. This is due to the possible merging of different networks. Some methods proposed in literature for managing the merging of networks assume that when a merging is detected a procedure is started to automatically reorganize the system into a single network [7][8]. However, ad-hoc devices generally have limited resources and the wireless channels are unreliable. These approaches require to generate a huge amount of traffic.
Initial configuration of the address. When a new node wishes to connect to an ad hoc network (Requester), it selects the HID and asks to a node of the nework already configured (Initiator) to look for an address for it. The Initiator selects an address at random among the allowed ones, and sends a Type Search IP packet in broadcast. If no node of the network sends a Type Used IP packet to say that the address is already in use, the Initiator notifies the Requester with the NetID of the network and the IP address. Management of the duplicated addresses. Because of the mobility of the nodes, single networks can get in contact, thus generating a new system with duplicate addresses. Before sending the data, the reactive routing protocols has to discover the path between the source and the destination node. During this phase Aipac determine whether the IPx address of the destination is duplicated forcing the destination to mark the Reply with the NetID of the network it belongs to. When the source receives different replies, it checks if they are marked with different NetIDs. In that case it notifies the nodes that their IP address is duplicate through a Type Change IP packet. Management of the partitioning of a network into two or more different ones. In fact, let us assume that a network identified with NetIDx splits in two parts (A and B), and that new nodes enter the network. A following merging between A and B can cause address duplication that cannot be detected. When one neighbor disappears, the node searches for a path to the neighbor. If the path does not exist, the node assumes that the partitioning has occurred and selects a new NetID for his network.
3. The AIPAC implementation The AIPAC protocol manages scenarios where several networks can coexist in a wide area. The networks topology can be very dynamic, so nodes can connect to or disconnect from these networks or migrate from one to another. To implement AIPAC, we need to use two identifiers beside the IP address: the Network Identi-
Gradual Merging of networks: it allows a system with a lot of different overlapped networks to become less heterogeneous. It causes the nodes to switch from a network to another, according to the evolution of the networks.
165
source of the Type Hello packet, which becomes its Initiator. - Type Search Ip: this packet allows an Initiator node to ask the other nodes of the network whether the address selected for a Requester is already in use. This packet is sent in broadcast to all the nodes of the network. - Type Used Ip: when an Initiator sends a Type Search IP packet during the configuration procedure of a Requester, the nodes receiving this packet check whether the selected address is the same as their own. If the match is verified, they send a Type Used Ip packet to the Initiator that originated the request, in order to confirm that the address is already in use. When the Initiator receives this packet, a new IP address is selected for the Requester and a new Type Search IP packet is sent to the network. - Type Initialize: this packet gives to a Requester node the possibility of configuring its network parameters. When a Requester receives this packet from its Initiator, the IP address can be configured with a valid one. The node switches from the Requester to the Normal state, and can send data and route packets for the other ones. - Type Hello: the nodes configured with a valid IP address must regularly send this packet to the neighbor nodes, in order to prove their presence. When a node does not receive Hello packets from a neighbor node for a long time, the procedure for the management of partitioning needs to be started. - Type Goodbye: this is the packet that sends a node to its neighbors, before leaving the network when it decides to pass from a network to another in the Gradual Merging process. The node specifies the address of a neighbor node belonging to its network in the packet. This mechanism allows the remaining nodes to detect a partitioning checking whether the node specified in the packet can be reached or not. - Type Check Partition: when a node detects that a neighbor has disappeared or receives a packet Type Goodbye, it needs to check whether a partitioning has taken place or not. This way, a packet of this type is sent in broadcast to the neighbor node or to the node specified in the obj field of the packet Type Goodbye. Then it waits to receive a packet Type Verify Partition. If this packet arrives, this means that no partitioning has taken place. Otherwise, the node must select a new NetID and send it to the nodes of the network, by using a packet Type Change Netid. - Type Verify Partition: make use of h2 header. When a node receives a packet Type Check Partition des-
In [5] we presented the protocol in more detail and provided the measurements about the procedures related to the initial configuration of the nodes. In this paper we give a piece of information about the protocol implementation and assess the merging and partitioning procedures.
4. States and packets for nodes A node can be in just one of four different states: Idle, Requester, Normal and Initiator. A node is in the Idle state when it turns on. Then it looks for an Initiator broadcasting a Type Requester packet, but remains in this state until it does not receive any reply. When the node receives a Type Hello packet from a node of the network, it shifts into the Requester state, sets the Type Hello packet’s source as its Initiator, and waits for the initialization parameters. If the node doesn’t receive Type Hello ackets from its Initiator for a long time, it returns in the Idle state and looks for a new one. A node in the Idle or Requester state can not exchange data or other type of packets in the networks. Just when the node, being in the Requester state, receives the Type Initialize packet, it can configure its own IP address and get into the Normal state. A node in the Normal state can send, receive and route packets. It starts the merging/partitioning procedures and can negotiate the addresses for new Requesters. In the latter case, when the node receives at least one Type Requester packet, it shifts into the Initiator state and starts up the procedure for searching a valid IP address. When it finishes all its Requester configuration procedures, it can go back into the Normal state. A node, with the IPx address already configured, can receive a Type Change IP packet. This means that a duplication of IPx address has happened. So the node has to interrupt its works (e.g. searching IP addresses for Requesters), to return into the Requester state and to restart the procedure for tha configuration of its IP Address. Now we give a detailed list of the Aipac packet’s type: - Type Requester : a node sends this type of packet when it is switched on, and when it wants to be configured with a valid IP address. Its HID and the destination of the packet are included in the header. In fact, the node sends the packet in broadcast, in order to search for an Initiator. When a Type Hello packet is received from a configured node, a Type Requester packet is resent to the
166
tined to it, this type of packet is sent as a reply, in order to avoid to enable the procedure for managing the partitioning from the source node. - Type Change Netid : when a node detects a partitioning, the NetID of its network must be changed. Then it sends a packet of this type, by specifying the original NetID of the network, as well as the new one. The nodes that receive it check whether the original NetID specified in the packet is the one they have, and then change the NetID value.
5. Experimental evaluation In order to test Aipac’s correct operation and assess its performances, we have used the ns2 simulator [2] version 2.26 with the CMU extension for ad hoc networks [6]. The measurements that we are presenting allow to assess the traffic generated for managing and maintaining the uniqueness of addresses in a dynamic ad hoc network. In fact, the merging and partitioning procedures are the most complex and innovative part of the work we are presenting. Furthermore, in a previous paper we have already analyzed the behaviour of the procedure for the initial configuration of the nodes made by Aipac [5]. To easily verify the correctness of our protocol, we have used the graphic interface of the animation tool Nam. This way, we could view the network topologies and we could follow the behavior of each node and of the system as a whole. In the example shown in Figure 1 we can see a screenshot of a simulation done with 10 nodes on an area of 50mx50m. The interface uses the same color for the nodes sharing the same NetID. We can clearly see two distant aggregations of nodes, which are differentiated with two colors for the nodes.
Figure 1. Nam Interface for Aipac. the Gradual Merge Index (igm ). Each node periodically calculates the number of neighbors belonging to its network (n mine), as well as the maximum number of neighbors belonging to one NetID different than its own (n other). If ∆n = n other − n mine is the gap between the number of nodes of the two networks being examined, and n tot = n other + n mine is the total number of neighbors observed, a node switches from a network to another one when the following condition is verified: ∆n > igm (1) n tot The graphs 2(a) and 2(b) show the traffic generated for the merging operations with sets of 60 and 20 nodes respectively, according to different values of igm . The same way, the graphs 3(a) and 3(b) show the partitioning traffic for the same sets of nodes and the same values of igm . The merging traffic that we have considered is the total number of packets Type Requester, Type SearchIP and Type Initialize generated by the nodes. Conversely, the partitioning traffic that we have considered is only the one of the packets Tyype Check Partitoning, Type Verify Partitioning and Type Change NetID. The packets Type Hello and Type Goodbye do not belong to these types of traffic, and are used for both operations. In fact, the former is used both for the assessment of the merging threshold and for detecting the partitioning. The latter is sent when a merging takes place for managing a possible partitioning. The analysis of the graphs shows that the merging and the checks for the partitioning take place ear-
5.1. Simulation results The scenarios used for the performance measurements consist of sets of 10, 20, 30, 40, 50 and 60 nodes, which are switched on in a 1000m x 1000m area, in random positions and between 0 and 75s. Starting from 100, the nodes start moving at a speed between 0 and 5m/s and with a random direction until the end of the simulation. The end of the simulation has been set at 200s. The underlying routing protocol used is AODV [9]. This choice does not affect our measurements, since they are related only to the configuration parameters of the nodes and to the traffic introduced in the network by the protocol examined. The Gradual merging mechanism causes the nodes to switch from a network to another, according to
167
(a)
(a)
(b)
(b)
Figure 2. Traffic generated for the merging operations.
Figure 3. Traffic generated for the partitioning operations.
lier, if the concentrations of the nodes are higher. In fact, with 60 nodes and igm = 0, 3, the traffic for merging is already detected at 20s and the first partitioning operations take place at 45s. In the case of 20 nodes with igm = 0, 3, the procedures are enabled at 50s and 95s respectively. The more the density of the nodes increases, the more the networks tend to overlap. This overlap starts the process of Gradual Merging with respect to the threshold value igm selected. This process tends to limit the level of disgregation of the system. This way, the curves of 60 for the merging traffic nodes can fill up within the simulation time, while the systems with 20 nodes need longer times to reach their stability. Another remark must be made about the traffic generated according to the variation of the merging threshold igm . The merging traffic decreases accord-
ing to the increase in igm . In fact, if the threshold is raised, the nodes cannot switch from a configuration to another, and the merging procedures are enabled less frequently. On the other hand, the partitioning traffic increases according to the increase in igm ; since the merging does not take place, the network is broken down, and partitioning becomes more frequent. We have therefore selected an intermediate value for igm , in order to monitor the number of NetIDs present in the network throughout the time, as well as the unhomogeneity of the network. In particular, the graph 4 has been created with igm = 0.3, carrying the results obtained for the sets of 20, 40 and 60 nodes. While the nodes are switched on (0-75s), the number of NetIDs increases. This is due to the initial configuration of the nodes, which tend to form some pairs if the
168
concentration of neighbor nodes is low. Each pair sets a new NetID, which can be removed only with a process of network merging. The larger is the set of nodes, the larger is the slope of the curve during the first seconds of simulation because more frequently the nodes switch on. Thanks to the Gradual Merging enabled in advance in the systems with a higher concentration of nodes, the 60 nodes curve shows a peak of 3.4, while the 20 nodes curve shows the peak of NetIDs at 4.6. Furthermore, we receive a confirmation about the level of convergence reached by the systems observed. In fact, we note that the 60 nodes curve reaches the value of 1 at 145s. In such conditions, all the nodes have the same NetID, and no more traffic due to merging will be generated. Conversely, the 20 nodes curve does not reach in figure 2(b) the threshold value, due to the low concentration of the nodes, which breaks up the network.
Interface we have realized, we have shown that if two networks merge, the Gradual Merging procedure assures that one will prevail over the other, until the system becomes uniform. This means that all the nodes will have the same NetID. This consideration have been confirmed by accurate simulation results.
7. Acknowledgements Work supported by Consiglio Nazionale delle Ricerche (CNR) with the Strategic IS-MANET Project ”Middleware Support for Mobile Ad-hoc Networks and their Application”[1].
References [1] Infrastrutture software per reti ad-hoc orientate ad ambienti difficili. In Consiglio Nazionale delle Ricerche (CNR) with the Strategic IS-MANET Project, http://zeus.elet.polimi.it/is-manet/, 2002-2004. [2] K. Fall and K. Varadhan (editors). ns Notes and Documentation, 14 April 2002. [3] L. M. Feeney. A taxonomy for routing protocols in mobile ad hoc networks. Technical Report SICS Technical Report T99/07, October 1999. [4] M. Mutka H. Zhou, L. Ni. Prophet address allocation for large scale manets. In The Conference on Computer Communications (IEEE INFOCOM 2003), San Francisco, 1-3 April 2003. [5] M. Villari M. Fazio and A. Puliafito. Autoconfiguration and maintenance of the ip address in ad-hoc mobile networks. In Australian Telecommunications, Networks and Applications Conference (ATNAC 2003), Melbourne, 8-10 December 2003. [6] David A. Maltz. The CMU Monarch Projects Wireless and Mobility Extensions to ns. Monarch Project,
[email protected], snapshot release 1.1.1 edition, 1999. [7] S. Nesargi and R. Prakash. Manetconf: Configuration of hosts in a mobile ad hoc network. In The Conference on Computer Communications (IEEE INFOCOM 2002), New York, 23-27 June 2002. [8] J.-S. Park, Y.-J. Kim, and S.-W. Park. Stateless address autoconfiguration in mobile ad hoc network using sitelocal address, 2001. Internet Draft, draft-park-zeroconfmanetipv6- 00.txt. [9] C. E. Perkins, E. M. Belding-Royer, and S. R. Das. Ad hoc on-demand distance vector (aodv) routing, June 2002. IETF Internet Draft. [10] C. E. Perkins, J.T. Malinen, R. Wakikawa, E. M. Royer, and Y. Sun. Ip address autoconfiguration for ad hoc networks, July 2002. Internet Draft, draft-ietf-manetautoconf-01.txt. [11] N. H. Vaidya. Weak duplicate address detection in mobile ad hoc networks. In ACM International Symposium on Mobile Ad Hoc Networking and Computing, BostonMassachusetts, 9-11 June 2002.
Figure 4. Number of NetID in the ad hoc network for 20,40 and 60 nodes.
6. Conclusions The AIPAC protocol provides for an autoconfiguration mechanism of the IP address for the nodes of an ad-hoc network. It manages merging and partitioning of networks due to the mobility of nodes, so that nodes have unique IP addresses. These procedures are reactive. This does not guarantee that the addresses of the nodes can always be different. However, this guarantees that any duplication is detected as soon as two users want to communicate. In this paper we have presented some details of AIPAC implementation. Through the ns2 simulator, we have given simulation results about the merging and partition traffic, whose management represents the more innovative features of our work. Thanks to the Graphical
169
