1. Device (Addressing &) Discovery Prasun Dewan Department of Computer Science University of North Carolina dewan@unc.edu

2. 2 Addressing Devices vs. Traditional Servers n Sever and network is always around - static address n Centralized heavyweight scheme acceptable to give install and give unique addresses to servers n Client expected to know traditional server address u imap.cs.unc.edu n Discovery phase possible u www.cnn.com u logical name to physical name can be bound dynamically n Devices may be dynamically added on ad-hoc networks - dynamic address n With so many dynamic devices and ad-hoc networks lightweight decentralized scheme needed n Client may not know or care about device server address u print to the nearest printer u turn off all light bulbs n Implies later binding and thus a discovery phase

3. 3 0 Addressing n Control point and device get address u Use a DHCP server u Else use Auto IP n What is Auto IP? u IETF Draft Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network n What steps does it take? u Pick an address in 169.254/16 range u Check to see if it is used (ARP) u Periodically check for DHCP server Could use DNS and include DNS Client

4. 4 Discovery : Active and Passive n SSDP Solution: u Hybrid approach u Advertisement has lifetime F Can simulate pure push model u HTTP over UDP F What if message gets lost? F Must send UDP message 3 times F Solution over TCP planned Client Server

5. 5 Issues raised by UPnP discovery n Scaling problem of multicast-based discovery u Auto Shut off problem n Simple-minded search u Attribute-based n Lack of access control

6. 6 Jini Discovery ClientServer Service Object Attributes NS Service Object Attributes Service Object Attributes Java Type Template lookup() Service Object Attributes join() discover() announce()

7. 7 Jini Discovery n Discovery is of Java object reference u Can be used directly to invoke methods or register for events u Language-based solution n Can search by type u But type is a Java interface/class F E.g. edu.unc.cs.appliances.Printer F Can use inheritance for matching edu.unc.cs.appliances.Output F Versioning problems Client type version may not be same as Server’s

8. 8 Jini Discovery n Service has typed attributes u Color Printing, local printer name,physical location,document format, paper size, resolution, access list u Some of this info may come from third-party (local admin) F Physical location, local name, access list n Client specifies u Type of service u Template of attributes F Non-null values are filled in by discovery E.g. user-interface

9. 9 Jini Lookup n Special name server expected on network F Servers join Can register object by value (local) or reference (remote) Service has lease F Clients lookup Proxy of reference object loaded Copy of by value objects loaded –May behave as smart proxy Class of the object may also be dynamically loaded F Servers and clients discover it using (LocalDisovery object, which) multicasts F Discovery service multicasts to announce existence

10. 10 Jini Discovery ClientServer Service Object Attributes NS Service Object Attributes Service Object Attributes Java Type Template lookup() Service Object Attributes join() discover() announce() n What if no name server?

11. 11 Peer Discovery ClientServer Service Object Attributes Service Object Attributes Java Type Template lookup() Service Object Attributes join() discover() announce() n What if no name server? u Client uses some special method in server to find server? u Server uses some special method in client to announce service? u Actually, can reuse methods of lookup-based discovery.

12. 12 Peer Lookup n What if no name server? u Client pretends to be a lookup service F multicasting announcement of service F replying to lookup service searches? u Servers send it join information F Can filter it ClientServer Service Object Attributes NS Service Object Attributes Service Object Attributes join() discover()? announce()

13. 13 Dual? n What if no name server? u Server pretends to be a name server F sending announcement of service F replying to lookup service searches. u Clients send it lookup information F Can filter it u Every lookup request sent to every server? ClientServer Service Object Attributes Service Object Attributes discover()? announce() Java Type Template lookup() NS

14. 14 Service Location Protocol n What if no name server? u Client multicasts lookup request rather than unicast u More network traffic? n SLP Address: IP address, port number, type- dependent path n Not bound to Java ClientServer Service Attributes Service Attributes announce() Type Template mlookup()

15. 15 SLP with Lookup and DHCP ClientServer Service Attributes NS Service Attributes Service Attributes Type Template lookup() Service Attributes join() DHCP register NS lookup (NS)

16. 16 No DHCP ClientServer Service Attributes NS Service Object Attributes Service Attributes Type Template lookup() Service Attributes join() discover() announce()

17. 17 Replicated Lookups ClientServer Service Attributes NS1 Service Attributes Type Template lookup() NS 2 discover() Service Attributes Service Attributes join() Service Attributes discover(l1) n Joins sent to all NS discovered. n Not considered desirable to discover all NS. Not a multicast!

18. 18 accounts legal Scoped Discovery ClientServer 1 Service 1 Attributes 1 NS1 Service 1 Attributes 1 Type Template lookup() NS 2 Service 1 Attributes Service 1 Attributes join() Server 2 Service 2 Attributes join() Service 2 Attributes 2 Service 2 Attributes 2 Service 2 Attributes announce (accounts) announce (legal) discover(legal)

19. 19 accounts legal Peer Scoped Discovery ClientServer 1 Service 1 Attributes 1 Service 1 Attributes 1 Type Template mlookup(legal) Server 2 Service 2 Attributes

20. 20 SLP Scaling n NS discovered through DHCP n Also through UDP-based multicast u Repeated multicasts list who has been found so far n NS replicated u Synchronized via multicasts of join to detected lookups u Lookups partitioned F Room 115 vs 150 F Legal vs. Account Payable F a la DNS u Partitions can overlap u Wide-area scaling? F Every service contacts every name server in partition discovered.

21. 21 Wide-Area Extension (WASRV) n Divide world into SLP domains n Each domain has u Advertising agent F Multicast services to other domains F Configuring necessary Only selected services multicast Otherwise everything shared u Brokering agent F Listens to multicasts from remote advertising agents F Advertises services to local domain

22. 22 WASRV Limitations addressed by SDS n Wide-area multicast “ill-advised” n Configuring necessary to determine what is multicast u Otherwise everything shared F Linear scaling

23. 23 Controlled Partitioning n Partitioning automatically selected u Based on query criteria? F Globe, OceanStore, Tapestry, Chord, Freenet, DataInterface F location = UNC  UNC server F location = UCB  Berkeley server u Works as long as single criteria F location = UNC & type = printer All printers and all UNC devices in one domain F type = printer & model = 2001 All printers and 2001 models and UNC devices in one domain F Popular criteria (2001 models) can lead to bottleneck

24. 24 Query Flooding n No controlled partitioning n Query sent to all partitions u Service announcement sent to specific (arbitrary or local) partition u These sent frequently n No control over query rate u Scaling problem

25. 25 Centralization n A single central name server u Napster, Web search engine u Multi criteria search u Bottleneck

26. 26 DNS Hybrid n Hierarchical scheme n A single central name server at root level u All queries and service announcements contact it n Forwards request to partitioned lower-level servers base d on single-criterion query n Works because u Positive and negative caching u Low update rates

27. 27 SDS Hybrid n Partitioning n Centralization n Query Flooding

28. 28 SDS Query Filtering n Service announcement given to specific NS node – the local domain node n Query given to specific NS node – the local domain node u NS advertisement on well known multicast address u Address can be used to find NS using expanding ring search F Increase TTL until found n From each NS all other nodes reachable n Information reachable from a neighbour is summarized u Summarization is lossy aggregation F Hashing F Can give false positives u Can direct query not satisfied locally to matching neighbours F Multiple neighbours because of false positives F Can do this in parallel F Intelligent query flooding u Recursive algorithm

29. 29 Mesh vs. Tree n Mesh u Need to detect cycles F TTL F Or give unique Ids to queries to avoid repetition n Tree u Can summarize information in one direction F Parent summarizes children u Upper nodes are bottlenecks F Centralization a la DNS F Queries start at any node rather than always at root F Upper nodes may not be contacted F Service announcements propagated to all ancestors F Bandwidth used for propagation bounded Less the bandwidth  more responsive to changes F Summaries propagated so lower load More concise summary  more query flooding

30. 30 Summarization Filters n All pass filter u Low update load u High query load F Must contact all neighbours n Send complete description to neighbour u No loss in aggregation u High update load u No flooding n Need something in between u False positives OK u False negatives not OK (those nodes not searched)

31. 31 Cntroid Indexed Terminals Filter n WHOIS++/LDAP n For each attribute send all values of that attribute u Service 1 F location = “UNC”, model = “2001” u Service 2 F location = “Duke”, model = “2000” u Summary F location: “UNC”, “Duke” F model: “2001”, “2000” u False Positives F location = “UNC”, model = “2000” F Location = “Duke”, model = “2001” u No false negatives

32. 32 Cross Terminals Filter n For each attribute description create hashes attribute cross products u Service F location = “UNC”, model = “2001” u Possible matching queries F location = “UNC” F model = “2001” F location = “UNC” & model = “2001” u If actual query hash equal to a possible matching query hash, then positive u Bound number of attributes considered to avoid exponential # of cross products u Must find cross products of query because which service attributes used in cross products unknown F Otherwise false negatives

33. 33 Bloom-filtered Cross Terminals n Given a list of hashes: u d 1, d 2,..d n n Create a compressed word of size L from hashing salts u s 1, s 2,..s n n Bit x is set if u hash (d i + s j ) mod L = x for some i, j n An item d is in list if u Hash (d + s j ) mod L is set for all j. n What happens when service deleted u reference count with each set bit

34. 34 False Positives in BCT n Cross products n Limiting number of attributes n Bloom filters

35. 35 Range queries n Query: u Location = University of * u Model > 2000 u Type = printer n Bloom filter elides query, ignores range attributes u Type = printer n Keeps list of false positives with queries u Negative caching

36. 36 Tree construction n Support multiple hierarchies n Can be specified by configuration file u Admin domains F edu, com n Computed automatically F Network topology Hops F Geographic location Distance n Query specifies which domain to consider in search. n Special primary domain guaranteeing coverage of all nodes.

37. 37 Tree construction n A node can serve multiple levels in the hierarchy n Child nodes can be dynamically added/deleted n Services and clients continuously listen for domain, address announcements n Replication for fault tolerance u Multicast address representing replicas n Replicas and parents listen for heart beats

38. 38 Other SDP Features n Security n Hierarchical rather than flat attributes

39. 39 SDP Security Kinds Kinds of security: n Access control u Arbitrary client cannot discover arbitrary service u Arbitrary clients and services can invoke NS methods (lookup() and join()) n Authentication u Clients, Services, and NS n Privacy u Service descriptions u Not queries or NS announcements

40. 40 Access Control Mechanisms Access control u Capability lists vs. access lists u Access lists for persistence F AC server keeps them F Client (not NS) contacts AC server u Derived cap lists for performance F A la open call returning file handler F Given to client by AC server after authentication

41. 41 Authentication Mechanisms n Trusted machine address, port number u Cannot use when variable address n Public key u Sender decrypts message with own private key u Authenticator encrypts message with sender’s public key u Used for Client and Server

42. 42 Privacy Mechanisms n Symmetric Encryption u Encryption and decryption key are the same u E.g. XOR, Blowfish n Asymmetric Encryption u Sender encrypts with receiver’s public key u Receiver decrypt’s with receiver’s private key u RSA n Performance: u Blowfish F Encryption: 2.0ms; Decryption: 1.7ms u RSA F Encryption: 15.5 seconds; Decryption: 142.5 ms (raising message to power of key) u DSA F Signature: 33.1 ms, Verification: 133.4ms n NS can get overloaded with asymmetric n How to establish symmetric key?

43. 43 SDS Privacy Mechanisms n Use asymmetric for establishing symmetric key for some tunable time period n Use symmetric key for sending info during that period.

44. 44 SDP Hierarchical Attributes n Service associated with XML DDT describing attributes n Join() describes hierarchical attributes u Must follow syntax specified by DDT u Can add tags http://www/~ravenben/printer.dtd print466; lws466 466 yes http://joker.cs/lws466

45. 45 SDP Hierarchical Attributes n Lookup describes hierarchical template() u yes n DDT for it? n Bound to a particular type?

46. 46 An Architecture for a Secure Service Discovery Service Steven Czerwinski, Todd Hodes, Ben Zhao, Anthony Joseph, Randy Katz UC Berkeley Internet Scale Research Group

47. 47 Outline n Intro n Architecture n Security n Wide Area n Conclusion

48. 48 Supporting Ubiquitous Computing n Ubiquitous Computing envisions… u Billions of computers and devices available to users u Devices seamlessly interact with all others u Networks and computers as an unobtrusive utility n One problem: Locating servers and devices u How can you locate a light bulb among billions? u Solution must be scalable, fault-tolerant, self-configuring, secure, and support wide-area n Existing solutions don’t adequately address needs

49. 49 A Secure Service Discovery Service n Services are applications/devices running in the network n One piece of the puzzle u Helps manage explosive growth of services u Aids in configuration by providing indirection u Aids in protecting user and services by providing security The Idea: A secure directory tool which tracks services in the network and allows authenticated users to locate them through expressive queries

50. 50 Berkeley Service Discovery Service 443 Phaser io.printer Soda/443 yes rmi://batman.cs czerwin@cs Where is a color printer? The SDS 443 Phaser “443 Phaser” io.printer yes XML Query Service Description

51. 51 Discovery Services n Discovery/Directory services are not new u Provide a mapping of attribute values to domain specific addresses u Examples: Telephone book, card catalogs, etc.. n Computer network discovery services u DNS u NIS u SAP u Globe u LDAP u Jini LookUp service

52. 52 Differentiating Discovery Services n Query Routing u Implicitly specified by the query (DNS, globe) n Queries u Query grammar complexity (LDAP vs. DNS) n Push (advertisements) versus pull (queries) u Pull only (DNS) vs. Push Only (SAP modulo caching) n Update rate u Short for mobility vs. long for efficient caching

53. 53 Discovery Services Cont. n Bootstrapping u “Well-known” local name (“www.”) u List of unicast addresses (DNS) u Well-known global/local multicast address (SAP, SLP) n Soft state vs. hard state u Implicit recovery vs. guaranteed persistence n Service data u Reference (globe) vs. content (SAP+SDP) n Security u Privacy and authentication

54. 54 Features of the Berkeley SDS n Hierarchical network of servers u Multiple hierarchies based on query types n Queries u Use XML for service descriptions and queries n Bootstrapping via Multicast announcements u Listen on well-known global channel for all parameters n Soft-state approach u State rebuilt by listening to periodic announcements n Secure u Use certificates/capabilities to authenticate

55. 55 The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Servers SDS Server Client “czerwin@cs”

56. 56 The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall “czerwin@cs” SDS Server SDS Servers Create hierarchy for query routing Store service information and process requests Advertise existence for bootstrapping Client SDS Servers

57. 57 The Berkeley SDS Architecture Printer Converter Jukebox Printer Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Services Responsible for creating and propagating XML service description Client SDS Servers

58. 58 The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Clients The users of the system Perform look up requests via SDS server Client SDS Servers

59. 59 The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Certificate Authority Certificate Authority Provides a tool for authentication Distributes certificates to other components Client SDS Servers

60. 60 The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Capability Manager Capability Manager Maintains access control rights for users Distributes capabilities to other components Client SDS Servers

61. 61 How the Pieces Interact... SDS Server Client Printer Music Server Backup SDS Server Server Announcements: Global multicast address Periodic for fault detection Provides all parameters Service Announcements: Multicast address from server Periodic for soft state Contains description Client Queries: SDS address from server Sends service specification Gets service description and URL

62. 62 Security Goals n Access control n Authentication of all components n Encrypted communication

63. 63 Security Goals n Access control u Services specify which users may “discover” them n Authentication of all components u Protects against masquerading u Holds components accountable for false information n Encrypted communication u Authentication meaningless without encryption u Hides sensitive information (service announcements) n No protection against denial of service attacks

64. 64 Security Hazards SDS Server Client Printer Music Server Backup SDS Server Clients: Encryption for 2-way communication Have to prove rights Authenticated RMI Server Announcements: Have to sign information No privacy needed Signed broadcasts Service Announcements: Only intended server can decrypt Signed descriptions to validate Secure One-Way Broadcasts All components: Use certificates for authentication

65. 65 Secure One-Way Broadcasts Service K Private Signing (DSA) Asymmetric Encryption (RSA) Symmetric Encryption (Blowfish) Service Description Server EK Public K Session K Session {Signed Description}EK Public {Session Key} Key idea: Use asymmetric algorithm to encrypt symmetric key

66. 66 Secure One-Way Broadcasts Asymmetric Encryption (RSA) Symmetric Encryption (Blowfish) Signed Service Description Server EK Private K Session K Session {Signed Description}EK Public {Session Key} (Cache it) To decode, only intended server can decrypt session key Use session to retrieve service description Cache session key to skip later asymmetric operations

67. 67 Wide Area Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley UCB CS Stanford U Kinko’s #123 CS Physics Mobile People Root Hierarchy motivation: Divide responsibility among servers for scalability The big question: How are queries routed between servers?

68. 68 The Wide Area Strategy n Build hierarchies based upon query criteria u Administrative domain u Network topology u Physical location n Aggregate service descriptions (lossy) n Route queries based on aggregation tables  Parent Based Forwarding (PBF)

69. 69 Service Description Aggregation n Hash values of tag subsets of service description used as description summary n Hash list compressed with Bloom Filter [Bloom70] n Fixed-size aggregation tables prevent explosion at roots n Guarantees no false negatives n Can have false positives, probability affected by table size n Algorithm: u To add service, compute description tag subsets, insert into Bloom Filter table u To query, compute query tag subsets, examine corresponding entries in Bloom Filter table for possible matches

70. 70 Multiple Hierarchies Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley UCB CS Stanford U Kinko’s #123 CS Physics Mobile People Root Administrative Hierarchy

71. 71 Multiple Hierarchies Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley Soda Hall Stanford U Kinko’s #123 CS Physics Mobile People Root Physical Location Hierarchy Stanford, USBerkeley, US Hearst St Northern California

72. 72 Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ?

73. 73 Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Room 443 Room 443 server examines its data and tables, routes to parent

74. 74 Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Each server checks aggregation tables, Hearst sees possible hit

75. 75 Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Kinko’s #123 finds match, returns service description

76. 76 Conclusion n A tool for other applications u Provides a listing of services in the network u XML descriptions allow for flexibility u Well defined security model u Fault tolerant, scalable u Releasing local area implementation as part of Ninja n Ongoing work u Experimenting with wide area strategy and caching n For more information u sds@iceberg.cs.berkeley.edu

77. 77 INS Issues n System-supported search u System parameters F Hop count u Application parameters F Least loaded printer n Mobility u Node mobility F Node may move between discovery and operation F End-to-end solution u Service mobility F Ideal node changes Least loaded printer Closest location n How to store hierarchical attributes? n Fault tolerance and availability

78. 78 System supported search n Allow service to advertise an application-defined metric (load) u Single metric F Either least loaded or closest printer n Name server will find service with least value of metric

79. 79 Mobility n Client never sees physical address u Query serves as intentional name for source and destination n Discovery infrastructure also does message routing u Different from query routing in SDS n Conventional model u Get address from query u Use address to send message n INS model u Send message with query u What if multiple services F Anycast Send to service with least value of metric F Multicast Send to all matching services Cannot use internet multicast!

80. 80 Multicast approach n Internet multicast groups u Contain internet addresses u But internet addresses may change! n Point to point multicast u Inefficient because of duplication of messages along common paths n Overlay routing network of NS u Multiple replicated NS F Number can vary dynamically u Each service and client bound to specific NS u Spanning tree of NS F Based on round trip latency u NS forwards message to appropriate neighbours

81. 81 Distributed Spanning Tree Construction n List of current name servers kept in (possibly replicated) NS server n New name server addition u Gets list of NS’s from NS server F NS server serializes requests u Does a ping to all existing NS u Makes closest NS its neighbour (parent) u Puts itself in NS server list n Connections made a spanning tree? u NS’s are connected u n-1 links made u Any connected graph with n-1 links is tree u Nodes put in NS server in linear order u A later node cannot be parent of earlier node

82. 82 Load balancing n NS server keeps list of potential NS sites n As load gets high u New NSs added to inactive potential sites F dynamically attach themselves to spanning tree n As load gets low at a site u NS killed u Tree must adjust F Incremental vs. batch F Incremental Informs peers (children) about this They rejoin

83. 83 Service 1 name record service [service = camera] camera Storing/Searching Attributes Service 1 announcement: [service = camera [color = true]] [location = 536] Name record: IP Adr, next hop NS Query: [location = 536] root location 536 color true Service 2 announcement: [service = printer [postscript = true]] [location = 536] Name record: IP adr, next hop NS postscript true printer Service 2 name record

84. 84 Storing/Searching Attributes Lookup (T, q): Set of name records let S be the set of all name-records for each av pair, (a q, v q ) of query if v q = * find attribute node a q in T intersect S with name records in subtree(a q ) else find av node (a q, v n ) in T if v q or v n is leaf intersect S with name records in subtree(v n ) else intersect S with name records in lookup (subtree(v n ), subtree(v n )) return S

85. 85 Lookup overhead T(d) = n a * (t a + t v + T(d-1)) T(d) = n a * (1 + T(d-1)) (hashing) n T(0) = b (intersect all name records with selected set) n T(d) = O (n a d * (1 + b)) n T(0) = O(n), (n = number of name records) “experimentally” from random name specifiers and tree n T(d) = O (n a d * n)) root rara rvrv 2d nana

86. 86 Fault Tolerance n All name servers are replicas u each announcement forwarded to neighbours u announcements sent periodically (hearbeat) n Hearbeat mechanism detects service and NS failure n if service fails u announcement removed n If NS fails u reconfigure overlay network n Client queries sent to single NS u load balancing

87. 87 Forwarding Announcements root servicelocation camera536printer color true postscript true Service 1 name recordService 2 name record

88. 88 Forwarding Announcements root service cameraprinter color true postscript true Service 1 name recordService 2 name record [color = true] [service = camera] [service = camera [color = true] location 536 [location = 536] [color = true] ] [

89. 89 Get Name GetName(r) name  a new empty name-specifier root.PTR  name for each parent value node of r trace (parentvalueNode, null) return n Trace(valueNode, name) if valueNode.PTR != null if name != null graft name as child of valueNode.PTR else valueNode.PTR  (valueNode.parentAttribute(), valueNode.value()) If (name != null) graft name as child of valueNode.PTR Trace(valueNode.parentValue(), valueNode.PTR) Synthesized attributes!

90. 90 Update time n t = n * (T lookup + T graft + T update + network_delay) n Experiments show costly operation n Solution is to divide name space into disjoint virtual spaces ala SLP u camera-ne43 u building-ne43 n Each service heart beat not sent each NS n Sending tree diffs as a solution?

91. 91 Applications n Floorplan: An map-based navigation tool u Example service F [service = camera[entity = transmitter][Id=a]] [room=150] u Retrieving map F [service = locator [entity = server]] [region = first floor] u Retrieving devices F [room = 150]

92. 92 Applications n Load-balancing printer u Unicast F [id = hplj156] F Retrieve, delete, submit job u Anycast F [service=printer [entity=spooler]][room=517] u Printer advertises metric based on F Error status, number of enqueued jobs, length of jobs

93. 93 Applications n Camera: A mobile image/video service u Request camera image F destination address [service = camera[entity = transmitter]][room = 510] F source address [service = camera[entity = receiver][id=r]][room = 510] F Transmitters/receivers can move u Multicast to receivers F Multiple users viewing image u Multicast to senders F User viewing multiple cameras

94. 94 NS Caching n Case 1 u Camera multicasts image u Some other client subsequently requests image n Case 2 u Client requests image u Requests image again u A la web caching n Caching implemented for any service using IN u Assumes RPC call interface? n Cache lifetime given

95. 95 Design and implementation of an intentional naming system William Adjie-WinotoElliot Schwartz Hari BalakrishnanJeremy Lilley MIT Laboratory for Computer Science http://wind.lcs.mit.edu/ SOSP 17, Kiawah Island Resort December 14, 1999

96. 96 Environment n Heterogeneous network with devices, sensors and computers n Dynamism u Mobility u Performance variability u Services “come and go” u Services may be composed of groups of nodes n Example applications u Location-dependent mobile apps u Network of mobile cameras n Problem: resource discovery

97. 97 Responsiveness Integrate name resolution and message routing (late binding) Robustness Easy configuration Name resolvers self-configure into overlay network Expressiveness Decentralized, cooperating resolvers with soft-state protocol Design goals and principles Names are intentional; apps know what, not where

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

99. 99 INS architecture Name resolver Overlay network of resolvers Client Intentional anycast Intentional multicast Message routing using intentional names Name Service Late binding Name with message

100. 100 Name-specifiers [vspace = mit.edu/thermometer] [building = ne43 [floor = 5 [room = *]] [temperature < 60 0 F] data [vspace = lcs.mit.edu/camera] [building = ne43 [room = 510]] [resolution=800x600]] [access = public] [status = ready] n Expressive name language (like XML) n Resolver architecture decoupled from language n Providers announce descriptive names n Clients make queries u Attribute-value matches u Wildcard matches u Ranges

101. 101 Name lookups n Lookup u Tree-matching algorithm u AND operations among orthogonal attributes n Polynomial-time in number of attributes u O(n d ) where n is number of attributes and d is the depth

102. 102 Resolver network n Resolvers exchange routing information about names n Multicast messages forwarded via resolvers n Decentralized construction and maintenance n Implemented as an “overlay” network over UDP tunnels u Not every node needs to be a resolver u Too many neighbors causes overload, but need a connected graph u Overlay link metric should reflect performance u Current implementation builds a spanning tree

103. 103 UDP tunnel new Spanning tree algorithm n Loop-free connectivity n Construct initial tree; evolve towards optimality u Select a destination and send a discover_bottleneck message along current path max A B

104. 104 Late binding n Mapping from name to location can change rapidly n Overlay routing protocol uses triggered updates n Resolver performs lookup-and-forward u lookup(name) is a route; forward along route n Two styles of message delivery u Anycast u Multicast

105. 105 Intentional anycast n lookup(name) yields all matches n Resolver selects location based on advertised service-controlled metric u E.g., server load n Tunnels message to selected node n Application-level vs. IP-level anycast u Service-advertised metric is meaningful to the application

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

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

108. 108 Performance and scalability n Lookup performance n Spawn INR on a new node to shed load Number of names Lookups per second

109. 109 vspace=cameravspace=5th-floor Delegate this to another INR Routing updates for all names Routing Protocol Scalability n vspace = Set of names with common attributes n Virtual-space partitioning: each resolver now handles subset of all vspaces Name-tree at resolver

110. 110 INR Implementation Overlay Manager Network Monitor Route Manager Client Manager Forwarder vspace neighbors NameTreeSet Communicator Mobility Sockets TCP/UDP lookup Intentional anycast, multicast Incoming message

111. 111 Applications n Location-dependent mobile applications u Floorplan: An map-based navigation tool u Camera: A mobile image/video service u Load-balancing printer u TV & jukebox service n Sensor computing n Network-independent “instant messaging” n Clients encapsulate state in late-binding applications

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

113. 113 Conclusion n INS is a resource discovery system for dynamic, mobile networks n Expressiveness: names that convey intent n Responsiveness: late binding by integrating resolution and routing n Robustness: soft-state name dissemination with periodic refreshes n Configuration: resolvers self-configure into an overlay network

114. 114 Active Name Issues Example u Printer selected F randomly F round-robin n INS metric of load not sufficient n Need some application-specific code

115. 115 Active Approaches Active networks u Install code in internet routers F can only look at low-level packets F not enough semantics n Active services u Allows application to install arbitrary code in network F application-awareness

116. 116 Active Names n Active names u Install code in name servers F enough semantics F application-transparency u vs INS F installs metric and data F extension is to install code F declarative vs procedural F security problem confine code a la applet u vs HTTP caching F special proxies translate name

117. 117 Active Names n Active name u name u namespace program to interpret name F specified by active name name name space program to interpret name recursively until – name – specifier of predefiened name space programs such as DNS, HTTP u Example F printing round-robin install program that listens for printer announcements picks printers in round-robin

118. 118 Active Name RPC n Example u Camera data caching n Active name used in RPC call u name space program has notion of F data (parameters) F reply u it can cache data

119. 119 Upward comapatibity Example n Service name without transport protocol u www.cs.utexas.edu/home/smithwww.cs.utexas.edu/home/smith u Transport protocol concern of name space program n Root name space delegates to WWW-root active name program n WWW-root implements default web caching n Response to URL indicates name space program to interpret name u www.cs.utexas.edu/home/smith/active/* www.cs.utexas.edu/home/smith/active/* u Original request must be prefix of active name program F www.cs.utexas.edu/* illegal www.cs.utexas.edu/*

120. 120 Active Name Delegation n Example u Might wish to transcode camera image F color to black and white u Name space program in client’s NS can transcode F but might want transcoding nearer data producer if network is slow n Name delegation u Each name space program interprets part of the F name F data input stream u Chooses next NS and name space program to interpret the rest u DNS special case

121. 121 After Methods n Return path for result may not be the same as path for data u request forwarded to more appropriate NS n Each delegation specifies return path for result u active name called after method u pushed on stack of current active names n Stack popped on way back u Each node on return path F pops active name F sends name, part of result and popped stack to NS u Leaf destination chooses closest NS and top-level after method F Can influence how request is serviced on the network F Transcoding, adding banner ads u Name space resolver and after method at other return nodes choose processing and subsequent node  Direct cal cost: 0.2  s, After method cost: 3.2  s

122. 122 Security n Answer could come back from anyone n How to trust? n Assume transitive trust u A trusts B u B trusts C u  A trusts C n Client sends capability u Some unforgeable object n It is passed along n Trusts anyone who returns it.

123. 123 Active Names: Flexible Location and Transport of Wide- Area Resources Amin Vahdat Systems Tea April 23, 1999

124. 124 Active Naming Vision n Today: Name is static binding to physical location and object (DNS, LDAP) n Want: dynamic, flexible binding to service/data u Server selection among geographic replicas (CISCO, IBM, etc.) u Client customization (e.g., distillation, custom CNN) u Server customization (e.g., hit counting, ad rotation, etc.) n An Active Name is a mobile program that invokes a service or acquires data u Flexibly support various naming semantics u Minimize wide-area communication

125. 125 Outline n Background n Active Names u Opportunity u Implementation n Examples u Programmability u Location Independence u Composibility n Conclusions

126. 126 Current Name Services n DNS translates machine names to IP addresses u Updates propagated over a period of days u Bindings cached at client, TTL invalidation u Assumes bindings change slowly, updated centrally n RPC name service binds caller and callee u Assumes every service provider is equivalent n In wide area: heterogeneous quality of service depending on selection of provider

127. 127 Wide Area Naming Today: HTTP Redirect w/Dynamic Content Client Proxy 1 Name DNS Server 2 HostBinding HTTP Server 3 URLRedirect 4 URL HTTP Server 5 Name Program 6 Data

128. 128 Current Attempts to Add Flexibility to Name Binding n HTTP redirect n DNS round robin n Cisco Local Director/Distributed Director URN’s with sed scripts to mangle names n Global object IDs (e.g., Globe, Legion) n Web caches/Active Caches n Mobile IP n...

129. 129 The Active Naming Opportunity n Name translation often incorporates client- specific info u Custom home pages (www.cnn.com => your news page) u Distilling picture to client requirements (small B&W for PDA’s) n Naming often a step in a larger process n Availability of remotely programmable resources u Java, Active Networks n Importance of minimizing wide-area latency for requests

130. 130 Active Naming Implementation n Clients generate Active Names domain:name n Active Name Resolver determines domain- specific program u Location independent, can run anywhere u Application specific, name resolved in domain- specific manner n Domain-specific code to check for cache hit u Active caching (hit counters, ad-rotation) n After Methods associated with each Active Name u List of programs guaranteed to be called after initial eval u Multi-way RPC, anonymization, distillation u Client-specific transformation of data

131. 131 Active Name Resolution n Program agent of service u Hit counting u Dynamic content generation n Location independent u Hand off to other resolvers n After methods perform client-specific transforms u Distillation u Personalization n Virtual Machine u Resource allocation u Safety Client Name Data Active Name Resolver DomainResolver After Methods Distillation Return Data Virtual Machine Program Cache

132. 132 Multi-Way RPC n Goal: minimize latency u Usually have to pass results all the way down a hierarchy u Adds latency u Store and forward delays n Multi-Way RPC leverages after methods u Convention: last after method transmits result back to client u Minimize latency u Back fill for caches? P CP P SP P CP P SP Multi-Way RPC Traditional Request Response

133. 133 Change the Socket API? n Network programming traditional model: u ipaddr = gethostbyname(“www.cs.duke.edu”); socket = connect(ipaddr, 80 /* port */); write(socket, “GET /index.html HTTP/1.0\n\n”); read(socket, dataBuffer); u dataBuffer = ANResolver.Eval(“www.cs.duke.edu/index.html”) ; n Analogs in other areas u Filesystems, virtual memory, Java URL objects u Programmer does not see inodes or physical page addresses u Allows for reorganization underneath the hood

134. 134 Security Considerations n Multi-way RPC u Send request to local resolver u Wait for answer on a socket u Answer could be transmitted by anyone n Solution: use capabilities u Associate a capability with each request u Capability must come back with reply n Future work: integrate with CRISIS xfer certificates u Specify the privileges available for name resolution (local state) u Inspect complete chain of transfers linked to replies

135. 135 Outline n Background n Active Names u Opportunity u Implementation n Examples u Programmability u Location Independence u Composibility n Conclusions

136. 136 Example: Load Balancing l DNS Round-Robin »Randomly choose replica »Avoid hotspots l Distributed Director »Route to nearest replica »Geographic locality l Active Naming »Previous performance, distance »Adaptive Berkeley Replica Seattle Replica Berkeley Clients

137. 137 Load Balancing Performance l Optimal load balancing varies with offered load: »Low load: choose closest server »High load: distribute load evenly

138. 138 Example: Mobile Distillation n Clients name a single object n Returned object based on client u Network connection, screen n Current approach [Fox97] u Proxy maintains client profile u Requests object, distills n Active naming u Transmit name + program u Flexible distillation point u Tradeoff computation/bandwidth u Support mobile clients Client-Specific Naming Variables: Network, Screen

139. 139 Determine Placement of Computation: First-Cut Placement Algorithm serverDist= (evalCost / specint server * loadAverage server ) + (smallFileBW / distillFileSize); proxyDist = (largeFileBW / origFileSize) + (evalCost / specint proxy * loadAverage proxy ); Prob(serverEval)= proxyDist / (proxyDist + serverDist); n Distribute load based on estimate of cost n Feedback confidence information? è In wide area u Must use approximate information  Avoid deterministic decisions

140. 140 Importance of Location Independence I n Distill 59 K image to 9 K n Clients/Proxy at UC Berkeley n Server at Duke è Active Policy tracks then beats best static policy

141. 141 Importance of Location Independence II n Server loaded with 10 competing processes n No longer makes sense to perform all distills at server è Dynamic placement of computation for optimal performance

142. 142 Example: Active Caches èLow (50%) hit rates to proxy caches; causes for misses:

143. 143 Example: Active Caches n 50% hit rate to caches n Active Name Resolvers promise to run domain- specific code to retrieve/enter cache entries n Cache program implements u Ad rotation, Server side include (SSI) expansion, Access checking, Hit counting è No magic bullets, have to compose multiple extension » Combination of distillation, server customization outperforms distillation-only by 50%, customization-only by 100%

144. 144 Related Work n Active Networks: u New routing protocols: multicast, anycast, RSVP u Must modify routers u Bottom of protocol stack: end-to-end app performance n Active Services: u No composibility, extensibility u Restricted to single point in the network u Unrestricted programming model

145. 145 Hyper-Active Naming n Buying stocks u Name stock, requested price, credit card u Execute Active Name applet at server to purchase n Cooperating agents u Request best price on a commodity (book) u Active Name applet returns with results and option to buy n Print to nearest printer (mobility) u Active name applet locates printer with client prefs u Runs method at print server to print document

146. 146 Discussion n Query optimization problem u Reordering of after methods n Placement of wide-area computation u What’s available for running my job? n Estimating remote bandwidth, CPU load n Integration with CRISIS security n Resource allocation n Debugging? n Performance overheads?

147. 147 Conclusions n Active Name: mobile program that invokes a service or acquires data n Prototype demonstrates u Feasibility of approach u Interesting applications n Provides dynamic, flexible binding to service/data u Server selection among geographic replicas (Rent- A-Server) u Client customization (e.g., distillation, custom CNN) u Server customization (e.g., hit counting, ad rotation, etc.) u Active Caching

148. 148 Active vs. Intentional Names n INS and Active Networks u Name servers deliver and route message u Name servers are general modules with application-specific features F INS declarative attributes and metric F Active name procedural Name space resolver programs u Overlay network F Use IP for routing

149. 149 Sensor Networks n Sensor networks u Name servers directly do routing F Not built on top of IP u Connected directly to each other with physical point-to- point links F Special ad-hoc network separate from internet u No distinction between F Client F Service F Name server F Router u Every node is a routing sensor and name server u Framework for building such networks

150. 150 Distributed Sensors vs. Appliances n Sensors u produce and consume data n Communication u data messages u a la event notifications n Appliances u respond to operations u send back events n Communication u remote method call u event notifications

151. 151 Internet vs. Sensor Networks Internet n Plentiful power n Plentiful bandwidth n Low delay n Router throughput an issue Sensor network n Scarce power n Bandwidth dear n High-delay n Sensor/router nodes powerful compared to bandwidth u 3000 instructions take as much power as sending a bit 100m by radio n Tradeoff computation in router for communication u Rainfall aggregation near source node u Duplicate suppression u Avoid flooding, multicast …

152. 152 No IP address n Client does not use address u As in active name, IN n Service does not register address u Unlike active name, IN u No special name server source sink

153. 153 Naming and Routing n How do nodes communicate? u Naming F attribute-based F as in INS u Routing F Broadcast to all neighbours source sink Away path

154. 154 Avoiding Away paths n Sink sends interest to source n Interest forwarded by intermediate nodes n Sink and intermediate nodes record gradient: u neighbours from which each interest came u And update rate, active/inactive interest n Data matching interest returned to these neighbours if active at update rate n Avoiding away paths for interest - Directed diffusion Away interest path

155. 155 Avoiding interest away-paths n Away paths of interest u send interest about interests F Extends Model View Controller F Many to many communication u must stop recursion F Away paths for interest about interest Away interest about interest path

156. 156 Avoiding source overload n Source does not generate/sense data until interest about interest arrives n Interest can be dynamically activated/deactivated u at source and intermediate nodes u changes gradient activated

157. 157 Avoiding sink overload n Update rate associated with interest u intermediate nodes forward events at update rate u recorded in gradient Not sent because of update rate

158. 158 Multiple paths n Event goes to destination along all paths

159. 159 Avoiding Multiple Paths n Send “source” sends exploratory message to all possible sinks n Each sink reinforces path along which message reached earliest n Subsequently reinforced path used n Exploratory messages periodically sent to update routes n Local repair on node failure n Negative reinforcements possible if alternative paths better u How determined?

160. 160 Aggregation n Same real-world event may trigger multiple sensors u Multiple motion detectors n Sink may be interested in aggregation of events from multiple sensors u Rainfall sensors n Download filters at intermediate nodes u They match attributes u Examine matching messages u Can respond by doing application-specific aggregation F A la active networks Installed Filter

161. 161 Aggregation Kind/Examples n Binary u There was a detection n Area u Detection in specific quadrant n Probability u 80% chance of detection

162. 162 Two-Level Sensing n Wireless monitoring system u Low-power sensors F Light and motion detectors F Always on u High-power sensors F Microphones and steerable cameras F Triggered by low-power sensors u Configured externally by some distant client F Where the user is u Must go through some intermediate nodes u How configured? High- power Low- power Sink

163. 163 Conventional Solution Conventional n Client listens for low- power events n Triggers high-power events n Lots of communication

164. 164 Nested Query Solution Nested query solution n Nested interest sent to secondary sensor n It registers interest in primary sensors n Less communication

165. 165 Attribute Matching n Interest class IS interest task EQ “detectAnimal” confidence GT 5.0 latitude GE 10.0 latitude LE 100.0 longitude GE 5.0 longitude LE 95.0 target IS “4-leg” n Published class IS data task IS “detectAnimal” confidence IS 90 latitude IS 20.0 longitude IS 80.0 target IS “4-leg” Free variable (actual parameter) Bound variable (actual parameter) Matching = Unification EQ = subclass of ? key valop

166. 166 Attribute Matching Algorithm One-way match (AttributeSet A, B) for each unbound a in A { matched  false for each bound b in B where a.key = b.key matched  compare (a.key, b.key, a.op) if not matched return false return true

167. 167 API Subscription subscribe (AttributeSet attributeSet, SubscriptionCallback callback); unsubscribe(Subscription subscription); Publication publish(AttributeSet attributeSet); unpublish (Publication publication); send (Publication publication, AttributeSet sendAttrs); Filter addFilter(AttributeSet attributeSet, int priority, FilterCallback callback); removeFilter (Filter filter) sendMessage(Message message, Handle handle, Agent agent) sendMessageToNext(Message message, Handle handle) Accesses gradient, message, previous and next destination

168. 168 Two Implementations n Full size u 55 KB Code u 8Kb data u 20KB library u 4KB data n Meant for secondary sensors n Micro size u 3K code u 100 byte data n Micro functionality u Single attribute u 5 active gradients u 10 packet cache u 2 relevant bytes/packet u No filters n Meant for primary sensors

169. 169 Database based composition Queries over multiple devices u For each rainfall sensor, average rainfall u For each sensor in Tompkin county, current rainfall u For next 5 hrs, every 30 minutes, rainfall in Tompkin county

170. 170 Query Kinds Device Queries n Historical u For each rainfall sensor, average rainfall n Snapshot u For each sensor in Tompkin county, current rainfall n Long-running u For next 5 hrs, every 30 minutes, rainfall in Tompkin county u New kind of query n Defining device databases and queries?

171. 171 Cougar Device Model n Embedded vs. Attached u Embedded F Network appliance/sensor u Regular appliance attached to computer F Computer connected to regular device n Stationary vs. Mobile n Strongly vs. Intermittently connected n Local area vs. wide area n Device database work focuses on stationary devices n Data Gatherers (sensors) vs. Operation Servers (appliances)?

172. 172 Cougar Device Operations n Operation Model u acquire, store, and process data u may trigger action in physical world u return result n Synchronous operation u returns result immediately n Asynchronous operation u result(s) later F abnormal rainfall F as event n Intermittently connected device u only asynchronous operations possible u device not guaranteed to be connected when operation invoked u intermittently connected device as server

173. 173 Defining Device Database Device DBMS vs. Traditional Relational DBMS n Device vs. Data collection u Computed vs. stored values n Distributed information sources u Data needed not available locally u May not even be available remotely for intermittent n Long-running queries. u Not modelled by traditional DBMS Solution n Base device relations u One record for each device n Virtual Relations u Records partitioned over distributed nodes u Includes results of device operations n Extended query language over virtual relations

174. 174 Base Relations Collection of devices of a particular type. n one record per device n attributes u device id u X coordinate u Y coordinate IDXY

175. 175 Virtual Relations Per device function u Attribute for F each function argument F result F global timestamp of result F device id u New record added for each new result u Append-only relation u Each device contributes to part of relation a1a1 Valamam TSID f( a 1,…, a m ): T

176. 176 Example RFSensor n One function u getRainfallLevel() : int n Base relation u RFSensors n Virtual relation u VRFSensorsGetRainfa llLevel ValueTS Device ID RFSensors VRFSensorsGetRainfallLevel Device IDXY

177. 177 For next four hours, retrieve every 30 seconds, rainfall level of each sensor if it is greater than 50mm. Query Q: SELECT VR.value FROM RFSensors R, VRFSensorsGetRainfallLevel VR WHERE R.ID = VR.ID AND VR.value > 50 AND AND $every(30) Run Q for 4 hours 200 devices R cardinality = 200 VR cardinality = 480 Long running queries joinselection AND R.X =... IN... WHY JOIN?

178. 178 Execution Strategies RMaterialized VR RVR Q R if R.ID = VR.ID VR.value > 50 RVR R.ID = VR.ID if VR.value > 50 VR.value > 50R.ID = VR.ID Val every 3O min No local knowledge Local rate info, remote Q Local Join, Remote Selection Local Selection, Remote Join

179. 179 Performance Metrics n Traditional u Throughput u Response time F Long query running time implementation independent n Sensor specific u Resource usage F network, power n Reaction time u Production to consumption time

180. 180 Power Usage Components n CPU n Memory access n Sending message n Sending Nbytes Cost in joules = W cpu *CPU + W ram *RAM + W msg Msg + W bytes *NBytes

181. 181 Centralized Warehouse No local knowledge n Single location monitors all sensors n Queries are sent to site n Works for historical queries n Wastes resources for long running queries u Irrelevant sites u Higher rate than necessary n What to monitor for long running queries u Camera direction? n Centralization u Workload u Bottleneck

182. 182 Distributed Device Database n All sensors together form a distributed device database system n Individual nodes u sense on demand u do part of query processing n Better resource utilization n Know what to monitor n Historical? u based on some long-running query

183. 183 Distributed Database Approach n All sensors together form a distributed device database system n Individual nodes u sense on demand u do part of query processing n Better resource utilization n Know what to monitor n Historical?

184. 184 Remote Query Evaluation n Only relevant sensors send data n No relations sent to sensors RVR VR.value > 50R.ID = VR.ID Val every 3O min Local rate info, remote Q

185. 185 Local Join RVR if R.ID = VR.ID VR.value > 50 Val every 3O min Local Join, Remote Selection n Only relevant sensors send value n Whole relation send to device u communication overhead

186. 186 Execution Strategies n Only relevant sensors send value n Whole relation send to device u communication overhead RVR R.ID = VR.ID if VR.value > 50 Val every 3O min Local Selection, Remote Join