Control Frameworks

OMF Control Monitoring Framework

OMF [Rakotoarivelo 2010] is a framework developed in Ruby language and based on XMPP (eXtensible Messaging and Presence Protocol) with the focus on controlling and managing network devices. The OMF suite also provides OML (OMF Monitoring Library), which allows instrumentation of applications for collecting measurements. Actually, OMF depends on a suite of software components in order to provide services such as dynamic IP addressing, remote booting, remote OS imaging, data archiving, etc.
OMF was originally developed for the ORBIT wireless testbed at Winlab, Rutgers University. This former software only supported the specific ORBIT hardware resources (i.e. custom built static nodes with 802.11wireless devices), and provided a limited experiment description language. In contrast, the current OMF [OMF 2012] supports a large number of different wired and wireless resources, such as PC-like devices, Android phones, routers, sensors, among others.
The OMF architecture consists of 3 logical planes: control, measurement, and management. This architecture is not completely clear in version OMF 5.4, but it is the approach defined for the  forthcoming version 6. The control plane includes the OMF tools that a researcher uses to describe his/her experiments, and the OMF entities responsible for orchestrating them. The measurement plane includes the OMF tools to instrument an experiment, and the corresponding OMF entities to collect and store measured data. The management plane includes the OMF functions and entities to provision and configure the resources, which are provided by the testbed facilities and used by the experiments.

In the next Figure, there is a system view of an OMF deployment. The main OMF elements are detailed below.

A domain specific language (the OMF Experiment Description Language – OEDL) allows an experimenter to write an Experiment Description (ED), which details the resource requirements, their initial configuration, and a state machine describing the time/event-triggered actions required to realize the experiment.
The experimenter submits the ED to an Experiment Controller (EC), which is the control entity orchestrating the experiment on behalf of the experimenter. The EC issues requests on the management plane to configure the resources as specified in the ED. Once the experiment prerequisites are met, the EC sends directives to the Resource Controller (RC) associated with each resource.  Actually, the configuration of the resources is also done by the RC. Following the ED’s state machine, the EC sends directives to the RCs, which are the control entities responsible for executing actions on the resources.
The measurement plane consists of two parts, namely the Measurement Collection Server (MCS) and the Measurement Library (ML). OML allows recording of any relevant metrics and instrumented applications. The resulting streams are forwarded to the MCS either in real-time or batch mode to minimize interference with the experiment itself. The MCS stores them in a SQL database created for each experiment instance. The user can directly run SQL queries against it, or retrieve a data dump from it. Standing queries can feed events back into the EC to support steerable experiments.
The batch mode is monitoring part the disconnected operation mode, which also involves specific configuration in OMF elements. The capability of performing experiments with partial disconnection of mobile devices is an important feature which allows tests with smart phones, cars, DTN devices, etc.
Another important feature is the capability to visualize the measurements at real-time on the experimenter’s Web browser. This is useful for the beginners, but it can also help the experts to easily verify if the expected results are being generated at very begin of an experiment.
OMF combines a set of management services into an Aggregate Manager (AM). Thus, the AM is a collection of services, which can be deployed across multiple servers for performance and redundancy reasons. AM accepts request from the ECs or the testbed operator, and sends corresponding commands to the RC running on each resource. MCS may be treated as one of the services of the AM.
 

References

  • [Rakotoarivelo 2010] T. Rakotoarivelo, M. Ott, G. Jourjon, Iv. Seskar, “OMF: a control and management framework for networking testbeds”, ACM SIGOPS Operating Systems Review archive Volume 43, Issue 4, 2010.
  • [OMF 2012] OMF official site.http://mytestbed.net.

Historic of Control Frameworks used by the FIBRE Testbed

OCF: OFELIA Control monitoring Framework

The OFELIA Control Framework (OCF) was developed in the framework of the OFELIA testbed project, funded by the European Union 7th Framework Programme (FP7). Is is a open-source control framework that followed the evolution of Expedient and Opt-in manager [Naous, 2011], and the introduction of the VT-Manager, all publicly available (Codebasin) and intended to be of easy setup.

Expedient consists of several subsystems: an object relational mapping (ORM) database, a base platform subsystem, and at least two types of plug-ins, the so-called connectors and user clients. These plugins cooperate to provide the user interface for creating and managing slices across multiple island providers. The architecture depicted originally in Naous work can be represented by Figure below. In OFELIA, regarding the Expedient sub modules, they were substantially improved, in particular the WebUI, that is the most used and important part for the experimenters and the database.
In order to slice the OpenFlow resources to support multiple experiments and users, the Expedient system, from which OFELIA and FIBRE inherit some of the most important features, make use of 4 layers: at the bottom (identified in Figure 1 as IaaS Provider resources) are OpenFlow switches, then on top of them, the Flowvisor, the Opt-In Manager, and finally the OpenFlow Expedient connector. The Flowvisor is the most necessary part to isolate and support multiple experiments. At an abstract level, Flowvisor is a transparent proxy between many islands with OpenFlow switches and OpenFlow controllers used in a certain slice. Basically, the Flowvisor(s) present in each island (or provider) monitors OpenFlow protocol messages from and to the controllers, ensuring that each slice defined by the FlowSpace (a set of header values defined to isolate experiments) operates on traffic within that space.
The OCF, in addition to the expedient and opt-in pair, make use of an additional resource of a virtualization service, in order to provide, virtual machines to the users as end-hosts or in order to, allocate local OpenFlow controllers to test the experiments. Next Figure (extracted from Public Deliverable 5.1 of OFELIA Project) presents the main components of the OFELIA framework and the internal configuration of each OFELIA island.

As it can be verified, the OCF system uses LDAP as the main software authenticator, and provides the Virtualization Aggregate Manager based on Xen machines (called OXA – OFELIA Xen Agent) which can allocate on-demand virtual machines.

References

  • [Naous, 2011] JadNaous.Path-Policy Compliant Networking and Platform for Heterogeneous IaaS Management.PhD Thesis. Stanford. March 2011.
  • [White, 2010] White, J. (2010). A Tutorial Introduction to OML. GEC9. Available at http://omf.mytestbed.net/projects/oml.

Terra: a Wireless Sensor Network Control Framework

Terra’s goal is to facilitate the creation of WSN applications, specifically as refers to dealing with event-driven programming and with network programming. The Terra model is based on a virtual machine and combines a reactive scripting language with a set of customized components. These components may be selected as needed, creating customized virtual machines with abstractions provided by the component interfaces. A scripting language enforces a programming model that glues components together to create powerful applications in a few lines of code. This makes them suitable for creating programs that benefit from the pre-defined and pre-installed set of components and that can be easily sent over the network.
Terra uses Céu-T as its scripting language and provides a component-based virtual machine VM-T to be customized for different application domains. Céu-T implements a variation of the Céu programming language [SantAnna2013]. The Terra Virtual machine VM-T, with its customizations, runs on WSN nodes with limited resources. We built VM-T using the nesC programming language and the TinyOS [Levis2004] operating system. Below it is presented the three basic elements of Terra:
Terra’s guarantees for race freedom and against local starvation and invalid pointers contribute to safer code. These guarantees came, basically, from the static analysis of the Céu compiler and runtime checks of the VM-T execution.
 

References

  • [SantAnna2013] Sant’Anna, Francisco and Rodriguez, Noemi and Ierusalimschy, Roberto and Landsiedel, Olaf and Tsigas, Philippas, “Safe system-level concurrency on resource-constrained nodes.”, Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, SenSys ’13, 2013. http://dx.doi.org/10.1145/2517351.2517360
  • [Levis2004] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, D. Culler. “TinyOS: An Operating System for Sensor Networks”. Book Title: Ambient Intelligence, Part II, pages 115-148, 2005. http://dx.doi.org/10.1007/3-540-27139-2_7.