Download presentation
Presentation is loading. Please wait.
Published byDoris Jefferson Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.