Resource Discovery in Self-Organizing Networks

1
Resource Discovery inSelf-Organizing Networks
Hari Balakrishnan MIT Lab for
Computer Sciencehttp//inat.lcs.mit.edu/hari_at_lcs
.mit.edu
2
Application 1 Collab Regions
3
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

4
Challenges

• Configuration
• Routing
• Discovery
• Adaptation
• Security

5
Today
Clients

• Mostly static topology services
• Applications cannot learn about network
• Deploying new services cumbersome
• Failures are common!
• High management cost

Routers
Servers
6
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)

7
DHCP
a1
a2
a3
DHCP server

• Centralized DHCP server to provide address, DNS
  server, etc.
• Relays to avoid per-LAN servers
• IETF standard protocol

8
Ad hoc Configuration

• Static configuration impossible
• DHCP-like configuration undesirable
• Over wireless, pre-configured subnetworks and
  broadcasts problematic
• Solution Distributed, randomized address
  assignment

Coalesce? Route?
addr ar mask mr
addr br mask mr
addr cr mask n
9
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)

10
Unicast IP Routing
Routing table
P1I1
P2I2
Route lookup
P3I2
I1
P4I3
I2
dst
I3

• IP address signifies location in Internet
• Routers forward based on longest-prefix
• Routing protocols build route info

11
Mobile IP
Fixed Hosts
Internet
Home Agent
Intercepts pkts
Foreign Agent (FA)
Temporary address dtmp changes with mobility
Mobile Host
12
Mobile Ad hoc Routing

• Many proposals exist
• Destination-Sequenced Distance Vector (DSDV)
• Temporally-Ordered Routing Algorithm (TORA)
• Dynamic Source Routing (DSR)
• Ad Hoc On-Demand Distance Vector (AODV)
• . . .

Request
r4
D
S
r3
r1r2r4D
r1
r2
Route to D in cache
Reply r2r4D
13
Discovery

• Perhaps the hardest challenge in this area
• Heterogeneity
• Devices
• Services
• User interfaces
• Change
• Mobility
• Data
• Performance
• Robust architecture
• Spontaneous deployment ZERO config!

14
Intentional Naming System
Apps know WHAT they want, not WHERE

• 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

15
INS Architecture
camera510.lcs.mit.edu
Lookup
image

• Intentional Name Resolvers
• form a distributed overlay

Integrate resolution and message forwarding
16
How Does It Work
Virtual space partitions Domain Space Resolvers
Scaling?
INR
DSR
17
Name-Specifiers

• Problem Expressive name language (like XML)

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

Administratively scoped names (e.g., lcs.mit.edu)
18
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

19
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)

20
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

21
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

22
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

23
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

udp_recv()
IBM Intranet
MIT
Firewall
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
Status Performance

• Java implementation of system
• Ported to Palm III too!
• PC-based resolver performance
• 1 resolver --gt 75,000 names at gt 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)

34
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

35
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 applications
36
Challenges

• Configuration
• Routing
• Discovery
• Adaptation
• Security

37
Adaptation via the Congestion Manager

• Adaptation Enable applications to learn about
  network conditions and adapt
• Sharing Efficiently multiplex streams and share
  paths

HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
API
IP
38
Security

• Confidential authenticated inter-node and
  external communications
• Privacy and anonymity
• Selective node visibility
• If it aint visible, it aint hackable
• Hard problem!
• Decentralized security modes preferred
• E.g., self-certifying names

39
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

40
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

41
Whats 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

42
Supporting Application-Level Networks

• General protocols for meta-data dissemination
• Using all the good stuff weve 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

43
Summary

• Configuration
• Standard wireline protocols ad hoc
  zero-manual-config protocols needed
• Packet routing
• Mature area, many proposals, deployment and
  evaluation needed
• Application-controlled routing key!
• Adaptation
• Congestion, error, and route management
• API for learning

44
Summary (cont.)

• Discovery
• Key to self-organization
• SLP, Jini, UPnP, Intentional Naming System
  (INS),...
• INS provides rapidly deployable,
  self-configuring, robust facility
• Security
• Privacy (and anonymity) are hard
• Impoverished devices

45
Future Internet Architecture
Use each other to add value
Flexible IP routers
Scheduling, buffer mgmt
46
Conclusions

• Achieving self-organization isnt 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