1 / 9

E2E piPEfitters

E2E piPEfitters . Eric L. Boyd. Agenda. NLANR / DAST Advisor Jim Ferguson John Estabrook OWAMP Jeff Boote SONAR Prototype Deployment Eric Boyd. OWAMP 2.0a. New Features Fully compliant with latest version of OWAMP specification (version 14 - out of the IPPM/IETF working group)

roza
Télécharger la présentation

E2E piPEfitters

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 piPEfitters Eric L. Boyd

  2. Agenda • NLANR / DAST Advisor • Jim Ferguson • John Estabrook • OWAMP • Jeff Boote • SONAR Prototype Deployment • Eric Boyd

  3. OWAMP 2.0a • New Features • Fully compliant with latest version of OWAMP specification (version 14 - out of the IPPM/IETF working group) • TTL set to 255 on send, TTL of received packets saved in data (if Socket implementation supports) • Better support for early terminated sessions • Added PHB/DCSP options (PHB not supported by owampd, but client still supports making protocol requests for them.) • Added option to schedule tests in the future (control connection happens immediately) • Ready for testing • Not installed on Abilene yet • Looking for alpha-testers (boote@internet2.edu)

  4. Prototype Phases • Phase I • Link Utilization data presented as RRD files • RRD files wrapped in a Measurement Archive (MA) interface • Client directly asks RRD MA for data • Phase II • Cricket/MRTG wrapped as a Measurement Point (MP) • Data sent to the RRD MA using the internal proprietary interface that those tools use now. • Client contacts the MA to get a copy of the data. • Phase III • RRD MA extended to include a subscriber interface so data from RRD MP can be put into it. • Cricket/MRTG MP extended to have a publisher interface so data can be retrieved from it. • Client modified to request the test results from the MP be put into the MA.

  5. Prototype Phase 1 • Components: AA, LS, MA • AA - Accept requests for authentication and issue tokens. • Only authN; no authZ • Only one AA server • Simple passwd file implementation • LS - Flat file (basically DNS) for services. • Information about services will be populated manually. • Found using DNS; only one LS; no authentication required to access data • MA - MA interface wrapped around existing RRD files. • Client Interface: • Graphs of each parameter that can be pulled. • LinkUtilization • AvailableBandwidth • Multiple plots displayed concurrently. • Client directly asks for data from the RRD MA.

  6. Prototype Phase 2 • Components: AA, LS, MP, MA • AA - Extended to manage "real" identities • Ability to store attributes about those identities. • User A is a network engineer, etc. • LS - Extended to have services dynamically register and deregister information instead of hard-coding it. • MP - Accept tests for some "OTHER" metrics that the MRTG/Cricket tool is not currently doing • Use the MP to configure a new metric data feed to be sent to whatever "subscriber" interface passed in. • Initially this will be a special NULL subscriber handle indicating that the MRTG tool should just use its own back-door data propagation. • Client Interface: • Client requests additional SNMP variables that are not currently being collected through this interface and makes it available through the MA-RRD archive. • Visualization/analysis front end extended to graph/analyze additional variables. • Perhaps even add the ability to query the MP to find out what types of variables can be requested.

  7. Prototype Phase 3 • Components: AA, LS, MP, MA, RP • AA - Manage identities as before, but now handle attribute requests from RP services so they can perform the authZ function. • LS - Start looking at how to distribute the LS data across multiple LS servers. • The hard part here will be for "protected" data. Protected data should probably not be distributed, but a reference to the "home" location(s) of the protected portion could be included. • MP - Start taking full subscription handles as part of a measurement request • Send data directly there instead of into the RRD files of the MRTG tool. • Could go back to the client or perhaps to a MA.) • MA - Start accepting archive requests and returning subscription handles. • Could be passed onto a MP so data from a measurement request could be passed directly into a MA subscriber. (Or a client subscriber.) • RP - Start looking at requests • Base acceptance of resource consumption based not only upon the "class" the requester is in but on their individual attributes by making attribute requests back to the AA server. • Client Interface: • Addition of authZ. • Client passes in "real" subscription handles for the Data propagation from the MP. • Client can get a direct feed of the data, or it can request a subscription handle from the MA before contacting the MP. • Possible to create other types of MA's (SQL based instead of RRD based). • This phase will be key to determining how dynamic and resilient the framework can be.

  8. Next Steps • Once Prototype 3 is complete … • It should be possible to start adding additional services without too much difficulty. • We should be able to make future development from here on more parallel.

More Related