FLAME – A Flexible Lightweight Active Measurement Environment

Last modified on Monday, March 4th 2013 at 6:46 PM.

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.

About FLAME

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, UDP, TCP, and 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 ping, traceroute, pchar, and owping) can be downloaded here.

Using FLAME

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 martinlab@lncc.br describing your problem.

Publications

1. ZIVIANI, A. ; CARDOZO, T. B. ; GOMES, A. T. A. . Rapid Prototyping of Active Measurement Tools. Computer Networks, Elsevier, 2011. Accepted for publication.
2. ZIVIANI, A. ; GOMES, A. T. A. ; KIRSZENBLATT, M. L. ; CARDOZO, T. B. . FLAME: Flexible Lightweight Active Measurement Environment. In: International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom), 2010, Berlim, Alemanha. Proceedings of the 6th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities, 2010.
3. KIRSZENBLATT, M. L. ; CARDOZO, T. B. ; GOMES, A. T. A. ; ZIVIANI, A. . FLAME: Uma Plataforma para Prototipagem Rápida de Ferramentas de Medição Ativa. In: Salão de Ferramentas do XXVIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC), 2010, Gramado, RS. Anais do XXVIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos. Porto Alegre, RS : Sociedade Brasileira de Computação (SBC), 2010.
4. KIRSZENBLATT, M. L. ; CORREA, B. S. P. M. ; ZIVIANI, A. ; GOMES, A. T. A. . Prototipagem Rápida de Ferramentas de Medição Ativa. In: Workshop de Gerência e Operação de Redes e Serviços (WGRS), 2009, Recife, PE - Brasil. Anais do XIV Workshop de Gerência e Operação de Redes e Serviços, 2009.

IMPORTANT NOTE

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:

• The FLAME environment developed by our MARTIN group at LNCC is NOT malware. We're aware of at least two other packages with the same name, it's simple and easy to make an acronym from such an appealling word, therefore it's quite likely the are other packages, including the cited malware, share this same name.
• Our FLAME environment does use Lua, but for the purpose of sending ICMP, TCP and UDP measurement probes. Crucially, our environment does not allow specially-crafted payload to be conveyed in such probes. Also, by no means it has any kind of code that allows recording audio, taking screenshots and other announced characteristics of the cited malware.
• The top hit for "FLAME Lua" on Google points to the website of our FLAME platform. The platform website has been online since November 2009.
• the source code of our FLAME environment hasn't been publicly available. A specific request for it must be made by email, explaining the requester's intended purpose. So far, we havent received such requests (the first one was a couple of hours ago, motivated by the news about the cited malware). Therefore it's unlikely that the cited malware has been even based on our package.
• Our FLAME platform only compiles on Linux. The cited malware is for Windows-based systems.
• The Lua code and log snippets presented in this link have never been part of our FLAME environment.

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.

END OF NOTE