Citation Context

...mation about a name-specifier: • The IP addresses for this name-specifier and a set of [port-number, transport-type] pairs for each IP address. The port number and transport type (e.g., HTTP [2], RTP =-=[38]-=-, TCP [34], etc.) are returned to the client to allow it to implement early binding. • An application-advertised metric for intentional anycast and early binding that reflects any property that the se...

Citation Context

...support for describing, locating, and gaining access to available services in these heterogeneous, mobile networks. While the packet routing problem in mobile networks has been extensively researched =-=[6, 32]-=-, the important functions of resource discovery and service location are only recently beginning to receive attention in the research community. We believe that this is an important problem to solve b...

Citation Context

...support for describing, locating, and gaining access to available services in these heterogeneous, mobile networks. While the packet routing problem in mobile networks has been extensively researched =-=[6, 32]-=-, the important functions of resource discovery and service location are only recently beginning to receive attention in the research community. We believe that this is an important problem to solve b...

Citation Context

...guring Web caches [20]. Estrin et al. build on this, exploring a diffusionbased approach to data dissemination in sensor networks using data attributes to instantiate forwarding state at sensor nodes =-=[15]-=-. Our intentional naming scheme has some features in common with these proposals, but differs in the details of the resolution, late binding and name dissemination processes, as well as the overall re...

Citation Context

...n structured names to express application parameters. This decision to leave IP unicast unmodified is based on the difficulties encountered in deploying other IP extensions, for example, IP multicast =-=[12]-=-, guaranteed services [10], and more recently, active IP networks [46]. In this sense, one may view the INS architecture as similar in philosophy to application-level anycast [3] and Web server select...

Citation Context

..., the group of sensors that have all recorded sub-zero temperatures. These two delivery services allow INS to achieve application-level anycast and multicast. In keeping with the end-to-end principle =-=[37]-=-, we leave the underlying network-layer addressing and routing of the IP architecture unchanged. Rather, our approach to providing these services is to layer them as an overlay network over unicast IP...

Citation Context

...ing information about a name-specifier: • The IP addresses for this name-specifier and a set of [port-number, transport-type] pairs for each IP address. The port number and transport type (e.g., HTTP =-=[2]-=-, RTP [38], TCP [34], etc.) are returned to the client to allow it to implement early binding. • An application-advertised metric for intentional anycast and early binding that reflects any property t...

Citation Context

...ess application parameters. This decision to leave IP unicast unmodified is based on the difficulties encountered in deploying other IP extensions, for example, 1P multicast [12], guaranteed services =-=[10]-=-, and more recently, active IP networks [46]. In this sense, one may view the INS architecture as similar in philosophy to application-level anycast [3] and Web server selection, which have recently g...

Citation Context

...iguration, INS resolvers self-configure into an application-level overlay network and clients can attach to any of them to resolve their requests and advertise services. These resolvers use softstate =-=[9]-=- periodic advertisements from services to discover 1 Note that we do not rely on Mobile IP [32] in INS. 187names and delete entries that have not been refreshed by services, eliminating the need to e...

Citation Context

...s. Despite allowing application-controlled routing metrics, INS presents a simple and well-defined service model for intentional anycast and multicast. In contrast to the active networks architecture =-=[41, 46]-=- and their naming counterpart, ActiveNames [43], where arbitrary code and services may be injected into the data path to customize the functions of an IP router or name resolver, INS resolvers do not ...

Citation Context

...ard the name and payload message through the overlay network to all of the network locations that announce a given name. In our current implementation, INRs use the distributed Bellman-Ford algorithm =-=[1]-=- to calculate shortest path trees to those end-nodes announcing the name. Unlike 3 For inter-INR communications we could have had the INRs use reliable TCP connections and send updates only for entrie...

Citation Context

... The intentional names are beginning to propagate throughout the INR network. An application discovering names sends a query to an INR (6), receives a set of names that match the name in query. MBone =-=[14]-=- or the 6Bone [17], INRs can be spawned or terminated and automatically adjust their neighbor relationships based on network conditions. They also implement load-balancing algorithms to perform better...

Citation Context

...he IETF Service Location Protocol (SLP) [44, 33], Sun’s Jini service discovery [21], the Simple Service Discovery Protocol [19], universal plug-and-play [42], and Berkeley’s service discovery service =-=[11]-=-. An important feature of our architecture is its potential for incremental and easy deployment in the Internet, without changing or supplanting the existing Internet service model. INS is intended fo...

Citation Context

...es that provide a service to precisely describe what they provide and consumers to easily describe what they require. Names based on attributes and values have been suggested before in other contexts =-=[5, 7, 13, 45]-=- and we draw upon previous work in this area in designing our naming language. While several complex query languages based on attributes and values exist in the literature, ours is particularly simple...

Citation Context

...te contains the following information about a name-specifier: The IP addresses for this name-specifier and a set of � �� � �℄ pairs for each IP address. The port number and transport type (e.g., HTTP =-=[2]-=-, RTP [38], TCP [34], etc.) are returned to the client to allow it to implement early binding. An application-advertised metric for intentional anycast and early binding that reflects any property tha...

Citation Context

...n early proposal to decouple names from object locations was described in a paper by O’Toole and Gifford [28], where they describe a content naming scheme and its application to Semantic File Systems =-=[18]-=-. Their design and application of content names is very different from ours, but the underlying philosophy is similar. The Discover system [39] is an HTTP-based document discovery system that uses que...

Citation Context

...g to forward a query to the servers that contain the result. Discover is document-centric and uses parallel processes to search servers and merge the results. Oki et al. introduce the Information Bus =-=[30]-=- to allow applications to communicate by describing the subject of the desired data, without knowing who the providers are. Other projects with a similar flavor include Malan et al.'s Salamander [25] ...

Citation Context

...ected using the early-bindingflag in the request), the INR returns a list of IP addresses corresponding to the name. This is similar to the interface provided by the Internet Domain Name System (DNS) =-=[27]-=- and most other existing service discovery systems, and is useful when services are relatively static. When there are multiple IP addresses corresponding to a name, the client may select an end-node w...

Citation Context

...n our environment, which is a dynamic and mobile network with little pre-configured infrastructure. In addition to the wealth of classical literature on naming in distributed systems (e.g., Grapevine =-=[4]-=-, Global Name Service [23], etc.), there has been some recent research in wide-area naming and resolution. For example, Vahdat et al. [43] present a scheme for ActiveNames, which allow applications to...

Citation Context

...s. Despite allowing application-controlled routing metrics, INS presents a simple and well-defined service model for intentional anycast and multicast. In contrast to the active networks architecture =-=[41, 46]-=- and their naming counterpart, ActiveNames [43], where arbitrary code and services may be injected into the data path to customize the functions of an IP router or name resolver, INS resolvers do not ...

Citation Context

...ency or available bandwidth, is ineffective from the point of view of many applications because it does not optimize the precise metric that applications require. For example, a network-layer anycast =-=[31]-=- to find the "best" printer on a floor of a building cannot locate the least-loaded printers. To remedy this, INS allows intentional anycast based on application-controlled metrics, where resolvers se...

Citation Context

...is a dynamic and mobile network with little pre-configured infrastructure. In addition to the wealth of classical literature on naming in distributed systems (e.g., Grapevine [4], Global Name Service =-=[23]-=-, etc.), there has been some recent research in wide-area naming and resolution. For example, Vahdat et al. [43] present a scheme for ActiveNames, which allow applications to define arbitrary computat...

Citation Context

...nt end-nodes. INRs replicate and form an overlay network among themselves, over which they send updates of valid names in the system. The name discovery protocol treats name information as soft-state =-=[9, 35]-=-, associated with a lifetime. Such state is kept alive or refreshed whenever newer information becomes available and is discarded when no refresh announcement is received within a lifetime. Rapid chan...

Citation Context

...metrics, INS presents a simple and well-defined service model for intentional anycast and multicast. In contrast to the active networks architecture [41, 46] and their naming counterpart, ActiveNames =-=[43]-=-, where arbitrary code and services may be injected into the data path to customize the functions of an IP router or name resolver, INS resolvers do not run arbitrary code nor embed any application-sp...

Citation Context

...lowing information about a name-specifier: The IP addresses for this name-specifier and a set of � �� � �℄ pairs for each IP address. The port number and transport type (e.g., HTTP [2], RTP [38], TCP =-=[34]-=-, etc.) are returned to the client to allow it to implement early binding. An application-advertised metric for intentional anycast and early binding that reflects any property that the service wants ...

Citation Context

...nd resolution and does not integrate resolution and routing. Furthermore, each resolver is independent in DistributedDirector, whereas they form a cooperating overlay network in INS. IBM’s “T Spaces” =-=[24]-=- enable communication between applications in a network by providing a lightweight database, over which network nodes can perform queries. However, this system has been optimized for relatively static...

Citation Context

...xample, 1P multicast [12], guaranteed services [10], and more recently, active IP networks [46]. In this sense, one may view the INS architecture as similar in philosophy to application-level anycast =-=[3]-=- and Web server selection, which have recently gained in popularity. INS uses a decentralized network of resolvers to discover names and route messages. To ease configuration, INS resolvers self-confi...

Citation Context

...plicated resolvers using soft-state message exchanges. These features distinguish it from other service discovery proposals made in the recent past, including the IETF Service Location Protocol (SLP) =-=[44, 33]-=-, Sun's Jini service discovery [21], the Simple Service Discovery Protocol [ 19], universal plug-andplay [42], and Berkeley's service discovery service [11]. An important feature of our architecture i...

Citation Context

... [30] to allow applications to communicate by describing the subject of the desired data, without knowing who the providers are. Other projects with a similar flavor include Malan et al.'s Salamander =-=[25]-=- and Talarian's SmartSockets [40]. These use a flat naming scheme, do not support late binding, and have statically configured resolvers. The idea of separating names from network locations was also p...

Citation Context

...ing scheme and its application to Semantic File Systems [ 18]. Their design and application of content names is very different from ours, but the underlying philosophy is similar. The Discover system =-=[39]-=- is an HTTP-based document discovery system that uses query routing to forward a query to the servers that contain the result. Discover is document-centric and uses parallel processes to search server...

Citation Context

...es, has self-configuring resolvers, and does not rely on IP multicast to perform discovery. Numerous attribute-based directory services have been proposed in the past. The X.500 distributed directory =-=[7, 36]-=- by the CCITT (now the ITU-T) facilitates the discovery of resources by using a single global namespace with decentralized maintenance. INS differs from X.500 in its goals and mechanisms to achieve re...

Citation Context

...nd resolution and does not integrate resolution and routing. Furthermore, each resolver is independent in DistributedDirector, whereas they form a cooperating overlay network in INS. IBM’s “T Spaces” =-=[24]-=- enable communication between applications in a network by providing a lightweight database, over which network nodes can perform queries. However, this system has been optimized for relatively static...

Citation Context

...In addition, INS implements a self-configuring resolver network based on network performance. An early proposal to decouple names from object locations was described in a paper by O'Toole and Gifford =-=[28]-=-, where they describe a content naming scheme and its application to Semantic File Systems [ 18]. Their design and application of content names is very different from ours, but the underlying philosop...

Citation Context

...es that provide a service to precisely describe what they provide and consumers to easily describe what they require. Names based on attributes and values have been suggested before in other contexts =-=[5, 7, 13, 45]-=- and we draw upon previous work in this area in designing our naming language. While several complex query languages based on attributes and values exist in the literature, ours is particularly simple...

Citation Context

...late binding, and have statically configured resolvers. The idea of separating names from network locations was also proposed by Jacobson in the context of multicast-based self-configuring Web caches =-=[20]-=-. Estrin et al. build on this, exploring a diffusionbased approach to data dissemination in sensor networks using data attributes to instantiate forwarding state at sensor nodes [15]. Our intentional ...

Citation Context

...plicated resolvers using soft-state message exchanges. These features distinguish it from other service discovery proposals made in the recent past, including the IETF Service Location Protocol (SLP) =-=[44, 33]-=-, Sun's Jini service discovery [21], the Simple Service Discovery Protocol [ 19], universal plug-andplay [42], and Berkeley's service discovery service [11]. An important feature of our architecture i...

Citation Context

...e the source and destination of the message. This string-based representation was chosen to be readable to assist with debugging, in the spirit of other string-based protocols like HTTP [16] and NNTP =-=[22]-=-. Levels of nesting are indicated by the use of brackets (� and ℄), and attributes and values are separated by an equals sign (�). The arbitrary use of whitespace is permitted anywhere within the name...

Citation Context

...n structured names to express application parameters. This decision to leave IP unicast unmodified is based on the difficulties encountered in deploying other IP extensions, for example, 1P multicast =-=[12]-=-, guaranteed services [10], and more recently, active IP networks [46]. In this sense, one may view the INS architecture as similar in philosophy to application-level anycast [3] and Web server select...

Citation Context

...es that provide a service to precisely describe what they provide and consumers to easily describe what they require. Names based on attributes and values have been suggested before in other contexts =-=[5, 7, 13, 45]-=- and we draw upon previous work in this area in designing our naming language. While several complex query languages based on attributes and values exist in the literature, ours is particularly simple...

Citation Context

...es that provide a service to precisely describe what they provide and consumers to easily describe what they require. Names based on attributes and values have been suggested before in other contexts =-=[5, 7, 13, 45]-=- and we draw upon previous work in this area in designing our naming language. While several complex query languages based on attributes and values exist in the literature, ours is particularly simple...

Citation Context

...plicated resolvers using soft-state message exchanges. These features distinguish it from other service discovery proposals made in the recent past, including the IETF Service Location Protocol (SLP) =-=[44, 33]-=-, Sun’s Jini service discovery [21], the Simple Service Discovery Protocol [19], universal plug-andplay [42], and Berkeley’s service discovery service [11]. An important feature of our architecture is...

Citation Context

... at the expense of maintaining connection state in the INRs. We do not explore this option further in this paper, but intend to in the future. 190traditional routing protocols that use the algorithm =-=[26]-=-, the INS architecture allows multiple identical names to exist in the system. The unique AnnouncerlD ensures that routes to identical names can be differentiated. In our implementation, applications ...

Citation Context

...late binding, and have statically configured resolvers. The idea of separating names from network locations was also proposed by Jacobson in the context of multicast-based self-configuring Web caches =-=[20]-=-. Estrin et al. build on this, exploring a diffusionbased approach to data dissemination in sensor networks using data attributes to instantiate forwarding state at sensor nodes [15]. Our intentional ...

Citation Context

...ames are beginning to propagate throughout the INR network. An application discovering names sends a query to an INR (6), receives a set of names that match the name in query. MBone [14] or the 6Bone =-=[17]-=-, INRs can be spawned or terminated and automatically adjust their neighbor relationships based on network conditions. They also implement load-balancing algorithms to perform better, by spawning new ...

Citation Context

...iguration, INS resolvers self-configure into an application-level overlay network and clients can attach to any of them to resolve their requests and advertise services. These resolvers use softstate =-=[9]-=- periodic advertisements from services to discover Note that we do not rely on Mobile IP [32] in INS. 187names and delete entries that have not been refreshed by services, eliminating the need to exp...

Citation Context

...t from other service discovery proposals made in the recent past, including the IETF Service Location Protocol (SLP) [44, 33], Sun’s Jini service discovery [21], the Simple Service Discovery Protocol =-=[19]-=-, universal plug-andplay [42], and Berkeley’s service discovery service [11]. An important feature of our architecture is its potential for incremental and easy deployment in the Internet, without cha...

Citation Context

...es that provide a service to precisely describe what they provide and consumers to easily describe what they require. Names based on attributes and values have been suggested before in other contexts =-=[5, 7, 13, 45]-=- and we draw upon previous work in this area in designing our naming language. While several complex query languages based on attributes and values exist in the literature, ours is particularly simple...

Citation Context

...e the source and destination of the message. This string-based representation was chosen to be readable to assist with debugging, in the spirit of other string-based protocols like HTTP [16] and NNTP =-=[22]-=-. Levels of nesting are indicated by the use of brackets ( [ and ] ), and attributes and values are separated by an equals sign (=). The arbitrary use of whitespace is permitted anywhere within the na...

Citation Context

...nd resolution and does not integrate resolution and routing. Furthermore, each resolver is independent in DistributedDirector, whereas they form a cooperating overlay network in INS. IBM's "T Spaces" =-=[24]-=- enable communication between applications in a network by providing a lightweight database, over which network nodes can perform queries. However, this system has been optimized for relatively static...

Citation Context

...ut a name-specifier: • The IP addresses for this name-specifier and a set of [port-number, transport-type] pairs for each IP address. The port number and transport type (e.g., HTTP [2], RTP [38], TCP =-=[34]-=-, etc.) are returned to the client to allow it to implement early binding. • An application-advertised metric for intentional anycast and early binding that reflects any property that the service want...

Citation Context

...s. Despite allowing application-controlled routing metrics, INS presents a simple and well-defined service model for intentional anycast and multicast. In contrast to the active networks architecture =-=[41, 46]-=- and their naming counterpart, ActiveNames [43], where arbitrary code and services may be injected into the data path to customize the functions of an IP router or name resolver, INS resolvers do not ...

Citation Context

...mplementation, INRs use the distributed Bellman-Ford algorithm [1] to calculate shortest path trees to those end-nodes announcing the name. Unlike traditional routing protocols that use the algorithm =-=[26]-=-, the INS architecture allows multiple identical names to exist in the system. The unique AnnouncerID ensures that routes to identical names can be differentiated. In our implementation, applications ...