1. mPlane: project and architecture The need of an intelligent measurement plane for the internet FIRE-GENI workshop May 5-6, Cambridge USA Disclaimer: I’m not a testbed guy! I’m a measurement guy Disclaimer: I’m not a testbed guy! I’m a measurement guy Marco Mellia Politecnico di Torino for testbeds integration

2. 2 A complicated technology… The internet is a key infrastructure where different technologies are combined to offer a plethora of services. It’s horribly complicated. We sorely miss the technology to understand what is happening in the network and to optimize its performance and utilization.

3. 3 Who we are

4. 4 mPlane architecture

5. 5

6. 6

7. 7

8. 8 Sounds straightforward But the evil is in the details Sounds straightforward But the evil is in the details

9. 9 Key insights Three years isn’t enough time to rebuild all the tools we’ll need  we must support easy integration of existing probes and repositories. The core of the architecture is the mPlane protocol, anything which implements it a component... ...which can advertise its capabilities ...perform measurements or analyses given specifications thereof ...and return or indirectly export results therefrom Measurements completely defined by the types of data they produce and parameters they require.

10. 10 Architecture Overview

11. 11 Privacy and Data Protection (D1.2) Personal data must be protected to prevent re- identification of the subject; must be processed for specific, explicit, and legitimate purposes  Directives 95/46/EC, 2002/58/EC, 2009/136/EC Specific technical guidance for mPlane:  Anonymization/pseudonymization where necessary/appropriate  Mandatory access control for access to measurement data and infrastructure  Mandatory encryption for all control and data interactions

12. 12 mPlane Protocol Message-oriented exchange of capabilities, specifications, and results. Based on a message information model with bindings to multiple representations and session protocols  HTTPS (with X.509 mutual auth) or SSH sessions Session-provided identity to integrate with RBAC  JSON over HTTPS in reference implementation Support for push/pull-based interaction patterns for deployment and discovery flexibility. Support for indirect export and message indirection.  Most bulk data transfer to occur over other protocols, which themselves must provide encryption.

13. 13 mPlane Protocol Information Model

14. 14 Schema-level interoperability Network measurement produces rows in databases. Network data analysis munges rows in databases into other rows in databases. The key to interoperability is ensuring that columns with the same name have the same meaning. Operations of common measurement tools can be completely described by the schemas involved.

15. 15 Initial Element Registry Derived from scenarios in D1.1, inspired by IPFIX IE Registry. Partially structured namespace:  [base].[modifiers].[units].[aggregation]: [primitive] Minimal set of core elements in the protocol  start, end, period: temporal scope  source, observer: topological scope

16. 16 Example Capability: ping capability: measure parameters: start.ms: now...+inf end.ms: now...+inf source.ip4: 10.2.3.4 destination.ip4: * period.s: 1...60 results: - delay.twoway.icmp.ms.min - delay.twoway.icmp.ms.mean - delay.twoway.icmp.ms.max

17. 17 Example Specification: ping specification: measure parameters: start.ms: 2014-01-20 09:25:00 end.ms: 2014-01-20 09:26:00 source.ip4: 10.2.3.4 destination.ip4: 10.4.5.6 period.s: 1 results: - delay.twoway.icmp.ms.min - delay.twoway.icmp.ms.mean - delay.twoway.icmp.ms.max

18. 18 Example Result: ping result : measure parameters: start.ms: 2014-01-20 09:25:01.135 end.ms: 2014-01-20 09:26:01.136 source.ip4: 10.2.3.4 destination.ip4: 10.4.5.6 period.s: 1 results: - delay.twoway.icmp.ms.min - delay.twoway.icmp.ms.mean - delay.twoway.icmp.ms.max resultvalues: - - 39 - 44 - 73

19. 19 mPlane protocol for testbed We build testbeds … to collect measurements  Probes … and we need algorithms to post-process results  (Intelligent) repository So why not extending the mPlane approach for testbed in general?  [Submitted a FIRE proposal for a 3G/4G Eu testbed] CoNEXT TPC workshop Barcellona, 5/9/13

20. 20 Questions How to share resources?  ISPa can run experiments from ISPb? Supervisor(ISPa) talks to Supervisor(ISPb)  Federated solutions? How to share results?  Value is in the data… We have 10GB of data per day… (from our passive probes  How to access to this data?  What to do with this data? CoNEXT TPC workshop Barcellona, 5/9/13

21. 21 Gantt

22. 22 Collaborating Institutions - CI mPlane foresees the collaboration with external partners Collaborating institutions have no commitment  No bureaucracy, no deliverable, no deadline They can access to real data that we have  Active and passive probes (e.g., passive probe in ISP) They can have access to results and technology preview They can collaborate with partners

23. 23