Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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: Need for naming service that is 2/25 Describe What to look for, not Where to find it Expressive Responsive Robust Easily configurable INS- February 2002 Vincent Matossian CS545 naming language Simple and lightweight Hierarchy of Attributes and Values allows 3/25 Small set of operators nodes providing a service to describe what they provide Consumers to describe what they require INS resolution architecture designed independently of the query language INS- February 2002 Vincent Matossian CS545 overview 4/25 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 INS- February 2002 Vincent Matossian CS545 system architecture 5/25 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 INS- February 2002 Vincent Matossian CS545 name specifiers • Hierarchical arrangement of attribute value pairs •Providers announce descriptive names • Clients make queries –Attribute-value matches –Wildcard matches –Ranges 6/25 INS- February 2002 Vincent Matossian CS545 discovering names Updates contain: 7/25 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. INS- February 2002 Vincent Matossian CS545 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 8/25 INS- February 2002 Vincent Matossian CS545 resolver network 9/25 INRs self-configure to form a spanning tree overlaynetwork 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 INS- February 2002 Vincent Matossian CS545 late binding Mapping from name to location can change rapidly Overlay routing protocol uses triggered updates Resolver performs lookup-and-forward Two styles of message delivery 11/25 lookup(name) is a route; forward along route Anycast Multicast INS- February 2002 Vincent Matossian CS545 intentional anycast lookup(name) yields all matches Resolver selects location based on advertised service-controlled metric Tunnels message to selected node Application-level vs. IP-level anycast 12/25 E.g., server load Service-advertised metric is meaningful to the application INS- February 2002 Vincent Matossian CS545 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 13/25 Shared tree, rather than per-source trees Enables more than just receiver-initiated group communication INS- February 2002 Vincent Matossian CS545 robustness Decentralized name resolution and routing in “serverless” fashion Names are weakly consistent, like network-layer routes Routing state is soft 14/25 Routing protocol with periodic & triggered updates to exchange names Expires if not updated Robust against service/client failure No need for explicit de-registration INS- February 2002 Vincent Matossian CS545 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 15/25 INS- February 2002 Vincent Matossian CS545 routing Protocol Scalability Name-tree at resolver vspace=camera Routing updates for all names 16/25 vspace=5th-floor Delegate this to another INR vspace = Set of names with common attributes Virtual-space partitioning: each resolver now handles subset of all vspaces INS- February 2002 Vincent Matossian CS545 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 18/25 INS- February 2002 Vincent Matossian CS545 applications Location-dependent mobile applications 19/25 Floorplan: An map-based navigation tool Camera: A mobile image/video service Load-balancing printer TV & jukebox service Sensor computing Network-independent “instant messaging” INS- February 2002 Vincent Matossian CS545 experimental results For ra=3; rv=3, na=2 and d=3; strings were one 16 bit character 20/25 Max = 900 lookups/sec Size of Name-tree varies Min = 700 lookups/sec From 0.5 MB to 3 MB! INS- February 2002 Vincent Matossian CS545 results 100 packets: 82B Header+586B payload 15-second periodic updates Time to discover a new network name is linear in the number of INR hops Order of 10’s ms 21/25 Local: [310ms,1.9s] Remote, same vspace: ~ 1s Remote, different vspace: 381 ms INS- February 2002 Vincent Matossian CS545 status Java implementation of INS & applications Scalability Wide-area implementation in progress Deployment 22/25 Several thousand names on single Pentium PC; discovery time linear in hops Integration with Jini, XML/RDF descriptions in progress Hook in wide-area architecture to DNS Standardize virtual space names (like MIME for devices/services) INS- February 2002 Vincent Matossian CS545 naming and service discovery 23/25 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 INS- February 2002 Vincent Matossian CS545 conclusions 1/2 24/25 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 INS- February 2002 Vincent Matossian CS545 conclusions 2/2 Three resolution types: Early binding: like DNS Late Binding: Java implementation performs: 25/25 Intentional anycast: returns optimal node providing service Intentional multicast: distributes to all names satisfying a query [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 INS- February 2002 Vincent Matossian CS545