Transcript MF Concept Summary Slides - MobilityFirst

MobilityFirst: A Robust and
Trustworthy Mobility-Centric
Architecture for the Future Internet
Concept Summary – Oct 2011
Contact: D. Raychaudhuri
WINLAB, Rutgers University
Technology Centre of NJ
671 Route 1, North Brunswick,
NJ 08902, USA
[email protected]
MobilityFirst Project: Collaborating Institutions
(LEAD)
D. Raychaudhuri, M. Gruteser, W. Trappe,
R, Martin, Y. Zhang, I. Seskar,
K. Nagaraja, S. Nelson
M. Reiter
A. Venkataramani, J. Kurose, D. Towsley
S. Bannerjee
W. Lehr
Z. Morley Mao
B. Ramamurthy
X. Yang, R. RoyChowdhury
G. Chen
Project Funded by the US National Science Foundation (NSF)
Under the Future Internet Architecture (FIA) Program, CISE
+ Also industrial R&D collaborations with AT&T Labs,
Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others
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
~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors
~1B server/PC’s, ~700M smart phones
INTERNET
Wireles
s
Edge
Networ
k
INTERNET
Wireless
Edge
Network
~2010
~2020
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-ofmagnitude gain in cost performance since 1970)
 Edge/core disparity, fast fiber but continuing shortage of radio spectrum

WINLAB
Architecture: MobilityFirst Network Overview


MF Arch designed to meet
emerging mobile/wireless
service requirements at scale
Key MF 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 ….
MobilityFirst
Router with
Integrated
Computing &
Storage
Computing Blade
Buffer Storage
Forwarding Engine
Hop-by-Hop
Transport
Core Network
(flat label routing)
Base Station
GDTN
Routing
Data block
AP
Wireless Router
Router
Data
Plane
Global Name
Resolution Service
Name <-> PKI
address mapping
Control &
Management Plane
WINLAB
Architecture: MobilityFirst 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
MF Abstraction: Network Object Group with
broadcast reachability
MF Abstraction: Network Object
with multipath reachability
Send(IP=X, data)
Send(GUID=Y, data, options)
..options for mpath & time delivery
Network
IP Addr=X
Interface
Dest
Device
Name=
MAC
NA=X1
NA=X2
Send(GUID=Z, data, options)
..option for mcast delivery
NA=X3
NA=X2
Static
MAC=X
binding
GUID=Y
Network
Attached
Object
Dynamic
GUID – NA
bindings
Broadcast Medium
Group
GUID = Z
GUID1
GUID2
WINLAB
GUID3
Architecture Concepts: Name-Address
Separation

Separation of names (ID) from
network addresses (NA)
Globally unique name (GUID)
for network attached objects
Sue’s_mobile_2





User name, device ID, content, context,
AS name, and so on
Multiple domain-specific naming
services
Server_1234
John’s _laptop_1
Host
Naming
Service
Media File_ABC
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
for GUID  NA mappings
Global Name Resolution Service
Network
Hybrid GUID/NA approach

Both name/address headers in PDU
 “Fast path” when NA is available
 GUID resolution, late binding option
Net2.local_ID
Network address
Net1.local_ID
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
Host GUID
Registration
update
Network – NA2
NA2
Mobile node
trajectory
Data Plane
AP
Network – NA1
Host GUID
Initial
registration
Global NameAddress Resolution
Service
Decentralixed name services
Hosted by subset of ~100,000+
Gatway routers in network
NA1
Host Name, Context_ID or Content_ID
Network Address
WINLAB
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)
1
0.9
Cumulative Distribution Function (CDF)

0.8
0.7
K = 5,
95 th Percentile
at 91 ms
K = 1,
95 th Percentile
at 202 ms
0.6
0.5
0.4
0.3
K
K
K
K
K
0.2
0.1
0
10
20
50
100
Round Trip Query Latency in milliseconds (log scale)
Internet Scale Simulation Results
Using DIMES database
WINLAB
=
=
=
=
=
1
2
3
4
5
1,000
Architecture Concepts: MobilityFirst
Routing Design Goals

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
Core
4G
Connectivity
Wired
Wireless Mesh / Cellular
Mobile Ad-Hoc
DTN
WINLAB
Architecture Concepts: Exploiting InNetwork Storage for Routing
Take advantage of cheap
storage in the network
(storage-aware routing)

~10GB, in-network storage
~1TB, content caching
Expands routing options



~100MB, data in transit
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
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: 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..
Temporary
Storage at
Router
Initial Routing Path
Low BW
cellular link
Re-routed path
For delivery
Mobile
Device
trajectory
PDU
Storage
Router
High BW
WiFi link
Sample CNF routing result
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
GUID=13247..99
GUID=13247..99
NA43
NA31
GUID=13247..99
NA29
GNRS
Query
NA99
Content cache at mobile
Operator’s network – NA99
Data fetch from
NA99
GNRS query
Returns list:
NA99,31,22,43
GUID=13247..99
NA22
Content Store #1
(owner)
Data fetch from
NA43
Get (content_GUID)
User mobility
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
Context = geo-coordinates & first_responder
Send (context, data)
Context
Naming
Service
Context
GUID
Global Name
Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory
WINLAB
Protocol Design: MF Stack

Core elements of MF protocol stack






GUID services layer, supported by control protocols for bootstrap & updates
GUID to network address mapping (GNRS) for dynamic mapping of GUID
Generalized storage-aware routing (GSTAR) with supporting control protocols
Reliable hop-by-hop block transfer between routers
Management plane protocol with its own routing scheme
Multiple TP options and plug-in programmable services at GUID layer
APP-2
APP-1
Name Certification
Service A
Mgmt
Apps
Routing
Apps
Management
Plane
Protocols
(incl. routing)
Routing
Control
Protocols
E2E
Transport
Protocol A
GUID
Services
Control
Protocols
E2E
Transport
Protocol B
APP-n
……..
E2E
Transport
Protocol B
Computing Layer
Service Plug-ins
GUID Service Layer
GUID-to-Net Address Mapping
Storage-Aware Routing (GSTAR)
Hop-by-hop Block Transfer Protocol
Link Layer A
(e.g fiber)
Link Layer B
(e.g LTE)
Link Layer C
(e.g WiFi)
Link Layer D
(e.g Ethernet
WINLAB
Example 1: 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
GUID
NA1:PA22; NA7:PA13
Router bifurcates PDU to NA1 & NA7
(no GUID resolution needed)
GUID
DATA
NetAddr= NA1.PA22
Net
1
Alice’s laptop
GUID = xxx
Data Plane
Net 7
Dual-homed
mobile device
DATA
DATA
GUID
NetAddr= NA7.PA13
GUID/SID
NA1:PA22; NA7:PA13
DATA
GUID & SID
Send data file to “Alice’s laptop”
Current network addresses provided by GNRS;
NA1:PA22 ; NA7:PA13
WINLAB
Example 2: GUID/Address Routing
Scenarios – Handling Disconnection

Intermittent disconnection scenario below uses GUID based redirection (late
binding) by router to new point of attachment
DATA
GUID
NetAddr= NA1.PA9
- Delivery failure
PDU Stored in router
- GUID resolution for redirection
DAT
A
GUID
Mobility
Trajectory
Net
1
Data Plane
Disconnected
Region
Net 7
DATA
GUID
DATA
NetAddr= NA1.PA7
GUID
DATA
GUID/SID
Send data file to “Alice’s laptop”
Current network address provided by GNRS;
NA1 – network part; PA9 – port address
NetAddr= NA7.PA3
Successful redelivery after connection
WINLAB
MobilityFirst Prototyping: Phased Approach
Content
Addressi
ng Stack
Context
Addressi
ng Stack
Host/Device
Addressing
Stack
Encoding/Certifying Layer
Global Name Resolution Service (GNRS)
Storage Aware
Routing
Locator-X Routing
(e.g., GUID-based)
Context-Aware /
Late-bind Routing
Simulation/Emulation
Emulation/Limited Testbed
Testbed/‘Live’ Deployment
Evaluation Platform
Standalone
Components
System Integration
Deployment ready
Prototyping Status
WINLAB
MobilityFirst Prototyping: GENI Deployment
Plan (Phase 3)
Legend
Domain-1
Services
Internet 2
National Lambda Rail
Domain-3
Domain-2
OpenFLow Backbones
OpenFlow
Full MF Stack
at routers, BS, etc.
Wireless Edge
(4G & WiFI)
WiMAX
ShadowNet
Router
Wireless Egde
(4G & WiFI)
Router
Wireless Edge
(4G & WiFI)
Router
Router
Intra-domain mobility
Router
Opt-in users
Router
Inter-domain mobility
Mapping onto GENI
Infrastructure
ProtoGENI nodes,
OpenFlow switches,
GENI Racks,
WiMAX/outdoor ORBIT
nodes, DieselNet bus,
etc.
Deployment Target:
• Large scale, multi-site
• Mobility centric
• Realistic, live
WINLAB
19
MobilityFirst Prototype: Multi-Site GENI
Demo (GEC12, ~4Q2011)





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
GENI Core
NA-1
WiFi AP
WiMAX BSS
e
a
MF Router
c
Android Client w/ WiMAX + WiFi
NA-2
Linux PC/laptop w/ WiMAX + WiFi
Campus Network
(at Rutgers)
Vehicular node w/ WiMAX
Sensor node
d
b
MF Sensor GW
20
Campus Network
(at other GENI site)
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.)
WINLAB