MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Concept Summary – Oct 2011 Contact: D. Raychaudhuri WINLAB, Rutgers University Technology Centre of NJ 671 Route 1, North Brunswick, NJ 08902, USA ray@winlab.rutgers.edu MobilityFirst Project: Collaborating Institutions (LEAD) D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson M. Reiter A. Venkataramani, J. Kurose, D. Towsley S. Bannerjee W. Lehr Z. Morley Mao B. Ramamurthy X. Yang, R. RoyChowdhury G. Chen Project Funded by the US National Science Foundation (NSF) Under the Future Internet Architecture (FIA) Program, CISE + Also industrial R&D collaborations with AT&T Labs, Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others WINLAB Vision: Mobility as the key driver for the future Internet Historic shift from PC’s to mobile computing and embedded devices… ~4 B cell phones vs. ~1B PC’s in 2010 Mobile data growing exponentially – Cisco white paper predicts 3.6 Exabytes by 2014, significantly exceeding wired Internet traffic Sensor/IoT/V2V just starting, ~5-10B units by 2020 ~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors ~1B server/PC’s, ~700M smart phones INTERNET Wireles s Edge Networ k INTERNET Wireless Edge Network ~2010 ~2020 WINLAB Vision: Protocol Design for the future Mobile/Wireless World Fundamental change in design goals and assumptions ~10B+ mobile/wireless end-points as “first-class” Internet devices Mobility as the norm for end-points and access networks Wireless access – varying link BW/quality, multiple radios, disconnections Stronger security/trust/robustness requirements due to: open radio medium need for dynamic trust association for mobile devices/users/data/networks increased privacy concerns (e.g. location tracking) greater potential for network failure Mobile applications involve location/content/context and energy constraints Technology has also changed a lot in the ~40 yrs since IP was designed Moore’s law improvements in computing and storage (~5-6 orders-ofmagnitude gain in cost performance since 1970) Edge/core disparity, fast fiber but continuing shortage of radio spectrum WINLAB Architecture: MobilityFirst Network Overview MF Arch designed to meet emerging mobile/wireless service requirements at scale Key MF protocol features: Separation of naming & addressing Public-key globally unique identifier (GUID) and flat network address (NA) Storage-aware (GDTN) routing Multicast, multipath, anycast services Flexible inter-domain boundaries and aggregation level Early binding/late binding options Hop-by-hop (segmented) transport Support for content & context Strong security and privacy model Separate mgmt & computing layers Several new protocol components, very distinct from today’s TCP/IP …. MobilityFirst Router with Integrated Computing & Storage Computing Blade Buffer Storage Forwarding Engine Hop-by-Hop Transport Core Network (flat label routing) Base Station GDTN Routing Data block AP Wireless Router Router Data Plane Global Name Resolution Service Name <-> PKI address mapping Control & Management Plane WINLAB Architecture: MobilityFirst Service Abstractions MobilityFirst API proposes a new multipoint/multipath/time delivery abstraction that reflects the intrinsic broadcast & multi-homing nature of the wireless medium along with in-network storage Replaces the communication link abstraction provided by IP … IP Abstraction: Virtual Link MF Abstraction: Network Object Group with broadcast reachability MF Abstraction: Network Object with multipath reachability Send(IP=X, data) Send(GUID=Y, data, options) ..options for mpath & time delivery Network IP Addr=X Interface Dest Device Name= MAC NA=X1 NA=X2 Send(GUID=Z, data, options) ..option for mcast delivery NA=X3 NA=X2 Static MAC=X binding GUID=Y Network Attached Object Dynamic GUID – NA bindings Broadcast Medium Group GUID = Z GUID1 GUID2 WINLAB GUID3 Architecture Concepts: Name-Address Separation Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects Sue’s_mobile_2 User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services Server_1234 John’s _laptop_1 Host Naming Service Media File_ABC Sensor@XYZ Sensor Naming Service Content Naming Service Context Naming Service Globally Unique Flat Identifier (GUID) Global Name Resolution Service for GUID NA mappings Global Name Resolution Service Network Hybrid GUID/NA approach Both name/address headers in PDU “Fast path” when NA is available GUID resolution, late binding option Net2.local_ID Network address Net1.local_ID Taxis in NB WINLAB Architecture Concepts: Global Name Resolution Service for Dynamic Name <-> Address Binding Fast Global Name Resolution a central feature of architecture GUID <-> network address (NA) mappings Distributed service, possibly hosted directly on routers Fast updates ~50-100 ms to support dynamic mobility Service can scale to ~10B names via P2P/DHT techniques, Moore’s law Host GUID Registration update Network – NA2 NA2 Mobile node trajectory Data Plane AP Network – NA1 Host GUID Initial registration Global NameAddress Resolution Service Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network NA1 Host Name, Context_ID or Content_ID Network Address WINLAB Protocol Design: Direct Hash GNRS Fast GNRS implementation based on DHT between routers GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID) Results in distributed in-network directory with fast access (~100 ms) 1 0.9 Cumulative Distribution Function (CDF) 0.8 0.7 K = 5, 95 th Percentile at 91 ms K = 1, 95 th Percentile at 202 ms 0.6 0.5 0.4 0.3 K K K K K 0.2 0.1 0 10 20 50 100 Round Trip Query Latency in milliseconds (log scale) Internet Scale Simulation Results Using DIMES database WINLAB = = = = = 1 2 3 4 5 1,000 Architecture Concepts: MobilityFirst Routing Design Goals Routing protocol should seamlessly support a wide range of usage scenarios, from wired mobile ad hoc DTN Device, content and network mobility Heterogeneous devices and radio access Robustness to varying BW, disconnection Dynamic network formation & flexible boundaries Core 4G Connectivity Wired Wireless Mesh / Cellular Mobile Ad-Hoc DTN WINLAB Architecture Concepts: Exploiting InNetwork Storage for Routing Take advantage of cheap storage in the network (storage-aware routing) ~10GB, in-network storage ~1TB, content caching Expands routing options ~100MB, data in transit Store and/or replicate as feasible routing options Enables “late binding” routing algorithms Hop-by-hop transport Large blocks reliably transferred at link layer Entire block can be stored or cached at each router Generalized Storage-Aware Routing • Actively monitor link qualities of network • Router store or forward decision based on: 1. Short and long term link qualities 2. Available storage along path 3. Connectivity to destination Protocol Design: Storage-Aware Routing (GSTAR) Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection Routing algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/short disconnection) to DTN (longer disconnections) Storage has benefits for wired networks as well.. Temporary Storage at Router Initial Routing Path Low BW cellular link Re-routed path For delivery Mobile Device trajectory PDU Storage Router High BW WiFi link Sample CNF routing result WINLAB Protocol Design: Content Delivery in MobilityFirst Content delivery handled efficiently by proposed MF architecture “Content objects” identified by unique GUID Multiple instances of content file identified by GNRS via GUID to NA mapping Routing protocol used for “reverse anycast” to nearest content object Approach differs from NDN/CCN, where content attributes are carried in packet headers MF uses content GUID naming service & GNRS to keep things general and avoid interpreting content semantics inside network Content Store #2 GUID=13247..99 GUID=13247..99 NA43 NA31 GUID=13247..99 NA29 GNRS Query NA99 Content cache at mobile Operator’s network – NA99 Data fetch from NA99 GNRS query Returns list: NA99,31,22,43 GUID=13247..99 NA22 Content Store #1 (owner) Data fetch from NA43 Get (content_GUID) User mobility Get (content_GUID) WINLAB Protocol Design: Context Aware Delivery Context-aware network services supported by MF architecture Dynamic mapping of structured context or content label by global name service Context attributes include location, time, person/group, network state Context naming service provides multicast GUID – mapped to NA by GNRS Similar to mechanism used to handle named content Context = geo-coordinates & first_responder Send (context, data) Context Naming Service Context GUID Global Name Resolution service NA1:P7, NA1:P9, NA2,P21, .. ba123 341x Context-based Multicast delivery Mobile Device trajectory WINLAB Protocol Design: MF Stack Core elements of MF protocol stack GUID services layer, supported by control protocols for bootstrap & updates GUID to network address mapping (GNRS) for dynamic mapping of GUID Generalized storage-aware routing (GSTAR) with supporting control protocols Reliable hop-by-hop block transfer between routers Management plane protocol with its own routing scheme Multiple TP options and plug-in programmable services at GUID layer APP-2 APP-1 Name Certification Service A Mgmt Apps Routing Apps Management Plane Protocols (incl. routing) Routing Control Protocols E2E Transport Protocol A GUID Services Control Protocols E2E Transport Protocol B APP-n …….. E2E Transport Protocol B Computing Layer Service Plug-ins GUID Service Layer GUID-to-Net Address Mapping Storage-Aware Routing (GSTAR) Hop-by-hop Block Transfer Protocol Link Layer A (e.g fiber) Link Layer B (e.g LTE) Link Layer C (e.g WiFi) Link Layer D (e.g Ethernet WINLAB Example 1: GUID/Address Routing Scenarios – Dual Homing The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location … Dual-homing scenario below allows for multiple NA:PA’s per name DATA GUID NA1:PA22; NA7:PA13 Router bifurcates PDU to NA1 & NA7 (no GUID resolution needed) GUID DATA NetAddr= NA1.PA22 Net 1 Alice’s laptop GUID = xxx Data Plane Net 7 Dual-homed mobile device DATA DATA GUID NetAddr= NA7.PA13 GUID/SID NA1:PA22; NA7:PA13 DATA GUID & SID Send data file to “Alice’s laptop” Current network addresses provided by GNRS; NA1:PA22 ; NA7:PA13 WINLAB Example 2: GUID/Address Routing Scenarios – Handling Disconnection Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment DATA GUID NetAddr= NA1.PA9 - Delivery failure PDU Stored in router - GUID resolution for redirection DAT A GUID Mobility Trajectory Net 1 Data Plane Disconnected Region Net 7 DATA GUID DATA NetAddr= NA1.PA7 GUID DATA GUID/SID Send data file to “Alice’s laptop” Current network address provided by GNRS; NA1 – network part; PA9 – port address NetAddr= NA7.PA3 Successful redelivery after connection WINLAB MobilityFirst Prototyping: Phased Approach Content Addressi ng Stack Context Addressi ng Stack Host/Device Addressing Stack Encoding/Certifying Layer Global Name Resolution Service (GNRS) Storage Aware Routing Locator-X Routing (e.g., GUID-based) Context-Aware / Late-bind Routing Simulation/Emulation Emulation/Limited Testbed Testbed/‘Live’ Deployment Evaluation Platform Standalone Components System Integration Deployment ready Prototyping Status WINLAB MobilityFirst Prototyping: GENI Deployment Plan (Phase 3) Legend Domain-1 Services Internet 2 National Lambda Rail Domain-3 Domain-2 OpenFLow Backbones OpenFlow Full MF Stack at routers, BS, etc. Wireless Edge (4G & WiFI) WiMAX ShadowNet Router Wireless Egde (4G & WiFI) Router Wireless Edge (4G & WiFI) Router Router Intra-domain mobility Router Opt-in users Router Inter-domain mobility Mapping onto GENI Infrastructure ProtoGENI nodes, OpenFlow switches, GENI Racks, WiMAX/outdoor ORBIT nodes, DieselNet bus, etc. Deployment Target: • Large scale, multi-site • Mobility centric • Realistic, live WINLAB 19 MobilityFirst Prototype: Multi-Site GENI Demo (GEC12, ~4Q2011) Edge networks NA-1, NA-2 connected to global core Each of NA-1, NA-2 are contained MF routing domains Each WiMAX BSS and WiFi AP is associated with a MF Router Node a is multi-homed within a network Node c is multi-homed across 2 networks GENI Core NA-1 WiFi AP WiMAX BSS e a MF Router c Android Client w/ WiMAX + WiFi NA-2 Linux PC/laptop w/ WiMAX + WiFi Campus Network (at Rutgers) Vehicular node w/ WiMAX Sensor node d b MF Sensor GW 20 Campus Network (at other GENI site) Resources Project website: http://mobilityfirst.rutgers.edu GENI website: www.geni.net “Emerging Wireless Technologies and the Future Mobile Internet”, Cambridge Press, 2011 – D. Raychaudhuri & M. Gerla (eds.) WINLAB