An Efficient Mechanism for Mobility Support using Peer-to ... - CiteSeerX

Download PDF
3 downloads 2501 Views 226KB Size Report
Comment
support mobile IP users using a Peer-to-Peer overlay network. The proposed overlay exploits locality to efficiently use the network resources and manage ...
An Efficient Mechanism for Mobility Support using Peer-to-Peer Overlay Networks Hanh Le, Doan Hoang, Andrew Simmonds, Bushar Yousef, and Joe Chan Faculty of Information Technology, University of Technology, Sydney {hanhlh,dhoang,simmonds,byousef,joechan}@it.uts.edu.au

Abstract—Expanding the Internet infrastructure to span mobile devices is a challenging task. The Internet’s addressing and routing scheme was originally designed for fixed devices making it inoperable without redirection and tracking functions such as those proposed by Mobile IP. However, Mobile IP requires prior network setup, and causes a large added overhead. In this paper, we propose a new approach to support mobile IP users using a Peer-to-Peer overlay network. The proposed overlay exploits locality to efficiently use the network resources and manage location data in a selforganizing and distributed fashion. The simulation results are presented. Index Terms— Peer-to-Peer, Overlay Network, Mobility, Location Management

I. INTRODUCTION Internet and Mobile device communities have been separately evolving everyday over the last few decades. Internet applications are developing as fast as the human mind works. Meanwhile the mobile community has reached every corner of the earth and has become an attachment that today’s generation finds hard to live without. It is imperative to provide plentiful Internet applications to a large number of mobile users. However, existing systems are facing the problem of merging the two communities together. This is because the Internet was originally designed for fixed devices with long-term IP addresses, whereas mobile devices require a temporary IP address in a location-based and timely manner to be able to access the Internet. Mobile IP (MIP) [1] is the immediate network mobility solution to integrate mobile computing devices with the global Internet (so called Mobile Internet). MIP supports IP mobility at the network layer to facilitate users roaming and applications transparency across network domains, i.e. TCP/IP session continuity. In MIP, each mobile node (MN) has a Home Agent (HA) to represent it and a Foreign Agent (FA) to attach to the Internet. Correspondent Host (CH) that wants to communicate with the MN will contact the HA of the MN. Then the information will be tunnelled from HA to FA before delivering to the MN. Changes of points of attachment (PoA or FA) need to be updated to the HA. Since the MN is given a long-term IP address in its home network and the system depends on one or more HAs, it is clear that the number of devices that can have mobility support is limited. Moreover, this standard Mobile IP routing is inefficient and introduces significant delay as a

result of triangle routing. The delay depends on the distance between HA and MN rather than between CH and MN. However, the applications and deployments of MIP are limited by stringent requirements such as network management and infrastructure dependency. MIP does not work without prior network setup (i.e. FA, HA and AAA) and service level agreements (SLA) in place. Furthermore, current design of Mobile Internet applications is tied to specific terminals indirectly addressed to mobile users. This implicit user addressing approach generally restricts the applications development to device capability (bandwidth, I/O, multimedia and battery). In this paper, we propose a new approach to support mobility using Peer-to-Peer (P2P) overlay network. Some of advantages of the approach are summarised as following: • P2P mobility at the application layer providing user/applications mobility, i.e. independent of mobile devices and infrastructure. • All the network changes are transparent to the end users. • Applications can run smoothly even though nodes move and change IP addresses. • It requires no modification to the network infrastructure. [2] • The overlay is self-organizing; and self-managing; • It employs topology-aware efficient routing; Peer-to-Peer (P2P) overlay networks have emerged in the last few years as highly attractive, decentralized and distributed systems. Overlay networks work at the application layer, allowing end users to deploy applications regardless of the underlying infrastructure. Many useful P2P application such as distributed file systems [3-6], application-layer multicast [7-9], and event notification services [10, 11], etc. have been developed. Mobile node internetwork that works at the overlay layer could become a very promising approach. However there exist two main challenges in the current Internet access systems that support mobile nodes: Firstly, inefficient routing, which is caused by triangle routing [1] or physical network unawareness overlays such as Chord [12], CAN [13], Pastry [14], and Tapestry [15]; Secondly, inefficient location management or update mechanism, which leads to high overhead and slow convergence network. This prevents the system from supporting fast moving nodes because of frequent IP addresses changes. In this paper, we propose a new mechanism to provide a Peer Name Resolution Service (PNR) to provide reachability for peers and support mobility in a distributed

and self-organising manner. PNR service is built on top of the efficient overlay layer, which is proposed by [16]. The overlay network is self-organising, self-managing, and aware of the underlying network infrastructure. As a result, the end-to-end latency is minimised and network resources are used more efficiently. With an intelligent location management and update approach, PNR can support fast moving nodes while minimising the overhead. The rest of the paper is organised as follows. Section 2 briefly presents mechanisms for constructing overlays that match the underlying network infrastructure. The new location management and update approach is presented in Section 3. Section 4 describes PNR performance evaluation. Related work is in Section 5. Our conclusions are in Section 6. II. EFFICIENT OVERLAY NETWORK To form an overlay that closely matches the underlying network topology, we propose: firstly cluster nodes that are close to each other in terms of network proximity and network membership; secondly define cluster neighbourhood based on the proximity between clusters A. Clustering scheme The Geographical Longest Prefix Matching (Geo-LPM) scheme [17] clusters nodes based on the longest matching prefix (LPM) and the geography/network proximity (distance) between the o-router and other nodes in a cluster. Geo-LPM makes use the contiguous IP addresses in a physical network and Classless Inter-Domain Routing to cluster nodes. In Geo-LPM, each cluster has a node that acts as the routing node for the cluster, termed an “o-router”. Any node can become an o-router and normally it is the first node that establishes the cluster. After other nodes join the cluster, it is preferable to select a node that remains online for long periods and has a high bandwidth connection to be the o-router. Note that o-routers do not serve like “superpeers” as in a hierarchical P2P system or hybrid P2P system [18, 19]. Rather, the o-router mainly assists in locating and routing between clusters. The idea behind Geo-LPM is that nodes that are in the same physical network and geographically close to each other should belong to the same cluster. Geo-LPM therefore employs two parameters to self-organise a cluster. One is to isolate/locate candidate peers for a cluster by selecting the longest common prefix (LCP) cluster for a peer. The other is to make a final decision on whether the peer is to join the cluster by measuring the proximity between the peer and the o-router of the LCP cluster. Geo-LPM locates peers simply and directly, by virtue of Classless Inter-Domain Routing (CIDR) and its hierarchical IP address arrangement [20, 21]. Geo-LPM arranges clusters with their corresponding common prefixes in a CIDR hierarchy. The common prefix of a cluster is the IP common prefix of all peers in the cluster, rather than extracting it from BGP routing tables [22]. Clusters at a higher level aggregate the addresses of their child clusters. The join request of a new peer is routed by forwarding

between parent and child clusters in the CIDR tree until it reaches a cluster that shares the longest common prefix (LCP) with the new peer. The difference in Geo-LPM is that the new node will now measure its distance (latency) to the o-router of the cluster with which it shares the LCP. From this distance value, the new node may join the cluster or create a new cluster, if the distance is smaller or greater respectively than a predefined distance threshold, T. In so doing, peers in the same cluster often belong to the same physical network. Therefore, Geo-LPM optimises the use of the physical underlying network resources by minimising the number of packets travelling over WAN links. B. Geo-Partitioning for Cluster Neighbour Discovery We propose, Geographical Partitioning (GeoPartitioning), a method to automatically divide the geographical space into partitions following a tree structure as shown in Fig.1 *

Lj Lj+1 Lj+2

1* 11*

2* 12*

21*

…

k* k1*

Figure 1: An illustration of Geo-Partitioning

By using Geo-Partitioning, nodes/clusters can quickly find their neighbours in the same partition rather than in other partition. As a result, a topological-matched overlay can be constructed based on clusters of nodes that are close to each other and proximity between the clusters. Each partition has a head node (o-router) to help other nodes locate their position in the geographical space. When a new node joins the overlay, it will measure its distances to the head nodes to find its local partition. Within this partition, the new node will measure its distance to the next level head nodes (child/smaller partitions of the local partition) to achieve higher precision. The procedure is repeated until the new node finds its closest partition. The PseudoCode of Geo-Partitioning is in Table 1 and bounded by O(logM), where M is the number of clusters . Function/Abbr Lj_Threshold MAX_LEVEL distance(x, Y) min(x, yi)

Description Latency Threshold at level j. The maximum number of levels. Returns the latency (round-trip time) between x and Y Returns minimum value of all value between the brackets

Table 1: The PseudoCode of Geo-Partitioning

Procedure Locate(X: new cluster); Level j = 0; Yj = an o-router at level 0; while (level j < MAX_LEVEL) { RTT = distance(X, Yj); RTTi = distance(X, Yij) where Yij is the child partition i of Yj Yx ∈ {Yij, Yj} has min(RTTi, RTT); if (Yj == Yx) // current region Yj is closest to X break ; else { j = j+1; Yj = Yx; // Yx is closer to X’s destination region than Yj } end while //Yx is X’s destination region if (distance(Yx, X) > LJ_Threshold) { X is a child partition of Yx; } X has LJ prefix of Yx and random suffix; End Locate; In order to control the number of partitions at each level and achieve maximum scatter of the head node distribution, at each level we use a distance threshold. If the minimum distance of a node to all head nodes at a level is greater than the threshold of that level, it can be the head node of its own partition at that level. Note that head nodes at level Lj are also the head nodes of their corresponding lower level and smaller partitions. Head nodes play no different role in routing at the application routing layer compared to other peers. They just assist a new cluster to locate its closest partition. MAX_LEVEL is a parameter that is used to control the number of levels and/or the overhead of discovering clusters. After a new node finds its closest partition, it will assign its ID prefix based on the ID prefix of the closest partition. The suffix ID of the node is assigned randomly or based on its IP address. If the head node of a partition leaves the overlay, any nodes in its local region can substitute. If there are no nodes in that region then the entire region is vacated. Head nodes of partitions are selected automatically and replaceable which makes the system self-organising. C. Overlay formation Clusters can selectively choose clusters in the same partition to be neighbours because they are geographically close to each other. Overlay network is formed of vertexes (clusters of nodes that are close to each other) and edges (shortest distant links between clusters). Each o-router maintains a routing table R that has log 2b M rows and (2b-1) columns, where M is the number of overlay o-routers (clusters) and 2b base. An entry at row i and column j in R points to an o-router that has the same first i digits with the current o-router but has value j at (n+1) digit. Geo-LPM clusters nodes precisely and makes communication within a cluster locally. It is done without

consuming WAN resources. Routing between clusters is done based on the Longest Prefix Matching (LPM) rule and the routing complexity is O(logM) where M is the number of clusters. To maintain the overlay, nodes need to send keepalive messages to its neighbours periodically to inform them of its status. To minimize the impact of peer departures, peers in the same cluster should backup each other; clusters in the same partition should also backup and replicate at least the routing information part. It is preferable to choose a node which remains online for long periods and has a high bandwidth as a representative for the cluster. As a result, the overlay structure will be more stable. III. PEER NAME RESOLUTION SERVICE In P2P systems, peers often do not have permanent IP addresses because of IP scarcity problem and they are behind NAT or firewall. In addition, peers might move from place to place and receive different IP addresses, especially in the case of mobile hosts. Therefore, it is crucial for any P2P system to support reachability and mobility amongst P2P community. In order to do so, P2P systems should provide: 1) Identification: each peer must have its own and unique ID universally. 2) Translation: P2P system must support translation between a user ID and his/her current location PoA (i.e., IP address) for reachability. 3) Location Management and Update: the system must support update functionality so that when users move or change PoA, the system can reflect this in a timely fashion. D. Reachability: In P2P system, each peer has a unique ID, which can be generated by hashing peer names and/or IP addresses. In PNR, each user has a unique ID, which is similar to an email address, called a user ID. This user ID will be stored at a node whose ID numerically closest to the user ID in the format of tubes: {userID, current PoA ID, current IP address}. This can be done either by a longest prefix matching (LPM) assignment or other kind of mapping (e.g. by hash function). If user A wishes to be reached by other users, it can store/advertise and update its current location (its tube) to a live overlay node whose ID is numerically closest to A. A request to locate user A will be routed to a node whose ID is numerically closest to A. This node has already stored the current location of user A when A advertised its location. From the stored information, the requester can reach A no matter where A is. E. Update Update should be a function of time and/or location that is normally represented by the IP address of PoA. Update time interval (or overhead) is reverseproportional to the freshness of the location information. In P2P system, a peer has to store its tube each time it logs into the system. Peers may refresh this information but not frequently, for example every one hour. Otherwise, the

entry would be stale. If a user moves to another location with a different IP address and Partition ID, or after some time interval, the user will update its location information to its name manager (i.e. the node stores the tube). Note that peers are classified into fixed and mobile categories. Only fixed peers store information (i.e. tubes) so that the PNR service will be more reliable. If MNs change their PoAs or IP addresses too frequently, we propose that update is a function of partition ID. A partition composes of a number of nodes/PoAs that are close to each other. In fact, a partition definition to support mobility could be a mobile pattern, which means that if there are more handover operations between two PoAs, they could be classified in the same partition. Moving within a partition of a MN in a short period does not need to update to other partitions. Since partition changes are less frequent than PoA changes, the update overhead could be reduced. Moreover, the location information of MNs will more consistent because the time between two partition updates is longer. Alice

Move & Join (3)

Bob Join (1)

Locate BOB (5)

Location Update (2,4)

amongst nodes in a cluster can be done easier, introduce minimum latency and often be LAN traffic. IV. PERFORMANCE EVALUATION To evaluate the performance of PNR service over MIP, we setup different roaming scenarios: (1) MIP near: the MN is near the HA, (2) MIP far: the MN is more than twothirds the diameter of the network away from the HA, and (3) MIP mid: the MN is in between (1) and (2). We also implemented Tapestry [15] for overlay performance comparison. We used transit-stub network topologies that were generated by the GT-ITM network generator [23] to evaluate the architecture. Each topology has 1020 nodes, composed of 2 transit domains of 6 nodes, each transit node has 7 stub domains with an average of 12 nodes each. We used the shortest path latency as the IP layer latency. F. Routing Efficiency 1) Hop Length Hop Length =

D N

Overlay Hops

is the average latency of an overlay hop in ms.

In MIP, Hop Length is the average latency from CH and MN when tunnelling via HA

Map(Bob)

Map(Bob)

Query “closest” NameServer

S

S

S

S

Bob’s Current Address (6)

Figure 2: An illustration of PNR operation

Figure 2 illustrates the operation of PNR service. Step 1) Bob joins the overlay Step 2) Bob uses a number of universal mappings (e.g. hash functions) to determine live overlay nodes, and publishes his location at all these nodes. In Figure 2, there are 3 mappings. Step 3) Bob moves and joins a different part of the overlay. Step 4) Bob uses the same hash functions to re-publish his new location. Step 5) Alice wants to find Bob. She uses the same mapping and Bob’s name to find the nodes that stores Bob's location. The high number of mappings will increase locality and fault tolerance for the system because a requester can reach nearby and multiple tubes. However, in the evaluation section, we use only one uniform hash function and map to the LPM node. Partition size: If there are more than n tubes that a fixed node can manage, there should be a mechanism for load balancing between fixed nodes. Using Geo-LPM clustering, nodes inside a cluster often belong to a physical network. Therefore, load balancing and data replication

Figure 3: Average Hop Length

As can be seen from Figure 3, Geo-Tech, which composes of Geo-LPM and Geo-Partitioning, has lower average hop length compared to both Tapestry and MIP (mid and far). MIP routing efficiency depends on the distance between MN and HA. 2) Relative Delay Penalty

RDP =

∑D D

Overlay

Avg. RDP is the average of RDP

Physical

Relative Delay Penalty (RDP) or Routing Stretch is the basic index to measure the routing efficiency. RDP is defined as the ratio of the total distance between a source and a destination by going through the overlay network (DOverlay), to the distance between the same source and the same destination in the underlying network (DPhysical).

This is significant in that Geo-Partitioning allows MNs move fast within its partition and update less frequently. If we keep the same update frequency, PNR reduces overhead because nodes moving inside a partition will have only local effect. We could increase the Keepalives frequency inside a partition and reduce the frequency of HA update. In so doing, we can improve the freshness of information while keeping the overhead low. V. RELATED WORK

Figure 4: Average Relative Delay Penalty

RDP of MIP is greater than 1 and varies according to the distance between MN and HA. From Figure 4, we can see that our proposed overlay Geo-Tech introduces much lower RDP than Tapestry. In the implementation of the overlays either using our proposed overlay or Tapestry, the distance to find a MN’s location is the distance from the CH to a node that stores the tube. We do not use pointers (or shortcuts) as in [2] even though it might reduce the overlay delay, for following reasons: i) Pointers are cached, that should be cleared after some time because of the limited buffer size, unless the location information is updated regularly. ii) Even the information is updated periodically, when other CHs request the location of a MN, if the information at the root is not yet up-to-dated. The information at the pointers would be inconsistent. G. Mobility Management Efficiency Overhead mainly relates to the frequency that nodes send Keepalives message to detect the status of other nodes. However, this parameter often contradicts to the freshness of the information, e.g., nodes may move or leave the network but other nodes can not discover these changes before next few Keepalives intervals. Additionally, overhead also depends on the efficiency of information propagation from the PoA to the HA.

Figure 5: Partition changes vs. Distance between PoAs

Figure 5 shows the percentage of partition changes compared to the distance between Proxies. When MNs change PoAs (or proxies) within 30 ms, Geo-Partitioning can save more than 90% of update overhead. This is because the proxies are still under the same partition. The result was calculated based on the smallest/lowest partition with 64 ms threshold. If mobility management area covers higher level partitions, the result will be further improved.

Tapestry, a famous P2P system provides deterministic search mechanisms to store and retrieve data items based on logical node ID relationships. In the Tapestry system, each node is assigned a unique 128-bit identifier (node ID) randomly when it joins the system. A Tapestry node has to maintain a routing table R that has log 2 N rows and (2b1) columns, where N is the number of overlay nodes and 2b base. At row n of the routing table R, each entry of (2b-1) columns points to a node whose node ID shares with the present node ID the first n digits but (n+1)th digit has the value of the column order. The entry contains the IP address of one of potentially many nodes whose node ID has the appropriate prefix. In practice, a node is chosen that is close to the present node, according to the proximity metric (proximity neighbour selection: PNS method) [24]. If no node is known with a suitable node ID, then the routing table entry is left empty. Node IDs and keys are considered as a sequence of digits with base 2b. A node normally forwards the message to a node whose node ID shares with the key a prefix that is at least one digit (or b bits) longer than the prefix that the key shares with the present node ID. If no such node is known, the message is forwarded to a node whose node ID shares a prefix with the key as long as the current node, but is numerically closer to the key than the present node ID in its routing table or leaf set. Tapestry is decentralised, self-organizing, and efficient in terms of the number of application-level hops taken on a search path. However, physical correlation is not taken into account in overlay search path decisions, neighbouring peers on the overlay may actually be some distance apart in the underlying network. This leads to high end-to-end latency and an inefficient use of the underlying network resources. Landmarking is a method to detect the underlying network infrastructure in choosing overlay communication paths. It has been used in binning [25] and Global Network Positioning (GNP) [26] to achieve the underlying network awareness. The technique uses a small number of wellknown nodes, called “landmarks”, as a reference frame for other nodes to position them in the Internet. Each node only needs to measure its distance to these landmarks. ”Landmarking” is simple and reduce the latency, and generates low overhead. However the method might cause hotspots at the landmarks in large-scale systems. More over, if the landmarks are unavailable, the entire system is affected and non-self-organizing. To discover neighbours, Waldvogel et al. retrieve “neighbors of candidate neighbors” to search for a better candidate neighbour for the new node [27]. The neighbour b

of the new node will be the best found candidate neighbour. However this process may be time consuming because searching is done in an unstructured manner. GeoPartitioning is efficient in terms of the number of steps/time taken to reach the destination regions. Geo-Partitioning for neighbour discovery is similar to the process of going towards the region of the closest landmark in binning [25]. However, Geo-Partitioning has next-level landmarks (o-router) arranged in the local region to achieve higher precision location. O-routers in our work cooperate with each other to provide this geographical partitioning feature. Therefore the problem of fixed landmarks can be avoided, e.g., the unavailability of o-routers will affect only the local region. Geo-Partitioning scheme helps clusters to discover their neighbours precisely with O(logM) complexity. VI. CONCLUSIONS We introduce a Peer Name Resolution service on top of the efficient overlay to support reachability and mobility. The service is decentralised and self-managing. It is scalable and supports fast moving due to the geographical hierarchical management of Geo-Partitioning. The simulation results show that our proposed overlay causes low delay and overhead to support mobile users. VII. REFERENCES [1] C. Perkins, "IP Mobility Support," IETF, October 1996. RFC 2002. [2] B. Y. Zhao, L. Huang, A. D. Joseph, and J. D. Kubiatowicz, "Rapid Mobility via Type Indirection," Proceedings of the Third International Workshop on Peer-to-Peer Systems (IPTPS'04), San Diego, CA, 2004. [3] F. Dabeck, M. F. Kasshoek, D. Karger, R. Morris, and I. Stoica, "Wide-are cooperative storage with cfs," In 18th ACM Symposium on Operating Systems Principles, 2001. [4] P. Druschel and A. Rowstron, "PAST: a large-scale, persistent peerto-peer storage utility," Hot Topics in Operating Systems, 2001. Proceedings of the Eighth Workshop on, 2001. [5] J. Kubiatowicz, "Oceanstore: An architecture for global-scale persistent storage," Proc. Of ASPLOS, 2000. [6] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. Katz, and J. Kubiatowicz, "Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination," 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001), 2001. [7] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Applicationlevel multicast using content-addressable networks," Proc. 3rd International Workshop on Networked Group Communication,, 2001. [8] S. Banerjee, B. Bhattacharjee, and C. Kommareddy, "Scalable application layer multicast," Proc. ACM Sigcomm, 2002. [9] J. Jannotti, D. Gifford, K. Johnson, M. Kaashoek, and J. O’Toole, "Overcast: Reliable Multicasting with an Overlay Network," Proc.

[10]

[11] [12]

[13] [14]

[15]

[16] [17]

[18] [19] [20] [21] [22]

[23] [24]

[25]

[26] [27]

4th Symposium on Operating Systems Design and Implementation, 2000. A. Rowstron, A.-M. Kermarrec, M. Castro, and P. Druschel., "Scribe: The Design of a Large-Scale Event Notication Infrastructure," Proc. of the 3rd Int. Workshop on Networked Group Communication (NGC'01), 2001. L. F. Cabrera, M. B. Jones, and M. Theimer, "Herald: Achieving a Global Event Notication Service," Proc. of the 8th Workshop on Hot Topics in Operating Systems, Elmau, Germany, 2001. I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H. Balakrishnan, "Chord: a scalable peer-to-peer lookup protocol for Internet applications," Networking, IEEE/ACM Transactions on, vol. 11, pp. 17-32, 2003. S. Ratnasamy, P. Francis, M. Handley, and R. Karp, "A Scalable Content-Addressable Network," ACM SIGCOMM, 2001. A. Rowstron and P. Druschel, "Pastry: Scalable, Distributed Object Location and Routing for Large-Scale Peer-to-Peer Systems," In IFIP/AC International Conference on Distributed Systems Platforms (Middleware), 2001. B. Y. Zhao, J. Kubiatowicz, and A. Joseph, "Tapestry: An infrastructure for fault-tolerant wide-area location and routing," University of California at Berkeley, Computer Science Department Tech. Rep. UCB/CSD-01-1141, 2001. H. Le, D. Hoang, and A. Simmonds, "A Self-Organising Model for Topology-Aware Overlay Formation," "IEEE International Conference on Communications", Seoul, 2005. H. Le, D. Hoang, and A. Simmonds, "An Efficient Scheme for Locating Nodes in the Internet," Australian Telecommunications Networks & Applications Conference (ATNAC 2004), Sydney, Australia, 2004. B. Yang and H. Garcia-Molina, "Designing a super-peer network," Data Engineering, 2003. Proceedings. 19th International Conference on, 2003. B. Yang and H. Garcia-Molina, "Comparing Hybrid Peer-to-Peer Systems," Proceedings of the 27th International Conference on Very Large Data Bases, 2001. RFC1518, "An Architecture for IP Address Allocation with CIDR," Web page http://www.faqs.org/rfcs/rfc1518.html, 1993. RFC1519, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy.," Web page http://www.faqs.org/rfcs/rfc1519.html, 1993. L. Garces-Erce, K. W. Ross, E. Biersack, P. Felber, and G. UrvoyKeller, "TOPLUS: Topology Centric Lookup Service," Fifth International Workshop on Networked Group Communications (NGC'03), Munich, 2003. GT-ITM, "Georgia Tech Internetwork Topology Models," Web page: http://www.cc.gatech.edu/projects/gtitm/, 1997. M. Castro, P. Druschel, Y. C. Hu, and A. Rowstron, "Topologyaware routing in structured peer-to-peer overlay networks," FuDiCo 2002: International Workshop on Future Directions in Distributed Computing, University of Bologna Residential Center Bertinoro (Forli), Italy, 2002. S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologicallyaware overlay construction and server selection," INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 2002. T. S. E. Ng and H. Zhang, "Towards global network positioning," Proceedings of the First ACM SIGCOMM Workshop on Internet Measurement, 2001. M. Waldvogel and R. Rinaldi, "Efficient Topology-Aware Overlay Network," in Proceedings of ACM HotNets-I, 2002.