GENI ARCHITECTURE Global Environment for Network Innovations The
GENI ARCHITECTURE Global Environment for Network Innovations The GENI Project Office (GPO) www. geni. net Clearing house for all GENI news and documents March 2, 2008 – GEC #2 Architecture www. geni. net 1
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 Architecture www. geni. net 2
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 Architecture www. geni. net 3
Design flow Technical Req’s High Level Architecture Construction/ Community Req’s Core Architecture Implementation Ops and Mgmt. Req’s Requirements Overall Design: modularity and structure March 2, 2008 – GEC #2 Architecture Narrow Waist: abstractions and Interfaces www. geni. net Narrow Waist: algorithms and implementation choices 4
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 Architecture www. geni. net 5
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 Architecture www. geni. net 6
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 Architecture www. geni. net 7
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 Architecture www. geni. net 8
Facility Architecture (View 1) User Services - name spaces, registries, etc Bootstrap Structure Minimal Core -for key system elements (users, slices, & components Universal Fixed Points - set of interfaces -(“plug in” new substrate components) - support for federation -(“plug in” new partners) Reference Implementations Substrate Components March 2, 2008 – GEC #2 Architecture www. geni. net 9
Facility Architecture (View 2) List of Organizations List of Resources O&M Federation Policy Clearinghouse Research Organization em sur e lan en t. P a Me Control Plane Dat Researcher with Tools Measurements O&M Aggregate Control Opt-in User (? ? ) a. P lane Internet Trust Interface March 2, 2008 – GEC #2 Architecture Components Aggregate A Aggregate B www. geni. net 10
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 Architecture www. geni. net 11
National Fiber Facility We expect there to be multiple backbone providers. March 2, 2008 – GEC #2 Architecture www. geni. net 12
+ Programmable Switch/Routers March 2, 2008 – GEC #2 Architecture www. geni. net 13
+ Clusters at Edge Sites March 2, 2008 – GEC #2 Architecture www. geni. net 14
+ Wireless Subnets March 2, 2008 – GEC #2 Architecture www. geni. net 15
+ ISP Peers MAE-West MAE-East March 2, 2008 – GEC #2 Architecture www. geni. net 16
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 Architecture www. geni. net 17
Substrate Hardware Substrate HW March 2, 2008 – GEC #2 Architecture Substrate HW www. geni. net Substrate HW 18
Slicing Model and Software • (often, “virtualization”) Virtualization SW Substrate HW March 2, 2008 – GEC #2 Architecture Virtualization SW Substrate HW www. geni. net Virtualization SW Substrate HW 19
Components • Export a standard component manager interface – Resource allocation (to slices) and control – Minimal management CM CM CM Virtualization SW Substrate HW March 2, 2008 – GEC #2 Architecture www. geni. net 20
Aggregates Aggregate (Proxy. Controller for set of components) Resource Auditing Archive O & M Control Slice Coordination CM CM CM Virtualization SW Substrate HW March 2, 2008 – GEC #2 Architecture www. geni. net 21
User Portals Researcher Portal (Service Front-End) March 2, 2008 – GEC #2 Architecture www. geni. net 22
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 Architecture www. geni. net 23
Hour-Glass Revisited User Services Bootstrap Structure Minimal Core Universal Fixed Points Reference Implementations Substrate Components March 2, 2008 – GEC #2 Architecture www. geni. net 24
Principals 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. March 2, 2008 – GEC #2 Architecture 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. www. geni. net 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. 25
Components & Resources Component Resource Some resources describe nonconfigurable characteristics of the component. Some measurements are available as resources Transmission Channel Computer Optical Switch Route ρ r Cable ρ c CPU Switch Port Fiber ρ f Memory Channel Spectrum ρ s Disk Band Endpoint ID ρ e BW S/N measurements μ e Fiber ID Other resources are pools which may be allocated under some constraints. 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 welldefined interface for the component. In addition to describing physical devices, components may be defined that represent logical devices as well. March 2, 2008 – GEC #2 Architecture ρ www. geni. net Spectrum Analyzer Location Measurement equipment may also appear as components Sample period Sample BW 26
Slivers & Slices Transmission Channel Route ρ Cable ρ Fiber ρ Spectrum ρ Endpoint ID ρ Computer r Optical Switch c Fiber ID r c f CPU Switch Port s Memory Channel e Disk Band f s e ρ, ρ, ρ, ρ 1 2 3 4 BW sliver sliver slice 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 of slivers. Marchempty) 2, 2008 set – GEC #2 www. geni. net 27 Architecture
Identifiers Held by component/slice possessing the GID Easy-to-use handle private key GID 128 bit UUID For verifying integrity & authenticity of GID, UUID. 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. public key Says who is responsible by pointing up the chain of authority. (optional). authority’s signature March 2, 2008 – GEC #2 Architecture www. geni. net 28
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 Architecture www. geni. net 29
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 www. geni. net 30
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 www. geni. net 31
Maturity levels • General statement – The strawman design builds on significant community experience. • Planet. Lab, 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 Architecture www. geni. net 32
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 Architecture www. geni. net 33
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 Architecture www. geni. net 34
- Slides: 34