OMF6

OMF (http://omf.mytestbed.net) is a generic framework which allows the definition and orchestration of experiments using shared (already provisioned) resources from different federated testbeds. OMF was originally developed for single testbed deployments, but has recently been extended to support multiple deployments and the following features. First, it provides a domain-specific language based on an event-based execution model to fully describe even complex experiments (OEDL). OMF also defines a generic resource model and concise interaction protocol (FRCP), which allows third parties to contribute new resources as well as develop new tools and mechanisms to control an experiment (as mentioned on the previous slide). It has a distributed communication infrastructure based on XMPP supporting the scalable orchestration of thousands of distributed and potentially disconnected resources.

But how does this OMF experiment control work? This is depicted on the slide. At the bottom the resources are depicted, in this case an embedded PC with several wired and wireless connections. On the OMF layer, three entities can be observed. The Aggregate Manager (AM) is responsible for the inventory, disk imaging and chassis management (powering nodes on or off when needed. The second OMF management entity is the Experiment Controller (EC). It processes a description of the experiment scenario (written in the OEDL language), and will automatically trigger the right actions at the right nodes when needed. Although it is part of the OMF management layer from a logical point of view, the EC can both be provided as a service by the testbed, and can be run locally by the experimenter on its own PC. To perform these actions at the resource, the EC will send a message to a daemon running an every resource: the Resource Controller (RC). The RC is capable of executing everything what a user could do manually on the command line. It can also make abstraction of certain commands by wrapping them in OMF commands. An example is the OMF command to change the Wi-Fi channel. Behind the curtains it will determine which wireless driver is used on the resource, and will then select the suitable set of command line commands to execute, depending on the driver. To support this messaging between EC and RC, an XMPP service is used. Hence a XMPP server is added as the third entity of the OMF control framework. The protocol used by the EC to request actions at the different RCs is FRCP.

So the experiment control is executed as follows:

1. The experimenter gains access to the PC that runs the EC (his own PC, or a server at the testbed that is reachable through SSH)
2. The experimenter starts the experiment control procedure by giving the command “OMF exec”. The name of the scenario description that is to be executed is given as an argument. The EC will process this description, and will initiate specific commands at certain resources at the appropriate time.
3. If the target node is powered off, the EC will call the chassis manager service of the AM to power it on. For this it will send an appropriate XMPP message.
4. Once the target node is powered on, the EC will request the RC running at the desired resource to perform a certain command. As mentioned, this can be any command that could also be given on the command line manually. To trigger the RC, an XMPP message is sent from the EC to the RC. This message is compliant with the FRCP protocol.

It is a common misassumption that OMF and OML are the same things, while in fact they are not. OMF is the framework for provisioning and experiment control as described above. OML is an additional software suite targeting experiment monitoring. They are very often deployed together in testbeds, but this is not a strict requirement. From a logical point of view they can be considered as two separate entities. You can run OMF without running OML, and vice versa.