A Dependable Global Location Service using Rendezvous on Hierarchic Distributed Hash Tables J. Risson1, S. Qazi1, T. Moors1, A. Harwood2 1 University of New South Wales, 2University of Melbourne email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Abstract should proceed without interruption. These A location service is the part of a naming dependability properties are only satisfied by hierarchic architecture that maps identifiers to network addresses. DHTs. Previously, hierarchic DHTs have been used for Ideally, the identifiers are globally unique, persistent content locality, path locality or administrative and semantic-free. It has been acknowledged that autonomy [5-10]. Distributed Hash Tables (DHTs) enable, for the first The problem is that the leading hierarchic DHTs time, the use of semantic-free identifiers in massive, embed semantics in identifiers. DHT identifiers are global networks. We argue that hierarchy is essential for commonly chosen from a circular key space, for dependability in massive, geographically distributed example [0, 2160-1]. Sometimes the identifier itself DHTs. Existing hierarchic DHTs embed location determines which DHT in the hierarchy owns it . information in identifiers. Consequently, if identifiers Sometimes a “ring identifier” indicates the path from the move between DHTs in the hierarchy, then the changes root DHT to the target DHT . Consequently, if an always propagate to the root DHT. This Location object with a persistent identifier moves between lower Information Plane (LIP) design is the first hierarchic layer DHTs, the changes propagate up to the root DHT. DHT that contains "moves and changes" within the By analogy, the DNS root has taught us to minimize the lower layers of the hierarchy. It protects the root DHT impact of “moves and changes”. using the rendezvous abstraction. We show how it This paper presents the first hierarchic DHT design supports global internet telephony networks based on that protects the root DHT from “moves and changes”. If the Session Initiation Protocol (SIP). an object moves between two DHTs, then the changes only propagate to the lowest common parent DHT. Such 1. Introduction a design is necessary for a dependable, massive, A location service maps identifiers to network geographically distributed location service that is addresses. It is a key part of emerging name resolution tolerant of operational “moves and changes”. architectures [1, 2]. It is increasingly recognized that the Section 2 shows that hierarchic DHTs are important best identifiers for a massive location service are for dependability. It outlines the design goals for a globally unique, persistent and semantic-free [3, 4]. A global location service and explains the “moves and persistent object identifier does not change when an changes” problem in existing hierarchic DHTs. Section object moves or is replicated. A semantic-free identifier 3 lays out the design of the Location Information Plane does not contain information about the organization, (LIP). By using the rendezvous abstraction with domain or set of nodes in which the object is located. semantic-free identifiers, it mitigates the “moves and Such identifiers are free from the ownership and legal changes” problem. Section 4 shows how LIP supports disputes that hamper human-friendly internet names. internet telephony. Section 5 reviews related work on Distributed Hash Tables (DHTs) make it possible to name resolution, peer-to-peer internet telephony and use semantic-free, flat identifiers in internet-scale name hierarchic DHTs. Section 6 concludes. resolution architectures [3, 4]. We argue that hierarchy is important for dependability in massive, globally 2. Requirements and Scope distributed DHTs. Consider two large internet data 2.1. Location Service centers, each with thousands of nodes that are to A location service maps identifiers to addresses. In participate in a global DHT. There should be strict the Session Initiation Protocol (SIP), the location service guarantees that these nodes do not maintain neighbor provides a mapping from an address-of-record to a relationships with distant ephemeral nodes. If one of the contact address, both of which are Uniform Resource sites is isolated from the network, lookups within the site Identifiers . In Globe, the location service mapped object handles (Uniform Resource Names) to contact addresses (Uniform Resource Locators) . Location 2.2. Hierarchic DHTs are Dependable services here are not geographic databases. The design assumes the need for DHTs and hierarchy A location service is a subset of name resolution. at the outset. DHTs were assumed, despite the existence Currently, there is primarily one level of name resolution of alternatives for large-scale name resolution. For in the internet: from user-level domain names to IP example, Globe  also provided a global location addresses. Distilling years of research on names, service, intended for one billion users with one thousand identifiers and addresses, Balakrishnan et al. argued that objects each. It mapped persistent object handles onto a there should be up to three levels of name resolution: static hierarchy of nodes. The recent DHTs let the set of user-level descriptors to service identifiers (SIDs); SIDs nodes to grow more easily. to endpoint identifiers (EIDs); and EIDs to IP addresses Hierarchic DHTs are assumed because of the . Fig. 1 illustrates. combination of dependability, scale and geographic distribution. Scale alone does not justify hierarchy. For User level name User level name Application layer example, even if one billion location records each took 1kbyte of memory, the global service could reasonably Service ID (SID): be implemented on a few thousand commodity PCs in a User/Object mobility single DHT. Similarly latency does not justify hierarchy. Session layer For example, some might argue that a lookup in a single Endpoint ID (EID): global DHT might involve unnecessary international Host/Network mobility hops, whereas an extra layer of national DHTs would Transport layer ensure that national queries remain within national IP address IP address boundaries. However, one-hop DHTs would avoid these unnecessary hops. They have been shown to scale to as Domain Name System Layered Naming Architecture many as one million nodes . Figure 1. Internet Name Resolution  To see how dependability, scale and geographic distribution together motivate hierarchy, consider two Users and objects are best identified by a flat, users within one organization on one site. If the site is globally unique, persistent, semantic-free SID [3, 4]. disconnected from the internet, the two users should be Such identifiers enable objects, tied to hosts and able to communicate using the location service. If the domains in the current internet, to move and replicate location service relies on a single global DHT that across administrative boundaries. They do not change transits the site, then it will be disrupted after site failure when an object moves or is replicated. Semantic-free or recovery. The disruption may be acceptable if there identifiers are not humanly readable – they avoid legal are only a handful of nodes on the site – they quickly disputes over ownership. As a result, SIDs should be reform a local ring. If there are many hundreds or chosen from flat, unstructured namespaces. DHTs have thousands of nodes, recovery will take much longer. been proposed for the resolution of SIDs because However, if the location service is served by a subtended “DHTs allow us, for the first time, to contemplate using DHT within the site, then local queries and updates are flat namespaces” in internet-scale architectures . not interrupted. EIDs were proposed to avoid overloading IP In the remainder of this paper, we assume the DHT addresses [4, 11]. Currently, an IP address represents hierarchy of Fig. 2. User and infrastructure nodes can both the identity of a network interface and its location. participate in DHT rings which support the location Mobility and multi-homing of hosts is frustrated. EIDs service queries and updates. “Rings” here are for easy alleviate this problem by decoupling the transport and reference only – we do not restrict the design to DHTs network layers. Again, it has been proposed that these with circular identifier spaces. Ring A is a single global EIDs are flat [11, 12]. The resolution of EID to IP ring. Rings B to D illustrate the hierarchy that might be address requires changes to the transport layer whereas required in a massive administrative domain. It might be SIDs are managed by higher layers. a service provider in which the location service supports This paper concentrates then on the core location many millions of internet telephony users. Ring E might service function: resolving flat identifiers to network be a single organization where the user PCs participate addresses. We assume that the mapping from user-level in the DHT that is the location service. Ring F illustrates names to SIDs is available by some out-of-band process. an ad hoc location service, such as might be provided for For example, the SID might be sourced from DNS, an internet telephony users at a conference. Here, the two email, a web page, or a peer-to-peer query response. stable nodes in Ring F that connect to the global Ring A are optional. The uplinks between rings are logical links, internal to nodes. For example, node x may be owned by a service provider to handle location queries and updates different domain, these references become obsolete. in Ring B. It also participates in the global Ring A and References to a persistent SID would remain intact. acts as a gateway to it. Alternatively, one might embed locality in global ring and object identifiers. This approach stumbles when A objects move between nodes and rings. For example, x Mislove and Druschel proposed a hierarchic DHT in F which the ring identifier is a concatenation of all ring x identifiers from the root to the leaf . In this case, if B E objects move amongst the leaf rings, then the global ring bears the brunt of the update load. Even worse, if the leaf ring moves to a different part of the hierarchy, or C D DHT merges with other leaf rings, then the global ring sees a Node Domain large number of instantaneous updates. The current internet has over 353 million hosts . To support mobility at this scale, it would be better that the global Figure 2. Global Hierarchy of DHT Rings ring not see every update. Garcés-Erice et al. proposed a One can envisage counter-arguments to say that hierarchy where the responsible subgroup in the top dependability does not require hierarchic DHTs. For layer of the hierarchy is determined by the object’s key example, it has been suggested that, for robustness, “all . If the object moves to a different sub-tree, then a nodes without connectivity constraints should join the new key is required. Such an identifier is not persistent. global ring” . The implicit assumption is that there is a risk of a network partition when there are only a few 2.4. Rendezvous enables Object Mobility gateway nodes between rings. However, our design One fundamental mechanism is used in some form in assumes that all nodes in the global ring and all gateway many of the designs mentioned thus far [1, 5, 14]: nodes are dependable. A small number of gateways rendezvous. Although elegant, the idea that a sender and adequately protect against individual node failures. receiver meet in the network is hardly new. The novelty Alternatively, one might argue that some DHTs here is in the support for the global hierarchy of DHT inherently support network locality, so hierarchy is rings of Fig. 2. The significance is that, by coupling unnecessary. For example, the nodes in Pastry’s routing rendezvous with hierarchic DHT rings, the global table are “close” with high probability . However, a location service will: Pastry node is deemed to have failed when it loses • Expand more easily than location services on static contact with its “leaf set”, that is, with its immediate trees . DHTs can self-organize when nodes join neighbors in the nodeID space. In a single, global DHT, and leave. these neighbors are “remote” with high probability. • Be more dependable than single DHT rings. Because Consider the case where many Pastry nodes on one site of the hierarchy, an intra-site DHT is not interrupted instantaneously lose contact with a global Pastry if the site is partitioned from the network. Similarly, overlay. In such a site failure, it is likely that the leaf sets it is not interrupted when other large site rings in the are not repaired. Since the leaf sets are important for the same organization fail. final hop towards a target key, there are no guarantees of • Enable object mobility while protecting the global finding a particular key, even if it is on a live node on ring. Unlike a leading hierarchic DHT , the global the same site. Such locality improves routing efficiency, ring is rarely involved when objects move between not dependability. rings. The design supports mobility because of the 2.3. Existing Hierarchic DHTs do not support use of rendezvous with semantic-free tags. Object Mobility Unlike other rendezvous-based designs for semantic- How does a query from one subtended ring find a free name resolution , LIP does not need changes location record in another ring? One option is to use the below the transport layer. It can be deployed domain name to refer to the remote ring and a locally incrementally and privately within administrative significant identifier for the target object in the remote domains for massive location update and query rates. It ring. In taking this approach, the emerging internet supports ad hoc networks of commodity devices without telephony standards  localize the location service. stable infrastructure. It supports a global location service Persistence requirements are also violated. References to by aggregating nodes from participating organizations. a user or object may be widely dispersed on web sites or in private caches. When the user or object moves to a 2.5. Goals 20,000 nodes with 2 Gbytes of memory each can support The following design goals for the location service the global index. address dependability (1-2), latency (3), scalability (4). Each ring also stores “gateway records”. For 1. Support high availability. The mean availability of example, the gateway record for Ring C is shown in an authoritative DNS server is 98.64% , so the Ring A (Fig. 3). The ‘anycast’ EID for Ring C maps to expected downtime for replicated servers is 97 the EIDs of the specific nodes that participate in both minutes per year. Because the location service is a Ring A and Ring C. The benefit of the gateway record is subset of name resolution, the service downtime that the gateways can be changed without altering the attributed to stable location servers should be vast number of object forwarding records. Although the considerably less than this DNS benchmark. authoritative gateway record is homed at one node, it 2. Support disconnected administrative domains and can be replicated across nodes in the ring to reduce sites. For high availability, the intra-site and intra- lookup hop count. The memory overheads of this domain location queries should remain strictly replication are modest, given that there are only 5000 within the site and domain respectively. Ad hoc POPs. meetings of user devices should be possible without O C C (C) server infrastructure. 3. Incur delays suitable for existing location services. Given that the location service is a subset of name 3 4 A resolution, its latency should at least fall within 5 E (E) measured DNS bounds: median latencies of less 7 than 100 msecs; 90th-percentile latencies of up to a few seconds . The location service in internet 6 8 C telephony needs to support 99th percentile call setup 2 B ? (?) 1 O E delays of 1.5 secs  (Section IV-D). Query 4. Scale to support the global number of 9 administrative domains, identifiers, owners and O O lookups per day. Mockapetris estimated that modern D 10 E name resolution systems need to deal with 1012 O O identifiers, 1010 owners, and 1011 lookups per day SID EID Contact address . Ballani and Francis estimated that there are O O 5000 service provider points of presence (PoPs) Contact record maps SID for object O to the contact address for object O globally, based on 200 tier-1 and tier-2 ISPs and an O O Forwarding record maps SID for object O to the target EID average of 25 PoPs per service provider . O E Assuming four gateways per POP, the design should Forwarding record maps SID for object O to the anycast EID for ring E cater for a global ring of at least 20,000 nodes. E (E) Gateway record maps the EID for ring E to the EID of ring E gateways ? (?) 3. Design Default forwarding record pointing to the upward gateways 3.1. Architecture Fig. 3 captures the overall Location Information Figure 3. Architecture of the Location Information Plane (LIP) architecture. Ring A is the global ring. Plane (LIP) Nodes from different organizations participate in the The “contact records” – those with the actual contact global ring. These same nodes are the gateways to address for a particular object - will generally be stored subtended rings (B and C). at leaf nodes. There are no contact records stored There are several kinds of location records stored in directly in the global ring. Records in the global ring are the LIP. Object “forwarding records” each map a SID to either forwarding or gateway records. When a contact an EID. We assume that SIDs and EIDs are 160 bits in record moves regularly between Rings D and E, it may length – a common DHT assumption that balances the be more efficient to store the authoritative contact risk of key collisions against memory requirements for address in the parent Ring C. the index . The 1012 objects that need to be visible 3.2. Queries globally dominate the lookup table in the global ring. To illustrate how a query moves through the LIP, The EID identifies the next ring on the path to the consider the query for the contact address of object O, contact address. Can the global ring store this number of initiated on a node in Ring B of Fig. 3. This initial forwarding records? If they are stored naively, they description assumes that there is no caching and that all consume 40 bytes per record, or 40 terabytes for a non- rings are implemented using one-hop DHTs. replicated, insecure global index. In approximate terms, Initially, the originating node queries the node on 4.1. Motivation Ring B that is responsible for the object’s SID (Step 1 in What motivates proposals for DHT-based internet Fig. 3). It does not exist on that node, so the query is telephony ? Bryan, Lowekamp and Jennings referred to the gateways to the parent Ring A (Step 2). lamented that Voice over IP (VoIP) and instant The vertical lines between Ring A and Ring B each messaging (IM) deployments are frustrated by central represent a gateway node that participates in the two servers . They cited several scenarios: small DHT rings. All nodes in Ring B know the set of EIDs organizations don’t trust VoIP and IM services to central that represent gateways to the parent ring. Because the servers in other organizations; there may not be path to the global ring is used regularly, the set of connectivity to central servers due to disaster or gateways EIDs is “corrected-on-use” – a proactive equipment failure; participants in an ad hoc meeting multicasting scheme is not required. don’t want the hassle of configuring or connecting to a The gateway then hunts for the object’s forwarding central server; access to central servers may be record within the global ring (Step 3). It indicates that prohibited because of government censorship or the contact record for object O is in Ring C or one of its competitive carrier tactics; central servers are inherently subtended rings. The same gateway node iteratively unscalable and failure-prone. Singh and Schulzrinne polls for Ring C’s gateway record (Step 4). Step 4 will advocated a DHT-based design for its scalability, often not be required when the gateway records are dependability and ease of configuration . They multicast amongst all nodes in the same ring. Ring B’s acknowledged that DHT-based designs suit multiple gateway chooses one of the Ring C gateways and deployment scenarios: in internet-wide peer-to-peer forwards the query to it (Step 5). We assume that the networks; in internet telephony service providers to query response is to traverse the same sequence of distributed load; or for enterprise, telephony networks gateways in the reverse direction – Ring C’s gateway within a LAN. Matthews and Poustchi also focused on will forward the query response directly to Ring B’s permanent enterprise telephony networks without costly, gateway. Iterative routing was chosen over recursive central servers . Johnston proposed standardization routing for intra-ring queries. There is no difference of a peer-to-peer location service for internet telephony, between the two in terms of hop count – both require 6 so as to bypass central servers . unidirectional hops in Ring A. However, iterative routing gives Ring B’s gateway greater operational 4.2. Network Scenarios visibility. If there is a fault on the lookups for the How might LIP fit within an internet telephony forwarding records or gateway records, then the Ring B network? One important protocol for internet telephony gateway can more easily determine the location of the is the Internet Engineering Task Force’s Session fault when routing is iterative. Initiation Protocol (SIP) . SIP is primarily about the The query then traverses Ring C with a similar control plane - initiating, updating and terminating lookup sequence (Steps 6-8). The forwarding record and sessions - rather than the data plane. In a SIP the gateway record for object O in Ring C both refer to deployment, “a location service is used by a SIP redirect Ring E. or proxy server to obtain information about a callee's The query completes its forward path in Ring E. One possible location(s). It contains a list of bindings of of the gateway nodes between Rings C and E polls the address-of-record keys to zero or more contact forwarding record to find the EID of the node addresses” . responsible for the location record. This node provides the target contact address and sends the query response Consider a call from Alice to Bob in Fig. 4 . The via the same path of gateways (Steps 10, 8, 5 and 2 in SIP INVITE message is sent from Alice’s user agent to the reverse direction). the Atlanta.com proxy. The Atlanta.com proxy queries the Domain Name System (DNS) for the IP address of the Biloxy.com proxy and sends the INVITE message to 4. Application: LIP for Internet Telephony it. The Biloxi.com SIP proxy server submits Bob’s Having reviewed the LIP design, we now show how address-of-record <sip:email@example.com> to the location it supports a massively distributed internet telephony service, which responds with his contact address network. We first consider motivation. What is the value <sip:firstname.lastname@example.org>. The IETF SIP specifications do of DHTs for internet telephony? Secondly, we review not mandate a particular protocol for the location architecture. How does LIP fit with the network, data, service. Though proxies and other intermediaries are and performance measures of internet telephony? used in most deployments, they are not mandatory – if Finally, we show how the LIP design supports an Alice could locate Bob, it is entirely feasible that they internet telephony call. could signal directly between themselves to establish a session. 5. Related Work Atlanta.com Biloxi.com The LIP design was inspired by application research DNS a Location Service on name resolution and peer-to-peer internet telephony. Signalling It also builds on the growing base of hierarchic DHTs. Otherc Path SIP Proxy Server LIP was influenced by prior work on name resolution, and more specifically on location services. Alice SIP User Agent Bob Globe separated its naming service from its location service via a single indirection, the object handle . Figure 4. Internet Telephony Signaling in the Session Van Steen and Ballintijn used a static hierarchy of nodes Initiation Protocol  – Alice calls Bob via the in Globe, noting that in practice each node would Atlanta.com proxy then the Biloxi.com proxy. probably be implemented by local clusters. LIP is a more LIP can therefore support the SIP location service in scalable, dynamic stack of rings. Instead of local multiple ways. LIP rings could be used to massively clusters, LIP uses massively distributed DHTs. Like the scale just the location service within one domain for a “layered naming architecture” , LIP uses two service provider. If SIP user agents could interact semantic-free identifiers - the SID and the EID. i3 used directly with LIP, then they could establish local ad hoc rendezvous and semantic-free identifiers on a single sessions amongst themselves without a SIP proxy. Chord ring for service composition and multicasting Alternatively, if users were in possession of persistent, . Unlike the “layered naming architecture”  and i3 semantic-free identifiers for other users, then they could , LIP does not require changes to the transport layer. use LIP to establish sessions globally. Because DHTs provide good load balancing, fault tolerance and easier administration, Cox et al. used them 4.3. Design: LIP in an Internet Telephony Call in a DNS design, DDNS . However at the time, One of several possible LIP deployment scenarios is DHTs typically used O(log n) hops per lookup – they as a global location service. Fig. 5 shows the sequence concluded that such DHTs cannot meet DNS latency of SIP signaling and LIP queries to setup an internet requirements. SFR used a single global Chord ring to telephony session from a node in Ring B to a node in provide location services . CoDoNs built on a single Ring E. The various optimizations, like replication of Pastry ring to provide DNS services. Both SFR and gateway records and caching, are omitted. All nodes in CoDoNs used caching to reduce the latency of O(log n) Rings A to E can initiate LIP queries and forward SIP DHTs. In contrast, LIP relies on caching and O(1) DHTs messages. to reduce latency, multi-ring hierarchy to cope with O C C (C) correlated (site/domain) failures, and rendezvous for easier mobility of objects. 3 4 A LIP responds to open issues recently identified by E (E) peer-to-peer internet telephony researchers. There have 5 been two SIP prototypes that use DHTs to reduce 7 reliance on intermediaries [24, 25]. Both use single 6 8 C Chord rings. One uses iterative lookups , the other is 2 B recursive . Johnston argued the need for 1 ? (?) O E standardization of a global location service for SIP- Query based internet telephony and hinted that DHTs are a part 9 O O of the solution . For future work, Bryan, Lowekamp LIP Query SIP Call Setup 10 E and Jennings  had proposed an investigation of hierarchical routing to interconnect SIP P2P realms. Figure 5. Call Setup using SIP and LIP. Singh and Schulzrinne identified the need for low Given ample bandwidth, low churn rates and latency DHTs for internet telephony . Accordion DHTs, intra-ring signaling usually requires LIP differs from prior proposals for hierarchic DHTs only one hop (Steps 2, 5, 8 and 10). However, in in its motivation, its use of semantic-free keys, its massive rings with high churn rates, intra-ring signaling application to both structured and unstructured DHTs, involves O(log n) nodes. However, the call setup path and its support for object mobility. Superficially, LIP is still only traverses one hop. The originating node in each most similar to the hierarchic rings of Mislove and ring iterates around the ring until it can send the SIP call Druschel . However, there are important differences: setup message directly to the gateway or destination they confined their work to structured DHTs; they node in the same ring. embedded semantics of the ring hierarchy in Ring IDs; their motivation was path and content locality for  M. Walfish, H. Balakrishnan, and S. Shenker, "Untangling the web from DNS," Proc. First Symp. on Networked Systems Design and administrative control. Garcés-Erice et al. proposed Implementation NSDI'04, 225-238, March 29-31, 2004. hierarchic DHTs to improve routing performance . To  H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish, "A Layered Naming Architecture for the move an object to a different group, a new key needs to Internet," SIGCOMM'04, Portland, Oregon, USA, Aug 30-Sept 3, 2004. be assigned. When groups merge, keys and their related  A. Mislove and P. Druschel, "Providing administrative control and autonomy in structured peer-to-peer overlays," The 3rd Int'l Workshop on objects will move to different nodes. Coral used multiple Peer-to-Peer SystemsJune 9-12, 2004. rings but did not guarantee data locality . Skipnet   L. Garces-Erice, E. W. Biersack, K. Ross, P. Felber, and G. Urvoy-Keller, builds a hierarchy of rings but embeds locality in keys, "Hierarchical P2P Systems," Proc. ACM/IFIP Int'l Conf. on Para. and Dist. Comp.Aug, 2003. violating the requirement for persistent, semantic-free  B. Zhao, Y. Duan, L. Huang, A. Joseph, and J. Kubiatowicz, "Brocade: keys. Ratnasamy et al. grouped nodes into ‘bins’ to landmark routing on overlay networks," First Int'l Workshop on Peer-to- Peer Systems IPTPS'02March, 2002. minimize lookup latencies . Brocade associated  M. Freedman and D. Mazieres, "Sloppy Hashing and Self-Organizing nodes with nearby supernodes, to reduce point-to-point Clusters," Proc. 2nd Int'l Workshop on Peer-to-Peer Systems IPTPS '03February, 2003. routing distances a minimize bandwidth .  N. Harvey, M. B. Jones, S. Saroiu, M. Theimer, and A. Wolman, LIP’s advantages over prior hierarchic DHTs stem "SkipNet: A Scalable Overlay Network with Practical Locality from its use of rendezvous with semantic-free keys. If Properties," Proc. Fourth USENIX Symp. on Internet Technologies and Systems USITS'03March, 2003. LIP rings merge, or if an object moves between lower  S. Ratnasamy, M. Handley, R. Karp, and S. Shenker, "Topologically- layer rings, then updates are usually not required in the aware overlay construction and server selection," Proc. IEEE Infocom, 3- 12, 2002. global ring. LIP was motivated by dependability, in  R. Moskowitz and P. Nikander, "Host Identity Protocol Architecture," particular, locality during catastrophic failure rather than IETF Internet Draft, <draft-moskowitz-hip-arch-06>, June 27, 2004. locality during normal routing. If one organization has  B. Ford, "Unmanaged Internet Protocol: taming the edge network management crisis," ACM SIGCOMM Computer Communication two massive site rings and one site fails, then LIP Review, vol. 34, iss. 1, pp. 93-98, 2004. ensures that lookups within the remaining site’s ring are  A. Gupta, B. Liskov, and R. Rodrigues, "Efficient Routing for Peer-to- Peer Overlays," First Symp. on Networked Systems Design and not interrupted. It also ensures that recovery traffic on Implementation NSDI March, 2004. the remaining site is minimized when the failed site  A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems," IFIP/ACM recovers. At the same time, LIP inherits the strict Middleware 2001Nov, 2001. guarantees in  on data and path locality during normal  "Domain Survey Information, Internet Systems Consortium," available at routing. http://www.isc.org/index.pl?/ops/ds/, accessed October, 2005  I. Stoica, D. Adkins, S. Zhuang, and S. Shenker, "Internet indirection infrastructure," IEEE/ACM Trans. on Networking, vol. 12, iss. 2, pp. 205- 6. Conclusions  218, 2004. J. Pang, J. Hendricks, A. Akella, R. De Prisco, B. Maggs, and S. Seshan, We presented a design for a global Location "Availability, usage and deployment characteristics of the domain name Information Plane (LIP) to manage globally unique, system," Proc. of the 4th ACM SIGCOMM conference on internet measurement, 1-14, 2004. persistent, semantic-free identifiers. It is the first design  J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS Performance and that simultaneously minimizes the impact of catastrophic the Effectiveness of Caching," ACM SIGCOMM Internet Measurement Workshop, November, 2001. failures and operational “moves and changes”. The  T. Eyers and H. Schulzrinne, "Predicting internet telephony call setup hierarchic DHT design limits DHT maintenance traffic delay," Proc. of the First IP Telephony WorkshopApril, 2000.  P. Mockapetris, "The internet and identifiers," ACM SIGCOMM during and after catastrophic failures. The rendezvous Computer Communication Review, vol. 35, iss. 4, pp. 325-325, 2005. abstraction protects the critical root of the DHT  H. Ballani and P. Francis, "Towards a global IP anycast service," Proc. of hierarchy from “moves and changes”. These two ACM SIGCOMM 2005Aug 22-26, 2005.  J. Li, J. Stribling, R. Morris, and F. Kaashoek, "Bandwidth-efficient properties – dependability and object mobility – are management of DHT routing tables," Proc. 2nd Symposium on Networked essential for location services in practical, global Systems Design and ImplementationMay 2-4, 2005.  S. Baset, H. Schulzrinne, E. Shim, and K. Dhara, "Requirements for SIP- networks. based peer-to-peer internet telephony," IETF Internet Draft, draft-baset- sipping-p2preq-00Oct 28, 2005.  D. Bryan, B. Lowekamp, and C. Jennings, "SOSIMPLE: a serverless, Acknowledgment standards-based P2P SIP communication system," Proc. of the We thank Dr. Egemen Tanin (University of international workshop on Advanced Architectures and Algorithms for Internet Delivery and ApplicationsJune 15, 2005. Melbourne) for discussions during the formative stages  K. Singh and H. Schulzrinne, "Peer-to-peer internet telephony using SIP," of this paper. Proc. of the international workshop on network and operating systems support for digital audio and videoJune 13-14, 2005.  P. Matthews and B. Poustchi, "Industrial-Strength P2P SIP," IETF References Internet Draft, vol. draft-matthews-sipping-p2p-industrial-strength-00.txt,  M. van Steen, F. Hauck, P. Homburg, and A. Tanenbaum, "Locating 2005. Objects in Wide-Area Systems," IEEE Communications Magazine, 1998.  A. Johnston, "SIP,P2P and internet communications," IETF Internet Draft  J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. (expired) draft-johnston-sipping-p2p-ipcom-01, Mar 17, 2005. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol,"  R. Cox, A. Muthitacharoen, and R. Morris, "Serving DNS using a Peer- IETF Request for Comment 3261, 2002. to-Peer Lookup Service," First Int'l Workshop on Peer-to-Peer Systems (IPTPS)March, 2002.
Pages to are hidden for
"A Dependable Global Location Ser"Please download to view full document