Name Resolution in On-demand MANET

Transcription

1 Name Resolution in On-demand MANET Peng Hu, Pei-Lin Hong, and Jin-Sheng Li Abstract As an important service, DNS is essential to lots of network applications such as and SIP. But traditional DNS can not work well in Mobile Ad Hoc Network (MANET) owing to the lack of fixed infrastructure. This paper proposes a novel DNS framework for the On-demand MANET by extending a DNS message in the routing protocol. The simulation results are showed that the new framework has better performance in reducing the overhead of domain name resolution. Index Terms Domain name resolution, mobile ad hoc network, network simulation, on-demand routing protocol, proactive cache I. INTRODUCTION Mobile Ad Hoc Network is an autonomous system of Amobile wireless nodes that can dynamically form a network without necessarily using any pre-existing network infrastructure. Different from traditional IP networks, it is distributed, multi-hop, self-organized. Due to node mobility, the network topology may change rapidly and unpredictably. As an important component in computer networks, Domain Name System (DNS) is relevant to many applications closely. Currently most of services in Internet, such as Web, , SIP, all can not work without the cooperation of DNS. As a matter of fact, DNS is very important to MANET too, which can be deduced from the following reasons: Ultimately MANET is used to bear the concrete service relevant to DNS, especially under the circumstance of person being the mobile node, and domain name is easier to remember and manage than pure IP address. with the overlay broadening, MANET is certain to interoperate with Internet, so it is necessary to understand the DNS of Internet. As IPv6 is around the corner, the address space of MANET will be very huge so that it is prone to building stable mapping between address and domain name. As a supplement, domain name can make the system more controllable. Owing to the inherent character of MANET, traditional centralized and hierarchical DNS can not work well in the distributed network. It is considered from two aspects: the lack of fixed infrastructure in MANET makes it incapable of guaranteeing to supply the stable DNS server. Even with the Manuscript received December 20, 2004; revised March 17, The authors are with the Information Networks Lab, Departiment of Electronic Engineering and Information Science, University of Science and Technology of China, Hefei, Anhui , PRC ( hupeng@mail.ustc.edu.cn; plhong@ustc.edu.cn; jinsheng@ustc.edu.cn). appearance of stable DNS server node, since the topology of the MANET varies from time to time, the service is not reliable so that DNS server may be out of the transmission area of other nodes. Nowadays a few schemes of domain name resolution are proposed since the Multicast DNS [1] can be introduced into the MANET as a solution. In [2] the author investigated some characters of IPv6 and proposed Ad Hoc Name Service System for IPv6 MANET (ANS), which is similar to multicast DNS. Engelstad [3] found a method that utilizes the route discovery packets to carry the DNS messages to fulfill the DNS request and response by extending the route discovery in on-demand MANET. The scope of this article is limited to MANET that is routed with a reactive routing protocol. We only focus on the on-demand MANET and propose a DNS framework that is implemented in the routing protocol as an extension. The main novel feature of the framework is that it can undertake both name resolution and route discovery simultaneously. For convenience the MANET discussed below refers to the on-demand one if not specified. II. RELATED WORKS A. On-demand Routing MANET routing is a research hot spot in recently years. Generally speaking there are two kinds of routing protocol: proactive (table-driven) and reactive (on-demand) [6]. Reactive routing protocol is preferred when nodes move frequently, when only a subset of nodes keep on communicating at any one time, and when communication sessions last for relatively long times. A number of reactive routing protocols have been proposed, among which the most widely studied and popular proposals include the Ad hoc On-demand Distance Vector (AODV [4] ) routing protocol, the Dynamic Source Routing (DSR [5] ) protocol and the Temporally Ordered Routing Algorithm (TORA), etc. Reactive protocols, or on-demand protocols allow source node to discover dynamic route towards a destination node on the fly. Demonstrating with the protocol AODV, they work as the following: When a source node wants to communicate with a destination node that can not be reached based on the existing routes, it will broadcast a Route Request (RREQ). The packet is forwarded by the neighbor nodes and spread throughout the network. During this broadcast a reverse path from the destination node to source node is constructed. If some node receiving RREQ packet either is the destination or has the valid route towards the destination IP address, it will unicast a Route /05/$ IEEE

2 Response (RREP) packet along the reverse path mentioned above. Once the RREP packet reaches the source node, the whole procedure of the route discovery is over, and the data packets can be delivered consequently. Although different on-demand protocols vary in detail, the framework proposed in this paper can work based the common on-demand protocols since they comply with the rule of route discovery above. B. Domain Name Resolution Methods in MANET Related papers [3] show that multicast and broadcast is more suitable for DNS resolution than unicast and anycast. This section reviews prior work on domain name service. Multicast DNS can be used as a solution of DNS in MANET. It is designed jointly by Zero Configuration Networking working group and DNS Extension working group of IETF. In the case of lack of centralized DNS server, Multicast DNS allows query request packets to be spread by multicast. When some node that knows the mapping from the domain name to IP address, it sends out the query response packet by multicast too. ANS is the name service system that provides the name resolution and service discovery in IPv6 MANET that is site-local scoped network. ANS System consists of ANS Resolver and ANS Responder. ANS Resolver performs the role of DNS resolver while ANS works as name server in MANET. ANS Resolver sends DNS query in the multicast address that ANS Responder in each mobile node has joined for name service before. While ANS Responder receives DNS query from ANS Resolver in other mobile nodes, it checks whether it is responsible for the query. If it is responsible for the query, it sends the appropriate response to ANS Resolver in unicast. The mechanism proposed by Engelstad [3] extends the traditional RREQ/RREP message with DNS query message. Source node put the Name Resolution Request (NREQ) into the RREQ packet that is spread throughout the network. In order to distinguish the new RREQ and old one, the destination IP address in RREQ is filled with a specially-defined address. If the node receiving RREQ does not understand NREQ extension, it will ignore the subsequent process and just forward it to other neighbor nodes. When the destination node receives the request, it will generate the piggyback Name Resolution Reply (NREP) message as well as RREP, and unicast them back to the source node. C. Analysis of Prior Solutions After analyzing the solutions introduced above, we find that some drawbacks still exist. Owing to lack of consideration of feature of MANET, Multicast DNS uses multicast during the resolution, thus it result in excessive packets which increase the overhead of nodes as well as overload the network. ANS improves the performance to some extent by replacing the multicast with unicast the time reply is sent back, so it decrease the system overhead. Yet it is mainly a framework designed for IPv6 ad hoc network and demands the auto configuration necessarily. Especially when it comes to on-demand MANET, ANS doesn t behave well because some 3 S A 1 characters, such as route cache, which are not taken into account. Compared with the others, the proposal of Engelstad is more feasible to on-demand MANET. It introduces the DNS query into route discovery more efficiently. In fact, its performance may discount in some special cases. As illustrated in Figure 1, if node A wants to get IP address of node D, it initiates an NERQ which passes along the path A-B-D, and node D sends back the NREP reversely. Subsequently, if node S needs to know the IP address of D, it will repeat the same steps. We can notice that S doesn t make use of the DNS mapping cached in A and does forward the request along the path S-A-B-D because A does not handle the piggyback NERQ/NERP but the RREQ/RREP. So, this can lead to a number of unnecessary overheads of DNS queries while there are lots of DNS queries for the same destination name. We can find that among the known schemes, none of them fully considers the dynamic routing property of MANET or combines the existing on-demand routing method with name resolution. III. THE FRAMEWORK AND PROTOCOL As analyzed above, with regard to the existing proposals there are two steps in on-demand MANET before the data is transmitted: The source queries the IP address of communication peer by means of broadcast or multicast. The source initiates the route discovery according to some routing protocol if there is no valid route before. We can notice that the proposals discussed above just involve the first step at that time name resolution is performed only. Note that broadcast or multicast is necessary to both name resolution and route discovery. Besides, the paths in both scenarios are of the same hops. With this consideration we combine the two phases into a whole one more tightly by adding the domain name property into the route table, so that DNS query can be handled during the route discovery. A. Framework and protocol description There are some preliminaries in our new scheme: Each node can involve the domain name resolution as well as the route discovery. In addition every node is the authoritative name server of itself. This means that, each node can request and respond independently. B 1. A sends name request for D 2. D replies name response to A 3. S sends name request for D 4. D replies name response to S Fig. 1. An example of Name Resolution D 2 4

3 In order to make DNS a bump in the route layer, cache table and routing protocol must be extended. One property, NAME, is inserted into the cache table of each node, which represents the corresponding name mapping to the destination IP address of a route item. Besides, for one destination, NAME and the route item share the same TTL value and are present or absent in pairs. In other words, if some node is able to return the DNS mapping, it will provide the valid route for the source also by sending the RREP with piggyback NERP. Extensions Type Len Reserved Receive RREQ Name extension exist? Yes Cache the route and name of src No RREQ/RREP UDP Name Mapping(s) fresh cache exist? IP Generate RREP and NREP Fig. 2. Format of extended packet NREQ and NERP here differ with what [3] defined on the packet format though they have the same abbreviation. Figure 2 gives the packet format of the NREQ and NREP in our framework, while the function is listed in the Table 1. The main improvement is that there is the mapping from the source name to its IP address in the NREQ. In contrast to [3], NERQ here takes the name information of the source node. Another new feature is that both NREQ and NREP may include more than one mapping from the source name to the IP address, which makes some application such as load balance possible in the MANET. With regard to handling the packets, each node runs the new TABLE I FUNCTION OF EXTENDED HEADER Type Function DNS Request DNS Response Push the Source Mapping Domain Name Destination Destination Source and Destination Routing packet RREQ RREP RREQ IP address None Destination Source Fig. 3. An example of Name Resolution Renew RREQ and NREQ subsequent routine of AODV Receive RREP Name extension exist? Yes Cache the route and name No on-demand routing protocol with the extension of domain name and handles the NREQ/NREP defined in Figure 2. While broadcasting the NREQ and RREQ, each node received the broadcast does nothing different but additionally cache the mapping of source node contained in the NREQ and the route item taken by RREQ into the local memory. Concerning the treatment of NERP and RREP, it is similar to the above means except that unicast replaces broadcast. With AODV as the raw protocol, the flow details are illustrated in Figure 3 and Figure 4. When there is no extension in the RREQ/RREP packet, nothing additional is needed. Otherwise, the intermediate node executes the following action. Fig. 4. An example of Name Resolution Renew RREP and NREP subsequent routine of AODV Firstly it decapsulates the RREQ and caches in the mapping of source node, then reads in the domain name to be resolved, which is to be searched in the local cache subsequently. While the domain name is matched, It is implied that the node not only can return the corresponding IP address but also can declare a

4 valid route. If the domain name is not found in the cache, the node generates the new NERQ and RREQ. Cache mentioned here includes two attributes: the mapping from domain name to IP address and the route leads to this exact IP address. Domain name and corresponding IP address are included in the NERP, while the IP address of answer denoting the route is carried by the RREP. With the NERP and RREP passing along the reverse path, both the mapping and route of destination are cached in the intermediate nodes in order to be reused by other request. While receiving the NERP and RREP, the source node gets known to the IP address and corresponding route towards the destination node. Then it is qualified to send the data directly based on the fresh route. B. Analysis of our framework Compared with the prior solutions, our solution outperforms them in terms of on-demand MANET. Firstly it is a tight combination of route discovery and DNS query, both of which are implemented at the same time. So it results in the decrease of overhead and enhancement of the efficiency. Secondly, it changes the traditional caching concept of DNS item by introducing the Proactive cache. After pushing the DNS item to the nodes that receives the RREQ broadcast, DNS cache can make full use of the on-demand feature of MANET and raise the hit probability. Thirdly, in respect that name extension can be inserted into the packets freely, our solution has a scalability advantage over the others. Otherwise, it is fit for both IPv4 and IPv6 MANET because of the independence of IP protocol. Lastly, multi-mapping from names to IP addresses brings more flexibility to the network. It is also convenient for developing some new techniques (such as load balance). General speaking, domain name is just a sign to identify the node. If all the nodes is assigned one or more domain names, in fact, node can make route decision based on the NAME property directly. Without doubt the name-based routing is more efficient than the current routing on network layer. Also, it is much friendly to applications and end users. TABLE 2 SOME PARAMETERS OF SIMULATION Network area 800x800m Simulation time 100s Num of nodes 50 Mobility 4m/s Transmission Num of data 250m 100 distance items C. Performance measurement It is obvious that our framework is more efficiency since it has less state while both the domain name and route discovery are considered. In order to assess the improvement quantitively, we simulate in NS-2.1b9a with CMU Monarch Project's extension. The basic parameter is shown in Table 2. In addition, we adopt IEEE as MAC protocol, AODV as the base routing protocol and Constant Bit Rate (CBR) as traffic model. Our new scheme and the original scheme are compared below on the same condition. Here the original scheme we use to compare with is the proposal of [3] which caches the name-to-ip mapping along the reverse path. As a result of simulation, the packet loss rate in both scenarios are almost the same and below 5%. We select the routing load and average end-to-end delay as the evaluated parameters, which are defined in Formula 1 and Formula 2. Note that NR Represents the number of routing packets, N D Refers to the number of data packets, andti refers to th end-to-end delay of the ith data packet. NR LR (1) N T N D Ti (2) D i 1 ND 1 As shown in Figure 5, the overhead of routing in our new scheme is lower than that in traditional DNS. This owes to the raised hit ratio of DNS query. We can observe that the new load is 26 percent less than the old one averagely. Figure 6 illustrates the comparison of the end-to-end delay in both scenarios. Owing to the decrease of the processing time and less broadcast flooded, the average transmission delay in our scheme is about 20 percent lower than the original, so quality of service is enhanced evidently too. Routing load Average pause time (s) Fig. 5. An example of Name Resolution Delay (ms) IV. CONCLUSION New scheme AODV+DNS Average pause time (s) Fig. 6. An example of Name Resolution New scheme AODV+DNS This paper analyzes the prior domain name resolution schemes of MANET firstly, then proposes a new resolution method for on-demand MANET which binds name resolution

5 and route discovery together. By means of appending several aspects related to DNS to the routing protocol, It resolves the domain name and discovers the route at the same time. Consequently the overhead of bandwidth of the whole network and processing time of each node can be decreased to a degree. In addition the proposal works in both IPv4 and IPv6 MANET and scales well. REFERENCES [1] Stuart Cheshire, Marc Krochmal, Multicast DNS draft-cheshire-dnsext-multicastdns-04.txt, IETF, February [2] Jaehoon Jeong, Jungsoo Park, Hyoungjun Kim, Kishik Park: Name Service in IPv6 Mobile Ad-Hoc Network, ICOIN 2003, Cheju Island, Korea, Feb , 2003, [3] Engelstad,P.E., Thanh,D.V., Egeland G., Name Resolution in On-Demand MANETs and over External IP Networks, Proceedings of IEEE International Conference on Communication 2003 (ICC), Anchorage, Alaska, May 11-15, [4] C. Perkins, E. Belding-Royer, S. Das, Ad hoc On-Demand Distance Vector (AODV) Routing, RFC 3561, IETF, July [5] David B.J., David A.M., Yih-Chun Hu, The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR), draft-ietf-manet-dsr-10.txt, IETF, July [6] E. Royer and C-K. Toh, A Review of protocols for ad hoc mobile wireless networks, IEEE Personal Communication, 6(2): 46-55, Apr