This page has been deprecated. See GENIGlossary instead.

GENI Glossary

Active Sliver
A sliver that supports user-installed code.
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.
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 infrastructure suite 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 are the primary building block of the architecture. For example, a component might correspond to an edge computer, a customizable router, a programmable access point, or an optical link. 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. 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.
Component Manager
The entity responsible for allocating resources at a component. It exports a standard interface defined in the GENI architecture document. That interface is also exported by aggregates. Though it is intuitive to think of the component manager residing on the component it manages, this is not necessarily the case.
Component Registry
A registry that maps between a component name, e.g. and a GENI Global Identifier. Components and aggregates share a name space, so a component registry maps aggregate names to GGIDs as well.
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.
Resource federation permits the interconnection of independently-owned and autonomously-administered infrastructures in a way that permits owners to declare resource allocation and usage policies for substrate infrastructure 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.
GENI Global Identifier (GGID)
Unambiguous, certified unique identifiers assigned to GENI objects. Specifically these are assigned to users, components, and slices. A GGID consists of an X.509 certificate that binds a UUID to a public key.
Internet eXchange Point (IXP)
A facility where Internet networks exchange traffic. GENI will connect to the commodity Internet at one or more IXPs. This allows GENI services to be accessed by Internet users via user opt-in.
Internet eXchange Point
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.)
Operations and Management
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.
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.
A principal is an actor in GENI such as a researcher or operator.
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.
Resource Specification (RSpec)
Represents all GENI resources that can be bound to a sliver within GENI. An rspec describes both the resources available, advertised or allocated at a component and the relationships between those resources, and perhaps other resources in GENI.
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).
From a researcher's perspective, a slice is a substrate-wide network of computing, communication, and measurement 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.
Slice Authority (SA)
Entity responsible for the behavior of some set of slices. Participates in the slice naming hierarchy.
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.”
GENI provides a set of physical equipment and its software (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.
Signed data structure issued by a component or aggregate that guarantees the availability of a given set of resources. The ticket may have time or other constraints. Tickets are redeemed to create slivers.
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

See also

Last modified 11 years ago Last modified on 07/15/13 11:06:36