wiki:GeniGlossary

Version 8 (modified by jjacob@bbn.com, 16 years ago) (diff)

--

Aggregate
An aggregate is an object representing a group of components, where a given component can belong to zero, one, or more aggregates. Aggregates can be hierarchical, meaning that an aggregate can contain either components or other aggregates. Aggregates provide a way for users, developers, or administrators to view a collection of GENI nodes together with some software-defined behavior as a single identifiable unit. Generally aggregates export at least a component interface‚ i.e., they can be addressed as a component‚ although aggregates may export other interfaces, as well. Aggregates also may include (controllable) instrumentation and make measurements available. This document makes broad use of aggregates for operations and management. Internally, these aggregates may use any O&M systems they find useful.
Clearinghouse
A clearinghouse is a, mostly operational, grouping of a) architectural elements including trust anchors for Management Authorities and Slice Authorities and b) services including user, slice and component registries, a portal for resource discovery, a portal for managing GENI-wide policies, and services needed for operations and management. They are grouped together because it is expected that the GENI project will need to provide this set of capabilities to bootstrap the facility and, in general, are not exclusive of other instances of similar functions. There will be multiple clearinghouses which will federate. The GENI project will operate the NSF-sponsored clearinghouse. One application of ‘federation’ is as the interface between clearinghouses.
Components
Components are the primary building block of the architecture. For example, a component might correspond to an edge computer, a customizable router, or a programmable access point. A component encapsulates a collection of resources, including physical resources (e.g., CPU, memory, disk, bandwidth) logical resources (e.g., file descriptors, port numbers), and synthetic resources (e.g., packet forwarding fast paths). These resources can be contained in a single physical device or distributed across a set of devices, depending on the nature of the component.
Experiment
An experiment is a researcher-defined use of a slice; we say an experiment runs in a slice. Experiments are not slices. Many different experiments can run in a particular slice concurrently or over time.
Federation
Resource federation permits the interconnection of independently owned and autonomously administered facilities in a way that permits owners to declare resource allocation and usage policies for substrate facilities under their control, operators to manage the network substrate, and researchers to create and populate slices, allocate resources to them, and run experiment-specific software in them.
Management Authority
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. (Note that management authorities potentially conflate owners and operators. In some cases, an MA will correspond to a single organization in which case the owner and operator are likely the same. In other cases, the owner and operator are distinct, with the former establishing a “management agreement” with the latter.)
Owner
GENI includes owners of parts of the network substrate, who are therefore responsible for the externally visible behavior of their equipment, and who establish the high-level policies for how their portion of the substrate is utilized.
Portals
A portal denotes the interface—graphical, programmatic, or both—that defines an “entry point” through which users access GENI. A portal is likely implemented by a combination of services. Different user communities can define portals tailored to the needs of that community, with each portal defining a different model for slice behavior, or support a different experimental modality. For example, one portal might create and schedule slices on behalf of researchers running short-term controlled experiments, while another might acquire resources needed by slices running long-term services. Yet another portal might be tailored for operators that are responsible for keeping GENI components up and running.
Resource
Resources are abstractions of the sharable features of a component that are allocated by a component manager and described by an RSpec. Resources are divided into computation, communication, measurement, and storage. Resources can be contained in a single physical device or distributed across a set of devices, depending on the nature of the component.
Sharing
Wherever possible GENI components should support multiple concurrent experiments. We refer to this as making components and aggregates sharable (or sometimes “sliceable”). Different strategies may be needed to share components based on the nature of the technologies. This can be done by a combination of virtualizing the component (where each user acquires a virtual copy of the component's resources), or by partitioning the component into distinct resource sets (where each user acquires a distinct partition of the component's resources).
Slices
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 the basis for resource revocation (i.e., shutdown). 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.
Slivers
It must be possible to share component resources among multiple users. This can be done by a combination of virtualizing the component (where each user acquires a virtual copy of the component's resources), or by partitioning the component into distinct resource sets (where each user acquires a distinct partition of the component's resources). In both cases, we say the user is granted a sliver of the component. Each component must include hardware or software mechanisms that isolate slivers from each other, making it appropriate to view a sliver as a “resource container.”
Substrate
GENI provides a set of physical facilities (e.g., routers, processors, links, wireless devices), which we refer to as the substrate. The design of this substrate is concerned with ensuring that physical resources, layout, and interconnection topology are sufficient to support GENI’s research objectives.
User Opt-In
An important feature of GENI is to permit experiments to have access to end-user traffic and behaviors. For examples, end-users may access an experimental service, use experimental access technologies, or allow experimental code to run on their computer or handset. GENI will provide tools to allow users to learn about an experiment’s risks and to make an explicit choice (“opt-in”) to participate.

Technology Readiness Level's (NASA Definition, adapted to GENI context)

Technology readiness levels (TRL's) are used to describe the maturity of technologies. Technology risks are often identified through the assessment of component, sub-system and the integrated system TRL's. It is not uncommon to have high component TRL's but low system TRL's caused by the absence of demonstrated integration into the particular system of interest. The table below provides the widely accepted description of each TRL level.

TRL-1Basic principles observed and reported
TRL-2Technology concept and/or application formulated
TRL-3Analytical and experimental critical function and/or characteristic proof-of-concept achieved in a laboratory environment
TRL-4Component and/or breadboard validated in a laboratory environment
TRL-5Component and/or breadboard validated in a relevant environment
TRL-6System/subsystem model or prototype demonstration in a relevant lab environment
TRL-7System prototype demonstrated in an end-to-end "GENI-like" environment
TRL-8Actual system completed and demonstrated in the end-to-end GENI environment
TRL-9Actual system "flight proven" through successful end-to-end GENI experiments