Supporting Communication for Multihomed Mobile Devices
description
Transcript of Supporting Communication for Multihomed Mobile Devices
Supporting Communication for Multihomed Mobile Devices
Prof. Robin KravetsMobius Group
Dept. of Computer ScienceUniversity of Illinois at Urbana-Champaign
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
Wireless LAN
In-Building Infrared
HomeRF
Satellite Network
GPS NetworkPacket Radio
Network
Wireless LAN
BlueTooth
Infrared
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
IR
WLAN
Cell
Transport:
Network:Contact Networking
Control:Corvus
Link Layer
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
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
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
Local Communication
MN MIPFA
MIP HA
MN MIPFA
MIP HA
MN MIPFA
MIP HA
MN MIPFA
MIP HA
Con
tact
Net
wor
king
Problems of Remote Communication
Long-haul wireless is inherently slower and more expensive
Two users meet in the desert Can’t use MobileIP without Internet Can’t use DNS without Internet
How about manual configuration? Complicated IP and link layer configuration Fails the “Mom” test
Solution? Just use a floppy!
Con
tact
Net
wor
king
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
Con
tact
Net
wor
king
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
Transport
IP
Link
Channel
Connection
Flow
Link Connection
Transport
IP
Link
Con
tact
Net
wor
king
Requirements forLocalized Communication
Neighbor Discovery Name Resolution On-Demand Interface Binding IP Autoconfiguration Neighbor Routing Channel Management Infrastructure Access
Con
tact
Net
wor
king
Requirements:Neighbor 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
Alice Who’s there?
Who’s there?Bob
Con
tact
Net
wor
king
Requirements:Name 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
Alice It’s Bob!
It’s Alice!Bob
Con
tact
Net
wor
king
Requirements:On-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
Alice
I want to talk to Alice!
Bob
Con
tact
Net
wor
king
Requirements:IP Autoconfiguration
IP needs an address Can’t rely on DHCP Manual config is
worse Fast and persistent
Link-local IP addresses are insufficient
Alice
Bob
Bob’s IP
Alice’s IP
Con
tact
Net
wor
king
Requirements:Neighbor Routing
Route support Tell IP who is at the
other end of the connection
Bidirectional Ensure symmetric
routing
Alice
I am connected to
Alice!Bob
I am connected to
Bob!Bob via Bob’s IP
Alice via Alice’s IPC
onta
ct N
etw
orki
ng
Requirements:Channel 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
Alice
Bob
Carol
I lost my connection to
Alice!
Switch my connection to
Bob to WLAN.
Con
tact
Net
wor
king
Requirements:Infrastructure Access
Local is better… Prefer local
communication when possible
But people move Seamlessly
transition between local and remote communication
BobI lost my last connection to
Alice!
Switch my channel to Bob
to remote communication
.
InternetInternet
Alice
Con
tact
Net
wor
king
Approach:Contact 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
IP
LinkLayers
Transports
Route Table
CN
DatabaseRoute Control
Interface ManagementCNS ND
Physical Layers
Con
tact
Net
wor
king
Neighbors
Interfaces
Links
Paths
Architecture:Database
A
CBA
CB
What Transport sees:
Con
tact
Net
wor
king
Architecture:Interface Management
Watch for interface plugging Inform higher layers of new interfaces, or Connections broken by interface removal
Monitor traffic to determine connection idleness Don’t waste battery on idle connections
Con
tact
Net
wor
king
Architecture:IP 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
Con
tact
Net
wor
king
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
Con
tact
Net
wor
king
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
Con
tact
Net
wor
king
Architecture:Neighbor 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
Con
tact
Net
wor
king
Architecture:Route Control
The brains of the operation Controls other modules
Several primary responsibilities On-demand binding Neighbor routing Channel control Internet access
Con
tact
Net
wor
king
Route Control:Neighbor 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
Con
tact
Net
wor
king
Virtual Neighbor
Internet
Route Control:Infrastructure Access
Treat the Internet as a single virtual neighbor
Virtual paths overlay actual FA paths
Map remote access into virtual neighbor access
FA Path
Virtual Path
Con
tact
Net
wor
king
Route Control:Channel 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
Con
tact
Net
wor
king
Example
The misadventures of hypothetical grad student, Prashant
Three examples show Contact Networking performing Local communication Local communication with handoff Infrastructure access
Con
tact
Net
wor
king
Example Network
MN
/.
InternetDNS
Soda ChipCon
tact
Net
wor
king
Example:Purely Local Communication
Prashant loves FritosTM
Performs purchase transaction with “any.irda”
CNS engages ND to obtain C’s GRIP
First data packet activates path, binds/connects IR
Chip
MNCon
tact
Net
wor
king
CokeTM goes well with FritosTM
As before, but with the soda machine
Prashant pockets the MN, blocking IrDA
Channel management switches paths
Example: Local Communication with Handoff
MN
Soda
Con
tact
Net
wor
king
Example:Infrastructure 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 otherC
onta
ct N
etw
orki
ng
Example:Infrastructure Access
MN
DNS
/.
Internet
Con
tact
Net
wor
king
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 switchingC
onta
ct N
etw
orki
ng
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
Con
tact
Net
wor
king
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
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
Cor
vus
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
Cor
vus
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
Cor
vus
Context Mutability
How applications affect context
Types Immutable
Applications can’t 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
APP
APP
Cor
vus
Context Dependency
Problem Context represents dynamically changing
information Goal
Capture the relationships between context to track changes
Approach Context dependency graph (CDG)
Cor
vus
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
Available Interfaces
Channel Quality
Application A Channel
Usage
Application B Channel
Usage
Aggregate
Fused
Basic
Presentation Data Unit
Sizes
Time Constraints
Available Bandwidth
Amount of Data to send
What Data to Send
Cor
vus
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
Cor
vus
Extended Blackboard
Extended Blackboard contains access control areas: Global, Application specific and OS specific
Public
Private
Read: GlobalWrite: Global
Read: GlobalWrite: OS
Read: OSWrite: OS
Application A
Read: GlobalWrite: Application A
Read: Application A/OSWrite: Application A
Read: Application A/OSWrite: OS
Application B
Read: GlobalWrite: Application B
Read: Application B/OSWrite: Application B
Read: Application B/OSWrite: OS
Cor
vus
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
Cor
vus
Example Scenario
Video Source 1
Mobile Node
MobileIP Foreign Agent
802.11
InternetInternet
Public
Private
Time
PriorityVideo 1: Med
Video 1
BW Needed: 5 - 25fps
BW Available: 25fps
Cor
vus
Example Scenario
Public
Private
Video Source 1
Mobile Node
MobileIP Foreign Agent
802.11
Video Source 2
InternetInternet
Time
Video 1: MedVideo 2: High
Video 1
BW Needed: 5 - 25fps
BW Available: 5fps
Video 2
BW Needed: 15 - 25fps
BW Available: 25fps
Cor
vus
Example Scenario
Public
Private
Video Source 1
Mobile Node
MobileIP Foreign Agent
802.11
Video Source 2
InternetInternet
Time
Video 1: MedVideo 2: High
Video 1
BW Needed: 5 - 25fps
BW Available: 0fps
Video 2
BW Needed: 15 - 25 fps
BW Available: 15fps
Cor
vus
Comparison
Standard Kernel and resource management
0
5
10
15
20
25
30
35
0 5 10 15 20 25 30 35 40
Time (min)
Fra
me
s p
er
Se
co
nd Collegue
Friend
Cor
vus
Comparison
Priority based resource management
0
5
10
15
20
25
30
35
0 5 10 15 20 25 30 35 40
Time (m in)
Fra
me
s p
er
Se
co
nd Collegue
Friend
Cor
vus
Comparison
Corvus performance
0
5
10
15
20
25
30
35
0 5 10 15 20 25 30 35 40
Time (min)
Fra
me
s p
er
Se
co
nd Collegue
Friend
Cor
vus
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
Cor
vus
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
Cor
vus
Research in Mobile and Wireless Networking
Robin Kravets
Mobius Group
http://mobius.cs.uiuc.edu