1 / 23

E2E piPEs Overview

This project, E2E.piPES, aims to enhance end-users and network operators' abilities to determine and resolve performance issues through collaborative efforts. The system architecture involves various components like Measurement Test Point, Performance Measurement Schedule Controller, and more. Collaboration with organizations like GGF NMWG and UCL facilitates the development of interoperable tools. The framework rollout plan includes milestones like joint demos, campus deployment, and international collaborations. Moving forward, the emphasis will be on interoperability, discovery, AAA integration, and open-source development for mutual benefit.

ejanis
Download Presentation

E2E piPEs Overview

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. E2E piPEs Overview Eric L. Boyd Internet2

  2. Overview • What is piPEs? • Goals • System Architecture • Well-defined Interfaces • Collaboration • Measurement Software Components • Framework Rollout Plan • Collaboration Going Forward

  3. E2E piPES Architecture • Project: End-to-End Performance Initiative Performance Environment System (E2E piPES) • Approach: Collaborative project combining the best work of many organizations, including DANTE/GEANT, EGEE, GGF NMWG, NLANR/DAST, UCL, Georgia Tech, etc.

  4. Goals • Enable end-users & network operators to: • determine E2E performance capabilities • locate E2E problems • contact the right person to get an E2E problem resolved. • Enable remote initiation of partial path performance tests • Make partial path performance data publicly available

  5. System Architecture

  6. Measurement Infrastructure Components

  7. Measurement Software Components Network Detect Detective Monitoring Web Service Interface Measurement Domain Interface Authorize (MDI) Performance Measurement Schedule Controller (PMC) Performance Measurement Test Point (PMP) Store Database

  8. Interfaces • Test Request / Response • Authentication / Authorization • End Points • Measurement Characteristic (e.g. Latency) • (Suggested) Measurement Tool / Parameters (e.g. Ping / 2, OWAMP) • Result Request / Response • End Points • Measurement Results • Error Bars • Measurement Tool / Parameters • Inter-Measurement Domain / Framework Interfaces

  9. Interface Consumers • End-User Performance Analysis Tools • Advisor (Jim Ferguson, Tanya Brethour) [Current] • Detective (Bob Riddle) [Planned] • NDT Tool (Rich Carlson) [Planned] • MonaLisa [Under Discussion] • Data Mining Web Pages • Abilene Observatory (Rick Summerhill) [Current] • Network Planning • HENP, VLBI Communities [Under Discussion] • Application Self-Diagnosis [Future] • Other Measurement Domains [Planned]

  10. Collaboration • Support Performance Data Consumers • SOAP / XML-RPC Interface to Performance Data • Will be used by tools such as NLANR/DAST Advisor • Common Performance Data Format • Global Grid Forum Network Measurement Working Group • University College London (Peter Clarke’s Group) • Interoperable Tools (DANTE, NLANR/DAST, AppareNet) • Measurement Node Deployment • Campuses • Regional Networks • Datagrids (Application Communities) • International Partners

  11. Building a Measurement Federation: Open Issues • “Inter-Domain” Authentication and Authorization (e.g. Shibboleth) • Resource Discovery (e.g. “Root Server”) • Measurement Node • Performance Database • Test Request / Response Schemata (e.g. GGF NMWG efforts) • Result Request / Response Schemata (e.g. GGF NMWG efforts)

  12. Measurement Software Components Network Detective Detect Detective Monitoring NDT v1.0 Response v0.1 Interface Web Service Request in Development Measurement Authorize Domain Interface Just beginning ... (MDI) Web Service SOAP / XML-RPC Performance POWMASTER, BWCTL, Schedule Measurement TRCTL Controller(PMC) OWAMP, IPERF, Performance Test Traceroute, “Generic Tool” Measurement Point (PMP) OWAMP Controller, BWCTL Controller, Traceroute Controller, Store Database mySQL

  13. Abilene Measurement Infrastructure Rollout Schedule • OWAMP (now) • Deployed on 10 Abilene nodes • Available via Web Services Interface • Web-based Visualization (http://abilene.internet2.edu/owamp/status.cgi/now) • Worst-case Abilene Link (Loss / Latency) • BWCTL (now) • Deployed on some Abilene nodes • Regularly Scheduled / On-Demand Tests • Enables End-User Tests to Abilene Nodes • http://abilene.internet2.edu/observatory/data-views.html • Web-based Visualization (http://abilene.internet2.edu/owamp/bwstatus.cgi/now)

  14. External Participation • Edge to the Backbone • BWCTL • OWAMP • Contact: Matt Zekauskas (matt@internet2.edu) • AES key security

  15. NEXT 2 MONTHS Traceroute Deployment Multiple Measurement Domain Support NTP Data Data Integrity Analysis NEXT 6-12 MONTHS Improved AMI Visualization Improved Documentation MDI Interface Integration Detective / NDT 2.0 Network Monitoring AAA Integration Upcoming Milestones

  16. Framework Rollout Schedule [Planned] • Joint-Techs Hawaii Demo with E2E TAG and NLANR/DAST • Campus Deployment • ITECs (Ohio State, NC State, San Diego) • Application Communities (HENP, VLBI) • Campuses (CENIC) • International Collaboration • TransPac Monitoring (LA <-> Japan) • DataTag Monitoring (Illinois <-> CERN) ???

  17. Collaboration Going Forward • 3 Levels of Collaboration • Awareness of Other Projects • Interoperable Measurement Frameworks • Discovery • AAA • GGF NMWG Test Request/Response Schemata • GGF NMWG Result Request/Response Schemata • Open Source Development of Common Tools • Mutually agreed-upon architecture • Common source code base • Feature emphasis driven by individual project needs

  18. Performance Measurement Architecture WS Framework

  19. OWAMP • One Way Latency • Requires NTP on endpoints • Control connection used to broker test request based upon policy restrictions and available resources. (Bandwidth/disk limits) • Enables the combination of regularly scheduled tests with on-demand tests. • http://owamp.internet2.edu/ • Reference implementation of Draft: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-06.txt

  20. OWAMP – Architecture

  21. BWCTL • Iperf control scheduler. • Requires NTP on endpoints. • Control connection used to broker test request based upon policy restrictions and available resources. (Time slice, bandwidth…) • Enables the combination of regularly scheduled tests with on-demand tests. • Abilene deployment in progress.

  22. BWCTL – Architecture

More Related