mobilityfirst: architecture summary and industry structure
Post on 12-Sep-2021
3 Views
Preview:
TRANSCRIPT
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
top related