RSpec Lifecycle

RSpec Variations

There are four different kinds of RSpecs to serve different purposes in the ProtoGENI system. Advertisements describe resources provided by component managers. Requests describe the resources that a client wants. Tickets are resource reservations which are promised by a component manager to a client or broker. Finally, manifests map the resources actually received by the user to configuration and other dynamic information for those resources.

The four different kinds of RSpec mean fundamentally different things and are used in different ways. Below is a description of how each one is used.

Advertisements

The basic RSpecs in the advertisement pipeline are generated by component managers or aggregate managers in response to resource discovery requests. Advertisements contain only physical information about the node.

Additional information about components may come from other sources, such as measurement services. Measurement services are independent services which monitor nodes and can provide information which may be relevant to the use of those nodes. This information can be static information, like motherboard chipsets or memory capacity. Or it may be transient such as CPU load or network usage. Transient data is taken care of by extensions. Because such a service provides its data as an extended RSpec, gathering measurement data can take the form of annotating an advertisement.

Advertisements may be split or combined by clients. An arbitrary subset of nodes and links may be chosen in a split. A split advertisement retains all of the nodes or links adjacent to the remaining nodes as external references. When RSpecs are combined, so are external references. When RSpecs are combined, external references are merged. No links or nodes are assumed to exist between the two RSpecs except where an external reference of one RSpec points to a node or link in the other RSpec.

Combined RSpecs may be from different administrative domains or sites. This has two implications. First, the administrative domain must be a per-node and per-link annotation. Second, there are no implicit network links; any possible links between the domains, such as VLAN "peering points" or possible tunneling over other networks (such as the Internet) must be explicit.

Advertisements are passed along with request RSpecs to slice embedding services (the advertisement being the physical topology and the request being the virtual topology.)

Advertisements may be used as an information source when generating a request RSpec.

Requests

Request RSpecs contain a complete, partial, or empty mapping between the slivers a client might desire and the physical components available on component managers. A request is unbound if there are links or nodes which are not mapped to components. A request is bound if every link or node is so mapped. A virtual node is a logical network device. A virtual link may be mapped either to a physical network link or to a physical network path.

Requests are generated by clients and are generally unbound. Each client fills in a virtual_id field on each link and node. This virtual_id field should be unique to the request. This is used as a key so that a client may later determine which bindings were on which nodes in their original request.

Requests are passed, along with advertisements to slice embedding services. An annotated request is returned to the client. The annotations will bind some or all of the links or nodes of the request. Multiple slice embedding services may be used in turn to bind the request RSpec in different ways or to different aggregates.

Request RSpecs may be split or combined by clients similar to advertisements. This is useful, for instance, to map specific parts of a topology to specific advertisements. Once that is done, they may be recombined and sent to a final slice embedding service which can bind the connections between the two parts.

Since links can be bound to a graph of many links and nodes, the physical annotation of a link consists of an element with a set of physical resources which make up the graph of that path.

Once a client has sent the request to slice embedding services, it will send the request to the aggregate managers specified by the RSpec and acquire tickets The requests which it sends may be bound (every node and link has component IDs) or unbound (some nodes have partial bindings, such as just the CM to request from). Every node in the request must have a physical CM bound.

Tickets

Each CM returns a ticket or a failure. The ticket is either a bound ticket or an unbound ticket, depending on whether the request was bound or unbound. Each ticket represents a reservation of either a particular set of nodes or a general pool of nodes with particular attributes.

An unbound ticket must be exchanged for a bound ticket rather than redeemed. Once all tickets are bound, then they may be redeemed for the slivers. The result of redeeming a ticket is a credential which allows access to the slivers and a manifest which provides information about them.

Manifest

The manifest describes the slivers added to a slice and maps those slivers to dynamic information which facilitates the use and configuration of those slivers. A component manager creates the manifest as an annotated version of a ticket and returns it as one of the results of the RedeemTicket XMLRPC call. Since the manifest is simply an annotation of a ticket, it provides a mapping of dynamic information to both the physical resources used and to the slivers actually created.

The manifest is used to convey useful information about the slivers to the user:

Node Hostname -- The manifest contains an optional hostname attribute on each node which can be used to log into the node or communicate over the network.

Interface MAC Address -- The manifest contains an optional MAC address of each interface so that the user can determine which interface on the actual node corresponds to the interfaces in their original request.

Interface IP Address -- The manifest contains an optional IP address of each interface.

The manifest will also contain other dynamic information which makes the use of a node easier to maintain for a user.

The manifest will also be used to provide a configuration channel between the component manager and the user client so that the user can specify how the component manager should set up the user's slivers.

We will be adding a 'Configure' XMLRPC call which accepts a manifest and modifies some dynamic state on existing slivers.