Peter Clarke organized and hosted an informal workshop at the University College London on 5/15/03, entitled UCL E2E Monitoring Workshop.
Topics of discussion included Internet2's E2E piPEs project and ongoing efforts and interests at DANTE, CLRC-DL, SLAC, UCL, and UKERNA.
Many participants (marked above with an asterisk) continued meeting on 5/16/03, with the primary focus being a revision of the v1 piPEs archictecture. The revised architecture incorporated both new ideas and ideas gleaned from the previous day's workshop. Major accomplishments included a cleaner definition of modules, a cleaner definition of protocols, a fully integrated scheme for access, authentication, and authorization, and a scheme designed to minimize DOS attacks (either as a hijacked participant or as the target). These ideas will be sent out to the Workshop participants and other interested parties for further review.
On Day 2, we did a reasonable amount of work revising the v1.0 piPEs architecture picture. The following diagram replaces the Scheduler, a pair of PMPs, the result arbiter, the test arbiter, and the database.
A bit about the new concepts:
Mapping old to new, the Source and Sink both correspond to PMPs on the original diagram. The test arbiter, central scheduler and individuals PMPs are replaced by a domain interface (representing the test arbiter and administrative domain's AAA), the PMC (representing the measurement nodes local scheduler and AAA), and the PMP (representing the barebones ability to accept a test initiation request, to run a test, to store the data locally, and to send it to the database gatekeeper (which used to be called the result arbiter).
The idea here is that these three components can be thought of as independent processes that may or may not run on the same machine. There may be one or more domain interfaces per administrative domain. There may be one or more PMCs per domain interface. There may be one or more PMPs per PMC. One common case is likely to be a single domain interface, and several PMC/PMP/hardware packages per administrative domain.
In the (rare?) case where the source of the test does not capture the performance data, it is assumed that the tool is wrapped in a script that makes it so. It is also assumed that *all* tests have a source and a sync. Even in the nominally "one-ended" case of 2-way ping, this would enable the sink to unblock a firewall, for example, and would also prevent an overload of pings against the sink.
There's an implicity restriction on the source PMC and PMP, requiring that they ONLY perform tests with other, known PMC/PMP machines. This has the desired effect of reducing the chance that a source could be hijacked for DOS attacks against unrelated machines.
Our design goals included modularity, minimizing risk DOS attacks (against or as agent thereof), flexibility of deployment, clean interfaces, and applicability to most tools.
Note, we fully expect to design an additional module, currently represented by a dotted line, that passes through A and P unchanged, but links B to O.
Here's the protocol diagram we came up with on 5/16/03:
Here's a revised version of the Architecture diagram I did after the fact to match up with the protocol diagram:
A. Here is who I am, and I want "this result" to exist (characteristic)
and that includes the IP addresses of the two routers [[may be 1 if
it's a passive result]]
- newness of test result
B. *no, go away [rejected (and here's why)]
*yes, result exists (with pointer)
*be patient, I will send response later (maybe with time estimate)
[Q: send response later or ask to call back?]
C. I would like to contact the PMC associated with this router,
here's who I am, and here's who I am asking on behalf of,
and here's the tool I'd like to run
D. *Get lost [not authorized, tool unavailable]
*IP address of sink PMC, capability to use
[or under hood, tell sink PMC to trust source PMC for a little while]
E. Initiate tool
- request interface token
- tool and argments to run
- Sink PCM IP address, capability {is a token}
F. here's my capability, can we start tool X with certain parameters now?
[[need source PMP IP address?]]
G. Start receptor
- prepare to receive tool
- IP address of source could be parameter [[never given?]]
- Identity of Sink PMC (token)
H. *OK
*Rejected can't do it
[[pmp doesn't do scheduling]]
I. *Rejected (don't like that capability; failed ot initiate receptor)
*willing and able, IP addr of sink PMP (really machine) to use
*Ask again in +T time units
J. Start tool:
- identity of source PMC (token)
- tool
- arguments for tool
- IP addr of sink PMP
K. Test stream from tool
L. Results
- identity of source PMP
- identity of sink PMP
- characteristic [[?]]
- tool output [[in standard form?]]
- [[accuracy, other ancilliary data that is relevant]]
(implicit ACK from DB, L is a stream)
M. Result report
- id of src PMP
- result ready, pointer to result (pointer contains capability?)
- result failed
-- test failed
-- write to DB failed
N. Result report
- id of src PMC
- result ready, pointer to result
- result failed
--test failed
--write to DB failed
(message B, actually is next)
O. Give me result
- who I am
P. *Rejected
*Result