mobilityfirst project update nsf meeting march 11, 2013 d. raychaudhuri winlab, rutgers university...
TRANSCRIPT
MobilityFirst Project UpdateNSF MeetingMarch 11, 2013
D. Raychaudhuri
WINLAB, Rutgers University
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 real-
world end-users and applications
Introduction: Meeting Agenda
Time Topic Presenter10:00-10:10 Introduction and comments from NSF Darleen Fisher, Bryan Lyles, Ray10:10-10:25 High-level MF architecture updates Arun Venkataramani, Ray10:25-10:40 GNRS design #1 and AUSPICE implementation Arun, Emmanuel Cecchet10:40-10:50 GNRS design #2 and DMap implementation Yanyong Zhang10:50-11:00 Bloom routing design & evaluation Morley Mao11:00-11:10 Edge-aware inter-domain routing (EIR) & prototyping Tam Vu11:10-11:20 Computing layer design & prototyping Yang Chen, Xiaowei Yang11:20-11:30 Wireless/mobile use case evaluation & economics Roy Yates, Bill Lehr11:30-11:40 Network mobility, and performance metrics Jim Kurose11:40-11:50 M2M/context use case & prototyping Jun Li, Rich Martin11:50-12:00 Security and Privacy Analysis Wade Trappe, Janne Lindqvist12:00-12:10 Network management design & prototyping Suman Banerjee12:10-12:25 MF Prototyping & GENI deployment Kiran Nagaraja, Ivan Seskar12:25:1:00 Q&A/Discussion 1:00 Adjourn
Draft Agenda
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
Context & M2M services
Service migration
Content storage & retrieval
Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions
Inter-,intra-domain routing
Segmented transport
Computing layer
Management plane
5
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Architecture: Global name service
Global name service
Name certification
Name resolution: Auspice, DMap
Context & M2M services
Service migration
Content storage & retrieval
human_readable_name GUID
“Darleen Fisher’s phone” 1A348F76
self-certifying GUID = hash(public-key) permits bilateral authentication
GUID flexibly identifies principals: interface, device, person, group, service, network, etc.
6
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Architecture: Global name service
Global name service
Name certification
Name resolution: Auspice, DMap
Context & M2M services
Service migration
Content storage & retrieval
GUID NA
NA1 NA2
GUIDNA 1
resolve(GUID)
data
GUIDNA2
GUIDNA 1
GUIDNA 2
7
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Name certification
Name resolution: Auspice, DMap
Context & M2M services
Service migration
Content storage & retrieval
Global name service: Content retrieval
Global name service
8
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Global name service: Content retrieval Content CGUID [NA1, NA2, … ]
• Opportunistic caching + request interception
GNRS
CGUID
[NA 1,NA 2,…]
CGUIDCGUID
CGUID
CGUID
CGUIDCGUID
NA1
NA2
get(CGUID, NA1)
get(CGUID)
9
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Name certification
Name resolution: Auspice, DMap
Context & M2M services
Service migration
Content storage & retrieval
Global name service: Content retrieval
Global name service
10
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Indirection and grouping Indirection: D1 D2
Grouping: D {D1, D2, …, Dk}
Indirection and grouping enable context-aware services, content mobility, and group mobility
11
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
CAID
{T1,T
2,…,T
k}
T1
Tk
T2
send_data(CAID,T1)
send_data(CAID,T2)
send_data(CAID,T3)
CAID1members(CAID){T1, T2, …, Tk}
13
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
Context & M2M services
Service migration
Content storage & retrieval
Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions
Inter-,intra-domain routing
Segmented transport
Computing layer
Management plane
16
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Architecture: Scaling interdomain routing
NA1
NA2
Function: Route to GUID@NA Scale: Millions of NA’s huge forwarding tables
NA3
…
…
…
…
…
…
…
……
……
…
………
…
…
…
……
send(GUID@NA, data)
Network Interface
NA1 2
NA2 6
NA3 1
NA4 2
…
…
NA108
17
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Architecture: Scaling interdomain routing
Function: Route to GUID@NA scalably Approach: Core and edge networks to reduce state
T1 T2 T3
T4 T5
T6
X2 X3X1
Global name service
GUID
[X2,T
4]
GUID
X2,T4
data
Few interdomain routing design efforts maturing1. Vnode + pathlet routing + link-state + telescoping updates2. Bloom routing3. Core-edge routing with *-cast through name service
18
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
Context & M2M services
Service migration
Content storage & retrieval
Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions
Inter-,intra-domain routing
Segmented transport
Computing layer
Management plane
20
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
...... ......
Packet forwarding/routing
Computing layer CPU Storage
Virtual ServiceProvider
ContentCaching
Privacyrouting
anon anon
21
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
Context & M2M services
Service migration
Content storage & retrieval
Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions
Inter-,intra-domain routing
Segmented transport
Computing layer
Management plane
22
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
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
Context & M2M services
Service migration
Content storage & retrieval
Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions
Inter-,intra-domain routing
Segmented transport
Computing layer
Management plane
24
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Architecture: Why logically centralized? Indirection-based Logically centralized Network-layer
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
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Global name service as geo-distributed key-value store
28
Global name serviceresolve(GUID,…)
value(s)
GUID: { {NAs:[[X1,T1],[X2,T2],…},{geoloc:[lat, long]},{TE_prefs: [“prefer WiFi”,…]},{ACL: {whitelist: […]}},…}
resolve(GUID,…)
value(s)
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Auspice design goals1. Low response time: Replicas of each name’s resolver
should be placed close to querying end-users2. Low update cost: Number of resolver replicas should
be limited to reduce replica consistency overhead3. Load balance: Placement of replicas across all names
should prevent load hotspots at any single site4. Availability: Sufficient number of replicas so as to
ensure availability amidst crash or malicious faults5. 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
31
Locality-aware Load-aware
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Replica controllers
Active replicas
X XX
X X
X
X
XX
X
End-hosts or local name servers
First request for name X
Typical request for name X to nearby active replica
Load reports
Locality-aware, load-aware,consistent
Migratereplicas
Mapping algorithm + Paxos to compute active replica locations
Auspice resolver placement engine
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
PaxosPaxos
PaxosPaxos
Sequential consistency
Lineariazability
create_replica(.)shutdown_replica(.)migrate_replica(.)
America Europe Asia
report_load(.)
Auspice service migration (in-progress)
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
34
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Auspice vs. alternate proposals
35
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Auspice vs. commercial managed DNS
36
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Application scenario: Emergency geo-cast
Demo by Emmanuel Cecchet http://youtu.be/EfDaqs0uuBY
37
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science
Questions? http://www.cs.umass.edu/~arun/MobilityFirst
38
WINLAB
Name-Address Separation Through GNRS Globally unique name
(GUID) for network attached objects 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?
Taxis in NB
Globally Unique Flat Identifier (GUID)
John’s _laptop_1
Sue’s_mobile_2
Server_1234
Sensor@XYZ
Media File_ABC
Host NamingService
Network
SensorNamingService
ContentNamingService
Global Name Resolution Service
Network addressNet1.local_ID
Net2.local_ID
ContextNamingService
WINLAB
(00101100……10011001)
Hash Function
GUID
IPx = (44.32.1.153) IP
(+) Strictly 1-overlay-hop lookup No extra routing requirement
(e.g. utilize current BGP)
(-) IP “hole” issues Limited locality
Direct Mapping (DMAP)
WINLAB
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
Value at m=10 is 0.0009
Map of IP (/8) address space (white = unassigned addresses)
Fixing IP Holes for IPv4
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
network address space
used segments
unused segments
(2, 1) (1, 1) (1, 2) (2, 2)
WINLAB
IPx = (44.32.1.153)
Every mapping is replicated at K random locations
Lookups can choose closest among K mappings. Much reduced lookup latencies
K=1
K=2
K=3
Mapping Replication
k Hash Functions
GUID
IP
IP
(00101100……10011001)
IPx = (67.10.12.1) IP
IPx = (8.12.2.3)
WINLAB
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
GUID 10
GUID AS#
10 1
K=1
AS 1
AS 5
GUID AS#
10 1K=2
AS 101
GUID AS#
10 1
K=3
AS 200
GUID AS#
10 1
Local replica
Capturing Locality
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 design: routing table reconstructionA 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 interfaceEvaluation• Scalability
• Routing lookup • Routing table size• Path inflation
• Flexibility• Avoiding intermediate domains• Load balancing
Implementation• Platform
• 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• Milestones
• ORBIT: test on single router• GENI: test on a couple of POPs
WINLAB
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, multi-network 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
Edge-aware Inter-domain Routing (EIR)
WINLAB
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
EIR Mechanisms
WINLAB
SID 3
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
EIR forwarding engine
RIB OSPF w. Telescoping
Link state advsNSP
GNRSd Binding requestSID 2
NextHop Table
SID 1
Data Packets Data Packet
WINLAB
Click-based prototyping on Orbit nodes Message delivery with late binding Storage-aware routing Efficient multicast & multipath data delivery
EIR Prototyping(2)
100 200 300 400 500 600 700 800 900 10000
10
20
30
40
50
60
70
Mobility rate (ms)
Pe
rce
nt o
f lo
st p
ack
ets
(%
)
Early bindingLate bindingSender
ReceiverMobile Trajectory
EIR Routers
EIR Routers
EIR Routers
EIR Routers
EIR Routers
WINLAB
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, games) Proxies in different networks Current practice: delivering servers to ISPs
Telmex
AT&T
WINLAB
PacketCloud: Overview
Cloudlet
Cloudlet
Domain Controller
DC NY
Cloudlets form an elastic resource pool to support in-
network services
59
WINLAB
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 Access Use-case through MobilityFirst MobilityFirst enables a stitched-together architecture for
mobile networks Current Mobile Networks
Wi-Fi ISP 1
ISP 2
ISP 3
GSM/CDMA/LTE
Internet
Global Name Resolution
ServiceMobility Support
Through GNRS
Wireless Cooperation through Geographic Routing
AAA Server
Mobility Management Entity (MME)
GSM/CDMA/LTE
Internet
Control Path Elements
Data Path Elements
Gateway Node
Make-before-break Handover Controlled QoS inside network
• Planned Deployment• Licensed Spectrum• Fine-grained Managed QoS• Centralized Mobility Support• Homogeneous Topology• Network-wide Authentication
MF Network-of-Networks
• Ad-hoc Deployment• Unlicensed Spectrum• Coarse-grained Managed• In-network Mobility Support• Heterogeneous topology• Authentication at APs
WINLAB 63
LTE/4G Cellular Networks
Evolved Packet Core: IP Gigabit Ethernet IP pipes
Between eNBs (basestations) To MME, P-GW, S-GW etc
RAN interconnect: IP Cellular Protocol interfaces
simple IP port implementation
C-Plane
U-Plane
UE
E-UTRAN
eNB
Internet
EvolvedPacket Core
P-GW
S-GWMME
HSS
PCRF
eNBeNB
WINLAB 64
4G/LTE: Modern View
A private IP network Basestations (eNB) Mobility Management (MME) Authentication Gateway
Anchor for public Internet connections
Similar to MobileIP home agent
Internet
UE
E-UTRAN
eNB
EvolvedPacket Core
P-GW
S-GWMME
HSS
PCRF
eNBeNB
65
LTE/M1ST Feature ComparisonLTE Features
(What M1st is missing) Licensed spectrum eNB coordination
Frequency/coverage planning
Private mobility services subscribers only
Business model Monthly subscription
ubiquitous access
M1ST Features
(What LTE/4G is missing)
Transparent Multihoming & Multipath Enabler for heterogeneous
dynamic spectrum access Public mobility services
Ad Hoc Networks Network Mobility
Content & Context
WINLAB
Cellular/LTE M1ST ?
Should/will operators adopt M1st? Incentives:
Outsourced mobility/authentication, M1st new features are useful, perhaps essential
Disincentives: 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:
0 10 20 30 40 50 60 70 80 900
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Number of Updates/second
Cu
mu
lativ
e D
istr
ibu
tion
Fu
nct
ion
(C
DF
)
Cell Radius = 250 m
Cell Radius = 500 mCell Radius = 750 m
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
WINLAB
Wi-Fi roaming with MobilityFirst Quantifying the benefits of in-network mobility management &
storage aware routing
0 50 100 150 2000
20
40
60
80
100
Time (sec)
To
tal D
ata
Re
ceiv
ed
(M
Byt
es) Speed = 30 miles/hr
0 50 100 150 2000
20
40
60
80
100
Time (sec)
Speed = 50 miles/hr
0 50 100 150 2000
20
40
60
80
100
Time (sec)
Speed = 70 miles/hr
MobilityFirst
TCP/IP
• NS3 Simulation with full 802.11 stack, different vehicular speeds & offered load
• Comparing TCP/IP with MF
Transmission of stored packets Throughput Jumps
WINLAB
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
0 20 40 60 80 100 1200
100
200
300
400
500
600
700
800
900
1000
Time (sec)
Ag
gre
ga
te T
hro
ug
hp
ut (
MB
yte
s)
Aggregate Throughput with Time
MobilityFirstTCP/IP
Throughput boost due to transmission of stored packets
TCP takes more time to re-start session (DHCP + Application reset)
WINLABMarch 11, 2013 MobilityFirst Review Meeting
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
boundaries
S1Shared Platform
(hosting, middleware)
A1
A2
AjSensors(Things) Apps
S2
Si
MobilityFirst is a ubiquitous computing platform
Naming server (assign GUIDs)
WINLABMarch 11, 2013 MobilityFirst Review Meeting
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
GNRS: Global Name Resolution Service
Internet (MobilityFirst
)
Sensor S1(temperature
)
M2M / Context (Naming)Server, GUIDAssign & Publish(S1, S2, C1, T1)
S1 -> A1C1 -> NA1
Sensor S2(location)
Actuator C1(air
conditioning)
Application A1
SmartGrid App
Application A2
Presentation
Context T1Conf @WINLAB
Subscriber P1 P2P3
Lookup Context T1Lookup S2, T1 &
Subscribe T1
UPDATE
S2T1, T1P1..P4P1 -> NA2, P2->NA2P3 -> NA2, P4->NA3
NA1
NA4
NA2
NA3
GNRSEntries:
UPDATE
A1 -> NA4
DATA
M2MGateWay
Lookup S1
Lookup S1, C1, subscribe S1
P4DATA
March 11, 2013 MobilityFirst Review Meeting
System Components for M2M/Context Demos
73
WSN Gateway (Android) - MF Client Protocol Stack- WSN Access Point Stack- WSN to MF GW
processing
M2M/Context (naming) Server - Definitions and descriptions- GUID assignment & GNRS update- Subscription management
Native MF Client Stack
mySQL DBApache Server
GW Module(GUID lookup)
GUI (Sensor/Context on Map)
Naming Mod(GUID
assignment)
Service Mod(GUID lookup , Subscription)
TCP/IP
GNRS Module(GUID update)
Sensor / Context Management (add/remove resources)
Web services
Downloadable User-level Appfor Android
Applications (PC) - Lookup a GUID- Subscribe to GUID- Send/Rcv data of
GUID
Native MF Client Stack
Context App(File transport)
GUID lookup & subscription
TCP/IP
Sensor/Actuator App (smartGrid)
Browser / HTTPclient
Java Wrapper
GNRS- Sensor GUID -> App GUID
MF Router Stack
GNRS Caching Computing
Click Router
Native MF Client Stack
WiFi or 3G/LTESensor Radio
(Proprietary now)
Java USB Driver for Wireless Sensor AP
Java wrap up APIRaw data processing
MF formatting & delivery
Lookup Sensor GUIDs &
description XMLSensor Data Parsing & Collection
GUI/settings
TCP/IP
Gateway
WINLABMarch 11, 2013 MobilityFirst Review Meeting
Evaluation – MF compare to conventional - avoiding bottlenecks while retaining controls
Sensor GatewayM2M Server
AppsWSN Internet Internet
Signaling
Data“bottleneck”
“End-to-end”
Sensor Gateway
M2M Server
AppsWSN Internet
Signaling
Data
MFedge
MFedge
“Hop-by-hop & multicasting”
“Lightweight& Mobile”
“Single copy”
“Multi-copy”Current(3GPP)
MobilityFirst
WINLABMarch 11, 2013 MobilityFirst Review Meeting
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)
Network mobility, and performance metrics
Simon Heimlicher
Jim Kurose
Don Towsley
Arun Venkataramani
WINLAB
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
UMass
128.119.*.*(UMass)
76.119.101.*(Comcast)
174.224/11(VZ Wireless)
mobile home
128.119.*.*(UMass VPN)
174.224/11(VZ Wireless)
174.224/11(VZ Wireless)
ßß
ß
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
Measuring network mobilityIMAP logs UMass CS
Univ logs: IRB needed sample heatmap:
Android app: detect/record/upload network
change traceroute http://iptrack.srvr.ch/
WINLAB
Security Considerations: Trust Model
NET NA1
NET NA7
NET NA33
NA 51 NA 99
NA 14
NA 88
NetworkNamingService
A
NetworkNaming Service
B
GNRS
Aggregate NA166: NA14, NA88, NA 33
HostNamingService
X
ContentNamingService
Y
ContextNamingService
Y
OtherNamingServices
TBD
Secure InterNetworkRouting Protocol
SecureHostName
ServiceLookup
SecureGNRSUpdate
SecureNetwork
NameServiceLookup
SecureData PathProtocol
Name assignment& certification services (..canincorporatevarious kinds oftrust 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
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 two-
tier name resolution service
Ongoing: Access-control within name resolution impacts security and privacy of network services
[82]
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:
Insert (self-certifying) / Certificate request (certificate assignment)
Query Update Revoke
[84]
Example: NCRS Certificate Insert (self-certifying)– Can leverage existing
technologies– Insert certificate using
Kerberos 5 protocol
WINLAB
GNRS Security Concerns
GUID Spoofing 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
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:
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.
Consequence: denial of service[85]
WINLAB
Securing GNRS
[86]
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.
Current Status: Integrated security mechanisms into
GNRS protocol Secure variations of Update and
Query Protocols Identified appropriate cryptographic
parameters that provide efficiency and security together (ECC P-256)
Secure GNRS Update
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
NameAddress
ListTimestamp
sPolic
y
Cryptographic Package
NameAuthentication
Token
Cryptographic Package
Update Query
Mobility Services Engine: A Measurement Framework for the MobilityFirst Architecture
Suman Banerjee
University of Wisconsin-Madison
WINLAB
MSE Architecture
Database Server
Clients
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
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
Throughput (WiMAX) RSSI (WiMAX)
RTT (Cellular) Throughput (Cellular)
Experiments on GENI WiMAX and other infrastructure in Madison, WI
WINLAB
MF Software Router and Host Protocol Stack
93
Click-based MF Router
- Storage-aware routing (GSTAR)- Name resolution server (GNRS)- Reliable hop-by-hop link transport (Hop)
Android/Linux MF Protocol Stack
- Network API- Hop - Dual homing (WiFi/WiMAX)
WiMAX BTS
WiFi AP
Native, user-level implementation on Android runtime
MF Router
MF Router
MF Router
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:
Network Emulation
3. Commercial cloud platform
1. GENI Wide Area Deployment
2. ORBIT lab with net. 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
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
App 2App 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)
WINLAB
MF Service Examples
Content retrieval from best server:
• No need of specifying the content location
• Exploit of network services (i.e. ANYCAST)
WiMAX BTS
WiFi AP
Content location
WiFi AP
Content location
Content location
get(“Content_GUID”, “ANYCAST”)
Multihoming exploiting:
• Using all the resources from different interfaces
• Mobility reliability without the need of complex systems
send(message, “Destination_GUID”, “MULTIHOME”)
MF Prototype: DMap GNRS
Main Server Components: Longest Prefix – IPv4, BGP
announced namespace Prefix Trie
Hashing - Java SE (MD5/SHA)
Networking - Apache MINA (IPv4+UDP) Custom JNI for MF Routing
Record Storage - Java SE (Map) Berkeley DB/SQL
WINLAB
Prototype Activities: MF Click Router
99
Inter-Domain (EIR)
Multicast
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
100WINLAB
MF Prototype in OpenFlow-based SDN
MF Protocol Stack
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
WINLAB
Layer 2 Switching Options for MFByrav 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 504 x 1Gbps bi-directional portsSRAM: 4.5 MB DDR2 DRAM: 64MB
FPGA Router: Flat Identifier Lookup in Hardware
The Output Port Lookup performs simultaneous lookups of GUID and NAs.
BCAM + FPGA Block RAM to store <GUID, MAC, Port>
NA lookup uses two level cache (BCAM for L1 and external SRAM for L2).
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.
104WINLAB
Prototype Deployment on GENI Testbed (GEC-12 Recap)
Physical Topology 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
I 2 Atlanta
I 2 Houston
I 2 Los Angeles
I 2 Washington
I 2 New York
I 2 OF Switch
VLAN 3715
NLR OF Switch
VLAN 3716
NLRChicago
NLRDenver
NLRSeattle
NLRSUNW
Edge OF Switch
Wisconsin
Clemson
Georgia Tech.
Rutgers
BBN
I ndiana
Washington
Stanford
WiMAX BTSWiMAX BTS
WiFi AP
WiFi AP
Rutgers Wireless EdgeBBN Wireless Edge
Content Publisher
Content Subscriber
GUID & SID
DATA
DATA
DATA
DATA
DATA
DATA
NA
DATA
ProtoGENI Backbone
Robust Content Delivery • Dual-homed mobile subscriber with WiFi + WiMAX• Adapt to disconnection and variable link quality (GSTAR)• Dual-homed delivery
WINLAB
Multi-Site MF Deployment (In-Progress)
Salt Lake, UT
Cambridge, MA
N. Brunswick, NJ
Ann Arbor, MIMadison, WI
Tokyo, Japan
Lincoln, NE
Los Angeles, CA
Houston, TX
Clemson, SC
Long-term (non-GENI)
MobilityFirst Access Net
Short-term
Wide Area ProtoGENI
Palo Alto, CA
ProtoGENI
MobilityFirst Routing and Name Resolution Service Sites
I2
NLR
Atlanta, GA
WINLAB
Emulated Topology
Salt Lake, UT
Cambridge, MA
New Brunswick, NJ
Ann Arbor, MIMadison, WI
Tokyo, Japan
Lincoln, NE
Los Angeles, CA
Atlanta, GA
Clemson, SC
Long-term (non-GENI)
MobilityFirst Access Net
Short-term
Wide Area ProtoGENI
ProtoGENI
MobilityFirst Routing and Name Resolution Service Sites
Palo Alto, CA
Houston, TX