Changes between Version 1 and Version 2 of TIEDFeddMapping


Ignore:
Timestamp:
07/02/09 18:21:22 (10 years ago)
Author:
faber@isi.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TIEDFeddMapping

    v1 v2  
    11= Fedd and GENI Clearinghouses =
    22
    3 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).
     3The 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).
    44
    55An exact definition of a clearinghouse is somewhat difficult to nail down.  The [GeniControlFrameworkRequirements 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 [http://groups.geni.net/geni/attachment/wiki/Gec4presentations/GEC%204%20-%202.%20Chip%20wrap-up%20-%20draft%2030%20Mar%2009.ppt comments] at the [wiki:Gec4Agenda 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.
     
    1717 * Enable principals to allocate resources into slices, which are resource sets managed together, and manage them
    1818
    19 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.
     19In 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.
    2020
    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.
     21A 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
     23We 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
     25We 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
     27The 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.
    2228
    2329Basically, 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.
     
    2531== Fedd functions ==
    2632
     33Fedd 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
     39While 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
     41Fedd 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
     43Slices 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
     45In 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
     47These 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
     49As 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
     53Though 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
     55This 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]
     56when 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.
    2757
    2858
     59== Conclusions ==
     60
     61Though 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.
     62
     63In 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.