MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet NIKSUN WWSMC July 26, 2011 Contact: D. Raychaudhuri, 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 A. Venkataramani, J. Kurose, D. Towsley M. Reiter S. Bannerjee W. Lehr Z. Morley Mao B. Ramamurthy X. Yang, R. RoyChowdhury G. Chen Project Funded by the US National Science Foundation (NSF) + Also industrial R&D collaborations with AT&T Labs, Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others
Architecture Summary
MobilityFirst 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 Internet-connected PC s in 2010 Mobile data growing exponentially Cisco white paper predicts >1exabyte per month (surpassing wired PC traffic) by 2012 Sensor deployment just starting, ~5-10B units by 2020 ~1B server/pc s, ~700M smart phones ~2B servers/pc s, ~10B notebooks, PDA s, smart phones, sensors Wireless Edge Network INTERNET INTERNET Wireless Edge Network ~2010 ~2020
MobilityFirst : High-Level Design Goals Mobility-centric design Migration of 10B network-attached objects (devices, content, users, ) Robustness in presence of channel impairments & disconnections Support for network mobility & dynamic network-of-networks formation Socket API s designed explicitly for mobility use cases: multicast, anycast, context- or location-aware delivery, etc. ( service innovation at the edge) Strong security and privacy Standard security services (authentication, secrecy, confidentiality, nonrepudiation,..) built into architecture Resistance to common IP network attacks, e.g. address hijacking, DDoS,.. Network protocols designed to be resilient against failures/attacks No single root of trust, flexible trust domains/mechanisms No per-flow state, low control overhead No signaling, reduced end-to-end chatter (back to packet switching basics..)
MobilityFirst: Protocol Highlights Separation of naming and addressing Clear distinction between identify of network-attached endpoint and net addr Name () = self-certifying public key; address = flat NA Multiplicity of name assignment and trust management services encourages specialization & competition High-level services for managing content, context, network trust, etc Fast global name resolution service (GNRS) Integral part of network protocol, resolves NA in ~100 ms Hybrid /NA routing with self-defining packets NA routing for fast path; late binding routing for advanced services Multicast/anycast as the norm with unicast as special case In-network storage and computing options at routers Seamless integration of switching, storage and DTN modes Hop-by-hop (or segment-by-segment) transport vs. end-to-end TCP
Architecture Concepts: Name-Address Separation Separation of names (ID) from network addresses (NA) Globally unique name () for network attached objects User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services Global Name Resolution for NA mappings Hybrid /NA approach Both name/address headers in PDU Fast path when NA is available resolution, late binding option Sue s_mobile_2 Network address Net1.local_ID John s _laptop_1 Host Naming Server_1234 Sensor Naming Sensor@XYZ Media File_ABC Globally Unique Flat Identifier () Network Content Naming Global Name Resolution Net2.local_ID Context Naming Taxis in NB
Architecture Concepts: Global Name Resolution Fast Global Name Resolution a central feature of architecture <-> network address & port number (also called locator ) mappings Distributed service, possibly hosted directly on routers Fast updates ~50-100 ms to support dynamic mobility can scale to ~10B names via P2P/DHT techniques, Moore s law Mobile node trajectory Network NA2 Registration update Host NA2 Data Plane AP Network NA1 Host NA1 Initial registration Global Name- Address Resolution Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network Name, Context_ID or Content_ID Network Address
Architecture Concepts: 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/disconnected) Storage has benefits for wired networks as well.. Temporary Storage at Router Initial Routing Path Low BW cellular link PDU Storage Router Re-routed path For delivery Mobile Device trajectory High BW WiFi link Sample CNF routing result
Architecture Concepts: Segmented Transport Segment-by-segment transport between routers with storage, in contrast to end-to-end TCP used today Unit of transport (PDU) is a content file or max size fragment Hop TP provides improved throughput for time-varying wireless links, and also helps deal with disconnections Also supports content caching, location services, etc. PDU Segmented (Hop-by-Hop TP) Hop #1 Hop #2 Hop #3 BS Hop-by-Hop Transport Storage Router Temporarily Stored PDU Optical Router (no storage) Low BW cellular link Hop #4 GID/ Hdr Mux Hdr More details of TP layer fragments with addl mux header Data Frag 1 Data Frag 2 Data Frag n Net Address Hdr
Architecture Concepts: 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 mapped to NA by GNRS Similar mechanism used to handle named content Context = geo-coordinates & first_responder Send (context, data) Context Naming Context Global Name Resolution service ba123 341x NA1:P7, NA1:P9, NA2,P21,.. Context-based Multicast delivery Mobile Device trajectory
Protocol Design: Packet Headers and Forwarding with Hybrid GIUD/NetAddr Hybrid scheme in which packet headers contain both the object name () and topological address (NA) routing NA header used for fast path, with fallback to resolution where needed Enables flexibility for multicast, anycast and other late binding services Name-GID Mapping Name server@winlab xy17519bbd Optional list of NA s - Destination NA - Source route - Intermediate NA - Partial source route based forwarding (slow path) GID-Address Mapping NA xz1756.. Net 1194 GID/ Header / Header / Header NA Header NA Header PDU with Header only PDU with and NA headers Data Object (100B-1GB) Header Components Routing Table Dest NA Path Net 123 Net11, net2,.. /Public Key Hash SID ( Identifier) Network Address Based Routing (fast path)
Use Cases: /Address Routing Scenarios Dual Homing The combination of 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 NA1:PA22; NA7:PA13 Data Plane Router bifurcates PDU to NA1 & NA7 (no resolution needed) Net 1 Net 7 DATA NetAddr= NA1.PA22 Alice s laptop = xxx Dual-homed mobile device DATA NA1:PA22; NA7:PA13 DATA NetAddr= NA7.PA13 DATA Send data file to Alice s laptop Current network addresses provided by GNRS; NA1:PA22 ; NA7:PA13
Use Cases: /Address Routing Scenarios Handling Disconnection Intermittent disconnection scenario below uses based redirection (late binding) by router to new point of attachment DATA NetAddr= NA1.PA9 - Delivery failure PDU Stored in router - resolution for redirection DAT A Mobility Trajectory Net 1 Disconnected Region Data Plane Net 7 DATA DATA Send data file to Alice s laptop NetAddr= NA1.PA7 Current network address provided by GNRS; NA1 network part; PA9 port address DATA NetAddr= NA7.PA3 Successful redelivery after connection
Use Cases: /Address Routing Scenarios Multicast/Anycast/Geocast Multicast scenario below also uses <-> Network Address resolution (latebinding) at a router closer to destination (.. tunnel) Late <-> addr Binding at NA1 DATA NetAddr=NA1:PA1,PA2,PA9; NA7,PA22 Port 1 NetAddr=NA1,PA1 NetAddr=NA1,PA2 Net 1 Port 2 Net 7 Port 22 DATA = mcast group Send data file to students DATA NetAddr= NA1 Intermediate network address NA1 provided by GNRS NetAddr=NA7,PA22
Security Considerations: Public keys names for hosts & networks; forms basis for Ensuring accountability of traffic Ubiquitous access-control infrastructure Secure routing; no address hijacking Emphasis on achieving robust performance under network stress or failure Byzantine fault tolerance as a goal Transform malicious attacks into benign failure Performance observability (in management plane) Intentional receipt policies at networks and end-user nodes Every MF node can revert to level to check authenticity, add filters,.. No globally trusted root for naming or addressing Opens naming to innovation to combat naming-related abuses Removes obstacles to adoption of secure routing protocols
Security Considerations: Trust Model Host Naming X = public Key Content Naming Y Context Naming Y GNRS Other Naming s TBD Network Naming B Network Naming A Name assignment & certification services (..can incorporate various kinds of trust including CA, group membership, reputation, etc Secure Host Name Lookup Secure GNRS Update <-> NA binding NET NA7 Secure InterNetwork Routing Protocol Secure Network Name Lookup NET NA1 NET NA33 NA 14 Aggregate NA166: NA14, NA88, NA 33 NA 51 NA 99 NA 88 Secure Data Path Protocol Public Key object and network names enable us to build secure protocols for each interface shown
Privacy Considerations: Public keys as addresses enable their use as pseudonyms Can be changed frequently by end-users to interfere with profiling Flat-label PKI addresses provide an additional layer of routing privacy Openness in naming & addressing introduces competition on grounds of privacy E.g., enable retrieval of mappings in a privacy-preserving way Virtual service provider framework can optionally provide enhanced support for privacy E.g., constant-rate traffic between routers to defeat traffic analysis Route transparency and selection supports user choice on privacy grounds
Prototyping & Evaluation
MobilityFirst Prototyping: Phased Approach Context Addressi ng Stack Content Addressi ng Stack Host/Device Addressing Stack Encoding/Certifying Layer Global Name Resolution (GNRS) Storage Aware Routing Locator-X Routing (e.g., -based) Context-Aware / Late-bind Routing Simulation/Emulation Standalone Components Emulation/Limited Testbed Evaluation Platform Cross Layer Integration Prototyping Status Testbed/ Live Deployment Deployment ready
MobilityFirst Prototyping: Multi-site Exptl Network using GENI Infrastructure Multi-site GENI campus networks used for real-world evaluation of MF protocol during final stage of evaluation in year 3 Involves realistic applications and opt-in users with both Linux PC s or Android mobile devices MF protocol as a long-running slice on GENI network MFA Router Software Typical campus Network To GENI/I2 Backbone Campus Testbed Open WiMAX/3G Base Station Campus sites Duke Rutgers OpenFlow + Blade Server Router Platform UMass Wisconsin End-user Android mobile Phones or Linux netbooks with WiMax and WiFi MFA Client Software GENI Spiral 1 connectivity (figure courtesy of GPO at BBN Technologies)
MobilityFirst Prototyping: ORBIT Grid & WiMax Testbeds for Wireless Edge Evaluation Multi-radio indoor and outdoor nodes - WiMAX, WiFi, Linux-based Click implementation of routing protocols
MobilityFirst Prototyping: Software Router Linux-based software router with two-level implementation MF App s Portable user-level implementation OpenFlow Controller MF Name Resolution MF Routing & Mgmt. User-Level Control Plane Quagga XORP OpenFlow switch host Forwarding Engine Linux routing Click Commodity Hardware NetFPGA 23
MobilityFirst Evaluation: GENI Deployment Plan (Phase 3) Domain-1 Legend s Wireless Edge (4G & WiFI) Router Wireless Edge (4G & WiFI) Opt-in users Domain-2 Full MF Stack at routers, BS, etc. Router Router Inter-domain mobility Router Domain-3 Router Wireless Egde (4G & WiFI) Intra-domain mobility Router Internet 2 National Lambda Rail OpenFLow Backbones OpenFlow WiMAX ShadowNet 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 24
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.)