1 / 55

Supporting Communication for Multihomed Mobile Devices

Supporting Communication for Multihomed Mobile Devices. Prof. Robin Kravets Mobius Group Dept. of Computer Science University of Illinois at Urbana-Champaign. Communication resources Multiple choices No one perfect technology Range vs. Capacity vs. Power Dynamically changing

alavender
Télécharger la présentation

Supporting Communication for Multihomed Mobile Devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 Supporting Communication for Mobile Nodes Cellular Network Satellite Network GPS Network Packet Radio Network Wireless LAN BlueTooth Infrared Wireless LAN In-Building Infrared HomeRF

  3. 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 Supporting Communication for Mobile Nodes

  4. 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 Link Layer Mobility Support Throughout the Protocol Stack 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. Existing Solutions Focus on communication with devices in the Internet Remote communication Inefficient for communication with local devices Requires internet access Requires complex configuration Local vs. Remote Communication 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 • 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! 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. Transport IP Link Transport IP Link 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. 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 Bob Requirements:Neighbor Discovery Who’s there? Contact Networking Who’s there?

  12. 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 Bob Requirements:Name Resolution It’s Bob! Contact Networking It’s Alice!

  13. 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 Bob Requirements:On-Demand Interface Binding Contact Networking I want to talk to Alice!

  14. IP needs an address Can’t rely on DHCP Manual config is worse Fast and persistent Link-local IP addresses are insufficient Alice Bob Requirements:IP Autoconfiguration Alice’s IP Contact Networking Bob’s IP

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

  16. 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 Switch my connection to Bob to WLAN. Alice Carol Bob Requirements:Channel Management Contact Networking I lost my connection to Alice!

  17. Local is better… Prefer local communication when possible But people move Seamlessly transition between local and remote communication Switch my channel to Bob to remote communication. Alice Internet Bob Requirements:Infrastructure Access Contact Networking I lost my last connection to Alice!

  18. 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 Transports IP Route Table CN Route Control Database Contact Networking Link Layers Interface Management CNS ND Physical Layers

  19. What Transport sees: A B C Architecture:Database Neighbors Interfaces Links Paths A Contact Networking B C

  20. 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 Contact Networking

  21. 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 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. 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 Contact Networking

  25. Architecture:Route 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 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 Contact Networking

  27. Treat the Internet as a single virtual neighbor Virtual paths overlay actual FA paths Map remote access into virtual neighbor access Virtual Neighbor Route Control:Infrastructure Access Internet Contact Networking FA Path Virtual Path

  28. 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 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. Soda Chip MN Example Network Internet DNS /. Contact Networking

  31. 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:Purely Local Communication Contact Networking

  32. 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: Local Communication with Handoff Contact Networking

  33. 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 other Contact Networking

  34. MN Example:Infrastructure Access Internet DNS /. Contact Networking

  35. 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 Prototype Implementation Contact Networking

  36. 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 Conclusion 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. 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 Context Acquisition Corvus

  41. 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 Context Mutability 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 in the middle of the graph only needs to be recalculated when a leaf changes. Context Dependency Graphs 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

More Related