1. GENI Architecture Global Environment for Network Innovations The GENI Project Office (GPO) March 2, 2008 – GEC #2 Architecturewww.geni.net1 Clearing house for all GENI news and documents

2. Acknowledgement These slides have evolved over time as the architecture has. Larry Peterson, John Wroclawski, and the Planning Group Architecture WG deserve thanks for producing much of the material. March 2, 2008 – GEC #2 Architecture2www.geni.net

3. Outline of this Talk High-level requirements –Design goals for the GENI facility Facility substrate –A hardware-oriented view of what GENI might look like Core architectural elements –Key concepts that form the basis for the architecture Discussion of maturity levels –Fixed vs. squishy vs. undefined March 2, 2008 – GEC #2 Architecture3www.geni.net

4. Design flow Technical Req’s Ops and Mgmt. Req’s Construction/ Community Req’s High Level Architecture Core Architecture Implementation Requirements Overall Design: modularity and structure Narrow Waist: abstractions and Interfaces Narrow Waist: algorithms and implementation choices March 2, 2008 – GEC #2 Architecture4www.geni.net

5. Top-Level Requirements 1.Generality A.Minimal Constraints allow new data formats, new functionality, new paradigms,… allow freedom to experiment across the range of architectural issues (e.g., security, management,...) B.Breadth of Representative Technology include a diverse and representative collection of networking technologies, since any future Internet must work across each of them, and the challenges/opportunities they bring 2.Sliceability support many experiments in parallel isolate experiments from each other, yet allow experiments to compose their experiments to build more complex systems March 2, 2008 – GEC #2 Architecture5www.geni.net

6. Top-Level Req (cont) 3.Fidelity A.Device Level expose useful level(s) of abstraction, giving the experimenter the freedom to reinvent above that level, while not forcing him or her to start from scratch (i.e., reinvent everything below that level) these abstractions must faithfully emulate their real world equivalent (e.g., expose queues, not mask failures) B.Network Level arrange the nodes into representative topologies and/or distribute the nodes across physical space in a realistic way scale to a representative size expose the right network-wide abstractions (e.g., circuits, lightpaths) C.GENI-Wide end-to-end topology and relative performance economic factors (e.g., relative costs, peering) March 2, 2008 – GEC #2 Architecture6www.geni.net

7. Top-Level Req (cont) 4.Real Users allow real users to access real content using real applications provide incentives and mechanisms to encourage this Support long-lived experiments and services 5.Research Support A.Ease-of-Use provide tools and services that make the barrier-to-entry for using GENI as low as possible (e.g., a single PI and one grad student ought to be able to use GENI) Key point: this community builds its own tools. B.Observability make it possible to observe and measure relevant activity March 2, 2008 – GEC #2 Architecture7www.geni.net

8. Top-Level Req (cont) 6.Sustainability A.Extensible and evolvable accommodate network technologies contributed by various partners accommodate new technologies that are likely to emerge in next several years support technology roll-over without disruption B.Operational Costs the community should be able to continue to use and support the facility long after construction is complete Trade off increased capital cost for decreased operational cost when appropriate March 2, 2008 – GEC #2 Architecture8www.geni.net

9. Facility Architecture (View 1) - name spaces, registries, etc -for key system elements (users, slices, & components - set of interfaces -(“plug in” new substrate components) - support for federation -(“plug in” new partners) March 2, 2008 – GEC #2 Architecture9 User Services Substrate Components Bootstrap Structure Reference Implementations Minimal Core Universal Fixed Points www.geni.net

10. Facility Architecture (View 2) O&M Aggregate Control Measure- ments Components Aggregate A O&M Measure- ments Components Aggregate B Researcher with Tools Clearinghouse List of Organizations List of Resources O&MPolicy Measurement Plane Control Plane Data Plane Federation Trust Interface Internet Opt-in User (??) Aggregate Control Research Organization March 2, 2008 – GEC #2 Architecture10www.geni.net

11. Diversion: the physical substrate The key function of the GENI system is to support flexible, useful embedding of experiments within a shared physical substrate. To understand the system architecture, it is helpful to first understand the sorts of physical resources the architecture is designed to control. March 2, 2008 – GEC #2 Architecture11www.geni.net

12. National Fiber Facility March 2, 2008 – GEC #2 Architecture12www.geni.net We expect there to be multiple backbone providers.

13. + Programmable Switch/Routers March 2, 2008 – GEC #2 Architecture13www.geni.net

14. + Clusters at Edge Sites March 2, 2008 – GEC #2 Architecture14www.geni.net

15. + Wireless Subnets March 2, 2008 – GEC #2 Architecture15www.geni.net

16. + ISP Peers MAE-West MAE-East March 2, 2008 – GEC #2 Architecture16www.geni.net

17. GENI-izing the Substrate Previous slides described a strawman physical substrate Next slides describe GENI’s system architecture - the software abstractions, objects, and functions that make this physical substrate available to GENI’s researchers as experiments. March 2, 2008 – GEC #2 Architecture17www.geni.net

18. Substrate Hardware Substrate HW March 2, 2008 – GEC #2 Architecture18www.geni.net

19. Slicing Model and Software March 2, 2008 – GEC #2 Architecture19 Virtualization SW Substrate HW Virtualization SW Substrate HW Virtualization SW Substrate HW (often, “virtualization”) www.geni.net

20. Components Export a standard component manager interface –Resource allocation (to slices) and control –Minimal management March 2, 2008 – GEC #2 Architecture20 Substrate HW CM Virtualization SW CM Virtualization SW CM Virtualization SW www.geni.net

21. Aggregates Resource ControllerAuditing Archive Aggregate (Proxy for set of components) CM Virtualization SW Substrate HW CM Virtualization SW Substrate HW CM Virtualization SW Substrate HW O & M Control Slice Coordination March 2, 2008 – GEC #2 Architecture21www.geni.net

22. User Portals Researcher Portal (Service Front-End) March 2, 2008 – GEC #2 Architecture22www.geni.net

23. The Core Architectural Elements Previous slides have described the physical substrate, and some aspects of the overall software architecture that supports it Next slides describe the minimal set of core abstractions that serve as “fixed points” for the GENI architecture –This allows other system elements to evolve flexibly and independently New components, services, partners, … Particularly relevant during this early development / prototyping phase. March 2, 2008 – GEC #2 Architecture23www.geni.net

24. Hour-Glass Revisited March 2, 2008 – GEC #2 Architecture24 User Services Substrate Components Bootstrap Structure Reference Implementations Minimal Core Universal Fixed Points www.geni.net

25. Principals March 2, 2008 – GEC #2 Architecture25 Researcher: A user that wishes to run an experiment or service in a slice, or a developer that provides a service used by other researchers. A slice authority (SA) is responsible for the behavior of a set of slices, vouching for the users running experiments in each slice and taking appropriate action should the slice misbehave. A management authority (MA) is responsible for some subset of substrate components: providing operational stability for those components, ensuring the components behave according to acceptable use policies, and executing the resource allocation wishes of the component owner. www.geni.net

26. Components & Resources March 2, 2008 – GEC #2 Architecture26 Component: An object representing a physical device in the GENI substrate. A component consists of collection of resources. Such physical resources belong to precisely one component. Each component runs a component manager that implements a well- defined interface for the component. In addition to describing physical devices, components may be defined that represent logical devices as well. Transmission Channel Computer CPU Memory Disk BW Optical Switch Fiber IDρ Switch Port Channel Band Other resources are pools which may be allocated under some constraints. Component Resource Some resources describe non- configurable characteristics of the component. Some measurements are available as resources Spectrum Analyzer Location Sample period Sample BW Measurement equipment may also appear as components Routeρ r Cableρ c Fiberρ f Spectrumρ s Endpoint IDρ e S/N measurementsμ e www.geni.net

27. Slivers & Slices March 2, 2008 – GEC #2 Architecture 27 sliver slice Transmission Channel Routeρ r Cableρ c Fiberρ f Spectrumρ s Endpoint IDρ e Transmission Channel Routeρ r Cableρ c Fiberρ f Spectrumρ s Endpoint IDρ e Computer CPU Memory Disk BW Optical Switch Fiber IDρ 1, ρ 2, ρ 3, ρ 4 Switch Port Channel Band From a researcher's perspective, a slice is a substrate-wide network of computing and communication resources capable of running an experiment or a wide-area network service. From an operator's perspective, slices are the primary abstraction for accounting and accountability—resources are acquired and consumed by slices, and external program behavior is traceable to a slice, respectively. A slice is defined by a set of slivers spanning a set of network components, plus an associated set of users that are allowed to access those slivers for the purpose of running an experiment on the substrate. That is, a slice has a name, which is bound to a set of users associated with the slice and a (possibly empty) set of slivers. sliver slice www.geni.net

28. Identifiers March 2, 2008 – GEC #2 Architecture 28 All researchers, slices, and components have a Global Identifier (GID). A GID binds a Universally Unique Identifier (UUID) to a public key. The object identified by the GID holds the private key, thereby forming the basis for authentication. GID private key Held by component/slice possessing the GID 128bit UUID public key Easy-to-use handle For verifying integrity & authenticity of GID, UUID. authority’s signature Says who is responsible by pointing up the chain of authority. (optional). www.geni.net

29. Minimal Core Principals –Slice Authorities (SA) –Component Management Authorities (MA) –User (researcher/experimenter, not “end user”) Objects –Slices - containers for experiments Registered, Embedded, Accessed –Components - providers of resources Data Types –Global Identifiers (GID) –RSpec: resource specification –Tickets (credentials issued by component MA) –Slice Credentials (express live-ness, issued by SA) March 2, 2008 – GEC #2 Architecture29www.geni.net

30. Core (cont) Default Name Registries –Slice Registry (e.g., geni.us.princeton.codeen) –Component Registry (e.g., geni.us.backbone.nyc) Component Interface –Get/Split/Redeem Tickets –Create and Control Slices (“Slivers”) –Query Status March 2, 2008 – GEC #2 Architecture 30www.geni.net

31. Core (cont) Control Interfaces (Minimal common elements) –Return to known state –Start/stop –Become more intelligent (boot load) Federation Interfaces –Cross-domain accountability –Policy expression and management March 2, 2008 – GEC #2 Architecture 31www.geni.net

32. Maturity levels General statement –The strawman design builds on significant community experience. PlanetLab, Emulab, DETER, others. –The strawman design is work in progress. It is not implemented. Some parts are incomplete. Some are in great flux. –… but the initial version is incremental and “simple” –Component and service prototypers will work in parallel with the control plane development. March 2, 2008 – GEC #2 Architecture32www.geni.net

33. Relatively Mature Core system objects - users, components,.. Concept & function of components Concept & function of universal identifiers Concept of resource specifications Simple model for slice and component registries … March 2, 2008 – GEC #2 Architecture33www.geni.net

34. Less Mature Configuration management –How are components at a site related? Federation model and interfaces –How do we build experiments across different administrative regions? Operations and management interfaces –Ensure sufficient reliability, accessibility –Track usage to plan for future needed … March 2, 2008 – GEC #2 Architecture34www.geni.net