## 4 Methods
### Integration and Use of Third-Party Tools in OMF  
This section presents how a third-party tool can be integrated into the OMF measurement library and how it can be used in an experiment. Figure 2: Current OMF-enabled testbed. The task of integrating and using a tool in OMF consists of three steps. These are (i) creating the measurement point definitions inside the source code of the tool, (ii) creating the tool definition file, and, finally, (iii) integrating and using the tool in OMF experiments. To explain these stages in more detail, we use the pathload [25] tool which estimates the end-to-end avail-bw on a path and converges to a range of avail-bw that is defined by a lower and upper bound value. From a practical point of view, a user can run this tool by starting a measurement client and server at the sender and receiver hosts, respectively. The client is responsible for sending the carefully scheduled probing packets which are received and analyzed by the server to estimate the final avail-bw range on the receiver host. As the first stage, the source code of this tool should be extended with measurement points so that it sends the final estimation to the OML server instead of the standard output. In this case, we defined two measurement point metrics: the lower and upper bound avail-bw estimates. In OMF terminology, this extended version is also called the OMLized tool. To be able to use this OMLized tool in an OMF experiment, declaration of a corresponding OMF tool definition is needed as the second stage. A tool definition can be viewed as an interface that makes the OMF EC aware of the tool. More specifically, it defines which parameters the tool accepts, which measurement points it provides, and where to find the tool to be executed. Since pathload is a both-ended tool requiring the cooperation of the sender and receiver components, an additional tool definition should be written for its sender component, too. However, since the actual measurements are only performed by the receiver component, the tool definition file for the sender component does not provide any declarations of measurement points. Finally, to run an experiment with pathload in OMF, the experiment scenario should be described in an experiment description file. It contains detailed descriptions of the resources involved in an experiment and the sets of actions to perform in order to realize that experiment. In this case, the resources are two research nodes acting as the sender and receiver hosts running the client and server components of the tool. The action corresponds to the start of these components with appropriate parameters to perform the measurement. Usually, the duration of an OMF experiment will be explicitly customized in the experiment description file. However, since the pathload tool is based on an iterative algorithm that converges to a final estimate depending on current network conditions, its exact duration cannot be anticipated in advance. Thus, for the parallel termination of the pathload tool and the experiment description executions, we use event-driven mechanisms that are provided by the OMF framework. More specifically, the EC holds and updates an XML tree of states about the running experiments and the involved resources that can periodically be observed and caught via event-driven mechanisms. Examples of some experiment states include the start of a tool or its termination with success or failure. Fortunately, OMF allows querying such states during the experiment runtime. Thus, using an event-driven mechanism, whether or not the pathload execution has finished is checked. If yes, a corresponding final event is triggered for terminating the entire experiment. The procedure for integrating and using tools in OMF is of generic nature and can be applied to all third-party tools. To enrich the test environment with more OMLized tools, we performed a survey of the literature related to network management and measurement research in order to identify the well-known and most often used tools.