Supporting Communication for Multihomed Mobile Devices

1
Supporting Communication for Multihomed Mobile
Devices

• Prof. Robin Kravets
• Mobius Group
• Dept. of Computer Science
• University of Illinois at Urbana-Champaign

2
Supporting Communication for Mobile Nodes

• Communication resources
• Multiple choices
• No one perfect technology
• Range vs. Capacity vs. Power
• Dynamically changing
• Need information about availability
• Coverage varies
• Transparent support from the network
• Goal
• Support mobile devices
• Requirements
• Connectivity
• Configuration
• Performance

Cellular Network
Satellite Network GPS Network
Packet Radio Network
Wireless LAN BlueTooth Infrared
Wireless LAN In-Building Infrared HomeRF
3
Supporting Communication for Mobile Nodes

• Challenge
• Mobile hosts have multiple network interfaces
• Coverage areas of different technologies overlap
• Mobile hosts are able to use network access
  points from different technologies
• Goal
• Intelligent use of multiple interfaces
• Approach
• Focus on supporting communication for a single
  node

4
Mobility Support Throughout the Protocol Stack

• Network Layer
• Connectivity
• Configuration
• Expose available interfaces
• Contact Networking
• Transport Layer
• Performance
• Expose potential configurations
• Resource Management
• Efficient use of resources in the current
  environment
• Corvus

Application
Control Corvus
Transport
Network Contact Networking
5
Contact Networking

• Environment
• Mobile node
• Multiple interfaces
• Unknown environment
• Goal
• Simple efficient communication with other devices
  in the current environment, as well as with other
  devices in the Internet
• People
• Casey Carter, UIUC
• Jean Tourrilhes, HP Labs

6
Local vs. Remote Communication

• Existing Solutions
• Focus on communication with devices in the
  Internet
• Remote communication
• Inefficient for communication with local devices
• Requires internet access
• Requires complex configuration

Remote Communication
MIP FA
MIP HA
MN
MIP FA
MIP HA
MN
Contact Networking
Local Communication
MIP FA
MIP HA
MN
MIP FA
MIP HA
MN
7
Problems of Remote Communication

• Long-haul wireless is inherently slower and more
  expensive
• Two users meet in the desert
• Cant use MobileIP without Internet
• Cant use DNS without Internet
• How about manual configuration?
• Complicated IP and link layer configuration
• Fails the Mom test
• Solution? Just use a floppy!

Contact Networking
8
Goals of a Localized Mobility System

• Infrastructureless
• Internetworking without the Internet
• Transparent
• User ignorant of number and type of interfaces
• Transparent local/remote communication
• Rendezvous, ZeroConf
• Simple as beaming a business card between PDAs

Contact Networking
9
Realizing a Localized Mobility System

• Challenge
• Link-layer connections are changing dynamically
• Goal
• Maintain an application-layer flow across
  connection lifetimes
• A flow is an end-to-end bit pipe between
  transports
• A channel is the end-to-end network-layer pipe
  through which transport-layer flows propagate
• A connection is a link-layer pipe through which
  channels propagate

Contact Networking
Flow
Channel
Connection
Connection
Link
10
Requirements forLocalized Communication

• Neighbor Discovery
• Name Resolution
• On-Demand Interface Binding
• IP Autoconfiguration
• Neighbor Routing
• Channel Management
• Infrastructure Access

Contact Networking
11
RequirementsNeighbor Discovery

• Presence
• Mobile node needs to know what neighbors it can
  access through its interfaces
• Link-layer dependence
• Discovery mechanism is necessarily specific to
  each link layer

Whos there?
Contact Networking
Whos there?
12
RequirementsName Resolution

• Simplicity
• Users want to use names instead of addresses even
  when DNS is not available
• Transparency
• Local and remote names should be the same

Its Bob!
Contact Networking
Its Alice!
13
RequirementsOn-Demand Interface Binding

• Binding is configuration to select the link-layer
  medium
• ESSID in IEEE 802.11
• Saving Power
• Desirable to keep interfaces in low-power state
• Flexibility
• Can only bind to one medium at a time

Contact Networking
I want to talk to Alice!
14
RequirementsIP Autoconfiguration

• IP needs an address
• Cant rely on DHCP
• Manual config is worse
• Fast and persistent
• Link-local IP addresses are insufficient

Alices IP
Contact Networking
Bobs IP
15
RequirementsNeighbor Routing

• Route support
• Tell IP who is at the other end of the connection
• Bidirectional
• Ensure symmetric routing

I am connected to Bob!
Bob via Bobs IP
Contact Networking
Alice via Alices IP
I am connected to Alice!
16
RequirementsChannel Management

• Multiple Neighbors
• Orchestrate simultaneous channels to several
  neighbors
• Multiple Interfaces
• Choose between potential connections to a
  neighbor
• Switch channel when connection breaks
• Proactively switch to better connections

Contact Networking
I lost my connection to Alice!
17
RequirementsInfrastructure Access

• Local is better
• Prefer local communication when possible
• But people move
• Seamlessly transition between local and remote
  communication

Contact Networking
I lost my last connection to Alice!
18
ApproachContact Networking (CN)

• Architected as several modules in two sub-layers
• Link-layer independent part (in IP layer)
• Link-layer specific part (in Link layer)

Applications
Transports
IP
Route Table
CN
Route Control
Database
Contact Networking
Link Layers
Interface Management
CNS
ND
Physical Layers
19
ArchitectureDatabase

• Neighbors
• Interfaces
• Links
• Paths

A
Contact Networking
C
B
20
ArchitectureInterface Management

• Watch for interface plugging
• Inform higher layers of new interfaces, or
• Connections broken by interface removal
• Monitor traffic to determine connection idleness
• Dont waste battery on idle connections

Contact Networking
21
ArchitectureIP Autoconfiguration

• Extend the MobileIP home address approach
• Use same Globally Routable IP (GRIP) address on
  all interfaces
• Permanent and statically configured node ID
• Sidesteps the addressing problem
• Distinct IP addresses are unnecessary for one hop
  communication
• Infrastructure access still needs topologically
  valid addresses

Contact Networking
22
Architecture Contact Naming System (CNS)

• Transparency to Users
• Every node uses its fully qualified DNS name for
  CNS
• The name DNS resolves to its GRIP
• Local and remote names are equivalent
• Transparency to Applications
• CNS and DNS use the same name resolution API

Contact Networking
23
Contact Naming System (CNS)

• Nodes are identified by CNS records
• Name
• GRIP
• Optional service information
• Browsing is possible with aliases
• any, all
• Link-layer specific name suffixes
• any.irda enables IR selection

Contact Networking
24
ArchitectureNeighbor Discovery

• Transport
• Nodes Query/Advertise CNS records using
  link-layer specific mechanisms
• Active or On-demand discovery
• Name resolution requests can trigger neighbor
  discovery
• Caching
• CNS record is coupled with neighbor knowledge
• Discovery adds new Path and Neighbor to Database

Contact Networking
25
ArchitectureRoute Control

• The brains of the operation
• Controls other modules
• Several primary responsibilities
• On-demand binding
• Neighbor routing
• Channel control
• Internet access

Contact Networking
26
Route ControlNeighbor Routing

• Catch demand indications
• Queue packets waiting for connection
  establishment
• Create IP routes to reflect link-layer
  connectivity
• Routing is GRIP-specific
• Enables transport-layer persistence

Contact Networking
27
Route ControlInfrastructure Access

• Treat the Internet as a single virtual neighbor
• Virtual paths overlay actual FA paths
• Map remote access into virtual neighbor access

Internet
Contact Networking
FA Path Virtual Path
28
Route ControlChannel Management

• Policy
• Chooses which path to connect to a neighbor
• Decides when to proactively switch connections
• Power Conservation
• Responds to idleness indications by disconnecting
  paths and unbinding interfaces

Contact Networking
29
Example

• The misadventures of hypothetical grad student,
  Prashant
• Three examples show Contact Networking performing
• Local communication
• Local communication with handoff
• Infrastructure access

Contact Networking
30
Example Network
Internet
DNS
/.
Contact Networking
31
ExamplePurely Local Communication

• Prashant loves FritosTM
• Performs purchase transaction with any.irda
• CNS engages ND to obtain Cs GRIP
• First data packet activates path, binds/connects
  IR

Contact Networking
32
Example Local Communication with Handoff

• CokeTM goes well with FritosTM
• As before, but with the soda machine
• Prashant pockets the MN, blocking IrDA
• Channel management switches paths

Contact Networking
33
ExampleInfrastructure Access

• On the way back to the office, Prashant decides
  to check the headlines on Slashdot
• This is, of course, challenging with a bag of
  FritosTM in one hand and a can of CokeTM in the
  other

Contact Networking
34
ExampleInfrastructure Access
Internet
DNS
/.
Contact Networking
35
Prototype Implementation

• Linux 2.4 Kernel
• Added support for wireless events
• Three link layers
• IrDA
• link-layer notifications
• 802.11/Ethernet
• link-layer notifications
• Virtual
• Dynamics MobileIP

• Almost complete
• Only proactive discovery
• No policy support
• Static preference order of link layers
• No proactive channel switching

Contact Networking
36
Conclusion

• Contact Networking extends traditional mobility
  support with the notion of localized mobility
• Internetworking without the Internet
• Benefits
• No changes to IP
• Link-specific mechanisms
• Light-weight discovery
• Link-failure detection
• Link-specific optimizations
• Simple setup
• No infrastructure access
• Simultaneous use of multiple interfaces

• Future Work
• Integration of Co-Link
• 802.11 scanning
• Bluetooth
• Flexible Network Support
• Inverse Multiplexing
• On-demand ad hoc cloud formation
• Integration with resource management

Contact Networking
37
Corvus A Context-Aware Mobile System

• Goals
• Use of context by the mobile system to support
  resource management
• Inclusion of system-level resources as context
• Challenges
• System resources are shared
• Context involving systems resources has complex
  dependencies
• Context involving systems resources must have
  access control
• People
• Al Harris, UIUC

38
Context and Its Use

• What is context?
• Information
• Ex time, location, available bandwidth
• What changes when we consider system resources as
  context?
• Dependencies between units of context become more
  complex
• Ex available bandwidth depends on what
  applications are using it
• Access control to context is needed
• Ex some context may be private to an application
  or the operating system
• Simple interface is needed
• Ex applications should not need to know system
  configurations to use context

Corvus
39
Context Structure

• Defines interface between context user and
  context provider
• Types
• Simple
• Single unit of information
• Ex.Time, amount of bandwidth available
• Complex
• Multiple units of information
• Ex. GPS coordinates, who is present in the room

Corvus
40
Context Acquisition

• Means by which context is acquired
• Types
• Basic
• Acquired from a single source
• Ex. Time
• Aggregate
• The union multiple units
• Ex. Bandwidth usages of applications
• Fused
• Derived from other units
• Ex. Amount of Bandwidth Available

Corvus
41
Context Mutability

• How applications affect context
• Types
• Immutable
• Applications cant change
• Ex Time of day
• Direct-mutable
• Application directly change
• Ex Desired bandwidth
• Indirect-mutable
• Applications actions can affect the context
• Ex Amount of bandwidth available on the system

APP
Corvus
APP
APP
42
Context Dependency

• Problem
• Context represents dynamically changing
  information
• Goal
• Capture the relationships between context to
  track changes
• Approach
• Context dependency graph (CDG)

Corvus
43
Context Dependency Graphs

• Context in the middle of the graph only needs to
  be recalculated when a leaf changes.

Example CDG for a Content Filtering Application
Aggregate
What Data to Send
Fused
Basic
Amount of Data to send
Presentation Data Unit Sizes
Corvus
Available Bandwidth
Time Constraints
Available Interfaces
Channel Quality
Application A Channel Usage
Application B Channel Usage
44
Context Access Control

• Accessing Context
• Current approach Context Blackboard
• Globally readable
• Globally writable
• Problem
• Applications should not be able to access and/or
  alter all context
• Approach
• Extended Context Blackboard

Corvus
45
Extended Blackboard

• Extended Blackboard contains access control
  areas Global, Application specific and OS
  specific

Read Global Write Global
Application A
Application B
Corvus
Read Global Write OS
Read Global Write Application A
Read Global Write Application B
Public
Private
Read Application A/OS Write Application A
Read Application B/OS Write Application B
Read OS Write OS
Read Application A/OS Write OS
Read Application B/OS Write OS
46
Example Scenario

• Video Feeds from two people
• A friend at home
• A colleague at work
• Presence Detection utility running at both
  locations
• Need to view feed from colleague when available

Corvus
47
Example Scenario
Video Source 1
802.11
Internet
Mobile Node
MobileIP Foreign Agent
Corvus
Video 1
Time
Public
Private
BW Needed 5 - 25fps
Priority Video 1 Med
BW Available 25fps
48
Example Scenario
Video Source 1
802.11
Internet
Mobile Node
MobileIP Foreign Agent
Video Source 2
Corvus
Video 1
Video 2
Time
Public
Private
BW Needed 5 - 25fps
BW Needed 15 - 25fps
Video 1 Med Video 2 High
BW Available 5fps
BW Available 25fps
49
Example Scenario
Video Source 1
802.11
Internet
Mobile Node
MobileIP Foreign Agent
Video Source 2
Corvus
Video 1
Video 2
Time
Public
Private
BW Needed 5 - 25fps
BW Needed 15 - 25 fps
Video 1 Med Video 2 High
BW Available 0fps
BW Available 15fps
50
Comparison

• Standard Kernel and resource management

Corvus
51
Comparison

• Priority based resource management

Corvus
52
Comparison

• Corvus performance

Corvus
53
Conclusions

• Corvus
• Context distribution and resource management
  framework
• Extended categorization
• Capture and understand context relationships
• Context Dependency Graphs
• Represent the application-context and
  context-context relationships
• Extended Blackboard
• Provided access control

Corvus
54
Future Directions

• Policy Enforcement
• Make sure applications are well-behaved
• Ex. Keep applications from trying to use more
  bandwidth then Corvus allots
• Group Management in the Blackboard
• Access area for context to be shared between a
  group of applications, but not globally

Corvus
55
Research in Mobile and Wireless Networking

• Robin Kravets
• Mobius Group
• rhk_at_cs.uiuc.edu
• http//mobius.cs.uiuc.edu