1Mobility(and philosophical questions aboutnames and identity)David AndersenCMU CS 15-744The problem• How to “support” mobile users• What do we mean by support?• Make it easy and convenient to effectivelyuse the network while moving fromlocation to location2The Solution Space• Where can we address this problem?– Physical layer? (sure; very limited)– Link layer– Transport layer– “Something higher” (often called session)– Application layerThe questions• What components are affected?– E.g., what needs to explicitly support mobility?– Is it incrementally deployable?• What timescales does it support?• What geographic/logical bounds does it place onmobility?• What overhead does it impose?• How does it affect or interact with other aspectsof the architecture?• How does it scale?3Who are we supporting?• What kinds of mobility scenarios shouldwe support?– Talking on a VoIP phone while walking downthe street?– Navigating with a laptop in a car?– Using a laptop in an airplane?– Taking laptop from home to work?– Walking around lab or campus?– Something we haven’t thought of yet??Try #1: No Network Support(Applications are on their own)• Let them disconnect and reconnect whenthey arrive at a new location.– Network support needed: None / DHCP– Your SSH sessions die.  Your streamingmedia probably gets interrupted.– Some applications have already workedaround this:• Your Web browser doesn’t care• Your IMAP mail reader probably doesn’t care4Dealing with disconnection• Possible to code many applications to dealwith disconnection– It’s all about trying to resume and managingstate (we’ll come back to this)– But should the burden be placed on everyapplication developer?So – Application?• What components are affected?– Any application that wants to work• What timescales does it support?– End-to-end application communication. Seconds?• What geographic/logical bounds does it place onmobility?– None• What overhead does it impose?– Lots of programmer overhead• How does it affect or interact with other aspects of thearchitecture?– Nothing’s changed5Try #2: Link-layer mobility• Have the link layer mask mobility– E.g., the campus 802.11 wireless. You can moveanywhere and keep the same MAC and IP address• Completely transparent. No OS/App supportneeded. Brilliant!• Fast & Local: Only switches near moving clientmust be updated.• But – only local! Can’t move out of your subnet.So – Link?• What components are affected?– The local switching infrastructure• What timescales does it support?– Pretty durned fast• What geographic/logical bounds does it place onmobility?– Can only move within local subnet• What overhead does it impose?– Little• How does it affect or interact with other aspects of thearchitecture?– Could encourage ideas like making all of CMU a singlebroadcast domain. Oops, too late. 6IP Layer Mobility• Allow hosts to take their “home” IPaddress with them wherever they go.• Advantages:– Potentially global mobility scope (not limited tosubnet like link layer)– Transparent to applications and layers aboveIP• How can we do it?– (Many ways, each with own costs)Brute Force: IP routing• If node leaves home, send out (global?) routingannouncement pointing to new location– In theory, “just works”– Example: Boeing’s “Connexion” announced a /24 intoBGP for every supported airplane and moved theannouncement to the gateway the plane was closestto– Why? Latency concerns over really long flights (startin SF, end in London)– Already have high latency from using satellites. Ow.7Brute force 2• May be feasible for Boeing• But wouldn’t scale for single IP addresses– Every AS in world would have routing entry forevery mobile user in the world? Ouch!• Problem: Having the whole world maintainstate for every user• Alternative: Keep state local, by…Mobile IP (& others):• Same as other problems in ComputerScience– Add a level of indirection• Keep some part of the network informedabout current location– Need technique to route packets through thislocation (interception)• Need to forward packets from this locationto mobile host (delivery)8Interception• Somewhere along normal forwarding path– At source– Any router along path– Router to home network– **Machine on home network (masqueradingas mobile host)Delivery• Get packet to mobile’s current location• Tunnels– Tunnel endpoint = current location– Tunnel contents = original packets• Source routing?– Loose source route through mobile currentlocation (not widely supported)• Network address translation (NAT)– What about packets from the mobile host?9Mobile IP (RFC 2290)• Interception– Typically home agent – hosts on homenetwork• Delivery– Typically IP-in-IP tunneling– Endpoint – either temporary mobile addressor foreign agent• Terminology– Mobile host (MH), correspondent host (CH),home agent (HA), foreign agent (FA)– Care-of-address, home addressMobile IP (MH at Home)Mobile Host (MH)VisitingLocationHomeInternetCorrespondent Host (CH)Packet10Mobile IP (MH Moving)VisitingLocationHomeInternetCorrespondent Host (CH)PacketHome Agent (HA)Mobile Host (MH)I am hereMobile IP (MH Away – ForeignAgent)VisitingLocationHomeInternetCorrespondent Host (CH)PacketHome Agent (HA)Foreign Agent (FA)EncapsulatedMobile Host (MH)11Mobile IP (MH Away -Collocated)VisitingLocationHomeInternetCorrespondent Host (CH)PacketHome Agent (HA)Mobile Host (MH)EncapsulatedOther Mobile IP Issues• Route optimality– Triangle routing– Can be improved with route optimization• Unsolicited binding cache update to sender• Authentication– Registration messages– Binding cache updates• Must send updates across network– Handoffs can be slow• Problems with basic solution– Reverse path check for security– Do we really need it?12TCP Migrate• Transport-layer solution• Idea: No IP support; just have transportlayer dynamically re-bind endpointsThe Migrate Approach• Locate hosts through existing DNS– Secure, dynamic DNS is currently deployed andwidely available (RFC 2137)– Maintains standard IP addressing model• IP address are topological addresses, not Ids• Fundamental to Internet scaling properties• Ensure seamless connectivity throughconnection migration– Notify only the current set of correspondent hosts–