The Design and Implementation of an intentional naming system

1. The Design and Implementation of an intentional naming system William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley MIT Lab of Computer Science Presenter: Vincent Matossian - February 2002

2. the context and the goal • Dynamic and mobile network • Idea is: • Describe What to look for, not Where to find it • Need for naming service that is • Expressive • Responsive • Robust • Easily configurable Vincent Matossian CS545

3. naming language • Simple and lightweight • Small set of operators • Hierarchy of Attributes and Values allows • nodes providing a service to describe what they provide • Consumers to describe what they require • INS resolution architecture designed independently of the query language Vincent Matossian CS545

4. overview • Decentralized network of resolvers (to discover names and route messages) self-configured into an application-level overlay network • Use of intentional names for routing • soft-state periodic advertisements from services • Not yet meant for WAN internet Vincent Matossian CS545

5. system architecture • Every request goes to an INR (resolver) • INRs self-configure into a spanning-tree overlay network using INR-to-INR round trip time measurements • INRs route clients to services Vincent Matossian CS545

6. name specifiers • Hierarchical arrangement of attribute value pairs • Providers announce descriptive names • Clients make queries • Attribute-value matches • Wildcard matches • Ranges Vincent Matossian CS545

7. discovering names • Updates contain: • IP address + [port number, transport-type] • Application-advertised metric for late binding • Next-hop INR and INR-to-INR round trip time • AnnouncerID for differentiation between similar names • Advertisement on specific port • Name information is treated as soft-state  no need for registration, deregistration • Information dissemination done using a routing protocol that includes periodic updates and triggered updates. Vincent Matossian CS545

8. name lookup • Lookup returns a name-record which includes IP address of destination advertising name + set of “routes” to next-hop INRs • Name trees store correspondence between name-specifiers and name-records • Lookup • Tree-matching algorithm • AND operations among orthogonal attributes • Polynomial-time in number of attributes • O(nd) where n is number of attributes and d is the ½ depth of tree Vincent Matossian CS545

9. resolver network • INRs self-configure to form a spanning tree overlay-network over UDP tunnels • INR-pings send a small name between INRs and measure the time it takes to process this message and get a response • Domain Space Resolver (DSR) keeps track of all INRs in the system Vincent Matossian CS545

10. late binding • Mapping from name to location can change rapidly • Overlay routing protocol uses triggered updates • Resolver performs lookup-and-forward • lookup(name) is a route; forward along route • Two styles of message delivery • Anycast • Multicast Vincent Matossian CS545

11. intentional anycast • lookup(name) yields all matches • Resolver selects location based on advertised service-controlled metric • E.g., server load • Tunnels message to selected node • Application-level vs. IP-level anycast • Service-advertised metric is meaningful to the application Vincent Matossian CS545

12. intentional multicast • Use intentional name as group handle • Each resolver maintains list of neighbors for a name • Data forwarded along a spanning tree of the overlay network • Shared tree, rather than per-source trees • Enables more than just receiver-initiated group communication Vincent Matossian CS545

13. robustness • Decentralized name resolution and routing in “serverless” fashion • Names are weakly consistent, like network-layer routes • Routing protocol with periodic & triggered updates to exchange names • Routing state is soft • Expires if not updated • Robust against service/client failure • No need for explicit de-registration Vincent Matossian CS545

14. load Balancing and Scaling • Name processing dominates lookup processing 1 Mb/s link • Virtual space: application-specified set of names that share some attributes in common Vincent Matossian CS545

15. vspace=camera vspace=5th-floor Delegate this to another INR routing Protocol Scalability Name-tree at resolver • vspace = Set of names with common attributes • Virtual-space partitioning: each resolver now handles subset of all vspaces Routing updates for all names Vincent Matossian CS545

16. message header format B: Binding bit flag {early, late} D: Delivery bit flag {anycast, multicast} Hop limit sets a time to live for each message Cache lifetime : 0 disallows cache Vincent Matossian CS545

17. applications • Location-dependent mobile applications • Floorplan: An map-based navigation tool • Camera: A mobile image/video service • Load-balancing printer • TV & jukebox service • Sensor computing • Network-independent “instant messaging” Vincent Matossian CS545

18. experimental results For ra=3; rv=3, na=2 and d=3; strings were one 16 bit character Max = 900 lookups/sec Min = 700 lookups/sec Size of Name-tree varies From 0.5 MB to 3 MB! Vincent Matossian CS545

19. results 100 packets: 82B Header+586B payload 15-second periodic updates Local: [310ms,1.9s] Remote, same vspace: ~ 1s Remote, different vspace: 381 ms Time to discover a new network name is linear in the number of INR hops Order of 10’s ms Vincent Matossian CS545

20. status • Java implementation of INS & applications • Several thousand names on single Pentium PC; discovery time linear in hops • Integration with Jini, XML/RDF descriptions in progress • Scalability • Wide-area implementation in progress • Deployment • Hook in wide-area architecture to DNS • Standardize virtual space names (like MIME for devices/services) Vincent Matossian CS545

21. naming and service discovery • Wide-area naming • DNS, Global Name Service, Grapevine • Attribute-based systems • X.500, Information Bus, Discover query routing • Service location • IETF SLP, Berkeley service discovery service • Device discovery • Jini, Universal plug-and-play • Intentional Naming System (INS) • Mobility & dynamism via late binding • Decentralized, serverless operation • Easy configuration Vincent Matossian CS545

22. conclusions 1/2 • Presented an intentional naming scheme where applications describe what they are looking not where to find data. • Expressiveness: Achieved through a simple naming language based on av-pairs • Responsiveness: by integrating name resolution and message routing coping with mobility and performance changes • Robustness: periodic service advertisements and soft-state name dissemination protocols between replicated resolvers • Ease of configuration: by deploying self-configuring name resolvers Vincent Matossian CS545

23. conclusions 2/2 • Three resolution types: • Early binding: like DNS • Late Binding: • Intentional anycast: returns optimal node providing service • Intentional multicast: distributes to all names satisfying a query • Java implementation performs: • [100s,1000s] lookups/sec depending on name complexity • Dissemination of new names in tens of milliseconds • Name space partitioning improves the scalability of INS • No WAN deployment; No security; Improve name matching operations and soft-state dissemination protocol to take into account importance of certain names Vincent Matossian CS545