1. Extending the Measurement Infrastructure of Pipes beyond Abilene
Jeff W. Boote
18 February 2019

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 PAS is a specified PC based computer ($2000 estimated) with a software load provided by Internet2
Campus Y
PMP
PMP
PMP at each Campus Border

4. System Architecture (10/03)
Deployment is an inside-out approach. Start with regularly scheduled tests inside, make sure it plays well with regularly scheduled tests outside. Hope that projects working on the end nodes will meet us in the middle.

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 Authorization
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?
Shiboleth is being extended for the IM environment – hopefully that work can be leveraged for this as well.
Not sure if GSSAPI has enough to deal with “roles” based authorization…

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 Nearest neighbor One on one
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?
Color of nodes represent individual domains
Color of links represent different configuration sets

12. System Architecture (10/03)
Deployment is an inside-out approach. Start with regularly scheduled tests inside, make sure it plays well with regularly scheduled tests outside. Hope that projects working on the end nodes will meet us in the middle.

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)
Deployment is an inside-out approach. Start with regularly scheduled tests inside, make sure it plays well with regularly scheduled tests outside. Hope that projects working on the end nodes will meet us in the middle.