Transcript MF_Review_Mtg_3.13Rx - MobilityFirst Future Internet

MobilityFirst Project Update
NSF Meeting
March 11, 2013
D. Raychaudhuri
WINLAB, Rutgers University
[email protected]
Introduction: Progress Highlights


MobilityFirst project now moving from design phase to
experimental evaluation and GENI/EC2 deployment
Highlights of recently completed work:









Architecture is now stable – clarification of named-object/GUID narrow waist and
application to specific use cases; comparisons with other FIA schemes
Two alternative GNRS designs completed and evaluated with prototype
deployment starting on EC2 and GENI
Intra-domain routing complete (GSTAR); 2 alternative inter-domain routing designs
completed; ongoing evaluation and prototyping
Evaluation of routing technology options: software, OpenFlow, NetFPGA
Security and privacy analysis for key MF protocols – GNRS, routing, ..
Compute layer for plug-in extensions/in-network processing designed and
implemented
Detailed designs and prototyping for mobile, content and M2M use cases
Network management client-side design and demo; ongoing work on overall NMS
capabilities
System-level prototyping of MF protocol stack and GENI deployment with realworld end-users and applications
Introduction: Meeting Agenda
Draft Agenda
Time
10:00-10:10
10:10-10:25
10:25-10:40
10:40-10:50
10:50-11:00
11:00-11:10
11:10-11:20
11:20-11:30
11:30-11:40
11:40-11:50
11:50-12:00
12:00-12:10
12:10-12:25
12:25:1:00
1:00
Topic
Introduction and comments from NSF
High-level MF architecture updates
GNRS design #1 and AUSPICE implementation
GNRS design #2 and DMap implementation
Bloom routing design & evaluation
Edge-aware inter-domain routing (EIR) & prototyping
Computing layer design & prototyping
Wireless/mobile use case evaluation & economics
Network mobility, and performance metrics
M2M/context use case & prototyping
Security and Privacy Analysis
Network management design & prototyping
MF Prototyping & GENI deployment
Q&A/Discussion
Adjourn
Presenter
Darleen Fisher, Bryan Lyles, Ray
Arun Venkataramani, Ray
Arun, Emmanuel Cecchet
Yanyong Zhang
Morley Mao
Tam Vu
Yang Chen, Xiaowei Yang
Roy Yates, Bill Lehr
Jim Kurose
Jun Li, Rich Martin
Wade Trappe, Janne Lindqvist
Suman Banerjee
Kiran Nagaraja, Ivan Seskar
MobilityFirst: High-level
Architectural Updates
Arun Venkataramani
4
From Design Goals to Current Architecture






Host + network mobility
No global root of trust
Intentional data receipt
Proportional robustness
Content-awareness
Evolvability
Global name service
Name certification
Name resolution
Content storage & retrieval
Context & M2M services
Service migration
Inter-,intra-domain
routing
Computing
layer
Segmented
transport
Management
plane
Key insight: Logically centralized global name service
enhances mobility, security, and network-layer functions
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
5
Architecture: Global name service
Global name service
Name certification
Name resolution: Auspice, DMap
human_readable_name  GUID
“Darleen Fisher’s phone”  1A348F76
Content storage & retrieval
Context & M2M services
Service migration
self-certifying GUID = hash(public-key)
permits bilateral authentication
GUID flexibly identifies principals:
interface, device, person, group, service, network, etc.
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
6
Architecture: Global name service
Global name service
GUID  NA
Name certification
Name resolution: Auspice, DMap
GUIDNA2
Content storage & retrieval
Context & M2M services
Service migration
data
NA1
NA2
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
7
Global name service: Content retrieval
Global name service
Name certification
Name resolution: Auspice, DMap
Content storage & retrieval
Context & M2M services
Service migration
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
8
Global name service: Content retrieval
 Content CGUID  [NA1, NA2, … ]
• Opportunistic caching + request interception
GNRS
CGUID
get(CGUID, NA1)
NA1
CGUID
CGUID
CGUID NA2
get(CGUID)
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
9
Global name service: Content retrieval
Global name service
Name certification
Name resolution: Auspice, DMap
Content storage & retrieval
Context & M2M services
Service migration
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
10
Indirection and grouping
 Indirection: D1  D2
 Grouping: D  {D1, D2, …, Dk}
Indirection and grouping enable context-aware services,
content mobility, and group mobility
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
11
Indirection+grouping: Context-awareness
 GUID_cabi [T1, {“type””yellowcab”, “geo””Times Sq.”}]
 At source: CAID  {T1, T2, …, Tk} // terminal networks
 At terminal n/w: CAID  {members(CAID) | Ti} // late binding
GNRS
CAID1members(CAID){T1, T2, …, Tk}
T1
T2
Tk
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
13
From Design Goals to Current Architecture






Host + network mobility
No global root of trust
Intentional data receipt
Proportional robustness
Content-awareness
Evolvability
Global name service
Name certification
Name resolution
Content storage & retrieval
Context & M2M services
Service migration
Inter-,intra-domain
routing
Computing
layer
Segmented
transport
Management
plane
Key insight: Logically centralized global name service
enhances mobility, security, and network-layer functions
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
16
Architecture: Scaling interdomain routing


Function: Route to GUID@NA
Scale: Millions of NA’s  huge forwarding tables
send(GUID@NA, data)
…
…
…
…
…
…
Network
…
Interface
…
NA1
2
NA2 …
NA3
6
NA3
…
1
NA4
2
…
…
…
…
…
…
NA1
…
…
…
…
NA2
…
…
NA108
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
17
Architecture: Scaling interdomain routing


Function: Route to GUID@NA scalably
Approach: Core and edge networks to reduce state
Global name service
X1
X3
 Few interdomain routing designX2 efforts maturing
X2,T4
1. Vnode + pathlet
routing + link-state + telescoping updates
data
2. Bloom routing
3. Core-edge
T1
T2 routing with *-cast throughT4nameTservice
5
T
T6
3
GUID
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
18
From Design Goals to Current Architecture






Host + network mobility
No global root of trust
Intentional data receipt
Proportional robustness
Content-awareness
Evolvability
Global name service
Name certification
Name resolution
Content storage & retrieval
Context & M2M services
Service migration
Inter-,intra-domain
routing
Computing
layer
Segmented
transport
Management
plane
Key insight: Logically centralized global name service
enhances mobility, security, and network-layer functions
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
20
Architecture: Computing layer
 Programmable computing
layer enables service
flexibility and evolvability
• Routers support new network
services off the critical path
• Packets carry (optional)
service tags for demuxing
• Integration with “active” GUID
resolution in global name
service
Virtual
Service
Provider
Content
Caching
Computing layer
CPU
Privacy
routing
Storage
Packet forwarding/routing
anon
......
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
anon
......
21
From Design Goals to Current Architecture






Host + network mobility
No global root of trust
Intentional data receipt
Proportional robustness
Content-awareness
Evolvability
Global name service
Name certification
Name resolution
Content storage & retrieval
Context & M2M services
Service migration
Inter-,intra-domain
routing
Computing
layer
Segmented
transport
Management
plane
Key insight: Logically centralized global name service
enhances mobility, security, and network-layer functions
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
22
From Design Goals to Current Architecture






Host + network mobility
No global root of trust
Intentional data receipt
Proportional robustness
Content-awareness
Evolvability
Global name service
Name certification
Name resolution
Content storage & retrieval
Context & M2M services
Service migration
Inter-,intra-domain
routing
Computing
layer
Segmented
transport
Management
plane
Key insight: Logically centralized global name service
enhances mobility, security, and network-layer functions
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
24
Architecture: Why logically centralized?
 Indirection-based
 Logically centralized
 Network-layer
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
26
Auspice: A Global Name
Service for a Highly Mobile
Internetwork
Arun Venkataramani, Emmanuel Cecchet
(with Abhigyan Sharma, Xiaozheng Tie, David
Westbrook, Hardeep Uppal)
University of Massachusetts Amherst
27
Global name service as geo-distributed key-value store
value(s)
resolve(GUID,…)
Global name service
GUID: {
{NAs:[[X1,T1],[X2,T2],…},
{geoloc:[lat, long]},
{TE_prefs: [“prefer WiFi”,…]},
{ACL: {whitelist: […]}},
…
}
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
28
Auspice design goals
1. Low response time: Replicas of each name’s resolver
should be placed close to querying end-users
2. Low update cost: Number of resolver replicas should
be limited to reduce replica consistency overhead
3. Load balance: Placement of replicas across all names
should prevent load hotspots at any single site
4. Availability: Sufficient number of replicas so as to
ensure availability amidst crash or malicious faults
5. Consistency: Each name resolver’s consistency
requirements must be preserved
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Trade-offs of traditional approaches
 Replicate everything everywhere:
• + Low response times
• - High update cost under mobility, load imbalance
 Few primary replica plus edge caching:
• + Low update bandwidth cost
• - Consistency requirements may limit caching benefits
• - Load balance vs. response time trade-offs
 Consistent hashing with replication
• + Good load balance
• - High response times (randomization, locality at odds)
• - Dynamic replication, consistency coordination, load balance
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Auspice resolver replica placement
Locality-aware
Load-aware
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
31
Auspice resolver placement engine
Replica controllers
X
X
X
Migrate
replicas
Active
replicas
X
First request
for name X
Load reports
X
X
Mapping algorithm +
Paxos to compute active
replica locations
X
X
X
X
Typical request for name X
to nearby active replica
End-hosts or local name servers
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Locality-aware,
load-aware,
consistent
Auspice service migration (in-progress)
Paxos
create_replica(.)
shutdown_replica(.)
migrate_replica(.)
Paxos
report_load(.)
Sequential
consistency
America
Europe
Paxos
Asia
Paxos
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Auspice implementation & evaluation
 Implemented mostly in Java (~22K lines of code)
• Supports mysql, MongoDB, Cassandra, in-memory store
• HTTP API for request/responses
 Flexible keys and values
• [GUID, NA], [GUID, IP], [name, IP]
 Near-beta version deployed on eight geo-distributed
Amazon EC2 locations
• Extensive evaluation on larger clusters and PlanetLab settings
 Mobile socket library for seamless mid-session client
and server migration
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
34
Auspice vs. alternate proposals
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
35
Auspice vs. commercial managed DNS
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
36
Application scenario: Emergency geo-cast
 Demo by Emmanuel Cecchet
http://youtu.be/EfDaqs0uuBY
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
37
Questions?
 http://www.cs.umass.edu/~arun/MobilityFirst
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
38
Global Name Resolution
Services Through Direct
Mapping (DMAP)
Yanyong Zhang
Name-Address Separation Through GNRS

Globally unique name
(GUID) for network
attached objects
Sue’s_mobile_2
Server_1234
John’s _laptop_1
Media File_ABC
Taxis in NB
Sensor@XYZ

device, content, context, AS name,
sensor, and so on
 Multiple domain-specific naming
services


Global Name Resolution
Service for GUID  NA
mappings
Where to store these
mappings?
Host
Naming
Service
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
Network
Net2.local_ID
Network address
Net1.local_ID
WINLAB
Direct Mapping (DMAP)
GUID
(00101100……10011001)
Hash Function
IP
IPx = (44.32.1.153)
(-)
(+)


Strictly 1-overlay-hop lookup
No extra routing requirement
(e.g. utilize current BGP)


IP “hole” issues
Limited locality
WINLAB
Fixing IP Holes for IPv4

Fixing IP Holes:


If hash of GUID falls in
the IP hole, rehash that IP
m times to get out of the
hole
Lookup follows the same
process to find GUID
Map of IP (/8) address space (white
= unassigned addresses)
Value at m=10 is 0.0009
WINLAB
Fixing IP Holes for General
Network Addressing Schemes


In a general network addressing scheme, we can have more
holes than used segments (e.g., IPv6)
Used address segments are hashed into N buckets


a two-level index: (bucket ID: segment ID)
Mapping GUID to NA
H1(GUID)  bucket ID
 H2(GUID)  segment ID within a bucket

(2, 1)
(1, 1)
(1, 2)
(2, 2)
network address space
used segments
unused segments
WINLAB
Mapping Replication
(00101100……10011001)
GUID
k Hash Functions
K=2
IPx = (44.32.1.153)
IP
IP
IP


K=3
IPx = (67.10.12.1)
IPx = (8.12.2.3)
Every mapping is replicated
at K random locations
Lookups can choose closest
among K mappings. Much
reduced lookup latencies
K=1
WINLAB
Capturing Locality


Spatial locality: GUIDs will be more often accessed by local nodes (within
the same AS)
Solution: Keep a local replica of the mapping


A lookup can involve simultaneous local lookup and global lookup
LNRS and GNRS
Local replica
AS 1
GUID
AS#
10
1
GUID 10
AS 5
AS 200
K=1
K=3
AS 101
GUID
AS#
10
1
K=2
GUID
AS#
10
1
GUID
AS#
10
1
WINLAB
Simulation Results – Query
Latencies
WINLAB
Evaluation: Tomorrow’s Internet

A Jellyfish model


captures each AS’s distance to the core
Tomorrow’s Internet

More and larger ASs
 Flatter topology
20% more
nodes in all
6 levels
Double the
nodes in
the 4 levels
WINLAB
Plural Routing
Z. Morley Mao
Plural routing design: routing table
reconstruction
A scalable, flexible, incrementally deployable inter-domain routing protocol
Deployability: limiting upgrades into
routing tables
• Upgrading routing tables only, the rest
of BGP remains
Scalability: significantly smaller routing
tables
• Replacing routing tables with bloom
filters
Flexibility: multiple routing entries per
destination
• Each neighbor is allocated a dedicated
bloom filter
WINLAB
Plural routing simulation-based evaluation
Scalability:
routing table size
•
•
The maximum routing table size < 5MB
99% of routing tables < 100KB
• A single bloom filter is 1KB to guarantee
zero false positive
Flexibility:
avoiding a
domain
•
•
MIRO is 64%, and plural routing is 69-70%
Most of the rest 30% cannot be avoided.
Flexibility: load
balancing
•
•
The disjointness between the alternate route
and the default one is high
Close to the optimal
WINLAB
Plural routing prototyping
Research question: what’s the deployability?
• How much plural routing deployment achieves how much
flexibility/scalability
• How efficient plural routing interacts with other internet
infrastructure interface
Implementation
Evaluation
• Platform
• Scalability
• Click router
• Naming service (GNRS?)
• Steps
• Re-construct routing tables using bloom filters,
keep the rest of BGP
• Take RouteViews BGP traces as the input to a
Click router
• Perform routing looking up and update routing
table accordingly
• Routing lookup
• Routing table size
• Path inflation
• Flexibility
• Avoiding intermediate domains
• Load balancing
• Milestones
• ORBIT: test on single router
• GENI: test on a couple of POPs
WINLAB
Edge-Aware Inter-Domain
Routing
Tam Vu, D. Raychaudhuri
Edge-aware Inter-domain Routing (EIR)

Provide network level support for:
 Robust

message delivery to unstable mobile edge networks
Using in-network name-to-address mapping and storage
aware routing
 Flexible
path selection for multi-homing, multi-path, multinetwork operations

Providing a full view of network graph with link-state protocol
 Efficient

multicast and any-cast
Using naming resolution service for membership management
 Service-defined

message delivery
Service ID –based routing and forwarding
WINLAB
EIR Mechanisms

Abstracting network entities to increase network visibility

Aggregation nodes (aNode) and virtual link(vLink)
 ASes distribute NSP(Network state packets): Information about internal
network states and links to its neighbors (link-state protocol)

Telescopic routing updates to reduce dissemination overhead


Controlling the NSP update rate as a function of distance-to-originating AS
Late name-to-address binding

Router has capability of rebinding <GUID=>Address> for packets in transit
WINLAB
EIR Prototyping

Click-based prototyping on Orbit nodes


Implementation on 200+ nodes on the grid
Evaluate: Packet loss rate, throughput, good put,
lookup delay, stretch, routing stable size, etc.
EIR Click router
RIB
OSPF w.
Telescoping
Link state advs
NSP
GNRSd
Binding request
SID 3
SID 2
SID 1
NextHop
Table
EIR forwarding engine
Data Packets
Data Packet
WINLAB
EIR Prototyping(2)

Click-based prototyping on Orbit nodes
 Message
delivery with late binding
 Storage-aware routing
 Efficient multicast & multipath data delivery
70
Sender
EIR Routers
EIR Routers
EIR Routers
Percent of lost packets (%)
60
Early binding
Late binding
50
40
30
20
10
EIR Routers
EIR Routers
0
100
Mobile Trajectory
Receiver
200
300
400
600
500
Mobility rate (ms)
700
800
900
WINLAB
1000
PacketCloud Compute Layer
Yang Chen, Xiaowei Yang
PacketCloud Motivation


End-to-end principle
Benefits of In-network Services
 For Internet Service Providers (ISPs)
 Value-added services for end users
 Current practice: Standalone middleboxes
 For third-party providers (Netflix, Youtube,
 Proxies in different networks
 Current practice: delivering servers to ISPs
games)
Telmex
AT&T
WINLAB
PacketCloud: Overview
Domain Controller
DC
NY
Cloudlet
Cloudlet
Cloudlets form an elastic
resource pool to support innetwork services
WINLAB
59
PacketCloud: Implementation
and Evaluation

A proof-of-concept prototype based on MobilityFirst
architecture


Service identification and discovery
Implemented services

Protocol Translator, WAN Optimizer, Intrusion Detection System, Secure
Communication (more are coming…)
 Deployment in both wired/wireless environments

Scalability

How much traffic a service hosting node can handle?



Hardware: bpc2133 nodes on Deterlab (Quad Core processor running at 2.13GHz)
Service complexity: AES encryption (computationally intensive)
One bpc2133 node can handle traffic as fast as 500~600Mbps
20 nodes in a Cloudlet 
10+Gbps
WINLAB
Wireless/Mobile Use Case
Roy Yates, Bill Lehr
Wireless Access Use-case through
MobilityFirst

MobilityFirst enables a stitched-together architecture for
mobile networks
Current Mobile Networks
•
•
•
•
•
•
AAA Server
GSM/CDMA/
LTE
Control Path Elements
Mobility Management
Entity (MME)
Data Path Elements
Make-before-break
Handover
Controlled QoS inside network
Wi-Fi
Internet
Gateway
Node
ISP 1
MF Network-of-Networks
Internet
GSM/CDMA/
LTE
ISP 2
Mobility Support
Through GNRS
Planned Deployment
Licensed Spectrum
Fine-grained Managed QoS
Centralized Mobility Support
Homogeneous Topology
Network-wide Authentication
Global Name
Resolution
Service
•
•
•
•
•
•
Ad-hoc Deployment
Unlicensed Spectrum
Coarse-grained Managed
In-network Mobility Support
Heterogeneous topology
Authentication at APs
ISP 3
Wireless Cooperation
through Geographic Routing
WINLAB
LTE/4G Cellular Networks
Internet
PCRF

 Gigabit Ethernet IP pipes
 Between eNBs (basestations)
 To MME, P-GW, S-GW etc
P-GW
Evolved
Packet
Core
HSS
MME
Evolved Packet Core: IP
S-GW
E-UTRAN
eNB
RAN interconnect: IP
 Cellular Protocol interfaces
 simple IP port implementation
UE
eNB

eNB
C-Plane
U-Plane
WINLAB
63
4G/LTE: Modern View

Internet
PCRF
 Basestations
P-GW
Evolved
Packet
Core
HSS
MME
A private IP network
S-GW
E-UTRAN
(eNB)
 Mobility Management (MME)
 Authentication
 Gateway


Anchor for public Internet
connections
Similar to MobileIP home agent
eNB
UE
eNB
eNB
WINLAB
64
LTE/M1ST Feature Comparison


Licensed spectrum
eNB coordination



Frequency/coverage
planning
Transparent Multihoming
& Multipath

Private mobility services


M1ST Features
(What LTE/4G is missing)
LTE Features
(What M1st is missing)
subscribers only
Enabler for heterogeneous
dynamic spectrum access

Public mobility services

Ad Hoc Networks
Business model

Monthly subscription 
ubiquitous access


65
Network Mobility
Content & Context
Cellular/LTE  M1ST ?

Should/will operators adopt M1st?

Incentives:



Disincentives:


Outsourced mobility/authentication,
M1st new features are useful, perhaps essential
Weaker customer relationships?
M1st technical/performance issues


GNRS signaling load & handoff latency,
Benefits of in-network mobility management & storage aware
routing
66
WINLAB
Scalability of mobility management using MF
GNRS and GSTAR


We did a trace driven simulation to assess MF scalability
Question: How much load on GNRS if everyone driving in a
given area uses MF for mobility management:
Traces from Rutgers Intelligent Transportation Systems Lab: Captures peak
time traffic of >16K vehicles in a ~8 sq.km urban area of Jersey CIty, NJ
GNRS load not too high even for very frequent handovers
and high density of vehicles
Cumulative Distribution Function (CDF)
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
Cell Radius = 250 m
Cell Radius = 500 m
Cell Radius = 750 m
0.1
0
0
10
20
30
40
50
60
70
WINLAB
Number of Updates/second
80
90
Wi-Fi roaming with MobilityFirst
Quantifying the benefits of in-network mobility management &
storage aware routing
• NS3 Simulation with full 802.11 stack,
different vehicular speeds & offered load
• Comparing TCP/IP with MF
Transmission of stored packets  Throughput Jumps
Total Data Received (MBytes)

Speed = 30 miles/hr
Speed = 50 miles/hr
100
Speed = 70 miles/hr
100
100
80
80
80
60
60
60
40
40
40
20
20
20
0
0
50
100
150
Time (sec)
200
0
0
50
100
150
Time (sec)
200
0
MobilityFirst
TCP/IP
0
50
100
WINLAB
Time (sec)
150
200
Seamless switching between LTE & WiFi
MF provides several benefits in a heterogeneous wireless
environment:

Mobility Mgmt. is not specific to each network
 Automatic storage of packets in transition
 Simultaneous use of multiple networks
Aggregate Throughput with Time
1000
900
Aggregate Throughput (MBytes)

Throughput boost
due to transmission
of stored packets
800
TCP takes more time to
re-start session (DHCP +
Application reset)
700
600
500
400
300
200
MobilityFirst
TCP/IP
100
0
0
20
40
60
Time (sec)
80
100
120
WINLAB
M2M Use Case
Jun Li, Rich Martin
[70]
M2M Challenge: System Isolations

Solution: a shared platform providing standard APIs across
systems

Mobile operator solution (3GPP): M2M Gateway + M2M server
 Web of Things solution (W3C): Semantic Web / Linked-data
 MobilityFirst solution: Core network ubiquitous computing


Sensor data is identified by GUID assigned by owners
Applications access sensors by GUIDs across system
server
boundaries Naming
(assign GUIDs)
A1
S1
S2
Sensors Si
(Things)
Shared Platform
(hosting, middleware)
A2
Apps
Aj
MobilityFirst is a ubiquitous computing platform
March 11, 2013
MobilityFirst Review Meeting
WINLAB
Use cases: M2M and Context-aware



M2M: S1 data is picked up by Mobile GW and sent to MF for A1 that subscribes it
Context: T1, conf@WINLAB, is subscribed by P1 …P4;A2 sends a file to T1 reaches P1..P4
via MF
M2M/Context server updates MF-GNRS for mappings: S1 A1 and T1  P1…P4
Context T1
Conf @WINLAB
Subscriber P1
Lookup S2, T1 &
Subscribe T1
P2
P3
Lookup S1, C1, subscribe S1
M2M / Context (Naming)
Server, GUID
Assign & Publish
(S1, S2, C1, T1)
Application A2
Lookup Context T1
Lookup S1
NA2
P4
Presentation
DATA
NA3
DATA
Sensor S2
(location)
UPDATE
Sensor S1
(temperature)
Actuator C1
(air conditioning)
March 11, 2013
Application A1
Internet
(MobilityFirst)
NA4
UPDATE
M2M
GateWay
GNRS: Global Name
Resolution Service
NA1
GNRS
Entries:
S1 -> A1
C1 -> NA1
S2T1, T1P1..P4
P1 -> NA2, P2->NA2
P3 -> NA2, P4->NA3
MobilityFirst Review Meeting
SmartGrid App
A1 -> NA4
WINLAB
System Components for M2M/Context Demos
WSN Gateway (Android)
- MF Client Protocol Stack
M2M/Context (naming) Server
- Definitions and descriptions
- GUID assignment & GNRS update
- Subscription management
- WSN Access Point Stack
- WSN to MF GW processing
GUI/settings
Sensor Data
Parsing &
Collection
Raw data
processing
Lookup Sensor
GUIDs &
description XML
GUI (Sensor/Context on Map)
MF formatting
& delivery
Java wrap up API
Java USB Driver
for Wireless
Sensor AP
Native MF
Client Stack
Sensor Radio
(Proprietary now)
WiFi or 3G/LTE
TCP
/IP
Gatewa
y
Service Mod
(GUID lookup ,
Subscription)
GNRS Module
(GUID update)
GW Module
(GUID lookup)
- Lookup a GUID
- Subscribe to GUID
- Send/Rcv data of GUID
Sensor/Actuator
Context App
App (smartGrid) (File transport)
GUID lookup & subscription
Java Wrapper
Sensor / Context Management
(add/remove resources)
Browser /
HTTPclient
Native MF Client Stack
TCP/IP
GNRS
- Sensor GUID -> App GUID
Apache Server
Downloadable
User-level
App
for Android
MobilityFirst Review
Meeting
Naming Mod
(GUID
assignment)
Applications (PC)
mySQL DB
GNRS
Native MF Client Stack
Web
services
TCP/IP
Caching
Computing
MF Router Stack
Click Router
March 11, 2013
73
Evaluation – MF compare to conventional
- avoiding bottlenecks while retaining controls
Gateway
WSN
Sensor
Signaling
Current
(3GPP)
Data
WSN
Signaling
Gateway
“Single copy”
Data
March 11, 2013
“Multi-copy”
M2M
Server
Internet
Apps
“bottleneck”
“End-to-end”
“Lightweight
& Mobile”
MobilityFirst
Sensor
Internet
M2M
Server
MF
edge
Internet
MF
edge
Apps
“Hop-by-hop & multicasting”
MobilityFirst Review Meeting
WINLAB
Evaluation - compare to an overlay data hosting model

Scalability – measure server load (computing/
storage) and analyze network traffic load



Server load: No data traffic to M2M/Context server, No per
data trunk/flow signaling, only per application signaling (use
experiments to evaluate)
Network load: in-network multicasting increases delivery
efficiency ( use analysis or simulations to evaluate)
Latency


Compare the delays of pulling vs. pushing (use analysis to
evaluate)
Measure the delay of pushing data through M2M hosting
server (use experiments evaluate)
March 11, 2013
MobilityFirst Review Meeting
WINLAB
Network mobility, and
performance metrics
Simon Heimlicher
Jim Kurose
Don Towsley
Arun Venkataramani
Goal: network mobility models

develop models of user mobility among edge networks
for evaluation of:

architecture (core principles, basic design decisions)
 mechanism design (instantiated architecture: protocols)
 deployment decisions (operational network)

network mobility distinct from user mobility: user
switches networks, depending on device, personal
mobility
ß
ß
128.119.*.* 174.224/11
(UMass) (VZ Wireless)
UMass
ß
174.224/11
(VZ Wireless)
mobile
128.119.*.* 174.224/11 76.119.101.*
(UMass VPN)(VZ Wireless) (Comcast)
home
WINLAB
Modeling network mobility

quantitatively measure network residency times, transition
rates among networks, sets of networks visited




network granularity: subnet, AS
routing distance between networks
abstract mobility-among-networks models
two measurement approaches:


server-based (IMAP logs: IMAP client sends client IP network
every 5 minutes, when client active)
 scalable measurement – one trace file captures many users
client-based: directly measure client network mobility (Andriod app)
 high-fidelity measurement – doesn’t rely on email
WINLAB
Measuring network mobility
IMAP logs UMass CS
 Univ logs: IRB needed
 sample heatmap:
Android app:



detect/record/upload network
change
traceroute
http://iptrack.srvr.ch/
Mobility First: Security
Discussions
Wade Trappe
[80]
Security Considerations: Trust Model
Host
Naming
Service
X
Content
Naming
Service
Y
Other
Naming
Services
TBD
Context
Naming
Service
Y
Network
Naming
Service
B
Network
Naming
Service
A
GNRS
GUID = public Key
Secure
Host
Name
Service
Lookup
Secure
GNRS
Update
GUID <-> NA
binding
Name assignment
& certification
services (..can
incorporate
various kinds of
trust including
CA, group
membership,
reputation, etc
Secure
Network
Name
Service
Lookup
NET NA7
Secure InterNetwork
Routing Protocol
NET NA1
NET NA33
NA 14
Aggregate NA166:
NA14, NA88, NA 33
NA 88
NA 51
NA 99
Secure
Data Path
Protocol
Public Key object and network names enable us to build secure protocols for each interface shown
WINLAB
MobilityFirst Security Efforts




Identification of potential
security threats and risks
 The methods of such
intrusions/subversions
 The risks that may result
from a successful attack
Development of security
solutions to address the
identified risks
Results:
 Security analysis for twotier name resolution
service
Ongoing: Access-control
within name resolution
impacts security and privacy
of network services
[82]
WINLAB
Functional View of NCRS & GNRS
[83]
WINLAB
NCRS Functionalities


Name Translation
 Provide translation between
human
readable keywords and GUID
Certificate Registry
 Analogous to Public Key
Infrastructure (PKI) and functions
a CA performs
 Define certificate format
 Allow self-certifying & certificate
assignment
 Certificate registry operations:





Example: NCRS Certificate Insert
(self-certifying)
– Can leverage existing
technologies
– Insert certificate using
Kerberos 5 protocol
Insert (self-certifying) / Certificate
request (certificate assignment)
Query
Update
Revoke
[84]
WINLAB
GNRS Security Concerns

GUID Spoofing Attack:




Stale Mapping Attack:




A message manipulation attack
A device moves and issues an update, the malicious GNRS server can purposely ignore the
update and claim it still has the most recent mapping. Perhaps worse, a GNRS server can
selectively choose which (possibly stale) mapping to give out during queries.
Consequence: denial of service
False Announcement Attack:




A masquerading threat
A malicious user A claims another user B's GUID and attempts to associate it with A's own
network address by announcing the mapping (GUIDB, NAA).
Consequence: denial of service
An information modification attack
User A, which is in network NA1, claims its GUIDA binds to a different network address, (GUIDA,
NA2).
Consequence: illegitimate resource consumption
Collusion Attack:



An information modification attack
A malicious user, its network and the location where the mapping is stored collude with each other
to allow a fake mapping involving a false network address to pass the verification and become
stored in the storage location.
[85]
Consequence: denial
of service
WINLAB
Securing GNRS


Securing GNRS involves
developing new Update and Query
protocols that are resistant to
attacks
GNRS Specific Attack: IP Hole
Protocol Attack:


During withdrawing IP prefix, a
malicious user can insert many fake
orphan mappings to a target network
to exhaust that network's storage
resources, while also causing the
GNRS to report false mappings to
queries.
Secure GNRS Update
Current Status:

Integrated security mechanisms into
GNRS protocol
 Secure variations of Update and
Query Protocols
 Identified appropriate cryptographic
parameters that
[86]provide efficiency
Secure GNRS Query
WINLAB
Controlling Access to GNRS Information

User should be able to specify:
Which people can see any information about the user’s name
 Which people can see which set of available interfaces mapped to the user’s
name
 How frequently people are allowed to receive information about the user’s name
(similar to location privacy)


User-initiated cryptographic techniques:

Encrypt specific updates with a group key only available to a target group


Leads to key distribution problems
GNRS-based access control:

Updates contain a policy that specifies who can access what
 Queries contain an authentication token that can be used in conjunction with the
policy to supply appropriate information
Update
Query
Cryptographic Package
Name
Address
List
Timestamp
s
Cryptographic Package
Polic
y
Name
Authentication
Token
WINLAB
Mobility Services Engine:
A Measurement Framework
for the MobilityFirst
Architecture
Suman Banerjee
University of Wisconsin-Madison
MSE Architecture




Build a client-assisted measurement framework
for monitoring network devices
Minimize the measurement load through
distributed operations
Conduct location based measurement, identify
the network performance
Utilize the measurement results for
scheduling/routing decision
Server Database
Clients
Logically distributed
WINLAB
Web Service API




Provide web services using HTTP methods and
JSON objects to serve clients and administrators
All messages between server and clients will be
delivered via API
Support various types of clients
Universally reachable
WINLAB
Measurement Results
Experiments on GENI WiMAX and other infrastructure in Madison, WI
Throughput (WiMAX)
RTT (Cellular)
RSSI (WiMAX)
Throughput
(Cellular)
WINLAB
Mobility First Prototyping
& GENI Deployment
Kiran Nagaraja
[92]
MF Software Router and Host Protocol Stack
Click-based MF Router
Android/Linux MF Protocol Stack
Storage-aware routing (GSTAR)
- Name resolution server (GNRS)
- Reliable hop-by-hop link transport (Hop)
- Network API
- Hop
- Dual homing (WiFi/WiMAX)
-
Native,
user-level
implementation
on Android
runtime
WiFi AP
MF Router
MF Router
93
MF Router
WiMAX BTS
WINLAB
GNRS Implementation

Two alternate designs:

network-level one-hop map service; co-located with routing
 Locality-aware, cloud-hosted service

Three alternate evaluation platforms:
1. GENI Wide Area
Deployment
2. ORBIT lab with net.
emulation
3. Commercial cloud
platform
Network Emulation
WINLAB
MF Service API

Analysis of today’s most used API (Berkeley Sockets):

Based on end-to-end communication
 Tightly bound to the TCP/IP services
 Scarce support for mobility
 Scarce support for data retrieval and service access

What should a new API provide?





High flexibility for lower layers innovation and expansion
Provide full support for architecture services
Unbinding the API level from the transport layer
Choosing the right transport service to use basing the decision on the user intent
Abstracting the communication interface from the network architecture
WINLAB
MF Android Mobile Client
App 2
App 1
App ...
MF JAVA Client API
E2E Transport
Protocol A
E2E Transport
Protocol B

GUID Service Layer

Storage-Aware Routing (GSTAR)

Hop-by-Hop Block Transport Protocol
Link Layer A
(e.g. WIFI)
Link Layer B
(e.g. WIMAX)

JAVA (Android) and C
(Linux) API prototype
Usable with ARM based
Android devices
Multihoming capabilities for
WiMAX enabled devices
Distributed as a system
library and jar library for
easiness of deployment in
Android SDK based
applications
WINLAB
MF Service Examples
Content
location
Content
location
Content
location
WiFi AP
WiFi AP
WiMAX BTS
send(message, “Destination_GUID”, “MULTIHOME”)
Multihoming exploiting:
•Using all the resources from different
interfaces
•Mobility reliability without the need of
complex systems
get(“Content_GUID”,
“ANYCAST”)
Content retrieval from best server:
•No need of specifying the content location
•Exploit of network services (i.e. ANYCAST)
WINLAB
MF Prototype: DMap GNRS
Main Server Components:
 Longest Prefix – IPv4, BGP
announced namespace



Hashing - Java SE
(MD5/SHA)
Networking - Apache MINA
(IPv4+UDP)


Prefix Trie
Custom JNI for MF Routing
Record Storage - Java SE
(Map)

Berkeley DB/SQL
Prototype Activities: MF Click Router
Lightweight, scalable multicast
• GNRS for maintenance of
multicast memberships
• Heuristic approaches to
reduce network load, limit
duplicated buffering, and
improve aggregate delivery
delays
• Click prototype, with SID for
multicast flows
• Evaluating hail a cab
application as a example
multipoint delivery scenario
99
Multicast
Inter-Domain
(EIR)
WINLAB
MF Prototype in OpenFlow-based SDN




Protocol stack embedded within controller
Label switching, NA or GUID-based routing (incl. GNRS lookup)
Controllers interact with other controllers and network support
services such as GNRS
Flow rule is set up for the remaining packets in the chunk based on
Hop ID (which is inserted as a VLAN tag in all packets)
E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101
=> OUT PORT = 16
100
MF Protocol Stack
WINLAB
Layer 2 Switching Options for MF
Byrav Ramamurthy (UNL), Kiran Nagaraja (Rutgers) and students

Layer 2 switching using OpenFlow

Dynamic forwarding table updates
 Centralized network-wide knowledge
 Flow abstraction

Layer 2 switching in MobilityFirst

One or more MobilityFirst GSTAR routers can be bypassed (for specific flows)
 Currently investigating: for which traffic can this be done? for how long should a
L2 circuit exist? integration with GUID tunneling.

Optical switching: similar to Layer 2 switching but
accomplished using ROADM and OTN switches.
WINLAB
MF FPGA Router Prototype

Designing Architecture and hardware (RTL) for NetFPGA
platform to prototype Mobility First router

Supporting 4 Gigabit Ethernet Channels, standard 1500 Ethernet packets.
 Supporting 2 DMA Channels for Host packet transfer (over PCI bus).
 Designed to be configurable through Host computer
 Designed for Fast NA (2-level cache) and GUID lookups.

Evaluating different lookup strategies for GUID and NA

2-level caches (BCAM for L 1 and SRAM for L2)
 Compare and contrast of hardware Binary heap search Vs hardware Bloom
Filters for L2 cache.
NetFPGA – 1st Generation:
Xilinx Virtex-II Pro 50
4 x 1Gbps bi-directional ports
SRAM: 4.5 MB DDR2 DRAM: 64MB
WINLAB
FPGA Router: Flat Identifier Lookup in Hardware
The Output Port Lookup performs
simultaneous lookups of GUID and NAs.
NA lookup uses two level cache (BCAM for
L1 and external SRAM for L2).
BCAM + FPGA Block RAM to store <GUID,
MAC, Port>
Packet is held in a small buffer until the output port is resolved. If
GUID is matched, and packet needs to be routed to the local network,
destination MAC address is updated immediately. If the packet should
be routed to the global network, MAC addresses are updated at the
output queues because a packet may have to be sent out from
multiple output ports.
Prototype Deployment on GENI Testbed
(GEC-12 Recap)
Washington
Physical Topology
Wisconsin
BBN
NLR
Seattle
Indiana
MF Routers at 7 campuses across
US on ProtoGENI hosts
Layer2 links: Internet2 & NLR
backbones, OpenFlow switches
Edge networks: WiFi and WiMAX
access at BBN & Rutgers



NLR
Denver
NLR
SUNW
NLR
Chicago
I2
New York
Rutgers
Clemson
I2
Los Angeles
I2
Washington
Georgia Tech.
I2
Atlanta
Stanford
I2
Houston
I2 OF Switch
VLAN 3715
NLR OF Switch
VLAN 3716
Edge OF Switch
NA
DATA
DATA
Content
Subscriber
DATA
DATA
WiFi AP
Robust Content Delivery
•
•
•
Dual-homed mobile subscriber with WiFi + WiMAX
Adapt to disconnection and variable link quality (GSTAR)
Dual-homed delivery
WiFi AP
DATA
GUID & SID
DATA
DATA
Content
Publisher WiMAX BTS
BBN Wireless Edge
104
WiMAX BTS
ProtoGENI Backbone
Rutgers Wireless Edge
WINLAB
Multi-Site MF Deployment (InProgress)
NLR
Madison, WI
Cambridge, MA
Ann Arbor, MI
Lincoln, NE
Palo Alto, CA
N. Brunswick, NJ
Salt Lake, UT
Tokyo, Japan
I2
Los Angeles, CA
Clemson, SC
Atlanta, GA
Houston, TX
MobilityFirst Routing
and Name Resolution
Service Sites
Long-term (non-GENI)
MobilityFirst Access Net
ProtoGENI
Short-term
Wide Area ProtoGENI
WINLAB
Emulated Topology
Madison, WI
Palo Alto, CA
Salt Lake, UT
Cambridge, MA
Ann Arbor, MI
Lincoln, NE
New Brunswick, NJ
Tokyo, Japan
Los Angeles, CA
Clemson, SC
Atlanta, GA
Houston, TX
MobilityFirst Routing
and Name Resolution
Service Sites
Long-term (non-GENI)
MobilityFirst Access Net
ProtoGENI
Short-term
Wide Area ProtoGENI
WINLAB