plement various name systems network realms, IPNL provides more eficient routing by assuming The Domain Name system(DNS) maps hostnames to IP a hierarchical topology with a single"middle realm". Packet for- resses [19]. A DNS name is mapped to an end-host as a result warding in both TRIAd and IPNl is similar to packet forward of an explicit request at the beginning of a transfer. In 23, the based on identifier stacks in 23. However, while with TRIAD and identifier-to-address mapping and the packet forwarding are tightl PNL the realm-to-realm path of a packet is determined during the integrated. DNS resolvers form a static overlay hierarchy, while DNS name resolution by network specific protocols, with i3 the servers form a self-organizing overlay ath is determined by end-hosts Active Names(AN) map a name to a chain of mobile code re- Multi-Protocol Label Switching(MPLS) was recently propose ponsible for locating the remote service, and transporting its re- speed-up the IP route lookup and to perform route pinning [1] sponse to the destination [30]. The code is executed on names at Similar to i3, each packet carries a stack of labels that specifies the resolvers. The goals of AN and 3 are different. In AN, applica- packet route. The first label in the stack specifies the next hop. Be- tions use names to describe what they are looking for, while in i3 fore forwarding a packet, a router replaces the label at the head of identifiers are used primary as a way to abstract away the end-host the stack. There are several key differences between 23 ocation. Also, while the goal of An is to support extensibility for While 23 identifiers have global meaning, labels have only local wide-area distributed services, the goal of i3 is to support basic meaning. In addition, MPLS requires special protocols to choose ommunication primitives such as multicast and anycast. and distribute the labels. In contrast, with 3 identifier stacks are The Intentional Naming System(INS) is a resource discovery chosen and maintained by end-hosts and service location system for mobile hosts [32]. INS uses an attribute-based language to describe names. Similar to i3 identi- 7. DISCUSSION AND FUTURE WORK fiers, INS names are inserted and refreshed by the application. INS also implements a late biding mechanism that integrates the name While we firmly believe in the fundamental purpose of 23- resolution with message forwarding. 23 differs from INS in that oviding a general-purpose indirection service through a single overlay infrastructure-the details of our design are preliminary from the network's point of view, an identifier does not carry any Besides exploring the security and efficiency issues mentioned in emantics. This simplicity allows for a scalable and efficient imple mentation. Another difference is that 23 allows end-hosts to control the paper further, there are areas that deserve significant additional the application-level path followed by the packets attention The rendezvous-based abstraction is similar to the ip multicast A general question is what range of services and applications can abstraction 6. An IP multicast address identifies the receivers of be synthesized from the fixed abstraction provided by 23. Until now a multicast group in the same 23 identifier identifies the tion (381, and a scalable reliable multicast protocol [181. While the multicast receivers. However, unlike IP which allocates a special range of addresses (ie, class D)to multicast, 23 does not put any initial experience with developing these applications has been very promising, it is too early to precisely characterize the limitations restrictions on the identifier format. This gives i3 applications the and the expressiveness of the i3 abstraction. To answer this ques- ability to switch on-the-fly from unicast to multicast. In addition, tion, we need to gain further experience witn using and deploying 3 can support multicast groups with heterogeneous receivers. Several solutions to provide the anycast service have been re- new applications on top of i3 cently proposed. IP Anycast aims to provide this service at the IP For inexact matching, we have used longest-prefix match. Inex layer [21. All members of an anycast group share the same IP act matching occurs locally, on a single node, so one could use an address. IP routing forwards an anycast packet to the member of reasonably efficient matching procedure. The question is which inexact matching procedure will best allow applications to choose the anycast group that is the closest in terms of routing distance. among several candidate choices. This must work for choosing Global IP-Anycast(GIA) provides an architecture that addresses based on feature sets(e.g, selecting printers ) location(e.g,se- the scalability problems of the original IP Anycast by differentiat ing between rarely used and popular anycast groups [7. In cop- recting users to facilities that match their credentials ). We chose rast to these proposals, i3 can use distance metrics that are only longest-prefix match mostly for convenience and familiarity, and it orts other basic communication primitives such as multicast and service composition. Estrin et al. have proposed an attribute-based data communi- Our initial design decision was to use semanticless identifiers cation mechanism, called direct diffusion, to disseminate data and routing; that is, identifiers are chosen randomly and routing is done based on those identifiers. Instead one could embed location tify what information they provide or are interested in. A user that semantics into the node identifiers. This may increase the eficiency wants to receive data inserts an interest into the network in the form of attribute-value pairs. At a high level, attributes are similar to but at the cost of making the overlay harder to deploy, manage, and load-balance identifiers. and interests are similar to triggers. However in di- rect diffusion the attributes have a much richer semantic and the Our decision to use Chord [26] to implement 23 was motivated rules can be much more complex than in 23. At the implementation y the protocol simplicity, its provable properties, and by our famil rarity with the protocol. However, one could easily implement 23 bors, while i3 uses a lookup service to store the triggers determined on top of other lookup protocols such as CAN (22), Pastry [2 and based on the trigger identifier TRIAD [3] and IpNL [9] have been recently proposed fits. For instance, using Pastry and Tapestry can reduce the latency the IPv4 address scarcity problem. Both schemes use DN of the first packets of a fow, since these protocols find typically rather than addresses for global identification. However, routes with lower latencies than Chord. However. note that once and IPNL make different tradeoffs. While TRIAd is more gen- the sender caches the server storing the receiver's trigger, there will eral by allowing an unlimited number of arbitrarily connected IP be little difference between using different lookup protocols, as the packets will forwarded directly via IP to that server. Studying theimplement various name systems. The Domain Name system (DNS) maps hostnames to IP ad￾dresses [19]. A DNS name is mapped to an end-host as a result of an explicit request at the beginning of a transfer. In ☎✝✆, the identifier-to-address mapping and the packet forwarding are tightly integrated. DNS resolvers form a static overlay hierarchy, while ☎✝✆ servers form a self-organizing overlay. Active Names (AN) map a name to a chain of mobile code re￾sponsible for locating the remote service, and transporting its re￾sponse to the destination [30]. The code is executed on names at resolvers. The goals of AN and ☎✝✆ are different. In AN, applica￾tions use names to describe what they are looking for, while in ☎✝✆ identifiers are used primary as a way to abstract away the end-host location. Also, while the goal of AN is to support extensibility for wide-area distributed services, the goal of ☎✝✆ is to support basic communication primitives such as multicast and anycast. The Intentional Naming System (INS) is a resource discovery and service location system for mobile hosts [32]. INS uses an attribute-based language to describe names. Similar to ☎✝✆ identi- fiers, INS names are inserted and refreshed by the application. INS also implements a late biding mechanism that integrates the name resolution with message forwarding. ☎✝✆ differs from INS in that from the network’s point of view, an identifier does not carry any semantics. This simplicity allows for a scalable and efficient imple￾mentation. Another difference is that ☎✝✆ allows end-hosts to control the application-level path followed by the packets. The rendezvous-based abstraction is similar to the IP multicast abstraction [6]. An IP multicast address identifies the receivers of a multicast group in the same way an ☎✝✆ identifier identifies the multicast receivers. However, unlike IP which allocates a special range of addresses (i.e., class D) to multicast, ☎✝✆ does not put any restrictions on the identifier format. This gives ☎ ✆ applications the ability to switch on-the-fly from unicast to multicast. In addition, ☎✝✆ can support multicast groups with heterogeneous receivers. Several solutions to provide the anycast service have been re￾cently proposed. IP Anycast aims to provide this service at the IP layer [21]. All members of an anycast group share the same IP address. IP routing forwards an anycast packet to the member of the anycast group that is the closest in terms of routing distance. Global IP-Anycast (GIA) provides an architecture that addresses the scalability problems of the original IP Anycast by differentiat￾ing between rarely used and popular anycast groups [17]. In con￾trast to these proposals, ☎✝✆ can use distance metrics that are only available at the application level such as server load, and it sup￾ports other basic communication primitives such as multicast and service composition. Estrin et al. have proposed an attribute-based data communi￾cation mechanism, called direct diffusion, to disseminate data in sensor networks [8]. Data sources and sinks use attributes to iden￾tify what information they provide or are interested in. A user that wants to receive data inserts an interest into the network in the form of attribute-value pairs. At a high level, attributes are similar to identifiers, and interests are similar to triggers. However, in di￾rect diffusion, the attributes have a much richer semantic and the rules can be much more complex than in ☎✝✆. At the implementation level, in direct diffusion, nodes flood the interests to their neigh￾bors, while ☎ ✆ uses a lookup service to store the triggers determined based on the trigger identifier. TRIAD [3] and IPNL [9] have been recently proposed to solve the IPv4 address scarcity problem. Both schemes use DNS names rather than addresses for global identification. However, TRIAD and IPNL make different tradeoffs. While TRIAD is more gen￾eral by allowing an unlimited number of arbitrarily connected IP network realms, IPNL provides more efficient routing by assuming a hierarchical topology with a single “middle realm”. Packet for￾warding in both TRIAD and IPNL is similar to packet forwarding based on identifier stacks in ☎✝✆. However, while with TRIAD and IPNL the realm-to-realm path of a packet is determined during the DNS name resolution by network specific protocols, with ☎✝✆ the path is determined by end-hosts. Multi-Protocol Label Switching (MPLS) was recently proposed to speed-up the IP route lookup and to perform route pinning [1]. Similar to ☎✝✆, each packet carries a stack of labels that specifies the packet route. The first label in the stack specifies the next hop. Be￾fore forwarding a packet, a router replaces the label at the head of the stack. There are several key differences between ☎✝✆ and MPLS. While ☎✝✆ identifiers have global meaning, labels have only local meaning. In addition, MPLS requires special protocols to choose and distribute the labels. In contrast, with ☎ ✆ identifier stacks are chosen and maintained by end-hosts. 7. DISCUSSION AND FUTURE WORK While we firmly believe in the fundamental purpose of ☎✝✆— providing a general-purpose indirection service through a single overlay infrastructure—the details of our design are preliminary. Besides exploring the security and efficiency issues mentioned in the paper further, there are areas that deserve significant additional attention. A general question is what range of services and applications can be synthesized from the fixed abstraction provided by ☎✝✆. Until now we have developed two applications on top of ☎✝✆, a mobility solu￾tion [38], and a scalable reliable multicast protocol [18]. While the initial experience with developing these applications has been very promising, it is too early to precisely characterize the limitations and the expressiveness of the ☎✝✆ abstraction. To answer this ques￾tion, we need to gain further experience with using and deploying new applications on top of ☎✝✆. For inexact matching, we have used longest-prefix match. Inex￾act matching occurs locally, on a single node, so one could use any reasonably efficient matching procedure. The question is which inexact matching procedure will best allow applications to choose among several candidate choices. This must work for choosing based on feature sets (e.g., selecting printers), location (e.g., se￾lecting servers), and policy considerations (e.g., automatically di￾recting users to facilities that match their credentials). We chose longest-prefix match mostly for convenience and familiarity, and it seems to work in the examples we’ve investigated, but there may be superior options. Our initial design decision was to use semanticless identifiers and routing; that is, identifiers are chosen randomly and routing is done based on those identifiers. Instead, one could embed location semantics into the node identifiers. This may increase the efficiency of routing, by allowing routes to take lower-latency ☎✝✆-level hops, but at the cost of making the overlay harder to deploy, manage, and load-balance. Our decision to use Chord [26] to implement ☎✝✆ was motivated by the protocol simplicity, its provable properties, and by our famil￾iarity with the protocol. However, one could easily implement ☎✝✆ on top of other lookup protocols such as CAN [22], Pastry [23] and Tapestry [12]. Using these protocols may present different bene- fits. For instance, using Pastry and Tapestry can reduce the latency of the first packets of a flow, since these protocols find typically routes with lower latencies than Chord. However, note that once the sender caches the server storing the receiver’s trigger, there will be little difference between using different lookup protocols, as the packets will forwarded directly via IP to that server. Studying the