MobilityFirst: A Robust and

Trustworthy Mobility-Centric

Architecture for the Future Internet

PIMRC Keynote, Sept 13, 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. Lehr Z. Morley Mao

B. Ramamurthy

G. Chen X. 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

Introduction

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 Wireless

Edge

Network

INTERNET

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

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

~2010 ~2020

Wireles

s

Edge

Networ

k

WINLAB

INTERNET

Vision: Near-term “mobile Internet” usage

scenario – cellular convergence

~4-5B new cellular devices in just a few years will drive convergence of technical standards and business models

Currently involves 2 sets of addresses (cellular number & IP), 2 sets of protocols (3GPP and IP), and protocol gateways (GGSN, PDN GW, etc.)

Scalability, performance and security problems when bridging 2 networks

Cross-layer interaction between PHY/MAC and TCP/IP impacts performance

Lack of a single unified standard inhibits mobile Internet app development across diverse networks and platforms

Cellular –Internet

GW

Cellular –Internet

GW

MOBILE

INTERNET

Cellular system A

Cellular system B

Radio Access Net A

Radio Access

B

Radio Access

C

Mobility, Security

Varying Access bW

Heterogeneous radio

WINLAB

Vision: Near-term “mobile Internet” usage

scenario – Mobile P2P and Infostations

P2P and Infostations (DTN-like) modes for content delivery

becoming mainstream

Heterogeneous access; network may be disconnected at times

Both terminal & network mobility; dynamic trust identity vs. address

Requires content caching and opportunistic data delivery

Mobile DTN Router

Roadway Sensors

Mobile DTN User/Router

Ad-Hoc

Network

Opportunistic

High-Speed Link

(MB/s)

Mobile P2P User

Infostations

Router

MOBILE INTERNET

Disconnection

Opportunistic access

Message ferry/DTN

Content delivery/cache

WINLAB

Vision: Future “mobile Internet” usage

scenarios – vehicular networks

100’s of million cars will be equipped with radios by ~2015

Both V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) modes

Involves capabilities such as location services, georouting, ad hoc networks

Important new trust (security and privacy) requirements in this scenario

Irrelevant vehicles

in radio range for few seconds

Passing vehicle,

in radio range for seconds

Following vehicle,

in radio range for

minutes

V2I

V2V

Geographic routing/multicast

Dynamic network formation, trust

Location & context services

WINLAB

Vision: Emerging “mobile Internet” usage

scenarios – pervasive/M2M/IoT

The next generation of Internet applications will involve

interfacing human beings with the physical world

Wide range of usage scenarios including healthcare, smart grids, etc.

Networking requires awareness of location, content and context

Challenges – content/context services, security and robustness

“Cloud computing” models with in-network processing & storage

Vehicles with

Sensors & Wireless

Healthcare

Application

Robotics Application

Network Connectivity

& Computation

“Human in the Loop”

To Actuators

Virtualized physical

world object

Content & Location

Aware Routers

Computation

& Storage Protocol

module

Ambient interfaces

Global Pervasive Network

(Future Internet)

Data

From

Sensors

Smart Grids

“Cloud” Applications

Context- and content-services

In-network computing options

“cloud” computing models

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

Vision: Protocol Design for the future

Mobile/Wireless World (cont.)

MobilityFirst is a clean-slate architecture that directly addresses these requirements while taking into account technology constraints and Moore’s Law advances

Proposed network design highlights include: Separation of names & addresses for identity management (…no single root of trust)

Global directory service for dynamic binding of identity with net address

PKI names with unified framework for mobile devices, networks, content, context, ..

Generalized delay tolerant network (GDTN) routing for efficiency and robustness in the

presence of disconnection and access BW variation

In-network storage and hop-by-hop transport of large data units

Inter-network routing with enhanced flexibility and path choice

Multicast, multipath, anycast as basic routing capabilities

Content- and context-aware network services

Optional computing layer for specialized services such as privacy or caching

Clean-slate architecture is a research methodology to identify useful

protocol innovations – in practice, changes to network will be evolutionary

Architecture Summary

WINLAB

Architecture: MobilityFirst Network Overview

Base Station

Wireless Router

AP

Core Network

(flat label routing)

Router

Global Name Resolution Service

Control & Management Plane

Computing Blade

Buffer Storage

Forwarding Engine

MobilityFirst

Router with

Integrated

Computing & Storage

Hop-by-Hop

Transport

GDTN Routing

Name <-> PKI address mapping

Data block Data

Plane

MobilityFirst key 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 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

Naming

Service

Network

Sensor

Naming

Service

Content

Naming

Service

Global Name Resolution Service

Network address

Net1.local_ID

Net2.local_ID

Context

Naming

Service

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

Registration

update

Mobile node

trajectory

Initial

registration

Host Name, Context_ID or Content_ID Network Address

Host GUID

NA2

Decentralixed name services

Hosted 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)

Cum

ulat

ive

Dis

tribu

tion

Func

tion

(CD

F)

K = 1

K = 2

K = 3

K = 4

K = 5

K = 5,

95th

Percentileat 91 ms

K = 1,

95th

Percentileat 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

Connectivity Wired Wireless Mesh / Cellular Mobile Ad-Hoc DTN

4G Core

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 qualities

2. Available storage along path

3. 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

Mobile

Device

trajectory

High BW

WiFi link

Temporary

Storage at

Router

Initial Routing Path

Re-routed path

For delivery

Sample CNF routing result

PDU

WINLAB

Protocol Design: Segmented Transport

Segment-by-segment transport between routers with storage,

in contrast to end-to-end TCP used today

Unit of transport (PDU) is a content file or max size fragment

Hop TP provides improved throughput for time-varying

wireless links, and also helps deal with disconnections

Also supports content caching, location services, etc.

Storage

Router

Low BW

cellular link

Segmented (Hop-by-Hop TP)

Optical

Router

(no storage)

PDU

Hop #1 Hop #2

Hop #3

Hop #4

Temporarily

Stored PDU

BS

GID/Service Hdr

Mux Hdr

Net Address Hdr

Data

Frag 1

Data

Frag 2

Data

Frag n

……

Hop-by-Hop

Transport

More details of

TP layer fragments

with addl mux header

WINLAB

Architecture Concepts: MobilityFirst

Interdomain Routing

Requirements include: flexible network boundaries, dynamic

formation, virtual nets, network mobility, DTN mode, support for

path selection, multipath, multi-homing, improved security, etc.

Motivates rethinking of today’s 2-tier IP/BGP architecture (inter-

AS, intranet)

MobilityFirst interdomain approach uses GNRS service +

enhanced path vector routing to achieve design goals – still

evaluating multiple design options….

Core Net 17

Core Net 23

Access Net 200

Access Net 500

Mobile

Net 1

Path Vector+

Routing protocol

Provides reachability

& path info between

networks

GNRS provides

Net name <-> addr

mapping

Path Vector+

Routing Plane

Global GNRS

directory Mobile

Net 2

WINLAB

Protocol Design: MobilityFirst Interdomain

Routing

One approach under consideration is to enhance BGP-like

protocols with summary node/link info (“Vnode graph”) Summary knowledge of access net properties (Mbps, % avail, etc.), ingress/egress

points and alternate paths exchanged between networks/AS’s

Network topology information for identifying multiple paths, storage points, etc.

Inspired by “Vnode” concept in “Pathlet” routing (Godfrey, 2008)

Support for multicast, anycast, multihoming and multipath

Transit Network

Edge Network

V21 V22

V23

V72 V73

V71 V74

V11 V12

V13

Aggregated Vnode

properties & path info

Example of dual=homing route

Supported by routing protocol

WINLAB

Protocol Design: Virtual Routing Domains

Virtual network domains can be created by combining Vnodes

and/or networks into logical aggregates Vnodes and networks can form VN’s without having to be physically contiguous –

GNRS provides membership list & trust relationships

Virtual networks share fine-grain intra-domain routing information & expose multiple

ingress and egress points to the inter-domain protocol

Can be used to aggregate disjoint wireless access networks (e.g. “NJfreeWiFi”) or set

up a “mobile cloud service” with improved routing visibility; many other uses ….

Vnode 11

Net A

Vnode 21

Vnode 22

Net B Net C

Virtual Net ABC

Intra-domain

Routing tunnel

Ad Hoc Net

(may be disconnected

at times)

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 mobile

Operator’s network – NA99

User mobility Content Store #1

(owner)

GUID=13247..99

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

GUID=13247..99

GNRS query

Returns list:

NA99,31,22,43

NA22

NA31 NA99

NA29

NA43

Data fetch from

NA99

Data fetch from

NA43

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

Mobile

Device

trajectory

Context = geo-coordinates & first_responder

Send (context, data)

Context-based

Multicast delivery

Context

GUID

Global Name

Resolution service

ba123

341x

Context

Naming

Service

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

WINLAB

Protocol Design: Management Plane

Separate mgmt plane designed into MF architecture Provides visibility into key mobile network aspects such as name

resolution, disconnected operation, wireless access quality, context-

aware services, location, privacy, …

Includes mechanism for network-assisted dynamic spectrum

assignment (DSA) as a basic capability

Intended to improve transparency and support add-on mgmt services

AP

Control & Management

Plane Net Mgmt

Interface

(performance queries,

configuration, faults, security, ..)

Data Plane

Data packets

WINLAB

Protocol Design: Management Plane (cont.)

Support for dynamic spectrum assignment (DSA) Given that the majority of end-user devices are wireless, Internet spectrum

should be assigned on demand

Management plane mechanism for exchange of spectrum use data

AP

Mobility First Control

& Management Plane

Distributed Spectrum Coordination

Algorithm Software (runs on all radio devices)

Aggregate Spectrum

Updates Between Routers

Radio Coverage

Region A

Region B

Region C

Region D

Spectrum Use Update (from Radios)

Spectrum Occupancy Map (from Routers)

Geo-cast Spectrum

Update Service

WINLAB

Protocol Design: Computing Layer

Programmable computing layer provides

service flexibility and evolution/growth path Routers include a virtual computing layer to support new network services

Packets carry service tags and are directed to optional services where applicable

Programming API for service creation provided as integral part of architecture

Computing load can be reasonable with per-file (PDU) operations (vs. per packet)

...... ......

Packet forwarding/routing

Computing layer CPU Storage

Virtual Service Provider

Content Caching

Privacy routing

anony anony

WINLAB

Protocol Design: Packet Headers and

Forwarding with Hybrid GIUD/NetAddr Hybrid scheme in which packet headers contain both the object name (GUID)

and topological address (NA) routing

NA header used for “fast” path, with fallback to GUID resolution where needed

Enables flexibility for multicast, anycast and other late binding services

GUID/Service

Header

GID-Address Mapping

Routing Table

GUID NA

xz1756.. Net 1194

GUID/Service

Header

NA Header

Dest NA Path

Net 123 Net11, net2, ..

GUID –based forwarding

(slow path)

Network Address Based Routing

(fast path)

Name-GID Mapping

Name GUID

server@winlab xy17519bbd GID/Service

Header

NA Header

Data Object

(100B-1GB)

PDU with GUID

Header only

PDU with GUID

and NA headers

GUID/Public Key

Hash

SID

(Service

Identifier)

GUID Header Components

Optional list of NA’s

- Destination NA

- Source route

- Intermediate NA

- Partial source route

WINLAB

Use Cases: 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/SID NA1:PA22; NA7:PA13

DATA

GUID NA1:PA22; NA7:PA13

DATA

Router bifurcates PDU to NA1 & NA7

(no GUID resolution needed)

Dual-homed

mobile device

GUID NetAddr= NA7.PA13

DATA

GUID NetAddr= NA1.PA22

DATA

Alice’s laptop

GUID = xxx

WINLAB

Use Cases: 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

GUID NetAddr= NA1.PA7

DATA

Send data file to “Alice’s laptop”

Mobility

Trajectory

Disconnected

Region

Net

1

Net 7

Current network address provided by GNRS;

NA1 – network part; PA9 – port address

GUID NetAddr= NA1.PA9

- Delivery failure

DATA

GUID

DAT

A

PDU Stored in router

- GUID resolution for redirection

GUID NetAddr= NA7.PA3

Successful redelivery after connection

DATA

WINLAB

Use Cases: GUID/Address Routing

Scenarios – Multicast/Anycast/Geocast

Multicast scenario below also uses GUID <-> Network Address resolution (late-

binding) at a router closer to destination (..GUID tunnel)

GUID/SID

DATA

GUID

= mcast

group

NetAddr= NA1

DATA

Send data file to “WINLAB students”

Late GUID <-> addr

Binding at NA1

Net 1

Net 7

Intermediate network address NA1

provided by GNRS

NetAddr=NA1:PA1,PA2,PA9; NA7,PA22

GUID

DATA NetAddr=NA1,PA1

NetAddr=NA1,PA2

NetAddr=NA7,PA22

Port 1

Port 2

Port 22

WINLAB

Public keys names for hosts & networks; forms basis for Ensuring accountability of traffic

Ubiquitous access-control infrastructure

Secure routing; no address hijacking

Emphasis on achieving robust performance under network

stress or failure Byzantine fault tolerance as a goal

Transform malicious attacks into benign failure

Performance observability (in management plane)

Intentional receipt policies at networks and end-user nodes Every MF node can revert to GUID level to check authenticity, add filters, ..

No globally trusted root for naming or addressing Opens naming to innovation to combat naming-related abuses

Removes obstacles to adoption of secure routing protocols

Security Considerations:

WINLAB

Security Considerations: Trust Model

NET NA1

NET NA7

NET NA33

NA 51 NA 99

NA 14

NA 88

Network

Naming

Service

A

Network

Naming

Service

B

GNRS

Aggregate NA166:

NA14, NA88, NA 33

Host

Naming

Service

X

Content

Naming

Service

Y

Context

Naming

Service

Y

Other

Naming

Services

TBD

Secure InterNetwork

Routing Protocol

Secure

Host

Name

Service

Lookup

Secure

GNRS

Update

Secure

Network

Name

Service

Lookup

Secure

Data Path

Protocol

Name assignment

& certification

services (..can

incorporate

various kinds of

trust including

CA, group

membership,

reputation, etc GUID = public Key

GUID <-> NA

binding

Public Key object and network names enable us to build secure protocols for each interface shown

WINLAB

Privacy Considerations:

Public keys as addresses enable their use as pseudonyms Can be changed frequently by end-users to interfere with profiling

Flat-label PKI addresses provide an additional layer of routing privacy

Openness in naming & addressing introduces competition

on grounds of privacy E.g., enable retrieval of mappings in a privacy-preserving way

Virtual service provider framework can optionally provide

enhanced support for privacy E.g., constant-rate traffic between routers to defeat traffic analysis

Route transparency and selection supports user choice on

privacy grounds

Prototyping & Evaluation

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

Standalone Components

System Integration

Testbed/‘Live’ Deployment

Deployment ready

WINLAB

Multi-radio indoor and outdoor nodes - WiMAX, WiFi, Linux-based Click implementation of routing protocols

MobilityFirst Prototyping: ORBIT Grid &

WiMax Testbeds for Wireless Edge Evaluation

WINLAB

MobilityFirst Prototyping: Software

Router

Linux-based software router with two-level implementation

OpenFlow Controller

Quagga OpenFlow switch host

XORP

User-Level Control Plane

Click Linux routing

Commodity Hardware

Forwarding Engine

NetFPGA

38

MF Name Resolution

MF Routing & Mgmt.

Portable user-level implementation MF App Services

WINLAB

MobilityFirst Prototyping: Android Client

Device: HTC Evo, Android 2.3 Unbranded and rooted

Development: SDK, NDK, flash a modified kernel (if required)

WiFi, WiMAX interfaces

Modules in Android’s MF stack MF-socket API - user level library

Transport layer

Storage aware routing

SHIM layer support for multi-homing

1-Hop reliable data transfer

MF-socket API open, send, send_to, recv, recv_from

User policies for resource use and intentional data receipt

39

WINLAB

OpenFLow Backbones

OpenFlow

WiMAX

ShadowNet

Internet 2 National 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

40

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

Full MF Stack

at routers, BS, etc.

Opt-in users

Services

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

41

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

b c 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.)