| 21 | | 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. |
| | 21 | 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. |
| | 22 | |
| | 23 | 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. |
| | 24 | |
| | 25 | We are integrating usch a flexible negotiating system into coming versions of fedd. The [http://www.isso.sparta.com/research_projects/security_infrastructure/abac_overview.html 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. |
| | 26 | |
| | 27 | 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. |
| | 33 | Fedd provides three main functions to principals: |
| | 34 | |
| | 35 | * Principal registration (binding principals to federation access information) |
| | 36 | * Experiment (slice) creation and management |
| | 37 | * Testbed (aggregate) access control |
| | 38 | |
| | 39 | 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 [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Three-levelNames three-level names]). |
| | 40 | |
| | 41 | 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. |
| | 42 | |
| | 43 | 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. |
| | 44 | |
| | 45 | 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. |
| | 46 | |
| | 47 | 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. |
| | 48 | |
| | 49 | As we [wiki:TIEDClearinghouse] have described elsewhere, we consider fedd and DETER to be functioning as the TIED GENI clerainghouse. |
| | 50 | |
| | 51 | == Modularity of Clearinghouses and Fedd == |
| | 52 | |
| | 53 | 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. |
| | 54 | |
| | 55 | This is more than an academic concern. It is more difficult to explain the [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#TheDETERFederationArchitectureDFA federation model that underlies TIED] |
| | 56 | 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. |
