1 / 12

Nicolas Simar, Network Engineer DANTE

GN2 Performance Monitoring & Management : AA Needs 2 nd AA Workshop 20 - 21 November 2003 Malaga, Spain. Nicolas Simar, Network Engineer DANTE. Introduction. GN2 project starting from Q3 2004 build the successor of the GÉANT network

jett
Download Presentation

Nicolas Simar, Network Engineer DANTE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GN2 Performance Monitoring & Management : AA Needs2nd AA Workshop20 - 21 November 2003Malaga, Spain Nicolas Simar, Network Engineer DANTE

  2. Introduction • GN2 project starting from Q3 2004 • build the successor of the GÉANT network • integrated activities between NRENs: Joint Research Activities (JRA) and Services Activities (SA) • AA required by various activities in GN2 (non extensive lists) • JRA1 – Performance monitoring & management • JRA3 – BW allocation & reservation • SA3 – end-to-end service quality across multiple domains • Need to define a common EU-wide AA architecture (JRA5-Ubiquity and/or JRA2 Security?)

  3. What is JRA1? • Multi-domain Network Performance Measurement Management Platform • Retrieve network information from several domains through a pre-defined interface. • Performance Monitoring: • monitoring of network characteristics such as delay, packet loss, available bandwidth, “traceroute”, etc • extended to looking glass functionality • netflow like data (to track DoS attack)

  4. What is JRA1? • Management platform • Provide an “aggregated/concatenated” view of the information retrieved. • Available bandwidth R1 -> R2 = x Mbps ; R2 -> R3 = y Mbps ; R3 -> R4 = z Mbps • Available bandwidth R1 -> R4 = min(x,y,z) Mbps • Enable users to generate traffic and its characteristics. • Generate flow <IP (destIP, tos, size, etc); TCP/UDP (port, etc)> • Allow to retrieve information out of several domains.

  5. Performance Monitoring Overview

  6. Where does it come from? • PERT (Performance Enhancement Response Team) need to isolate and resolve end-to-end problems. • The performance monitoring architecture should provide an useful debugging tool for this group. • Users are requesting to have access to more and more network information. • GRID to check what is the best way to ship data. • Network/application researchers to investigate the result of their experiments.

  7. Objectives • Exchange monitored data between domains to • Ease the troubleshooting • Give to the network users (for instance end-site systems administrator or advanced network users) more information about networks-edge to network-edge performances (later on, end-to-end for end-users). • Network/service health verification. • SLA verification. • Re-usable parts (as much as possible). • Must be able to cope with new type of tests/network characteristics. • Heterogeneous monitoring architecture in different domains

  8. AA Requirements • Different groups of users can perform different actions (e.g.) • Network end-user can access a subset of monitoring data. • NREN NOC can access a subset of data and perform some test using measurement points (MP) not under his/her administrative authority. Some limitations are applied to the tests he/she can perform. • The domain NOC can access any data and perform any test without limitation within its administrative authority. • Which groups are foreseen? • Domain NOC (NREN) • Other Domain NOC (NREN) • Customer NOC (campus sys-admin, regional network NOC) • Special end-users distributed over different domains or not (GRID - EGEE) • Generic end-user (default)

  9. AA Requirements • Every domain must stay in control of its monitoring infrastructure. • it decide which group can access which data and which group can do what with its MPs • it need to authenticate the user, map him/her to a group of user and check the what this group is authorised to do. • AA between the monitoring tools in different domains? • Cross domain AA for the end users? • e.g. a user in domain D1 should be able to start a test between MP’s in domain D2 and domain D3 • Flexible & extensible distributed AA architecture.

  10. Other GN2 activities • SA3 : e2e service quality • they may automate the service provisioning. • may need some modules to authenticate and authorise the user requesting the service (for GRID - EGEE) • JRA3: new services • build a new service providing end-to-end L2 connectivity • may also need to automate the provisioning of the service • JRA2: security and JRA5: ubiquity

  11. Other Issues • What can we do? • Use the JRA-5 AA architecture or some part of it? • Adapt an AA architecture to our needs (or to the ones from other GN2 activities)? • Develop another scheme? • Solicit advice regarding AA implementation in GN2 for the JRA1. • There are two main types of users. • Domain specific users • Cross Domain users • Compatibility with internet2 PiPEs.

  12. Q&A Any further Questions, Comments, Feedback or Suggestions please contact Nicolas Simar (Nicolas.Simar@dante.org.uk)

More Related