Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Aggregates




Emulab as an Aggregate

In our prototype, the set of software and services that is currently considered "an Emulab" will operate as an aggregate. That is, it will export a Aggregate Manager (AM) interface, which is nearly identical to the CM interface, with the difference that there are a set of components behind it rather than a single one.

One of the reasons we need to do this is to handle link creation. This is a coordinated operation, that might involve making VLANs on several switches, tunnels on multiple nodes, etc. The only way that the current GENI API allows for such coordination is through the use of an aggregate.

Adding and Removing Components From Aggregates

The AddComponents() and DeleteComponents() operations should not be part of the public API - they are really "behind the scenes" management interfaces, and we have no intention of implementing these two API calls. (Though, of course, something like them, but likely much more complicated, will be supported as backend operations.)

Aggregates And Slivers

While an aggregate is defined for a collection of components, it is not clear what a slice of an aggregate (sliver) looks like: is it considered an 'aggregate sliver', or several slivers?

One of the key reasons this matters is in regards to what one gets back from a CreateSliver() call on an aggregate - is it a credential for a single sliver? Is it a set of credentials for all slivers that got created by this call?

The answer we came up with is this: It returns a "handle" on the set of slivers created by the call. If one wants to operate on, or delegate rights to, all of these slivers at once, one can simply use the credential returned by the CreateSliver() call. However, we will add a new call to the API for an aggregate component manager that, given such a handle, returns credentials for all of the slivers inside.

In this way, the simpleness of the common case (operating on all slivers we got in the aggregate) is preserved, but users can also "look inside" of the slivers they have been given from an aggregate, in a hierarchy that exactly mirrors the original aggregate.

Without giving aggregates special information about or special privileges on the components underneath it, adding an aggregate on top doesn't help link creation.