[Nmc-wg] Circuit monitoring - next draft of MDM proposal
Roman Łapacz
romradz at man.poznan.pl
Fri Apr 1 07:25:07 CDT 2011
Hi Aaron/All,
I'm sending an example of extended lookup information (this is what we
discussed yesterday; two new things: eventType and message types in the
lookup info):
<?xml version="1.0" encoding="UTF-8"?>
<nmwg:message id="msg1"
type="LSRegisterRequest"
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/"
xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/">
<nmwg:metadata id="meta1">
<perfsonar:subject id="1">
<psservice:service id="mat_1">
<psservice:serviceName>Measurement Archive for intra-domain
topology</psservice:serviceName>
<psservice:accessPoint>http://host:8080/services/ma_t</psservice:accessPoint>
<psservice:serviceType>MA</psservice:serviceType>
<psservice:organization>PIONIER</psservice:organization>
</psservice:service>
</perfsonar:subject>
<!-- eventType indicates what kind of data the service supports -->
<nmwg:eventType>http://ggf.org/ns/nmwg/topology/201103</nmwg:eventType>
<psservice:parameters>
<nmwg:parameter name="supportedMessage">TSAddRequest</nmwg:parameter>
<nmwg:parameter name="supportedMessage">TSQueryRequest</nmwg:parameter>
</psservice:parameters>
</nmwg:metadata>
<!-- There is no data element(s) with metadata information because -->
<!-- at the beginning (when the service starts) MA(t) does not store any
data -->
<nmwg:data id="data1" metadataIdRef="meta1"/>
</nmwg:message>
The problem I see is that the MA and the MP may use the same message
type (SetupDataRequest) for different actions. In case of the MA it is
fetching data. For the MP it is executing a test or collecting data. I
don't think we've had a separate message type defined for the MP and if
I'm not wrong SetupDataRequest was used (until it is not clarified I
prefer to have 'operation' parameter).
Cheers,
Roman
W dniu 2011-03-29 17:57, Aaron Brown pisze:
> Hey Roman,
>
> Comments inline.
>
> Cheers,
> Aaron
>
> On Mar 29, 2011, at 8:31 AM, Roman Łapacz wrote:
>
>> W dniu 2011-03-28 14:23, Aaron Brown pisze:
>>>
>>> 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.
>>
>> I would not use message types because they also might be misleading
>> like service types. I like the idea of registering the operations
>> that are supported by a service. Changing a bit your example: "the
>> services that support store operation of utilization data".
>
> I guess the open question here is what meaning service type (or
> supported operation) is meant to convey. Is there an instance where
> two different services would support the same data types and the same
> messages, but have different semantics?
>
>>> 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.
>>
>> I've used eventType parameters and I knew this wasn't a good solution
>> but I'd like to see your comments on this. The parameter 'operation'
>> would be more suitable. What do you think?
>>
>>> 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.
>>
>> But the GLIF format and its domain part isn't enough? An agent does
>> not have to know what the last part of the GLIF urn means.
>> (I'll forward this comment to the AutoBAHN team)
>
> In the model, the starting domain creates the circuit descriptor.
> However, to do that, that domain needs to know how the other domains
> are going to set the identifiers for their segment descriptors. There
> are two ways to do that:
>
> 1) have a programmatic way that each domain uses to create the segment
> id using information that is available to all domains
> 2) have the starting domain contact each of the other domains and
> request the segment identifiers
>
> I'd prefer #1 if possible since it makes it substantially easier to
> deploy. However, for #1, there's not a good way, if OSCARS is the
> starting domain, to figure out how an AutoBAHN domain is going to name
> its segments since all OSCARS will have is a GRI (not compatible with
> AutoBAHN's id structure), and the domain names.
>
>>> 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.
>>
>> Agree. I was thinking about this while writing descriptor examples in
>> the doc but which one to choose? I would take "connects" but this
>> must be agreed by all of us. So are you fine to take "connects"?
>
> I'd just been using "over", but would be fine with "connects".
>
>>> 3. It looks like the SIP agent is registering the segment ID. I'm
>>> curious why
>>> it's being registered there.
>>
>> The SIP contains info about running monitoring sessions and stores it
>> after they are finished to keep the history (detailed info - segment
>> descriptors - can be fetched from the MA(t) or the MA(at)).
>>
>>
>>>
>>> 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"] .
>>
>> To keep compatibility I'll replace xquery statements with xpaths (we
>> have started doing this).
>>
>>>
>>> 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?
>>
>> Yes, you're right (SIP->MA(t)). There's a short comment in the
>> request why.
>>
>>>
>>> 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.
>>
>> Fine for me (I didn't do it this way because I followed the example
>> http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-TopologyService/doc/requests/TSAddRequest.xml
>> where there's no datum element)
>
> Yeah, I figured as such. I'd just like to change the semantics to be
> more similar to other services.
>
>>> 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?
>>
>> Additional info in parameters may contain some general info about the
>> reservation and its monitoring (for example: duration) but now I
>> don't have anything specific in my mind.
>>
>>> 9. I'm curious what kinds of subjects are envisioned for the SIP to MP
>>> messages.
>>
>> I don't think the MDM release has an MP service (collecting the link
>> status) ready to be used so it will be developed sooner or later.
>> It's difficult now to say how a possible request will look like (not
>> sure I'll be involved in the work on messages for it).
>>
>>> 10. In 9.2.2.1, the client does a request for every service
>>> containing anything
>>> on pionier.net <http://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):
>>
>> This request goes to the gLS so only address(es) of hLS(es) of
>> pionier domain will be provided (I don't expect a domain may have
>> many hLS(es)). But of course additional filtering info may be used
>> (depends on what is summarized and sent by the hLS to the gLS).
>
> Well, the result would be any hLS that has any data on the pionier
> domain. So if there are other domains out there that running PingER,
> HADES, owamp or bwctl tests against pionier hosts, they'd be returned
> as well. On the flipside, I'm not sure adding the eventType would help
> this situation since many of those domains could also have utilization
> data (which may or may not be applicable to the pionier domain), so a
> search for utilization data and pionier could grab the same set of
> domains. I'm wondering if the LS summarization should account for the
> relationships between the data and the domains. The semantics of the
> summary query to the gLS would be "give me the hLSes that know about
> services with utilization data about internet2.edu
> <http://internet2.edu>", as opposed to, "give me the hLSes that know
> about services with data about internet2.edu <http://internet2.edu>,
> and services with utilization data).
>
>>> <nmwg:metadata metadataIdRef="meta1"
>>> id="metadata.8532851"><summary:subject>
>>> <summary:subject>
>>> <nml:domain id="pionier.net <http://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 <http://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>
>>
>> I'll update it.
>>
>> thanks,
>> Roman
>>
>>>
>>>
>>> Cheers,
>>> Aaron
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20110401/4e3087b8/attachment-0001.html
More information about the Nmc-wg
mailing list