MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Summary Slides for FIA Review September 2012 D. Raychaudhuri [email protected] Arun Venkataramani [email protected]
MobilityFirst: A Robust and
Trustworthy Mobility-Centric
Architecture for the Future Internet
Summary Slides for FIA Review
September 2012
D. Raychaudhuri
Arun Venkataramani
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