Handling Mobility and Mul/-homing in the IP Internet - - PDF document

11/10/16 ¡ 1 ¡

1

CMPE 252A 252A: : Comput

• mputer

er Communica

• mmunication

ion SET 12: 12:

Handling ¡Mobility ¡and ¡ ¡ Mul/-­‑homing ¡in ¡the ¡IP ¡Internet ¡

Why Are Mobility and Multi-Homing Important Now?

q Network ¡mobility ¡and ¡mul6-­‑homing ¡are ¡a ¡fast ¡ ¡

growing ¡concern ¡for ¡network ¡operators… ¡

– 26 ¡billion ¡mobile ¡devices ¡expected ¡by ¡2020 ¡ – The ¡“typical” ¡end ¡host ¡is ¡nomadic ¡ – Cloud ¡services ¡are ¡virtualized/replicated/migrated ¡ – V(X)LANs ¡are ¡equally ¡mobile/dynamic ¡

q …But ¡there ¡s6ll ¡exists ¡no ¡good ¡solu6on! ¡

– Current ¡state-­‑of-­‑the-­‑art: ¡restart ¡the ¡connec6on ¡L ¡

Related Work: Network Layer

q Network-­‑layer ¡solu6ons ¡(MIP, ¡LISP, ¡shim6, ¡LIN6) ¡

– Support ¡ ¡network ¡mobility ¡at ¡the ¡network ¡layer ¡ – Support ¡all ¡higher-­‑layers ¡without ¡modifica6on ¡

q Problems: ¡ ¡

– Address-­‑space ¡fragmenta6on ¡ – Triangle ¡rou6ng ¡ – Infeasible ¡rou6ng-­‑table ¡growth ¡ – Requires ¡changes ¡to ¡the ¡Internet ¡rou6ng ¡infrastructure ¡

11/10/16 ¡ 2 ¡

Mobile IP (MIP)

q Static home address and

dynamic care-of-address

q HA and FA needed q Tunneling needed between HA and

FA (and associated complications).

q HA must be updated if changes to

address of mobile node occur.

q Suboptimum paths to “static”

addresses.

q More complex infrastructure (i.e.,

HA and FA)

q HA and FA may become bottlenecks

Host: ¡Discover ¡the ¡care-­‑of ¡address, ¡ register ¡the ¡care-­‑of ¡address, ¡update ¡ the ¡care-­‑of ¡address ¡ HA ¡& ¡FA: ¡Tunnel ¡to ¡the ¡care-­‑of ¡address ¡ Original ¡goal: ¡Do ¡not ¡change ¡end ¡hosts ¡ ¡or ¡routers ¡ But ¡new ¡protocols ¡needed ¡between ¡host, ¡FA ¡and ¡MA ¡anyway! ¡

Related Work: Higher Layers

q Transport-­‑layer ¡solu6ons ¡(many ¡TCP ¡variants) ¡

– Completely ¡restrict ¡modifica6ons ¡to ¡end-­‑hosts ¡ – Migrate ¡each ¡connec6on ¡individually ¡ – O]en ¡require ¡apps ¡to ¡be ¡opt-­‑in ¡modified ¡

q Applica6on-­‑layer ¡solu6ons ¡(SIP, ¡DHTs, ¡etc.) ¡

– Easier ¡to ¡implement/deploy ¡than ¡network ¡layer ¡ – Don’t ¡actually ¡support ¡socket/connec6on ¡migra6on ¡

¡

MTCP: Multipath TCP

q Add ¡a ¡mul6plexing ¡sublayer ¡within ¡TCP ¡to ¡

handle ¡one ¡connec6on ¡per ¡path ¡

11/10/16 ¡ 3 ¡

Related Work: Future Internet

q Many ¡works ¡propose ¡adding ¡a ¡“Host ¡ID ¡layer” ¡

– Makes ¡architectural ¡sense, ¡splits ¡IDs ¡from ¡locators ¡ – Supports ¡all ¡higher ¡layers, ¡but ¡doesn’t ¡change ¡IP ¡

q Clean ¡slate ¡(e.g., ¡NDN ¡and ¡CCNx): ¡Eliminate ¡

addresses ¡altogether. ¡

q Problems: ¡

– must ¡change ¡every ¡end-­‑host! ¡ – Altering ¡the ¡protocol ¡stack ¡breaks ¡compa6bility ¡ – Requires ¡a ¡“flag ¡day,” ¡cannot ¡be ¡“opt-­‑in” ¡model ¡ – Future ¡“lock ¡in” ¡to ¡a ¡new ¡iden6fier ¡model ¡

HIP: Host Identity Protocol

q Separates ¡transport ¡layer ¡from ¡network ¡layer. ¡ q Binding ¡to ¡host ¡ID ¡and ¡not ¡IP ¡addresses ¡

There Is Another Way!

Let’s ¡take ¡the ¡best ¡parts ¡of ¡all ¡approaches: ¡

– Architecturally ¡split ¡the ¡ID ¡and ¡Locator ¡ spaces ¡ – Restrict ¡changes ¡to ¡end-­‑hosts, ¡not ¡routers ¡ – Enable ¡“opt-­‑in” ¡deployment ¡ – Allow ¡the ¡network ¡layer ¡to ¡focus ¡on ¡rou6ng ¡ – Keep ¡the ¡transport ¡layer ¡simple ¡ – Support ¡unmodified ¡applica6ons ¡

q Why ¡don’t ¡we ¡have ¡it ¡yet? ¡

11/10/16 ¡ 4 ¡

Understanding of Identifiers

q Take a look at: John Shoch, “Inter-Network

Naming, Addressing, and Routing,” IEN 19, Jan. 1978.

The name of a resource indicates what we seek, an address indicates where it is, and a route tell us how to get there.

q This informal definition of names, addresses and

routes has been the norm since the beginning of the Internet.

q Definition does not define the three types of

identifiers very clearly.

q It does not specify the assumptions used for the

assignment of those identifiers.

Implementation of Protocol Stacks

q The identifier used to denote a process in the protocol at

layer N is passed up or down the stack without modification.

q Some protocols make explicit use of the identifiers used

in lower-layer protocols (e.g., TCP, UDP use IP addresses used at the network layer).

Layer-N Protocol Entity Layer-N Protocol Entity Layer-(N - 1) Protocol Entity Layer-(N - 1) Protocol Entity

(virtual communication)

Layer N packets

interface

NODE A NODE B

protocol

Why Is This A Problem?

q It is not just about names, addresses and routes, and there is no reason

why identifiers remain unchanged across layers of protocol stack.

PHYSICAL LINK NETWORK TRANSPORT SESSION PRESENTATION APPLICATION

Socket ¡is ¡an ¡iden6fier ¡deno6ng ¡a ¡process ¡ name ¡at ¡“this ¡site” ¡ ¡ ¡which ¡should ¡be ¡ independent ¡of ¡where ¡the ¡site ¡is ¡rela6ve ¡to ¡ the ¡network ¡topology ¡(address). ¡ Address ¡is ¡an ¡iden6fier ¡deno6ng ¡one ¡of ¡ possibly ¡mul6ple ¡points ¡of ¡agachment ¡of ¡the ¡ same ¡site ¡(mul6-­‑homing) ¡to ¡the ¡network ¡ Route ¡is ¡an ¡associa6on ¡between ¡two ¡ iden6fiers ¡(unicas6ng) ¡deno6ng ¡points ¡of ¡ agachment ¡of ¡sites. ¡ Name ¡given ¡by ¡applica6on ¡denotes ¡a ¡ resource; ¡resources ¡are ¡accessed ¡through ¡ “windows” ¡to ¡the ¡OS. ¡ ¡ ¡

We ¡will ¡always ¡need ¡ ¡ “addresses” ¡ ¡to ¡have ¡ routes ¡between ¡processes ¡

11/10/16 ¡ 5 ¡

Big Problem: Early Binding

q Applica6on ¡processes ¡“bind” ¡to ¡sta6c ¡IP ¡addresses. ¡ q Connec6ons ¡are ¡broken ¡if ¡the ¡addresses ¡change. ¡

Hidden Identifiers

q Opaque ¡values ¡bound ¡by ¡higher ¡layers ¡in ¡the ¡

stack ¡

q Sit ¡between ¡layers ¡of ¡a ¡protocol ¡stack ¡ q Translate ¡as ¡datagrams ¡pass ¡up ¡or ¡down ¡the ¡

stack ¡

q Are ¡NOT ¡a ¡new ¡protocol ¡or ¡layer ¡in ¡the ¡stack ¡ q Essen6ally ¡similar ¡to ¡file ¡descriptors ¡( ¡handles ¡

used ¡in ¡UNIX ¡to ¡access ¡files ¡and ¡I/O ¡resources) ¡

Hidden Identifiers

From ¡This… ¡

11/10/16 ¡ 6 ¡

Hidden Identifiers

To ¡This! ¡

The DIME Network Stack

The ¡DIME ¡network ¡stack ¡uses ¡a ¡single ¡hidden ¡ iden6fier ¡called ¡the ¡HID ¡to ¡refer ¡to ¡foreign ¡hosts ¡ ¡ The ¡HID ¡table ¡stores ¡and ¡classifies ¡every ¡address ¡

• wned ¡by ¡a ¡foreign ¡host ¡

HID Address Categories

q Ac/ve ¡Addresses: ¡addresses ¡owned ¡by ¡the ¡

foreign ¡host ¡that ¡the ¡local ¡host ¡can ¡reach ¡ ¡

q Unreachable ¡Addresses: ¡addresses ¡that ¡the ¡

local ¡host ¡cannot ¡reach ¡(e.g., ¡ ¡private ¡IPs) ¡ ¡

q Local ¡Addresses: ¡addresses ¡that ¡the ¡local ¡host ¡

has ¡adver6sed ¡to ¡the ¡foreign ¡host ¡

11/10/16 ¡ 7 ¡ Sending Datagrams With DIME DIME and Location Management

Loca/on ¡Managers: ¡

1: ¡Take ¡as ¡input ¡an ¡iden6fier ¡(e.g., ¡a ¡DNS ¡hostname) ¡ ¡from ¡a ¡network ¡applica6on ¡ 2: ¡Resolve ¡the ¡iden6fier ¡to ¡a ¡set ¡of ¡addresses ¡ 3: ¡Bind ¡the ¡address ¡set ¡to ¡a ¡new ¡HID ¡ 4: ¡Return ¡the ¡HID ¡to ¡the ¡applica6on ¡

DIME and Location Management

Loca/on ¡Managers: ¡

– ¡ Are ¡primarily ¡responsible ¡for ¡crea6ng ¡new ¡HIDs ¡ – ¡ DO ¡assume ¡that ¡the ¡bindings ¡are ¡ini6ally ¡valid ¡ – ¡ DO ¡NOT ¡maintain ¡or ¡update ¡iden6fier ¡bindings ¡

¡ Current ¡Support ¡For: ¡ ¡DNS ¡ ¡HIP ¡tags ¡ ¡IPv4 ¡ ¡IPv6 ¡

11/10/16 ¡ 8 ¡

DIME and Host Mobility

The ¡Internet ¡Host ¡Mobility ¡Protocol ¡(IHMP) ¡is ¡ responsible ¡for ¡upda6ng ¡HID ¡bindings ¡as ¡hosts ¡ gain ¡and ¡lose ¡network ¡addresses. ¡IHMP: ¡

– Is ¡contained ¡en6rely ¡at ¡end-­‑hosts ¡(not ¡routers) ¡ – Is ¡out-­‑of-­‑band ¡with ¡respect ¡to ¡the ¡data-­‑plane ¡ – Is ¡implemented ¡as ¡a ¡user-­‑space ¡UDP ¡process ¡ – Listens ¡to ¡the ¡system ¡for ¡network ¡events ¡ – Interacts ¡closely ¡with ¡the ¡HID ¡table ¡

IHMP: Initial Address Exchange

When ¡a ¡new ¡HID ¡is ¡created, ¡IHMP ¡starts ¡a ¡ HELLO-­‑ACK ¡exchange ¡with ¡the ¡foreign ¡host. ¡ Hosts ¡exchange ¡their ¡en6re ¡address-­‑set, ¡ categorize ¡foreign ¡addresses ¡by ¡their ¡ reachability, ¡and ¡add ¡them ¡to ¡HID ¡tables ¡

IHMP: Initial Address Exchange

Known-­‑Reachable: ¡The ¡address ¡is ¡part ¡of ¡a ¡ unique ¡subnet ¡reachable ¡by ¡the ¡local ¡host ¡ ¡ Known-­‑Unreachable: ¡The ¡address ¡is ¡part ¡of ¡a ¡ subnet ¡that ¡the ¡local ¡host ¡cannot ¡reach ¡ ¡ Poten/ally-­‑Reachable: ¡The ¡address ¡is ¡in ¡a ¡ reachable ¡subnet, ¡but ¡the ¡subnet ¡itself ¡might ¡ not ¡be ¡unique ¡(e.g. ¡10.0.0.0/8) ¡

11/10/16 ¡ 9 ¡

IHMP: Path Probing

If ¡an ¡address ¡is ¡poten/ally ¡reachable, ¡then ¡ (un)reachability ¡must ¡be ¡confirmed ¡ ¡ IHMP ¡sends ¡out ¡a ¡PATH_PROBE ¡message ¡to ¡the ¡ address ¡in ¡ques6on ¡and ¡waits ¡for ¡a ¡response ¡ ¡ IHMP ¡responds ¡to ¡path ¡probes ¡with ¡an ¡ACK ¡

IHMP: Initial Address Exchange

IHMP: Address Updates

When ¡Address-­‑Up ¡or ¡–Down ¡events ¡occur, ¡IHMP ¡ sends ¡an ¡update ¡message ¡to ¡all ¡foreign ¡HIDs ¡ ¡

q IHMP ¡sends ¡this ¡message ¡even ¡if ¡the ¡address ¡

was ¡unreachable ¡by ¡the ¡foreign ¡host ¡

q If ¡two ¡events ¡happen, ¡IHMP ¡combines ¡them ¡

into ¡a ¡single ¡HANDOFF ¡message ¡

q Foreign ¡hosts ¡respond ¡with ¡an ¡ACK ¡

11/10/16 ¡ 10 ¡ Implementation and Evaluation

q Network ¡stack ¡a ¡Linux ¡kernel ¡module ¡ q IHMP ¡and ¡locators ¡implemented ¡in ¡user ¡space ¡ q Comparisons ¡with ¡Mul6path ¡TCP ¡(MPTCP) ¡and ¡

Host ¡Iden6ty ¡Protocol ¡(HIP): ¡end-­‑to-­‑end ¡ latency, ¡throughput, ¡and ¡control ¡overhead ¡

– Why ¡not ¡MIP? ¡Focusing ¡on ¡end-­‑host ¡solu6ons ¡ – Why ¡not ¡ILNP? ¡No ¡public ¡release ¡of ¡codebase ¡

Not ¡connected ¡to ¡Internet, ¡ ¡ no ¡name ¡resolu6on ¡supported, ¡100sec ¡delay ¡ Connected ¡to ¡Internet ¡ ¡

Initial Connection Establishment Address Handoff Latency

11/10/16 ¡ 11 ¡

Multipath Addr-Up Latency Lines of Code Modified

Protocol ¡ Kernel ¡LOC ¡ User ¡space ¡ LOC ¡ Total ¡LOC ¡ MPTCP ¡ 10,400 ¡ 0 ¡ 10,400 ¡ HIP ¡ 0 ¡ 28,770 ¡ 28,770 ¡ DIME ¡ 600 ¡ 2,400 ¡ 3,000 ¡

Main Takeaways

¡

q Reduces ¡connec6on ¡establishment ¡latency ¡ q Is ¡more ¡responsive ¡to ¡network ¡events ¡ q Throughput ¡very ¡close ¡to ¡theore6cal ¡max. ¡ q Reduces ¡control ¡message ¡overhead ¡ ¡ q AND ¡implemented ¡with ¡a ¡smaller ¡codebase! ¡

11/10/16 ¡ 12 ¡

Implications and Future Work

q DIME ¡is ¡the ¡first ¡mobility/mul6-­‑homing ¡system ¡that ¡

is ¡completely ¡seamless ¡for ¡the ¡IP ¡Internet ¡

q DIME ¡significantly ¡outperforms ¡HIP ¡and ¡MPTCP ¡ q Future ¡Work: ¡

– Reliable ¡mul6path ¡transport: ¡flow ¡control ¡& ¡ordering ¡ – Can ¡we ¡op6mize/simplify ¡other ¡protocols ¡this ¡way? ¡ – Comparisons ¡with ¡network-­‑layer ¡work ¡(i.e., ¡MIP) ¡

q Implica6ons: ¡

– Name-­‑based ¡networking ¡is ¡NOT ¡needed ¡to ¡support ¡ mobility ¡and ¡mul6-­‑homing ¡in ¡the ¡Internet ¡ – Why ¡do ¡we ¡need ¡to ¡change ¡the ¡rou6ng ¡infrastructure ¡to ¡ handle ¡mobility, ¡mul6-­‑homing ¡and ¡efficient ¡access ¡to ¡ content ¡and ¡services? ¡