MobilityFirst: A Robust and

Trustworthy Mobility-Centric

Architecture for the Future Internet

NIKSUN WWSMC

July 26, 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)

Architecture Summary

WINLAB

MobilityFirst 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 Internet-connected PC’s in 2010

Mobile data growing exponentially – Cisco white paper predicts >1exabyte

per month (surpassing wired PC traffic) by 2012

Sensor deployment 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

Wireless

Edge

Network

WINLAB

MobilityFirst : High-Level Design Goals

Mobility-centric design Migration of 10B network-attached objects (devices, content, users, …)

Robustness in presence of channel impairments & disconnections

Support for network mobility & dynamic network-of-networks formation

Socket API’s designed explicitly for mobility use cases: multicast, anycast,

context- or location-aware delivery, etc. (…service innovation at the edge)

Strong security and privacy Standard security services (authentication, secrecy, confidentiality, non-

repudiation, ..) built into architecture

Resistance to common IP network attacks, e.g. address hijacking, DDoS, ..

Network protocols designed to be resilient against failures/attacks

No single root of trust, flexible trust domains/mechanisms

No per-flow state, low control overhead No signaling, reduced end-to-end chatter (back to packet switching basics..)

WINLAB

MobilityFirst: Protocol Highlights

Separation of naming and addressing Clear distinction between identify of network-attached endpoint and net addr

Name (GUID) = “self-certifying” public key; address = flat NA

Multiplicity of name assignment and trust management services – encourages specialization & competition High-level services for managing content, context, network trust, etc

Fast global name resolution service (GNRS) Integral part of network protocol, resolves GUID NA in ~100 ms

Hybrid GUID/NA routing with self-defining packets NA routing for fast path; late binding GUID routing for advanced services

Multicast/anycast as the norm with unicast as special case

In-network storage and computing options at routers Seamless integration of switching, storage and DTN modes

Hop-by-hop (or segment-by-segment) transport vs. end-to-end TCP

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

Fast Global Name Resolution a central feature of architecture GUID <-> network address & port number (also called “locator”) 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

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

Architecture Concepts: 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/disconnected)

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

Architecture Concepts: 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 1Data

Frag 2Data

Frag n……

Hop-by-Hop

Transport

More details of

TP layer fragments

with addl mux header

WINLAB

Architecture Concepts: 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 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: 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 xy17519bbdGID/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

DATA

Send data file to “Alice’s laptop”

Net

1

Net 7

Current network addresses provided by GNRS;

NA1:PA22 ; NA7:PA13

GUIDNA1: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 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

DATA

GUIDNetAddr= 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

GUIDNetAddr= NA1.PA9

- Delivery failure

DATA

GUID

DAT

A

PDU Stored in router

- GUID resolution for redirection

GUIDNetAddr= 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

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, etcGUID = 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

StandaloneComponents

Cross Layer Integration

Testbed/‘Live’ Deployment

Deployment ready

GENI Spiral 1 connectivity (figure courtesy of GPO at BBN Technologies)

Wisconsin

UMass

Rutgers

Duke

To GENI/I2

Backbone

Open WiMAX/3G

Base Station

End-user Android mobile

Phones or Linux netbooks

with WiMax and WiFi

Campus

Testbed

OpenFlow

+ Blade Server

Router Platform

Typical campus

Network

MFA Client

Software

MFA Router Software

Campus sites

MobilityFirst Prototyping: Multi-site Exptl

Network using GENI Infrastructure

Multi-site GENI campus networks used for real-world evaluation of MF protocol during final stage of evaluation in year 3

Involves realistic applications and opt-in users with both Linux PC’s or Android mobile devices

MF protocol as a long-running “slice” on GENI network

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

QuaggaOpenFlow switch host

XORP

User-Level Control Plane

ClickLinux routing

Commodity Hardware

Forwarding Engine

NetFPGA

23

MF Name Resolution

MF Routing & Mgmt.

Portable user-level implementationMF App Services

WINLAB

OpenFLow Backbones

OpenFlow

WiMAX

ShadowNet

Internet 2National Lambda Rail

Legend

MobilityFirst Evaluation: 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

24

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

Full MF Stack

at routers, BS, etc.

Opt-in users

Services

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