Name Resolution in On-Demand MANETs and over External IP Networks

Transcription

1 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, e- mail, 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. 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

2 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. 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.)

3 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

4 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.

5 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.

6 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 FULLY- DISTRIBUTED 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

7 surroundings and register with it. Hence, with this approach name resolution comprises three phases; Registration, Find and Bind (Figure 8): 1. 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. 2. 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. 3. 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

8 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

9 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 [ 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-aodv- 10.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-servicediscovery- 00.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 [10] Engelstad, P.E. and Egeland, G., "Name Resolution in On Demand MANETs", IETF Internet draft, draft-engelstad-manet-name-resolution- 00.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 [ 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). [13] 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). [ 14] 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 [15] Toh, C.-K., "Ad Hoc Mobile Wireless Networks. Protocols and Systems", Prentice Hall PTR, New Jersey, 2002, pp