INS: Intentional Naming System (original) (raw)

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.

• Name 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.
• Late 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:
• Domain Space Resolvers (DSRs). Names are administratively scoped with administrative zones, much like DNS names. The default scope for an intentional name is the zone in which it was created, e.g., lcs.mit.edu. Each domain will have a set of "external" resolvers (DSRs) that will exchange information in a concise way about services in its domain that are reachable from the outside.
• Partitioned virtual spaces. Since names need not be hierarchical within an administrative zone (in general they could be hierarchies of orthogonal attributes and values), we partition the entire namespace amongst INRs, with each INR having to only resolve for a subset of all the active virtual spaces in a domain. A virtual space is an arbitrary, application- or user-chosen description of the "class" to which a name belongs, such as "cameras," "printers," "fax machines," "students in 6.033 in spring 2000," and so forth. DSRs maintain a soft-state cache of active (and dormant) INRs in a domain and a mapping between virtual spaces and INRs.
  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.

Available from the NMS papers page. The design and implementation of INS v1.0 appeared at ACM SOSP 17 in December 1999: