Version 1 (modified by 15 years ago) (diff) | ,
---|
Fedd and GENI Clearinghouses
The contents and function oa 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.
These functions 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 around them. Even more to the point, we are concerned that GENI requirements may put unnecessary requirements around the clearinghouse set rather than 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.