T1.2 mPlane Architecture Specification

Lead: ETH

This task will define the mPlane general architecture. While the exact arrangement of components and interfaces will be determined after requirements and analysis, we envision an architecture consisting of four types of components, and the interfaces among them. The envisioned components are:

• mPlane probes, which passively or actively observe some aspect of network traffic or network performance, and generate intermediate results. Results may be generated for forwarding to repositories for later analysis, or streamed for real-time analysis on live traffic. The design and implementation of specific programmable mPlane probes for the identified use cases will be undertaken in WP2. Given the wide range of scales and types of measurements probes will be built for, there is very little that can be said about them generically from an architectural standpoint, except that they must:
• reduce captured data to the greatest extent possible, to minimize privacy risk and maximize scalability,
• analyze data directly on the probe, to the greatest extent possible, in order to support streaming analysis of live traffic and increase the scalability of the system as a whole,
• interact with repositories for intermediate- and long-term data storage,
• implement appropriate data export interfaces to cooperate with other Probes, and
• be controllable by an mPlane measurement Supervisor.
• Repositories which store intermediate or final measurement results across a variety of timescales, and provide a central point of computation for the calculation of results for particular measurement. As the computational and storage demands at the repositories may for some scenarios be quite high, the repository framework must allow for distributed processing of data sets across clusters of computers (as in, e.g., Hadoop) and/or for offloading of storage and computation to cloud providers (e.g. Amazon S3). As the distributed nature of many of our use cases will necessitate storage and calculation within different administrative domains, the repository framework must allow for a given measurement to use multiple repositories. The details of repository design and implementation will be undertaken in WP3.
• The mPlane Supervisor, incorporating a set of analysis modules and an intelligent reasoner which interacts with repositories for the computation of measurement results, and iteratively controls probes and repositories to “drill down” during analysis. This iterative process is managed by thereasoner, which automatically identifies probable causes and next measurements, with the assistance of domain knowledge information. The analysis modules and the corresponding algorithms by which mPlane performs measurements across multiple probes and repositories can be represented as “running” on the Supervisor. The design of the intelligent reasoner and the algorithms it runs to perform the measurements identified in our use cases will be undertaken in WP4, in coordination with WP3.
• A user interface, which allows configuration of probes and repositories; configuration of access control policies; authentication and authorization against the access control system; running measurements, viewing results, and using results interactively as parameters to new measurements. The user interface will be designed as a web application, and designed such that multiple UI instances may operate with the same controller simultaneously, to support multiple-user use cases.

More important than the components for the flexibility and interoperability of the platform will be the interfaces; the detailed design of these will be undertaken in T1.4.