La concepción y el estado fetal en el pensamiento nahua

testbeds have implemented the API correctly, all the blocks that SFA is composed of are ready.

Finally, the interaction between actors and abstract resources is shown in Fig. 4.8.

Fig. 4.8 SFA actors, authorities and abstract resources interaction.

The workflow to inact an experiment is the following:

1. Researchers need to first acquire valid credentials from the SA, which grants them specific access rights to the federated resources. Depending on these rights, the allowed specifics of the reservation may change.

2. Certificates allow researchers to correctly submit their custom Rspec to the SM.

As we previously said, Rspec definition depends on each testbed and federation, because the SFA simply defines basic interfaces, therefore GENI suggests to use predefined tools such as Flack [75], or to modify existing examples.

3. The SM then parses the Rspec and forwards the request to the target AM, which grants an experimentation ticket to the researcher, with predefined expiration date and rights of use. Together with the ticket, the AM instances the requested slice, which is, from now up to the expiration date, reserved.

4. The experiment must agree with the final policy of use, which is always defined by the component owner. Policies may determine maximum durations for the experiment as well as restrictions on the diffusion of the collected data to the general public.

Fed4FIRE Federation

5. Once the researcher submits a valid experiment, the AM disseminates the already instanced components with the experiment code, and the experiment is started, and the researcher’s focus may shift without any issue on the monitoring tools provided by the federation.

6. When either the ticket expires or the experiment is concluded, and in case the researcher didn’t refresh its subscription, the slice is automatically erased and the resources are released for future uses.

This concludes the formal introduction to the SFA architecture. Any other imple-mentation detail is out of our concern, for now. Fed4FIRE integrates SFA modules in a specific architecture, which can be seen in Fig. 4.9, that describes the resource discovery, reservation and provisioning architecture. In this case, the role distribution is the following:

• The Testbed shall provide the physical resources and their interfaces, like an SSH server or a service on top of them. In order to be able to manage them in a federated way, it is mandatory to provide a compliant Aggregate Manager [AM] (see next). Finally, if willing to do so, it can also offer additional federation services that match the Federator ones (member and slice authorities).

• The Federator must provide a registration portal, a documentation center, member and slice authorities (see next), as well as directories for authorities, services and AMs.

• The Experimenter should be equipped with a compliant browser, together with stand-alone tools (if needed, like SSH client, FTP client, etc.).

All these and additional information can be found in [76].

As a review, we recall that the SFA framework aims to provide a flexible back-ground for component-based architectures, that - due to dependencies, privileges and a reservation system - may assume a hard-to-deal-with, non-linear structure. This is performed through a series of abstraction, that ease the way in which resources are handled throughout the federation. In addition, the SFA framework also allows to secure the communication between different layers of the architecture, by means of certification authorities, credentials, and firm policies. It is not the only solution viable to build large federation, be it clear, but its good features made it popular in the field.

Additionally, large freedom of implementation is granted by the architecture, and the presence of many existing, open source implementations of this architecture helped its

4.3 Federative Technology: OML, SFA, OMF

Application ServicesTestbed resourcesTestbed management

Testbed with nodes

API Used also outside F4F Proprietary API

Aggregate

Fig. 4.9 Fed4FIRE architecture for discovery, reservation and provisioning diffusion. The one we employed for our contribution was developed under the FiTeagle Project [77], and we chose it as it granted us the largest degree of freedom and ease of use, while being an almost stand-alone application.

4.3.3 Orbit Management Framework [OMFv6]

OMF [78] is a Testbed Control, Measurement and Management Framework, and, in its latest release, Version 6, it is one of the supported experiment control tools in Fed4FIRE. As well as OML, OMF was originally developed for the ORBIT wireless testbed at Winlab, Rutgers University. Since 2007, OMF has been actively extended to operate on testbeds with many different type of network and resource technologies.

It is now deployed and used on different testbeds in Australia, Europe, and in the U.S. OMF is currently being extended further to support exciting new features and technologies.

It is a powerful tool, that from the experimenter’s point of view, provides a set of tools to describe and instrument an experiment, execute it and collect its results, while from the testbed operator’s point of view, provides a set of services to efficiently manage and operate the testbed resources.

Fed4FIRE Federation

OMF client and server application comes as standalone, as its measurement coun-terpart OML, and the framework exists out of 3 parts:

• Every node runs a Resource Controller (RC)

• There is one Experiment Controller (EC) from where the experiment control script runs

• There are PubSub servers which send around the FRCP messages between the EC and RCs

Experiment description can be performed through OMF, using the OMF Experiment Description Language (OEDL) [79], which is based on Ruby, but provides its own set of experiment-oriented commands and statements.

An OEDL experiment description is composed of 2 main parts:

• A first part where we declare the resources that we will use in the experiment, such as applications or computing nodes, and some configurations that we would like to apply to these resources.

• A second part where we define the events that we would like to re-act to during the experiment’s execution, and the associated tasks we would like to execute when these events occur.

For additional informations, refer to the main documentation of OMF. Fundamen-tally, all testbeds within the federation should support FRCP-based experiment control, therefore also OMF; further information on the state of the implementation within each testbed can be recovered from Fed4FIRE documentation.