33 | | Fedd plays the role of the Federator in the diagram above. |
| 33 | Fedd plays the role of the Federator in the diagram above. It is divided into two parts: |
| 34 | |
| 35 | '''Experiment controller''':: |
| 36 | Presents the abstraction of a federated experiment to the users. Allows allocation, configuration, and release of resources to the federated experiment. |
| 37 | '''Access Controller''':: |
| 38 | Negotaties access and allocation of resources from federant testbeds. |
| 39 | |
| 40 | The access controller is depicted by the regular plug-in shapes in the federator. These are standard plug-in interfaces that allow standard access to a variety of testbed types. Currently emulab style testbeds and DRAGON style transit networks are supported. The regular system interface to fedd allows new systems to be added easily. |
| 41 | |
| 42 | Depending on the nature of the access controller it may be implemented on the local testbed, on the same host as the experiment controller (even in the same process) or partially in both places. This depends on the access mechanisms of the underlying testbed and the policies of the administrators. We have implemented plugins for Emulab-style testbeds that run completely remotely and access the testbed through ssh and plug-ins that run on the Emulab testbed directly and communicate outside the testbed entirely through fedd interfaces. Access controllers that run directly on the remote testbed have more discretion in executing privledged local commands than remote access controllers. |