Future Internet Architectures (FIA) And GENI Darleen Fisher Program Director Division of Computer & Network Systems Directorate for Computer and Information Science and Engineering National Science Foundation

Outline FIA Vision Future Internet Architecture (FIA) Projects FIA Projects’ Current Ideas about Using GENI Going Forward—What might be next for FIA & GENI?

Future Internet – The Vision Society’s needs for an IT infrastructure may no longer be met by the present trajectory of incremental changes to the current Internet Society needs the research community to create the trustworthy Future Internets that meet the needs and challenges of the 21st Century. Research should include intellectually distinctive ideas, driven by the requirement for long-range concepts unfettered by the current limitations of or the requirement for immediate application to the current Internet. Architecture includes all needed functionalities (overarching architecture). Research on Future Internets create a community better informed and educated about network architecture design

Future Internet Architectures (FIA) NSF issued a call for proposals: To support innovative and creative projects that conceive, design, and evaluate trustworthy Future Internet architectures 4 projects awarded – A diverse portfolio (smaller projects under consideration and expected submit to NeTS Large) http://www.nets-fia.net/

FIA Projects and their View of the Future Mobility First The future is mobile (Cellular, wireless sensors, machine-to-machine, smart grid & vehicular nets integrate physical world awareness and control into Internet applications) NEBULA 24x7 Utility for secure communication, computation and storage Named Data Network (NDN) Content is the future driver eXpressive Internet Architecture (XIA) Design for evolution of: usage (host-host, content retrieval, services) and technology (link, storage, computing) http://www.nets-fia.net/

MobilityFirst Mobility Path disruption tolerance (path redundancy) Principle Investigator: Dipankar Raychaudhuri, Rutgers Collaborating Institutions: Duke Univ., Massachusetts Institute of Technology, Univ. of Massachusetts/Amherst, Univ. of Massachusetts/Lowell, Univ. of Michigan, Univ. of Nebraska/Lincoln, Univ. of North Carolina/Chapel Hill, Univ. of Wisconsin/Madison Underlying architectural principles Mobility is the norm without gateways or overlay accommodations The architecture uses generalized delay-tolerant networking (GDTN) to provide robustness even in presence of link/network disconnections. GDTN integrated with the use of self-certifying public key addresses to provide an inherently trustworthy network. Wired networks special case. http://mobilityfirst.winlab.rutgers.edu Mobility Path disruption tolerance (path redundancy) Delay-tolerant networking

M-F Overview - Component Architecture Location Service Other Application Services Context Addressing Content Addressing Host/Entity Addressing Application Services Encoding/Certifying Layer Global Name Resolution Service (GNRS) Network-Support Services Storage Aware Routing (STAR) Context-Aware / Late-bind Routing Management Link state and Path Measurements Core Network Services Locator-X Routing (e.g., GUID-based) IP Routing (DNS, BGP, IGP) Monitor, Diagnosis and Control

Named Data Networking Content distribution Policy Enforcement Principle Investigator: Lixia Zhang, UCLA Collaborating Institutions: Colorado State University, PARC, Univ. of Arizona, Univ. of Illinois/Urbana-Champaign, UC Irvine, Univ. of Memphis, UC San Diego, Washington Univ., and Yale Univ. Underlying architectural principles Content is what users and applications care about; By naming data not location data become a first-class entity. Packets indicate what (content) , not who/where (IP address) Packet is a <name, data, signature> Securing named data potentially allows trust to be more user-centric. Retain the hourglass in the architecture Separate routing and forwarding http://www.named-data.net/index.htm Content distribution Policy Enforcement Attribution

Named Data Networking (NDN) The architecture retains the hourglass shape Change the thin waist from using IP addresses to using data names Always retrieve data from closest copy on a path to source; use memory for intrinsic multicast distribution IP addresses name locations; retrieving data by names eliminates a fundamental hurdle in mobility support Retrieving data by names facilitates new application development in sensor networking Robust security from per packet signature The new strategy layer enables intelligent data delivery via broadcast, multicast, and multiple paths ISP ISP

NEBULA DP/CP Redundancy Data plane and control plane separation Principle Investigator: Jonathan Smith, Univ. of Penn. Collaborating Institutions: Cornell Univ., Massachusetts Institute of Technology, Princeton Univ., Purdue Univ., Stanford Univ., Stevens Institute of Technology, Univ. of California/Berkley, Univ. of Delaware, Univ. of Illinois/Urbana-Champaign, Univ. of Texas, Univ. of Washington Underlying architectural principles Always-on utility where cloud computing data centers are the primary repositories of data and the primary locus of computation Storage, computation, and applications move into the "cloud“ Data centers are connected by a high-speed, extremely reliable and secure backbone network. Parallel paths between data center and core Secure access and transit, policy-based path selection and authentication during connection establishment http://nebula.cis.upenn.edu/ DP/CP Redundancy Data plane and control plane separation Virtualization Fast, token-based Data plane, feature-rich control plane

NEBULA Architecture NDP (NEBULA Data Plane) distributed multiple-path establishment and policy enforcement NVENT (NEBULA Virtual and Extensible Networking Technologies) extensible control plane Ncore (NEBULA Core) redundancy-connected, high-availability routers

eXpressive Internet Architecture (XIA) Principle Investigator: Peter Steenkiste, Carnegie Mellon Univ. Collaborating Institutions: Boston Univ., Univ. of Wisconsin/Madison Underlying architectural principles XIA offers support for communication between current communicating principals--including hosts, content, and services--while accommodating unknown future principals. For each type of principal, XIA defines a narrow waist that dictates the application programming interface (API) for communication and the network communication mechanisms. XIA enables flexible context-dependent mechanisms for establishing trust between the communicating principals. http://www.cs.cmu.edu/~xia/ API-centric approach (Narrow Waist) Path decisions based on principal type, host, content, service Trustworthy Computing Store-and-forward

XIA Components and Interactions

FIA Projects’ Current Ideas to use GENI Just began September 1, 2010; Are at different levels of maturity; as are Their plans for experimentation and how they might use GENI.

Potential use of GENI in NEBULA* GENI Technology: Enables experiments involving multiple sites Isolates NEBULA experiments to a single VLAN Eliminates need for special HW & Address Translation Potential Uses: Multisite student collaboration on Ncore (NEBULA Core) Testbed for NDP (NEBULA Data Plane) experiments Platform for NVENT (NEBULA extensible control plane) * No GENI-enabled switches on NEBULA campuses-->so preliminary thoughts 15

XIA Testbed Requirements Run fairly large, geographically diverse experiments Several tens or more nodes High speed packet processing platform Evaluating Openflow – XIA is very different from IP Diverse access network technologies Evaluate XIA over diverse networks using applications Short learning curve for students Avoid time sink that takes away time from research Essential for UG and MS student participation

NDN Experimental Infrastructure Pervasive/mobile computing “infrastructure-less” testbeds with embedded hardware Real world settings for Internet-of-Things scenarios Open Network Lab (ONL) Controlled small-scale experiments, especially forwarding NDN Overlay Testbed on public Internet Live application testing/use under realistic conditions Routing and incremental deployment PlanetLab Large-scale experiments Supercharged PlanetLab Platform (SPP) Nodes High-performance CCNx/NDN forwarding Infrastructureless TB: lightweight wireless devices . Use applications: UCLA Estrin + jeff Burke= lighting; tarek Ab applications. Used IP TB with each having ugly middleware Hypothesis is that NDN is better. Implementing in NDN ONL racks PCs and switches. Lower left picture is graphic of lab and use GUI to design topology and can establish VLAN and have experiment of 40 machines. Verify performance of NDN architecture—key is look up and want to forward interest requests. Using novel hashtable and algorithm think can improve performance . Can implement and experiment in real SW/HW Overlay TB lower right. Each institution put up 1-2 machines with reference implementation and all routes populated. Useful for evaluating routing protocols. PlanetLab—expects that once vet routing ideas in overlay can increase scope using PlanetLab . SPPs programmable routers. Inside boxes is same as commercial routers. SW implementations of layer 3, but G/ethernet interfaces. Can run own layer 3; Up to 5 G/sec, but not have that BW between nodes. (could go faster)

NDN and GENI Using SPP nodes No other clear needs identified yet Initial software running on 5 nodes now Lead: Patrick Crowley No other clear needs identified yet Possibilities: Large numbers of nodes with significant topology control including local broadcast Running natively over something other than IP NDN “PlanetLab” NDN Participating Institutions Deployed SPP Nodes 5 SPP nodes are part of and connected by GENI. Take advantage of ethernet broadcast in LAN, NDN can provide data to all who want data when IP has a problem to broadcast. NDN “PlanetlLab” Larry released PL node AND management SW. So can create own PlanetLab. (Europe and Asia does this with PlanetLab Central management SW (accounts, statistics and reporting, error data) SPP could be controlled by PlanetLab Central Salt Lake City Yale PARC Washington DC Kansas City ColoState UIUC UCLA UCI WashU CAIDA/UCSD Arizona Memphis Atlanta Houston

Mobility-First Phased Approach Content Addressing Stack Host/Device Addressing Stack Context 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 Cross Layer Integration Deployment ready Prototyping Status 19

Phase1: Global Name Resolution Service (GNRS) Evaluation - ProtoGENI Mapping Phase 1 evaluation of distributed network services, e.g. GNRS Backbone bandwidth and delay representative of Internet core Edge substrates interconnected via backbone Required Testbed Infrastructure (ProtoGENI nodes, OpenFlow switches, GENI Racks, ORBIT node clients) Domain-1 Domain-2 Router Domain-3 Clients PoP 20

Phase 1: Wireless/Mobile Edge Substrate Phase 1 evaluation of storage-aware routing in edge network Network: Ad hoc, multiple wireless technologies – WiFi, WiMAX Evaluate routing with mobility, handoff, multi-homing Single Wireless Domain WiMAX AP Multi-homed device WiFi BTS Movement Handoff Cell tower Ad hoc network Required Testbed Infrastructure: GENI WiMax, ORBIT grid & campus net, DOME/DieselNET WiNGS

Phase 1: GENI WiMAX & ORBIT Testbeds Multi-radio indoor and outdoor nodes - WiMAX, WiFi, Linux-based Click implementation of routing protocols 22

GENI WiMax/OF campus nets, ORBIT, ProtoGENI Phase 2: Core + Edge Evaluations Multi-site experiments with both (wired) core and (wired + wireless) edge networks Evaluate: Core-to-edge routing Cross-layer interaction between GNRS and routing services In-core router storage resources in STAR routing 1Gbps Required Testbed Infrastructure: GENI WiMax/OF campus nets, ORBIT, ProtoGENI 23

Wireless Egde (4G & WiFI) Wireless Edge (4G & WiFI) Phase 3: Live Edge-Core-Edge Deployment OpenFLow Backbones OpenFlow WiMAX ShadowNet Internet 2 National Lambda Rail Legend Domain-1 Router Domain-2 Wireless Egde (4G & WiFI) Wireless Edge (4G & WiFI) Domain-3 Services Full MF Stack at routers, BS, etc. Mapping onto GENI Infrastructure ProtoGENI nodes, OpenFlow switches, GENI Racks, WiMAX/outdoor ORBIT nodes, DieselNet bus, etc. Inter-domain mobility Intra-domain mobility Opt-in users Deployment Target: Large scale, multi-site Mobility centric Realistic, live 24

Going Forward FIA team members continue to participate in GENI GENI-FIA-like Workshop??? FIA testbed/experimentalists Reps GENI GPO Reps Working Groups Reps Other researchers working on architecture projects Other ideas?