Transcript Slides: Supporting Communication for Multihomed Mobile

Supporting Communication for
Multihomed Mobile Devices
Prof. Robin Kravets
Mobius Group
Dept. of Computer Science
University of Illinois at UrbanaChampaign
Supporting Communication for
Mobile Nodes

Communication resources

Multiple choices



Transparent support from the
network
Goal


Need information about
availability
Coverage varies


GPS Network
Dynamically changing


No one perfect technology
Range vs. Capacity vs. Power
Cellular
Network
Satellite
Network
Support mobile devices
Wireless
LAN
BlueTooth
Infrared
Requirements



Connectivity
Configuration
Performance
Wireless
LAN
In-Building
Infrared
HomeRF
Packet
Radio
Network
Supporting
Communication for Mobile Nodes

Challenge




IR
Goal


Mobile hosts have multiple
network interfaces
Coverage areas of different
technologies overlap
Mobile hosts are able to use
network access points from
different technologies
Intelligent use of multiple
interfaces
Approach

Focus on supporting
communication for a single
node
WLAN
Cell
Mobility Support Throughout
the Protocol Stack

Network Layer





Transport Layer



Connectivity
Configuration
Expose available interfaces
Contact Networking
Performance
Expose potential
configurations
Resource Management


Efficient use of resources in
the current environment
Corvus
Application
Control:
Corvus
Transport:
Network:
Contact Networking
Link Layer
Contact Networking

Environment




Goal


Mobile node
Multiple interfaces
Unknown environment
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
Contact Networking

Focus on
communication with
devices in the Internet




Remote
communication
Inefficient for
communication with
local devices
Requires internet
access
Requires complex
configuration
Remote Communication
MN
MIP
FA
MIP
HA
MN
MIP
FA
MIP
HA
Local Communication
MN
MIP
FA
MIP
HA
MN
MIP
FA
MIP
HA
Problems of
Remote Communication
Contact Networking


Long-haul wireless is inherently slower and
more expensive
Two users meet in the desert



How about manual configuration?



Can’t use MobileIP without Internet
Can’t use DNS without Internet
Complicated IP and link layer configuration
Fails the “Mom” test
Solution? Just use a floppy!
Goals of a
Localized Mobility System

Infrastructureless
Contact Networking


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
Realizing a
Localized Mobility System

Challenge

Contact Networking

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
Flow
Transport
IP
Channel
IP
Link
Connection
Link
Connection
Link
Requirements for
Localized Communication

Contact Networking






Neighbor Discovery
Name Resolution
On-Demand Interface Binding
IP Autoconfiguration
Neighbor Routing
Channel Management
Infrastructure Access
Requirements:
Neighbor Discovery

Presence
Contact Networking


Mobile node needs to
know what neighbors it
can access through its
interfaces
Alice
Who’s there?
Link-layer dependence

Discovery mechanism
is necessarily specific
to each link layer
Who’s there?
Bob
Requirements:
Name Resolution

Simplicity
Contact Networking


Users want to use
names instead of
addresses even
when DNS is not
available
Alice
It’s Bob!
Bob
It’s Alice!
Transparency

Local and remote
names should be
the same
Requirements:
On-Demand Interface Binding
Contact Networking

Binding is
configuration to select
the link-layer medium


Alice
Saving Power


ESSID in IEEE 802.11
Desirable to keep
interfaces in low-power
state
Flexibility

Can only bind to one
medium at a time
Bob
I want to talk
to Alice!
Requirements:
IP Autoconfiguration
Contact Networking

IP needs an
address



Can’t rely on DHCP
Manual config is
worse
Alice
Alice’s IP
Fast and persistent

Link-local IP
addresses are
insufficient
Bob’s IP
Bob
Requirements:
Neighbor Routing

Route support
Contact Networking


Tell IP who is at the
other end of the
connection
I am
connected to
Bob!
Bidirectional

Ensure symmetric
routing
Alice
Bob via
Bob’s IP
Alice via
Alice’s IP
I am
connected to
Alice!
Bob
Requirements:
Channel Management

Multiple Neighbors
Contact Networking


Orchestrate
simultaneous channels
to several neighbors
Alice
Multiple Interfaces



Choose between
potential connections to
a neighbor
Switch channel when
connection breaks
Proactively switch to
better connections
Switch my
connection to
Bob to
WLAN.
Carol
Bob
I lost my
connection to
Alice!
Requirements:
Infrastructure Access

Local is better…
Contact Networking


Prefer local
communication
when possible
But people move

Seamlessly
transition between
local and remote
communication
Alice
Switch my
channel to Bob
to remote
communication
.
Internet
Bob
I lost my last
connection to
Alice!
Approach:
Contact Networking (CN)
Contact Networking

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
Database
Link
Layers CNS
ND
Route
Control
Interface
Management
Physical Layers
Architecture:
Database
Neighbors
Contact Networking
Interfaces
A
Links
Paths
What Transport sees:
B
A
C
B
C
Architecture:
Interface Management

Watch for interface plugging
Contact Networking



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
Architecture:
IP Autoconfiguration

Extend the MobileIP home address
approach
Contact Networking



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
Architecture: Contact Naming
System (CNS)

Transparency to Users
Contact Networking

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 Naming System
(CNS)

Nodes are identified by CNS records
Contact Networking




Name
GRIP
Optional service information
Browsing is possible with aliases


“any”, “all”
Link-layer specific name suffixes

“any.irda” enables IR selection
Architecture:
Neighbor Discovery

Transport
Contact Networking


Active or On-demand discovery


Nodes Query/Advertise CNS records using linklayer specific mechanisms
Name resolution requests can trigger neighbor
discovery
Caching

CNS record is coupled with neighbor knowledge

Discovery adds new Path and Neighbor to Database
Architecture:
Route Control

The brains of the operation
Contact Networking


Controls other modules
Several primary responsibilities




On-demand binding
Neighbor routing
Channel control
Internet access
Route Control:
Neighbor Routing

Catch demand indications
Contact Networking


Queue packets waiting for connection
establishment
Create IP routes to reflect link-layer
connectivity


Routing is GRIP-specific
Enables transport-layer persistence
Route Control:
Infrastructure Access

Contact Networking


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
Virtual
Neighbor
Internet
Route Control:
Channel Management

Policy
Contact Networking



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
Example
Contact Networking


The misadventures of hypothetical
grad student, Prashant
Three examples show Contact
Networking performing



Local communication
Local communication with handoff
Infrastructure access
Contact Networking
Example Network
Internet
DNS
/.
Soda
Chip
MN
Example:
Purely Local Communication
Contact Networking

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
MN
Example: Local
Communication with Handoff
Contact Networking

CokeTM goes well
with FritosTM



As before, but with
the soda machine
Prashant pockets
the MN, blocking
IrDA
Channel
management
switches paths
Soda
MN
Example:
Infrastructure Access
Contact Networking


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
Example:
Infrastructure Access
Internet
DNS
/.
MN
Prototype Implementation

Linux 2.4 Kernel
Contact Networking


Added support for
wireless events
Three link layers

IrDA


Almost complete


link-layer notifications
Virtual

Dynamics MobileIP
Only proactive
discovery
No policy support

link-layer notifications
802.11/Ethernet




Static preference
order of link layers
No proactive
channel switching
Conclusion

Contact Networking extends
traditional mobility support with
the notion of localized mobility
Contact Networking


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
Corvus:
A Context-Aware Mobile System

Goals



Challenges




Use of context by the mobile system to support resource
management
Inclusion of system-level resources as context
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?


Corvus

Information
Ex: time, location, available bandwidth
What changes when we consider system resources
as context?

Dependencies between units of context become more
complex


Access control to context is needed


Ex: available bandwidth depends on what applications are
using it
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
Context Structure


Defines interface between context user and
context provider
Types
Corvus

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
Context Acquisition


Means by which context is
acquired
Types

Basic
Corvus



Aggregate



Acquired from a single
source
Ex.: Time
The union multiple units
Ex.: Bandwidth usages of
applications
Fused


Derived from other units
Ex.: Amount of Bandwidth
Available
Context Mutability


How applications affect
context
Types

Immutable

Corvus


Direct-mutable



Applications can’t change
Ex: Time of day
APP
Application directly change
Ex: Desired bandwidth
APP
Indirect-mutable


Applications’ actions can
affect the context
Ex: Amount of bandwidth
available on the system
APP
Context Dependency

Problem
Corvus


Goal


Context represents dynamically changing
information
Capture the relationships between
context to track changes
Approach

Context dependency graph (CDG)
Context Dependency Graphs
Corvus

Context in the
middle of the graph
only needs to be
recalculated when
a leaf changes.
Example CDG for a Content
Filtering Application
What Data to
Send
Aggregate
Fused
Basic
Presentation
Data Unit
Sizes
Time
Constraints
Available
Interfaces
Amount of
Data to send
Available
Bandwidth
Channel Application Application
Quality A Channel B Channel
Usage
Usage
Context Access Control

Accessing Context


Corvus


Problem


Current approach: Context Blackboard
Globally readable
Globally writable
Applications should not be able to access and/or
alter all context
Approach

Extended Context Blackboard
Extended Blackboard
Corvus

Extended Blackboard contains access control
areas: Global, Application specific and OS specific
Read: Global
Write: Global
Read: Global
Write: OS
Read: OS
Write: OS
Application A
Application B
Read: Global
Write: Application A
Read: Global
Write: Application B
Read: Application A/OS
Write: Application A
Read: Application B/OS
Write: Application B
Read: Application A/OS
Write: OS
Read: Application B/OS
Write: OS
Public
Private
Example Scenario

Video Feeds from two people

Corvus



A friend at home
A colleague at work
Presence Detection utility running at
both locations
Need to view feed from colleague
when available
Example Scenario
Video
Source 1
802.11
Corvus
Mobile
Node
MobileIP
Foreign
Agent
Internet
Video 1
Time
Public
BW Needed: 5 - 25fps
Priority
Video 1: Med
BW Available: 25fps
Private
Example Scenario
Video
Source 1
802.11
Corvus
Mobile
Node
MobileIP
Foreign
Agent
Video 1
Internet
Video
Source 2
Video 2
Time
Video 1: Med
Video 2: High
Public
BW Needed: 5 - 25fps
BW Needed: 15 - 25fps
BW Available: 5fps
BW Available: 25fps
Private
Example Scenario
Video
Source 1
802.11
Corvus
Mobile
Node
MobileIP
Foreign
Agent
Video 1
Internet
Video
Source 2
Video 2
Time
Video 1: Med
Video 2: High
Public
BW Needed: 5 - 25fps
BW Needed: 15 - 25 fps
BW Available: 0fps
BW Available: 15fps
Private
Comparison

Standard Kernel and resource management
Frames per Second
Corvus
35
Collegue
Friend
30
25
20
15
10
5
0
0
5
10
15
20
25
Time (min)
30
35
40
Comparison

Priority based resource management
Frames per Second
Corvus
35
Collegue
Friend
30
25
20
15
10
5
0
0
5
10
15
20
25
Time (min)
30
35
40
Comparison

Corvus performance
Frames per Second
Corvus
35
30
Collegue
Friend
25
20
15
10
5
0
0
5
10
15
20
25
Time (min)
30
35
40
Conclusions

Corvus:

Corvus

Extended categorization


Capture and understand context relationships
Context Dependency Graphs


Context distribution and resource management
framework
Represent the application-context and contextcontext relationships
Extended Blackboard

Provided access control
Future Directions

Policy Enforcement

Corvus


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
Research in Mobile and
Wireless Networking
Robin Kravets
Mobius Group
[email protected]
http://mobius.cs.uiuc.edu