Name Resolution in On-Demand MANETs and over External
IP Networks
Paal Engelstad, Do Van Thanh, Geir Egeland
University of Oslo (UniK) / Telenor R&D, 1331 Fornebu, Norway
{Paal.Engelstad, Thanh-van.Do, Geir.Egeland}@telenor.com
Abstract - Common user applications cannot run in
mobile ad-hoc networks (MANETs) before a method for
name resolution is in place. While the Domain Name System
(DNS) works well on the fixed Internet, it represents a
centralized approach to name resolution, which is not
suitable for MANETs. This article refines the framework
developed for name resolution in MANETs and shows how a
mechanism for local name resolution can be implemented
transparently to the application. It also proposes methods to
align local name resolution on the MANET with DNS over
external IP networks, forming one integrated method for
name resolution. Finally, different strategies for how to store
name-to-address mappings on MANETs are discussed.
I. INTRODUCTION
Most user-applications today, including web browsing, email, telnet and ftp, rely on name resolution for communication,
because it is not easy for users to remember 32-bits or 128-bits
IP-addresses. In fact, it is easier for human beings to remember
names, e.g. email addresses, SIP user names or site names.
Normally a DNS Resolver looks up a requested name (e.g. a
Fully Qualified Domain Name -FQDN) and retrieves an IPaddress on behalf of the application ([1], [2]). The application
would then subsequently contact the counterpart directly, using
the obtained IP-address. DNS takes a centralized hierarchical
approach to name resolution, and is designed with the fixed
Internet in mind.
A centralized approach is not very suitable for name
resolution on MANETs. Since MANETs lack infrastructure,
some means (e.g. an election algorithm) would be required to
ensure that there is always at least one name server present on
the network, storing name-to-address mappings of the other
MANET nodes. Furthermore, MANETs are dynamic and often
exhibit non-deterministic ad-hoc behavior. With a centralized
approach, MANET nodes would have no means to resolve
names or initiate sessions if the centralized name server moves
out of reach of the MANET.
Instead, MANETs call for a distributed approach to local
name resolution. Without a method for name resolution in place,
users in MANETs cannot use the same applications that are
developed for fixed networks for local communication.
The scope of this article is limited to MANETs that are
routed with a reactive routing protocol. Reactive routing
protocols are preferred when nodes are highly mobile, when
only a subset of nodes are communicating at any one time, and
when communication sessions last for relatively long times.
(Pro-active routing protocols, on the contrary, are preferred for
lower levels of mobility, and when communication is random
and sporadic.) With reactive routing there is no routing overhead
for nodes that don't communicate.
In this scenario, a solution to name resolution that is ondemand is also preferred. This means that there is no name
resolution overhead for names that MANET nodes don't want to
resolve, and the solution scales well to a large number of names
available on the MANET.
MANETs might be connected to the Internet, through one
or more Internet Gateways. An Internet Gateway is a MANET
node that is also a router or host on an external IP network. It
may provide other nodes with access to the Internet, and it will
probably be able to resolve names by the Domain Name System,
like most Internet hosts. A name resolution protocol for
MANETs should therefore interoperate with DNS so that it can
resolve both local names and names from the DNS system. With
an on-demand mechanism for name resolution, all names of the
DNS may be made available for resolution by MANET nodes,
without consuming additional bandwidth on the MANET.
In summary, the problem that this paper addresses is the
lack of a distributed name resolution mechanism for on-demand
MANETs. The name resolution mechanism should be ondemand, and it should co-operate well with reactive routing
protocols. It should also interoperate with DNS over external IP
networks. But most importantly, the mechanism should be
hidden to the application, so that the same application used for
communication on the Internet can also be used for
communication locally on a MANET.
Analyses of name resolution on MANETs have been
undertaken in [3], and a framework for name resolution was
outlined. In the following we present this and other related work
on name resolution. Then we detail how a mechanism for this
can be implemented in on-demand MANETs. We show how
local name resolution in a MANET can interoperate with name
resolution over external IP networks. Finally, we describe
different strategies for how to store name-to-address-mappings
in the MANET.
II. RELATED WORK
A. Reactive Routing protocols
A number of reactive routing protocols have been proposed.
The most widely studied and popular proposals include the Adhoc On-demand Distance Vector (AODV [4]) routing protocol,
the Dynamic Source Routing (DSR [5]) protocol and the
Temporally Ordered Routing Algorithm (TORA [6]).
Reactive protocols allow source nodes to discover routes to
a destination IP-address on demand. Most proposals, including
AODV, DSR and TORA, work as follows: When a source router
desires a route to a destination IP-address for which it does not
http://folk.uio.no/paalee/
already have a route, it issues a route request (RREQ) packet.
The packet is broadcasted by controlled flooding throughout the
network, and sets up a return route to the source.
If a router receiving the RREQ is either the destination or
has a valid route to the destination IP-address, it unicasts a
Route Reply (RREP) back to the source along the reverse route.
The RREP normally sets up a forward route. Thus, the pair of
RREQ and RREP messages set up a bi-directional unicast route
between source and destination. Once the source router receives
the RREP, it may begin to forward data packets to the
destination. (The acronyms RREQ and RREP are borrowed
from AODV.)
On-demand MANETs can scale to a larger number of
nodes, if the range of the flooding is restricted to a limited
number of hops. By setting appropriate values in the TTL field
of the IP header of an RREQ, the hop-limit can be controlled.
Some reactive routing protocols allow for expanded ring search
in which the originator of RREQs may search for a route to the
destination more than one time, each time increasing the hoplimit, until the route is found or until the originator gives up.
Different reactive routing protocols have different strategies
to deal with route maintenance and route repair. Most protocols
let routes that are inactive eventually time out. If a link break
occurs while the route is active, the routing protocol normally
implements an algorithm to repair the route. Often the router
upstream to the link breakage will send an error message
upstream towards the source.
Different protocols also have different ways to manage
routing state information. AODV, for example, stores state
information in the network. Routers that receive RREQs set up
the return routes in the route tables as backwards pointers to the
source router. Similarly, RREPs that are propagated back to the
source along the reverse route leave forward pointers to the
destination in the route tables. The Dynamic Source Routing
(DSR) protocol, on the other hand, does not rely on routing state
in the network for the forwarding of packets. Instead, the sender
of a packet encodes the route explicitly into the packet (i.e. it
source-routes the packet).
The analyses and proposals presented in this paper are
independent of different mechanisms for route maintenance and
route repair. They are also independent of how routing state
information is managed.
B. Name resolution in ad-hoc networks
Engelstad et al. [3] showed that MANETs call for a solution
to name resolution that is quite different from Multicast DNS
[7]. First they argue that name resolution requests should be sent
by multi-hop flooding, and that the flooding mechanism should
leave return routes towards the originator of the request. Without
a return route, nodes that respond to a request would have to
issue an additional broadcast to discover routes back to the
originator of the request.
http://www.unik.no/personer/paalee
They also showed that replies should leave a forward route
to a node that resolves a name. In many instances the node that
responds to a name resolution request will be the owner of the
requested name (i.e. the node identified with the name) or have a
valid route to that node. If the name resolution reply leaves a
forward route, a route is in place as soon as the originator wants
to contact (or 'bind to') the resolved IP address.
To realize this, a RREQ header should carry the name
resolution requests (NREQs) while a RREP header should carry
the name resolution replies (NREPs). The RREQ and RREP
headers ensure that return and forward routes are formed as part
of the name resolution process.
The destination IP address contained in the RREQ, which
indicates which address is searched for, should be set to a predefined value, NAME-RESOLUTION-ADDRESS. This can be
a zero-address, a broadcast address or a pre-assigned multicastaddress to which no node can cache a route. Hence, intermediate
nodes will respond to the RREQ, unless they can resolve the
requested name in the Name-to-Address extension of the RREQ
to an IP-address. When the NAME-RESOLUTION-ADDRESS
is being used, additional unicast specific properties of the
reactive routing protocol might also need to be turned off (e.g.
the destination sequence number of AODV should be treated as
unknown).
C. Service Discovery in ad-hoc networks
Engelstad et al.'s work [3] may serve as a general guideline
for resource discovery in on-demand networks. Later, Koodli
and Perkins [8] proposed a similar solution to service discovery
in on-demand Ad-hoc Networks. Service Discovery Requests
and Replies are carried by RREQs and RREPs. This approach is
justified by [3], due to basic similarities between name
resolution and simple service discovery. The proposed
mechanism for service discovery specifies message formats that
are designed to inter-operate with the Service Location Protocol
(SLP) [9].
III. IMPLEMENTING LOCAL NAME RESOLUTION
A. Name resolution on the air
As pointed out above, a MANET node that wants to resolve
a name should broadcast a Name Resolution Request (NREQ)
packet carried by a RREQ header. When another node that has a
valid name-to-address mapping for the requested name (and a
valid route to the resolved address) receives the NREQ, it
responds by unicasting a Name Resolution Reply (NREP)
carried by a RREP header back to the originator of the NREQ
(Figure 1).
To ensure that a forward route is formed, the sender of the
NREP must insert its own IP address as a Destination IP
Address in the RREP header. It might also have to add other
unicast specific routing information, depending on the reactive
routing protocol in use. (E.g. with AODV it must insert its own
destination sequence number in the RREP header.)
To conserve bandwidth on the MANET, the NREQ
extension should consume as few bits as possible. The NREQ
obviously needs to contain the name. In addition, it probably
only needs a Type-Length header as a multiplexor (mux) that
accommodates other extensions to RREQ messages to be
defined in the future (Figure 1).
actual name resolution mechanism has to be transparent to
applications. This means that applications should use the same
Application Programming Interface (API) to initiate name
resolution (such as the get_host_by_name API on Unix
operating systems) whether the application is located on a
MANET node or on a regular Internet host (Figure 2).
Figure 2. A client application initiates name resolution through an Application
Programming Interface (API). The API should be the same whether the
application is located on a MANET node or on a regular Internet host.
Figure 1. A Name Resolver (NR) floods a Name Resolution Request (NREQ),
carried by a Route Request (RREQ) header, throughout the network (1). A Name
Server (NS) process with the requested name-to-address mapping unicasts a
Name Resolution Reply (NREP), carried by a Route Reply (RREP) header, back
along the reverse route formed by the RREQ (2).
Similarly, the NREP should contain the resolved IPaddress(es) wrapped in a Type-Length header (mux). In addition
it may contain the requested name or similar information that
allows the originator to match the resolved IP address(es) with
the name (Figure 1). Otherwise, the originator might have
difficulty to distinguish between different replies if it tries to
resolve several different names within a short time interval.
An advantage of including a name in the NREP is that it
allows originators to be more stateless: They don't have to store
information to be able to match requests with replies. The
penalty of carrying the name in the NREP is low, since the
NREP is sent by unicast, assuming that only one or a few nodes
respond to the request. (We will see later that when NREPs are
specified to include both name and resolved IP address, it also
makes it easier for intermediate nodes to cache name-to-addressmappings appearing in NREP messages that they are
forwarding.)
The message formats of the NREQ, the NREP and other
extensions proposed in this document have been presented in a
separate Internet-Draft [10] and submitted as a by-product of
this document to the Internet Engineering Task Force (IETF).
B. Keeping name resolution transparent to the applications
A main objective of name resolution on MANETs is to be
able to reuse applications that are used for communication on
the Internet for local communication on the MANET. Hence, the
C. Different ways to implement name resolution
With a given API, there are two obvious ways to implement
name resolution, depending on whether the name resolution
software (i.e. Name Resolvers and Name Server
processes/daemons) are aware or un-aware that it is located on a
MANET node.
If the Name Resolver is MANET-unaware, it will normally
form a DNS request, push this request down the stack and try to
send it to the default DNS address. While present on the
MANET the operating system can set the default DNS address
to a pre-defined broadcast or multicast address, i.e. the
aforementioned NAME-RESOLUTION-ADDRESS. Then the
routing module can easily catch the DNS requests that are sent
down the stack from the Name Resolver, translate the request
into an NREQ extension, and flood it throughout the MANET
(Figure 3).
Figure 3. A DNS Request from the MANET-unaware Name Resolver (NR) is
caught by the routing module and translated into a Name Resolution Request
(NREQ). The NREQ, carried by a Route Request (RREQ), is being flooded
throughout the network. Intermediate routers with a MANET-unaware Name
Server (NS) process running translate the request into a DNS query, which is
sent up the stack to the Name Server (NS) process.
Similarly, an intermediate node that implements a MANETunaware Name Server process translates received NREQs into
DNS requests that are sent up the stack to the Name Server
process. Simultaneously, the NREQ is passed on to neighboring
nodes and flooded further throughout the network (Figure 3).
If a Name Server process has a valid mapping for the
requested name and wants to respond to a NREQ, it sends a
DNS Reply packet down the stack. The routing module
translates the reply into an NREP packet, wraps it into an RREP
header, and unicasts the resulting packet back to the originator
of the NREQ. The originator finally pushes the packet up the
stack as a DNS reply (Figure 4).
Figure 4. A DNS Reply from the Name Server (NS) process is caught by the
routing module and translated into a Name Resolution Reply (NREP). A Route
Request (RREP) carries the NREP, which is unicasted back to the originator of
the request. The originator 's routing module translates the request into a DNS
query, which is sent up the stack to the Name Resolver (NR).
A requirement for this solution is that the message format of
a NREQ and a NREP can easily be translated into a DNS
Request and a DNS Reply, respectively.
On the other hand, the name resolution software may
alternatively be aware that the node is currently located on a
MANET. In this case, the Name Resolver can translate requests
from the API directly into a NREQ message carried by a RREQ
message and ensure that this gets flooded on the network (Figure
5). Similarly, if a Name Server process is MANET aware, it may
receive the NREQ directly from the routing module and respond
with an appropriate NREP (Figure 5).
Figure 5. If the Name Resolver (NR) is aware that it is currently located on a
MANET router, it may catch a name resolution request from the API and
translate it directly into a Name Resolution Request (NREQ). Similarly, if a
Name Server (NS) process is MANET-aware, it may receive the NREQ directly
from the routing module and respond with an appropriate NREP (2).
IV. RESOLUTION OVER EXTERNAL NETWORKS
A. Integrating local name resolution with external DNS
Some MANET nodes may also be a router or a host on an
external IP network, and may provide other MANET nodes with
access to the external network. Such a node is hereafter referred
to as an Internet Gateway.
When MANET nodes have access to external IP networks,
resolution of names of only those nodes residing locally on the
MANET is not sufficient. In addition, a method for name
resolution on external networks is required to enable users to use
their common applications for external communication as well.
It should be clear from the above analysis that name
resolution over external networks should also be carried over
RREQ and RREP messages. When the NREQ reaches the
Internet Gateway a return route is already in place, and when a
NREP is returned from the Internet Gateway to the originator of
the NREQ, a route for subsequent communication out over the
Internet Gateway is also set up.
A node that has been assigned a Fully Qualified Domain
Name (FQDN) from the globally unique DNS name space may
enter the MANET at any time. In an on-demand MANET this
node will not advertise its appearance on the MANET. Thus,
other MANET nodes cannot be expected to know in advance
whether this node is present on the MANET or only reachable
through the external network.
The easiest way to deal efficiently with this uncertainty is to
integrate local name resolution on the MANET with name
resolution over external networks. This means that the NREQ
message should be able to trigger replies both from local
MANET nodes and from Internet Gateways. Otherwise,
MANET nodes would first have to broadcast a NREQ for a
name locally, and if the name were not resolved, another
broadcast would be required to resolve the name over Internet
Gateways to external networks. Combining the scheme means
that only one broadcast is required.
Since the Internet Gateway normally will have access to a
conventional DNS server over the external IP network (like
most Internet hosts have today), it will usually be able to assist
in name resolution. When an Internet Gateway receives a NREQ
from the MANET, it should therefore try to resolve the
requested name by a conventional DNS server through the
external IP network to which it is connected (i.e. using the
Domain Name System on the Internet). A successful response
may then be injected into the MANET as a Name Resolution
Reply (NREP) containing the resolved IP address(es), and the
NREP will be routed back to the originator of the RREQ. Figure
6 illustrates how MANET Name Resolution may interoperate
with the DNS system.
A requirement for this solution is the same as above: It
should be easy to translate the message format of a NREQ and a
NREP into a DNS Request and a DNS Reply, respectively.
Figure 6. An Internet Gateway, which receives a Name Resolution Request
(NREQ) on the MANET (1), may try to resolve the requested name using the
Domain Name System on the Internet (2). A successful response (3) may be
injected as a Name Resolution Reply (NREP) into the MANET (4).
Since the proposed mechanism for name resolution is ondemand, the Internet Gateway can easily make all the names in
the DNS on the Internet available to MANET nodes. The
number of names that are made available by an on-demand
name resolution protocol does not consume additional
bandwidth on the MANET. Only names that are resolved do.
If DNS resolved the name into a number of IP addresses,
the Internet Gateway should prioritize to return IP addresses that
it assumes is present locally at the MANET (e.g. if the gateway
has cached a valid route to the IP-address). Otherwise, the
gateway may return the IP-address(es) with the highest priority
(if a priority or precedence can be derived). Before returning an
IP address in a NREP, the Internet Gateway may even try to
'ping' an IP-address to ensure that an address is active over the
external network.
Amongst a number of IP addresses with the same priority,
the Internet Gateway may furthermore select one address at
random. This means that if there are several gateways
responding to the same NREQ, the node originating the NREQ
is likely to receive a number of different resolved IP-addresses.
Alternatively, the NREP format can be specified to allow for a
set of IP addresses being returned to the originator, and let the
node that originated the NREQ select the address.
The presented mechanism for name resolution on MANETs
does not hinder a node to also acquire an IP-address of a
conventional DNS server on an external IP network by some
means. This node may try to resolve a name on this server if
name resolution locally on the MANET fails. This option can be
utilized as a last resort in scenarios where the Internet Gateways
for some reason are not able to operate as DNS proxies.
However, many nodes might not have straightforward access to
an external network, and may therefore not be able to take
advantage of this option. It is thus assumed that relying on the
DNS-proxy mechanism of the Internet Gateways will be
sufficient in most scenarios.
B. Response selection
If the Internet Gateway is unaware that a node identified
with a name in a NREQ is present on the MANET, it will
resolve a name on the external network and return the result in a
NREP message. At the same time, the node identified with the
name (i.e. the Name Owner) may respond to the NREQ in a
separate message (Figure 7). Hence, the proposed scheme
resembles multicast DNS [7] in that an originator of a NREQ
might receive a number of NREPs from different responders,
both from different Internet Gateways and from other MANET
nodes. The originator of an NREQ should therefore wait for a
certain time interval to collect all responses that might arrive.
Furthermore, a procedure for handling multiple responses
and selecting a resolved IP address is also required:
1.
First, the receiver of multiple NREPs should prioritize a
NREP that is sent directly from the owner of the name (if
this can be concluded from the RREP header and the
NREP extension). This ensures that NREPs sent directly
from the owner of a name, have preference over NREPs
based on cached information sent by other nodes. That is,
first-hand information should have preference over
second-hand information on the dynamic MANET.
2.
Secondly, the receiver of multiple NREPs should
prioritize resolved IP-addresses to which it has a
preferred route (e.g. the freshest route or the shortest
route). Which route is preferred depends on the metrics
of the reactive routing protocol.
3.
Finally, if the originator of an NREQ receives a resolved
IP-address from both the external DNS system and from
information cached locally, it should prioritize responses
arriving from the local MANET. This means that a direct
route through the MANET will have preference compared
to a route that goes through external networks. It should
also be noted that a local response might also be more
reliable since the owner of the resolved name might not
have had a chance to update its DNS server (e.g. by using
secure dynamic DNS updates [11]) after having entered
the MANET.
C. Distinguishing between locally and externally resolved IP
addresses
To realize the third response selection rule above, receivers
of NREPs need a means to distinguish IP addresses resolved
locally from those resolved over external networks. To
distinguish, the Internet Gateway should have a way to mark
NREPs as Resolved over an External Network (Figure 7). A bit
in the NREP message can be reserved for this purpose, or an
additional Internet Gateway Reply Extension can be specified.
The Internet Gateway should only mark NREPs if it can
assume that the resolved IP address is not present locally on the
MANET (e.g. it has not cached a valid route to the resolved IP
address). When the mark is present in the NREP, the receiver
knows that the owner of the resolved IP-address is not assumed
to be present on the MANET: It was resolved over an external
IP network, and the originator of the NREQ will probably need
connectivity to the external network to be able to contact the
resolved IP address.
timeframe. This mechanism allows for some RREPs being lost
in the network while unnecessary duplicate responses are being
suppressed.
Figure 7. A Name Server (NS) process with the requested name-to-address
mapping returns an NREP containing the resolved IP address of a node that is
present on the MANET. Simultaneously, the Internet Gateway (GW) returns an
IP address resolved over the external IP network, because it is not aware that an
owner of the name is present on the MANET. It marks the NREP message so
that the recipient knows that the IP address was resolved over an external
network.
It is a good principle that a node contacts an IP address over
the same Internet Gateway that resolved the address, if this is
possible. Hence, when a NREP contains an externally resolved
IP address, the receiver should store the MANET IP address of
the Internet Gateway that sent the NREP. This address might be
useful for subsequent communication over the Internet Gateway.
D. Duplicate Response Suppression
A node that has responded to a NREQ, might receive a new
NREQ for the same name and from the same originator several
times in a row. The reason might be that the first NREP message
got lost, and never reached the originator. Hence, the responder
will have to respond to a NREQ again to ensure that the
originator receives the reply.
However, the reason for receiving the same NREQ over and
over again might also be that the originator is not satisfied with
the response. If the originator for example receives a DNS
mapping for an IP address on external networks, but has no
means to ensure global connectivity, the response might not be
very useful, and the originator might continue the expanded ring
search for a local response. In such cases, a responder should not
be allowed to respond to each NREQ issued.
Therefore, a duplicate response suppression technique is
required. An easy scheme could be as follows: The responder is
not allowed to respond to the same name resolution request
(originating from the same IP source address) more than a given
(pre-defined) number of times within a given (pre-defined)
E. Binding to a resolved IP address
When a MANET node has resolved a name to an IPaddress, it might want to contact (or 'bind to') the node of the
resolved address. In some cases, the node has established a valid
route to the resolved IP address as part of the name resolution
process, and packets can be unicasted to the resolved IP address
directly.
However, in cases where the node has not established a
valid route to the resolved IP address (e.g. if the IP address was
resolved over an external IP network) the node will first have to
try to discover a route to the IP address locally on the MANET
by flooding a RREQ.
If a direct route to the resolved IP address is not discovered,
and the resolved IP address was discovered over an external IP
network, the node should finally attempt to contact the resolved
IP address over the Internet Gateway that resolved the address.
In the latter case, the node will have to acquire a globally
routable IP address from the Internet Gateway so that return
packets from the resolved IP address on the Internet will be
received by the gateway. The gateway will have to inject the
packets into the MANET and ensure that they get routed to the
right recipient.
The node will also need a way to get outgoing packets sent
out of the MANET. The MANET node may for example tunnel
or source-route such packets out of the domain via the Internet
Gateway. Otherwise, some routing protocols allow Internet
Gateway to inject default routes into the domain. Different
proposals for how a MANET node can obtain global Internet
connectivity can be found in [12] and [13].
V. PARTIALLY CENTRALIZED VS FULLYDISTRIBUTED APPROACH
A. Partially Centralized Name Coordinators
The proposed name resolution mechanism does not mandate
where name-to-address mappings are stored in the network. In
the partially centralized approach to name resolution, a number
of centralized Name Coordinators are located on a share of the
nodes in the MANET. They cache name-to-address mappings of
names on surrounding nodes that do not implement a Name
Server process. In the fully distributed approach to name
resolution, on the contrary, no centralized Name Coordinator is
necessary, since each node that wants to make its name
discoverable runs a Name Server process. A hybrid approach is
also possible in which fully distributed name server processes
co-exist with some centralized name servers/coordinators on the
MANET.
With the partially distributed approach, a Name Owner (i.e.
a MANET node that wants to make its name discoverable by
other MANET nodes) must first find a Name Coordinator in its
surroundings and register with it. Hence, with this approach
name resolution comprises three phases; Registration, Find and
Bind (Figure 8):
1.
2.
3.
Registration (Find NC and Register): A Name Owner that
wants to make its name discoverable, must first find a Name
Coordinator (NC) on any of its surrounding nodes. The
Name Owner must subsequently register with at least one of
its surrounding Name Coordinators.
Find: It is a pre-requisite that a Name Resolver runs on
each node that needs to discover a name, i.e. on each Name
Requestor. The Name Resolver may search for a name by
flooding a NREQ. Each Name Coordinator must run a
Name Server process, which may respond by unicasting a
NREP back to the Name Resolver if it has cached the
requested name-to-address mapping.
Bind: Finally, the Name Requestor node may attempt to
bind to the Name Owner, by addressing it with the resolved
IP address.
Figure 8. With the partially centralized approach, a Name Owner will first have
to find a Name Coordinator (NC) and register with it (1). When a Name
Requestor node tries to find a Name Owner (by issuing an NREQ), the Name
Coordinator responds (with a NREP) on behalf of a targeted Name Owner (2).
Finally, the Name Requestor might possibly bind to the Name Owner, using the
resolved IP address returned from the Name Coordinator (3).
A problem with using a centralized Name Coordinator is
that the Name Requestor node will not have a direct route to the
resolved IP address as a result of the name resolution process
when the Name Owner is located somewhere in the Name
Coordinator's surroundings. It would have to broadcast an
additional RREQ to discover a direct route to the resolved IP
address.
A way to circumvent this problem would be to require that
valid routes be maintained between the Name Coordinator and
the surrounding nodes of which the Coordinator stores a nameto-address mapping. Then, the returned RREP header that wraps
the NREP extension provides a route to the resolved IP address.
A disadvantage of this solution is that all routes that the
Name Coordinator provides to different Name Requestors go via
the Coordinator. This is not necessarily an optimal route
between source and destination, and the Name Coordinator will
easily become a bottleneck for communication.
Another disadvantage of this solution is that maintenance of
routes between Name Coordinators and surrounding nodes
consumes bandwidth, even for surrounding nodes that do not
communicate. This proactive route maintenance goes bad
together with scenarios that call for a pure reactive solution to
routing. In fact, it would transform the MANET from being a
pure reactively routed network to a hybrid-routed MANET,
where the name resolution mechanism would contribute with the
proactive routing element.
A second problem with centralized Name Coordinators is
that nodes may move around and enter and leave the MANET in
a non-deterministic way. The Name Coordinator and
surrounding nodes therefore need to synchronize. First, the
Name Coordinator wants to avoid to store stale information, so
that it will not resolve a name of a node that is no longer present
on the MANET. Secondly, the Name Coordinator wants to make
names available as soon as a new Name Owner appears in its
surroundings. Such synchronization will consume additional
bandwidth on the MANET.
A third problem with centralized Name Coordinators is that
it increases complexity. First of all, a mechanism is required for
Name Owners to find a Name Coordinator in its surrounding.
The easiest solution would be to extend the presented scheme
for name resolution, to also accommodate Service Name
resolution, parallel to DNS SRV lookups [14]. Hence, a separate
NREQ extension would be defined to trigger service name
resolution, and a corresponding NREP would be defined to
allow for a service name to be resolved to an IP address and a
port number. By implementing the naming scheme proposed for
Multicast DNS [7], a Name Owner could for example search for
a service called '_namecoordinator._udp.local.'. A Name
Coordinator would resolve the request into its own IP address
and a port number that the Name Owner can use to register its
name with the Coordinator.
However, even with this fix, the complexity would still be
high, because surrounding nodes would require a means to
register names with the centralized Name Coordinators. Hence,
each Name Owner node must run a Registration Client (RC),
while each Name Coordinator must run a corresponding
Registration Server (RS) (Figure 9).
Figure 9. With the partially centralized approach, a Name Owner must use a
Registration Client (RC) to first register its name with the Registration Server
(RS) on the Name Coordinator (1). When a Name Requestor issues a Resource
discovery request (2) the Name Server process on the Name Coordinator
responds with a NREP (3) on behalf of the targeted Name Owner.
A third element that also might increase complexity is a
mechanism for Name Coordinator election. Such a mechanisms
would be required in most cases where it is not pre-determined
which nodes should take on the task of being a Name
Coordinator.
B. Fully distributed Name Server processes
An alternative to the partially centralized approach is the
fully distributed approach. In this case, each node with a
discoverable name runs its own Name Server process. The
Name Owner does not need to synchronize with any
surrounding nodes, and no registration with any external Name
Coordinator is required. Hence, with this approach the name
resolution process is reduced to a Find phase, possibly followed
by a Bind phase (Figure 10).
Figure 10. With the fully distributed approach, name resolution comprises only a
Find phase, possibly followed by a Bind phase. The Name Owner does not need
to find and register with external Name Coordinators.
According to the aforementioned framework, a fully
distributed approach to name resolution is normally more
bandwidth efficient than using partially centralized Name
Coordinators [3]. The reason is that after a name resolution is
completed, the Name Requestor is likely to bind to the resolved
IP address of the Name Owner. If the responding Name Server
process is located on the Name Owner's node, a direct route is
already in place for subsequent unicast communication between
the two.
Since a Name Owner responds to NREQs requesting an IPaddress for its own name, the Name Owner does not have to run
additional software that enables it to find Name Coordinators on
surrounding nodes and register with it/them. As a result we
derive a considerably simpler name resolution infrastructure, as
was illustrated in Figure 5. Finally, a Name owner does not
need to consume network bandwidth by continuously
synchronizing with a Name Coordinator.
C. Hybrid approach: With selected centralized servers
Some researchers claim that partially distributed service
coordinators might increase service availability [15]. However,
according to the above analyses the advantages of centralized
coordinators might not apply to name resolution.
In some cases, however, a centralized name server might be
beneficial. For example, in a scenario where an Internet
Gateway has a fixed interface towards the external network (i.e.
it does not roam) and where it is probable to remain in the role
of an Internet Gateway over a longer period of time, it might be
beneficial to implement a DNS server on the Internet Gateway.
D. Hybrid Approach: With caching on intermediate nodes
A milder form of storing name-to-address mappings on
behalf of other nodes is to allow caching on intermediate nodes
that forwards NREPs. Each intermediate node that runs a Name
Server process to make its own name discoverable also has the
opportunity to cache name-to-address mappings appearing in
NREP messages that are forwarded by the node. If the formats
of the NREP extensions contain both the resolved IP address and
the requested name, as proposed above, intermediate nodes can
easily cache the mappings.
If receiving an NREQ message for which it has cached a
mapping and a valid route to the resolved IP address, the
intermediate node might return a NREP message to the source
node containing the resolved IP address.
Furthermore, if an Internet Gateway receives an NREP for
which it has cached a valid mapping for a node on the MANET,
it should return an NREP directly without attempting to resolve
the name over the external IP network. This ensures that local
communication within the MANET has preference over
communication over external IP networks.
Intermediate node caching might improve the name
resolution process without adding additional complexity. No
synchronization between the Name Owner and the intermediate
node is required, and no additional software is required. With
such caching, however, a node originating a NREQ might get an
unnecessary large number of NREPs in return from different
intermediate nodes that have cached the same name-to-address
mapping. On the other hand, since many reactive routing
protocols let routes time out quickly, the effects of caching
might be limited if intermediate nodes are only allowed to
resolve name into IP-addresses to which they have valid routes.
Whether intermediate node caching is beneficial or leads to
unnecessary high bandwidth consumption and high complexity
is an issue open for further investigation.
VI. CONCLUDING REMARKS
A. Summary
This paper details the framework for name resolution
presented in [3]. It illustrates how name resolution messages
should be sent efficiently on the MANET. It also describes
different ways to implement name resolution to keep the name
resolution mechanisms transparent to the user applications (and
to the traditional name resolver, if this is required).
Furthermore, we proposed to integrate local name resolution
with DNS resolution over external IP networks. The Internet
Gateway is used as a name resolution proxy, which translates
local name resolution requests into DNS queries and translates
the DNS replies back to local name resolution replies. It also
marks such replies, so that the recipient will be able to
distinguish IP-addresses that have been resolved over external IP
networks, from those that have been resolved locally.
Although Internet Gateways act as name resolution proxies,
they may also return an IP address of a DNS server on the
external IP network. However, the name-resolving MANET
node might have to go through cumbersome steps to acquire
global connectivity before it can utilize such external IP
addresses.
A node resolving a name might receive a number of replies.
The proposed response selection rules prioritize communication
within the MANET before communication over external
networks. Furthermore, first hand information should have
preference over older second-hand information. Finally, a
response with a better route to the resolved IP address should be
preferred.
It was also pointed out that the Name Server process
(daemon) might need to implement a mechanism for duplicate
response suppression. A mechanism that suppresses unnecessary
many replies, but also allows some replies to be lost in the
MANET, was proposed.
Finally, we presented different strategies for storing nameto-address mappings in the network. In the partially centralized
approach a share of the MANET nodes implement name
coordinator modules that cache name-to-address mappings for
other surrounding nodes. In the fully distributed approach, on
the other hand, each node with a discoverable name runs its own
Name Server process. We showed that the partially centralized
approach has a large number of disadvantages compared to the
fully distributed approach.
The message formats of the extensions proposed in this
document have been presented in a separate Internet-Draft [10]
and submitted as a by-product of this document to the Internet
Engineering Task Force (IETF).
B. Further work
The proposed mechanism for name resolution can easily be
extended to reverse address-to-name resolution, parallel to what
can be done with DNS.
As indicated above, it can also easily be extended to simple
service discovery, similar to the use of DNS SRV records [11].
This will allow a MANET node to resolve a generic service
name to an IP-address and the transport protocol port number
that should be used to initiate the service. The transport protocol
name is normally encoded into the generic service name [11].
This DNS-based mechanism for service discovery would
complement the service discovery mechanism for on-demand
MANETS, proposed in [8], which is based on the Service
Location Protocol version 2 [9].
Further research is required to evaluate the trade-offs
between different strategies for storing name-to-address
information in the network. Whether a partially centralized, fully
distributed or hybrid approach to name resolution is preferred, is
still an open issue. A useful enhancement of the fully distributed
approach might be to allow each intermediate node that
implements a Name Server process to cache name-to-address
mappings appearing in NREPs that it is forwarding. However,
further research into this issue is also required.
REFERENCES
[ 1 ] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034,
Internet Engineering Task Force (IETF), November 1987.
[ 2 ] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1034, Internet Engineering Task Force (IETF), November 1987,
[ 3 ] Engelstad, P.E, Thanh, D.V., Jønvik, T.E., "Name Resolution in Mobile
Ad-hoc Networks". To appear in Proceedings of 10th International
Conference on Telecommunication, ICT'2003. In press. (Submitted July
2002.)
[ 4 ] Perkins, C.E., Royer, E.M., and Das, S.R., "Ad-hoc On Demand Distance
Vector (AODV) Routing", IETF Internet draft, draft-ietf-MANET-aodv10.txt, March 2002 (Work in Progress).
[ 5 ] Johnson, D.B., Maltz, D.A., Hu, Y.-C. and Jetcheva, J.G., "The Dynamic
Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", IETF
Internet draft. draft-ietf-manet-dsr-07.txt, February 2002 (Work in
Progress).
[ 6 ] Park, V.D., and Corson, S.M., "Temporally-Ordered Routing Algorithm
(TORA) version 1: Functional Specification", IETF Internet Draft,
November 2000 (Work in progress).
[ 7 ] Cheshire, S., "Performing DNS queries via IP Multicast", IETF Internet
Draft, draft-cheshire-dnsext-multicastdns-01.txt, December 2002 (Work in
Progress).
[ 8 ] Koodli, R., and Perkins, C.E., "Service Discovery in On Demand Ad Hoc
Networks", IETF Internet draft, draft-koodli-manet-servicediscovery00.txt, October 2002 (Work in Progress).
[ 9 ] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location
Protocol, version 2", RFC 2608, Internet Engineering Task Force (IETF),
June 1999.
[ 1 0 ] Engelstad, P.E. and Egeland, G., "Name Resolution in On Demand
MANETs", IETF Internet draft, draft-engelstad-manet-name-resolution00.txt, February 2003 (Work in Progress).
[ 1 1 ] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update",
RFC 3007, Internet Engineering Task Force (IETF), November 2000.
[ 1 2 ] Royer et al., "Global connectivity for IPv4 Mobile Ad Hoc Networks",
IETF Internet draft, draft-royer-manet-globalv4-00.txt, November 2001
(Work in Progress).
[ 1 3 ] Wakikawa et al., "Global connectivity for IPv6 Mobile Ad Hoc Networks",
IETF Internet draft, draft-wakikawa-manet-globalv6-02.txt, November
2002 (Work in Progress).
[ 1 4 ] Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, Internet Engineering Task
Force (IETF), February 2000.
[ 1 5 ] Toh, C.-K., "Ad Hoc Mobile Wireless Networks. Protocols and Systems",
Prentice Hall PTR, New Jersey, 2002, pp. 231-242.