D. Raychaudhuri WINLAB, Rutgers University ray@winlab.rutgers.edu MobilityFirst Future Internet Architecture ECE544 Lec 10 April 24, 2015 D. Raychaudhuri WINLAB, Rutgers University ray@winlab.rutgers.edu

Next-Gen Network Requirements

MobilityFirst Project: Background MobilityFirst 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  ~10B in 2020! Use cases: Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. Content Delivery Vehicular Networks Cloud Services Mobile Data (cellular, hetnet) Emergency Networks Internet-of-Things

Next-Generation Wireless Network Requirements Fast growth in mobile data accelerating cellular-Internet convergence ….. 100B+ Wireless Devices Cloud Services Heterogeneous Technologies Seamless Integration multi- homing Key requirements: Scale/Capacity (100B+) Speed (Gbps+) Latency (<10ms) Integrated mobility Multipath, multicast, multihoming .. Robustness/DTN Context-aware Energy aware ..others Wide-Area Internet Dynamic spectrum Access Network Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. High-Speed ~Gbps radio Local cache/ cloud Low end-to-end latency Content Services Global Mobility Strong Security/Privacy

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 INTERNET Wireless Access Net #3 Access Network #2 BS2 User/Device Mobility Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.

Next-Gen Network Requirements : – (2) Handling Disconnection & BW Variation Wireless medium has inherent fluctuations in bit-rate (as much as 10:1 in 4G 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 Dis- connect AP-2 Bit Rate (Mbps) BS-1 BS-1 Wireless Access Net #3 INTERNET Time Disconnection interval Wireless Access Network #2 AP-2

Next-Gen Network Requirements: – (3) Multicast as a Basic Service 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 INTERNET Session level Multicast Overlay (e.g. PIM-SIM) Wireless Access Net #11 Access Network (Eithernet) Radio Broadcast Medium Packet-level Multicast at Routers/AP’s/BSs RP Access Net #32 Pkt Mcast at Routers

Next-Gen Network Requirements : – (4) Multi-Homing as a Standard Feature Multiple/heterogeneous radio access technologies (e.g. 4G/5G and WiFi) increasingly the norm Improved service quality via path diversity Supports improved throughput in hetnet (WiFi/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 WiFi” or “deliver on all interfaces” LTE BS 60 Ghz BS (supplement to LTE) Wireless Access Net #3 INTERNET Wireless Access Network #2 WiFi AP Mobile device With dual-radio NICs

Next-Gen Network Requirements: Multi-Network Access 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 Single “virtual link” in wired Internet BS-1 Wireless Access Net #1 Wireless Access Network BS-2 Wireless Access Net #3 INTERNET INTERNET Access Network (Eithernet) BS-3 Multiple Potential Paths Wireless Edge Network Ethernet NiC AP1 Multi Radio NIC’s

Next-Gen Network Requirements: – (5) Efficient Content Retrieval 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 In-network cache Alternative paths for retrieval or delivery Content Owner’s Server Send(“content_ID”, “user_ID”)) Get (“content_ID”)

Next-Gen Network Requirements: – (6) Context-Aware Services 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 Global Name Resolution service NA1:P7, NA1:P9, NA2,P21, .. Context GUID ba123 341x Context-based Multicast delivery Mobile Device trajectory

Next-Gen Network Requirements: – (7) Edge Peering and Ad Hoc Networks 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 INTERNET Access Network Access Network ) )

Next-Gen Network Requirements: – (8) Spectrum Management 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 WiFi AP locations in a 0.4x0.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

MobilityFirst Protocol Design

MobilityFirst Design: Architecture Features Named devices, content, and context Strong authentication, privacy Human-readable name 11001101011100100…0011 Public Key Based Global Identifier (GUID) Routers with Integrated Storage & Computing Service API with unicast, multi-homing, mcast, anycast, content query, etc. Heterogeneous Wireless Access End-Point mobility with multi-homing In-network content cache Storage-aware Intra-domain routing Edge-aware Inter-domain routing Hop-by-hop file transport MobilityFirst Protocol Design Goals: 10B+ 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 Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. Connectionless Packet Switched Network with hybrid name/address routing Network Mobility & Disconnected Mode Ad-hoc p2p mode

MobilityFirst Design: Technology Solution Name Certification Service (NCS) Flexible name-based network service layer Global Name Resolution Service (GNRS) Name-Based Services (mobility, mcast, content, context, M2M) Optional Compute Layer Plug-Ins (cache, privacy, etc.) Meta-level Network Services Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. Hybrid GUID/NA Global Routing (Edge-aware, mobile, Late binding, etc.) Storage-Aware & DTN Routing (GSTAR) in Edge Networks Hop-by-Hop Transport (w/bypass option) Core Transport Services Pure connectionless packet switching with in-network storage

MF Design: Protocol Stack App 1 App 2 App 3 App 4 Socket API Name Certification & Assignment Service NCS E2E TP1 E2E TP2 E2E TP3 E2E TP4 Optional Compute Layer Plug-In A Global Name Resolution Service GNRS GUID Service Layer Narrow Waist MF Routing Control Protocol GSTAR Routing MF Inter-Domain IP Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. Hop-by-Hop Block Transfer Switching Option Link Layer 1 (802.11) Link Layer 2 (LTE) Link Layer 3 (Ethernet) Link Layer 4 (SONET) Link Layer 5 (etc.) Control Plane Data Plane

MF Design: Name-Address Separation  GUIDs Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services Global Name Resolution Service for GUID  NA mappings Hybrid GUID/NA approach Both name/address headers in PDU “Fast path” when NA is available GUID resolution, late binding option Sue’s_mobile_2 Server_1234 Media File_ABC Taxis in NB John’s _laptop_1 Sensor@XYZ 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

MobilityFirst Network 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 Smith22’s devices” with NCS Name Certification Services (NCS) GUID assigned GUID lookup from directory NA99 GNRS update (after link-layer association) MobilityFirst Network (Data Plane) Send (GUID = 11011..011, SID=01, data) NA32 GNRS GUID <-> NA lookup Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. GNRS query GUID = 11011..011 Represents network object with 2 devices Send (GUID = 11011..011, SID=01, NA99, NA32, data) DATA GUID SID NAs Packet sent out by host

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

MF 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

MF Protocol Design: Edge-Aware Inter-Domain Routing (EIR) EIR designed to better support new MF requirements such as late binding, multi-homing, edge peering, network mobility… Design based on aNodes and vLinks 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)

MF Protocol Design: Hybrid GUID/NA Storage Router in MobilityFirst Hybrid name-address based routing in MobilityFirst requires a new router design with in-network storage and two lookup tables: “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-Address Mapping – virtual DHT table NA Forwarding Table – stored physically at router GUID NA 11001..11 NA99,32 Dest NA Port #, Next Hop NA99 Port 5, NA11 GUID –based forwarding (slow path) Network Address Based Forwarding (fast path) Router Storage Store when: Poor short-term path quality Delivery failure, no NA entry GNRS query failure etc. NA32 Port 7, NA51 DATA SID GUID= 11001…11 NA99,NA32 NA62 To NA11 To NA51 Look up GUID-NA table when: - no NAs in pkt header - encapsulated GUID - delivery failure or expired NA entry Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry

MF Protocol Example: Handling Disconnection Store-and-forward mobility service example DATA GUID NA99  rebind to NA75 Delivery failure at NA99 due to device mobility Router stores & periodically checks GNRS binding Deliver to new network NA75 when GNRS updates NA99 Disconnection interval Device mobility Data Plane NA75 Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. DATA DATA GUID NA75 GUID SID NA99 DATA GUID SID Send data file to “John Smith22’s laptop”, SID= 11 (unicast, mobile delivery)

GNRS + Storage Routing Performance Result for WiFi Scenario Detailed NS3 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: 10KB to 5MB)

MF Protocol Example: Dual Homing Service Multihoming service example DATA DATA Router bifurcates PDU to NA99 & NA32 (no GUID resolution needed) GUID NetAddr= NA99 NA99 Data Plane NA32 Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide. DATA DATA GUID NetAddr= NA32 GUID= 11001…11 SID NA99,NA32 DATA GUID SID Send data file to “John Smith22’s laptop”, SID= 129 (multihoming – all interfaces)

Example Dual-Homing Result for MF: Cellular LTE + WiFi Performance Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing Dual-Homed Mobile Device (WiFI + LTE) MobilityFirst 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

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

MF Context Example: Geo-Tag Messaging Application (GEC18, Oct 2013) Context: Location L; messages dropped at L; phones that dropped message at L Location L is a geo fence, and captured by a context GUID: GL 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 Not an overlay or hosted service Devices: HTC Evo 4G, Samsung 4G (GSII/Epic Touch), with WiFi and WiMAX radios Software: Android 2.3.x/4.x, MobilityFirst Protocol Stack and Network Service API Drop Message @L Pickup Messages @L

MobilityFirst Protocol Prototyping & Validation

MobilityFirst Router Implementation Early Dev. Inter-Domain Integrate R3 Locality-Aware DNS GSTAR DMap – DiHT PacketCloud Framework User-level Processes Routing Name Resolution Compute Services Content Cache Service Mgmt. Click Forwarding Engine Host Rx Q Host Tx Q Wired and wireless i/f To/From Host To Next-hop Lookup Rsrc Control Wired and wireless i/f Forwarding Table Packet Classifier Block Aggregator Service Classifier Block Segmentor Rx Q Tx Q Next-hop Look up Hold buffer x86 hardware and runtime

MobilityFirst Host Protocol Stack ‘Socket’ API open send send_to recv recv_from close App-1 App-2 Context API App-3 Context Services Sensors Linux PC/laptop with WiMAX & WiFi Network API E2E Transport GUID Services Network Layer Android device with WiMAX & WiFi Security Routing User policies Interface Manager ‘Hop’ Link Transport Early Dev. WiFi WiMAX Integrate Device: HTC Evo 4G, Android v2.3 (rooted), NDK (C++ dev)

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

MobilityFirst Deployment on GENI 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) Salt Lake, UT Cambridge, MA N. Brunswick, NJ Ann Arbor, MI Madison, WI Tokyo, Japan Lincoln, NE Los Angeles, CA 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

GEC-12 Demo: Named Content Delivery in MF DATA Content Publisher Content Subscriber GUID=3 GUID=5 WiFi AP WiFi AP Bridge GUID=6 GUID=1 GUID & SID DATA GUID=7 GUID=2 GUID=4 GUID=201 WiMAX BTS GUID=101 WiMAX BTS BBN Wireless Edge ProtoGENI Backbone Rutgers Wireless Edge NLR path using VLANs 3716, 3799 (Clemson) I2 path using VLANs 3715, 3745(BBN), 3798 (Clemson) ProtoGENI host running MF Router, GNRS Server

GEC-13 Demo: Mobility & Multi-Homing in MF Mobile, Multi-homed device (WiMAX + WiFi) pg33@GeorgiaTech pg50@Rutgers pc1@BBN WiFi AP pc11@BBN pg51@Rutgers WiMAX BTS GENI Mesoscale MobilityFirst Router hosted on Protogeni node Rutgers Wireless Edge WiFi coverage WiMAX coverage

GENI 18 Demo: Wide-Area Deployment of MF MF Routing and Naming Services deployed at 5 GENI rack sites with Internet2’s AL2S providing cross-site layer-2 connectivity Rutgers and NYU Poly (with rack at NYU) routers connected to WiFi and WiMAX access networks Android phones with WiFi/WiMAX connectivity ran MF stack and demo application (Drop It) Wisconsin GENI rack Utah GENI rack BBN GENI rack GENI Internet2 Core GENI Edge WiMAX BTS WiMAX BTS MobilityFirst Software Router with GNRS instance Dual interface Android phone with WiFi/WiMAX with MF protocol stack ORBIT radio node with WiFi as MF Access point 11/24/2018 WINLAB, Rutgers University

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 User1 Internet Mid Mid User2 Original source Media transcoding via MF compute layer

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