| Network Measurement Working Group | M Swany, Editor |
| UDel | |
| Intended status: Informational | May 2007 |
An Extensible Schema for Network Measurement and Performance Data
This memo provides information for the Grid community. It does not specify any standards or technical recommendations. Distribution is unlimited.
Copyright © The Open Grid Forum (2007). All Rights Reserved.
This document presents an extensible encoding standard for network measurement and performance data. Uniform encoding of this class of information is a key problem for federated network management, and multi-domain dynamic provisioning of network circuits, as well as in advanced distributed computing environments, such as Grid computing.
This work is born of the need for a common mechanism for the exchange of network measurement and performance data. In the case of research-oriented networks, parties often want to exchange network performance data with neighbors for debugging purposes. In general, however, there is no single system that is in use. In the Grid community, the need to exchange network metrics of various sorts is often highlighted. In short it is highly desirable to have an extensible schema for network performance information that gives a common, general framework for representation and exchange.
This document builds on previous versions of the network measurement schemata. This document describes Version 2 of the Grid Forum's Network Measurement Working Group (NM-WG) schema.
The goal is to define a neutral representation for network measurements that can be easily extended to support new types of data. This representation should identify forms of network performance data as well as to create standardized mechanism to both describe and publish these metrics.
One of the high-level goals of this representation is to "normalize" the data representation by removing as much redundancy as possible. The basic schema design is based on the observation that network measurement data can be divided into two major classes. The first class is the Metadata, which describes the type of measurement data, the entity or entities being measured and the particular parameters of the measurement. The second class is the data itself, which is, at its simplest, a timestamp and a value, or vector of values. This division of Metadata and Data is present throughout the system. This structure is present both in the "Messages" sent between various data elements and in data "Stores" -- persistent storage of XML documents representing system state.
This schema defines the basic elements that can be used to represent performance data. The first distinction is between the "Metadata", the relatively static information regarding the data, and the "Data" itself, which generally changes over time. The key idea is that, for repeated measurements, which is a common case for performance data in networks and Grids, the Metadata need not be repeated with each measurement, saving space and effort.
Each top-level element in this schema has an Identifier attribute called "Id". There are many cases in which one element needs to refer to another. For these cases an Id Reference is used. Note that we have not used the XML Schema ID and IDREF types, although they seem to be appropriate. The reason is that for an IDREF, the corresponding ID must appear in the same document. We envision remote Id references (with e.g., a generic URL or a WS-Addressing EPR) and thus find this limitation overly restrictive. (Note that another possibility is the use of a simple element to resolve the local ID and point to remote Metadata.)
The Metadata must describe the Data unambiguously. To accomplish this, the Metadata must include three key things:
The "Subject" identifies the measured entity. For networks, this may represent a path between two hosts or an interface on a network device.
The "Event Type" is the canonical name of the aspect of the subject being measured, or the actual event (i.e. "characteristic") being reported.
The "Parameters" describe the exact way in which a particular measurement was gathered. These can include parameters to active measurement tools. Essentially, anything needed to determine which measurements are fungible should be included here. Parameters take the form of name, value pairs. The value of a parameter can itself be a complex XML element.
The "Data" element has an Identifier (Id) and an Identifier Reference (metadataIdRef) that refers to the "Metadata" that describes it. It contains some number of "Datum" elements.
The "Datum" elements hold the timestamp and value of the measurement or value of the event. For many network measurement data sources, this can be a time-series of timestamp, value pairs. For other measurement types, the result value may be a vector.
The above-named elements are currently contained in two types of outer elements, "Message" and "Store". They have exactly the same structure, i.e. containing "Metadata" and "Data" elements. Each may have an attribute called "Type" to indicate its type. Each may also contain one "Parameters" element to indicate Message- or Store-level parameters and options. This allows for a great deal of customization.
A key facet in this schema is the observation that the above elements can be used to describe any network measurement, but the exact content of the each will vary with the measurement type. We have adopted XML namespaces to allow reuse of these same basic element names, but to vary the contents of the basic elements for each different type of data.
In this way, some superficial examination of the structure of a message or information store can take place without looking at the details of the contents. Some processing functionality should be able to consume new data types with no modification.
We envision there being two major classes of namespace URIs. The first is a canonical name based on the Hierarchy of Network Measurements from this working group. (cite). The second is based on an organization's domain name and allows for autonomous extension in much the same way as the Enterprise branch of the OID space (cite) allows. Finally, as this specification doesn't address the embedding of this schema into other systems, we note that the relevant parts of the namespace can be appended to another namespace if one is already in use.
The namespace-based approach described above provides extensibility by defining new basic elements in a tool- or characteristic-specific namespace. An example of this is presented in the Ping example later.
This needs some textual description.
While the working group has made every effort to completely describe a few measurement types, we are well aware that tools, and ideas about how to represent them, may change. For this reason, each of the schema areas must have a version number.
To accomplish this, each of the URIs that comprise the namespaces end in a version number. TBD, conforming to recent GFD on namespaces.
While a complete Metadata block can be used to unambiguously describe a data block, it is often desirable to combine multiple, partial Metadata blocks together. The main reason for this is reuse of information. Using the "metadataIdRef" attribute of a Metadata block allows us to form a "chain" of Metadata blocks. This means that not all Metadata blocks will have an associated eventType. At the end of the chain, however, there MUST be an event type.
In addition to describing sets of raw data, Metadata blocks can also be used to describe transformation operations performed on a set of data. Thus, a list of Metadata blocks, including origin and transformations, can be used to unambiguously describe the provenance of any network data. This can also be used in cases where the transformation is "internal" and the original data is not available. This can be thought of as describing set operations on the original set as it passes through a list of operators.
One example of this is the selection of a subset of data from a a set, based on time or value. A "select" metadata block can be used to describe this filtering operation independent of the source. Formally, we can think of this as as an operation on one set that produces another set. This metadata block must unambiguously defining that set operation.
This relationship between Metadata blocks is expressed by having the Subject metadataIdRef refer to another Metadata, which denotes having it be input to an operation.
# ##############################################################
#
# File: nmbase.rnc - Main schema definition
# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
# Purpose: This is the main schema file, it defines the
# general structure of an NMWG message or store
#
# ##############################################################
# ##############################################################
# Namespace definitions
# ##############################################################
namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/"
# ##############################################################
# Include additional functionality from other files
# ##############################################################
include "nmtime.rnc"
include "filter.rnc"
# ##############################################################
# Every NMWG document should begin with either a 'store' or
# 'message' element
# Patterns are defined for the content of each element.
#
# Example (using message):
#
# <nmwg:message id="OPTIONAL_ID"
# messageIdRef="OPTIONAL_REFERENCE_ID"
# type="REQUIRED_TYPE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- OPTIONAL PARAMETERS -->
#
# <!-- OPTIONAL (MULTIPLE) METADATA -->
#
# <!-- OPTIONAL (MULTIPLE) DATA -->
#
# </nmwg:message>
#
# ##############################################################
start =
(
element nmwg:message {
MessageContent
} |
element nmwg:store {
StoreContent
}
)
MessageContent =
Identifier? &
MessageIdentifierRef? &
Type &
Parameters? &
(
Metadata |
Data
)+
StoreContent =
Identifier? &
MessageIdentifierRef? &
Type &
Parameters? &
(
Metadata |
Data
)+
# ##############################################################
# Metadata is the information that describes data. This
# information doesn't change over time
#
#
# Example:
#
# <nmwg:metadata id="REQUIRED_ID"
# metadataIdRef="OPTIONAL_REFERENCE_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- TBD OPTIONAL SUBJECT -->
#
# <!-- TBD OPTIONAL PARAMETERS -->
#
# <!-- TBD OPTIONAL EVENTTYPE -->
#
# <!-- TBD OPTIONAL KEY -->
#
# <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
#
# </nmwg:metadata>
#
# ##############################################################
Metadata =
element nmwg:metadata {
(
Identifier &
MetadataIdentifierRef? &
MetadataContent
),
anyElement*
}
MetadataBlock =
Subject? &
Parameters?
MetadataContent =
(
MetadataBlock |
FilterMetadataBlock
) &
EventType? &
Key?
# ##############################################################
# Subject identifies an endPoint (or points), perhaps the name of
# a service or some other form of physical location. For the
# purpose of the general case, we make no assumptions on potential
# elements and allow all elements, in any namespace. Verification
# can be handled in subsequent schema files.
#
# Example:
#
# <nmwg:subject id="REQUIRED_ID"
# metadataIdRef="OPTIONAL_REFERENCE_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- ANY ELEMENT IN ANY NAMESPACE -->
#
# </nmwg:subject>
#
# ##############################################################
Subject =
element nmwg:subject {
SubjectContent
}
SubjectContent =
(
Identifier &
MetadataIdentifierRef?
),
anyElement*
# ##############################################################
# Parameters and Parameter elements can be used in a number of
# ways in: 1) the message to signify items such as time stamp
# or authorization or 2) metadata or data to specify filters or
# special cases for the information. A 'parameters' block
# has an id and encloses one to many 'parameter' elements.
# These elements have a required 'name', and may contain
# an attribute, element, or text value (only one please;
# software using this should consider complex elements, then
# text, and finally the value attribute; exceptions should
# be thrown on duplicates).
#
# Example:
#
# <nmwg:parameters id="REQUIRED_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <nmwg:parameter name="REQUIRED_NAME" value="OPTIONAL_VALUE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- ANY TEXT, OR ANY ELEMENT ANY NAMESPACE (IF YOU DID NOT
# USE THE VALUE ATTRIBUTE) -->
#
# </nmwg:parameter>
#
# <!-- MORE PARAMETERS -->
#
# </nmwg:parameters>
#
# The namespaces can of course be different.
#
# ##############################################################
Parameters =
element nmwg:parameters {
ParametersContent
}
ParametersContent =
Identifier &
Parameter+
Parameter =
element nmwg:parameter {
attribute name { xsd:string } &
(
attribute value { xsd:string } |
(
anyElement |
text
)
)
}
# ##############################################################
# Event type is a simple text element used to describe the
# characteristic or event of the data.
#
# Example:
#
# <nmwg:eventType xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- TEXT -->
#
# </nmwg:eventType>
#
# ##############################################################
EventType =
element nmwg:eventType { xsd:string }
# ##############################################################
# The key is used to return a 'pointer' or otherwise special piece
# of identifying information in response to a request. For now,
# this information is enclosed only within a parameters block.
# The optional ID can be used to track past searches.
#
# Example:
#
# <nmwg:key id="OPTIONAL_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- OPTIONAL PARAMETERS -->
#
# </nmwg:key>
#
# ##############################################################
Key =
element nmwg:key {
Identifier? &
(
Parameters |
FilterParameters
)
}
# ##############################################################
# The data block is complex and has the potential to contain
# many things. The data block can be used to return a metadata
# block from a request, commonTime or datum elements, keys,
# or something that we have perhaps not defined as of yet.
#
# Example:
#
# <nmwg:data id="REQUIRED_ID"
# metadataIdRef="OPTIONAL_REFERENCE_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- OPTIONAL (MULTIPLE) METADATA -->
#
# <!-- OR -->
#
# <!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND
# OPTIONAL (MULTIPLE) DATUM ELEMENTS-->
#
# <!-- OR -->
#
# <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
#
# <!-- OR -->
#
# <!-- OPTIONAL (MULTIPLE) KEY ELEMENTS -->
#
# <!-- OR -->
#
# <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
#
# </nmwg:data>
#
# ##############################################################
Data =
element nmwg:data {
(
Identifier &
MetadataIdentifierRef? &
(
Metadata* |
(
commonTime+ &
Datum*
) |
Datum* |
Key*
)
),
anyElement*
}
# ##############################################################
# CommonTime is used as a shortcut that is able to 'factor out'
# a frequently occurring time range that a group of datum (or
# other) elements might share, thus reducing the verbosity of the
# XML representation. CommonTime is similar to the other NMWG time
# stamps (from nmtime.rnc) in its potential time representations.
#
# It is unfortunate that it needs to be in this file and not
# nmtime.rnc, but as it occurs outside the datum, it is here.
#
# Example:
#
# <nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
# duration="OPTIONAL_DURATION"
# inclusive="OPTIONAL_INCLUSIVE_FLAG"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR
# DURATION) -->
#
# <!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) -->
#
# <!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE
# ATTRIBUTE) -->
#
# <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
#
# <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
# </nmwg:commonTime>
#
# ##############################################################
commonTime =
element nmwg:commonTime {
(
Type &
(
TimeStamp |
(
StartTime &
(
EndTime |
Duration
)
)
) &
Datum*
),
anyElement*
}
# ##############################################################
# The datum is meant to be generic in this case because specific
# namespace declarations should be used to better define what
# format that datum should have.
#
# Example:
#
# <nmwg:datum ANY_ATTRIBUTE
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- ANY ELEMENT IN ANY NAMESPACE OR ANY TEXT -->
#
# </nmwg:datum>
#
# ##############################################################
Datum =
element nmwg:datum {
anyThing
}
# ##############################################################
# Common elements are defined as named patterns as they are re-
# used several times.
# ##############################################################
Identifier =
attribute id { xsd:string }
MetadataIdentifierRef =
attribute metadataIdRef { xsd:string }
MessageIdentifierRef =
attribute messageIdRef { xsd:string }
Type =
attribute type { xsd:string }
# ##############################################################
# This sequence allows any element, attribute, or text (regardless
# of name or namespace) into the document when invoked.
# ##############################################################
anyElement =
element * {
anyThing
}
anyAttribute =
attribute * { text }
anyThing =
(
anyElement |
anyAttribute |
text
)*
# ##############################################################
# This sequence allows any element, attribute, or text (only in the
# NMWG namespace) into the document when invoked.
# ##############################################################
anyNMWGElement =
element nmwg:* {
anyNMWGThing
}
anyNMWGAttribute =
attribute * { text }
anyNMWGThing =
(
anyNMWGElement |
anyNMWGAttribute |
text
)*
# ##############################################################
#
# File: nmtime.rnc - NMWG Time definitions
# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
# Purpose: This describes a set of time formats for
# representing measurements.
#
# ##############################################################
# ##############################################################
# Namespace definitions
# ##############################################################
namespace nmtm = "http://ggf.org/ns/nmwg/time/2.0/"
# ##############################################################
# Regular time is attached to a specific datum instance; it is
# essentially the same as before, but cannot have anything
# 'inside' of it. The type can be simple, like UNIX, or it
# could be something like timeRange or timeInterval. If this is
# the case, we would then see the two extra time designators for
# the start and end (or duration)
#
# Example:
#
# <nmtm:time type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
# duration="OPTIONAL_DURATION"
# inclusive="OPTIONAL_INCLUSIVE_FLAG"
# xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/">
#
# <!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR
# DURATION) -->
#
# <!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) -->
#
# <!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE
# ATTRIBUTE) -->
#
# </nmtm:time>
#
# ##############################################################
Time =
element nmtm:time {
attribute type { xsd:string } &
(
TimeStamp |
(
StartTime &
(
EndTime |
Duration
)
)
)
}
TimeStamp =
(
attribute value { xsd:string } |
element nmtm:value { xsd:string }
)
Duration =
attribute duration { xsd:string }
TimeContent =
attribute type { text } &
attribute inclusive { text }? &
TimeStamp
StartTime =
element nmtm:start {
TimeContent
}
EndTime =
element nmtm:end {
TimeContent
}
# ##############################################################
#
# File: nmtopo.rnc - Schema to describe topological
# elements.
# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z zurawski $
#
# ##############################################################
# ##############################################################
# Namespace definitions
# ##############################################################
namespace nmwgtopo = "http://ggf.org/ns/nmwg/topology/2.0/"
# ##############################################################
# Covers the basic point to point measurement situation. The two
# points are a source and destination; may contain information
# such as hostname or ip address, and port number when applicable.
#
# Example:
#
# <nmwgtopo:endPointPair
# xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
#
# <nmwgtopo:src type="REQUIRED_TYPE" value="REQUIRED_VALUE"
# port="OPTIONAL_PORT"/>
#
# <nmwgtopo:dst type="REQUIRED_TYPE" value="REQUIRED_VALUE"
# port="OPTIONAL_PORT"/>
#
# </nmwgtopo:endPointPair>
#
# ##############################################################
EndpointPair =
element nmwgtopo:endPointPair {
EndpointPairContent
}
EndpointPairContent =
element nmwgtopo:src {
EndpointContent
} &
element nmwgtopo:dst {
EndpointContent
}
# ##############################################################
# Similar to above, from one point only.
#
# Example:
#
# <nmwgtopo:endPoint type="REQUIRED_TYPE" value="REQUIRED_VALUE"
# port="OPTIONAL_PORT"/>
#
# ##############################################################
Endpoint =
element nmwgtopo:endPoint {
EndpointContent
}
EndpointContent =
(
attribute value { xsd:string } |
text
) &
attribute type { xsd:string } &
attribute port { xsd:string }?
# ##############################################################
# When looking at network utilization numbers (from a router or
# related software) there is a different set of applicable
# information
#
# Example:
#
# <nmwgtopo:interface xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
#
# <nmwgtopo:ipAddress type='REQUIRED_TYPE'> TEXT </nmwgtopo:ipAddress>
#
# <nmwgtopo:hostName> TEXT </nmwgtopo:hostName>
#
# <nmwgtopo:ifName> TEXT </nmwgtopo:ifName>
#
# <nmwgtopo:ifDescription> TEXT </nmwgtopo:ifDescription>
#
# <nmwgtopo:ifAddress type='REQUIRED_TYPE'> TEXT </nmwgtopo:ifAddress>
#
# <nmwgtopo:ifHostName> TEXT </nmwgtopo:ifHostName>
#
# <nmwgtopo:ifIndex> TEXT </nmwgtopo:ifIndex>
#
# <nmwgtopo:type> TEXT </nmwgtopo:type>
#
# <nmwgtopo:direction> TEXT </nmwgtopo:direction>
#
# <nmwgtopo:authRealm> TEXT </nmwgtopo:authRealm>
#
# <nmwgtopo:classOfService> TEXT </nmwgtopo:classOfService>
#
# <nmwgtopo:capacity> TEXT </nmwgtopo:capacity>
#
# </nmwgtopo:interface>
#
# ##############################################################
Interface =
element nmwgtopo:interface {
InterfaceContent
}
InterfaceContent =
element nmwgtopo:ipAddress {
Address
}? &
element nmwgtopo:hostName { xsd:string }? &
element nmwgtopo:ifName { xsd:string }? &
element nmwgtopo:ifDescription { xsd:string }? &
element nmwgtopo:ifAddress {
Address
}? &
element nmwgtopo:ifHostName { xsd:string }? &
element nmwgtopo:ifIndex { xsd:string }? &
element nmwgtopo:type { xsd:string }? &
element nmwgtopo:direction { xsd:string }? &
element nmwgtopo:authRealm { xsd:string }? &
element nmwgtopo:classOfService { xsd:string }? &
element nmwgtopo:capacity { xsd:string }?
Address =
(
attribute value { xsd:string } |
text
) &
attribute type { xsd:string }
This section includes examples of network measurements rendered in our schema. These examples are not intended to be normative, although at this time of this writing, they are in use.
# ##############################################################
#
# File: ping.rnc - Specialized schema for the ping
# tool
# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z zurawski $
# Purpose: Defines elements to be used in the representation
# of ping measurements.
#
# ##############################################################
# ##############################################################
# Namespace definitions
# ##############################################################
namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/"
namespace ping = "http://ggf.org/ns/nmwg/tools/ping/2.0/"
namespace nmwgr = "http://ggf.org/ns/nmwg/result/2.0/"
# ##############################################################
# Include additional functionality from other files
# ##############################################################
include "nmtopo.rnc"
include "nmtopo_ver3.rnc"
include "result.rnc"
include "nmbase.rnc" {
Metadata |= PingMetadata
Data |= PingData
}
# ##############################################################
# Metadata
# ##############################################################
PingMetadata =
element nmwg:metadata {
Identifier &
MetadataIdentifierRef? &
PingMetadataContent
}
PingMetadataBlock =
PingSubject? &
(
PingParameters |
Parameters
)?
PingMetadataContent =
(
PingMetadataBlock |
FilterMetadataBlock
) &
EventType? &
Key?
# ##############################################################
# Redefined ping subject allows only an endPointPair, and the
# two id attributes.
#
# Example:
#
# <ping:subject id="REQUIRED_ID"
# metadataIdRef="OPTIONAL_REFERENCE_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
#
# <nmwgtopo:endPointPair xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
#
# <nmwgtopo:src type="REQUIRED_TYPE" value="REQUIRED_VALUE"
# port="OPTIONAL_PORT"/>
#
# <nmwgtopo:dst type="REQUIRED_TYPE" value="REQUIRED_VALUE"
# port="OPTIONAL_PORT"/>
#
# </nmwgtopo:endPointPair>
#
# </ping:subject>
#
# ##############################################################
PingSubject =
element ping:subject {
Identifier &
MetadataIdentifierRef? &
(
EndpointPair |
L4EndpointPair
)
}
# ##############################################################
# This is simply the regular method of doing parameters with an
# enumeration to limit what 'names' are accepted and an outer
# ping: namespace for the parameters.
#
# Example:
#
# <ping:parameters id="REQUIRED_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
#
# <nmwg:parameter name="REQUIRED_ENUM_NAME" value="OPTIONAL_VALUE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- ANY TEXT, (IF YOU DID NOT USE THE VALUE ATTRIBUTE) -->
#
# </nmwg:parameter>
#
# <!-- MORE PARAMETERS -->
#
# </ping:parameters>
#
# ##############################################################
PingParameters =
element ping:parameters {
Identifier &
PingParameter+
}
PingParameter =
element nmwg:parameter {
attribute name { "count" | "interval" | "deadline" |
"packetSize" | "ttl" | "arguments" |
"valueUnits" | "numBytes" |
"numBytesUnits" } &
(
attribute value { text } |
text
)
}
# ##############################################################
# The data block is complex, and has the potential to contain
# many things. The data block can be used to return a metadata
# block from a request, commonTime or datum elements, keys,
# or something that we have perhaps not defined as of yet.
#
# Example:
#
# <nmwg:data id="REQUIRED_ID"
# metadataIdRef="OPTIONAL_REFERENCE_ID"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
# <!-- OPTIONAL (MULTIPLE) METADATA -->
#
# <!-- OR -->
#
# <!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND
# OPTIONAL (MULTIPLE) DATUM ELEMENTS-->
#
# <!-- OR -->
#
# <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
#
# <!-- OR -->
#
# <!-- OPTIONAL (MULTIPLE) KEY ELEMENTS -->
#
# <!-- OR -->
#
# <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
#
# </nmwg:data>
#
# ##############################################################
PingData =
element nmwg:data {
Identifier &
MetadataIdentifierRef? &
(
(
Metadata* |
PingMetadata*
) |
(
PingCommonTime+ &
(
PingDatum* |
ResultDatum*
)
) |
(
PingDatum* |
ResultDatum*
) |
Key*
)
}
# ##############################################################
# CommonTime
# ##############################################################
PingCommonTime =
element nmwg:commonTime {
Type &
(
TimeStamp |
(
StartTime &
(
EndTime |
Duration
)
)
) &
(
PingDatum* |
ResultDatum*
)
}
# ##############################################################
# These are the basic elements we would expect to see in the
# specific ping datum.
#
# Example:
#
# <ping:datum value="REQUIRED_VALUE"
# valueUnits="OPTIONAL_VALUE_UNITS"
# numBytes="OPTIONAL_NUM_BYTES"
# numBytesUnits="OPTIONAL_NUM_BYTES_UNITS"
# seqNum="OPTIONAL_SEQ_NUM"
# ttl="OPTIONAL_TTL"
# timeType="OPTIONAL_TIME_TYPE"
# timeValue="OPTIONAL_TIME_VALUE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
#
# <!-- TIME ELEMENT (IF ATTRIBUTES NOT USED) -->
#
# </ping:datum>
#
# ##############################################################
PingDatum =
element ping:datum {
attribute value { xsd:float } &
attribute valueUnits { xsd:string }? &
attribute numBytes { xsd:int }? &
attribute numBytesUnits { xsd:string }? &
attribute seqNum { xsd:int }? &
attribute ttl { xsd:int }? &
(
(
attribute timeType { xsd:string } &
attribute timeValue { xsd:string }
) |
Time
)?
}
There are important security concerns associated with the generation and distribution of network measurement information. For example, ISPs frequently consider network configuration and performance information to be proprietary. Furthermore, observing traffic, and, in particular, collecting packet headers, is frequently considered a violation of the presumption of privacy on the network. Systems that collect the measurements described here are sometimes regarded as invasive, and, indeed, poorly designed or configured monitoring tools can consume a disproportionate amount of network bandwidth. Port blocking, protocol blocking, and traffic shaping can impact many measurement tools. Tools, such as traceroute, that send UDP probes to increasing port numbers can appear to be port scans and raise security alerts.
We do not address those concerns in this document, but implementers are encouraged to consider the security implications of generating and distributing measurement information. While distribution of end-to-end application-level measurements is generally accepted, measurements that identify individual users or consume noticeable amounts of resources should be taken carefully, and the distribution of information to other sites that cannot be obtained readily by other users at those sites should be considered carefully.
We gratefully acknowledge the contributions of: Jeff Boote, Eric Boyd, Mark Leese, Dan Gunter, Richard Hughes-Jones and Jason Zurawski and (who else??) the other members of the Network Measurements Working Group.
| [1] | Zurawski, J., Swany, M., and D. Gunter, “A Scalable Framework for Representation and Exchange of Network Measurements”, In Proceedings of 2nd International IEEE/Create-Net Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities (Tridentcom 2006). |
Copyright © The Open Grid Forum (2007). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OGF or other organizations, except as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights defined in the OGF Document process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees.
This document and the information contained herein is provided on an “As Is” basis and the OGF disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose.
The OGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the OGF Secretariat.
The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this recommendation. Please address the information to the OGF Executive Director.
This is a static archive of the previous Open Grid Forum Redmine content management system saved from host redmine.ogf.org file /dmsf_files/9958?download= at Fri, 04 Nov 2022 14:44:03 GMT