slide1
Download
Skip this Video
Download Presentation
Nicolas Simar, Network Engineer DANTE

Loading in 2 Seconds...

play fullscreen
1 / 12

Nicolas Simar, Network Engineer DANTE - PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Nicolas Simar, Network Engineer DANTE' - jett


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

GN2 Performance Monitoring & Management : AA Needs2nd AA Workshop20 - 21 November 2003Malaga, Spain

Nicolas Simar, Network Engineer

DANTE

introduction
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?)
what is jra1
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)
what is jra11
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.
where does it come from
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.
objectives
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
aa requirements
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)
aa requirements1
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.
other gn2 activities
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
other issues
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.
slide12
Q&A

Any further Questions, Comments, Feedback or Suggestions

please contact

Nicolas Simar ([email protected])

ad