102 | | The experiment controller is responsible for getting access to resources at the various testbeds, creating the sub-topologies that make up the federated experiment, and interconnecting them. As the experiment runs, the experiment controller can monitor and |
| 102 | The experiment controller is responsible for |
| 103 | |
| 104 | * Getting permission to access to resources at the various testbeds |
| 105 | * Coordinating the creation of the sub-topologies that make up the federated experiment |
| 106 | * Requesting their interconnection |
| 107 | |
| 108 | As the experiment runs, the experiment controller can monitor and perform coarse control operations on the various elements of the experiment. Controls are coarse because of the wide variety of elements that might be federated. In testbeds that require periodic renewals of resource reservations, the experiment controller handles them. Finally the experiment controller is responsible for coordinating the release of elements when the experiment ends. |
| 109 | |
| 110 | These functions are accessed by users via comand line tools available on DETER and packaged with the federation system. |
| 111 | |
| 112 | Each experiment controller creates a namespace of users and groups those users belong to. When the experiment controller contacts an access controller to request resources, the user and group information (as the experiment controller knows it) is passed on. The access controller makes its decisions based on that information. All of the information and policies about dealing with that information is encoded in [http://groups.geni.net/geni/wiki/TIEDABACModel ABAC]. DETER provides tools for generating basic user/group mappings. |
| 113 | |
| 114 | The main DETER testbed (DETERLab) runs an experiment controller that exports DETER users and the projects to which they belong. This provides a simple way for federating testbeds to add their users to the DETER namespace by registering as DETER users. In addition, it is simple to map back from DETER user names and groups (projects) into local access control. |
| 115 | |
| 116 | Other documentation provides more information about running an [FeddExperimentController experiment controller]. |
| 117 | |
| 118 | == The Access Controller == |
| 119 | |
| 120 | An access controller runs for each testbed that makes resources available via the DFA. Researchers carrying out experiments rarely, if ever, interact directly with an access controller. It is responsible for |
| 121 | |
| 122 | * Authorizing accesses based on ABAC information provided by the experiment controller (and local policy) |
| 123 | * Reserving, connecting and intializing local resources based on requests from the experiment controller (and local policy) |
| 124 | * Implementing the coarse controls requested by the experiment controller (within local policy) |
| 125 | * Safely releasing local resources |
| 126 | |
| 127 | The access controller translates between the fairly generic experiment ontroller primitives and the testbed-specific resource controls that a local testbed requires. |
| 128 | |
| 129 | There are access controllers available for several existing testbed architectures: [http://deter-project.org DETER], [http://emulab.org Emulab], [http://groups.geni.net/geni/wiki/GAPI_AM_API GENI AM], [http://ww.starbed.org StarBed], and [FeddDesktop desktops]. The existing controllers are configurable for a wide range of network connections (behind a NAT or not, etc.) and policies. |
| 130 | |
| 131 | For new testbeds, the architecture and code is structured as a [FeddPluginArchitecture plug-in architecture]. New code can make use of existing code to parse and handle the basic operations and act as a base for specialization. |
| 132 | |
| 133 | [FeddAccessController Access Controllers] are more deeply documented. |