T2.1 Probe Platform Design and Implementation

Lead NETVISOR

This task defines and implements the common probe framework, ultimately enabling the distributed deployment and execution of measurement modules, where a module represents a small measurement primitive (e.g., measuring jitter). For this framework, all the details such as protocol encodings and language bindings for interfaces (query and command protocols, including capability descriptors), will be designed and implemented, as defined by T1.2.

Common software components (such as communication modules, data representation and transfer services, configuration and lookup services, measurement and pre-processing building blocks) are designed and implemented within T2.1. Data representation and transfer services (designed in T1.4) include generic means for measurement data reduction (filtering and compression), intended to reduce the load on transfer, storage and processing facilities. Common elements of probe Graphical User Interfaces are developed by T2.1.

The overall framework enables the specification of a number of different types of programmable probes, including:

• High-speed software probes with hardware acceleration: to be deployed at a relatively few, high-traffic network vantage points. To provide the required high performance, these probes will leverage the significant advances made in commodity hardware in the recent years to provide a high level of accuracy and task separation, and to support high-speed network interfaces with potentially hardware-accelerated packet processing (e.g., NetFPGA boards). Such interfaces are going to implement analysis and deep packet inspection code (such as POLITO’s Tstat) in reconfigurable hardware, targeting 10Gbps and beyond.
• End-User probes are installed on End-User devices such as PCs, smartphones, set-top boxes, smart TVs, etc. These are implemented as “traditional” software applications that users can install. Thus, End-User probes must have a small footprint and must be controllable by the user to not interfere with other applications running on the system.

In all deployment scenarios, resource management is a key challenge: probes are expected to run multiple different measurements (see in T2.2 for details), thus proper task isolation and resource provisioning is needed. For dedicated probes, technologies like virtualization, real-time scheduling and other low-level OS features are going to be examined and exploited. Another issue arises in the case of passive monitoring, where an mPlane probe will need to allow concurrent measurement tools to observe, where appropriate, the same packets, and to provide accurate time-stamping features.

The other main part of this task is to merge all mPlane probes into a coherent measurement plane. This includes providing scalable lookup and catalogue services so that the mPlane Supervisor can locate, select, control and query probes. This task is going to study which approach to take (e.g., clustering, federated services, replication or distributed solutions like DHTs), and implement the one chosen.

This task main contributions are:

• a high performance re-programmable traffic measurement and analysis platform, able to perform both active and passive measurements.
• a scalable management service representing the measurement plane and able to manage a potentially large number of diverse mPlane probes.