MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future InternetConcept Summary – Oct 2011

Contact: D. Raychaudhuri

WINLAB, Rutgers University

Technology Centre of NJ

671 Route 1, North Brunswick,

NJ 08902, USA

ray@winlab.rutgers.edu

WINLAB

MobilityFirst Project: Collaborating Institutions

(LEAD)

+ Also industrial R&D collaborations with AT&T Labs,Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others

D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson

S. Bannerjee W. LehrZ. Morley Mao

B. Ramamurthy

G. ChenX. Yang, R. RoyChowdhury

A. Venkataramani, J. Kurose, D. Towsley

M. Reiter

Project Funded by the US National Science Foundation (NSF)Under the Future Internet Architecture (FIA) Program, CISE

WINLAB

Vision: Mobility as the key driver for the future Internet

Historic shift from PC’s to mobile computing and embedded devices… ~4 B cell phones vs. ~1B PC’s in 2010 Mobile data growing exponentially – Cisco white

paper predicts 3.6 Exabytes by 2014, significantly exceeding wired Internet traffic

Sensor/IoT/V2V just starting, ~5-10B units by 2020

INTERNET INTERNET

WirelessEdge Network

WirelessEdge Network

INTERNET INTERNET

~1B server/PC’s, ~700M smart phones

~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors

~2010~2020

WirelessEdge Network

WirelessEdge Network

WINLAB

Vision: Protocol Design for the future Mobile/Wireless World

Fundamental change in design goals and assumptions ~10B+ mobile/wireless end-points as “first-class” Internet devices Mobility as the norm for end-points and access networks Wireless access – varying link BW/quality, multiple radios, disconnections Stronger security/trust/robustness requirements due to:

open radio medium need for dynamic trust association for mobile devices/users/data/networks increased privacy concerns (e.g. location tracking) greater potential for network failure

Mobile applications involve location/content/context and energy constraints

Technology has also changed a lot in the ~40 yrs since IP was designed Moore’s law improvements in computing and storage (~5-6 orders-of-

magnitude gain in cost performance since 1970) Edge/core disparity, fast fiber but continuing shortage of radio spectrum

WINLAB

Architecture: MobilityFirst Network Overview

Base Station

Wireless Router

AP

Core Network(flat label routing)

Router

Global Name Resolution Service

Control & Management Plane

Computing BladeBuffer StorageForwarding Engine

MobilityFirstRouter withIntegrated

Computing & Storage

Hop-by-HopTransport

GDTN Routing

Name <-> PKI address mapping

Data blockDataPlane

MF Arch designed to meet emerging mobile/wireless service requirements at scale

Key MF protocol features: Separation of naming & addressing Public-key globally unique identifier

(GUID) and flat network address (NA) Storage-aware (GDTN) routing Multicast, multipath, anycast services Flexible inter-domain boundaries and

aggregation level Early binding/late binding options Hop-by-hop (segmented) transport Support for content & context Strong security and privacy model Separate mgmt & computing layers

Several new protocol components, very distinct from today’s TCP/IP ….

WINLAB

Architecture: MobilityFirst Service Abstractions

MobilityFirst API proposes a new multipoint/multipath/time delivery abstraction that reflects the intrinsic broadcast & multi-homing nature of the wireless medium along with in-network storage

Replaces the communication link abstraction provided by IP …IP Abstraction: Virtual Link

DestDevice

NetworkInterface IP Addr=X

Name=MAC

Send(IP=X, data)

StaticMAC=Xbinding

DynamicGUID – NAbindings

MF Abstraction: Network Objectwith multipath reachability

NA=X1 NA=X2 NA=X3

GUID=YNetworkAttachedObject

Send(GUID=Y, data, options)..options for mpath & time delivery

MF Abstraction: Network Object Group with broadcast reachability

NA=X2

GUID1 GUID2 GUID3GroupGUID = Z

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

Broadcast Medium

WINLAB

Architecture Concepts: Name-Address Separation

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

Architecture Concepts: Global Name Resolution Service for Dynamic Name <-> Address Binding Fast Global Name Resolution a central feature of architecture

GUID <-> network address (NA) mappings

Distributed service, possibly hosted directly on routers Fast updates ~50-100 ms to support dynamic mobility Service can scale to ~10B names via P2P/DHT techniques, Moore’s law

AP

Global Name-Address Resolution

Service

Data Plane

Host GUID

Network – NA2

Network – NA1

NA1

Registrationupdate

Mobile nodetrajectory

Initialregistration

Host Name, Context_ID or Content_ID Network Address

Host GUID

NA2

Decentralixed name servicesHosted by subset of ~100,000+ Gatway routers in network

WINLAB

10 100 1,00020 500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Round Trip Query Latency in milliseconds (log scale)

Cu

mu

lative

Dis

trib

utio

n F

un

ctio

n (

CD

F)

K = 1K = 2K = 3K = 4K = 5

K = 5,95th Percentile

at 91 ms

K = 1, 95th Percentile

at 202 ms

Protocol Design: Direct Hash GNRS Fast GNRS implementation based on DHT between routers

GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID) Results in distributed in-network directory with fast access (~100 ms)

Internet Scale Simulation Results Using DIMES database

WINLAB

Routing protocol should seamlessly support a wide range of usage scenarios, from wired mobile ad hoc DTN Device, content and network mobility Heterogeneous devices and radio access Robustness to varying BW, disconnection Dynamic network formation & flexible boundaries

ConnectivityWired Wireless Mesh / Cellular Mobile Ad-Hoc DTN

4GCore

WiFi

Architecture Concepts: MobilityFirst Routing Design Goals

Expands routing options Store and/or replicate as

feasible routing options Enables “late binding” routing

algorithms Hop-by-hop transport

Large blocks reliably transferred at link layer

Entire block can be stored or cached at each router

Take advantage of cheap storage in the network (storage-aware routing)

~100MB, data in transit

~10GB, in-network storage

~1TB, content caching

Generalized Storage-Aware Routing

• Actively monitor link qualities of network• Router store or forward decision based on:

1. Short and long term link qualities2. Available storage along path3. Connectivity to destination

Architecture Concepts: Exploiting In-Network Storage for Routing

WINLAB

Protocol Design: Storage-Aware Routing (GSTAR)

Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection

Routing algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/short disconnection) to DTN (longer disconnections)

Storage has benefits for wired networks as well..

Storage Router

Low BW cellular link

MobileDevicetrajectory

High BW WiFi link

TemporaryStorage atRouter

Initial Routing Path

Re-routed pathFor delivery

Sample CNF routing result

PDU

WINLAB

Protocol Design: Content Delivery in MobilityFirst

Content delivery handled efficiently by proposed MF architecture “Content objects” identified by unique GUID Multiple instances of content file identified by GNRS via GUID to NA mapping Routing protocol used for “reverse anycast” to nearest content object

Approach differs from NDN/CCN, where content attributes are carried in packet headers

MF uses content GUID naming service & GNRS to keep things general and avoid interpreting content semantics inside network

Content Store #2

Content cache at mobileOperator’s network – NA99

User mobilityContent Store #1(owner)

GUID=13247..99

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

GUID=13247..99

GNRS queryReturns list:NA99,31,22,43

NA22

NA31NA99

NA29

NA43

Data fetch fromNA99

Data fetch fromNA43

GNRS Query

Get (content_GUID)

Get (content_GUID)

WINLAB

Protocol Design: Context Aware Delivery

Context-aware network services supported by MF architecture Dynamic mapping of structured context or content label by global name service Context attributes include location, time, person/group, network state Context naming service provides multicast GUID – mapped to NA by GNRS Similar to mechanism used to handle named content

MobileDevicetrajectory

Context = geo-coordinates & first_responder

Send (context, data)

Context-basedMulticast delivery

ContextGUID

Global Name Resolution service

ba123341x

ContextNamingService

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

WINLAB

Protocol Design: MF Stack Core elements of MF protocol stack

GUID services layer, supported by control protocols for bootstrap & updates GUID to network address mapping (GNRS) for dynamic mapping of GUID Generalized storage-aware routing (GSTAR) with supporting control protocols Reliable hop-by-hop block transfer between routers Management plane protocol with its own routing scheme Multiple TP options and plug-in programmable services at GUID layer

Link Layer A(e.g fiber)

Link Layer B(e.g LTE)

Link Layer C(e.g WiFi)

Link Layer D(e.g Ethernet

RoutingControl

Protocols

GUID-to-Net Address Mapping

E2ETransport Protocol B

E2ETransport Protocol B

MgmtApps

APP-2 APP-n

Hop-by-hop Block Transfer Protocol

ManagementPlane

Protocols(incl. routing)

Storage-Aware Routing (GSTAR)

GUID Service Layer Computing LayerService Plug-ins

GUIDServicesControl

Protocols

Name CertificationService A

E2ETransport Protocol A

APP-1

……..

RoutingApps

WINLAB

Example 1: GUID/Address Routing Scenarios – Dual Homing

The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location …

Dual-homing scenario below allows for multiple NA:PA’s per name

Data Plane

GUID & SID

DATA

Send data file to “Alice’s laptop”

Net 1

Net 7

Current network addresses provided by GNRS;NA1:PA22 ; NA7:PA13

GUID/SIDNA1:PA22; NA7:PA13

DATA

GUIDNA1:PA22; NA7:PA13

DATA

Router bifurcates PDU to NA1 & NA7(no GUID resolution needed)

Dual-homed mobile device

GUIDNetAddr= NA7.PA13

DATA

GUIDNetAddr= NA1.PA22

DATA

Alice’s laptopGUID = xxx

WINLAB

Example 2: GUID/Address Routing Scenarios – Handling Disconnection

Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment

Data Plane

GUID/SID

DATA

GUIDNetAddr= NA1.PA7

DATA

Send data file to “Alice’s laptop”

MobilityTrajectory

DisconnectedRegion

Net 1

Net 7

Current network address provided by GNRS;NA1 – network part; PA9 – port address

GUIDNetAddr= NA1.PA9- Delivery failure

DATA

GUID

DATA

PDU Stored in router- GUID resolution for redirection

GUIDNetAddr= NA7.PA3Successful redelivery after connection

DATA

WINLAB

MobilityFirst Prototyping: Phased Approach

Global Name Resolution Service (GNRS)

Storage Aware Routing

Context-Aware / Late-bind Routing

Context Addressing Stack

Content Addressing Stack

Host/Device Addressing

Stack

Encoding/Certifying Layer

Locator-X Routing (e.g., GUID-based)

Evaluation Platform

Prototyping Status

Simulation/Emulation Emulation/Limited Testbed

StandaloneComponents System Integration

Testbed/‘Live’ Deployment

Deployment ready

WINLAB

OpenFLow Backbones

OpenFlow

WiMAXShadowNet

Internet 2National Lambda Rail

Legend

MobilityFirst Prototyping: GENI Deployment Plan (Phase 3)

Domain-1

Router

Router

Domain-2

Wireless Egde(4G & WiFI)

Wireless Edge (4G & WiFI) Router

Wireless Edge (4G & WiFI)

Domain-3

Router

Router

Router

Mapping onto GENI Infrastructure ProtoGENI nodes, OpenFlow switches, GENI Racks, WiMAX/outdoor ORBIT nodes, DieselNet bus, etc.

Inter-domain mobility

Intra-domain mobility

19

Deployment Target: • Large scale, multi-site • Mobility centric• Realistic, live

Full MF Stackat routers, BS, etc.

Opt-in users

Services

20

Edge networks NA-1, NA-2 connected to global core

Each of NA-1, NA-2 are contained MF routing domains

Each WiMAX BSS and WiFi AP is associated with a MF Router

Node a is multi-homed within a network

Node c is multi-homed across 2 networks

Android Client w/ WiMAX + WiFi

Linux PC/laptop w/ WiMAX + WiFi

WiMAX BSS

WiFi AP

MF Router

Vehicular node w/ WiMAX

Sensor node MF Sensor GW

NA-1

NA-2

a

bc d

e

MobilityFirst Prototype: Multi-Site GENI Demo (GEC12, ~4Q2011)

GENI Core

Campus Network(at Rutgers)

Campus Network(at other GENI site)

WINLAB

Resources

Project website: http://mobilityfirst.rutgers.edu

GENI website: www.geni.net

“Emerging Wireless Technologies and the Future Mobile Internet”, Cambridge Press, 2011 – D. Raychaudhuri & M. Gerla (eds.)