1 / 23

The Design and Implementation of an intentional naming system

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. the context and the goal. Dynamic and mobile network Idea is:

Download Presentation

The Design and Implementation of an intentional naming system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related