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. 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",
as opposed to, "give me the hLSes that know about services
with data about
internet2.edu, and services
with utilization data).
<nmwg:metadata metadataIdRef="meta1"
id="metadata.8532851"><summary:subject>
<summary:subject>
</summary:subject>
</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>
</summary:subject>
</nmwg:metadata>
<nmwg:data
metadataIdRef="metadata.8532851"
id="data.14027668">
<psservice:serviceName>Lookup
Service</psservice:serviceName>
<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