GEANT’s Performance Monitoring Infrastructure

1. GEANT’s Performance Monitoring Infrastructure Joint Techs meeting 20th of July, Colombus

2. Agenda • GN1 performance monitoring trial • Introduction • Overview • Building blocks • MPs deployment • GN2-JRA1 Performance Monitoring and Management

3. Introduction • Multi-domain Network Performance Measurement Management Platform • Retrieve network information from several domains through a pre-defined interface. • Performance Monitoring: provide network characteristics such as available bandwidth, delay, packet loss, “traceroute” • extended to looking glass functionality • netflow like data (to track DoS attack) • else (your feedback welcome)

4. Introduction (2) • Multi-domain Network Performance Measurement Management Platform • provides an “aggregated/concatenated” view of the information retrieved. • R1 -> R2 = 1.2Gbps ; R2 -> R3 = 800Mbps ; R3 -> R4 = 1.6Bbps • R1 -> R4 = 800Mbps • allows to generate some traffic with some specific characteristics. • Generate <IP (destIP, pkt size); UDP (port)>

5. Introduction (3) • PERT - the need of addressing the end-to-end problem and provide for the network side a tools for the PERT group. • PERT stands for Performance Emergency/Enhancement Response Team (http://www.dante.net/server/show/nav.00100q003003/) • Users (NRENs) and users’ users (GRIDs, application over network researchers) are requesting more and more information from the networks.

6. Overview • Objectives • Exchange monitored data between domains to • Ease the troubleshooting (fault/problem localisation) • Give to the network users (for instance end-site systems administrator or advanced network users) views of the networks-edge to network-edge performances. • Network/service health verification. • SLA verification • Re-usable parts (as much as possible). • Extendable to new type of tests. • Each domain has its own policy.

7. Overview (2)

8. Overview (3)

9. Building blocks • Measurement Point (MP) • “something” (router, piece of software, etc) capable of providing information about a network characteristics (delay, routing info, interface status, etc) • For a given type of measurement, different type of MP could be used. (e.g. delays: DFN IPPM on GÉANT, OWAMP on Abilene). • Implies inter-operability issues (packet format, way of requesting a test between domains, etc).

10. Building blocks (2) • “User” Interface • Presents network information (OWD so far) from a domain, uses the request and reply schema defined by the GGF NM-WG. • Using XML RPC • Allows to start measurements from/to MPs not under our administrative authority. • Need also interface for the path finder and the AA.

11. Building blocks (3) • “Domain Manager” • Primary goal: collects the data, concatenates them (if requested), aggregates them (if requested) and/or analyses them (if needed). • Query the path finder about which MP and which domain tool have to be contacted. • Query the domains MPs and other domains. • Schedules tests, do resource management on behalf of the MPs, negotiate test with other domains. • Authentication, authorisation. • Format data according to predefined format.

12. Building blocks (4) • Path Finder • High level functionality: locate the measurement nodes along a end-to-end path. • Two cases • the full path is given • only end points are given • trickier • Historical path variation difficult to provide • Implies limitation concerning the end-to-end information which can be provided.

13. Building blocks (5) • Authentication/Authorisation • High level functionality: authenticate a user and allow him to get the data he is authorised access and to start test based on its level of authorisation. • e.g. domainX.NOC or domainX.user_type

14. MPs deployment • DFN IPPM • GEANT Frankfurt (DE), GEANT Jerusalem (IL), PSNC Poznan (PL), GARR Rome (IT), Renater Paris (FR). • Data available September • OWAMP • On the same monitoring hosts than the DFN IPPM, plus GEANT London (UK) and GEANT Geneva (CH) • BWCTL • GEANT London (UK), GEANT Milano (IT) • RIPE TTM • GEANT Geneva (CH) • Will be able to provide information from more RIPE TTMs (NRENs have offered to include theirs).

15. Agenda • GN1 performance monitoring trial • GN2-JRA1 Performance Monitoring and Management • Objectives

16. JRA1 Objectives • Performance Monitoring and Management • Provide a multi-domain framework to exchange monitoring information. • For the end-to-end services offered by the GN2 community. • Information retrievable through a pre-defined interface. • Visualisation tools can access the data using a same format independently of the domain from which the data are retrieved. • 10 FTE over three years (Joint Research Activity) • 14 European NRENs involved

17. JRA1 Benefits • Better visibility on what is happening along the e2e path. • Easier troubleshooting. • Raise awareness about where the problems are. • Provide a better feel of satisfaction to the end-users towards the network. • Share development resources. • Create a monitoring community in Europe.

18. Three levels

19. Visualisation • Data consumer (user visualisation interface) • Adapted to different type of users • NOCs • GRID and projects • End-users • Researchers in the field of network or application over computer network • Uses per-defined interface for retrieval of monitoring data independently of the domain where the data are coming from. • Development of at least three visualisation tools (among them: map for users/NOCs/GRIDs and SLA verification)

20. Domain Controller • Bring the multi-domain dimension to the system • Bridge the visualisation tool with the measurement tools. • Measurement points discovery and path discovery. • Perform functions on behalves of the measurement points (scheduling tests, etc). • AA with other domain controller/framework, with measurements and visualisation tools. • GN2-JRA5 is in charge of building an AAI.

21. Measurement Points • Enhancements of existing tools • Work in two areas: • For active monitoring: (a) one-way-delay and (b) throughput measurement tools • AA, security and inter-operability • For Passive monitoring: (a) flow monitoring (netflow like), (b) passive packet capture tool and (c) network equipment information.

22. Collaboration with Internet2 piPEs • Frameworks should be inter-operable • “User” interfaces • Interface between the framework and the end-users • Protocols for active measurements. • Discovery mechanisms • AA • Reconciliation of the infrastructure • Test of tools • Investigation of the set up a shared development environment • Write common architecture description • Interim-roll out of common measurement environment

23. Collaboration with other Activities (6) • EGEE • Enable Grids for E-science in Europe • Objectives: deployment of an operational GRID infrastructure. • They will need to access monitoring information from the domain. • Interface to retrieve the data • Interested mostly in information which can be of any use at the L4 and in Available Bandwidth.