Mobility First Future Internet Architecture ECE 544 Lec

Mobility. First Future Internet Architecture ECE 544 Lec 10 April 24, 2015 D. Raychaudhuri WINLAB, Rutgers University ray@winlab. rutgers. edu

Next-Gen Network Requirements

Mobility. First Project: Background n n Mobility. First project started in 2010 under NSF FIA, continuing under FIA-NP Project team: Rutgers, UMass, Michigan, Wisconsin, Duke, MIT, Nebraska Clean-slate architecture motivated by fundamental shift of Internet services to mobile platforms ~10 B in 2020! Use cases: Vehicular Networks Content Delivery Cloud Services Mobile Data (cellular, hetnet) Emergency Networks Internet-of-Things WINLAB

Next-Generation Wireless Network Requirements Fast growth in mobile data accelerating cellular-Internet convergence …. . 100 B+ Wireless Devices Cloud Services Heterogeneous Technologies multihoming Seamless Integration - Wide-Area Internet Dynamic spectrum - Access Network High. Speed ~Gbps radio Strong Security/Privacy Local cache/ cloud Low end-to-end latency Key requirements: Scale/Capacity (100 B+) Speed (Gbps+) Latency (<10 ms) Integrated mobility Multipath, multicast, multihoming. . Robustness/DTN Context-aware Energy aware. . others Content Services Global Mobility WINLAB

Next-Gen Network Requirements: – (1) Mobility § End-point mobility as a basic service of the future Internet § Any network connected object or device should be reachable on an efficiently routed path as it migrates from one network to another § Requirements similar to mobile IP in the Internet today and authentication, handoff/roaming in cellular networks § Mobility service should be scalable (billions of devices) and fast ~50 -100 ms Wireless Access Net #3 INTERNET Wireless Access Network #2 BS 2 User/Device Mobility WINLAB

Next-Gen Network Requirements : – (2) Handling Disconnection & BW Variation n Wireless medium has inherent fluctuations in bit-rate (as much as 10: 1 in 4 G access), heterogeneity and disconnection Poses a fundamental protocol design challenge ¨ New requirements include in-network storage/delay tolerant delivery, dynamic rerouting (late binding), etc. ¨ Transport layer implications end-to-end TCP vs. hop-by-hop ¨ Mobile devices with varying BW due to SNR variation, Shared media access and heterogeneous technologies Bit Rate (Mbps) Disconnect BS-1 Wireless Access Net #3 Disconnection interval INTERNET Time Wireless Access Network #2 AP-2 WINLAB AP-2

Next-Gen Network Requirements: – (3) Multicast as a Basic Service n n n Many mobility services (content, context) involve multicast The wireless medium is inherently multicast, making it possible to reach multiple end-user devices with a single transmission Fine-grain packet level multicast desirable at network routers Packet-level Multicast at Routers/AP’s/BSs Session level Multicast Overlay (e. g. PIM-SIM) Pkt Mcast at Routers Wireless Access Net #11 Access Network (Eithernet) INTERNET RP Wireless Access Net #32 Radio Broadcast Medium WINLAB

Next-Gen Network Requirements : – (4) Multi-Homing as a Standard Feature n Multiple/heterogeneous radio access technologies (e. g. 4 G/5 G and Wi. Fi) increasingly the norm Improved service quality via path diversity ¨ Supports improved throughput in hetnet (Wi. Fi/small cell + cellular) scenarios ¨ Can also be used to realize ultra-high bit-rate services using multiple networks ¨ Multihomed devices may utilize two or more interfaces to improve communications quality/cost, with policies such as “deliver on best interface” or “deliver only on Wi. Fi” or “deliver on all interfaces” LTE BS 60 Ghz BS (supplement to LTE) Wireless Access Net #3 INTERNET Wireless Access Network #2 Wi. Fi AP Mobile device With dual-radio NICs WINLAB

Next-Gen Network Requirements: Multi. Network Access n n n Wired Internet devices typically have a single Ethernet interface associated with a static network/AS In contrast, mobile devices typically have ~2 -3 radios and can see ~5 -10 distinct networks/AS’s at any given location Basic property - multiple paths to a single destination leads to fundamentally different routing, both intra and inter domain! Mobile device with multi-path reachability BS-1 Single “virtual link” in wired Internet Wireless Access Net #1 BS-2 Wireless Access Network Wireless Access Net #3 Access Network (Eithernet) INTERNET BS-3 INTERNET Ethernet Ni. C Wireless Edge Network AP 1 Multi Radio NIC’s WINLAB Multiple Potential Paths

Next-Gen Network Requirements: – (5) Efficient Content Retrieval n n n Delivery of content to/from mobile devices a key service requirement in future networks (…”ICN”, etc. ) This requirement currently served by overlay CDN’s In-network support for content addressability and caching is desirable service primitives such as get(content-ID, . . ) In-network cache Content Owner’s Server Send(“content_ID”, “user_ID”)) Alternative paths for retrieval or delivery Get (“content_ID”) WINLAB

Next-Gen Network Requirements: – (6) Context-Aware Services n Context-aware delivery often associated with mobile services Examples of context are group membership, location, network state, … ¨ Requires framework for defining and addressing context (e. g. “taxis in New Brunswick”) ¨ Anycast and multicast services for message delivery to dynamic group ¨ Context = geo-coordinates & first_responder Send (context, data) Context Naming Service Context GUID Global Name Resolution service NA 1: P 7, NA 1: P 9, NA 2, P 21, . . ba 123 341 x Context-based Multicast delivery Mobile Device trajectory WINLAB

Next-Gen Network Requirements: – (7) Edge Peering and Ad Hoc Networks n n n Wireless devices can form ad hoc networks with or without connectivity to the core Internet These ad hoc networks may also be mobile and may be capable of peering along the edge Requires rethinking of interdomain routing, trust model, etc. Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility Access Network ) INTERNET ) WINLAB

Next-Gen Network Requirements: – (8) Spectrum Management n n As more and more data is carried by unlicensed wireless networks, spectrum coordination should be offered as a network service Management plane offers global visibility for cooperative setting of radio resource parameters across independent access networks Wi. Fi AP locations in a 0. 4 x 0. 5 sq. mile area in Manhattan, NY Network Management Plane Interface for Radio Parameter Map (e. g. Frequency, Power, Rate, . . ) Inter-network spectrum coordination procedures WINLAB

Mobility. First Protocol Design

Mobility. First Design: Architecture Features Named devices, content, and context Strong authentication, privacy 11001101011100100… 0011 Public Key Based Global Identifier (GUID) Human-readable name Heterogeneous Wireless Access End-Point mobility with multi-homing In-network content cache Storage-aware Intra-domain routing Mobility. First Protocol Design Goals: - Service API with unicast, multi-homing, mcast, anycast, content query, etc. Routers with Integrated Storage & Computing 10 B+ mobile/wireless devices Mobility as a basic service BW variation & disconnection tolerance Ad-hoc edge networks & network mobility Multihoming, multipath, multicast Content & context-aware services Strong security/trust and privacy model Edge-aware Inter-domain routing Hop-by-hop file transport Connectionless Packet Switched Network with hybrid name/address routing Network Mobility & Disconnected Mode Ad-hoc p 2 p mode WINLAB

Mobility. First Design: Technology Solution Name Certification Service (NCS) Flexible name-based network service layer Global Name Resolution Service (GNRS) Hybrid GUID/NA Global Routing (Edge-aware, mobile, Late binding, etc. ) Name-Based Services (mobility, mcast, content, context, M 2 M) Storage-Aware & DTN Routing (GSTAR) in Edge Networks Optional Compute Layer Plug-Ins Meta-level Network Services (cache, privacy, etc. ) Hop-by-Hop Transport (w/bypass option) Core Transport Services Pure connectionless packet switching with in-network storage WINLAB

MF Design: Protocol Stack App 1 App 2 App 3 App 4 E 2 E TP 3 E 2 E TP 4 Socket API Name Certification & Assignment Service NCS E 2 E TP 1 E 2 E TP 2 Optional Compute Layer Plug-In A Global Name Resolution Service GNRS MF Routing Control Protocol GUID Service Layer GSTAR Routing MF Inter-Domain Hop-by-Hop Block Transfer Link Layer 1 (802. 11) Control Plane Link Layer 2 (LTE) Narrow Waist Link Layer 3 (Ethernet) IP Switching Option Link Layer 4 (SONET) Link Layer 5 (etc. ) Data Plane WINLAB

MF Design: Name-Address Separation GUIDs n Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects Sue’s_mobile_2 n User name, device ID, content, context, AS name, and so on ¨ Multiple domain-specific naming services Server_1234 John’s _laptop_1 ¨ n n 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 ¨ Network address Net 1. local_ID Taxis in NB Net 2. local_ID WINLAB

MF Protocol Example: Mobility Service via Name Resolution at Device End-Points Service API capabilities: - send (GUID, options, data) Options = anycast, mcast, time, . . - get (content_GUID, options) Options = nearest, all, . . Register “John Smith 22’s devices” with NCS Name Certification Services (NCS) GUID assigned GUID lookup from directory NA 99 Mobility. First Network (Data Plane) Send (GUID = 11011. . 011, SID=01, data) GUID <-> NA lookup GNRS query Send (GUID = 11011. . 011, SID=01, NA 99, NA 32, data) GNRS update (after link-layer association) NA 32 GNRS GUID = 11011. . 011 Represents network object with 2 devices DATA GUID SID NAs Packet sent out by host WINLAB

MF Protocol Design: Realizing the GNRS n 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) ¨ Internet Scale Simulation Results Using DIMES database WINLAB

MF Protocol Design: Storage-Aware Routing (GSTAR) n n n 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 Wi. Fi link Sample CNF routing result WINLAB

MF Protocol Design: Edge-Aware Inter. Domain Routing (EIR) n EIR designed to better support new MF requirements such as late binding, multi-homing, edge peering, network mobility… Design based on a. Nodes and v. Links which allow AS owners considerable flexibility in aggregating and exposing network resources and transit paths ¨ Routing protocol uses telescopic NSP (network state packet) forwarding to provide full graph information while maintaining low control overhead ¨ NSP contains aggregated link properties such as BW, availability, variability, . . ¨ Label-based cut-through routing of transit traffic and enforcement of local policy ¨ Network State Packet (NSP) WINLAB

MF Protocol Design: Hybrid GUID/NA Storage Router in Mobility. First n Hybrid name-address based routing in Mobility. First requires a new router design with in-network storage and two lookup tables: n n n “Virtual DHT” table for GUID-to-NA lookup as needed Conventional NA-to-port # forwarding table for “fast path” Also, enhanced routing algorithm for store/forward decisions GUID –based forwarding (slow path) GUID-Address Mapping – virtual DHT table Look up GUID-NA table when: - no NAs in pkt header - encapsulated GUID - delivery failure or expired NA entry GUID NA 11001. . 11 NA 99, 32 DATA To NA 11 Router Storage DATA SID GUID= 11001… 11 NA 99, NA 32 To NA 51 Store when: - Poor short-term path quality - Delivery failure, no NA entry - GNRS query failure - etc. NA Forwarding Table – stored physically at router Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry Dest NA Port #, Next Hop NA 99 Port 5, NA 11 NA 62 Port 5, NA 11 Port 7, NA 51 NA 32 Network Address Based Forwarding (fast path) DATA WINLAB

MF Protocol Example: Handling Disconnection Store-and-forward mobility service example DATA GUID NA 99 rebind to NA 75 Delivery failure at NA 99 due to device mobility Router stores & periodically checks GNRS binding Deliver to new network NA 75 when GNRS updates NA 99 Disconnection interval Data Plane Device mobility NA 75 DATA GUID NA 75 SID NA 99 DATA GUID Send data file to “John Smith 22’s laptop”, SID= 11 (unicast, mobile delivery) WINLAB

GNRS + Storage Routing Performance Result for Wi. Fi Scenario n n n Detailed NS 3 Simulations to compare MF with TCP/IP Hotspot AP Deployment: Includes gaps and overlaps Cars move according to realistic traces & request browsing type traffic (req. size: 10 KB to 5 MB) WINLAB

MF Protocol Example: Dual Homing Service Multihoming service example DATA Router bifurcates PDU to NA 99 & NA 32 (no GUID resolution needed) GUID Net. Addr= NA 99 Data Plane NA 32 DATA GUID Net. Addr= NA 32 SID GUID= 11001… 11 NA 99, NA 32 DATA GUID Send data file to “John Smith 22’s laptop”, SID= 129 (multihoming – all interfaces) WINLAB

Example Dual-Homing Result for MF: Cellular LTE + Wi. Fi Performance Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing Dual-Homed Mobile Device (Wi. FI + LTE) Mobility. First network evaluation for dual-homing • Parametric analysis of best interface vs. dual homing • Link delay, data rate and download size varied • Soft threshold to stripe across both interfaces or use best WINLAB

MF Protocol Example: Enhanced CDN Service Using Compute Layer Feature Enhanced service example – content delivery with in-network caching & transcoding GUID=13247. . 99 NA 31 MF Compute Layer with Content Cache Service plug-in NA 43 GUID=13247. . 99 Content cache at mobile Operator’s network – NA 99 Filter on SID=128 GUID=13247. . 99 NA 99 GNRS query Returns list: NA 99, 31, 22, 43 NA 29 GNRS Query GUID=13247. . 99 Content file NA 22 Content Owner’s Server Data fetch from NA 99 Mobile’s GUID Data fetch from NA 43 Get (content_GUID, SID=128 - cache service) Get (content_GUID) Query User mobility GUID=13247. . 99 SID=128 (enhanced service) WINLAB

MF Context Example: Geo-Tag Messaging Application (GEC 18, Oct 2013) n Context: Location L; messages dropped at L; phones that dropped message at L n Location L is a geo fence, and captured by a context GUID: GL n GNRS mappings for GL enable advanced messaging operations ¨ Example 1 : ‘Send message to Location L’ : received by all phones bound to location L ¨ Example 2 : ‘Get messages dropped for Location L’ : requested received by all phones that dropped a message at L n Not an overlay or hosted service n Devices: HTC Evo 4 G, Samsung 4 G (GSII/Epic Touch), with Wi. Fi and Wi. MAX radios n Software: Android 2. 3. x/4. x, Mobility. First Protocol Stack and Network Service API Drop Message @L Pickup Messages @L WINLAB

Mobility. First Protocol Prototyping & Validation

Mobility. First Router Implementation Early Dev. Inter-Domain User-level Processes R 3 Locality-Aware DNS GSTAR DMap – Di. HT Routing Name Resolution Packet. Cloud Framework Compute Services Host Rx Q Click Packet Classifier Rx Q Block Aggregator Service Classifier Mgmt. Host Tx Q To/From Host Forwarding Engine Content Cache Service Forwarding Table To Next-hop Lookup Rsrc Control Block Segmentor Tx Q Next-hop Look up Wired and wireless i/f Integrate Hold buffer x 86 hardware and runtime WINLAB 31

Mobility. First Host Protocol Stack ‘Socket’ API open send_to recv_from close App-1 App-2 Linux PC/laptop with Wi. MAX & Wi. Fi App-3 Context API Network API Context Services E 2 E Transport GUID Services Network Layer Security Sensors Android device with Wi. MAX & Wi. Fi Routing User policies Interface Manager ‘Hop’ Link Transport Early Dev. Wi. Fi Integrate Wi. MAX Device: HTC Evo 4 G, Android v 2. 3 (rooted), NDK (C++ dev) WINLAB 32

Evaluation Strategy for Mobility. First Architecture WINLAB ORBIT Radio Grid Emulator GENI Open Cellular Campus Testbeds Opnet or ns Simulator GENI Core Network Science Wide Area MF Network 3 Scale Routing & GNRS Validation 3 Open. Flow MF Controller 4 Service demos & Real World Users 2 1 E MF val n atio ges Sta u Math models SDN/SDR Sandbox in ORBIT USRP/GNU Radio USRP 2 Degree of Realism 3 rd Gen CR Platforms WINLAB Early Adopter Trials (MF-NP)

Mobility. First Deployment on GENI n Long running MF “slice” in GENI to validate routing and name resolution and to run real-world applications on mobile devices (in wireless coverage areas) NLR Madison, WI Ann Arbor, MI Lincoln, NE Palo Alto, CA N. Brunswick, NJ Salt Lake, UT Tokyo, Japan Los Angeles, CA Cambridge, MA I 2 Atlanta, GA Mobility. First Routing and Name Resolution Service Sites Mobility. First Access Clemson, SC Long-term (non. GENI) Short-term Wide Area Proto. GENI WINLAB

GEC-12 Demo: Named Content Delivery in MF NA Content Publisher Content Subscriber DATA GUID=3 Wi. Fi AP DATA GUID & SID GUID=5 Bridge GUID=1 GUID=2 Wi. Fi AP GUID=6 GUID=7 GUID=201 GUID=4 GUID=101 Wi. MAX BTS BBN Wireless Edge Proto. GENI Backbone Rutgers Wireless Edge NLR path using VLANs 3716, 3799 (Clemson) I 2 path using VLANs 3715, 3745(BBN), 3798 (Clemson) 35 Proto. GENI host running MF Router, GNRS Server WINLAB

GEC-13 Demo: Mobility & Multi-Homing in MF Mobile, Multi-homed device (Wi. MAX + Wi. Fi) pg 33@Georgia. Tech pg 50@Rutgers pc 1@BBN Wi. Fi AP pc 11@BBN pg 51@Rutgers Wi. MAX BTS GENI Mesoscale Mobility. First Router hosted on Protogeni node Rutgers Wireless Edge Wi. Fi coverage Wi. MAX coverage WINLAB 36

GENI 18 Demo: Wide-Area Deployment of MF n MF Routing and Naming Services deployed at 5 GENI rack sites with Internet 2’s AL 2 S providing cross-site layer-2 connectivity n Rutgers and NYU Poly (with rack at NYU) routers connected to Wi. Fi and Wi. MAX access networks n Android phones with Wi. Fi/Wi. MAX connectivity ran MF stack and demo application (Drop It) Wisconsin GENI rack Utah GEN I rack GENI Internet 2 Core BBN GENI rack GENI Edge Wi. MAX BTS GENI Edge Mobility. First Software Router with GNRS instance Dual interface Android phone with Wi. Fi/Wi. MAX with MF protocol stack ORBIT radio node with Wi. Fi as MF Access point 12/25/2021 WINLAB, Rutgers University WINLAB 37

GEC-21 Demo: In-Network Computing Feature in MF Sample “mobile cloud” service scenario: Adaptive media transcoding via MF compute layer Name-based anycast service via MF routing Low Res HD User 1 Internet Mid User 2 Original source Media transcoding via MF compute layer WINLAB 38

Resources n Project website: http: //mobilityfirst. winlab. rutgers. edu n GENI website: www. geni. net n ORBIT website: www. orbit-lab. org WINLAB