Presentation on theme: "Future Internet Architectures (FIA) And GENI"— Presentation transcript:
1Future Internet Architectures (FIA) And GENI Darleen FisherProgram DirectorDivision of Computer & Network SystemsDirectorate for Computer and Information Science and EngineeringNational Science Foundation
2Outline FIA Vision Future Internet Architecture (FIA) Projects FIA Projects’ Current Ideas about Using GENIGoing Forward—What might be next for FIA & GENI?
3Future 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 InternetSociety 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
4Future Internet Architectures (FIA) NSF issued a call for proposals:To support innovative and creative projects that conceive, design, and evaluate trustworthy Future Internet architectures4 projects awarded – A diverse portfolio(smaller projects under consideration and expected submit to NeTS Large)
5FIA Projects and their View of the Future Mobility FirstThe future is mobile (Cellular, wireless sensors, machine-to-machine, smart grid & vehicular nets integrate physical world awareness and control into Internet applications)NEBULA24x7 Utility for secure communication, computation and storageNamed Data Network (NDN)Content is the future drivereXpressive Internet Architecture (XIA)Design for evolution of: usage (host-host, content retrieval, services) and technology (link, storage, computing)
6MobilityFirst Mobility Path disruption tolerance (path redundancy) Principle Investigator: Dipankar Raychaudhuri, RutgersCollaborating 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/MadisonUnderlying architectural principlesMobility is the norm without gateways or overlay accommodationsThe 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.MobilityPath disruption tolerance (path redundancy)Delay-tolerant networking
7M-F Overview - Component Architecture Location ServiceOther Application ServicesContext AddressingContent AddressingHost/Entity AddressingApplication ServicesEncoding/Certifying LayerGlobal Name Resolution Service (GNRS)Network-Support ServicesStorage Aware Routing (STAR)Context-Aware / Late-bind RoutingManagementLink state and Path MeasurementsCore Network ServicesLocator-X Routing (e.g., GUID-based)IP Routing (DNS, BGP, IGP)Monitor, Diagnosis and Control
8Named Data Networking Content distribution Policy Enforcement Principle Investigator: Lixia Zhang, UCLACollaborating 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 principlesContent 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 architectureSeparate routing and forwardingContent distributionPolicy EnforcementAttribution
9Named Data Networking (NDN) The architecture retains the hourglass shapeChange the thin waist from using IP addresses to using data namesAlways retrieve data from closest copy on a path to source; use memory for intrinsic multicast distributionIP addresses name locations; retrieving data by names eliminates a fundamental hurdle in mobility supportRetrieving data by names facilitates new application development in sensor networkingRobust security from per packet signatureThe new strategy layer enables intelligent data delivery via broadcast, multicast, and multiple pathsISPISP
10NEBULA 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 WashingtonUnderlying architectural principlesAlways-on utility where cloud computing data centers are the primary repositories of data and the primary locus of computationStorage, 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 coreSecure access and transit, policy-based path selection and authentication during connection establishmentDP/CP RedundancyData plane and control plane separationVirtualizationFast, token-based Data plane, feature-rich control plane
11NEBULA ArchitectureNDP (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
12eXpressive Internet Architecture (XIA) Principle Investigator: Peter Steenkiste, Carnegie Mellon Univ.Collaborating Institutions: Boston Univ., Univ. of Wisconsin/MadisonUnderlying architectural principlesXIA 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.API-centric approach (Narrow Waist)Path decisions based on principal type, host, content, serviceTrustworthy ComputingStore-and-forward
14FIA Projects’ Current Ideas to use GENI Just began September 1, 2010;Are at different levels of maturity; as areTheir plans for experimentation and how they might use GENI.
15Potential use of GENI in NEBULA* GENI Technology:Enables experiments involving multiple sitesIsolates NEBULA experiments to a single VLANEliminates need for special HW & Address TranslationPotential Uses:Multisite student collaboration on Ncore (NEBULA Core)Testbed for NDP (NEBULA Data Plane) experimentsPlatform for NVENT (NEBULA extensible control plane)* No GENI-enabled switches on NEBULA campuses-->so preliminary thoughts15
16XIA Testbed Requirements Run fairly large, geographically diverse experimentsSeveral tens or more nodesHigh speed packet processing platformEvaluating Openflow – XIA is very different from IPDiverse access network technologiesEvaluate XIA over diverse networks using applicationsShort learning curve for studentsAvoid time sink that takes away time from researchEssential for UG and MS student participation
17NDN Experimental Infrastructure Pervasive/mobile computing “infrastructure-less” testbeds with embedded hardwareReal world settings for Internet-of-Things scenariosOpen Network Lab (ONL)Controlled small-scale experiments, especially forwardingNDN Overlay Testbed on public InternetLive application testing/use under realistic conditionsRouting and incremental deploymentPlanetLabLarge-scale experimentsSupercharged PlanetLab Platform (SPP) NodesHigh-performance CCNx/NDN forwardingInfrastructureless 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 NDNONL 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/HWOverlay 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)
18NDN and GENI Using SPP nodes No other clear needs identified yet Initial software running on 5 nodes nowLead: Patrick CrowleyNo other clear needs identified yetPossibilities:Large numbers of nodes with significant topology control including local broadcastRunning natively over something other than IPNDN “PlanetLab”NDN Participating InstitutionsDeployed SPP Nodes5 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 CentralSalt Lake CityYalePARCWashington DCKansas CityColoStateUIUCUCLAUCIWashUCAIDA/UCSDArizonaMemphisAtlantaHouston
20Phase1: Global Name Resolution Service (GNRS) Evaluation - ProtoGENI Mapping Phase 1 evaluation of distributed network services, e.g. GNRSBackbone bandwidth and delay representative of Internet coreEdge substrates interconnected via backboneRequired Testbed Infrastructure (ProtoGENI nodes, OpenFlow switches, GENI Racks, ORBIT node clients)Domain-1Domain-2RouterDomain-3ClientsPoP20
21Phase 1: Wireless/Mobile Edge Substrate Phase 1 evaluation of storage-aware routing in edge networkNetwork: Ad hoc, multiple wireless technologies – WiFi, WiMAXEvaluate routing with mobility, handoff, multi-homingSingle Wireless DomainWiMAX APMulti-homed deviceWiFi BTSMovementHandoffCell towerAd hoc networkRequired Testbed Infrastructure:GENI WiMax, ORBIT grid & campus net,DOME/DieselNETWiNGS
22Phase 1: GENI WiMAX & ORBIT Testbeds Multi-radio indoor and outdoor nodes - WiMAX, WiFi,Linux-based Click implementation of routing protocols22
23GENI WiMax/OF campus nets, ORBIT, ProtoGENI Phase 2: Core + Edge EvaluationsMulti-site experiments with both (wired) core and (wired + wireless) edge networksEvaluate:Core-to-edge routingCross-layer interaction between GNRS and routing servicesIn-core router storage resources in STAR routing1GbpsRequired Testbed Infrastructure:GENI WiMax/OF campus nets, ORBIT, ProtoGENI23
25Going Forward FIA team members continue to participate in GENI GENI-FIA-like Workshop???FIA testbed/experimentalists RepsGENI GPO RepsWorking Groups RepsOther researchers working on architecture projectsOther ideas?