Resource Discovery inSelf-Organizing Networks

Hari Balakrishnan MIT Lab for Computer Science

http://inat.lcs.mit.edu/hari@lcs.mit.edu

Application #1: Collab Regions

Servers

Services in our environment

Application #2: Networks of Devices

• Access and control services provided by (wireless) networked devices

• Integrate the physical world– Sensor computing

• Location-dependent applications– Active maps, mobile camera network, object

tracking system, climate sensing

• Rapidly deployable & configurable systems

Challenges

• Configuration• Routing• Discovery• Adaptation• Security

Today

Routers

DNS

Hostname

Address

• Mostly static topology & services

• Applications cannot learn about network

• Deploying new services cumbersome

• Failures are common!• High management cost

Servers

Clients

Configuration

• Manual configuration– Contact network administrator and

get an address (+ DNS mapping)– This is the predominant mode today!

• Dynamic Host Configuration Protocol (DHCP)

• Decentralized ad hoc configuration (work-in-progress)

Packet Routing

• IP routing & forwarding– Unicast (RIP, OSPF, BGP)– Multicast (DVMRP, PIM, CBT, BGMP)

• Mobile IP (RFC 2002)– Movement (as opposed to relocation)– Continuous connections to mobile hosts– Mobile data sources

• Ad hoc routing (IETF MANET WG)

Discovery• Perhaps the hardest challenge in this area• Heterogeneity

– Devices– Services– User interfaces

• Change– Mobility– Data– Performance

• Robust architecture• Spontaneous deployment: ZERO config!

Intentional Naming System

• Descriptive names– Describe intent based on attribute-value

tuples

• Self-configuring resolvers• Integrate resolution and forwarding

– “Late binding” of names to nodes

• Soft-state dissemination protocols– Periodic announcements and refreshes

Apps know WHAT they want, not WHEREApps know WHAT they want, not WHERE

INS Architecture

[building = ne-43[room = 510]]

[entity = camera]

[building = ne-43[room = 510]]

[entity = camera]

Intentional name

INR

INR

INR

Intentional Name Resolvers form a distributed overlay

Integrate resolution and message forwardingIntegrate resolution and message forwarding

image

Lookup

camera510.lcs.mit.edu

How Does It Work

INRINR

DSRDSR

Application-leveloverlay networkformed based on

performance

Inter-domaininformation viaDSR protocol

Exchange namesas if they were routes

Virtual space partitionsDomain Space Resolvers

Scaling?

[vspace = thermometer][building = ne-43

[room = *]][temperature < 620F]

[vspace = thermometer][building = ne-43

[room = *]][temperature < 620F]

datadata

[vspace = café][state = ca [city = berkeley] [region = northside]]][distance < 0.25 miles]

[vspace = café][state = ca [city = berkeley] [region = northside]]][distance < 0.25 miles]

datadata

Name-Specifiers

• Names are query expressions– Attribute-value matches– Range queries– Wildcard matches

[vspace = camera][building = ne-43

[room = 504]][resolution=800x600]][access = public][status = ready]

[vspace = camera][building = ne-43

[room = 504]][resolution=800x600]][access = public][status = ready]

• Names are descriptive– Providers announce names

• Problem: Expressive name language (like XML)

Administratively scoped names (e.g., lcs.mit.edu)

Self-Configuring Resolvers

• Problem: Manual configuration• Solution: self-configuration protocol• Bootstrap

– DNS maintains list of per-domain INRs

• Neighbor formation– Based on metrics like round-trip latency

• Load balancing– Spawn/kill resolvers on INR nodes

Late Binding

• Problem: Track rapid changes• Solution: Integrate resolution and

forwarding message• Periodic advertisements from

provider nodes refresh state in INR• INRs forward message to destinations• Handles mobile, grouped, and

replicated services (& people)

Soft-state Dissemination

• Problem: Robustness and availability• Solution: Treat names as soft-state; use

“routing” protocols to exchange• Application-level routing & forwarding

between INR overlay nodes• To scale well, use bandwidth

management heuristics– Namespaces become huge quickly– Treat “hot” and “cold” names differently

Efficient Name Lookups• Data structure

• Lookup – AND operations among orthogonal attributes– For values pick the value(s) satisfying the lookup

• Polynomial-time in worst case

Applications

• Wireless Networks of Devices (WIND)– Location-dependent & mobile

applications over RF and IR– Floorplan: A navigation tool– Camera: An image/video service– Printer: A smart print spooler– TV & jukebox

• Server replication• Caching service

WIND Demo

• Problem: Firewalls– E.g., UDP for names, advertisements,

video

• Solution: split protocol across firewall– Completely unchanged applications!– Transparently replace

DatagramSocketImpl in java.net

IBMIntranet

Internet

MITFirewall

udp_recv()TCP

UDP

UDP

Status & Performance• Java implementation of system

– Ported to Palm III too!• PC-based resolver performance

– 1 resolver --> 75,000 names at > 100 lookups/s (untuned)– Discovery time linear in hops

• Algorithms for robust self-configuration• Scalability

– Wide-area architecture design in progress– Problem: Decouple service & network hierarchy

• Deployment– Hook in wide-area architecture to DNS– Standardize “virtual spaces” (like MIME data types)

Related Work• Domain Name System

– Differences in expressiveness and architecture

• Service Location Protocol– More centralized, less spontaneous

• Jini: – INS can be used for self-organization

• Universal Plug-and-Play– XML-based descriptions; INS fits well

• IBM T-spaces• Intentional names in other contexts

– Semantic file systems, adaptive web caching, DistributedDirector

INS Summary

• Expressive naming language• Self-configuring resolvers form an

application-level overlay• Integrate resolution and routing• Soft-state dissemination protocols• Runs on impoverished devices too• Wide-area architecture in progress

Enables self-organizing networks & applicationsEnables self-organizing networks & applications

Application-Level Networks

Increasing number of services that set up application-level overlay networks

• Distributed Web caches• Replica management systems• Transcoders• Multi-party communication• Naming systems• Resource discovery

What Do They Have in Common?

• Form an overlay over IP• Nodes exchange meta-data

information• Nodes forward messages based on

meta-data• Incorporate configuration machinery• Fault/crash recovery• Load balancing

What’s the “Right” Network Support?

• Put a lot (and more) in the routers– IP Multicast– Reliable multicast primitives– Name redirection (“resolution”)– Web caches– Programmable active routers...

• Or, provide more support at the application-level

Supporting Application-Level Networks

• General protocols for meta-data dissemination– Using all the good stuff we’ve learned about soft-

state protocols

• Fault-tolerance primitives• Self-configuring overlays: key component

– Bootstrap and placement– Neighbor formation– Load balancing

• Security and privacy primitives– E.g., self-certifying names

Future Internet Architecture

Resourcemanagement

Flexible IP routers

Traffic engineering

Congestion Manager

Scheduling,buffer mgmt

Middleware

...Cache & replica

management Self-configuringoverlays

INS

Media transcoders

Performance discoveryService

location Jini UPnPE-speak T-spaces

Decentralizedsecurity

Use each other to add value

Conclusions• Achieving self-organization isn’t easy!

– Configuration– Message routing– Discovery: INS has many desirable features!– Adaptation– Security & privacy

• Application-level networking is key to achieving self-organization and flexibility– But it is being done in rather ad hoc ways– It behooves us to ensure that the future application-level

network architecture is at least as sound as the underlying IP substrate