Version 2 (modified by, 15 years ago) (diff)


Fedd and GENI Clearinghouses

The contents and function of a GENI clearinghouse are evolving as GENI's control frameworks put usable systems on the ground. The clearinghouse itself is a collection of functionality generally related to helping users acquire and use experimental resources (slices).

An exact definition of a clearinghouse is somewhat difficult to nail down. The GENI Control Framework Requirements document does not directly state clearinghouse requirments, but the functional diagrams indicate that a clearinghouse is responsible for organizing principals, slices, and components as well as providing ancillary functions controlling resource allocations (tickets) and software distribution. Chip Elliot's comments at the 4th GEC outline a different set of requirements, including acting as a meeting point for resource users and providers, recording transactions, and implementing global policies.

It seems to us at TIED that the clearinghouse concept remains somewhat nebulous. That is a bit distressing, given that we are obligated to run one.

This page describes what we perceive to be the key aspects of a clearinghouse and how TIED implements them through fedd, though we will undercut that defintion somewhat by arguing that the aspects are largely orthogonal and grouped together somewhat arbitrarily.

What is a Clearinghouse and Do We Need One?

To the extent that there is agreement, a clearing house seems to:

  • Register information about principals that is relevant to resource allocation
  • Enable principals to find resources
  • Enable principals to allocate resources into slices, which are resource sets managed together, and manage them

In the course of constructing and manipulating a slice, records of the transactions are maintained and policies known to the clearinghouse can be enforced, in addition to policies that individual resource owners might enforce. The idea that such systems can enforce a global policy is worth a bit of exploration.

A global resource allocation policy implies that there is agreement on such a single policy between all resource providers and all slice alloaction systems. While this may be the case as the system grows, if the GENI/TIED interfaces become de facto standards, they will eventually be used by others who do not subscribe to the policies. To be clear, we consider a system that is flexibile enough to be so widely adopted a success.

We believe that such a distributed peer-to-peersystem can still represent and enforce policies across multiple resource providers - be they aggregates, clearinghouses, or something else. The power to do this lies in a more sophisticated authorization system. An authorization system that allows both sides to assess each other based on multiple attributes allows agreements on global policies to be expressed in terms of those attributes. A set of resource providers may make a fixed amount of their resources available only to slice creators that enforce some agreed upon cross-provider policy (e.g., an NSF allocation policy). In return, the slice managers would only allocate resources from providers that have agreed to abide by this policy. These attributes and their roles in allocation descisions would formalize an external agreement on policy. We believe that providing the mechanism to express these agreements makes it possible to make them enforcable in a large distributed system like GENI.

We are integrating usch a flexible negotiating system into coming versions of fedd. The ABAC system is being integreated into fedd as a prototype of such an expressive authorization system. This is an extension to our current simple attribute-based authorization.

The functions above are essential at some level, and it is clear that a control framework must provide them. What is less clear to us is that they interdepend to such an extent that they need to have a name and an architectural entity around them. Even more to the point, we are concerned that GENI may put unnecessary requirements around the clearinghouse set rather than more targeted and realizable requirements around the orthogonal functions.

Basically, while many useful functions have been attached to a clearinghouse, we have not been convinced that the clearinghouse is a necessary grouping. Furthermore, because of its ill-defined boundaries, additional functions and data requirements seem to adhere to clearinghouses. Architecturally we prefer to limit ourselves to essential well-defined abstractions and remove the rest. As a result we do not usually consider clearinghouses when defining TIED operations and implelentations.

Fedd functions

Fedd provides three main functions to principals:

  • Principal registration (binding principals to federation access information)
  • Experiment (slice) creation and management
  • Testbed (aggregate) access control

While principals can create their own identity, until a federation daemon attaches attributes to that entity that can be used for creating experiments, the identity is not very useful. In order to allocate resources, the federation system needs access to the attributes used to get access (in fedd, the three-level names).

Fedd acquires access to the various testbeds/aggregates and translates its requests (in terms of generic aggregate operations) into the local implementation of the resource allocation. Right now, there is a plug-in interface with only an Emulab interface plug-in in place. This translates fedd operations into Emulab operations; future plugins will convert fedd operations into other interfaces - DRAGON and ProtoGENI are planned.

Slices are principals with identities. Fedd operates on those principals, meaning that slices can be queried and destroyed in addition to their creation. Eventually they will be modifiable as well.

In the same way that the internal plug-in interface unifies resource allocation, a fedd running on each aggregate acts as an access controller for that aggregate, unifying the access controls. By unifying the access and allocation interfaces to aggregates, fedd acts as an aggregate controller.

These operations are similar to the ones outlined for clearinghouses. The largest difference is that fedd's knowledge and advertisement of resources is not well documented and scalable. For the moment, it does not limit fedd's use because the number of resources available is fairly small.

As we TIEDClearinghouse have described elsewhere, we consider fedd and DETER to be functioning as the TIED GENI clerainghouse.

Modularity of Clearinghouses and Fedd

Though fedd implements several independent functions, those functions are implemented in a single codebase with a single name. To be consistent with our position on clearinghouses and modular function, we intend to tease those functions apart. In the same way that creating an artificial connection between clearinghouse functions has obscured their modularity and clean boundaries, putting too much function in one codebase has doen the same for the fedd functions.

This is more than an academic concern. It is more difficult to explain the federation model that underlies TIED when the provider of various functions has the same name. Furthermore, there is a danger that the code itself is not respecting the clean lines that we believe separates the three functions. As such, we will be reorganizing the fedd code to walk the walk of our architectural talk in the near future.


Though we believe that the TIED fedd-based system implements a prototype clearinghouse to the extent that a clearinghouse is defined, we believe that the key functions of clearinghouses are best left decoupled. In order to demonstrate this we are restructuring our implementation to more clearly reflect those boundaries and use that code to continue to provide current functionality as well as future operations.

In addition we are extending fedd to operate on different kinds of aggregates and to incorporate an authorization system that is expressive enough to support broad policy negotiation.