RSpec Lifecycle

In the Beginning

RSpecs are used to transfer information about topologies. There are two main uses for it. First, it can be a description of what resources there are and the attributes of those resources. For instance, I might want to say that I have two nodes available and there is a physical wire between them and that they are 3 Ghz machines. This is an advertisement. Advertisements are generated by component managers.

Second, RSpecs are used as a way to talk about what resources a client wants to allocate. These are requests. Requests can be specific (bound): "I want node 54 and node 36 and wire 28 which connects them." But they can also be ambiguous (unbound): "I want a couple of nodes with some kind of link between them". They might even be partially bound "I want node 54 and node 36 and make some kind of link/tunnel between them."

These two RSpecs move through different pipelines. Each stage of the pipeline may modify an RSpec. RSpecs can have annotations added to make them more specific ("They said they wanted a couple of nodes, I will add annotations to bind those to node 54 and that node 36"). In addition, RSpecs can be split into parts and then combined or recombined with other RSpecs.

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

Advertisement Pipeline

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 with no virtual annotations.

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.

Request Pipeline

Request RSpecs contain a complete, partial, or empty mapping between the virtual resources a client might desire and the physical resources available on component managers. A request is unbound if there are links or nodes which are not mapped to physical resources. 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_uuid field on each virtual link and virtual node. This virtual_uuid field should be unique globally. Note that the virtual_uuid is distinct from the uuid of any sliver instantiated on a resource. Since the virtual_uuid is created by the client, it cannot be used as a lookup key for services by component managers. 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 path of many links and nodes, the physical annotation of a link consists of a path element with a list of UUIDs which make up the route of that path.

Once a client has sent the request to slice embedding services, it will split it the now-bound request up and acquire a ticket on the aggregate managers specified by the annotated RSpec. The requests which it sends may be bound (every node and link has physical UUIDs) 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.

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 should contain the request RSpec annotated with sliver_uuids. This will allow the client to associate their original requests with the slivers they have received.