Supporting Communication for Multihomed Mobile Devices Prof Robin

Supporting Communication for Multihomed Mobile Devices Prof. Robin Kravets Mobius Group Dept. of Computer Science University of Illinois at Urbana. Champaign

Supporting Communication for Mobile Nodes n Communication resources ¡ Multiple choices n n ¡ Transparent support from the network Goal ¡ n Need information about availability Coverage varies n n Support mobile devices Requirements ¡ ¡ ¡ GPS Network Dynamically changing n ¡ No one perfect technology Range vs. Capacity vs. Power Cellular Network Satellite Network Connectivity Configuration Performance Wireless LAN Blue. Tooth Infrared Wireless LAN In-Building Infrared Home. RF Packet Radio Network

Supporting Communication for Mobile Nodes n Challenge ¡ ¡ ¡ n IR Goal ¡ n 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 n Network Layer ¡ ¡ ¡ ð n Transport Layer ¡ ¡ n 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 n Environment ¡ ¡ ¡ n Goal ¡ n 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 n Existing Solutions Contact Networking ¡ Focus on communication with devices in the Internet n n Remote communication Inefficient for communication with local devices Requires internet access Requires complex configuration Remote Communication MN MIP FA MIP HA Local Communication MN MIP FA MIP HA

Problems of Remote Communication Contact Networking n n Long-haul wireless is inherently slower and more expensive Two users meet in the desert ¡ ¡ n How about manual configuration? ¡ ¡ n Can’t use Mobile. IP 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 n Infrastructureless Contact Networking ¡ n Internetworking without the Internet Transparent ¡ ¡ User ignorant of number and type of interfaces Transparent local/remote communication n n Rendezvous, Zero. Conf Simple as beaming a business card between PDAs

Realizing a Localized Mobility System n Challenge ¡ Contact Networking n Link-layer connections are changing dynamically Goal ¡ Maintain an application-layer flow across connection lifetimes n n n 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

Requirements for Localized Communication n Contact Networking n n n Neighbor Discovery Name Resolution On-Demand Interface Binding IP Autoconfiguration Neighbor Routing Channel Management Infrastructure Access

Requirements: Neighbor Discovery n Presence Contact Networking ¡ n 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 Bob Who’s there?

Requirements: Name Resolution n Simplicity Contact Networking ¡ n 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 n Binding is configuration to select the link-layer medium ¡ n Alice Saving Power ¡ n 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 n IP needs an address ¡ ¡ n Can’t rely on DHCP Manual config is worse Alice’s IP Fast and persistent ¡ Link-local IP addresses are insufficient Bob’s IP Bob

Requirements: Neighbor Routing n Route support Contact Networking ¡ n Tell IP who is at the other end of the connection Bidirectional ¡ I am connected to Bob! Ensure symmetric routing I am connected to Alice! Alice Bob via Bob’s IP Alice via Alice’s IP Bob

Requirements: Channel Management n Multiple Neighbors Contact Networking ¡ n Orchestrate simultaneous channels to several neighbors Alice Switch my connection to Bob to WLAN. Bob I lost my connection to Alice! Multiple Interfaces ¡ ¡ ¡ Choose between potential connections to a neighbor Switch channel when connection breaks Proactively switch to better connections Carol

Requirements: Infrastructure Access n Local is better… Contact Networking ¡ n 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 n 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 n Watch for interface plugging Contact Networking ¡ ¡ n 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 n Extend the Mobile. IP home address approach Contact Networking ¡ ¡ n 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) n Transparency to Users Contact Networking ¡ Every node uses its fully qualified DNS name for CNS n ¡ n 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) n Nodes are identified by CNS records Contact Networking ¡ ¡ ¡ n Name GRIP Optional service information Browsing is possible with aliases ¡ ¡ “any”, “all” Link-layer specific name suffixes n “any. irda” enables IR selection

Architecture: Neighbor Discovery n Transport Contact Networking ¡ n Active or On-demand discovery ¡ n Nodes Query/Advertise CNS records using linklayer specific mechanisms Name resolution requests can trigger neighbor discovery Caching ¡ CNS record is coupled with neighbor knowledge n Discovery adds new Path and Neighbor to Database

Architecture: Route Control n The brains of the operation Contact Networking ¡ n Controls other modules Several primary responsibilities ¡ ¡ On-demand binding Neighbor routing Channel control Internet access

Route Control: Neighbor Routing n Catch demand indications Contact Networking ¡ n 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 n Contact Networking n n Treat the Internet as a single virtual neighbor Virtual paths overlay actual FA paths Map remote access into virtual neighbor access FA Path Virtual Neighbor Internet

Route Control: Channel Management n Policy Contact Networking ¡ ¡ n 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 n n The misadventures of hypothetical grad student, Prashant Three examples show Contact Networking performing ¡ ¡ ¡ Local communication with handoff Infrastructure access

Contact Networking Example Network Internet DNS Soda /. Chip MN

Example: Purely Local Communication Contact Networking n Prashant loves Fritos. TM ¡ 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 n Coke. TM goes well with Fritos. TM ¡ ¡ ¡ As before, but with the soda machine Prashant pockets the MN, blocking Ir. DA Channel management switches paths Soda MN

Example: Infrastructure Access Contact Networking n n On the way back to the office, Prashant decides to check the headlines on Slashdot This is, of course, challenging with a bag of Fritos. TM in one hand a can of Coke. TM in the other

Contact Networking Example: Infrastructure Access Internet DNS /. MN

Prototype Implementation n Linux 2. 4 Kernel Contact Networking ¡ n Added support for wireless events Three link layers ¡ Ir. DA n ¡ ¡ link-layer notifications Virtual n Almost complete ¡ ¡ Dynamics Mobile. IP Only proactive discovery No policy support n link-layer notifications 802. 11/Ethernet n n ¡ Static preference order of link layers No proactive channel switching

Conclusion n Contact Networking extends traditional mobility support with the notion of localized mobility Contact Networking ¡ n Internetworking without the Internet Benefits ¡ ¡ No changes to IP Link-specific mechanisms n n n ¡ ¡ ¡ Light-weight discovery Link-failure detection Link-specific optimizations Simple setup No infrastructure access Simultaneous use of multiple interfaces n 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 n Goals ¡ ¡ n Challenges ¡ ¡ ¡ n 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 n What is context? ¡ ¡ Corvus n Information Ex: time, location, available bandwidth What changes when we consider system resources as context? ¡ Dependencies between units of context become more complex n ¡ Access control to context is needed n ¡ 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 n Ex: applications should not need to know system configurations to use context

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

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

Context Mutability n n How applications affect context Types ¡ Immutable n n Corvus ¡ APP Direct-mutable n n ¡ Applications can’t change Ex: Time of day Application directly change Ex: Desired bandwidth Indirect-mutable n n Applications’ actions can affect the context Ex: Amount of bandwidth available on the system APP

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

Context Dependency Graphs Corvus n 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 Quality A Channel B Channel Usage

Context Access Control n Accessing Context ¡ ¡ Corvus ¡ n Problem ¡ n 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 n 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 n Video Feeds from two people ¡ Corvus ¡ n n 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 Mobile. IP Foreign Agent Internet Video 1 Time Public BW Needed: 5 - 25 fps Priority Video 1: Med BW Available: 25 fps Private

Example Scenario Video Source 1 802. 11 Corvus Mobile Node Mobile. IP Foreign Agent Video 1 Internet Video Source 2 Video 2 Time Video 1: Med Video 2: High Public BW Needed: 5 - 25 fps BW Needed: 15 - 25 fps BW Available: 25 fps Private

Example Scenario Video Source 1 802. 11 Corvus Mobile Node Mobile. IP Foreign Agent Video 1 Internet Video Source 2 Video 2 Time Video 1: Med Video 2: High Public BW Needed: 5 - 25 fps BW Needed: 15 - 25 fps BW Available: 0 fps BW Available: 15 fps Private

Comparison Corvus n Standard Kernel and resource management

Comparison Corvus n Priority based resource management

Comparison Corvus performance

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

Future Directions n Policy Enforcement ¡ Corvus ¡ n 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 rhk@cs. uiuc. edu http: //mobius. cs. uiuc. edu