MobilityFirst Project Update NSF Meeting March 11, 2013

MobilityFirst Project UpdateNSF MeetingMarch 11, 2013

D. RaychaudhuriWINLAB, Rutgers University

[email protected]

mailto:[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 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

MobilityFirst: High-level Architectural Updates

Arun Venkataramani

4

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


Architecture: Global name service

Global name service

Name certification

Name resolution: Auspice, DMap


Service migration


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


Architecture: Global name service

Global name service

Name certification



Service migration


GUID NA

NA1 NA2

GUID

NA 1

resolve(GUID)

data

GUIDNA2

GUID

NA 1

GUID

NA 2

7

http://www.radiolabs.com/images/products/wireless-laptop-antenna.jpg


Name certification



Service migration


Global name service: Content retrieval

Global name service

8


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


Name certification



Service migration


Global name service: Content retrieval

Global name service

10


Indirection and grouping Indirection: D1 D2

Grouping: D {D1, D2, …, Dk}

Indirection and grouping enable context-aware services, content mobility, and group mobility

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

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




Global name service

Name certification

Name resolution


Service migration




Segmented transport

Computing layer

Management plane

16


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 InterfaceNA1 2

NA2 6

NA3 1

NA4 2

…

…

NA108

17


Architecture: Scaling interdomain routing Function: Route to GUID@NA scalably Approach: Core and edge networks to reduce state

T1 T2 T3

T4 T5T6

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





Global name service

Name certification

Name resolution


Service migration




Segmented transport

Computing layer

Management plane

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

...... ......

Packet forwarding/routing

Computing layer CPU Storage

Virtual ServiceProvider

ContentCaching

Privacyrouting

anon anon

21




Global name service

Name certification

Name resolution


Service migration




Segmented transport

Computing layer

Management plane

22




Global name service

Name certification

Name resolution


Service migration




Segmented transport

Computing layer

Management plane

24


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


Global name service as geo-distributed key-value store

28

Global name servicereso

lve(GU

ID,…)

valu

e(s)

GUID: { {NAs:[[X1,T1],[X2,T2],…},{geoloc:[lat, long]},{TE_prefs: [“prefer WiFi”,…]},{ACL: {whitelist: […]}},…}

resolve(GUID,…)

value(s)


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


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


Auspice resolver replica placement

31

Locality-aware Load-aware


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


PaxosPaxos

PaxosPaxos

Sequential consistency

Lineariazability

create_replica(.)shutdown_replica(.)migrate_replica(.)

America Europe Asia

report_load(.)

Auspice service migration (in-progress)


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


Auspice vs. alternate proposals

35


Auspice vs. commercial managed DNS

36


Application scenario: Emergency geo-cast

Demo by Emmanuel Cecchet http://youtu.be/EfDaqs0uuBY

37

http://youtu.be/EfDaqs0uuBY




Questions? http://www.cs.umass.edu/~arun/MobilityFirst

38

Global Name Resolution Services Through Direct Mapping (DMAP)Yanyong Zhang

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 1

K=2

AS 101

GUID AS#10 1

K=3AS 200

GUID AS#10 1

Local replica

Capturing Locality


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

Plural RoutingZ. Morley Mao

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

Edge-Aware Inter-Domain RoutingTam Vu, D. Raychaudhuri

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)

Per

cent

of l

ost p

acke

ts (%

)

Early bindingLate bindingSender

ReceiverMobile Trajectory

EIR Routers

EIR Routers

EIR Routers

EIR Routers

EIR Routers

PacketCloud Compute LayerYang Chen, Xiaowei Yang

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

Wireless/Mobile Use CaseRoy Yates, Bill Lehr

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 implementationC-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

Cum

ulat

ive

Dis

tribu

tion

Func

tion

(CD

F)

Cell Radius = 250 mCell 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)

Tota

l Dat

a R

ecei

ved

(MB

ytes

) 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

MobilityFirstTCP/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)

Agg

rega

te T

hrou

ghpu

t (M

Byt

es)

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)

M2M Use CaseJun Li, Rich Martin

[70]

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)


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


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


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



Evaluation – MF compare to conventional - avoiding bottlenecks while retaining controls

Sensor Gateway M2M 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


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 HeimlicherJim KuroseDon TowsleyArun 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)



ßß

ß

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/

Mobility First: Security DiscussionsWade Trappe

[80]

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

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:

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

Name AddressList

Timestamps

Policy

Cryptographic Package

Name Authentication Token

Cryptographic Package

Update Query

Mobility Services Engine: A Measurement Framework for the MobilityFirst ArchitectureSuman BanerjeeUniversity 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

Mobility First Prototyping & GENI DeploymentKiran Nagaraja

[92]

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 SwitchVLAN 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

Documents

MobilityFirst Project Update NSF Meeting March 11, 2013