MobilityFirst: A Robust and

Trustworthy Mobility-Centric

Architecture for the Future Internet

Summary Slides for FIA Review

September 2012

D. Raychaudhuri

ray@winlab.rutgers.edu

Arun Venkataramani

arun@cs.umass.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. 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

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

Introduction: Mobility as the key driver

of future Internet (cont.)

Mobile Data Traffic Swells 193% You can thank the iPhone for leading the charge

when it comes to a massive deluge of new mobile

Internet traffic.

March 26, 2010

Eric Schmidt: smartphones are the future for

Google and the world The chief executive of the search giant believes

smartphones will empower the poor and is the

equivalent to the arrival of TV

Guardian UK, 28 June, 2010

At AT&T, the No.2 wireless carrier in the United States, after

Verizon Wireless, the use of mobile data surged 5,000 percent

from 2007 through 2009 after the operator became the exclusive

U.S. seller of Apple’s iPhone, which has helped popularize the

mobile Web. But it has also strained AT&T’s wireless network at

peak times in urban areas in New York and California.

April 18, 2010

Getting What You Pay For on the Mobile Internet

Broadband Availability to Expand

The Obama administration is seeking to nearly double the

wireless communications spectrum available for commercial

use over the next 10 years, an effort that could greatly enhance

the ability of consumers to send and receive video and data with

smartphones and other hand-held devices.

June 27, 2010

Cutting the cord on Internet Connection

Research indicates that 56 percent of

users connect to the internet wirelessly.

Jul 23, 2009

Mobile Internet exploding, online ads about to

take off, In the Morgan Stanley analyst’s presentation at the

Conversational Marketing Summit in New York, Meeker said

mobile Internet use is ramping up faster than desktop Internet

use did, with Apple leading the trend with the release of the

iPhone nearly three years ago.

WINLAB

Introduction: Cellular-Internet convergence

Technology disparity today Two sets of addresses (cell number & IP), protocols (3GPP, IP), and protocol

gateways (GGSN)

Inefficient, fragile, difficult to manage

More so with heterogeneous radio access networks

INTERNET

Cellular –Internet gateway

Cellular –Internet gateway

MOBILE

INTERNET

Cellular system A

Cellular system B

Radio Access

Net A

Radio Access

Net B

Radio

Access

Net C

Single unified architecture can simplify and speed up mobile Internet application

development across diverse networks and platforms

WINLAB

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

Introduction: Vehicular Networks

100’s of millions of cars with radios by ~2015 Vehicle-to-vehicle and vehicle-to-infrastructure modes

Support for location services, geo-routing, reliable multicast

Critical new security and privacy requirements

Irrelevant vehicles

in radio range for

few seconds

Passing

vehicle,

in radio range

for seconds

Following

vehicle,

in radio

range for

minutes

V2I

V2V

WINLAB

Introduction: Pervasive Cyber-Physical

Systems/Internet-of-Things (IoT)

Next-generation Internet applications will interface human

beings with the physical world, e.g., First-response, smart grids, crowdsourcing

Location and context-aware embedded computing

Secure and flexible network computing model

Pervasive

Future

Internet

Vehicles with

Sensors & Wireless

Healthcare

Application

Robotics Application

“Human in the Loop”

Virtualized

physical

object

Computation

& Storage Protocol

module

Ambient

interfaces

Sensor

data

Smart Grids

“Cloud” Applications

Network Connectivity

& Computation

Content & Location

Aware Routers Actuators

WINLAB

Introduction: Why new protocols?

Mobility as the norm

Trustworthiness

Technology trends

Static special case of mobile

Varying wireless link quality

Multiple radio technologies

Disconnection tolerance

Dynamic trust association

Increased privacy concerns

Mission critical applications

Denial of service tolerance

Moore’s law aggressive storage/bandwidth tradeoff

Precious spectrum, fast fiber Edge/core disparity

Energy-constrained services Energy first-class resource

High-Level

Architecture Goals

WINLAB

Architecture: Design Goals (1)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content addressability

6. Evolvable network

ISP1 ISP2

ISP3 Virtualized

data center

Host

Mobile network

End-to-end communication must continue (i) despite

frequent mobility of end-hosts or networks; (ii) despite

absence of a contemporaneous end-to-end path

WINLAB

Architecture: Design Goals (2)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content addressability

6. Evolvable network

ICANN

Typosquatting

Frontrunning,

tasting attacks

Botnets,

DNS fluxing

Correct network behavior must not depend on a single root

of trust

WINLAB

Architecture: Design Goals (3)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content addressability

6. Evolvable network

Internet

ISP1

ISP2

Denial-of-service Sender-driven

No receiver

control

Incoming traffic engg.

Context-awareness

An end-host must (only) receive data consistent with its

receipt policy.

WINLAB

Architecture: Design Goals (4)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content addressability

6. Evolvable network

ISP AS 7007

ISP ISP

ISP

ISP

Single faulty router can render (most

of) Internet unavailable.

End-to-end communication must continue despite the

compromise of (a small fraction of) end-hosts or

infrastructural nodes

WINLAB

Architecture: Design Goals (5)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content/context addressability

6. Evolvable network

Internet

The network should assist with content retrieval in

addition to enabling host-to-host communication.

WINLAB

Software

router plug-ins

Architecture: Design Goals (6)

1. Host + network mobility

2. No global root of trust

3. Intentional data receipt

4. Proportional robustness

5. Content addressability

6. Evolvable network

The architecture should allow for the co-existence or

rapid creation of new and different network services.

Service software

repository

Service modules

Virtual Network A

Virtual Network B Software

BS plug-ins

Design Considerations

for Mobile/Wireless

WINLAB

Protocol Design for Mobile/Wireless: BW

Variation & Disconnection The wireless medium has inherent fluctuations in bit-rate (by

as much as 10:1 in 3G/4G access, heterogeneity and disconnection fundamental protocol design challenge

Motivates in-network storage and hop-by-hop transport (solutions such as CNF, DTN, ..)

INTERNET

Wireless

Access Net #3

Wireless

Access

Network #2

BS-1

AP-2

Mobile devices with varying BW due to SNR variation,

Shared media access and heterogeneous technologies

Time Disconnection

internal

Bit

Rate

(Mbps)

Dis-

connect

AP-2

BS-1

WINLAB

Protocol Design for Mobile/Wireless:

Multihoming, Multipath Wired Internet devices typically have a single Ethernet interface

associated with a static network/AS

In contrast, mobile devices typically have ~2-3 radios and can see ~5-10 distinct networks/AS’s at any given location

Basic property - multiple paths to a single destination leads to fundamentally different routing, both intra and inter domain!

INTERNET

Single “virtual link” in wired Internet Wireless

Access Net #1

Wireless

Access Network

Wireless

Access Net #3

Wireless

Edge

Network

INTERNET

Access

Network

(Eithernet)

BS-1

BS-2

BS-3

AP1

Mobile device with multi-path reachability

Dual

Radio

NIC’s

Ethernet

NiC

Multiple

Potential

Paths

WINLAB

Protocol Design for Mobile/Wireless:

Multicast Many mobility services (content, context) involve multicast

The wireless medium is inherently multicast, making it possible to reach multiple end-user devices with a single transmission

Fine-grain packet level multicast desirable at network routers

INTERNET

Session level Multicast Overlay (e.g. PIM-SIM)

Wireless

Access Net #11

INTERNET

Access

Network

(Eithernet)

Radio

Broadcast

Medium

Packet-level Multicast at Routers/AP’s/BSs

RP

Wireless

Access

Net #32

Pkt Mcast at Routers

WINLAB

Access

Network

)

Protocol Design for Mobile/Wireless: Ad Hoc

& Network Mobility Wireless devices can form ad hoc networks with or without

connectivity to the core Internet

These ad hoc networks may also be mobile and may be capable of peering

Requires rethinking of interdomain routing, trust model, etc. Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility

INTERNET

Access

Network

)

WINLAB

Content and context aware message delivery often

associated with mobile services “Anycast” content retrieval from nearest storage location (cache)

Context based message delivery specific by group, area, time, etc.

Service typically involves dynamic binding of content or context to a specific set

of network addresses along with multicast delivery

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

Protocol Design for Mobile/Wireless:

Content & Context

MobilityFirst Protocol

Design

WINLAB

MobilityFirst Design: Architecture Features

Routers with Integrated

Storage & Computing Heterogeneous

Wireless Access

End-Point mobility

with multi-homing In-network

content cache

Network Mobility &

Disconnected Mode

Hop-by-hop

file transport Edge-aware

Inter-domain

routing

Named devices, content,

and context

11001101011100100…0011

Public Key Based

Global Identifier (GUID)

Storage-aware

Intra-domain

routing

Service API with

unicast, multi-homing,

mcast, anycast, content

query, etc.

Strong authentication, privacy

Ad-hoc p2p

mode

Human-readable

name

Connectionless Packet Switched Network

with hybrid name/address routing

WINLAB

MobilityFirst Design: Technology Solution

Global Name

Resolution Service

(GNRS)

Hybrid GUID/NA

Global Routing (Edge-aware, mobile,

Late binding, etc.)

Storage-Aware

& DTN Routing

(GSTAR)

in Edge Networks

Optional

Compute Layer

Plug-Ins (cache, privacy, etc.)

Hop-by-Hop

Transport

(w/bypass option)

Name-Based

Services (mobility, mcast,

content, context,

M2M)

Name Certification

Service (NCS)

Meta-level

Network Services

Core Transport

Services

Pure connectionless packet switching with in-network storage

Flexible name-based network service layer

WINLAB

MobilityFirst Design: 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 Waist GNRS

MF Routing

Control Protocol

NCS Name

Certification

& Assignment

Service

Global Name

Resolution

Service

Data Plane Control Plane

Socket API

Switching

Option

Optional Compute

Layer

Plug-In A

WINLAB

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

Dest

Device

Network

Interface IP Addr=X

Name=

MAC

Send(IP=X, data)

Static

MAC=X

binding

Dynamic

GUID – NA

bindings

MF Abstraction: Network Object

with multipath reachability

NA=X1 NA=X2 NA=X3

GUID=Y Network

Attached

Object

Send(GUID=Y, data, options)

..options for mpath & time delivery

MF Abstraction: Network Object Group with

broadcast reachability

NA=X2

GUID1 GUID2 GUID3 Group

GUID = Z

Send(GUID=Z, data, options)

..option for mcast delivery

Broadcast Medium

WINLAB

Protocol Design: 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

Protocol Design: Protocol Example –

Name Resolution at Device End-Points

MobilityFirst Network

(Data Plane)

GNRS

Register “John Smith22’s devices” with NCS

GUID lookup

from directory

GUID assigned

GUID = 11011..011

Represents network

object 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

SID

NAs

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 Certification

Services (NCS)

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: Realizing the 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

Protocol Design: Routing 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

Protocol Design: 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

Protocol Design: MF Router Operation

GUID-Address Mapping – virtual DHT table

NA Routing Table – stored physically at router

GUID NA

11001..11 NA99,32

Dest NA Next Hop

NA99 NA11

GUID –based forwarding

(slow path)

Network Address Based Forwarding

(fast path)

Router

Storage

Store when:

- Poor short-term path quality

- Delivery failure, no NA entry

- GNRS query failure

- Content cache decision

- etc.

NA32 NA51

DATA

SID GUID=

11001…11 NA99,NA32

NA62 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

Example of Functions at Branching Router for a Multicast Packet to be delivered to NA99 and NA32

WINLAB

Protocol Design: Interdomain Routing

Requirements include: edge awareness, flexible network boundaries,

dynamic AS formation, virtual nets, network mobility, DTN mode, path

selection, multipath, multi-homing, etc.

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

intranet)

MobilityFirst interdomain approach uses GNRS service + enhanced

global routing protocol (path vector, telescopic flooding) 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: Interdomain Routing (cont.)

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 Example: Per-Packet Multicast

Data Plane

Send data file to “John Smith22’s

devices”, SID= 21 (mcast)

NA99

NA32

Router bifurcates PDU to NA99 & NA32

(no GUID resolution needed)

GUID NetAddr= NA32

DATA

GUID NetAddr= NA99

DATA

DATA

GUID SID

DATA

SID GUID=

11001…11 NA99,NA32

DATA

Multicast service example

WINLAB

Protocol Example: Dual Homing Service

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)

GUID NetAddr= NA32

DATA

GUID NetAddr= NA99

DATA

DATA

GUID SID

DATA

SID GUID=

11001…11 NA99,NA32

DATA

Multihoming service example

WINLAB

Protocol Example: Handling Disconnection

Data Plane

Send data file to “John Smith22’s

laptop”, SID= 11 (unicast, mobile

delivery)

NA99

NA75

Delivery failure at NA99 due to device mobility

Router stores & periodically checks GNRS binding

Deliver to new network NA75 when GNRS updates

GUID NA75

DATA

GUID NA99 rebind to NA75

DATA

DATA

GUID SID

DATA

SID GUID

NA99

Device

mobility

Disconnection

interval

Store-and-forward mobility service example

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)

MF Compute Layer

with service plug-ins

MF Compute

MF Compute

Enhanced Service

Provider Interface

Plug-in

Module

Plug-in

Module

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

Optional computing layer to support enhanced services such as

content caching

WINLAB

Protocol Example: Enhanced CDN Service

Content cache at mobile

Operator’s network – NA99

User mobility

Content Owner’s

Server

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,

SID=128 - cache service)

Get (content_GUID)

Enhanced service example – content delivery with in-network storage

MF Compute Layer

with Content Cache

Service plug-in

Query

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

Filter on

SID=128

Mobile’s GUID

Content file

WINLAB

Protocol Design: Context Communication

Paradigms

Communicate messages to an identity rather than an address

- covered by GUID layer

Communicate messages to an identity on conditional context:

- receive only during work hours, unless from a specific identity

- send a message to whomever is in a car's passenger seat

- send a message to a phone but not when in a moving car

Send a message to an event

- all people at the Winlab's teatime

- anyone at a talk posted on the calendar

- anyone who is in the building that isn't in a meeting

WINLAB

Protocol Design: Context Resolution

Service (CRS)

Translation context descriptions into network

destinations, identified by GUIDs at any level of a service

Sensors

Data processor

(context, event, analysis)

Readers

Distributor

Resource Discovery

MobilityFirst

FIAMiddleware

Things’ GUID

Groups

GUID

Context

GUID

CDN

GUID

Resource GUID

M2M

ApplicationsPhysical

objects

Context (CRS) stack Network Stack Clients

WINLAB

Protocol Example: UbiCab Context

Service

• UbiCab scenario: “A passenger calls for a nearby cab”

• UbiCab context service (GUID_c) redirects the call based on context – the relative

locations of caller and callee

• From outside network (overlay) to inside network (on-router caching)

• Low latency, reduced traffic load on Internet and bottleneck on overlay server

MobilityFirst Core Network

Service

Caching

GUID_c

Overlay Server

RDF queries

Service discover

Request, GUID_c

Service Discover,

Request, GUID_c

Service publishing

GUID_c

GUID_c Routing

Drivers

Passensgers

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

Public key GUIDs 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

Protocol Design: Security Considerations

WINLAB

Protocol Design: 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

Protocol Design: Privacy

Public key GUIDs provide a basic level of privacy Semantics of GUID in packet header not known to an observer

But, GUID’s locator/NA can be tracked through repeated queries to GNRS

Solutions such as disposable GUIDs or white-listing in GNRS

Enhanced privacy services possible through plug-ins at

computing layer e.g. optional onion routing for designated SID

Architecture supports a range of privacy policy options – to

be discussed further

MobilityFirst Protocol

Prototyping & Validation

WINLAB

MobilityFirst Prototyping: Phased Strategy

54

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)

Simulation and Emulation Smaller Scale Testbed

Standalone Modules

Distributed Testbed E.g. ‘Live’ on GENI

Deployable s/w pkg., box

Phase 1 Phase 2 Phase 3

Prototype

Evaluation

Integrated MF Protocol Stack and Services

WINLAB

MobilityFirst Prototyping: Click-based

Router Implementation

55

Click Forwarding Engine

Routing Name

Resolution Mgmt.

Service Classifier

Rx Q Tx Q

To/From Host

Host Rx Q Host Tx Q

Content Cache Service

Rsrc Control

User-level Processes

Next-hop Look up

Block Aggregator

Block Segmentor

Forwarding Table

To Next-hop Lookup

Hold buffer

x86 hardware and runtime

Wir

ed a

nd

wir

eles

s i/

f Wired

and

wireless i/f

DMap – DiHT

Locality-Aware DNS

GSTAR

R3

Compute Services

Inter-Domain

PacketCloud Framework

Packet Classifier

Integrate

Early Dev.

WINLAB

MobilityFirst Prototyping: Host Protocol Stack

56

Network API

E2E Transport

GUID Services

Routing

‘Hop’ Link Transport

Interface Manager

WiFi WiMAX

App-1 App-2

Security

‘Socket’ API open send send_to recv recv_from close

Network Layer

User policies

Linux PC/laptop with WiMAX & WiFi

Android device with WiMAX & WiFi

Device: HTC Evo 4G, Android v2.3 (rooted), NDK (C++ dev)

Integrate

Early Dev.

Context API

App-3

Context Services

Sensors

WINLAB

MobilityFirst Prototyping: GENI Deployment

57

OpenFlow Backbones

OpenFlow

WiMAX

ShadowNet

Internet 2

National Lambda Rail

Legend

MobilityFirst Router &

GNRS Servers

Mobile Hosts

Static Hosts

Mapping onto GENI Infrastructure (ProtoGENI nodes, OpenFlow switches, GENI Racks, DieselNET buses, WiMAX/outdoor ORBIT nodes)

Deployment Goals

• Large scale, multi-site • Mobility centric • Realistic, live

WINLAB

MobilityFirst Prototyping: GEC-12 Demo

(Content Delivery), ~11/11

58

WiMAX BTS WiMAX BTS

WiFi AP

WiFi AP

Rutgers Wireless Edge BBN Wireless Edge

I2 path using VLANs 3715, 3745(BBN), 3798 (Clemson)

GUID=1

GUID=2

GUID=3

Bridge

GUID=4

GUID=5

GUID=6

GUID=7

NLR path using VLANs 3716, 3799 (Clemson)

ProtoGENI host running MF Router, GNRS Server

GUID=101

GUID=201

Content Publisher

Content Subscriber

GUID & SID

DATA

NA

DATA

ProtoGENI Backbone

WINLAB

MobilityFirst Prototyping: Hot Mobile 2012 Delivery Services for Multi-Homed Devices with User preference of delivery interface

59

WINLAB

MobilityFirst Prototyping: GEC-13 Demo

(Mobility, Multi-homing), ~3/12

60

WiMAX BTS

WiFi AP pc1@BBN

pg51@Rutgers

Rutgers Wireless Edge

pc11@BBN

pg50@Rutgers pg33@GeorgiaTech

WiMAX coverage

WiFi coverage MobilityFirst Router hosted on Protogeni node

GENI Mesoscale

Mobile, Multi-homed device (WiMAX + WiFi)

Industry Structure &

Business Model

Implications

WINLAB

Industry Structure & Business Models:

Major Interfaces

Host

Naming

Service

Content

Naming

Service

External Global Name Resolution Service A

Context

Naming

Service

External Global Name Resolution Service B

Network

Naming

Service

Sensor

Naming

Service

Edge Network Transit or Core Network

Edge Network Ad Hoc and Vnet

Formation interface

Naming Service

Interface

Name resolution

Interface

Inter-network

GNRS & routing

interface

Name assignment

to GNRS interface

Enhanced Network Service Provider A

Compute Layer

API Enhanced Service

Interface

Client API

(GUID Service

Interface)

Intra-domain

Interface

Between routers

No single point of control in naming

Competing “meta-level

Mobility service providers

API for enhanced services

On top of base MF network

Flat network addresses & no hierarchy requirement

for inter-domain routing

Integration of cellular/mobile network functionality

+ ad hoc and mobile network support

Enhanced routing/SLA interfaces to support

Names, path choice, edge-awareness, …

WINLAB

Industry Structure & Business Models:

(1) Cellular-Internet Convergence

GMSC*

*Gateway Mobile

Switching Center

Mobile Internet

Cellular

Network

VLR

VLR

BSC

BSC

BSC

MSC 1

HLR PSTN

MSC 2

Current Architecture: Mobile Access Network with Internet Gateway Future Architecture : Unified Mobile Internet (all IP, no gateways)

MF provides a uniform

network API for both

Fixed and Mobile Internet

Services

WINLAB

Industry Structure & Business Models :

(2) Mobility as an ISP Service

Mobile User

SLA+ interface

For roaming agreements

Mobility services similar to cellular enabled by MF architecture MF protocol features such as GUID & GNRS provide mobility service

“Virtual AS” concept can be used to create edge network aggregates

Aggregate VAS could be ISP’s or regional free WiFi networks

SLA features to support roaming between networks – agreements not just

with peer networks but likely with regional aggregates

Virtual Network AS-96=AS-9+AS-41

AS-9

AS-41

Regional

Aggregate

Requires protocol support for aggregating non-contiguous AS’s into virtual AS

VN mgmt

interface

AS-208

WINLAB

Industry Structure & Business Models :

(3) Access Network Choice & Multi-homing

Mobile User

Wireless end-point implies a multiplicity of access networks A typical mobile device sees 10+ networks (4-5 cellular, 5-6 WiFi, etc.) in

populated areas

End-user benefit is more BW, reduced cost while operator can improve

coverage and increase traffic capacity via aggressive stat mux

Can be considered as a generalization of peering (you carry my traffic, I

carry yours), with shared radio medium as the “peering point”

Alternatively, competing operators might offer $/MB on-demand pricing

New entrants offering wholesale access capacity to major carriers…?

Access

Net 1

#2 #3

#k

100Kbps

250 Kbps

150 Kbps 500 Kbps

INTERNET

Requires protocol support for multi-homing across network domains

WINLAB

Industry Structure & Business Models :

(4) Ad-Hoc and P2P Service Model Ad-hoc and network mobility supported by MF protocol imply new

business models for P2P and related support services MF protocol supports ad hoc network formation, merging & migration

Network operators may offer DTN delivery, roaming and other services

aimed at this market (e.g. vehicular oriented infrastructure)

Incentives for end-user participation TBD

Ad hoc

networks

Access Provider

w/ DTN service Access Provider

w/ guest services

WINLAB

Industry Structure & Business Models :

(5) Competing Name Certification Service Providers

Multiple NCS service providers for registering human-readable names

and assigning a unique GUID public key Domain-specific services (such as content or M2M) anticipated

Each service may use their own schema for naming

GUID assignment does not require coordination because of the very large

address space ~ 2**1024 (… for 10-100B names, collision prob. 0)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host

Naming

Service

Taxis in NB

M2M

Naming

Service

Content

Naming

Service

Context

Naming

Service

GUID = 110011100101…..001

Networks

Network

Naming

& Trust

Service

…also specialized

Naming & Trust

Management

service for networks

Rutgers

NB Campus

NA = hash(GUID)

WINLAB

Industry Structure & Business Models :

(6) External GNRS Service Provider

Independent GNRS service may provide faster response or additional

data (such as geo-location) relative to in-network GNRS GNRS operator can offer privacy and other value-added features

Enables competition and differentiation in mobility meta-services

External Global Name Resolution Service A

External Global Name Resolution Service B

Location Update &

Name resolution

Interface

Client API

(GUID Service

Interface)

In-Network GNRS

(router DHT etc.)

WINLAB

Industry Structure & Business Models :

(7) Enhanced Network Service Provider

MF Architecture includes a compute layer with support for plug-in

service software modules downloaded by enhanced providers Service customizations such as content caching, delayed delivery or

media transcoding – “cloud services” involving locality or performance

Enables virtual service provider as a layer above network operator

In-network services have inherent value (relative to overlay) which can be

monetized and shared by ESP and network operator

MF Compute Layer

with service plug-ins

MF Compute

MF Compute

Enhanced Service

Provider Interface

Plug-in

Module

Plug-in

Module

WINLAB

Resources

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

GENI website: www.geni.net

ORBIT website: www.orbit-lab.org