From GEANT2-JRA1 Wiki

This section provides details on the presentation of measurement data, perfSONAR messages, and message types/IDs.

Contents 1 Presentation of measurement data 2 perfSONAR communication 2.1 SOAP details 2.2 TCP details 2.3 IP details 3 perfSONAR Messages 4 Message Structure 5 Metadata particulars 6 Data particulars

Presentation of measurement data

The Global Grid Forum’s Network Measurement Working Group (NMWG) XML schema is used to represent measurement data. It segments the measurement data presentation in two parts: the metadata and the data. Metadata describes the type of measurement data, the entity or entities being measured, and the particular parameters of the measurement. The data itself is simply a timestamp and a vector, or array, of values.

The actual version of the NMWG schema used is version 2. The ".rnc" files describing the schema releases are available on the perfSONAR web site (http://www.perfsonar.net), in the developer's information section (under ‘perfSONAR Specifications; NMWG Schema)’. Each NMWG release is published in a different page, with a link to a tarball containing all ".rnc" files of the release. Each page must contain an indication about the schema (new items, help, etc.).

perfSONAR communication

perfSONAR services exchange NMWG messages. The NMWG schema is not only used to describe measurement data, but also to exchange those data between services. These messages are carried in a SOAP message, carried over HTTP. Details about the underlying protocols are described in the next sub-sections.

SOAP details

The SOAP envelop describes that the body has the type: Document/literal The SOAP body contains the text of the NMWG message.

TCP details

Any TCP port can be used for messages exchange. Services must ensure they use the correct TCP port when sending a message to another service. The TCP port to use is obtained via the lookup service.

IP details

Any IP version (IPv4 or IPv6) can be used for message exchange. A service publishes a URL in the LS that will be used by other services for message exchanges. The IP version used will depend on the results obtained from the DNS query performed for the URL.

perfSONAR Messages

Message Structure

An NMWG message is constructed from an NMWG:message element. The message element can syntactically have any number of NMWG:metadata and NMWG:data elements. The semantics (or business logic) of the specific request will indicate the number of metadata and data elements.

An NMWG message starts with the following tag, used to tell the message type and message ID:

<NMWG:message type="xyz" id="rst" [...]>

perfSONAR message types are bound to the ones specified in the following sections of this document. The perfSONAR message ID is specified by the request sender. The reply must contain the same ID value.

Metadata particulars

metadata elements are used to describe the data of the message being passed. (This can be thought of as the non-time variant portion of the data.) metadata elements can be chained together to make it easier to describe data. (This is a way to aggregate some of the metadata out that will be reused in different ways throughout the message.) There are currently two supported ways to chain metadata together:

1. merge chaining

   This is used to effectively create a single metadata from the perspective of the data. It is useful for aggregating common portions of many metadata into building blocks. Think of it as normalization in the relational database sense.
   

   metadata elements are merge chained using the metadataIdRef attribute of the metadata element.

2. operation (or filter) chaining

   This is used to describe a set of transformations or operations that can be used to create the data (or describes how the data was created). The simplest description of this occurs if you consider a time selection of a given dataset. The complete set of data is described by one metadata with a time sub-selection described by another metadata element.
   

   metadata elements are filter chained using the metadataIdRef attribute of the subject element within the metadata element. In this case, the eventType of the two metadata involved will not match.

In general, a metadata will be comprised of 3 main things:

1. eventType element

   This is typically used to indicate the specific network metric being requested or reported. The value of this element should conform to URL namespaces allowing additional metrics to be created without causing namespace clashes. The namespaces for standard metrics are defined by the NMWG characteristics document http://www.ggf.org/documents/GFD.23.pdf. Namespaces in general need to comply with http://www.ogf.org/documents/GFD.84.pdf. Specifically, for NMWG schemas, namespaces should be in the format:

   http://ggf.org/ns/nmwg/characteristic/CHARPATH/VERSION

   
   

   or

   http://ggf.org/ns/nmwg/tools/TOOL/VERSION

   
   

   In the first case, CHARPATH is defined by the characteristics in the NMWG characteristics document, with the '.s replaced with '/s. VERSION is used to differentiate different versions of the characteristic, and as such will be updated as the NMWG metrics document is updated.

   For example:
   

   http://ggf.org/ns/nmwg/characteristic/utilization/2.0/

   
   

   In the second case, TOOL is a path defined by the tool itself. These are for tools that NMWG has sanctioned in some way.

   For example:
   

   http://ggf.org/ns/nmwg/tools/ping/2.0

   
   

   For tools and characteristics that are not publicized by the OGF (GGF's new name), the following namespaces should be used:

   http://ORG/characteristic/CHARPATH/VERSION

   
   

   http://ORG/tools/TOOL/VERSION

   
   

   ORG must include a domain name under control of one of the project participants and may contain a sub-directory component. This is how new metrics can be added in non-centralized way without worry of name-clashes. These new metrics can be migrated into the ggf namespace if and when there is sufficient desire to do so.

   perfSONAR as a project can/will sanction some tools (and characteristics) and publish schemas cooresponding to those tools. For those schemas, namespaces should be based on the schemas.perfsonar.net domain name.

   For example:
   

   http://schemas.perfsonar.net/tools/admin/echo/2.0

   
   

2. subject element

   This is typically used to indicate the topological element the eventType is relating to.

3. parameters element

   This is used to describe specific features of the given eventType. (ex. bandwidth limits for a throughput test, or time bounds for sampling, etc...)

Data particulars

The data element itself will use a metadataIdRef attribute to point at the metadata that describes this data. data elements will have any number of datum element children. The datum will typically be from a namespace specific to the eventType of the associated metadata element. This is how ANY data type can be supported.