perfsonar development work

["Jeff W. Boote" <>]

Nina Jeliazkova wrote:
> Hi,
>
> What will be the added value of an additional service to retrieve additional
> (e.g. interface) information, rather than querying the measurement acrhive or
> measurement point with specific type of messages?  

I definitely see the utility of a configuration-service. However, I'm not 
convinced *this* data belongs there.

But, I do see utility in registering service specific information to the LS. 
(Summarized, not full interface data!) Providing this kind of data would allow 
aggregation so a client would not have as many places it would need to request 
the information from. I still think a specific MA needs to be able to respond to 
some kind of request indicating what information it is holding.

Current clients know that nearly all MA's will give you utilization data. This 
will not be true in the future when we are providing many, many different kinds 
of data.

A GUI/analysis tool would probably like to know what data is held by different 
MA's before querying each and every one individually. One dimensionality of that 
is the 'type' of MA (what event type's it supports). Another dimension of that 
is what networks/routers/switches/hosts a given MA has data about.

One of the things we need to be able to do in the future, is to find measurement 
points, or data about specific network paths. To do this, we will need to 
correlate the information in the topology service with the information in the LS 
service. (Martin and I have suggested that this may actually end up being the 
same service, but we don't need to go down that road yet. That is more 
implementation driven, than design. The important thing is that enough 
information be available to do the correlation.)

In any case, enough topological information will need to be registered to the LS 
about the data a service holds for the relevance of that data to be determined 
with regard to actual topology.

jeff