On Mar 24, 2011, at 9:24 AM, Roman Łapacz wrote:

Hi,

I'm sending updated document of MDM circuit monitoring.

Aaron, Jason, all,  you can find a simplified version of client access algorithm (section 5.3.2) but it still supports that one that you formulated some time ago and we all accepted. It is simplified because some assumptions  have been made in the use case with AutoBAHN (see the picture in 5.3.2). Please, take a look at the examples of messages for this algorithm but also for the workflow presented in 5.2.1. Check if massages from and to the MA(at)/MA(t) are compatible with those for the pS-PS TS. Also take a look at the example of massage that is sent from the hLS to the gLS (section 9.2.3).

Some time ago we were talking about capabilities and dropping the service type field in the lookup information. I found it very useful while working on the examples of messages. Although the MA services (MA(at) and MA(t)) store the topology information they can be treated as the pS-PS TS if they support topology storage functionality and register that with the hLS. Take a look at the examples of LSRegisterRequest type (I've used the parameter eventType but probably normal eventType element would be more suitable; but first I'd like to see your comments). So far I've proposed 6 capabilities:

http://ggf.org/ns/nmwg/ops/storage/measurement/2.0  (for MA)
http://ggf.org/ns/nmwg/ops/storage/measurement/aggregated/autobahn/2.0  (for MA with data aggregated by AutoBAHN)
http://ggf.org/ns/nmwg/ops/creation/measurement/2.0 (for MP)
http://ggf.org/ns/nmwg/ops/integration/autobahn/2.0 (for SIP which connects pS with AutoBAHN)
http://ggf.org/ns/nmwg/ops/storage/topology/2.0 (for TS or MA(t) which store topology information)
http://ggf.org/ns/nmwg/ops/storage/topology/aggregated/autobahn/2.0 (for  TS or MA (at) which store the topology information aggregated by AutoBAHN)

So the proposal uses eventTypes for operations (e.g. http://ggf.org/ns/nmwg/ops/storage/measurement/2.0 means "this services can be used to store measurements"). My recollection is that the goal was to move away from using eventTypes as operations; they'd just be used to describe functions. To do this, we'd need some way of including the supported messages in the elements registered up by the services. The clients could then look for things like "the services that support MetadataStoreRequest and utilization data". I'm not positive the best way forward on this.

As to the parameter-based eventTypes, I think we need to move away from those if, for no other reason, than to ensure that clients can uniformly query the LS without having to worry about what form the eventType will take. Having multiple ways, especially if different software packages do things differently, is more likely to result in clients that can only work with one type or the other.

A few other comments and questions on the document after a first pass.

1. We'll need to think about the specifics of how to generate the segment

   identifiers when there's a OSCARS/AutoBAHN bridging. When this happens, there are

   2 very different identifier schemes, and it's not clear how an agent would

   go about generating the circuit descriptor since they need to know how other

   domains are going to generate their segment identifiers.

2. In the segment and circuit descriptors, there are two different relationship

   names used: 'connects' and 'serialcompound'. In both cases, the relationship

   is describing the constituent elements that make up the link (links in the

   case of the circuit descriptor, and ports in the case of the segment

   descriptor). Since they're describing the same conceptual relationship,

   having the same name would be good.

3. It looks like the SIP agent is registering the segment ID. I'm curious why

   it's being registered there.

4. All of the XQuery requests to the hLS are of the form "what services contain

   eventType X?". This type of request can be handled using the summary

   requests which has the side benefit of not embedding more XQuery into

   protocol. 

5. Relatedly, I'd like to specify that XPath queries be the only ones used the

   TS. This way there's a hope of moving away from the XQuery-based protocols,

   and their dependency on an XML Database. Since XPath can be converted to SQL

   requests, that'd be much easier to transition to something else. It'd

   probably also be good to specify exactly the subset of XPath to be supported

   so that we don't hit the XQuery issue where you are required to have a

   full-blown XPath implementation to implement the protocol. To keep the

   XPath syntax simplified, it'd probably be good to eschew the use of

   functions (at least in the beginning). e.g.: using /*:link[@id="XYZ"] or we

   could strip off the new for the namespace and have /link[@id="XYZ"] .

6. In the TSQueryResponse example, it looks like far more is returned than I'd

   expect given the query. Was this just a copy-and-paste instance?

7. The TSAddRequest wraps the individual network elements in an nml:topology

   element. In the TSQueryResponse response, the individual elements are

   wrapped in a 'datum'. It'd probably make sense to have the TSAddRequest wrap

   the individual elements in a 'datum' as well.

8. What kinds of additional info are you thinking about in 9.2.1.9? Is this

   stuff that is expected to be retrievable by the client, or is it stuff that

   the MA is going to strip out?

9. I'm curious what kinds of subjects are envisioned for the SIP to MP

   messages.

10. In 9.2.2.1, the client does a request for every service containing anything

   on pionier.net. That could easily become non-scalable. It might make sense

   to qualify the request a bit (e.g. by including eventTypes of interest):

   <nmwg:metadata metadataIdRef="meta1" id="metadata.8532851"><summary:subject>

      <summary:subject>

         <nml:domain id="pionier.net"/>

         <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>

      </summary:subject>

      <nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</nmwg:eventType>

   </nmwg:metadata>

11. Also, Jason noticed that the LS response has a datum element that it shouldn't:

   <nmwg:message>

     <nmwg:metadata metadataIdRef="meta1" id="metadata.8532851">

       <summary:subject>

         <nml:domain id="psu.edu" />

         <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>

       </summary:subject>

       <nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</nmwg:eventType>

     </nmwg:metadata>

     <nmwg:data metadataIdRef="metadata.8532851" id="data.14027668">

       <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/" id="3b010db87b462c778bd017447fcc762c">

         <perfsonar:subject xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/">

           <psservice:service xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/">

             <psservice:serviceName>Lookup Service</psservice:serviceName>

             <psservice:accessPoint>http://128.118.46.245:9995/perfSONAR_PS/services/hLS</psservice:accessPoint>

             <psservice:serviceType>hLS</psservice:serviceType>

             <psservice:serviceDescription>perfSONAR_PS Lookup Service at Penn State in University Park, PA USA</psservice:serviceDescription>

           </psservice:service>

         </perfsonar:subject>

       </nmwg:metadata>

     </nmwg:data>

   </nmwg:message>

Cheers,

Aaron