Federation AM API

The AM API is provided via XML-RPC over an SSL connection. Aggregate Managers shall require client side certificates to authenticate users, accepting only certificates that comply with the adopted GENI certificates standards. This API therefore assumes that users have already been authenticated, and that the aggregate manager has available the client certificate to identify the user.

All AM API methods return a struct, with at least three members. code, value, and output together provide the standard return from all AM API methods.

Aggregates are encouraged to use code values and output messages that help experimenters and tools distinguish between bad input, other experimenter error, temporary server errors, or server bugs.

Implementations can add additional members to the return struct as desired. All of these additional members must have a prefix followed by a colon. Implementations should choose an appropriate prefix to avoid conflicts. The empty prefix (: a single colon with nothing in front of it) is reserved by this API specification (and future version of it). Aggregates should document their additional return members.

A Sliver is an aggregate defined grouping of resources within a slice at this aggregate, whose URN identifies the sliver, and can be used as an argument to methods such as [Delete] or [Renew], and whose status can be independently reported in the return from [Status]. The AM defines 1 or more of these groupings to satisfy a given resource request for a slice. All reserved resources are directly contained by exactly 1 such sliver container, which is in precisely 1 slice.

One or more slivers are created by an aggregate when the experimenter tool calls [Allocate]. This API encourages aggregates to independently manage each sliver, allowing experimenters to selectively [Delete], [Renew], or [Provision] each sliver. As such, these methods take a list of sliver urns (or a slice urn), and return a struct reporting results for each sliver URN independently. However, slivers at an aggregate may have interdependencies, and an individual aggregate may not be able to independently manage each sliver, without also modifying other related slivers. This API defines a number of aggregate configuration options returned by [GetVersion], and an option to many methods, allowing aggregates to advertise their behavior, and experimenters to request particular behavior.

Many methods also take a :best_effort option (aggregates must support it, clients do not need to supply it):

It is expected that many aggregates will implement one of the following combinations of options:

Many operations in this API create slivers or change the allocation status of slivers, and often return the current allocation status of each sliver.

Valid sliver allocation states are:

:allocated represents resources that have been allocated to a slice without provisioning the resources. This represents a cheap and reversible resource allocation. When a sliver is created and moved into state 2 (:allocated), the aggregate produces a manifest RSpec identifying which resources are included in the sliver. These resources are exclusively available to the containing sliver, but are not ready for use. In particular, allocating a sliver should be a cheap and quick operation, which the aggregate can readily undo without impacting the state of slivers which are fully provisioned. For some aggregates, transitioning to this state may be a no-op.

States 2 and 3 (:allocated and :provisioned) have aggregate and possibly resource specific timeouts. By convention the :allocated state timeout is typically short, to keep most resources available. The :provisioned state timeout is the sliver expiration. If the client does not request transition the sliver from :allocated to :provisioned before the end of the :allocated state timeout, the sliver reverts to :unallocated. If the experimenter needs more time, the experimenter should be allowed to request a renewal of either timeout. Note that typically the sliver expiration time (timeout for state 3, :provisioned) will be notably longer than the timeout for state 2, :allocated.

State 3, :provisioned, is the state of the sliver allocation after the aggregate begins to instantiate the sliver. Note that fully provisioning a sliver may take noticeable time. This state also includes a timeout - the sliver expiration time. This is the time a resource stays provisioned, and is unrelated to the time it takes to provision a resource. After the sliver expiration timeout, the resource automatically reverts to the :unallocated state (stopping resources when needed). [Renew] extends this timeout. For some aggregates and resource types, moving to this state from state 2 (:allocated) may be a no-op.

If the transition from one state to another fails, the sliver shall remain in its original state.

Several AM API methods can be described in terms of transitions among allocation states.

When [Provision] fails for only some slivers, and :best_effort option was supplied, the aggregate will return the status of each requested sliver individually. The :allocation_state for slivers that failed will remain :allocated. This typically suggests that the experimenter may retry the call. For some aggregates or resource types, the sliver may be dead, and [Provision] may never succeed. Experimenters should check :error for more information.

These states apply to each sliver individually. Logically, the state transition methods then take a single sliver URN. For convenience, these methods accept a list of sliver URNs, or a slice URN as a simple alias for all slivers in this slice at this aggregate.

Slivers, once fully allocated, are said to be in a particular operational state. States may indicate that a sliver is configuring, running, ready, turning, etc. These states are used by tools to know what sliver-internal actions are relevant, and what aggregate-defined operational actions may be valid.

The AM API defines a few operational states with particular semantics. AMs are not required to support the API defined states for all resources, but if the aggregate uses the API defined states, then the aggregate must follow the given semantics. AMs are however STRONGLY encouraged to support them, to provide maximum interoperability. There is one state that AMs are required to support, :pending_allocation, for a sliver which has not been fully allocated and provisioned (other operational states are not yet valid). Operational states are generally only valid for slivers which have been provisioned (:provisioned allocation state).

AMs may have their own operational states/state-machine internally. AMs are however required to advertise such states and actions that experimenters may see or use, by using an advertisement RSpec extension (if an AM does not advertise operational states, then tools can not know whether any actions are available). See the Rspec document for more information on this extension. Operational states which the experimenter never sees, need not be advertised. Operational states and actions are generally by resource type. The standard RSpec extension attaches such definitions to the sliver_type element of RSpecs. Operational states defined by AMs must have names with a restricted format. They may only use alphanumeric characters plus underscore, and the first character must be an alphanumeric character. This means they must match the following regular expression: '^[a-zA-Z0-9][a-zA-Z0-9_]*$'

The standard advertisement RSpec extension for advertising operational states and actions can be found here, with an example with comments here.

States should be defined in terms of

Note that states represent the AM’s view of the operational condition of the resource. Each state represents what the AM has done or learned about the resource, but experimenter actions may cause failures that the AM does not know about. For example, the AM may advertise a state of :ready for a machine when the experimenter has manually rebooted the machine.

There is no generic busy state. Instead, AMs are encouraged to define separate similar transition states for each separate transition path, allowing experimenters to distinguish the start and end states for this transition.

[Shutdown] is not an operational state for a sliver. The [Shutdown]() API method applies to an entire slice.

States are generally of one of two forms:

Some AMs may allow actions during wait states, (e.g. Cancel).

Operational actions immediately change the sliver operational state (if any change will occur). Long running actions therefore require a wait state, while the action is completing.

GENI defined operational states (both required and optional for aggregates):

Some AM cannot know if a resource is ready or has stopped, or even in which state a resource is. To express this, additional states are available. Clients need to be able to handle these cases.

Operational actions are commands that the aggregate exposes, allowing an experimenter tool to modify or act on a sliver from outside of the sliver (i.e. without logging in to a machine), without modifying the sliver reservation. Actions may cause changes to sliver operational state.

The API defines a few operational actions: these need not be supported. AMs are encouraged to support these if possible, but only if they can be supported following the defined semantics.

AMs may have their own operational states/state-machine internally. AMs are however required to advertise such states and actions that experimenters may see or use, by using an advertisement RSpec extension (if an AM does not advertise operational states, then tools can not know whether any actions are available). Operational states which the experimenter never sees, need not be advertised. Operational states and actions are generally by resource type. The standard RSpec extension attaches such definitions to the sliver_type element of RSpecs.

The standard advertisement RSpec extension for advertising operational states and actions can be found here, with an example with comments here.

Tools must use the operational states and actions advertisement to determine what operational actions to offer to experimenters, and what actions to perform for the experimenter. Tools may choose to offer actions which the tool itself does not understand, relying on the experimenter to understand the meaning of the new action.

Any operational action may fail. When this happens, the API method should return an error code. The sliver may remain in the original state. In some cases, the sliver may transition to the :failed state.

Operational actions immediately change the sliver operational state (if any change will occur). Long running actions therefore require a wait state, while the action is completing.

Defined operational actions:

Aggregates are free to add additional return values or input options to support aggregate or resource specific functionality, or to innovate within the bounds of the AM API.

This includes adding new methods that use the same transport, interface, certificates, and credentials. Aggregates are encouraged to document any such new return values which they return or options arguments, to bootstrap coordination with clients, and provide documentation for human experimenters.

One way to provide partial documentation, is to implement XML-RPC introspection. Through the use of method help, aggregates can provide human readable text describing return values. Alternatively or additionally, aggregates may document return values as part of their return from [GetVersion]. This API does not specify the format for advertising those extra return values in [GetVersion].

Aggregates must choose names starting with a non-empty prefix followed by a colon, when choosing names for:

An URN is sent as an XML-RPC string. See also the General document about indentifiers.

All datetime arguments and returns in this API shall be strings that conform to RFC 3339. This represents a subset of the valid date/time strings permissible by the standard XML-RPC date/time data type, dateTime.iso8601. Note that RFC3339 still allows some flexibility. For example, the following dates are all valid RFC3339:

We recommend that implementers use parsers that fully comply with the RFC 3339. However, due to the flexibility in the spec and different interpretations chosen by different common parsers, we require that such DATETIME values:

Note that specifying a timezone is in fact always mandatory in RFC 3339. "Unqualified Local Time" is not allowed as it is guaranteed to cause interoperability problems.

In the specification of this API, this type is refered to as string.dateTime.rfc3339.

An RSpec is sent as an XML-RPC string.

See the Rspec Document for details on RSpecs.

Throughout this API, multiple arguments and returns are labeled as an RSpec. These fields shall be understood as XML documents following one of the schemas advertised in the return from [GetVersion]. All such RSpecs must pass an XML schema validator, must list all used schemas and namespaces within the document, using schemas that are publicly available. The [GetVersion] return advertises schemas for advertisement and request RSpecs; the schemas for manifest RSpecs are assumed to be available at the same base URL, but using a corresponding manifest schema.

A fully compliant aggregate will always support the GENI standard schemas for RSpecs, see the Rspec section. The current GENI RSpec version is 3 (type is geni, case insensitive). Aggregates are free to use an alternate format internally, but must accept and produce compliant RSpecs on demand.

This API requires this contract: Aggregates advertise the type and version of RSpec formats that they support in [GetVersion]. If available, they specify the schema, namespace and extensions combination which is the authoritative definition of that format. Clients of the API should understand that combination in order to know how to understand the resources available at that aggregate.

If an aggregate advertises a particular type/version (optionally defined with a combination of schema, namespace and extensions) in the :ad_rspec_versions attribute of [GetVersion], then it promises to send a correct Advertisement RSpec in response to a [ListResources] call which supplies a :rspec_version option containing that type/version. (:rspec_version is a struct with 2 members, type and version. type and version are case-insensitive strings, matching those in :ad_rspec_versions).

If an Aggregate advertises a particular type/version (optionally defined with a combination of schema, namespace and extensions) in the :request_rspec_versions attribute of [GetVersion] then it promises to correctly honor an [Allocate] call containing a request RSpec in the given format, and then to return a Manifest RSpec in the corresponding format (i.e. a GENI format request is answered with a GENI format manifest). The aggregate also promises to send a correctly formatted Manifest RSpec in response to a [Describe] or [Provision] call which supplies a valid slice URN or list of sliver URNs and an :rspec_version option containing that supported type/version.

In this API, such RSpec fields are refered to as string.rspec.

An XML-RPC struct. This is the last argument of all calls in this API. For [GetVersion] only, this argument is optional and thus may be omitted. In all other calls, it is required, but may be empty.

The struct contains string keys, mapped onto values. The type of these values depends on the specific option.

All direct arguments to calls are mandatory, and the options argument allows for optional arguments to be added. options may always be left empty by clients.

Unless otherwise specified, all arguments and returns of type struct may include aggregate or resource-specific entries. As arguments, such options must be optional for the client to supply, with the aggregate providing a reasonable default.

This API specifies some options that should be supported by each AM. These are prefixed with :. AM’s may also support additional options, if they follow these rules:

See General Concepts and SFA Credentials and ABAC Credentials for more information on credentials.

Many methods take an array of credentials to authorize the caller to perform the given operation with the given arguments. This array argument is actually an array of structures specifying the credential type and version, as well as the actual string credential.

For methods that take a slice URN or list of sliver URNs, when using SFA style credentials, this icredentials list must include a valid slice credential, granting rights to the caller of the method over the given slice.

Each credential (in :value) is defined as a signed document. A given list of credentials may contain credentials in multiple formats. The list may be empty. A given authorization policy at an AM may require 0, 1, or many credentials. Aggregates are required to allow credentials which are not used by local authorization policy or engines, using only credentials locally relevant.

At least one subset of the credentials (e.g. a single SFA style slice credential) must authorize operations for the slice specified in slice_urn if that is an argument, or for the slice that contains the named slivers, if sliver urns are an argument, or a valid set of administrative credentials with sufficient privileges. When sliver_urns are supplied, all such slivers must belong to the same slice, over which the given credential set provides access. Methods that do not take a slice urn or sliver urns, but do take credentials, are interpreted to require credentials that authorize the user generally. For example, an SFA style user credential must be supplied. Credentials must be valid (signed by a valid GENI certificate authority either directly or by chain, not expired, and grant privileges to the client identified by the SSL client certificate). Each method requires specific privileges, which must be granted by the provided credentials. Note that the semantics of this argument is not clear: most implementations require a single credential to provide all needed privileges. Alternative interpretations might, for example, accumulate privileges from each valid credential to determine overall caller permissions. For details on GENI AM API format credentials, see the GENI wiki.

There are restrictions on what characters are allowed in the :type string:

Regular expression expressing these rule: ^[a-zA-Z0-9][a-zA-Z0-9-_\.:]*$

The [GetVersion] reply advertises which credentials types are supported, using :credential_type. See GetVersion Return Value for details.

Clients may omit this option, but aggregates must honor the option if possible. This option modifies the way that the operation applies to all named slivers. By default (:best_effort=false), the operation must apply equally to all slivers, either succeeding or failing for all (returning an appropriate error code). When true, the aggregate may succeed the operation for some slivers, while failing the operation for other slivers (returning a code of SUCCESS but then explaining the per-sliver error in the appropriate :error field for that sliver). This option applies to [Provision], [Renew], [Delete], and [PerformOperationalAction]. Each of these methods returns a set of statuses for each requested sliver, allowing the AM to report individual results per sliver. This option does not apply to [Allocate] or [Describe], which is always all or nothing.

Several methods take some URNs to identify what to operate on. These methods are defined as accepting a list of arbitrary strings called URNs, which follow the GENI identifier rules. This API defines two kinds of URNs that may be supplied here, slice URNs and sliver URNs (see the GENI identifiers page). Some aggregates may understand other URNs, but these are not defined or required here. Aggregates that accept only URNs defined by this API will return an error when given URNs not in one of those forms. This API requires that aggregates accept either a single slice URN, or 1 or more sliver URNs that all belong to the same slice. Aggregates are not required to accept both a slice URN and sliver URNs, 2 or more slice URNs, or a set of sliver URNs that crosses multiple slices. Some aggregates may choose to accept other such combinations of URNs. Aggregates that accept only arguments defined by this API will return a BADARGS error when given more than 1 slice URN, a combination of both slice and sliver URNs, or a set of sliver URNs that belong to more than 1 slice.

If the urns list includes a set of sliver URNs, then the AM shall apply the method to all listed slivers. If the operation fails on one or more of the slivers for any reason, then the whole method fails with an appropriate error code, unless :best_effort is true and supported.

If the list contains a sliver URN, and that sliver is deleted, expired or unknown, the call will result in a SEARCHFAILED error code. The value (which is optional, since this is an error) may optionally contain more details, such as info on the expired sliver.

If the list contains a slice URN, and that slice has no slivers, or only expired or deleted slivers, the call results in a SEARCHFAILED error code. The value (which is optional, since this is an error) may optionally contain more details, such as info on the expired or deleted slivers.

Note that for both cases above, it is possible that the AM has no info on expired or deleted slivers. because of this, the SEARCHFAILED error is the best error that can be guaranteed to be returned by calls that take a urns argument. Some aggregate might have info on expired slivers. They should NOT return an EXPIRED error in the cases above. Aggregates should also not return a more general error. Aggregates should also never return SUCCESS in the cases above, and just omit the sliver from their value.

This expiration_time argument of [Renew] call and the :end_time option of [Allocate] and [Provision], are similar, thay both specify the requested expiration time of the sliver. However, it is an an argument for [Renew], and thus it is mandatory to include by clients.

The :end_time argument/option requests an expiration of the specified slivers. It is in string.datetime.rfc3339 format.

When an explicit argument ([Renew]), it is required, and aggregates must honor the request to the extent local policy permits. They must return an error if they cannot honor this argument.

When :end_time is an option in the options struct ([Provision] and [Allocate]), clients may omit the option, and AMs may choose not to or be unable to honor this option, but may still succeed the overall request. If :end_time is supplied, the experimenter is requesting a particular sliver reservation expiration time. Local policy may however dictate the expiration time. The AM therefore may ignore this argument; the call should still succeed, even if the date argument cannot be satisfied.

An XML-RPC struct indicating the type and version of Advertisement ([ListResources]) or Manifest ([Provision] and [Describe]) RSpec this call will return. The struct contains 2 members, type and version. type and version are case-insensitive strings, matching those in :ad_rspec_versions as returned by [GetVersion] at this aggregate. Aggregates should return a :code of 4 (BADVERSION) if the requested RSpec version is not one advertised as supported in [GetVersion]. All aggregate managers are required to honor this option.

There are some restrictions on the allowed string for type and version. The following rules apply to both:

Regular expression expressing these rule: ^[a-zA-Z0-9][a-zA-Z0-9-_\.:]*$

For more details on RSpecs and RSpec versions, see the type string.rspec and the Rspec Document.

The :operational_status in the sliver info list is required, unless these 2 conditions are met:

:error may be omitted entirely but may not be null/None. :resource_status can be used to describe the resource specific status in more detail than :operational_status.

[PerformOperationalAction], [Renew] and [Delete] directly return the basic sliver info list array described above. [Allocate], [Provision], [Describe] and [Status] return a struct, which contains a sliver info list array and additional info.

Query static configuration information about this aggregate manager implementation, such as API and RSpec versions supported.

Return a listing and description of available resources at this aggregate. The resource listing and description provides sufficient information for clients to select among available resources. These listings are known as advertisement RSpecs.

Allocate resources as described in a request RSpec argument to a slice with the named URN. On success, one or more slivers are allocated, containing resources satisfying the request, and assigned to the given slice. This method returns a listing and description of the resources reserved for the slice by this operation, in the form of a manifest RSpec. Allocated slivers are held for an aggregate-determined period. Clients must [Renew] or [Provision] slivers before the expiration time (given in the return struct), or the aggregate will automatically [Delete] them. Aggregates should implement Allocate() as quick, cheap, and not impacting provisioned resources, such that it can be readily undone. Allocate is an all or nothing request: if the aggregate cannot completely satisfy the request RSpec, it should fail the request entirely.

At some aggregates, experimenter tools may call Allocate multiple times, to add resources to the existing reservation for the same slice. Other aggregates may limit such requests or forbid them entirely. See the Operations On Individual Slivers section.

As described in the Operations On Individual Slivers section, the :allocate return from [GetVersion] advertises when a client may legally call Allocate (only once at a time per slice, whenever desired, or multiple times only if the requested resources do not interact).

Request that the named :allocated slivers be made :provisioned, instantiating or otherwise realizing the resources, such that they have a valid :operational_status and may possibly be made :ready for experimenter use. This operation is synchronous, but may start a longer process, such as creating and imaging a virtual machine.

Redeem a reservation, requesting that the listed slivers move from :allocated to :provisioned. Only when slivers are provisioned are the resources instantiated and made ready for operational use. Note that at some aggregates and for some resource types, this operation may be a no-op. At other aggregates, this operation starts a long running process (e.g. loading an image on a machine and booting it). Tools should monitor the sliver status (by calling [Status]), looking for an operational state other than :pending_allocation. Depending on the resource type, that next state may differ. See the advertisement RSpec for the resource type specific operational states and actions.

As with the [Allocate] method, some aggregates may not support provisioning only some reserved resources. See the Operations On Individual Slivers section for more information.

As described in the Operations On Individual Slivers section, the :single_allocation return from [GetVersion] advertises whether or not a client may invoke this method on only some of the slivers in a given :allocation_state in a given slice (default is false - the client may operate on only some of the slivers in a given state).

When only a slice URN is supplied (no specific sliver URNs), this method applies only to the slivers currently in the :allocated allocation state.

Perform the named operational action on the named slivers, possibly changing the :operational_status of the named slivers. E.G. start a VM. For valid operations and expected states, consult the state diagram advertised in the aggregate’s advertisement RSpec. See also the [SliverOperationalActions Sliver Operational Actions] section.

Operational actions modify the running state of the resource, not the nature of the resources in the reservation. To add or remove resources from the reservation, use [Delete] and [Allocate]. Operational actions, and the states that result, are resource type and aggregate specific. Aggregates advertise these in the advertisement RSpec. Example actions include :start (boot a computer), :restart (reboot a computer), and :stop (power down a computer).

Aggregate Managers SHOULD return an error code of 13 (UNSUPPORTED) if they do not support a given action for a given resource. An AM SHOULD constrain actions based on the current operational state of the resource. This is a fast synchronous operation, and MAY start long-running sliver transitions whose status can be queried using [Status]. This method should only be called, and is only valid, when the sliver is fully allocated (operational status is not :pending_allocation).

While the action argument may be aggregate and sliver type specific (none are required for all aggregates and sliver types), this API does define three common actions that AMs should support if possible: :start, :stop, and :restart.

Get the status of a sliver or slivers belonging to a single slice at the given aggregate. Status may include other dynamic reservation or instantiation information as required by the resource type and aggregate. This method is used to provide updates on the state of the resources after the completion of [Provision], which began to asynchronously provision the resources. This should be relatively dynamic data, not descriptive data as returned in the manifest RSpec.

In contrast to [Describe], Status is used to query dynamic state information about slivers. Aggregates may include detailed configuration information at their own discretion.

Retrieve a manifest RSpec describing the resources contained by the named entities, e.g. a single slice or a set of the slivers in a slice. This listing and description should be sufficiently descriptive to allow experimenters to use the resources.

Describe is used to list the resources belonging to a particular reservation. The return is the standard AM API struct, with a value that is a struct that always includes a single manifest RSpec, describing the resources in the set of slivers whose URNs were supplied, or describing the entire single slice whose URN was supplied as an argument.

The manifest RSpec should contain all necessary details about resource identity, configuration, and access information necessary for experimenters to use the resources. As that configuration information may change as the resource becomes operationally :ready, this information may change. Otherwise, the manifest is mostly static.

Additionally, Describe returns basic state and expiration information for all queried slivers. Valid values for :allocation_status and :operational_status are described on the Common Concepts page.

Request that the named slivers be renewed, with their expiration extended. If possible, the aggregate should extend the slivers to the requested expiration time, or to a sooner time if policy limits apply. This method applies to slivers that are :allocated or to slivers that are :provisioned, though different policies may apply to slivers in the different states, resulting in much shorter max expiration times for :allocated slivers.

When Renew is called with :best_effort false, the entire method will fail (return non-zero :code) if any requested sliver cannot be renewed to the requested time, and all slivers will keep their original expiration time. When Renew is called with :best_effort true, some slivers may fail to be renewed. In this case, the allocation state and expiration times do not change. :error may optionally be returned by the aggregate to explain this failure.

As described in the Operations On Individual Slivers section, the :single_allocation return from [GetVersion] advertises whether or not a client may invoke this method on only some of the slivers in a given :allocation_state in a given slice (default is false - the client may operate on only some of the slivers in a given state).

Renew requests a changed expiration for one or more slivers in a slice. At some aggregates, this expiration may be shorter. This method applies both to slivers that are :allocated and to those that are already :provisioned. Depending on local aggregate configuration, the aggregate may only support Renew on all current slivers in the slice, or may permit renewing only some slivers. Local policy will dictate maximum expiration times. These times are typically quite short (~ 10 minutes initially, ~ 120 minutes maximum) for reservations (:allocated), and longer for provisioned (:provisioned) slivers (~ 5-8 days initially). Since these expiration times are different, typically Renew is used only for slivers in the same allocation state.

Delete the named slivers, making them :unallocated. Resources are stopped if necessary, and both de-provisioned and de-allocated. No further AM API operations may be performed on slivers that have been deleted.

As described here, the :single_allocation return from [GetVersion] advertises whether or not a client may invoke this method on only some of the slivers in a given :allocation_state in a given slice (default is false - the client may operate on only some of the slivers in a given state).

Delete the given slivers, stopping any running resources and freeing the reservation. This method applies to slivers in any state.

As with the [Allocate] method, some aggregates may not support deleting only some slivers.

Perform an emergency shutdown on the slivers in the given slice at this aggregate. Resources should be taken offline, such that experimenter access (on both the control and data plane) is cut off. No further actions on the slivers in the given slice should be possible at this aggregate, until an un-specified operator action restores the slice’s slivers (or deletes them). This operation is intended for operator use. The slivers are shut down but remain available for further forensics.

This operation is similar to ProtoGENI’s Shutdown operation. The SFA specification does not include this operation.

This operation is for operator use, to stop a misbehaving resource. Once shut down, the slivers are not available for experimenter use. The underlying resources may be returned to the pool of available resources, depending on resource type and aggregate implementation.