MobilityFirst Project Update NSF Meeting March 11, 2013 D. Raychaudhuri WINLAB, Rutgers University ray@winlab.rutgers.edu 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 Architecture Update Arun Venkataramani 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 Segmented layer transport Management plane Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions WINLAB 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(publickey) permits bilateral authentication GUID flexibly identifies principals: interface, device, person, group, service, network, etc. WINLAB 6 Architecture: Global name service Global name service GUID NA Name certification Name resolution: Auspice, DMap GUIDNA2 Content storage & retrieval Context & M2M services Service migration data NA1 NA2 WINLAB 7 Global name service: Content retrieval Global name service Name certification Name resolution: Auspice, DMap Content storage & retrieval Context & M2M services Service migration WINLAB 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) WINLAB 9 Global name service: Content retrieval Global name service Name certification Name resolution: Auspice, DMap Content storage & retrieval Context & M2M services Service migration WINLAB 10 Indirection and grouping Indirection: D1 D2 Grouping: D {D1, D2, …, Dk} Indirection and grouping enable context-aware services, content mobility, and group mobility WINLAB 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 CAID1members(CAID){T1, T2, …, Tk} GNRS T1 T2 Tk WINLAB 12 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 Segmented layer transport Management plane Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions WINLAB 13 Architecture: Scaling interdomain routing Function: Route to GUID@NA Scale: Millions of NA’s huge forwarding tables send(GUID@NA, data) Network … … … … … … … NA1… Interfac … e 2 NA3 NA2 … 6 NA3 1 NA4 … … … 2 … NA2 … … … … NA1 … … … … NA108 WINLAB 14 Architecture: Scaling interdomain routing Function: Route to GUID@NA scalably Approach: Core and edge networks to reduce state Global name service X1 Few interdomain routing design efforts X2 maturing 1. 2. 3. X3 X2,T4 Vnode + pathlet routing + link-state + telescoping updates data Bloom routing Core-edge routing with *-cast through name service T1 T2 T3 T4 T5 T6 GUID WINLAB 15 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 Segmented layer transport Management plane Key insight: Logically centralized global name service enhances mobility, security, and network-layer function WINLAB 16 Architecture: Computing layer Programmable computing layer enables service flexibility and evolvability Virtual Service Provider 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 17 Content Caching Computing layer CPU Privacy routing Storage Packet forwarding/routing anon ...... anon ...... 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 Segmented layer transport Management plane Key insight: Logically centralized global name service enhances mobility, security, and network-layer function WINLAB 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 Segmented layer transport Management plane Key insight: Logically centralized global name service enhances mobility, security, and network-layer function WINLAB 19 Architecture: Why logically centralized? Indirection-based Logically centralized Network-layer WINLAB 20 Auspice GNRS Arun Venkataramani, Emmanuel Cecchet Global name service as geo-distributed keyvalue store value(s) resolve(GUID,…) Global name service GUID: { {NAs:[[X1,T1],[X2,T2],…}, {geoloc:[lat, long]}, {TE_prefs: [“prefer WiFi”,…]}, {ACL: {whitelist: […]}}, … } WINLAB 22 Auspice design goals 1. 2. 3. 4. 5. Low response time: Replicas of each name’s resolver should be placed close to querying end-users Low update cost: Number of resolver replicas should be limited to reduce replica consistency overhead Load balance: Placement of replicas across all names should prevent load hotspots at any single site Availability: Sufficient number of replicas so as to ensure availability amidst crash or malicious faults Consistency: Each name resolver’s consistency requirements must be preserved WINLAB 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 WINLAB Auspice resolver replica placement Locality-aware Load-aware 25 Auspice resolver placement engine Replica controllers X X X Migrate replicas Active replicas X Load reports X X Mapping algorithm + Paxos to compute active replica locations X X First request for name X X X Locality-aware, load-aware, consistent Typical request for name X to nearby active replica End-hosts or local name servers WINLAB Auspice service migration (in-progress) Paxos create_replica(.) shutdown_replica(.) migrate_replica(.) Paxos report_load(.) Sequentia l consisten cy America Europe Paxos Asia Paxos WINLAB 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 Near-beta version deployed on eight geo-distributed Amazon EC2 locations [GUID, NA], [GUID, IP], [name, IP] Extensive evaluation on larger clusters and PlanetLab settings Mobile socket library for seamless mid-session client and server migration WINLAB 28 Auspice vs. alternate proposals WINLAB 29 Auspice vs. commercial managed DNS WINLAB 30 Application scenario: Emergency geo-cast Demo by Emmanuel Cecchet WINLAB 31 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 52 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 56 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 57 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 58 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 59 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 [63] 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 S2T1, T1P1..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 66 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 [73] 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 [75] WINLAB Functional View of NCRS & GNRS [76] 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 [77] 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. [78] 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 [79]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 [85] 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 86 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 92 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 93 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 97 WiMAX BTS ProtoGENI Backbone Rutgers Wireless Edge WINLAB Multi-Site MF Deployment (InProgress) NL R Cambridge, MA Madison, WI Ann Arbor, MI Lincoln, NE Palo Alto, CA N. Brunswick, NJ Salt Lake, UT Tokyo, Japan I2 Los Angeles, CA Atlanta, GA Clemson, SC Houston, TX MobilityFirst Routing and Name Resolution Service Sites MobilityFirst Access Net Long-term (nonGENI) Short-term Wide Area ProtoGENI ProtoGENI WINLAB Emulated Topology Cambridge, MA Madison, WI Ann Arbor, MI Salt Lake, UT Lincoln, NE Palo Alto, CA New Brunswick, NJ Tokyo, Japan Los Angeles, CA Clemson, Atlanta, GA SC Houston, TX MobilityFirst Routing and Name Resolution Service Sites MobilityFirst Access Net Long-term (nonGENI) Short-term Wide Area ProtoGENI ProtoGENI WINLAB