Network measurements aim at characterizing the performance, behavior, dynamics, and structure of different kinds of networks. From an implementation viewpoint, the currently available measurement tools are typically coded in low-level programming languages (usually C) to avoid the impact of high-level programming language features — e.g. garbage collection and exception handling mechanisms — on the accuracy of measurement results. As a consequence, most of such tools present a potentially high development time. Besides, such tools are based on very low-level network APIs (usually BSD socket-like APIs), which hinders higher levels of code reuse across tool projectsm — this is easily observable in the open-source codes of several publicly available measurement tools. Further, the absence of standards in these tools with respect to the collection and storage of measurement data brings inconveniences to their integrated use in the existing measurement platforms.
Here at our MARTIN Lab we developed a platform for the rapid prototyping of active measurement tools, i.e. tools based on the sending of probes (packets with the single purpose of performing measurements) between network nodes, thus allowing the measurement of network properties along the path linking such nodes. Our platform, named FLAME (Flexible Lightweight Active Measurement Environment), allows the rapid prototyping of active measurement tools even if the targeted network metric depends on a cooperative destination node, i.e. a destination node that hosts (part of) the measurement tool.
The FLAME platform is based on the distribution of measurement agents among some network nodes. Such agents send and receive probe packets in response to commands from a central manager. Users issue such commands to the central manager with a command line-based console. The agents return the collected measurement data to the central manager, which publishes such data in a standardized way on a central repository, simplifying the management and further analysis of such data. All communication among the 3 components is based on the XMPP protocol. The figure below illustrates the FLAME architecture.
The FLAME platform offers its users active measurement primitives to be executed in the agents. Users can use the console to prototype active measurement tools upon such primitives in a rapid, practical, and efficient manner. The central manager is responsible for deploying such tools and starting their execution in the agents.
Tool prototyping in the FLAME platform is based on the Lua scripting language. Lua is adopted in FLAME as an extension language: its interpreter is embedded as a library into the measurement agents. On the one hand, the Lua interpreter gives to the scripts running in the agents access to active measurement primitives through a high-level, minimalist API. On the other hand, the measurement agents and the measurement API are implemented in C, preventing significant overheads in the measurement results due to the execution of Lua scripts.
The names of the probing operations offered by the measurement API follow the
send[protocol][type](...) structure, where
protocol indicates the protocol used for sending probes (in the current implementation,
ICMP are available), and
type indicates if the probes are bidirectional (
TW — Two Way), unidirectional (
OW — One Way), or sent in a burst (
PT — Packet Train).
The TW operations do not depend on cooperative destination nodes and the results obtained with these operations are collected in the source of the experiment. In this case, the source node is responsible for sending the results to the measurement manager.
The OW and PT operations depend on cooperative destination nodes. In this case, a destination node is responsible for collecting the results and sending them to the measurement manager. Such operations, however, also instruct the destination nodes to send the collected results back to the source node after the operation execution. This is important when the developer needs to implement active measurement tools that rely on successive iterations based on the feedback from the cooperative destination nodes to properly measure certain network characteristics.
All probing operations of the measurement API return a Lua table containing the collected results, in case of success. Such probing operations are extensibly parametrized, but without impacting significantly on the usability gained with a minimalist API, given that several parameters are optional and, when omitted, receive default values.
Besides probing operations, the measurement API also offers other operations, such as
sleep(...) (to suspend the execution of a script for a certain amount of time).
Some examples of tools implemented with the measurement API (like
owping) can be downloaded here.
You can download the source code and find install instructions here.
For a quick try on our FLAME platform, we also provide a Web console that allows experiments to be conducted on our local testbed in a controlled manner. The Web console can be accessed from here. If you have any problems with accessing the Web console, please send a message to
email@example.com describing your problem.
The FLAME platform described here has NOTHING TO DO with the FLAME malware discovered in 2012. Our FLAME platform is for the rapid prototyping of active measurement tools, as described in the platform website.
We've become aware of some supposedly "news" published in this link in 2012 about a malware called FLAME, that has been associated in a related post at the aforementioned website with the FLAME platform developed by our MARTIN group at LNCC.
In light of the above, we'd like to make it very much clear that:
As a final remark, we emphasize that all this matter boils down to a unfortunate coincidence of a malware having the same name as the acronym we’ve been using since 2010.
Hoping to have clarified the matter, our best wishes.
MARTIN Lab team.