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