1 / 15

Enhancing Measurement Infrastructure for Abilene Network

This study explores extending the measurement system of the Abilene network to include performance measurement points at nodes and campuses, addressing domain definitions and challenges in authentication, authorization, and configuration to optimize measurement configurations.

cain-villarreal
Télécharger la présentation

Enhancing Measurement Infrastructure for Abilene Network

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. Extending the Measurement Infrastructure of Pipes beyond Abilene Jeff W. Boote

  2. The Measurement System (4/03) The New Abilene will have measurement devices as part of its structure Abilene PMP PMP PMP PMP = Performance Measurement Point (at each Abilene Node)

  3. The Measurement System (4/03) Extend the System to Campuses Campus X Abilene PMP PMP PMP Campus Y PMP PMP PMP at each Campus Border

  4. System Architecture (10/03)

  5. Measurement Domain Definition • A measurement domain is simply a useful construct for centralizing the policy and control issues for a specific group of hosts control here is primarily about defining a specific set of regular tests to run between a specific set of hosts

  6. Single Domain to Multiple Domain adds Complications Who can run a test, between what hosts, and who gets the results? • Results must be able to flow to all authorized, interested parties • Policy • Configuration control • Data flow

  7. Policy Issues • Authentication • Federations of measurements, require federations of authentication and the sharing of trust • Authorization • Federated authentication requires a model where the definitions of “roles” are shared by all parts of the federation

  8. Federated Authentication/Authorization • There are many very good efforts in this area. • Shibboleth, Akenti, GSI, KX509… • That said, it is important that we soon start engaging that community more directly and start fully integrating the work! • Perhaps start with the GSSAPI? • Gives you Kerberos and GSI • What gives us roles?

  9. Configuration Issues • Distributed scheduling better integrates on-demand tests to any point • Distributed scheduling makes management of overall configuration more difficult • Desire to distribute configuration some • Should be able to drop in a new set of hosts to run a particular “experiment” without changing rest of configuration

  10. Use Cases • Full mesh • List of hosts (NxN) • Nearest neighbor • List of peers for a given host (1xN) • One on one • Same as 2 (1x1) • Subset of one domain with subset of another domain • Sparse mesh (JxK) = NxN + !(PxQ)

  11. Want to optimize these organizations • Full Mesh • One node with any group of others • Subset of mesh with subset of another mesh (inter-domain tests) Does this capture most measurement configurations?

  12. System Architecture (10/03)

  13. Data Flow • Peers may want results of test directly • NOC alarms… • Data may need to be collected to a central point before distributing further • Firewalls, aggregation points…

  14. Revised System Architecture (4/04)

More Related