perfsonar development work

[Andreas Hanemann <>]

Hi Jeff,

Jeff W. Boote schrieb:
> Hi Andreas,
>
> I fully agree with Stephan here. Also - I added some additional 
> comments in the document regarding the 'neighborhood' information 
> registered by a service, and the new messages you have created.
>
> The 'neighborhood' information needs to be abstracted into more of a 
> general rule for all services. It should not rely on the fact that the 
> HADES MA is 'usually' near a router. I suggest having the web admin 
> derive a NURN based on where it is in topology space (perhaps even 
> communicate with the topology service to figure it out), and absent 
> that it could run several traceroutes to known divergent locations on 
> the network and register all the first N hops it sees (including 0). N 
> could default to something like 3-5, but could be administratively 
> configurable to a number large enough to get off the NREN for example.
This generalization of the location seems to be a good idea, but we need 
to invest some thoughts into its details. The description that you are 
mentioning is the first step, but we also need a reliable query mechanims.

Let me at first rephrase a bit what you are suggesting. There is a HADES 
box (or any other kind of "MP") located somewhere in the network, maybe 
near an NREN router, maybe somewhere "deeply" in a campus LAN. There 
should then be global reference locations (e.g. DANTE office, Internet2, 
somewhere in Asia) and traceroutes should be run from the box location 
to these well-known reference locations. You are suggesting then to 
store information about 3 or 5 hops per path which are near the location 
to represent each of the paths. It is the question how we should 
represent the hops. My proposal would be to store the router host names 
rather then the IP addresses, because this may be rather unique(?). For 
routers in campus LANs such a resolution via a topology service may not 
be possible which would be a good reason to extend the representation to 
more hops. All this information should then go into the LS.

If there is the situation that a path should be investigated, we need a 
mechanism to filter out those boxes that are relevant to the path. This 
could be done in a manner that we convert the path representation to 
router host names and ask the LS to return all measurement box locations 
where the router host name is mentioned as part of the paths. Maybe we 
can sort the result according to the hop where is found (prefering 
nearer hops). The box locations are then used to query a "Traceroute MA" 
to get the actual measurement paths between the candidate boxes and then 
to decide what is relevant. These data can then be requested from HADES MA.

> The other thing I mention is that you have no eventTypes in any of 
> your messages. eventTypes is the mechanism you should be using to 
> indicate the type of data you are looking for, and therefore it is 
> usually required information. (It is not in the current set of LS 
> messages - but that is actually giving us some problems in the dLS 
> implementation and will likely change in the future.)
Ok. I will add event types to the messages. Concerning the DCN example 
Jason has provided this to the mailing list, but I have some 
difficulties to understand it because there is no further information 
provided.
> (Sorry - but I will not be able to attend the call. I will be in the 
> air at that time...)
>
> jeff
>
>
> On May 6, 2008, at 2:32 AM, Stephan Kraft wrote:
>
> > Hi Andreas,
> >
> > i added some comments on the document (attached). Main point for 
> > HADES and BWCTL will be, that it is not foreseen to put the "business 
> > logic" for finding related MPs into the HADES MA or the BWCTL MP. The 
> > point is to find a way to correlate the traceroute information with 
> > the topology service (cNIS), together with the lookup service.
> >
> > A proper way may be a "Traceroute MA" containing the information 
> > about traceroute of N=n(n-1) measurement paths (50 boxes representing 
> > 2450 measurements, _not_ containing additional measurements like 
> > IPv6, ToS etc.). This Traceroute MA can be requested by cNIS, LS 
> > etc.. Starting and ending point will be the measurement box (HADES, 
> > BWCTL other ...), the work will be to match the paths between the 
> > boxes and the paths between the corresponding routers. This should 
> > not be done by HADES MA (not only because it then just works for the 
> > HADES MA).
> >
> > Best
> >
> > Stephan
> >
> >
> >
> > Andreas Hanemann schrieb:
> > > Hi Nicolas, Nina, Martin, and Verena,
> > >
> > > Based on the discussions that we had in Zagreb I have refined the 
> > > document on "Finding related MPs". New is a proposal how an 
> > > interface in perfsonarUI may look like and how its business logic 
> > > should work (the most difficult part is the one related to the HADES 
> > > MA and BWCTL MP). The business logic requires that several 
> > > additional messages are exchanged. For this I have modified examples 
> > > from other schema uses (similar as in the Tranformation Service 
> > > document). As a starting point I would like you to read the document 
> > > and participate at the conf call that I have proposed for next week. 
> > > See the following link for the conf call and the document.
> > >
> > > http://wiki.perfsonar.net/jra1-wiki/index.php/Finding_Related_MPs_Conf_Call_13_may_2008 


--
Dr. Andreas Hanemann      
DFN-Verein
Stresemannstr. 78
10963 Berlin, Germany
Tel.:   ++49 30 884299 64
Fax:    ++49 30 884299 70
E-Mail:  (Please do 
not use  anymore)