INS is a new naming system intended for naming and discovering a variety of resources in future networks of devices and services. It has the following interesting characteristics about the way it names resources and the way names are resolved.
syntax. Names are intentional; they
describe application intent in the form of
properties and attributes of resources and data, rather
than simply network locations of objects (which is the
way most traditional naming systems like the DNS work
today). Names express and satisfy queries about
information and their providers. One can think of these
names as properties and queries expressed in a language
similar to XML. Intentional names are query expressions
(in INS, they are called name-specifiers) in a
carefully designed query language supporting exact
matches of arbitrary application-specified attributes
(variables) and values. Our design also includes other
operators for range matches.
However, the name resolution architecture in INS is largely independent of the naming syntax (except in how lookups work) and incorporate ideas that generalize to other ways of naming resources as well.
Self-configuring resolvers. INS resolvers are called Intentional Name Resolvers, or INRs. In any domain, INRs configure themselves into an application-level overlay network based on performance metrics and exchange meta-data about names and the corresponding network locations. The configuration protocols will enable the system to work with no manual intervention, incorporating machinery to bootstrap INRs, spawn and terminate INRs, maintain neighbor relationships, and perform load management across both the local and wide-area Internet.
binding. INS advocates the integration of name
resolution and message forwarding. In this mode,
applications name resources they seek (in any syntax,
e.g., in XML-like descriptions) and these messages, piggybacked
with application payload, traverse the resolver
overlay network (configured automatically by the above
protocols) and get looked-up and forwarded amongst the
INRs before being delivered to the node(s) that satisfy
the names. Thus, resolvers affect routing decisions,
leading to a flexible data delivery mechanism that allows
applications to track rapid change (e.g., user or network
mobility), changing data attributes. The level of
indirection provided by these names allows us to handle
mobility, group communication, and service replication.
It also allows applications to influence routing
decisions by having resolvers route on the basis of
application-specific metrics like load on servers.
Of course, INS also supports early bindings of names to locations, where an INR returns a list of end-hosts (typically a set of IP addresses) corresponding to the name, without forwarding messages to them. This is useful, in ensuring that an application can bind to the same end node(s) if it so desires; for example, after using INS to get to the closest, least loaded printer near you, you'd like to have all the pages of your file print out on the same printer!
Name discovery. To learn and share information about names, the INRs communicate via a name discovery protocol. The protocol uses periodic updates to convey name information, and uses triggered updates for fast changes. In addition, INS incorporates a novel optimization to implicitly learn about names by inferring information from source message headers of messages traversing the INR network. To achieve robustness and availability, INRs exchange name information much like IP routers exchange network routes, treating names as soft state, using periodic refreshes to achieve eventual consistency on change.
Scaling. In addition to achieving the above properties, an important challenge in INS is scaling to a large number ("millions") of names and services across the Internet. Unlike IP routing which relies almost solely on hierarchy to scale well, INS cannot, because of names aren't necessarily hierarchical. To combat this, INS uses two ideas to scale the system:
To summarize, the INS resolver architecture consists of a wide-area inter-domain resolver network of DSRs and an intra-domain self-configuring resolver network composed of INRs. It integrates resolution and forwarding that tracks change, and uses soft-state name discovery protocols that enable robust operation.
Students: William Adjie-Winoto | Jeremy Lilley | Anit Chakraborty | Jorge Rafael Nogueras
Faculty: Hari Balakrishnan
Alumni: Elliot Schwartz
Available from the NMS papers page. The design and implementation of INS v1.0 appeared at ACM SOSP 17 in December 1999:
|CSAIL||E E C S||M I T|
M. I. T. Computer Science and Artificial Intelligence Laboratory · 32 Vassar Street · Cambridge, MA 02139 · USA