Autoconfiguration and maintenance of the IP address in ad-hoc mobile networks

1 Autoconfiguration and maintenance of the IP address in ad-hoc mobile networks M. Fazio, M. Villari, A. Puliafito Università di Messina, Dipartimento di Matematica Contrada Papardo, Salita Sperone, 98166 Messina, Italy. e-mail: apulia{mfazio, mvillari}@ingegneria.unime.it Abstract - We present a protocol for the autoconfiguration of ad-hoc devices. It assures the univocal configuration of new nodes in the network and manages the addresses duplication, which is caused by the merging of several networks. The main innovation is the reactive approach for the addresses duplication management. The nodes check the validity of their configurations only when they have to exchange data. This keeps the network traffic load for the autoconfiguration procedures low. The merging of several networks into a single one is made gradually, so to avoid peaks of traffic on some nodes or channels. I. INTRODUCTION When some mobile users wish to connect to an existing ad hoc network or to create a new one, they need to configure their devices, so to be univocally identified. The opportunity of connecting to the Internet through the nodes of an ad hoc network is also a challenging issue [4]. For these reasons, new mechanisms have been created for the self-configuration of the IP addresses for ad hoc wireless devices. Such mechanisms must provide each node of the network with a single IP address. Furthermore, the mechanisms must manage the issue of addresses duplication, which may occur when different networks get in contact. In this paper we propose an innovative self-configuration protocol of IP addresses for the devices of an ad hoc network. This protocol provides unique IDs and minimizes the amount of information that must be stored by each node of the networkto limit the effective use of the portable devices s computational resources. The most innovative aspect of our self-configuration protocol is the reactive management of address duplication, if different ad hoc networks merge. When different networks merge, some nodes with the same IP address may get in contact. This way, packet routing may not take place correctly. The solutions proposed in literature may be used in small networks, because they require to exchange considerable amounts of information. Our protocol detects whether the nodes of the network are correctly configured only when they need to send or receive data. This enables to limit the traffic on the network for the procedures of network merging management. In order to make the communication of nodes more effective in case of merging of different networks, the network parameters of some nodes should be changed, so that a single network can be obtained. Our protocol performs these operation gradually to limit any peak of traffic in the network. The process of merging allows the largest networks to absorb the smallest ones and is stopped when the initial networks tend to split again. II. RELATED WORKS The MANET group of IETF has created a very simple mechanism for assigning an IP address to a new node that connects to an existing ad-hoc network [3]. The technique proposed enables a node (that is going to connect to the network) to select a temporary address. This address is used only for the negotiation of the final IP address. Then the node selects an IP address and asks all the nodes of the network, in order to check whether this address is in use. If a reply is received, a new address must be found. Otherwise, the address selected is automatically considered available, and the node uses it as a final IP address. However, this solution does not provide a way for solving the problem of two new nodes using the same temporary IP address. The system of self-configuration of the IP address proposed by Vaidya [5] also provides for the management of merging or partitioning networks. This system is based on the use of a single Key (eg. the MAC address or a random number consisting of a big number of bits), which is assigned to each node and is associated to the IP address. Referring to a link state routing protocol, each node has some routing tables where the entries exist for all of the nodes of the network. Both the IP address and the key must be stored in the routing tables. If a generic node detects some routing information about the same IP address with a different key, the node invalidates the entry for that specific IP, and notifies the other nodes about the presence of duplicate addresses. In the approach proposed in [2], the system for the management of the IP addresses, is distributed in all the nodes of the network. When a node (Requester) is going to be entered, it has to rely on a configured node (Initiator), which negotiates the address for the new node. Each node belonging to the network stores all the used addresses, as well as the ones that are going to be assigned to the new elements. This allows to know the available addresses at any time. Then the initiator selects an address among the available ones, and asks the other nodes for the permission to use it. This is a way for checking whether the same address is being assigned in another part of the network. If all the nodes send a positive reply for this request, the address is assigned to the Requester, and all the nodes of the network are notified. If a node decides to leave the network, it has to release the address. The nodes that have

suddenly disconnected are taken up, and the corresponding IP addresses are retrieved, since they do not respond to the new assignment procedures. Once the addresses are assigned to all the nodes, any network partitioning must be detected for releasing any IP address available, and for managing the merging of different networks. For this purpose, a single network ID is used, which is selected by the node with the lowest IP address. Since some nodes will not respond during the assignment procedure of the IP address, the partitioning is detected. If such nodes also include the one that originally determined the network ID, a new node must be found with the lowest IP address. This node will then determine the new network ID. Since the IP assignment operations may not take place for a long time, and thus no partitioning can be detected, the node with the lowest IP address must send a message in broadcast from time to time, in order to make its presence noted. The merging of networks is detected when the nodes which a new link is created between have different network IDs. When this happens, the nodes exchange the tables of the addresses used in their networks, in order to detect any duplicate. In this case, only one of the nodes with the same IP address restarts the procedure for assigning the address. III. THE PROPOSED SOLUTION The scenario we are referring to is the one of a wide area where independent ad-hoc networks can coexist. Single nodes can connect to or disconnect from these networks from time to time. In order to communicate with the other nodes, they need to have a single ID configured. Furthermore, due to the movements of their nodes, networks can get in contact or split, thus creating new distinct networks. The addresses that can be associated to the nodes must not have been assigned by the IANA (Internet Assigned Numbers Authority) in view of an Internet connection. For this reason, private addresses must be used for ad-hoc networks. Our system provides to assign any address to the nodes within the blocks 10.0.0.0-10.255.255.255, and 192.168.0.0-192.168.255.255. These blocks denote a class A (10.0.0.0) and a class B (192.168.0.0) network. The concepts of class and subnet are associated with the location of the nodes they consist of. In the case of ad-hoc networks, we do not need to consider these types of classifications, since a network can migrate from an area to another, due to the movement of the nodes. For this reason, the block of addresses containing the one to be assigned to each node is selected at random. Similarly to the UUID described in [2], we associate a NetID to each ad-hoc network created. This NetID must be stored by all the nodes connecting to the network. Each node is therefore identified by the pair NetID-hostID. Rather than using a single ID with many bytes for each node as in [5], this choice allows us to limit the amount of bytes sent to the network when two users wish to communicate. In fact, nodes can use just the hostid to exchange data. The NetID is determined during the network initialization phase, that is, when two single nodes get in contact and create a new ad-hoc network. We chose as NetID a 4-byte number. So the probability that independent ad-hoc networks have the same NetID is very low ( 10 6) even in the case of a heterogeneous system where up to 100 different IDs are present. According to these remarks, we can say that the network IDs of two ad-hoc networks that meet are always different. What we are going to explain is a reactive self-configuration and maintenance mechanism for the IP addresses. Our purpose is to guarantee the correct routing of packets by changing the state of the nodes or of the network as less as possible, in order to optimize the use of resources (memory, CPU, battery, bandwidth, etc.) The problem of the self-configuration of the node address can be divided in two parts: initial configuration of the address, which allows a node entering a network to have a single IP address; management of the merging among networks, due to the dynamics of nodes. Single networks can get in contact, thus generating a new network with duplicate addresses. With regard to the first item, many possible solutions have already been proposed in literature: in section 3.1 we will combine some of them, in order to get a new solution to the problem of the initial address configuration. With regard to the second item, a new and original solution to the network merging problem will be presented in section 4. A. Initial address configuration The solution presented for initial address configuration is based on the mechanism of IP address assignment proposed by the MANET group in [3]. This mechanism: does not produce much traffic in the communication channels; does not require the storage of many information about the network in the single nodes; its implementation is very easy. Perkins[3] does not provide a way for solving the problem of two nodes using the same temporary IP address. So we have decided to use the figures of requester and initiator, which have been defined in [2]. Moreover, we have discarded the address negotiation system from the solution [2], because it requires to update the list of IP addresses available in all of the nodes. As we can see in the experimental section, we have obtained less traffic generated in the network, as well as less information to be stored in each device. According to the [2] approach, the new node relies on the initiator, which negotiates the address for the new node. In our solution, when a node is going to connect to an ad-hoc network, it selects the 4-byte HostID (HID), and requests (through a Request packet) the initiator to start the Initialize procedure. The initiator selects an address at random among the allowed addresses, and sends a Search IP packet in broadcast. The selected address is specified in the packet. Any node receiving this packet checks whether the address is known (whether this address belongs to it or to another node in its routing tables). If the match is detected, the node sends a reply Used IP to the initiator. When the initiator receives the message, a new address is selected, and the Initialize procedure is restarted. Conversely, if no message is received for some time, the

initiator resends the Search IP packet. This way, if the reply does not arrive, this is not due to some errors in the wireless channels. At the end of the process, the initiator notifies the requester with the NetID of the network and the IP address that can be used. This way, the following benefits are obtained, in comparison with the model proposed in [3]: confusion is less likely to occur among the IDs of the nodes to be configured, since two nodes with the same HostID that rely on the same initiator are less likely, rather than two nodes in [3] have the same temporary IP address, even because the HostID consists of 32 bits chosen randomly, while the temporary IP address consists of only 11 bits; the address is assigned independently from the routing protocol selected, because the messages used are typical of this model and do not need to be supported by a specific routing protocol. In case a node configured with the HostID wants to connect to an ad-hoc network, it periodically sends a Request message in broadcast. This message contains the HostID, and is sent until a reply is received from at least one neighbor node. In this case, two conditions may occur: 1) the node that replied is isolated too; 2) the node belongs to an existing ad-hoc network. The first case happen, when two single nodes get in contact and are not configured with a IP address. The node with the highest ID should select the following values at random within the range of allowed values: the NetID for the new network that is being created, as well as the IP address for itself and for the second node. Then it notifies the second node with the NetID and the IP. In the second case, the IP address of the node contacted is already configured. Thus, the node can work as an initiator and perform the assignment procedure of the IP address, as we have mentioned above. Besides a requester may receive the reply to the Request message from several nodes at the same time. In this case, the node that sends the strongest signal is selected as the initiator. to assure the uniqueness of the addresses. The methods proposed in literature for managing the merging of networks use either IDs consisting of several bits (that need to travel in the network together with the IP address)[5] or mechanisms that detect the merging and organize the networks involved, in order to make them a new single network [2]. The devices of ad-hoc networks generally have limited resources and unreliable channels. An immediate management of duplicated addresses can overload the communication channels and nodes. To minimize the use of nodes resources, our protocol manages the networks merging reactively. This means working only when nodes with duplicate addresses need to communicate. We do not assure that duplicate addresses are never present in the network, but that the packets are routed correctly. We use reactive routing protocols (such as AODV), since the proactive routing protocols waste too many resources, and that is in conflict with our purposes. In fact, we chose to realize a protocol for nets of any extension. So we paid attention to minimize the network load and the node resource utilization. We associate a NetID to each ad-hoc network to detect merging of networks; the nodes characterized by the same NetID have different addresses. This is assured by the Initial Configuration phase. When a node needs to send data, the reactive routing protocol starts the Route Discovery process to search the path towards the destination node. During this phase, our protocol detects if duplicated addresses are present. If node S in Figure 2 looks for a node with IPx address, it sends a request packet in broadcast containing the source and destination IDs. When the request reaches the destination node, this sends a reply packet to the source, to specify the path for the data transfer. Our protocol inserts the NetID of the destination node in the reply packet. When the source S receives replies from nodes with different NetIDs, it detects that the IPx address duplication has occurred. If an address IV. DETECTION OF IP ADDRESS DUPLICATION Ad hoc networks are very dynamic environments. Different networks can overlap, and nodes with the same address can get in contact. When this happens, misunderstandings take place while routing the packets, as shown in Figure 1. So we have Fig. 2. Network merging. Fig. 1. Address duplication. to be able to detect the contact among distinct networks, and duplication is detected, the source sends the Change IP packet to the nodes with the same IPx. So these nodes are requested to change their addresses, by restarting the Initialization phase. If different networks get in contact, routing data is more complex, since the address duplication detection system has to be started up. Getting one network with a single NetID is therefore more convenient. However, network merging and partitioning can be very frequent (highly dynamic networks or low density of nodes), and the immediate reconfiguration of all the nodes might overload the devices. Our protocol implements

the Gradual Merging mechanism. This solution allows the nodes to switch from a network to another, according to the evolution of the networks. Each node periodically counts the number of neighbors of its own network or of another one. If there are more neighbors than in a different network, a node can decide to change its network with regard to specific metrics. This way, if two networks tend to merge, the system focuses on the NetID of the network with a higher number or with a higher density of nodes. Conversely, if the networks have few contact points, the procedure for standardizing the NetID is stopped. This merging mechanism avoids to overload the nodes and the communication channels, because it prevents all nodes from reconfiguring their network parameters at the same time. V. PARTITIONING As described above, we have chosen to associate a single network with an ID. We need to detect any network partitioning, so to avoid to create two networks with the same NetID. Let us consider two sub-networks close but logically splitted (see Figure 3). A link can break, and two similar situations may occur. If link 1 that connects different networks is broken, this is not a problem. Otherwise, if link 2 between nodes of the same network is broken, this is dangerous. Since a new node may enter part A and can receive an address present in part B, a new merging between A and B causes an address duplication that cannot be detected with the above-mentioned mechanism. In fact, the nodes of part A and B would have the same NetID2. The detection of the partitioning is activated its network to change the NetID. It specifies the original and the new NetIDs, so that the nodes of the other networks can be excluded from the process. Of course, several nodes can detect the partitioning at the same time, but just one NetID is diffused. VI. EXPERIMENTAL VALUATIONS The configuration protocol of IP addresses proposed in this paper has been simulated with ns2 [1] version 2.26. We have analyzed the operation and evaluated the performances of the protocol with the increase in the number of nodes of the network. In particular, the simulations have been made for two purposes: Analysis of the configuration times of the nodes present in the network. Evaluation of the performances of the protocol according to the traffic generated for the configuration of each node. In the first case we have studied some scenarios consisting of groups of 10, 30, 50, and 70 nodes. the nodes were contained in an area of 1000x1000 m and were activated at random. In Figure 4 we show the normalized average number of nodes that have been correctly configured throughout the time. After comparing the curves related to the number of network nodes, we can see that the higher this number is, the longer the time is for configuring the same amount of nodes. This is due to the different node concentration in the simulations. The lower the concentration is, the higher the number is of isolated groups. This way, more nodes can be configured without an Initiator and so more quickly. However, the longest time needed for the configuration of the nodes is not longer than 0.6 seconds. The curve for 10 nodes shows an abnormal trend, if compared with other curves. In fact, even if the inclination is very high between 0 and 0.1 seconds, the curve cannot reach the saturation value. This is due to the low density of nodes in the network. Many nodes cannot find a neighbor node, and cannot start the configuration procedure. Fig. 3. Network partitioning. when one or more neighbor nodes belonging to the network of one node disappear. Then the last node searches for a path to the first one through the nodes of its network. This is done for avoiding a fragmentation of the network whose nodes can be reached only through the ones of a different network. In fact, the management of partitioning would become more complex. This method provides for the use of a time-out, and the reply must be received before the time elapses. Since we try to reach a neighbor node, the time-out is not difficult to be determined. If no reply is received for the path to the missing node, we cannot determine which event has occurred (whether the node has been abruptly switched off or moved). So we prefer to deal with the two cases the same way, and to assume that a network partitioning has occurred. This is detected by both of the nodes that have lost the link. However, only the node with the higher IP starts the process of Network reidentification. This node selects a new NetID, and informs the nodes of Fig. 4. Percentage of correctly configured nodes The study of the protocol performances has made use of scenarios consisting of 20, 40, and 60 nodes in an area of 1000x1000 m. The nodes were divided in two equal groups. The first group of nodes were activated at random in a time range between t0=0 and t1=170 s, while the second group of nodes were activated in a time range between t2=400 and t3=570 s. In Figure 5 we show the number of packets Initialize sent in a time unit. Packets Initialize send the configuration parameters to the nodes that requested for them. Due to the

lower density of nodes, the curve shows a wide increase for 20 nodes during the first 20 seconds, in comparison with the other curves In fact, in these conditions nodes tend to configure in small groups. Thus, more Initialize packets are sent without starting the procedure Search IP. This is confirmed by the Fig. 7. Packets Request per time unit Fig. 5. Packets Initialize per time unit diagram of Figure 6, which shows the number of packets Search IP sent in a time unit. In this case, the curves (in particular, the 20 node one) are very flat in the first 20 seconds. There is a reason for this: the first nodes that are activated in the network do not need to exchange these packets, because they are configured in pairs. Conversely, figures 5 and 6 are very similar in the range between 400 and 570 seconds. This is due to the fact that the nodes of the second group are not likely to be activated one next to the other and far from the configured nodes. If there are not collisions, each packet Inizialize should be matched by a packet Search IP. In Figure 7 we show the number of packets Request per Fig. 6. Packets Search IP per time unit time unit. The activated nodes use these packets to request the neighbor nodes for the configuration parameters. The higher the number of nodes is, the higher the number of packets Request sent should be. However, the trend is opposite in the range between 170 and 400 seconds. This behavior depends on the different concentration of the nodes in the network. The nodes continue to send such packets, until they find an Initiator. Then they remain silent, waiting for the address to be configured. As we have seen in the previous figures, the nodes are configured 0.6 seconds after the time of activation, at the latest. Then the nodes that continue to send packets Request after this time interval are the ones that remained isolated. The lower the node concentration is, the nodes are more likely to remain isolated, and they cannot find their Initiator. This behavior is confirmed after 570 seconds. In fact, while almost all the nodes of the 60 node networks are configured and stop sending packets Request, the traffic of these packets is intense in a 20 node network. We have used the reactive routing protocol AODV in all of our simulations. This choice did not affect our measurements, because no evaluation was made for the total network traffic. The measures shown point out the behavior of the protocol examined, with reference to specific packets, and with no need for further routing procedures. However, the selection of the AODV protocol allowed to optimize the code, because we could use the methods SendHello, SendRouteRequest, and SendReplay. VII. CONCLUSION In this paper we have described a self-configuration mechanism of the IP address for the nodes of an ad-hoc network. The system has been designed so to avoid to store huge amounts of data allowing each node to be aware of the neighbor nodes only. The reactive management of the address duplication also allows to minimize the traffic in the network: this does not guarantee that the addresses of the nodes can always be different, but to detect any duplication as soon as two users want to communicate. Moreover a gradual merging mechanism has been presented. This allows a node to switch from a NetID to another, according to what is perceived by the node about the evolution of the network. Thanks to this procedure, if two networks with very different size merge, the larger one will prevail over the other. Conversely, the procedure tends to stop where a separation between the elements of two different networks may easily split because few contact elements are present between the different networks. This approach requires to check the partitioning of the network, in order to change the NetID of the two parts that have been formed. REFERENCES [1] K. Fall and K. Varadhan (editors). ns Notes and Documentation. Available http://www.isi.edu/nsnam/ns/ ns-documentation.html, 14 April 2002. [2] S. Nesargi and R. Prakash. Manetconf: Configuration of hosts in a mobile ad hoc network. In INFOCOM 2002, New York, June 2002. [3] C. E. Perkins, E. M. Royer, and S. R. Das. Ip address autoconfiguration for ad hoc networks. Technical report, 10 July 2000. [4] Y. Sun, E. M. Belding-Royer, and C. Perkins. Internet connectivity for ad hoc mobile networks. In International Journal of Wireless Information Networks special issue on Mobile Ad hoc Networks, April 2002. [5] N. H. Vaidya. Weak duplicate address detection in mobile ad hoc networks. In ACM International Symposium on Mobile Ad Hoc Networking and Computing, Boston- Massachusetts, June 2002.