MobilityFirst Project UpdateFIA PI Meeting, March 18-19, 2013Part-II – Protocol Details, Use Cases & Prototyping

D. Raychaudhuri & Arun VenkataramaniWINLAB, Rutgers University CS Dept, Umass - Amherst

ray@winlab.rutgers.edu arun@cs.umass.edu

MobilityFirst Protocol

WINLAB

MobilityFirst Protocol: Feature Summary

Routers with IntegratedStorage & ComputingHeterogeneous

Wireless AccessEnd-Point mobilitywith multi-homing In-network

content cache

Network Mobility &Disconnected Mode

Hop-by-hopfile transport

Edge-awareInter-domainrouting

Named devices, content,and context

11001101011100100…0011Public Key BasedGlobal Identifier (GUID)

Storage-awareIntra-domain

routing

Service API withunicast, multi-homing,mcast, anycast, content query, etc.

Strong authentication, privacy

Ad-hoc p2pmode

Human-readablename

Connectionless Packet Switched Networkwith hybrid name/address routing

MobilityFirst Protocol Design Goals:- 10B+ mobile/wireless devices- Mobility as a basic service- BW variation & disconnection tolerance- Ad-hoc edge networks & network mobility- Multihoming, multipath, multicast- Content & context-aware services- Strong security/trust and privacy model

WINLAB

MobilityFirst Protocol: Technology Solution

Global NameResolution Service

(GNRS)

Hybrid GUID/NAGlobal Routing

(Edge-aware, mobile,Late binding, etc.)

Storage-Aware& DTN Routing

(GSTAR)in Edge Networks

OptionalCompute Layer

Plug-Ins(cache, privacy, etc.)

Hop-by-HopTransport

(w/bypass option)

Name-BasedServices

(mobility, mcast, content, context,

M2M)

Name CertificationService (NCS)

Meta-levelNetwork Services

Core TransportServices

Pure connectionless packet switching with in-network storage

Flexible name-based network service layer

WINLAB

MobilityFirst Protocol: The Protocol Stack

IP

Hop-by-Hop Block Transfer

Link Layer 1(802.11)

Link Layer 2(LTE)

Link Layer 3(Ethernet)

Link Layer 4(SONET)

Link Layer 5(etc.)

GSTAR Routing MF Inter-Domain

E2E TP1 E2E TP2 E2E TP3 E2E TP4

App 1 App 2 App 3 App 4

GUID Service Layer Narrow WaistGNRS

MF RoutingControl Protocol

NCSNameCertification& AssignmentService

Global NameResolutionService

Data PlaneControl Plane

Socket API

SwitchingOption

Optional ComputeLayer

Plug-In A

WINLAB

MF Protocol: Name-Address Separation GUIDs

Separation of names (ID) from network addresses (NA)

Globally unique name (GUID) for network attached objects User name, device ID, content, context,

AS name, and so on Multiple domain-specific naming

services Global Name Resolution Service

for GUID NA mappings Hybrid GUID/NA approach

Both name/address headers in PDU “Fast path” when NA is available GUID resolution, late binding option

Globally Unique Flat Identifier (GUID)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host NamingService

Network

SensorNamingService

ContentNamingService

Global Name Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB

WINLAB

MF Protocol: Hybrid GUID/NA Storage Router in MobilityFirst

GUID-Address Mapping – virtual DHT table

NA Forwarding Table – stored physically at router

GUID NA11001..11 NA99,32

Dest NA Port #, Next HopNA99 Port 5, NA11

GUID –based forwarding(slow path)

Network Address Based Forwarding(fast path)

RouterStorage

Store when:- Poor short-term path quality- Delivery failure, no NA entry- GNRS query failure- etc.

NA32 Port 7, NA51

DATA

SIDGUID=11001…11 NA99,NA32

NA62 Port 5, NA11

To NA11

To NA51

Look up GUID-NA table when: - no NAs in pkt header - encapsulated GUID - delivery failure or expired NA entry

Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry

DATA

DATA

Hybrid name-address based routing in MobilityFirst requires a new router design with in-network storage and two lookup tables:

“Virtual DHT” table for GUID-to-NA lookup as needed Conventional NA-to-port # forwarding table for “fast path” Also, enhanced routing algorithm for store/forward decisions

WINLAB

MF Protocol: Service Abstractions (1) MobilityFirst offers a named-object service API that supports

mobility, disconnection, multi-homing, multicast in a natural way Replaces the point-to-point virtual link abstraction of IP … Example: Sending to a mobile device with multiple interfaces

IP Abstraction: Virtual Link

DestDevice

NetworkInterface IP Addr=X

Name=MAC

Send(IP=X, data)

StaticMAC=Xbinding

DynamicGUID – NAbindings

MF Abstraction: Multi-homed Network Object

NA=X1 NA=X2 NA=X3

GUID=Y NetworkAttachedObject

Send(GUID=Y, data, options)..options for multi-homing & late binding

e.g., Y may be a mobile device with 3 interfaces (WiFi & 2 cellular)

WINLAB

MF Protocol: Service Abstractions (2) Use of MF Service API for content retrieval and dynamic group

multicast (..membership may be specified by context)

MF Abstraction: Get Replicated Content Object

NA=X1 NA=X2 NA=X3

Content ObjectWith GUID=A

Get (Content_GUID=A, options)..option for shortest path

e.g., A is a replicated content object at multiple network locationse.g., Z may be a context group of M2M devices or a cloud service

GUID=A GUID=A

MF Abstraction: Send to Group Object with Multicast reachability

NA=X2

GUID1 GUID2 GUID3GroupGUID = Z

Send (GUID=Z, data, options)..option for mcast delivery

Broadcast Medium

WINLAB

MobilityFirst Protocol Stack: GUID addressing GUID-based addressing available at host, service/application,

socket, and file level GUIDs can also address groups of entities

Port-less addressing of application end-points Each application end-point can have a separate GUID No port contention, and no assumed well-known ports for services

GUID aggregation and Service Directories Applications may choose to use host-GUID with a demux – appID Demux identifiers advertised at local directory services

APP-1 APP-2 APP-3 APP-4

GUID-4GUID-3GUID-2GUID-1

Host

GUID-0

APP-1 APP-2 APP-3 APP-4

appID-4appID-3appID-2appID-1

Host

GUID-0

Transport Layer Directory Service

Port-less, 1 GUID per endpoint GUID Aggregation and Service Directory

WINLAB

MobilityFirst Protocol Stack: Service API MobilityFirst API (or “socket” interface) provides a new set of

services corresponding to the MF protocol stack’s capabilities

Key features are: GUID as the unique identifier right up to application level (no need for port #) Service identifier choice including: basic unicast/mcast, anycast, dual-homing,

late binding mobile delivery, delayed delivery, content query, context delivery, plug-in computing service, etc. (others TBD)

Unicast vs multicast determined Lightweight transport protocol choices for end-to-end reliability and flow control Socket interface examples:

Open(URL, myGUID, TP=A, TP_options) - identity specification and stack customization

Send(GUID=X, SvcFlags/SID=anycast, data, len) Send(GUID=X, SvcFlags/SID=unicast, TP=B, data, len) Send(GUID=X, SvcFlags/SID=late binding, options, data) Send(GUID=X, SvcFlags/SID=anycast+, data) Recv(data_buffer, len, GUID_allow={X, Y, X}) Get(GUID=X, SvcFlags/SID=anycast+content query, options, data_buffer, len) ….

WINLAB

MobilityFirst Protocol Stack: Network Service API

open (profile-URL, src-GUID, [profile-options]) A profile declares the customization of the stack such as choice of transport and

security features for the duration of a session. Profile option parameterize a profile

Optional source GUID identifies the initiating end-point and results in an update of attachment point to the GNRS.

send (message, dst-GUID, [service-option]) GUID based endpoint addressing Options include: MULTICAST, ANYCAST, GET (content), CACHE (a directive to

allow content caching), MULTI-PATH, MULTI-HOME, DTN (delay-tolerant), REALTIME (with delay constraints), COMPUTE (with GUID of compute service) …

recv (buffer, [GUID-set]) Intentional data receipt - GUID-set defined white list Synchronous and asynchronous implementations

get (content-GUID, buffer, [service-options]) Content-centric apps: native network support for direct (GUID-based) content

discovery and retrieval of content ANYCAST service: retrieval attempted from the closest among replicas listed in

GNRS

WINLAB

MobilityFirst Protocol Stack: Network Service API (Contd.)

attach (GUID-set) Publishes network reachability for the specified GUID(s) GUID services layer initiates an association request for each GUID Network cooperation (co-sign) to publish attachment point locator to GNRS Periodic association exchanged keeps locator bindings ‘fresh’ at GNRS

close () Terminates a session by clearing stack state and performing a clean

disassociation from network Locator bindings from GNRS can be removed or allowed to expire

Wireless/Mobile Use Case

WINLAB

Wireless/Mobile Use Case MobilityFirst enables a stitched-together architecture for

mobile networks Current Mobile Networks

Wi-Fi ISP 1

ISP 2

ISP 3

GSM/CDMA/LTE

Internet

Global Name Resolution

ServiceMobility Support

Through GNRS

Wireless Cooperation through Geographic Routing

AAA Server

Mobility Management Entity (MME)

GSM/CDMA/LTE

Internet

Control Path Elements

Data Path Elements

Gateway Node

Make-before-break Handover Controlled QoS inside network

• Planned Deployment• Licensed Spectrum• Fine-grained Managed QoS• Centralized Mobility Support• Homogeneous Topology• Network-wide Authentication

MF Network-of-Networks• Ad-hoc Deployment• Unlicensed Spectrum• Coarse-grained Managed• In-network Mobility Support• Heterogeneous topology• Authentication at APs

WINLAB

Wireless/Mobile Use Case: Service Capability Examples

MF provides several useful capabilities for mobile networks, e.g. mobility, multi-homing, multi-network access, late binding, multicast, ..

INTERNET

Wireless Access Net #1

WirelessAccess NetworkWireless

Access Net #3

WirelessEdge Network

BS-1

BS-2

BS-3

AP1

(3) Mobile device with Multi-network access

MultiplePotentialPaths

(2) Mobile device with dual-homing

(1) Mobile Device with Seamless Service

INTERNET

WirelessAccess Net #3

WirelessAccess Network #2

LTE BS

WiFiAP

Mobile deviceWith dual-radio NICs

BS1

INTERNET

WirelessAccess Net #3

WirelessAccess Network #2

BS2 User/DeviceMobility

WINLAB

Protocol Example: Mobility Service via Name Resolution at Device End-Points

MobilityFirst Network(Data Plane)

GNRS

Register “John Smith22’s devices” with NCS

GUID lookupfrom directory

GUID assigned

GUID = 11011..011

Represents networkobject with 2 devices

Send (GUID = 11011..011, SID=01, data)

Send (GUID = 11011..011, SID=01, NA99, NA32, data)

GUID <-> NA lookup

NA99

NA32

GNRS update(after link-layer association)

DATA

SIDNAs

Packet sent out by host

GNRS query

GUID

Service API capabilities: - send (GUID, options, data)Options = anycast, mcast, time, .. - get (content_GUID, options)Options = nearest, all, ..

Name CertificationServices (NCS)

WINLAB

Protocol Example: Dual Homing Service via Named-Object / GNRS

Data Plane

Send data file to “John Smith22’s laptop”, SID= 129 (multihoming – all interfaces)

NA99

NA32

Router bifurcates PDU to NA99 & NA32(no GUID resolution needed)

GUIDNetAddr= NA32

DATA

GUID NetAddr= NA99

DATA

DATA

GUID SID

DATA

SIDGUID=11001…11 NA99,NA32

DATA

Multihoming service example

WINLAB

Protocol Example: Handling Disconnection via Late Binding

Data Plane

Send data file to “John Smith22’s laptop”, SID= 11 (unicast, mobile delivery)

NA99

NA75

Delivery failure at NA99 due to device mobilityRouter stores & periodically checks GNRS bindingDeliver to new network NA75 when GNRS updates

GUIDNA75

DATA

GUID NA99 rebind to NA75

DATA

DATA

GUID SID

DATA

SIDGUIDNA99

Devicemobility

Disconnectioninterval

Store-and-forward mobility service example

WINLAB

Sample Results: MF vs TCP/IP for WiFi Roaming

Quantifying the benefits of in-network mobility management & storage aware routing

0 50 100 150 2000

20

40

60

80

100

Time (sec)

Tota

l Dat

a R

ecei

ved

(MB

ytes

) Speed = 30 miles/hr

0 50 100 150 2000

20

40

60

80

100

Time (sec)

Speed = 50 miles/hr

0 50 100 150 2000

20

40

60

80

100

Time (sec)

Speed = 70 miles/hr

MobilityFirstTCP/IP

• NS3 Simulation with full 802.11 stack, different vehicular speeds & offered load

• Comparing TCP/IP with MF

Transmission of stored packets Throughput Jumps

WINLAB

Sample Results: MF vs. TCP/IP for LTE/WiFi Switching

MF provides several benefits in a heterogeneous wireless environment: Mobility Mgmt. is not specific to each network Automatic storage of packets in transition Simultaneous use of multiple networks

0 20 40 60 80 100 1200

100

200

300

400

500

600

700

800

900

1000

Time (sec)

Agg

rega

te T

hrou

ghpu

t (M

Byt

es)

Aggregate Throughput with Time

MobilityFirstTCP/IP

Throughput boost due to transmission of stored packets

TCP takes more time to re-start session (DHCP + Application reset)

Content & Context/M2M Use Cases

[22]

WINLAB

Content Delivery Use Case: Content Retrieval via GUID Name

Content Owner’sServer

In-network cache

Get (“content_GUID”)Send(“content_GUID”, dest_GUID)

In-network cache

Alternative pathsfor retrieval or delivery

Network support for content addressability and caching service primitives such as get(content-ID, ..)

Optional computing layer plug-in for enhanced services

GUID=12379…78

GUID=12379…78

GUID=12379…78

Content Cache

Content Cache

NA94

NA22

GNRS query with CGUID returns NA94, NA22

WINLAB

Content Delivery Use Case: Enhanced CDN Service

Content cache at mobileOperator’s network – NA99

User mobility

Content Owner’sServer

GUID=13247..99

GUID=13247..99GUID=13247..99

GUID=13247..99

GNRS queryReturns list:NA99,31,22,43

NA22

NA31

NA99

NA29

NA43

Data fetch fromNA99

Data fetch fromNA43

GNRS Query

Get (content_GUID,SID=128 - cache service)

Get (content_GUID)

Enhanced service example – content delivery with in-network caching & transcoding

MF Compute Layerwith Content Cache

Service plug-in

Query

SID=128 (enhanced service)GUID=13247..99

Filter onSID=128

Mobile’s GUIDContent file

WINLAB

Context-aware delivery often associated with M2M services Examples of context are group membership, location, network state, … Requires framework for defining and addressing context (e.g. “taxis in New

Brunswick”) Anycast and multicast services for message delivery to dynamic group

MobileDevicetrajectory

Context = geo-coordinates & taxi group

Send (context, data)

Context-basedMulticast delivery

ContextGUID

Global Name Resolution service

ba123341x

ContextNamingService

NA1:P7, NA1:P9, NA2,P21, ..

M2M Use Case: Supporting Context-Aware Services

WINLABMarch 11, 2013 MobilityFirst Review Meeting

M2M Use Case: Protocol Example M2M: S1 data is picked up by Mobile GW and sent to MF for A1 that subscribes it Context: T1, conf@WINLAB, is subscribed by P1 …P4;A2 sends a file to T1 reaches

P1..P4 via MF M2M/Context server updates MF-GNRS for mappings: S1 A1 and T1 P1…P4

GNRS: Global Name Resolution Service

Internet (MobilityFirst

)

Sensor S1(temperature

)

M2M / Context (Naming)Server, GUIDAssign & Publish(S1, S2, C1, T1)

S1 -> A1C1 -> NA1

Sensor S2(location)

Actuator C1(air

conditioning)

Application A1

SmartGrid App

Application A2

Presentation

Context T1Conf @WINLAB

Subscriber P1 P2P3

Lookup Context T1Lookup S2, T1 & Subscribe T1

UPDATE

S2T1, T1P1..P4P1 -> NA2, P2->NA2P3 -> NA2, P4->NA3

NA1

NA4

NA2

NA3

GNRSEntries:

UPDATE

A1 -> NA4

DATA

M2MGateWay

Lookup S1

Lookup S1, C1, subscribe S1

P4DATA

Mobility First Prototyping & Deployment Status

[27]

WINLAB

MF Software Router and Host Protocol Stack

28

Click-based MF Router

- Storage-aware routing (GSTAR)- Name resolution server (GNRS)- Reliable hop-by-hop link transport (Hop)

Android/Linux MF Protocol Stack

- Network API- Hop - Dual homing (WiFi/WiMAX)

WiMAX BTS

WiFi AP

Native, user-level implementation on Android runtime

MF Router

MF Router

MF Router

WINLAB

MF Android Mobile Client

JAVA (Android) and C (Linux) API prototype

Usable with ARM based Android devices

Multihoming capabilities for WiMAX enabled devices

Distributed as a system library and jar library for easiness of deployment in Android SDK based applications

App 2App 1 App ...

MF JAVA Client API

E2E Transport Protocol A

E2E Transport Protocol B

GUID Service Layer

Storage-Aware Routing (GSTAR)

Hop-by-Hop Block Transport Protocol

Link Layer A (e.g. WIFI)

Link Layer B(e.g. WIMAX)

WINLAB

MF GNRS Implementation Two alternate designs:

network-level one-hop map service; co-located with routing (Dmap) Locality-aware, cloud-hosted service (Auspice)

Three alternate evaluation platforms:

Network Emulation

3. Commercial cloud platform

1. GENI Wide Area Deployment

2. ORBIT lab with net. emulation

WINLAB

MF Click Software Router

31

Inter-Domain (EIR)

Multicast

Lightweight, scalable multicast• GNRS for maintenance of

multicast memberships• Heuristic approaches to

reduce network load, limit duplicated buffering, and improve aggregate delivery delays

• Click prototype, with SID for multicast flows

• Evaluating hail a cab application as a example multipoint delivery scenario

32WINLAB

OpenFlow/SDN Implementation of MF

MF Protocol Stack

Protocol stack embedded within controller Label switching, NA or GUID-based routing (incl. GNRS lookup) Controllers interact with other controllers and network support

services such as GNRS Flow rule is set up for the remaining packets in the chunk based on

Hop ID (which is inserted as a VLAN tag in all packets)E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101 => OUT PORT = 16

33WINLAB

MF Prototype Deployment on GENI(GEC-12 Recap)Physical Topology MF Routers at 7 campuses across

US on ProtoGENI hosts Layer2 links: Internet2 & NLR

backbones, OpenFlow switches Edge networks: WiFi and WiMAX

access at BBN & Rutgers

I 2 Atlanta

I 2 Houston

I 2 Los Angeles

I 2 Washington

I 2 New York

I 2 OF SwitchVLAN 3715

NLR OF Switch

VLAN 3716

NLRChicago

NLRDenver

NLRSeattle

NLRSUNW

Edge OF Switch

Wisconsin

Clemson

Georgia Tech.

Rutgers

BBN

I ndiana

Washington

Stanford

WiMAX BTSWiMAX BTS

WiFi AP

WiFi AP

Rutgers Wireless EdgeBBN Wireless Edge

Content Publisher

Content Subscriber

GUID & SID

DATA

DATA

DATA

DATA

DATA

DATA

NA

DATA

ProtoGENI Backbone

Robust Content Delivery • Dual-homed mobile subscriber with WiFi + WiMAX• Adapt to disconnection and variable link quality (GSTAR)• Dual-homed delivery

WINLAB

MF Multi-Site Deployment (GEC-16)

Salt Lake, UT

Cambridge, MA

N. Brunswick, NJ

Ann Arbor, MIMadison, WI

Tokyo, Japan

Lincoln, NE

Los Angeles, CA Clemson,

SC

Long-term (non-GENI)

MobilityFirst Access Net

Short-term

Wide Area ProtoGENI

Palo Alto, CA

ProtoGENI

MobilityFirst Routing and Name Resolution Service Sites

I2

NLR

Atlanta, GA

WINLAB

MF/GENI Connectivity: VLAN Stitching

Salt Lake, UT

Cambridge, MA

New Brunswick, NJ

Ann Arbor, MIMadison, WI

Tokyo, Japan

Lincoln, NE

Los Angeles, CA

Atlanta, GAClemson, SC

Long-term (non-GENI)

MobilityFirst Access Net

Short-term

Wide Area ProtoGENI

VLAN Y

ProtoGENI

Wide Area ProtoGENI nodes connect on VLAN 3716 at: Internet2 PoP ORNLR PoP

VLAN 912

MobilityFirst Routing and Name Resolution Service Sites

Palo Alto, CAVLAN 192

VLAN

3134/3135VLA

N 1750

WINLAB

MF/GENI Setup: Emulated Topology

Salt Lake, UT

Cambridge, MA

New Brunswick, NJ

Ann Arbor, MIMadison, WI

Tokyo, Japan

Lincoln, NE

Los Angeles, CA

Atlanta, GAClemson, SC

Long-term (non-GENI)

MobilityFirst Access Net

Short-term

Wide Area ProtoGENI

ProtoGENI

MobilityFirst Routing and Name Resolution Service Sites

Palo Alto, CA