MobilityFirst: Architecture Summary

and Industry Structure/Business

Model Implications

FIA Meeting - 19,20 April 2012

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

MobilityFirst Architecture

Summary

WINLAB

MobilityFirst Summary: 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 Summary: The 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 Summary: 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 Summary: How MF Works -

(1) At the 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

MobilityFirst Summary: How MF Works -

(2) At Router, AP or BS

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

MobilityFirst Summary: How MF Works -

(3) End-to-End: Multicast Example

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

MobilityFirst Summary: How MF Works -

(4) End-to-End: Dual Homing Example

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

MobilityFirst Summary: How MF Works -

(5) End-to-End: Disconnection Example

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

MobilityFirst Summary: How MF Works –

(6) End-to-End: Enhanced Service Example

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

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

Actors in MobilityFirst

The MF architecture has the following key actors: Network-attached objects (clients, servers, M2M, content, mcast

groups, etc.)

Mobile/Edge network operators, virtual edge network aggregates

Ad hoc networks (clusters of people/cars), mobile platforms (bus, etc.)

Transit and core network operators

Optional external global name resolution service (GNRS) providers

Enhanced network service provider (e.g. CDN, video transcoding,

context..)

Name certification services for assignment of names to GUID public key

WINLAB

Industry Structure & Business Models : Major

Interfaces in MobilityFirst

The MF architecture has the following interfaces: Client to network service API (GUID based)

Client to name certification service (NCS) – name to GUID

Client to GNRS – GUID updates & GUID to NA queries

Network Router/AP to GNRS – GUID to NA queries

Intra-network router interface – reachability & path quality updates

Inter-network AS interface – reachability & path quality updates; GNRS

updates/queries

Inter-network SLA interface – aggregate traffic carrying, peering and

roaming agreements

Ad-hoc and virtual net management interface

Enhanced service client API & router programming interface

Network management API at client and routers

WINLAB

Industry Structure & Business Models:

Summary of MF Architecture Implications

Some properties of the MF industry structure: Network operators, both edge and core similar to current Internet

Mobility as a standard ISP/access network service; virtual networks with

aggregated edge network resources (community networks, etc.)

MF end-points have the choice between one or more wireless access

networks as the standard operating model (het-net, multi-homing, etc.)

Mobile networks (V2V, moving platforms, etc.) with new service model for

dynamic association with other edge networks

Architecture allows for optional GNRS providers for fast, large-scale name

resolution; opportunities for service differentiation

Architecture allows for multiple competing name assignment and trust

management services, possibly domain-specific such as devices, M2M, …

Architecture involves one or more authoritative network naming services

which assign flat GUIDs (and hence NA’s as the hash) to network owners;

this service will also manage trust and mediate inter-network agreements.

Architecture supports enhanced network service operators who use the

optional computing layer at routers – CDN, transcoding, cloud storage, etc.

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

Other Discussion Topics:

Censorship, Privacy,

Network Neutrality

WINLAB

Other Discussion Topics: Censorship & Monitoring

MF network based on GUID service layer Packets contain source/dest GUID’s, each a

random public key

Packet may also contain optional NA’s

GUID’s from intercepted packets cannot be

matched to users/network objects without

inverse GUID name lookup at NCS (..should

require user permission or warrant)

The optional NA’s do provide information on

destination networks, but only at AS level

Overall, MF does not make it easier for

unauthorized monitoring or censorship

Still not possible to prevent such actions by

governments with legal authority

Same GUID property provides strong

authentication for bona-fide users & their

application providers

DATA

SID

Optional NA’s

Source/Dest

GUIDs

Name Certification

Service

WINLAB

Other Discussion Topics: Privacy & Tracking

MF network based on GUID service layer

provides some privacy features Self-certifying GUID avoids any third party

anonymous service capability

Disposable GUID’s and onion routing as

options for enhanced privacy

Mobility service opens up all the issues of user

location tracking which arise in cellular services

NA’s in MF packet (or through GNRS query)

provide coarse-grained location at AS level

GNRS white-list may help limit access to

personal location information

Self-Certifying

User/Device

DATA

SID

Optional NA’s

Source/Dest

GUIDs

WINLAB

Other Discussion Topics: Network Neutrality

MF architecture is no better or worse than IP in

terms of network neutrality Connectionless packet network with provisions

for service ID based scheduling but no QoS

Routers do not attempt to provide GUID specific

priorities - in any case, GUID is a flat/opaque

public key that would be difficult to act on

Above properties consistent with current

definition of network neutrality?

Enhanced services (such as content or context)

at compute layer could provide GUID specific

capabilities where desired

Neutrality for storage resources in the network

is a new design element for MF

A

B

C

D

A C B

WINLAB

Other Discussion Topics: Availability, Robustness

The MF protocol stack is designed for robustness and availability caused

by dynamic changes in network topology or connectivity. Same features

useful for DDOS resistance, etc. Multipath and multi-homing as basic capabilities

In-network storage and DTN delivery as protection against intermittent

disconnection or poor connectivity

Hope-by-hop transport to avoid the need for a high-quality end-to-end path

Path choice and edge-aware inter-domain routing protocol

INTERNET

Wireless

Access Net #1

Wireless

Access Network

Wireless

Access Net #3

Wireless

Edge

Network

BS-1

BS-2

BS-3

AP1

Multi-

Radio

NIC’s

Multiple

Potential

Paths

WINLAB

Resources

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

GENI website: www.geni.net

ORBIT website: www.orbit-lab.org