Solution: Intentional Naming System (INS)

Responsiveness

Integrate name resolution and message routing to handle mobility

Robustness

Easy configuration

Name resolvers self-configure into overlay network

Expressiveness

Decentralized, cooperating resolvers

Names are intentional; apps know what, not where

Previous slide

Next slide

Back to first slide

View graphic version

Based on the nature of this environment and applications, we set ourselves four design goals:

Expressiveness: this follows from the fact that services are heterogeneous with a variety of capabilities, and applications often refer to WHAT they want, not WHERE. This motivates the reason we call our system an “intentional” naming system.

Because the environment is dynamic, INS must track changes rapidly.

Services, as well as name resolvers in INS are likely to be less reliable than in well-engineered networks, requiring a system that handles unreliable components.

Finally, we wanted to minimize manual configuration and maintenance of name resolvers; for example, in a room like this with several of our mobile computers and many networked services, we want something that can work without manual intervention or excessive configuration.