Ad-Hoc routing taxonomy and Resource Discovery

(1)

Jose Costa-Requena

Helsinki University of Technology Networking Laboratory

Jose@netlab.hut.fi

Abstract

This paper analyzes the recent development regarding the technology in ad-hoc networks. It compares the different routing protocols and analyses them from architecture design perspective. The comparison includes technical aspects, similarities and missing functionality on each of the protocols. The paper identifies the network resource discovery as missing functionality, and presents a generic proposal for implementing a resource discovery and auto-configuration mechanism in Ad Hoc networks. The auto-configuration proposal aims to fulfil the requirements of locating network services and resources that are required to perform some routing algorithms. This approach is presented and contrasted with various existing solutions.

Keywords:Ad Hoc, Network Resources, Service Discovery and Auto-Configuration.

1 Introduction

Ad Hoc networks are emerging as the next generation of networks. The strength of Ad Hoc networks reside in the diversity of computer networking and the growth of wireless over IP that patches the Internet together. Nowadays, the bandwidth available is larger and people are getting used to have easy Internet access no matter their location. Ad Hoc networks are seen as the potential market for embedded network devices in multiple environments such as vehicles, mobile telephones and personal appliances. They are considered the infrastructure-less that will allow the users to create their Personal Area Networks (PAN). Thus, the embedded networking is envisioned as the next generation of networks.

Nevertheless, Ad Hoc networks present some novel and unusual challenges that have not been primary concerns in network deployments until now. People are used to have reliable network communications and a set of networking applications. Therefore, mobile computers and applications will become indispensable and requested at any time and place, even where the appropriate infrastructures are not available. In this kind of environments, wireless devices will have to learn how to communicate without routers, base stations or service providers. The wireless devices should perform their own network topology functions keeping track of the connection between nodes and performing routing functionality.

The link state information in an Ad Hoc network changes whenever the users move, and the nodes must be able to provide automatic topology establishment and dynamic topology maintenance. Furthermore, these networks will be self-established without previous knowledge and all the nodes need to be able to carry diverse types of data. In

(2)

http://www.tml.hut.fi/Studies/T-110.557/2002/papers

this sense, the Ad Hoc nodes need to be self-contained and have their own device or resource discovery and control paradigms.

The nodes must have a set of mechanisms allowing the device to be automatically integrated and configured as part of the Ad Hoc network.

The drawback in the Ad Hoc concept is that the nodes have to configure themselves as part of the network. It cannot be assumed that there is a fixed address or server that can inform the node about the services available in the Ad Hoc network. Therefore, each node should contain a mechanism that after joining the Ad Hoc network allows it to discover the network capabilities and configure itself to the services available. This paper analyses the different routing protocols in Ad Hoc networks for evaluating them in terms of performance from low to large scale. Afterwards, the paper describes briefly the different mechanisms available for services or network resources discovery, and their advantages and inconveniences when dealing with Ad Hoc networks.

The paper is structured as follows. Section 2, presents the best practice in the design of new protocols as part of the overall IP architecture. These design rules consider the importance of the Complexity, Overhead, Resilience, Performance and Security (CORPS) when designing a protocol as part of an IP based architecture. Section 3 provides an overview of the Ad Hoc networks arena and the current routing protocols that can be used to build an Ad Hoc network (Ad Hoc On-demand Distance Vector, AODV [1], Dynamic Source Routing, DSR [2], Temporally Ordered Routing Algorithm, TORA [3], Optimal Link State Routing, OLSR [4], Zone Routing Protocol, ZRP [5] Location based routing protocols [6]). After analysing the existing routing algorithms, section 3 presents an overall evaluation to identify the main constrains and the missing functionalities. The section 4 includes the configuration paradigm in Ad Hoc environments, and analyses the requirements and constrains for any configuration mechanism in an Ad Hoc node. This section also presents gives an overview of the existing solutions proposed for service discovery and configuration in Ad Hoc networks. Finally, section 5 proposes a novel approach to overcome the resource discovery and auto-configuration problem within diversity networking like in Ad Hoc networks. Finally, section 6 outlines some conclusions.

2 Best practice in architecture design

The Internet Advisory Board has proposed a set of recommendations when designing and proposing new architectures or protocols within the overall Internet architecture. The motivation is due to a lack of coherence in the growing Internet. The new Internet design is moving "from a world of a single, coherent architecture designed by a small group of people, to a world of a complex, intricate architecture to address a wide-spread and heterogeneous environment" [21]. The Internet is growing as an agglutination of individual pieces of the architecture designed by sub-communities without paying attention to how each piece fits into the larger picture.

The basic guideline is that "it is also generally felt that end-to-end functions can best be realized by end-to-end protocols." Another design guideline [22] is that "heterogeneity is inevitable and must be supported by design." This means that a new design should be able

(3)

The Ad Hoc networks are a new architecture that requires applying these design questions.

Firstly, it has to be justified the proposed solution. In this case it has to be analysed the existing protocols defined for resource discovery and indicate why they are not suitable.

Section 5, presents the actual routing algorithms proposed for Ad Hoc networks. That section gives an overall description of the existing routing protocols, their pros and cons.

Section 6, presents the existing solutions designed for service discovery and a light summary of their functionality. In section 7, it is presented the proposed solution based on the overall picture on this problem starting at routing problem and going up to the application layer where the existing service discovery protocols are implemented.

The proposed approach is based on having a resource discovery mechanism that is tight to the routing protocol but the management and semantics of the protocol are handled at upper layer. In the proposed mechanism, the routing protocol should provide the basic tools such as service entity discovery and also the means for finding the location of that entity within the Ad Hoc network. This mechanism should reside as part of the Ad Hoc routing protocol. Moreover, the services negotiation and agreement would reside in the application layer, according to the actual design in similar service discovery protocols.

Therefore, the next step in the design of the suitable solution is to be identified the interactions between layers. The reason for proposing this interlayer approach consists of having the benefits for route discovery designed at the routing layer also for resource discovery. The actual solutions define a purely application layer based solution but in Ad Hoc networks this would have high performance costs. This approach is envisioned correct in terms of function, data integrity, ease of deployment, the diagnosis of failures, and mainly in performance.

In addition to these two steps it has to be checked the validity of the proposed design when considering long-term versus short-term solutions. This approach is considered as long-term solution for Ad Hoc networks that utilize specific routing protocol for route discovery and they embed the resource discovery as part of the same functionality. This approach does not restrict the evolvability of Internet and Ad Hoc networks since it does not impose any restrictions on future development. It is seen as set of building blocks but with a large context where the routing layer includes a mechanism to enable other service discovery protocols at upper layers.

This solution provides higher robustness to the resource discovery process within Ad Hoc networks. Since the same mechanism used for guarantee the routing across the Ad Hoc nodes is used, it provides a robust mechanism for resource discovery, not just overcoming to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations. This approach takes into account the realistic conditions of the Ad Hoc networks (e.g., packet drops and packet corruption; packet reordering;

asymmetric routing; etc).

Therefore, the proposed solution fulfils the IAB recommendations for a new Internet protocol design. The rest of the paper analyses the two layers involved in the new architecture and the existing protocols. The last part of the paper presents the proposed architecture.

(4)

3. Ad Hoc networks

The Ad Hoc network is defined as an autonomous system of mobile nodes connected by wireless links and their union forms an arbitrary and variable graph. The Ad Hoc networking has to support robust and efficient operation in mobile wireless networks. For that reason, the nodes of the network should incorporate routing functionality, auto- configuration features, and a mechanism to self organise the Ad Hoc network. The Ad Hoc nodes are free to move randomly and organise themselves arbitrarily. Thus, the network topology may change rapidly and unpredictably. Therefore, the Ad Hoc network should be able to operate either in a standalone fashion with no fixed infrastructure, or connected e.g. to the Internet.

The first part of this section describes the routing protocols proposed for implementing Ad Hoc networks. The aim is to analyse the existing protocols and collect performance information terms of reliability, fail tolerance, and robustness.

3.1 Routing Algorithms

The routing protocols can be classified in proactive (OSLR), reactive (AODV) [1] and certain proposal for hybrid solutions. The reactive protocols are based in "On demand"

basis, meaning that when the nodes require communicating with another entity the protocol initiate a route discovery mechanism. This is simple and with lower computational requirements but it requires having a set of big amount of broadcast messages when requesting new routs. The proactive protocols (OSLR) [4] are based on link state information, where each node has the knowledge about the network topology.

This means that the node requires higher computational power and continuous update of the link state information, which in high dynamic environment the routes are obsolete after short period of time. The hybrid solutions (ZRP [5], Location based protocols) are taking advantages of both mechanism and it is using one solution in certain space and the other for the rest. Still there is not clear view of the suitable mechanism for defining the border and decide where to use reactive or where to use proactive algorithms.

3.1.2 AODV

On-Demand routing protocol is an improvement on DSDV because it typically minimizes the number of broadcasts by creating routes on an on-demand basis. In simulations AODV has shown very good performance in highly mobile networks, provided that link breakage detection is performed using lower layers such as MAC to detect transmission errors. This protocol scales well and can be used in small, medium and large networks.

3.1.3 OSLR

The Optimised Link State Routing Protocol (OLSR) is developed for mobile ad hoc networks. It is as a table driven and proactive protocol that exchanges topology information with other nodes of the network regularly. The nodes selected as a multipoint relay (MPR) announce this information periodically in their control messages. The protocol uses the MPRs to facilitate efficient flooding of control messages in the network.

The node is elected as MPR by all the neighbours and the MPRs are used to form the route from a given node to any destination in the network.

(5)

3.1.4 ZRP

ZRP is a hybrid of table-driven and On-Demand Protocol. It divides the network into several routing zones and specifies two totally detached protocols, Intrazone Routing protocol IZRP and Interzone Routing Protocol IERP, that operate inside and between the routing zones, respectively. IZRP can be any of the proactive (table-driven) protocols while IERP is reactive (On-Demand). ZRP is a hybrid protocol between proactive and reactive schemes and uses advantages from both. Routes can be found very fast within routing zone, while routes outside the zone can be found by on-demand methods between selected nodes in the network.

3.1.5 Comparative of Ad Hoc Protocols

The common denominator for all Ad Hoc routing protocols is that it is necessary to broadcast a set of control messages and flooding announcements in order to discover the path towards the destination node (reactive) or for creating the network topology (proactive).

This set of flooding messages creates a lot of traffic and collisions in the network just for control messages (Figure 1). Moreover, these messages decrease the resources on the nodes and distinguished their lifetime. These are the main reasons highlighted in simulations when selecting proactive versus reactive protocols. Thus, when considering medium to big Ad Hoc network it is required to consider a hybrid solution rather than having purely either reactive or proactive algorithm.

Figure 1. Simulation comparing multiple Ad Hoc protocols in terms of number of control packets and delay, depending on the network load.

This is one of the main reasons for re-using the route discovery in the routing protocols for resource or service discovery as well. This is also the reason for investigating a new hybrid solution and rather than considering alternative routing algorithms, the proposal is to define a new taxonomy of the Ad Hoc networks based on the nodes classification (dummy and smart nodes).

Therefore, as a result the proposed architecture will utilise the existing route discovery to embed the service discovery. In addition to that, it is proposed new node taxonomy for facilitating the interoperability among multiple proposals of routing protocols within Ad Hoc networks. Following sections evaluates the existing service discovery protocols to

(6)

support the idea of routing embedded mechanism. In section 7 is proposed the nodes taxonomy for supporting the utilisation of multiple routing algorithms and promote the co-operation model for Ad Hoc networks.

4. Resource discovery in Ad Hoc Networks

This section presents the different protocols available in various technologies to perform the configuration and service discovery mechanism. Different proposals and the similarities in terms of elements involved during the service discovery and negotiation are described. Nevertheless, despite they are using similar elements and terminology, each protocol has different architecture and they provide different functionality. Therefore, all the available protocols are briefly depicted and the overall functionality is presented.

Ad Hoc networks were originally meant to be an easy and an efficient mechanism for setting networks infrastructure with no support. There are different proposals to overcome the auto-configuration problem for Ad Hoc networks. This section presents and evaluates some of them (JINI, UPnP, Salutation, SLP, etc).

4.6 Jini™ network technology

A Jini [12] is a distributed system based on the idea of defining the resources and identifying the groups of users that require those users. The overall goal is to facilitate the location of the resources within the network. Thee resources can be considered as hardware devices, software programs, etc. The JINI system is based on Java application environment that enables a distributed environment for sharing code and data among multiple machines. The result is a system in which the network facilitates an easy configuration of objects, and resources that move across the network.

The JINI technology provides the infrastructure for devices, services, and users to be incorporated into the network and detach from it in a smoothness manner. These assumptions rely on a good speed connection among network devices and a reasonable latency all over the network.

The main concept in the JINI technology resides in the fact that a service is considered as an entity (i.e. a person, a program, or another service, storage or a communication channel). Those services are found using a lookup mechanism and they user a service protocol for communicating with each other. This service protocol is implemented as a set of interfaces written in Java programming language.

The lookup mechanism maps the interfaces that provide the service functionality with the objects that implement the service itself. The lookup mechanism contains a couple of protocols ("discovery" and "join") for adding any new service to the lookup service.

All these services communicate using Java Remote Method Invocation (RMI), which is a traditional remote procedure call (RPC) mechanisms..

(7)

4.6.1 Jini technology drawbacks

This alternative has some drawbacks. The Code mobility (JINI) appears as an efficient solution for supporting information retrieval. The problem is that in an environment in which bandwidth is a scarce resource and users' mobility makes continuous communication, the code mobility is very complex (if not impossible). Furthermore, the nodes should be designed to define in such a way that the peers accept the others’ code.

Since code mobility gives to the users the access to other machines, security is a concern and the literature hardly addresses the security of Ad Hoc networks.

Figure 2. Service lookup process with Jini.

4.7 The Universal Plug and Play (UPnP)

The Universal Plug and Play Forum [6] is an industry initiative for enabling multivendor connectivity among wireless devices, intelligent appliances and PCs. The objective is to define and publish UPnP device and service descriptions, and the members of the UPnP Forum can create the means to easily connect devices and simplify the implementation of networks.

UPnP architecture consists of a TCP/IP communications channel and Web services that are used for transferring data among the multiple devices. These devices describe their capabilities and features when they join the network using the UPnP protocols (device addressing, device discovery, device description, action invocation, event messaging and presentation or human interface). Therefore, when other devices join the network can receive the description of existing devices and they can use them without a complex configuration.

(8)

4.8 The Salutation protocol

Figure 1, shows the overall architecture in Salutation protocol [14]. The server [left] uses the Salutation discovery protocol to ask other devices on its network about their capabilities. The inquiry passes from the Salutation manager to a transport manager, which prepares the inquiry to run over the transport protocol used by the network. It makes its way over the network to, for example, the device-server combination [centre], which supplies the information, and also learns about the server. The device-server combination is also connected to a different device by a second network running a different transport protocol [right]. The centre combination needs two transport managers, one for each network protocol, but only one Salutation protocol.

Figure 3. Salutation architecture

The Salutation application interface allows software programs, such as e-mail or word processing applications, to interact with the Salutation protocol.

4.9 The Service Location Protocol (SLP)

The Service Location Protocol is an IETF protocol defined for service discovery. The Service Location Protocol (SLP) [15] provides a lightweight mechanism for service discovery within one administrative domain. In addition to the local domain, SLP can be used to discover desired services in specific remote DNS domains. The key issue for remote discovery in SLP is to enable a User Agent (UA) to learn about remote Directory Agents (DAs) or/and remote Service Agents (SAs) without relying on multicast.

The SLP is based in the knowledge of the SLP server where the clients can address the service request. Furthermore, the service provisioning has to register the service characteristics in the SLP server. Thus, when the client accesses the server will get all the service information in the Service reply.

(9)

Figure 4. Service lookup process in SLP.

5. Proposed Solution for Resource Discovery

After analysing the existing service discovery proposals it can be concluded that the existing service or resource location are concerned for the Internet, primarily for wired network with low latency, reliable links and enough bandwidth.

This section describes a new approach to overcome the resource discovery and auto- configuration dilemma in an elegant solution. The novelty resides in the concept of defining a "co-operative middleware and a basic nodes classification". Our solution provides a mechanism to implement a Self-Organised and Self-operated Networking infrastructure that applies to Ad Hoc networks.

The new peer-to-peer paradigm of mobile Ad Hoc networks allows the development of services without using any central server, but using communications among nodes. This approach introduces the co-operation as basis of the middleware services, in order to provide a collaborative environment to self-organise and configure the network capabilities to application layer.

This concept defines a "self-operated" network as a complement rather than a replacement of current and future centralised infrastructures. Moreover, discovery and auto-configuration, as well as individuals and resource naming and addressing will require special attention.

(10)

5.6 Requirements from Routing protocol

The proposed architecture needs a minimum set of requirements from the routing protocol. The location of the elements providing the network services is crucial to the establishment of the Ad Hoc network. During the network establishment it is involved various elements such as routing, addressing and processes like nodes discovery, network interoperability and mobility, service discovery, etc. The suitable routing protocol depends on specific network requirements and conditions and it influences on the network scalability. The same device can handle multiple interfaces and a generic addressing layer such as IP can link together the different Link Layer addresses.

Therefore, the appropriate routing protocol and addressing schema are the primary elements for the network establishment.

Afterwards, the Ad Hoc node should start finding out the existing resources and the elements that provide mobility and addressing translation (NAT [16], DHCP [17], DNS [18], SIP Registrar [19], etc). The node needs a service or resource discovery mechanism to find the server that can provide service information available in the network and the protocol to access that server. In fixed networks this does not harm since each of those elements have their own specific protocol port and broadcast address that can be used for discovery and access.

In the fixed networks this processes and functionalities are handled at different layers but the Ad Hoc concept requires a common infrastructure with enhanced cross layer communication. Thus, those processes can be separated in various modules at different layers while the functionality is embedded in the routing layer. Thus, the Ad Hoc networks require certain changes in the traditional networking concept where the traditional layering and modular structure is kept but an embedded and generic routing/mobility/network management is defined. The infrastructure proposed in this paper to handle the auto-configuration and resource discovery requires new attributes in the routing protocol. The arguments for this design approach are considered in section 2.

The first proposal is to classify the Ad Hoc according to simple criteria depending on their capabilities and willingness to contribute to the Ad Hoc community. This basic classification consists on having two types of nodes, "smart" and "dummy".

The concept consists on the fact that the information inserted in the routing messages is received and interpreted by any Ad Hoc node. The "dummy" nodes will use that information to find the appropriate servers or network entities. Nevertheless, the "smart"

nodes will use that information for negotiating the service provisioning within the Ad Hoc network. Thus the former nodes benefit from the information that the routing packets are carrying either for path or for network capabilities or resources discovery. Instead, the latter nodes (smart) are responsible of including that information in the routing messages.

The "smart" nodes can receive, interpret and update that information in the messages for announcing the network resources among all the Ad Hoc nodes. This approach requires a cross layer communication in the generic routing/network management module. The creation or motivation for the Ad Hoc network is generated at user level based on application requirements that need the Ad Hoc network to be established among group of collaborative nodes.

(11)

inform the "dummy" nodes about optimal paths. As an overall, the proposed framework is implemented including all the logical elements but actually it is performed in terms of an abstract functionality, where only "smart" nodes have fully resource and service discovery functions and the "dummy" nodes implement the reactive functionality.

The criteria for becoming a "smart" node (Figure 5) is based on the willingness of the node to benefit the Ad Hoc community. Firstly, the "smart" node should have enough resources to maintain its functionality. Secondly, the "smart" node should have a strong motivation to collaborate in the functioning of the Ad Hoc network despite scarce of resources. The motivation can be in terms of rewards that the node will get for providing the service to the community. Those rewards will be exchanged when the node needs similar service from other nodes. Thus a collaborative relationship is established for a common benefit.

Figure 5. Attach procedure of “smart” nodes into Ad Hoc network

5.6.1 Comparative with existing service discovery protocols

The existing solutions for service discovery are designed on top of reliable IP connections. Some of the presented protocols such as "Jini" require having high bandwidth and low latency. Other protocols require having a well-known IP address to contact the location services within the network. Therefore, in general the existing proposals for Service discovery are based on fixed networks with low latency and reliable connections. The proposed solution defines a new mechanism for service discovery embedded within the routing protocol. This mechanism is provided to the upper layer as

1) Broadcast TTL=1 (Query: Network capabilities

2) Unicast (Response: Dummy node, Network capabilities=1, Service node address)

2) Unicast (Announcement: Local service node capabilities, Network service nodes addr/srv)

3) Network configuration negotiation

4) Broadcast (Update: service node capabilities) 1)

1) 1)

2)

2) 4) 4) 4)

4)

4) 4)

4) 3)

1) Broadcast TTL=1 (Query: Network capabilities

2) Unicast (Response: Dummy node, Network capabilities=1, Service node address)

2) Unicast (Announcement: Local service node capabilities, Network service nodes addr/srv)

3) Network configuration negotiation

4) Broadcast (Update: service node capabilities) 1)

1) 1)

2)

2) 4) 4) 4)

4)

4) 4)

4) 3)

(12)

the reliable discovery tool, rather than using broadcast addresses to flood the Ad Hoc network with specific service discovery messages for each of the protocols implemented on the upper layers on every Ad Hoc node.

This approach can be already designed in table-driven protocols such as OLSR [4] or TBRPF by simply adding Service Reply extensions to the topology update routing protocol packets. In this way, service information can be made available immediately along with the information about which links are available for creating routes. In this case, the discovery operation is not separate from the operation of processing new topology update messages.

Thus, this could be implemented by defining the data format for the service identifiers or network resources identifiers to be embedded within the routing protocols.

5.6.1.1 Support for proposed architecture

The proposed approach considers embedding the resource discovery mechanism as part of the routing protocol and then implementing the service negotiation peer-to-peer at the application layer. Recently, a new draft for AODV [1] is proposing this type of enhancement for Service discovery. This would be the implementation of the proposed approach within AODV. It defines new routing messages (SREQ, SREP, Figure 6) with the purpose to initiate a service discovery process similarly to the route discovery.

The draft [23] defines the process of discovering the service selector (services names and port numbers) and binding it with the IP address as part of the service discovery, which would be part of the route discovery and the path to the resolved IP address. Thus, when a node needs to discover a service, it formulates a service request containing the service selector data, which will identify the desired service application. The node then includes the query as an extension to the RREQ, and floods the RREQ.

Figure 6. AODV message extensions for service discovery.

This mechanism embedded within the routing protocol provides the possibility to receive a request resolution from the entity that provides the service where the service name is bound into an IP address of a node that offers the requested service. Thus, simultaneously a service query also requests a route to the resolved IP address and decreases the latency between the service request and path discovery.

Service discovery request:SREQ

Service discovery response:SRESP

Type

<Service-type> String Service Type

Length Reserved

Service Request PRedicate

Type

URL (Variable length) Lifetime

Length

Auth blocks (if any) URL length

No URL auth

Service discovery request:SREQ

Service discovery response:SRESP

Type

Length Reserved

Service Request PRedicate Type

Length Reserved

Service Request PRedicate

Type

Length

No URL auth Type

Length

No URL auth

(13)

Concluding, the proposed design will perform similarly to the existing service discovery protocols that work properly over fixed networks but in Ad Hoc environments.

6. Conclusions

The paper gives a completely overview of the Ad Hoc protocols and has been identified certain missing functionality for network configuration mechanism. It describes various existing alternatives including advantages and drawbacks. Finally, a proposed solution is given and its advantages are discussed. Therefore, from the different alternatives it can be deduced that a generic configuration mechanism is necessary. The last section presents an alternative approach that should be compliant with existing alternatives but tailored for Ad Hoc networks. Still, the main requirement for creating Ad Hoc networks is to have a collaborative behavior and per application request. This requires certain improvements that should be implemented at routing layer and they are compliant with the proposed concept resource discovery presented as basis for the auto-configuration mechanism.

REFERENCES

[1] C. E. Perkins and E.M. Royer, "Ad-hoc On Demand Distance Vector Routing", Second IEEE Workshop on Mobile Computing Systems and Applications, pp. 90-100, February 1999.

[2] D.b. Johnson and D. A. Maltz, "Dynamic Source Routing in Ad Hoc Wireless Networks", in Mobile Computing, edited by T. Imielinski and H. Korth, chapter 5, pp. 153-181, Kluwer Academic Publishers, 1996.

[3] V. Park and M.S. Corson, IETF MANET Internet Draft "draft-ietf-MANET-tora-spe03.txt", November 2000.

[4] .P. Jacquet, P. Muhlethaler, A. Qayyum, A. Lanouiti, L. Viennot and T. Clausen, IETF MANET Internet Draft

"draft-ietf-MANET-olsr-02.txt", July 2000.

[5] Z. Haas, M. Pearlman, P. Samar "The Zone Routing Protocol (ZRP) for Ad Hoc Networks", draft-ietf-manet-zone- zrp-04.txt, work ongoing, IETF, July 2002.

[6] A. Iwata, C.-C. Chiang, G. Pei, M. gerla and T.-W. Chen, "Scalable Routing Strategies for Ad Hoc Wireless Networks", IEEE Journal on Selected Areas in Communications, Special Issue on Wireless Ad Hoc Networks, vol.

17, No 8, pp. 1369-1379, August 1999.

[7] Bluetooth: http://www.bluetooth.org

[8] ETF - Mobile Ad-hoc networks (manet): http://www.ietf.org/html.charters/manet-charter.html.

[9] Institute of Electrical and Electronics Engineers, Inc., Short Description of the Standard, 1999.

<http://grouper.ieee.org/groups/802/11/main.html>

[10] IETF - Zero Configuration Networking (zeroconf): http://www.ietf.org/html.charters/zeroconf-charter.html [11] Sun Microsystems, Inc, "JiniTM Architecture Specification", Version 1.2, http://www.sun.com/jini/. December

2001

[12] Universal Plug and Play Forum," Universal Plug and Play Technology UPnP", http://www.upnp.org/

[13] Open Services Gateway Initiative (OSGi), " OSGi - The Managed Services Specification", http://www.osgi.org/

[14] The Salutation Consortium: Salutation Consortium, "The Application Programmer's Interface of the Salutation Architecture ", http://www.salutation.org/

[15] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", RFC 2608, July 1999.

[16] P. Srisuresh, M. Holdrege," IP Network Address Translator (NAT) Terminology and Considerations ", RFC 2663, IETF, Aug 1999.

[17] R. Droms, "DHCP: Dynamic Host Configuration Protocol", RFC 2131, Network Working Group, IETF, 1997 [18] P. Mockapetris, "Domain Names: implementation and specification", RFC 1035, Network Working Group, IETF,

1987.

[19] M. Handley, H. Schulzrinne, E Schrooler, J. Rosenberg. "Session Initiation Protocol", RFC 2543, IETF.

[20] M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration for the Zone Routing Protocol", IEEE Journal on Selected Areas in Communications, Special Issue on Wireless Ad Hoc Networks, vol 17, No 8, pp. 1395- 1414, August 1999.

[21] S. Floyd, "General Architectural and Policy Considerations", draft-iab-considerations-03.txt, work ongoing, IETF, October 02.

[22] B. Carpenter, "Architectural Principles of the Internet", RFC 1958, June 1996.

[23] R. Koodli and C. Perkins, "Service Discovery in On-Demand Ad Hoc Networks", draft-koodli-manet- servicediscovery-00.txt, work in progress, IETF, September 2002