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 e-mail 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
A
Mobile Ad Hoc Network is an autonomous system of
mobile 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, Email, 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, 2005.
The authors are with the Information Networks Lab, Departiment of
Electronic Engineering and Information Science, University of Science and
Technology of China, Hefei, Anhui 230027, PRC (e-mail:
hupeng@mail.ustc.edu.cn; plhong@ustc.edu.cn; jinsheng@ustc.edu.cn).
0-7803-9182-9/05/$20.00 ©2005 IEEE.
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 2002. 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
- 462 -
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
1
A
B
D
2
4
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
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.
http://folk.uio.no/paalee/
-2-
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.
0
Extensions
7
Type
15
Len
RREQ/RREP
Receive RREQ
Name extension
exist?
No
Yes
31
Cache the route
and name of src
Reserved
Name Mapping(s)
<HV
fresh cache exist?
UDP
Generate RREP
and NREP
IP
Fig. 2. Format of extended packet
Renew RREQ and NREQ
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
subsequent routine of
AODV
Fig. 3. An example of Name Resolution
Receive RREP
TABLE I
FUNCTION OF EXTENDED HEADER
Type
0
1R
1
Function
DNS Request
DNS Response
Domain Name
Destination
Destination
Routing packet
IP address
RREQ
None
RREP
Destination
Name extension
exist?
No
2
Yes
Push the Source
Mapping
Source
and
Destination
RREQ
Source
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.
Cache the route
and name
Renew RREP and NREP
subsequent routine of AODV
Fig. 4. An example of Name Resolution
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
-3-
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.
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, ND Refers to the number of data
packets, andTi refers to th end-to-end delay of the ith data
packet.
(1)
ND
¦ 'T
(2)
i
i 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.
New scheme
AODV+DNS
Average pause time (s)
Fig. 5. An example of Name Resolution
800x800m
Simulation time
100s
Num of nodes
Transmission
distance
50
Mobility
Num of
items
4m/s
New scheme
AODV+DNS
Delay (ms)
Network area
data
1
ND
T
TABLE 2
SOME PARAMETERS OF SIMULATION
250m
NR
ND
LR
Routing load
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.
100
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 802.11 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
Average pause time (s)
Fig. 6. An example of Name Resolution
IV.
CONCLUSION
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
-4-
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]
[2]
[3]
[4]
[5]
[6]
Stuart Cheshire, Marc Krochmal, “Multicast DNS”
draft-cheshire-dnsext-multicastdns-04.txt, IETF, February 2004.
Jaehoon Jeong, Jungsoo Park, Hyoungjun Kim, Kishik Park: “Name
Service in IPv6 Mobile Ad-Hoc Network”, ICOIN 2003, Cheju Island,
Korea, Feb. 12-14, 2003, 692-701.
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, 2003.
C. Perkins, E. Belding-Royer, S. Das, “Ad hoc On-Demand Distance
Vector (AODV) Routing”, RFC 3561, IETF, July 2003.
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 2004.
E. Royer and C-K. Toh, “A Review of protocols for ad hoc mobile
wireless networks”, IEEE Personal Communication, 6(2): 46-55, Apr.
1999.
-5-