Nicolas Simar, Network Engineer 12/01/2005 Brussels DANTE

1. GN2-JRA1 Performance Monitoring Nicolas Simar, Network Engineer 12/01/2005 Brussels DANTE

2. Agenda • GN2-JRA1 Objectives • Activity Update • Next Steps • General Framework Overview

3. Objectives • Multi-domain Network Performance Measurement Management Platform • Retrieve network information from several domains • Through a pre-defined interface • Modify and Improve measurement tools. • tests performed to determine how fast some aspect of a system performs under a particular workload • Covers network information such as delay, packet loss, “traceroute”, achievable TCP throughput, etc • Build visualisation tools to suit some users needs.

4. Objectives (2) Deprecated view of the infrastructure

5. Agenda • GN2-JRA1 Objectives • Activity Update • Next Steps • General Framework Overview

6. GÉANT2-JRA1 Activities • Requirements • Three questionnaires were written targeting: the NRENs, the projects and the end-users. • Goal: get an overview of • the existing monitoring infrastructure (metric, tools used) • the visualisation of the data • the need to access monitoring information from other networks. • 45 answers were received in total (respectively 16, 14, 15) • Strong interest to access monitoring information form multiple network. • NRENs: less than 5-10% of the problems they are encountering involves several domains ( => times 30 NRENs). They want to see improved the capability of localising the problems. • International projects want to have a view on what’s happening between their sites (uses: troubleshooting, SLA and internal decision making). • End-user: less important than for NRENs or projects (uses: troubleshooting, service verification)

7. GÉANT2-JRA1 Activities • Readiness to open access to measurement data • Some ready to show everything (or nearly so) • Some want to apply restriction (about what and to who) • Some don’t want to • Monitoring Information: • RTT and OWD • bandwidth utilisation and achievable TCP throughput • RTT and OWD packet loss • Delay variation • Interfaces error and drops • Routing/path information • On-demand capability (to and from other domains)

8. GÉANT2-JRA1 Activities • Be able to monitor the services deployed • IPv4/IPv6 • Multicast/unicast • IP QoS • VPN/point-to-point connections • Emulate behavior close from the one from the application used • Different tools used amongst the networks, need to abstract the data provided from the type of measurement tools used. • Provide data through a well define interface. • Inter-operability between tools.

9. GÉANT2-JRA1 Activities • Keep in mind: installation and maintenance! • Had a look at existing tools and went more in depth for the most interesting ones. • We have chosen so far the following tools: • OWD: DFN IPPM • Throughput: iperf based • Flow monitoring: flowtool • Visualisation: CNM • Pending: Packet capture tool (SW: scampi - tbc, HW: Endace or scampi - further work needed), other visualisation

10. Agenda • GN2-JRA1 Objectives • Activity Update • Next Steps • General Framework Overview

11. GÉANT2-JRA1 Activities • Current actions • General Framework Design v1 (mid-February) • Prototype (June-July 05) • Work on measurement concatenation (now -> September) • Buy equipment and install it. • Next steps • AA (discussion with JRA5) • Which model to follow? • Authorisation based on groups (NOC, PERT, projectA, user). How to have easy agreement between domains? (don’t want to negotiate an agreement with all the US universities or with all the European NRENs) • Detailed design of the modules v1 (September 05) • Trial phase (November 05-December05)

12. Agenda • GN2-JRA1 Objectives • Activity Update • Next Steps • General Framework Overview

13. Architecture Refinement • Strong collaboration between Internet2 PAT and GN2-JRA1 (meetings and conf-calls). • Best way to have our framework inter-operable is to build a common one. • Review of existing systems • Insights based upon Abilene prototype framework, DANTE’s perfmonit and IPPM experiences • New insights gained from inter-domain framework test experience (lightpath measurements, Abilene/ESnet, etc) • Additional use cases and experience of collaborators • Internet2, GÉANT2 JRA1, GGF NMWG

14. Architecture Proposal • Services Oriented Architecture • In a simple scenario, each domain consists of a set of services. All services are well defined and independent • Services within a domain represent the domain with the help of Authentication and Authorization – they respond to requests only if the Authentication service of the domain has authenticated the user and the policy of the given service authorizes it

15. Basic Services • Lookup • Authentication • Measurement Point • Measurement Archive • Resource Protector (Authorization) • Aggregation • Topology

16. Lookup Service • Initial discovery • Multicast / Anycast • Well known servers • Required servers (by administrative configuration) • Previously detected servers (organized in a P2P network – lookup services find out about other lookup services…

17. Lookup Service (II) • Lookup is not simply by name • Type (type of measurement, type of service) • Community • Network path (proximity information from Topology) • Organization • Type of authentication required • Other… • Response contains • Contact information • Available services • Authentication required • Other…

18. Authentication • Registers with lookup • Client requests “kind” of authentication token based lookup results • Authentication grants time-limited token used to request service • Protocol for determining “role/identity” for request. (Shib: federated trust) • Allow new measurement points to be created as easily as possible • Allow new data consumers access as easily as possible

19. Measurement Point • Service to wrap measurement tools • Interacts with resource protectors to protect shared resources • Registers with lookup service and specifies the authentication credentials required to interact • Registers with lookup service to indicate types of tests it can perform • Accepts requests for tests

20. Measurement Archive • Subscribes to some set of data – either from a measurement point or from an aggregation service • May publish the derived data sets

21. Resource Protector • Enables centralizing of resource allocation (not globally - this is within spheres of administrative control) • Multiple measurement points interact with a given resource protector to limit the shared resources • Resource protectors can be chained hierarchically to control aggregations of shared resources across larger frameworks.

22. Topology • Network topology information is necessary for measurement system optimization • Creates overviews/”maps” to illustrate network • Layered approach (domain level through to wavelengths and physical level) • Specific type of aggregation (translation) • Collects raw data from measurement points and pushes topology information into the lookup service (allows topologically based queries to lookup service)

23. Aggregation (Translation) • Data translation service (pipelines data between other components in the framework) • Subscribes and Publishes data • Provides: • Aggregation • Correlation • Caching • Duplication • Translation • Event generation • Data analysis

24. Process Flow (Client) • Discovery. • Find lookup servers. • Use lookup servers to find tool beacons for a given problem. (On correct path, with acceptable authentication requirements, with acceptable tools/measurements.). • Authentication. • Authenticate to correct auth servers that are needed for desired test executors. • Test execution. • Implement subscriber to accept results. • Make test requests presenting credentials and reference to subscriber interface for returned data.