Towards Scalable P2P Computing for Mobile Ad Hoc ... - CiteSeerX

Towards Scalable P2P Computing for Mobile Ad Hoc Networks Marco Conti, Enrico Gregori, Giovanni Turi IIT Institute, CNR, Via G. Moruzzi 1, 56124 Pisa, Italy {firstname.lastname}@iit.cnr.it

Abstract— The similarities between peer-to-peer (p2p) systems and ad hoc networking can be considered a duality in terms of computation model, policies for resource distribution, reliability and resiliency. Recently, self-organizing overlay networks like CAN, Chord and Pastry have been proposed as platforms for building decentralized and distributed applications for the Internet. The variety of applications and services realizable on top of these routing substrates, suites also ad hoc scenarios. Thus, having them working also on ad hoc network setups would be an advantage for this emerging technology. It is however not clear, how these overlays should be ported, and how they will perform on ad hoc networks. In this position paper, we show how a system designed for network with infrastructure like Pastry, could be efficiently ported on ad hoc environments using a cross-layered protocol stack design for ad hoc networks. In particular we show how cross-layering helps achieving optimized stack functioning, emphasizing interactions and adaptability between the Pastry-like substrate and the routing protocol at the network layer. Index Terms— Ad hoc networks, cross-layering, middleware, peer-to-peer computing.

I. I NTRODUCTION Ad hoc networks are distributed systems composed of selforganized wireless nodes. As these systems cannot benefit from any centralized infrastructure, networking functionalities, like packet forwarding, routing and network management, as well as application services, should be distributed over the nodes themselves. The distributed nature of ad hoc networking, finds in the peer-to-peer (p2p) interaction, its natural model of computation. The applications best suited for p2p implementation are those where a centralization is not possible, relations are transient, and resources are highly distributed. The above points also reflect main requirements of ad hoc networking. While ad hoc networks are still in a system design stage, several p2p systems have been proposed and deployed for the Internet. These systems provide services ranging from file sharing to redundant storage, from instant messaging to distributed and cooperative Web caching. Despite the rich set of services and features, the core problem in most of these systems remains how to efficiently locate data items without having a “perfect” knowledge of the p2p network. The Pastry system [1], the Content-Addressable Network [2], as well as Chord [3] and other platforms, are recent solutions to this core problem. They provide a distributed hash table abstraction, realizing a p2p overlay network over the physical network. Although these systems differ on the way they

build the overlays and route packets, they provide the same abstraction with comparable costs of operation. Moreover, some of these routing substrates (see Pastry) come along with an interesting set of applications and services, ranging from distributed archival storages to cooperative messaging, and from distributed web caching to event publishing/subscribing engines. The similarities between p2p systems and ad hoc networks justify the usage of distributed hash table abstractions also for the latter. Not only will ad hoc application programmers be provided with the right abstraction to develop decentralized and scalable application services, but many of these services could be directly imported, easying the deployment of this emerging technology. However, at the best of our knowledge, there have been no attempts at describing how these p2p routing substrates could be efficiently ported on ad hoc networks. This paper introduces an innovative protocol stack architecture for ad hoc networks, where emphasis is given on the sharing of network status information between the various stack layers. Such a way of interaction is denoted crosslayering and is an active argument of discussion in ad hoc forums. The key idea behind cross-layering is that the information collected at each layer could be used by the rest of the stack to perform optimizations of the overall functioning of single nodes and of the entire network. In particular this paper focuses on the interaction of network layer (routing protocol) and a Pastry-like substrate at the middleware layer. We show how the cost of building and maintaining Pastry routing tables could be reduced by sharing the network topology knowledge collected by a proactive routing protocol adopting Link-State information spreading. Finally, we show how optimizations are also possible for the routing algorithm run in the Pastry routing substrate. The rest of the paper is organized as follows. Section II provides a brief overview of the concepts inside p2p overlay networks like Pastry, Content-Addressable Network and Chord. Section III introduces our cross-layered protocol stack architecture, motivating the need of information sharing among stack layers and showing the mechanism we designed to implement it in a homogeneous way. Section IV details the interactions between a Pastry-like substrate and the network layer realizable with the cross-layered architecture and standing at the base of an efficient porting of such a technology on ad hoc networks. Finally, Section V concludes underlining our future directions.

II. OVERVIEW

OF SCALABLE PEER - TO - PEER OVERLAYS

In this Section we survey some of the recently proposed structured p2p overlay protocols. Namely, these are the Pastry system, the Content-Addressable Network (CAN) and Chord. A more detailed description is reserved for Pastry, as it is the system which we take as reference in this work, as motivated in Section IV. These systems work as a substrate for distributed p2p applications, offering the abstraction of a distributed hash table in which items can be located in a bounded number of routing hops, using a small per-node routing table. Even if they offer a similar abstraction, with comparable performances, they use different strategies to build the overlay and route packets on them. Among the three systems, Pastry shows explicit awareness of network proximity together with a rich set of services implemented on top of it, and therefore we consider it very interesting for ad hoc environments. The Pastry system [1] works with a circular address space of size 2128 − 1, also called the ring of addresses. When entering the Pastry network, a node get an address from the ring, typically applying a hash function on its network address or on its public certificate. The peers of a Pastry ring distribute (key, value) pairs among themselves applying the same hash function used for producing logical addresses. The distribution strategy is the following: a key k is stored on the peer that has the logical address numerically closer to k (it could be smaller or greater). For the purpose of routing a packet with key k (finding the numerically closer peer), node identifiers and keys are seen of as a sequence of digits with base 2b . Pastry routes messages hop by hop, getting each time closer to the target node. This is accomplished using the following logic. At each routing hop, the current node forwards the packet to a peer whose node identifier shares with the packet’s key a prefix that is at least one digit (or b bits) longer than the one of its own logic address. If no such peer is known, the message is forwarded to the node whose identifier shares the same prefix with the key as the current node, but is numerically closer to the key. A node’s routing table R is organized into log2b N rows, where N is the size of the p2p network, each with 2b − 1 entries. Each entry at row n refers to a node whose identifier has a common prefix of length n with the current node, but differs at digit n + 1. Each entry in the routing table contains the network address of one of (potentially) many nodes whose logical address has the appropriate prefix. In practice, the choice falls on a node which is close to the present one according to a proximity metric specified by the application (e.g. the distance in number of hops from the present node). This choice provides good locality properties. If no node is known with a suitable logical identifier, then the routing table entry is left empty. Additionally, a neighborhood set M contains the logical and network addresses of the nodes that are closest (according the proximity metric) to the present node. The neighbourhood set is not used in routing messages, but it is used to maintain locality properties. Finally, a leaf

set L maintains the nodes with logical addresses numerically closest to the current node. The set L is an interval centered around the present identifier: a half of the identifiers are larger and a half are smaller. The leaf set is used during the message routing in the following way: in routing a given message, the node first checks to see if the key falls within the range of identifiers covered by its leaf set, otherwise the above prefixbased routing is applied. When a new node X arrives, it needs to initialize its state tables, informing other nodes of its presence. Theoretically, it should first contact another nearby Pastry node A, according to a proximity metric, asking it to route a message with key equal to X. This message will eventually end up to a node with identifier Z numerically close to X. All the nodes encountered by this join message on the Pastry-path from A to Z, will send their routing information to X. X will afterwards synthetize its state tables in the following way: • The neighbohood set M from node A • Taking the leaf set L from node Z • The i-th row of the routing table R from node Bi , which is the i-th node in the path from A to Z and shares a prefix of length i with X. Finally, X informs any nodes that need to be aware of its arrival, transmitting a copy of its resulting state. This procedure ensures that X initializes its state with appropriate values, and that the states of the other affected nodes is updated. The CAN system [2] realizes a d-dimensional space abstraction, where the participating nodes control non-overlapping zones of the space. Data items, as well as data queries, are mapped on space points using a hash function, so that they fall under the control of one of the nodes. Zones are randomly chosen from the participating nodes. Routing is easy, as each node maintains information only about its neighbours in the virtual space, and forward CAN packets choosing the neighbour that owns a zones closer to the packet destination. The Chord platform [3], similarly to Pastry, works with a ring of addresses: it can be seen as a mono-dimensional space where node addresses, and both data items and data queries are mapped. In the Chord ring, each node is responsible for the range of consecutive keys with values greater than its address, but smaller than the address of the next peer in the ring. For example, in a ring with three nodes k, h, t, with k < h < t, the peers will own respectively the key ranges [k, h), [h, t) and [t, k) identifier. In Chord, nodes do not choose which range of keys to own. The key ranges are specified by the node identifiers. Routing in Chord requires each node maintaining information about a logarithmic number of nodes, called fingers, chosen to span the whole ring. Packets are routed selecting at each step the finger that is supposed to own a range including the packet’s key. There are other proposals which we don’t survey for space reasons. Namely, they are Tapestry [4] and Kademlia [5]. The basic feature provided by these systems is a middleware service that can be used to build fully-decentralized and distributed application services, where participating nodes play both the role of data producers/consumers and maintainers

Application 1

Application 2

Applications

Application n

Cross-layer Issues

Middleware

& Middleware

Service location, Group communication, DSM Security

Networking

Transport and Network layer protocols

Cooperation

TCP, IP routing, Forwarding, Addressing, Interconnection

Quality of Service Energy Saving

Enabling Technologies

802.11

Bluetooth

Hyper LAN

Medium Access Control, Antennas, Power Control

Fig. 1.

MANET reference architecture.

of the overlay infrastructure. The abstraction provided to the programmers is a distributed hash table: data is equally distributed on the members of the p2p network providing lookup costs logarithmic in the size of the network. III. C ROSS - LAYERING

IN MOBILE AD HOC NETWORKS

In this Section, we describe our reference protocol stack architecture, postponing the challenges of porting a Pastry platform in Section IV. One of the major challenges in the research on mobile ad hoc networks is to have them fully functional with good performance and, at the same time, make them able to communicate with the rest of the Internet. The IETF MANET Working Group proposes a view of mobile ad hoc networks (also referred as MANET’s)as an evolution of the Internet. This mainly implies an IP-centric view of the network, and the use of a layered architecture. This paradigm did bring successfull result in terms of simplified network design and protocols scalability (see the Internet). The use of the IP protocol for ad hoc networks would have two main advantages: simplified Internet interconnection, and guaranteed wireless technologies independency [6]. However, current results show that the layered approach is not equally valid in terms of performance [7]. The layered approach leads research efforts mainly to target isolated components of the overall network design (e.g., routing, MAC, power control). Each layer in the protocol stack is designed and operated apart from the others, with interfaces between layers that are static and independent of the individual network constraints and applications. However, as shown in Figure 1, in a MANET some functions cannot be assigned to a single layer. Energy management, security and cooperation, quality of service, among the others cannot be completely implemented in a single layer but they have to be part of each stack component. An efficient implementation of these functions can thus be achieved by introducing and integrated framework in which protocols can take advantage of the interdependencies between them. Relaxing the Internet layered architecture, by removing strict layer boundaries, is therefore an open issue in the mobile ad hoc networks evolution. However, as the layered approach was, and is, one of the key elements of the world-wide diffusion of the Internet, the question is to what extent the

pure layered approach needs to be modified. Even if there are solutions based on layer triggers that are still compatible with the principle of separation among layers, a full cross layering design represents the other extreme. Layer triggers are pre-defined signals to notify some events to the higher layers, e.g., failure in data delivery, that have been extensively used both in the wired and wireless Internet. For example, in wired Internet, the Explicit Congestion Notification (ECN) mechanism is used by intermediate routers to notify congestion conditions to the TCP layer. A full crosslayer design is a more extreme solution that tries to exploit, in the protocols design, layers interdependencies to optimize the overall network performance. In this case, control information is continuously flowing top down and bottom up through the protocol stack, and protocol behavior adapt both to higher and lower protocols status. For example, the physical layer can adapt rate, power, and coding to meet the requirements of the application, given current channel and network conditions. The MAC layer can adapt based on underlying link and interference conditions as well as delay constraints and bit priorities. Adaptive routing protocols can be developed based on current link, network, and traffic conditions. Finally, the application layer can utilize a notion of soft QoS that adapts to the underlying network conditions to deliver the highest possible application quality [7]. In mobile ad hoc networks, the use of layer triggers has been extensively proposed for fixing the problems due to TCP - IP MAC interactions. For example in [8], to minimize the impact of mobility and link disconnection on TCP performance, it was proposed to introduce explicit signaling (Route Failure and Route Re-establishment notifications) from intermediate nodes to notify the sender TCP of the disruption of the current route, and construction of a new one. However, recent works indicate that layer triggers are not enough for fixing ad hoc networks performance problems, as for example in [9], where to fix the problems due to TCP - IP - MAC interactions, two link level mechanisms, Link RED and adaptive spacing, are introduced to improve TCP efficiency, thus implying a joint design of the MAC and TCP protocols. In the ongoing debate among ad-hoc-network researchers on cross-layered architecture vs. the legacy layered one, we recognize the significance of strict layering in terms of easiness of protocol design and backward compatibility with the Internet, but we believe that layer triggers are not the only solution for performance problems: a careful cross-layer design must be adopted. Our approach is to introduce inside the layered architecture the possibility of protocols belonging to different layers to cooperate by sharing network status information still maintaining layers separation for protocols design. This is a very innovative approach for a working solution, as pointed out in [10]. At the best of our knowledge, no reference architecture has been defined to exploit a full cross-layer design of a mobile ad hoc network protocol stack. For this reason, in the framework of the MobileMAN project we have defined a mobile ad hoc network reference architecture able to exploit the advantages of a balanced cross-layer design, as shown

1) Allows for a full compatibility with standards, as it does not touch the core functions of each layer; 2) Is robust to upgrading, and protocols belonging to different layers can be added/removed from the protocol stack without modifying the operation at the other layers; 3) It maintains all the advantages of a modular architecture. To summarize this new reference architecture tries to achieve the advantages of a full cross-layer design (i.e., joint optimization of protocols belonging to different layers) still satisfying the layer separation principle. Layer separation is achieved by standardizing the access to the Network Status. This mainly implies defining the way protocols can read and write the data from it. Interactions between protocols and the Network Status are placed beside (juxtaposed) to normal layers behavior, and provide optimization without compromising the expected normal functioning. Replacing a Network Status oriented protocol with its legacy counterpart will therefore allow the whole stack to keep working properly. For example, using the legacy TCP protocol as the transport protocol, implies that cross-layer optimizations will not occur at this layer, and that the transport protocol will not provide any information to the Network Status but, even though in a degraded way, from the performance standpoint, the overall protocol stack will still correctly operate. In the context of this paper, we focus on the routing protocol adopted in the cross-layered architecture as it is directly related with the porting of Pastry. Routing in our crosslayer architecture, happens through a proactive algorithm that adopt a link-state dissemination policy, like the one described in [11]. Genarally, in a link-state routing algorithm each node broadcasts link-state update packets when it detects a change in its immediate (or 1-hop) links. As each node floods link-state update packets, everyone is able to synthetize the knowledge about the network topology from the received linkstate updates. The dissemination of link-state updates is a wellknown scalability issue for this class of routing protocol, as they occupy more and more bandwidth proportionally to the size of the network and the mobility of the node. However, a reduction of the overhead can be achieved by controlling the scope and the frequency of link-state updates. Intuitively, each node broadcasts link-state updates with increasing Time-

Applications Middleware [Pastry substrate]

Network Status

in Figure 2. In this architecture, cross layering is limited to parameters and implemented through data sharing. The innovation of the architecture is a shared memory, called “Network Status”, working as a repository of all the state information collected by the network protocols. All protocols can access this memory to write information sharing it with the rest of the stack, and to read information produced/collected from the other protocols. This avoids duplicating the layers efforts for collecting network status information, thus leading to a more efficient system design. In addition, inter-layer cooperations can be easily implemented by variables sharing. However, protocols are still implemented inside each layer, as in the traditional layered reference architecture. This has several advantages:

Transport Network [Link-State routing] MAC + Physical

Cross-layer interaction through shared repository (Network Status) Strict layer interaction through interfaces

Fig. 2.

Reference cross-layer architecture.

To-Live at decreasing frequencies. In this way neighbours are informed more often than far away peers about changes. This policy is motivated by the observation that in hop-byhop routing, changes experienced by far away nodes, tend to have little impact in a node local next hop decision. This algorithm determines in each node a “self-centred” view of the network topology, that fades away as the distance from the present node grows. As analysed in [11], this routing approach presents advantages in terms of costs if compared to classical proactive approaches, but also induces sub-optimal routes on distant targets. In the framework of our cross-layer architecture, we recognize in such an approach the ability to build and maintain knowledge of the whole network topology. This feature, if coupled together with the sharing feature offered by the Network Status, is a once and for all effort from which the entire stack can benefit. IV. PASTRY

IN A CROSS - LAYER ARCHITECTURE

As already mentioned in Section II, Pastry delivers a lookup service with logarithmic costs. This means that once the Pastry p2p network is set up, publishing and retrieving (key, value) pairs requires O(log N ) steps in the p2p network, where N is the size of the network. Also CAN and Chord provide comparable lookup costs, and hence we can consider Pastry an optimal solution in the area of distributed hash tables. Furthermore, the primitives exported by Pastry to application programmers are general enough to support a variety of applications and services. The rich set of application already developed over Pastry confirms this point. These are the main reasons why we decided not to go for yet another middleware for mobile ad hoc networks, but to work out an efficient way of porting an existing “optimal” platform. Finally, we selected Pastry among the set of scalable p2p overlays, as it is aware of a proximity metric specified by the application built on top of it. We see this feature as an interesting handle to deliver context-aware services for ad hoc networks.

In order to provide logarithmic lookup costs, the construction and maintainance of routing tables at the Pastry level is a primary operation. This is necessary on networks with infrastructure, as nodes have very little knowledge of the rest of the network. Typically, routing tables of ordinary nodes contain only gateways and DNS servers. So, in orther to build the overlay network and maintain it, Pastry nodes have to gather knowledge about other peers, storing it in the routing tables. This operation is costly, but is fundamental, as wellformed Pastry tables are a precondition for the convergency of the prefix-routing at logarithmic costs. In [1] the authors perform a cost analysis for a network of 5000 peers, where a 10% failure rate affects randomly selected nodes. The result is an average of 57 remote procedure calls performed by each node just to repair the tables. We believe ad hoc networks present even tougher scenarios, with higher failure rates and failure processes not describable as random: for example a group of nodes gets partitioned due to the presence of an obstacle. Hence, we believe that cost of maintaining Pastry routing table could quickly bring the system to unsatisfactory perfermances, due to the variability of ad hoc environments. Starting from the above considerations, our target is to reduce the cost associated with Pastry routing tables management, keeping their accuracy good enough to maintain the convergency property of the prefix-based routing policy. Although mobile nodes have resource limitations respect to their infrastructured counterparts, they have significant advantages from a routing point of view: they have a knowledge of the network comparable to the one of an Internet router. This is due to the necessity of having each node participating in the routing service. In our cross-layer architecture, the Pastry layer can exploit the knowledge built by the LinkState routing, thanks to sharing provided by the Network Status. The key idea is to build well-formed Pastry tables using directly the tables built by the network layer, by performing local transformation of the data written in the Network Status, instead of exchanging messages between peers. Below we show the steps required for that operation. A. Address space In Pastry, a random address from a circular logical space, is assigned to each node that performs a join of the p2p overlay. This logical address space is the same where data keys are mapped. The mapping is done by a hash function: typically, the nodes hash their IP addresses or their public keys [1], so that nodes living under the same jurisdiction get spread over in the logical ring. This aims at ensuring a fair balancing of the amount of keys each node will be responsible for in the distributed table. Also in ad hoc networks, assumptions cannot be made on the origin of the participating nodes and on the distribution of their physical addresses. This implies that a mapping in the logical address space is again needed. The advantage in the framework of the cross-layer architecture is that each node has a “hazy” but global vision of the network topology, and hence it knows the routing addresses of the rest of the network.

R1

R2

1. Write exported services in the Network Status

R3

Pastry-Like Substrate

6. Read topology AND service info from the Network Status

Network Status R1 Pastry

R2 Pastry

R3 Pastry

Synthetized Network Topology + Published Services

Link-State Routing

5. Write network topology and service info

4. Receive LinkState Updates

Fig. 3.

2. Read Services to be published from Network Status

3. Send LinkState Updates with Service Extensions

Layers interaction through the Network Status.

Each node is therefore able to calculate directly the Pastry logic addresses by just applying the hash function. The only restriction we impose in this area is to build Pastry addresses having exclusively network addresses as sources. It would be possible to use directly the network addresses (without moving on the logical space), but in this case the hash function, should be able to adapt to the distribution of physical addresses currently available in the network. B. Spreading service information The Link-State protocol continuosly updates a representation of the network topology in the cross-layer repository, as it receives link-state update packets. For a node willing to join a previously established Pastry ring R, the next information would be to understand which nodes, among those “listed” in the Network Status, participate to the same ring R. As a matter of fact, a Pastry ring has to be considered an application layer service, so the problem for the joining peer is to know which services are available in the network. Actually, this is equivalent to having a service discovery mechanism available. Our solution in the cross-layer architecture, extend network routing to spread around service information together with link-state update packets, resulting in a sole distributed protocol. The same idea has been proposed in [12], where AODV is extended to allow service request and service reply messages in conjunction with route-related ones. By including Service Extension blocks to Link-State Update packets, a proactive algorithm would exclude the need for explicit service request messages, having each node building its own “service map” together with the topology representation. This again adds an overhead to routing, but saves the run of a separate service location protocol at above layers. Figure 3 sketches how the Pastry substrate would interact with the network routing to realize spreading of service information. The operations are shown as a sequence, but in reality they occur concurrently. •

The Pastry substrate has knowledge about the application services currently running on the present node, as it

•

•

•

•

supports them 1 . Than, it writes this information in the Network Status. The link-state routing reads the locally-available services from the Network Status, producing update packets containing Service Extensions (service identifier and binding parameters). As nodes participate to the link-state routing, update packets contating Service Extensions are sent around in the network. Each node builds the network topology representation together with a mapping of the available services as it receives extended link-state update packets. Than, it writes this information in the Network Status. At this stage the Pastry substrate, as well as other protocol stack components, has a local service map from where it can understand which node is running the target Pastry ring R.

C. Building and maintaining pastry tables The Network Status allows the Pastry substrate to manage its routing tables with a cost that is significantly lower than on networks with infrastructure. In the cross-layer architecture, the Pastry routing tables are simply deduced from the ones built at the network layer. Considering a Pastry service identified by a ring R, run by a node X, its logical peers in the physical network will be those node publishing the same ring R among their exported services. The node will be able to locally compute its peers logical addresses and estimate their proximity according to the metric specified by the application. Managing the three blocks of the Pastry tables is reduced to: • Ordering and placing the peers satisfying the proximity metric in the neighbourhood set M. As M is not used for routing purposes, its computation could probably be avoided. • Among the peers, those with logical addresses closer to the one of node X will constitute the leaf set L. We wish to point out that in the original Pastry, the leaf set represents the good knowledge that the node has about its logical neighbourhood. In the case of the cross-layer architecture, as each peer knows the rest of the overlay, L could be extended to the whole Pastry ring. This could bring advantages to the routing procedure as explained later. • The routing table can be built analogously to the leaf set. The node can infer locally the set of peers with logical addresses sharing prefixes of increasing length with its own logical address. Those with common prefix of length 0 will constitute the first row of the table, those with common prefix of length 1 will constitute the second row and so on. Inferring Pastry tables from the network routing tables as described above, results in saving the communication costs of 1 Of course there could be services offered by other platforms, and they will have to perform similar operations to those described here.

routing data exchange among peers. The task of building the physical tables is done only by the network layer, while the Pastry routing substrate performs only local processing. D. Routing considerations Additional considerations can be also made on the routing procedure. Ideally, the knowledge built by the network layer allows the Pastry substrate to consider the visible peers as a “big” leaf set. A node having to route a key k could directly select, among the visible peers, the one with the closer logic address, without applying the prefix-based routing and passing through intermediate peers. In practice, the link-state routing at the network layer does not guarantee a perfect and immediate picture of the physical network. A certain latency has to be taken into account to see a link change propagated throughout the network. This result in a “hazy” vision of the network that would require the prefix-based routing to be still applied. Therefore, we propose a variation of the Pastry routing, in which the node first attempts to route the request directly to the closets peer and, in case of failure, applies the prefix-based routing involving intermediate nodes. Should the entire peer set be considered the leaf set, this is exactly what the original Pastry routing attempts to do. V. C ONCLUSIONS

AND FUTURE WORKS

In this position paper, we have outlined preliminary considerations about porting a scalable p2p overlay like Pastry, in an ad hoc network environment. We have described a cross-layer protocol stack architecture which allows global information sharing. In this framework, the topological information collected by a proactive link-state routing protocol, extended with information about exported services, cut out the costs associated with Pastry tables management, and potentially simplify its routing. In other words the efforts of link-state routing are simply reused at the Pastry level, where only local table re-arrangement is needed. At the best of our knowledge no other works addressed this problem before. The solution we have porposed, while targeted at Pastry, is applicable to other platforms like CAN and Chord, providing different views of routing tables built at the network layers. This work is part of our efforts in providing a global optimization of ad hoc networks functioning. In the future we intend to provide an analitical study of the savings offered by this approach when compared with traditional layered approaches, as well as to provide an implementation of it. R EFERENCES [1] A. Rowstron, P. Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pages 329-350, November, 2001. [2] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker. A scalable content-addressable network. In Proc. ACM SIGCOMM 2001, August 2001. [3] I. Stoica, R. Morris, D. Karger, F. Kaashoek, H. Balakrishnan. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. In Proceedings ACM Sigcomm 2001, San Diego, CA, Aug. 2001.

[4] B. Y. Zhao, J. Kubiatowicz, A. D. Joseph. Tapestry: an infrastructure for fault-resilient wide-area location and routing. Tech. Rep. UCB//CSD-011141, University of California at Berkeley, April 2001. [5] P. Mayamounkov, D. Mazi´eres. Kademlia: A P2P information system based on the xor metric. In 1st International Workshop on P2P Systems (IPTPS ’02), MIT Faculty Club, Cambridge, MA, USA, March 2002. [6] J.P. Macker, S. Corson. Mobile Ad hoc Networks (MANET): Routing technology for dynamic, wireless networking. In Mobile Ad hoc networking, S. Basagni, M. Conti, S. Giordano, I. Stojmenovic (Editors), IEEE Press and John Wiley and Sons, Inc., New York, 2003. [7] A.J. Goldsmith, S.B. Wicker. Design Challenges for Energy-Constrained Ad Hoc Wireless Networks. IEEE Wireless Communications, Volume 9, Number 4, August 2002. pp. 8- 27. [8] K. Chandran, S. Raghunathan, S. Venkatesan, R. Prakash. A Feedback Based Scheme for Improving TCP Performance in Ad Hoc Wireless Networks. IEEE Personal Communication Magazine, Special Issue on Ad Hoc Networks, Vol. 8, N. 1, pp. 34-39, February 2001. [9] Zhenghua Fu, Petros Zerfos, Kaixin Xu, Haiyun Luo, Songwu Lu, Lixia Zhang, Mario Gerla. The Impact of Multihop Wireless Channel on TCP Throughput and Loss. In Proc. Infocom 2003, San Francisco, April 2003. [10] M. Conti, S. Giordano, G. Maselli, G. Turi. MobileMAN: Mobile Metropolitan Ad Hoc Networks. In Proceedings of the 8th IFIP Conference on Personal Wireless Communications (PWC’03), Venice, September 2003. [11] C. A. Santiv´an˜ ez, R. Ramanathan, I. Stavrakakis. Making Link-State Routing Scale for Ad Hoc Networks. In Proceedings of the 2nd ACM Symposium on Mobile Ad Hoc Networking and Computing (MOBIHOC’01), 2001. [12] R. Koodli, C. E. Perkins. Service Discovery in On-Demand Ad Hoc Networks. Internet Draft available at (http://www.ietf.org/internetdrafts/draft-koodli-manet-servicediscovey-00.txt), October 2002.