GENI Resources

In the GENI Network there are three types of resources available to experimenters:

Production Resources: resources that have successfully undergone acceptance testing and are actively monitored by the GMOC. These resources have clearly defined administrative, monitoring, and network infrastructure support procedures.

Development Resources: resources that have successfully undergone acceptance testing, and may optionally support experimenters, but are simultaneously used for early testing of new software and functions. These resources are also actively monitored by GMOC, amd have clearly defined administrative, monitoring, and network infrastructure support procedures. Because these resources may run pre-release GENI software, they are likely to have more frequent scheduled maintenance and upgrades, and they may perform some functions differently than other GENI resources. Development resources are clearly indicated as such on their ​GENI wiki aggregate information page. New functions in development on these resources are typically supported directly by one or more developers, with the expectation that experimenters can use the functions while development is ongoing, but the functions may change during development. Development resources do not usually transition to production.

Provisional Resources: resources that were initially tested off the GENI network, and have now been connected to the GENI network for further testing. These resources are undergoing acceptance testing on the GENI network (See ​GENI Acceptance tests for examples of acceptance tests.) The administrative, monitoring, and network infrastructure support procedures for the resources are also under test, and subject to change, but should support standard procedures as much as possible during testing. Typically these sites are not actively supported by GMOC, except as part of the provisional testing. Provisional resources are clearly indicated as such on their ​GENI wiki aggregate information page. Provisional procedures that involve direct support from the resource developers and the site contacts must be documented on the GENI wiki. The amount of time a resource runs as a provisional resource is expected to be brief (weeks or small number of months), because the resource should pass acceptance tests and become a production or development resource quickly.

1.0 GENI Provisional Resources Support

This document describes the requirements to be met by provisional resources to begin acceptance testing on GENI. The document also describes requirements for the site adminstrators and developers of provisional resources.

1.1 GENI Infrastructure support

Provisional resources must provide the minimum functions documented in this section to operate on GENI.

1.1.1 Root Access

Provisional resources must provide GENI infrastructure engineers with remote root (or sudo-enabled) login access to the rack's control node, compute nodes, network switches, console access. Access should be by SSH key, VPN, or other secure means. Username/password only access to these resources is not allowed.

1.1.2 State Logging

Provisional resources must log the current state of all allocated resources, which includes operational state and performance state of those resources to remote or local storage. GENI infrastructure engineers must be able to determine which resources are in use by which experimenters/testers whenever the resource is active. It is highly desirable that the remote or local storage provide historical states as well.

1.1.3 IP and MAC Address requirement

Provisional resources must provide procedures or tools for associating a particular active VLAN MAC or IP address with a particular slice and (one or more) slivers on the resource. Documentation must exist in a standard location such as the GENI wiki describing each of the procedures to be used to map a VLAN MAC or IP address to a sliver.

1.1.4 Stop / Delete Resource

Provisional resources are required to provide tools that allow for pausing, stopping or deleting all resources associated with individual slices on that resource. Procedures must exist that describe how the GENI infrstructure engineers can stop resources as needed. Procedures for the GMOC are also highly desirable.

1.1.5 Network Disconnect / Connect

Provisional resources should provide documented tools to shut off and restore any connectivity to the external networks (L2 or L3). If such tools do not exist, then the site resource owners/developers must document procedures that describe how to disconnect and reconnect rack to the external network, and how GENI engineers can request this action.

1.2 Documentation Requirements

1.2.1 Documentation Location

Provisional resources documentation described in earlier sections must be actively maintained to meet the goals for the tools and procedures described above. Documentation and procedures for the provisional resources must be accessible to any GENI engineer, site administrator, GMOC staff or experimenter. The GENI public wiki meets this requirement.

1.2.2 Operator's Aggregate Page

Operator pages must be maintained for provisional resources. These pages must capture the site's network connectivity to GENI, and provide contact information for those supporting the provisional resource. For an example, see the ​InstaGENI Operators page.

1.3 Experimenter Support

1.3.1 Experimenters Provisional Aggregate Documentation

Provisional resources are not usually open to experimenters, because acceptance testing and software revisions can be quite disruptive. If a provisional resource is available to experimenters, it should be clearly indicated as such on its ​GENI wiki aggregate information page.

1.3.2 AM API Support

GENI Provisional resources must support the GENI AM API (V2 and V3) and must support a minimal set of functionality that allows experimenters to:

• request network and compute resources
• release network and compute resources
• get network and compute resource status
• list network and compute available resources.
• get aggregate version

1.4 Site Administration Support

Administrative procedures must exist that define how to manage rack compute resource, rack network resources, and how to manage administrative accounts.

1.4.1 Rack Device Access

Documentation must be available to provide an overview of devices in the aggregate (e.g. in the rack), device role in the aggregate (e.g. head node), and available types of access to each device (e.g. admin VPN).

1.4.2 Administrative Accounts

Procedures must exist to document how to add and remove administrative accounts. The procedures must clearly describe how access is granted (and removed) to each device for each type of access (ssh, web, etc) for an administrative account. All administrative environment requirements must be detailed. For example, if an account requires tools to be installed in order to manage the environment, tools must be described. Administrative account procedures must clearly specify how each type of access is removed (ssh, web) and how to move an active administrator account to non-active, as administrative user history should be preserved.

1.4.3 Resource Mapping

Rack administrators should be able to map resources to slices and to one or more slivers, if asked. Procedures must exist that allow the administrator to map slices resources to experimenters. These procedures must also describe how to map a MAC or IP address to a slice and to one or more slivers.

1.4.4 Resource Shutdown / Power-up procedures

Administrative procedures that document how a provisional site administrator can shut down the entire rack must be available. Procedures must also document how to power the rack up again, and how to restore all processes and resources so that they are working and available to experimenters.

1.5 GMOC Support

Procedures must exist to allow the GMOC to request an emergency stop or LLR investigation for a provisional resource. (These procedures will be based on those in section 1.1.). Note that acceptance tests include many functions relevant to GMOC support not specified again here.