perfsonar-dev - nmwg: r228 - trunk/nmwg/doc/nm-schema-base
Subject: perfsonar development work
List archive
- From:
- To: ,
- Subject: nmwg: r228 - trunk/nmwg/doc/nm-schema-base
- Date: Mon, 7 May 2007 07:26:43 -0400
Author: swany
Date: 2007-05-07 07:26:43 -0400 (Mon, 07 May 2007)
New Revision: 228
Modified:
trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
Log:
added ping schema and instance document.
They will now need to be cleaned up.
(some of those comments are really
familiar...)
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-06 16:45:28
UTC (rev 227)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-07 11:26:43
UTC (rev 228)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?><fo:root
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif"
font-size="10pt"><meta-info
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title"
value="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><meta-field name="author"
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master
master-name="first-page" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages-dc"
margin-left="1in" margin-right="1in" page-height="11in"
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in"
column-count="2"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master
master-name="sequence"><fo:single-page-master-reference
master-reference="first-page"/><fo:repeatable-page-master-reference
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
internal-destination="rfc.status"><fo:bookmark-title>Status of this
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.1"><fo:bookmark-title>1
Introduction</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1
Goals</fo:bookmark-title></fo:bookmark></fo
:bookmark><fo:bookmark internal-destination="rfc.section.2">!
<fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic
Elements</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1
Metadata</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event
Type</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2
Data</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.2.1"><fo:bookmark-title>3.2.1
Datum</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.3"><fo:bookmark-title>3.3 Container
Elements</fo:bookmark-
title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.5"><fo:bookmark-title>5
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Security
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11
Appendices</fo:bookmark-title><fo:bookmark inte
rnal-destination="rfc.section.11.1"><fo:bookmark-title>11.1 !
Acknowle
dgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.references"><fo:bookmark-title>12
References</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.authors"><fo:bookmark-title>Author's
Address</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and
Copyright
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
master-reference="sequence" language="en"><fo:static-content
flow-name="header"><fo:table width="100%" text-align="center"
space-before=".2cm" table-layout="fixed"><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">RFC </fo:block></fo:table-cell><fo:table-cell
text-align="center"><fo:block>
+<?xml version="1.0" encoding="UTF-8"?><fo:root
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif"
font-size="10pt"><meta-info
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title"
value="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><meta-field name="author"
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master
master-name="first-page" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages-dc"
margin-left="1in" margin-right="1in" page-height="11in"
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in"
column-count="2"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master
master-name="sequence"><fo:single-page-master-reference
master-reference="first-page"/><fo:repeatable-page-master-reference
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
internal-destination="rfc.status"><fo:bookmark-title>Status of this
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.1"><fo:bookmark-title>1
Introduction</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1
Goals</fo:bookmark-title></fo:bookmark></fo
:bookmark><fo:bookmark internal-destination="rfc.section.2">!
<fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic
Elements</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1
Metadata</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event
Type</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2
Data</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.2.1"><fo:bookmark-title>3.2.1
Datum</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.3"><fo:bookmark-title>3.3 Container
Elements</fo:bookmark-
title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.5"><fo:bookmark-title>5
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Topology
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11
Examples</fo:bookmark-title><fo:bookmark internal
-destination="rfc.section.11.1"><fo:bookmark-title>11.1 Sche!
ma for p
ing</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11.2"><fo:bookmark-title>11.2 Instance
document for ping</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.12"><fo:bookmark-title>12 Security
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.13"><fo:bookmark-title>13
Appendices</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.13.1"><fo:bookmark-title>13.1
Acknowledgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.references"><fo:bookmark-title>14
References</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.authors"><fo:bookmark-title>Author's
Address</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and
Copyright
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
master-reference="se
quence" language="en"><fo:static-content flow-name="header"><fo:table
width="100%" text-align="center" space-before=".2cm"
table-layout="fixed"><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">RFC </fo:block></fo:table-cell><fo:table-cell
text-align="center"><fo:block>
An Extensible Schema for Network Measurement and Performance Data
</fo:block></fo:table-cell><fo:table-cell text-align="end"><fo:block>May
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:static-content
flow-name="footer"><fo:table text-align="center" width="100%"
table-layout="fixed"><fo:table-column
column-width="proportional-column-width(7.5)"/><fo:table-column
column-width="proportional-column-width(13)"/><fo:table-column
column-width="proportional-column-width(7.5)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">Swany</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="center">Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="end">[Page
<fo:page-number/>]</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:flow
flow-name="xsl-region-body"><fo:table width="100%"
table-layout="fixed"><fo:table-column
column-width="proportional-column-width(1)"/><fo:table-column
column-width="proportio
nal-column-width(1)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block>Network
Measurement Working Group</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="right">M Swany,
Editor</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block/></fo:table-cell><fo:table-cell><fo:block
text-align="right">UDel</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block>Intended
status: Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="right">May
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table><fo:block
text-align="center" font-weight="bold" font-size="18pt" space-before="3em"
space-after="3em">
An Extensible Schema for Network Measurement and Performance Data
@@ -54,10 +54,22 @@
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 passed repeatedly, saving
+ 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.
+ </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
+ 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.)
</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.3.1">3.1 Metadata</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
The Metadata must describe the Data unambiguously. To
accomplish this, the Metadata must include three key
@@ -82,10 +94,12 @@
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.</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt" id="rfc.section.3.2">3.2 Data</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- The "Data" element has an Identifier and an Identifier
- Reference that refers to the "Metadata" that describes it. It
- contains some number of "Datum" elements.
+ should be included here. Parameters take the form of name,
+ value pairs. The value of a parameter can itself be a
+ complex XML element.</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt" id="rfc.section.3.2">3.2 Data</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ 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.
</fo:block><fo:block font-weight="bold" font-size="11pt"
keep-with-next="always" space-before="11pt" space-after="3pt"
id="rfc.section.3.2.1">3.2.1 Datum</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
The "Datum" elements hold the timestamp and value of
the
measurement or value of the event. For many network
@@ -160,11 +174,10 @@
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.8">8. Base Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
<fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
#
-# File: nmbase.rnc - Main schema definition
-# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This is the main relax schema file, it defines
-# the general makeup of an NMWG structured message.
-# Reference: http://books.xmlschemata.org/relaxng/page2.html
+# 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
#
# ##############################################################
@@ -182,8 +195,8 @@
include "filter.rnc"
# ##############################################################
-# Every suitable NMWG document should begin with either a
-# 'store' or 'message' element, in the appropriate namespace.
+# Every NMWG document should begin with either a 'store' or
+# 'message' element
# Patterns are defined for the content of each element.
#
# Example (using message):
@@ -193,11 +206,11 @@
# type="REQUIRED_TYPE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
-# <!-- TBD OPTIONAL PARAMETERS -->
+# <!-- OPTIONAL PARAMETERS -->
#
-# <!-- TBD OPTIONAL (MULTIPLE) METADATA -->
+# <!-- OPTIONAL (MULTIPLE) METADATA -->
#
-# <!-- TBD OPTIONAL (MULTIPLE) DATA -->
+# <!-- OPTIONAL (MULTIPLE) DATA -->
#
# </nmwg:message>
#
@@ -236,13 +249,10 @@
# ##############################################################
-# Metadata is the 'data' that describes physical measurements.
-# Metadata can be a physical address or a geographical location;
-# any form of static, re-usable designation. It is important to
-# note that the subject namespace and parameters namespace MUST
-# match (or the parameters can be a generic NMWG) or bad things
-# will occur.
+# Metadata is the information that describes data. This
+# information doesn't change over time
#
+#
# Example:
#
# <nmwg:metadata id="REQUIRED_ID"
@@ -485,11 +495,13 @@
# 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 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 TIME VALUE ELEMENT (USE IF NO VALUE
+# ATTRIBUTE) -->
#
# <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
#
@@ -599,17 +611,14 @@
text
)*
</fo:block>
-
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.9">9. Time Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
<fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
#
-# File: nmtime.rnc - NMWG Time definitions
-# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This describes a general time format for
-# representing measurements. It is far from complete,
-# and may be best represented by other methods.
-# Reference: http://books.xmlschemata.org/relaxng/page2.html
+# 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.
#
# ##############################################################
@@ -686,9 +695,466 @@
TimeContent
}
</fo:block>
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.10">10. Topology Schema</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ <fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
+#
+# File: nmtopo.rnc - Schema to describe topological
+# elements.
+# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z zurawski $
+#
+# ##############################################################
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.10">10. Security Concerns</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">There are important
security concerns associated with the
+
+# ##############################################################
+# 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 }
+
+ </fo:block>
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.11">11. Examples</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.11.1">11.1 Schema for ping</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ <fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">
+# ##############################################################
+#
+# File: ping.rnc - Specialized schema for the ping
+# tool
+# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z zurawski $
+# Purpose: Describes specific elements to be used in the
+# representation and handling of ping
+# measurements.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
+#
+# ##############################################################
+
+
+# ##############################################################
+# 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 is the 'data' that describes physical measurements.
+# Metadata can be something such as a physical address, or
+# a geographical location; any form of static, re-usable
+# designation. It is important to note that the subject
+# namespace and parameters namespace MUST match (or the parameters
+# can be a generic NMWG) or bad things will occur.
+#
+# 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>
+#
+# ##############################################################
+
+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 is used a a shortcut able to 'factor out' a frequently
+# occurring time range that a bunch of datum (or other) elements
+# might share, thus reducing complexity of XML representation.
+# CommonTime is similar to the other NMWG time stamps (from
+# nmtime.rnc) in its potential time representations.
+#
+# 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>
+#
+# ##############################################################
+
+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
+ )?
+ }
+
+ </fo:block>
+ </fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.11.2">11.2 Instance document for ping</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ <fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">
+
+ </fo:block>
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.12">12. Security Concerns</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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
@@ -709,10 +1175,12 @@
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. </fo:block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always"
id="rfc.section.11">11. Appendices</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt" id="rfc.section.11.1">11.1 Acknowledgements</fo:block>
- We gratefully acknowledge the contributions of: Jeff Boote, Eric
- Boyd, Dan Gunter, and Jason Zurawski and (who else??) the other
- members of the Network Measurements Working Group.<fo:block
font-weight="bold" font-size="14pt" keep-with-next="always"
space-before="0pt" space-after="7pt" id="rfc.references"
page-break-before="always">12
+ should be considered carefully. </fo:block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always"
id="rfc.section.13">13. Appendices</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt"
id="rfc.section.13.1">13.1 Acknowledgements</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ 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.
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="0pt" space-after="7pt"
id="rfc.references" page-break-before="always">14
References</fo:block><fo:list-block
provisional-distance-between-starts="3em"><fo:list-item
space-after=".5em"><fo:list-item-label end-indent="label-end()"><fo:block
id="tridentcom">[1]</fo:block></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>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
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2007-05-06 16:45:28
UTC (rev 227)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2007-05-07 11:26:43
UTC (rev 228)
@@ -293,14 +293,13 @@
content: normal;
}
}
-</style><link rel="Author" href="#rfc.authors"><link rel="Copyright"
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction"
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy"
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements"
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces"
href="#rfc.section.4"><link rel="Chapter" title="5 Versioning"
href="#rfc.section.5"><link rel="Chapter" title="6 Metadata Chaining"
href="#rfc.section.6"><link rel="Chapter" title="7 Operation Metadata"
href="#rfc.section.7"><link rel="Chapter" title="8 Base Schema"
href="#rfc.section.8"><link rel="Chapter" title="9 Time Schema"
href="#rfc.section.9"><link rel="Chapter" title="10 Security Concerns"
href="#rfc.section.10"><link rel="Chapter" title="11 Appendices"
href="#rfc.section.11"><link rel="Chapter" href="#rfc.section.12" title="12
References"><meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";><link rel="schema.DC"
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator"
content="Swany, M"><meta name="DC.Date.Issued" scheme="ISO8601"
content="2007-05"></head><body><table summary="header information"
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td
class="front left">Network Measurement Working Group</td><td class="front
right">M Swany, Editor</td></tr><tr><td class="front left"></td><td
class="front right">UDel</td></tr><tr><td class="front left">Intended status:
Informational</td><td class="front right">May 2007</td></tr></table><p
class="title">An Extensible Schema for Network Measurement and Performance
Data</p><h1><a id="rfc.status" href="#rfc.status">Status of this
Memo</a></h1><p>This memo provides information for the Grid community. It
does not specify any standards or technical recommendations. Distribution is
unlimited.</p><h1><a id="rfc.copyrightno
tice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><!
p>Copyri
ght � The Open Grid Forum (2007). All Rights Reserved.</p><hr
class="noprint"><h1 id="rfc.section.1" class="np"><a
href="#rfc.section.1">1.</a> <a id="intro"
href="#intro">Introduction</a></h1><p id="rfc.section.1.p.1">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.</p><p
id="rfc.section.1.p.2">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 o
ften 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.</p><p id="rfc.section.1.p.3">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.</p><h2 id="rfc.section.1.1"><a
href="#rfc.section.1.1">1.1</a> Goals</h2><p
id="rfc.section.1.1.p.1">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.</p><hr class="noprint"><h1 id="rfc.section.2" class="np"><a
href="#rfc.section.2">2.</a> Design Philosophy</h1><p
id="rfc.section.2.p.1">One of the high-level goals of this representation is
to "normalize" the data representation by removing as much r!
edundanc
y 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.</p><hr
class="noprint"><h1 id="rfc.section.3" class="np"><a
href="#rfc.section.3">3.</a> Basic Elements</h1><p
id="rfc.section.3.p.1">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 passed repeatedly, saving space
and effort.</p><h2 id="rfc.section.3.1"><a
href="#rfc.section.3.1">3.1</a> Metadata</h2><p
id="rfc.section.3.1.p.1">The Metadata must describe the Data unambiguously.
To accomplish this, the Metadata must include three key things:</p><dl
class="empty"><dd>"Subject" -- The Subject identifies the entity being
measured. This could include the network path between a pair of hosts, an
interface on a router, or a specific location on the network from which flow
or packet data is captured.</dd><dd>"EventType" -- The EventType identifies
exactly what sort of measurement Event occurred.</dd><dd>"Parameters" -- The
Parameters describe the details of the measurement.</dd></dl><h3
id="rfc.section.3.1.1"><a
href="#rfc.section.3.1.1">3.1.1</a> Subject</h3><p i
d="rfc.section.3.1.1.p.1">The "Subject" identifies the measu!
red enti
ty. For networks, this may represent a path between two hosts or an interface
on a network device.</p><h3 id="rfc.section.3.1.2"><a
href="#rfc.section.3.1.2">3.1.2</a> Event Type</h3><p
id="rfc.section.3.1.2.p.1">The "Event Type" is the canonical name of the
aspect of the subject being measured, or the actual event (i.e.
"characteristic") being reported.</p><h3 id="rfc.section.3.1.3"><a
href="#rfc.section.3.1.3">3.1.3</a> Parameters</h3><p
id="rfc.section.3.1.3.p.1">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.</p><h2
id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> Data</h2><p
id="rfc.section.3.2.p.1">The "Data" element has an Identifier and an
Identifier Reference that refers to the "Metadata" that describes it. It
contains some number of "Datum" elements.<
/p><h3 id="rfc.section.3.2.1"><a
href="#rfc.section.3.2.1">3.2.1</a> Datum</h3><p
id="rfc.section.3.2.1.p.1">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.</p><h2
id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> Container
Elements</h2><p id="rfc.section.3.3.p.1">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.</p><hr
class="noprint"><h1 id="rfc.section.4" class="np"><a
href="#rfc.section.4">4.</a> XML
Namespaces</h1><p id="rfc.section.4.p.1">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.</p><p id="rfc.section.4.p.2">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
modificiation.</p><p id="rfc.section.4.p.3">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.</p><hr class="noprin
t"><h1 id="rfc.section.5" class="np"><a
href="#rfc.section.5">5.</a> Versioning</h1><p
id="rfc.section.5.p.1">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.</p><p id="rfc.section.5.p.2">To
accomplish this, each of the URIs that comprise the namespaces end in a
version number. TBD, conforming to recent GFD on namespaces.</p><hr
class="noprint"><h1 id="rfc.section.6" class="np"><a
href="#rfc.section.6">6.</a> Metadata Chaining</h1><p
id="rfc.section.6.p.1">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 me
ans that not all Metadata blocks will have an associated eve!
ntType.
At the end of the chain, however, there MUST be an event type.</p><hr
class="noprint"><h1 id="rfc.section.7" class="np"><a
href="#rfc.section.7">7.</a> Operation Metadata</h1><p
id="rfc.section.7.p.1">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. </p><p id="rfc.section.7.p.2">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 opera
tion on one set that produces another set. This metadata block must
unambiguously defining that set operation.</p><p id="rfc.section.7.p.3">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.</p><hr class="noprint"><h1 id="rfc.section.8" class="np"><a
href="#rfc.section.8">8.</a> Base Schema</h1><p id="rfc.section.8.p.1">
<pre>
+</style><link rel="Author" href="#rfc.authors"><link rel="Copyright"
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction"
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy"
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements"
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces"
href="#rfc.section.4"><link rel="Chapter" title="5 Versioning"
href="#rfc.section.5"><link rel="Chapter" title="6 Metadata Chaining"
href="#rfc.section.6"><link rel="Chapter" title="7 Operation Metadata"
href="#rfc.section.7"><link rel="Chapter" title="8 Base Schema"
href="#rfc.section.8"><link rel="Chapter" title="9 Time Schema"
href="#rfc.section.9"><link rel="Chapter" title="10 Topology Schema"
href="#rfc.section.10"><link rel="Chapter" title="11 Examples"
href="#rfc.section.11"><link rel="Chapter" title="12 Security Concerns"
href="#rfc.section.12"><link rel="Chapter" title="13 Appendices"
href="#rfc.section.13"><link rel="Chapter" href="#
rfc.section.14" title="14 References"><meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";><link rel="schema.DC"
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator"
content="Swany, M"><meta name="DC.Date.Issued" scheme="ISO8601"
content="2007-05"></head><body><table summary="header information"
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td
class="front left">Network Measurement Working Group</td><td class="front
right">M Swany, Editor</td></tr><tr><td class="front left"></td><td
class="front right">UDel</td></tr><tr><td class="front left">Intended status:
Informational</td><td class="front right">May 2007</td></tr></table><p
class="title">An Extensible Schema for Network Measurement and Performance
Data</p><h1><a id="rfc.status" href="#rfc.status">Status of this
Memo</a></h1><p>This memo provides information for the Gri
d community. It does not specify any standards or technical !
recommen
dations. Distribution is unlimited.</p><h1><a id="rfc.copyrightnotice"
href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright � The Open
Grid Forum (2007). All Rights Reserved.</p><hr class="noprint"><h1
id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a
id="intro" href="#intro">Introduction</a></h1><p id="rfc.section.1.p.1">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.</p><p
id="rfc.section.1.p.2">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.</p><p id="rfc.section.1.p.3">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.</p><h2 id="rfc.section.1.1"><a
href="#rfc.section.1.1">1.1</a> Goals</h2><p
id="rfc.section.1.1.p.1">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.</p><hr class="noprint"><h1 id="rfc.section.2" class="np"><a hre
f="#rfc.section.2">2.</a> Design Philosophy</h1><p id="!
rfc.sect
ion.2.p.1">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.</p><hr class="noprint"><h1
id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Basic
Elements</h1><p id="rfc.section.3.p.1">This schema defines the basic elements
that can be used to repres
ent 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.</p><p id="rfc.section.3.p.2">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 reso
lve the local ID and point to remote Metadata.)</p><h2 id="r!
fc.secti
on.3.1"><a href="#rfc.section.3.1">3.1</a> Metadata</h2><p
id="rfc.section.3.1.p.1">The Metadata must describe the Data unambiguously.
To accomplish this, the Metadata must include three key things:</p><dl
class="empty"><dd>"Subject" -- The Subject identifies the entity being
measured. This could include the network path between a pair of hosts, an
interface on a router, or a specific location on the network from which flow
or packet data is captured.</dd><dd>"EventType" -- The EventType identifies
exactly what sort of measurement Event occurred.</dd><dd>"Parameters" -- The
Parameters describe the details of the measurement.</dd></dl><h3
id="rfc.section.3.1.1"><a
href="#rfc.section.3.1.1">3.1.1</a> Subject</h3><p
id="rfc.section.3.1.1.p.1">The "Subject" identifies the measured entity. For
networks, this may represent a path between two hosts or an interface on a
network device.</p><h3 id="rfc.section.3.1.2"><a
href="#rfc.section.3.1.2">3.1.2</a> Event Type</h3>
<p id="rfc.section.3.1.2.p.1">The "Event Type" is the canonical name of the
aspect of the subject being measured, or the actual event (i.e.
"characteristic") being reported.</p><h3 id="rfc.section.3.1.3"><a
href="#rfc.section.3.1.3">3.1.3</a> Parameters</h3><p
id="rfc.section.3.1.3.p.1">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.</p><h2 id="rfc.section.3.2"><a
href="#rfc.section.3.2">3.2</a> Data</h2><p id="rfc.section.3.2.p.1">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.</p><h3 id="rfc.section.3.2.1"><a
href="#rfc.section.3.2.1
">3.2.1</a> Datum</h3><p id="rfc.section.3.2.1.p.1">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.</p><h2 id="rfc.section.3.3"><a
href="#rfc.section.3.3">3.3</a> Container Elements</h2><p
id="rfc.section.3.3.p.1">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.</p><hr
class="noprint"><h1 id="rfc.section.4" class="np"><a
href="#rfc.section.4">4.</a> XML Namespaces</h1><p
id="rfc.section.4.p.1">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.</p><p id="rfc.section.4.p.2">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 modificiation.</p><p id="rfc.section.4.p.3">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.</p><hr class="noprint"><h1 id="rfc.section.5"
class="np"><a href="#rfc.sectio
n.5">5.</a> Versioning</h1><p id="rfc.section.5.p.1">Wh!
ile 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.</p><p id="rfc.section.5.p.2">To accomplish this, each of the URIs
that comprise the namespaces end in a version number. TBD, conforming to
recent GFD on namespaces.</p><hr class="noprint"><h1 id="rfc.section.6"
class="np"><a href="#rfc.section.6">6.</a> Metadata Chaining</h1><p
id="rfc.section.6.p.1">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 t
ype.</p><hr class="noprint"><h1 id="rfc.section.7" class="np"><a
href="#rfc.section.7">7.</a> Operation Metadata</h1><p
id="rfc.section.7.p.1">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. </p><p id="rfc.section.7.p.2">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.</p><p !
id="rfc.
section.7.p.3">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.</p><hr class="noprint"><h1
id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a> Base
Schema</h1><p id="rfc.section.8.p.1"> <pre>
# ##############################################################
#
-# File: nmbase.rnc - Main schema definition
-# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This is the main relax schema file, it defines
-# the general makeup of an NMWG structured message.
-# Reference: http://books.xmlschemata.org/relaxng/page2.html
+# 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
#
# ##############################################################
@@ -318,8 +317,8 @@
include "filter.rnc"
# ##############################################################
-# Every suitable NMWG document should begin with either a
-# 'store' or 'message' element, in the appropriate namespace.
+# Every NMWG document should begin with either a 'store' or
+# 'message' element
# Patterns are defined for the content of each element.
#
# Example (using message):
@@ -329,11 +328,11 @@
# type="REQUIRED_TYPE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
-# <!-- TBD OPTIONAL PARAMETERS -->
+# <!-- OPTIONAL PARAMETERS -->
#
-# <!-- TBD OPTIONAL (MULTIPLE) METADATA -->
+# <!-- OPTIONAL (MULTIPLE) METADATA -->
#
-# <!-- TBD OPTIONAL (MULTIPLE) DATA -->
+# <!-- OPTIONAL (MULTIPLE) DATA -->
#
# </nmwg:message>
#
@@ -372,13 +371,10 @@
# ##############################################################
-# Metadata is the 'data' that describes physical measurements.
-# Metadata can be a physical address or a geographical location;
-# any form of static, re-usable designation. It is important to
-# note that the subject namespace and parameters namespace MUST
-# match (or the parameters can be a generic NMWG) or bad things
-# will occur.
+# Metadata is the information that describes data. This
+# information doesn't change over time
#
+#
# Example:
#
# <nmwg:metadata id="REQUIRED_ID"
@@ -621,11 +617,13 @@
# 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 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 TIME VALUE ELEMENT (USE IF NO VALUE
+# ATTRIBUTE) -->
#
# <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
#
@@ -737,12 +735,10 @@
</pre> </p><hr class="noprint"><h1 id="rfc.section.9"
class="np"><a href="#rfc.section.9">9.</a> Time Schema</h1><p
id="rfc.section.9.p.1"> <pre>
# ##############################################################
#
-# File: nmtime.rnc - NMWG Time definitions
-# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This describes a general time format for
-# representing measurements. It is far from complete,
-# and may be best represented by other methods.
-# Reference: http://books.xmlschemata.org/relaxng/page2.html
+# 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.
#
# ##############################################################
@@ -818,7 +814,458 @@
element nmtm:end {
TimeContent
}
- </pre> </p><hr class="noprint"><h1 id="rfc.section.10"
class="np"><a href="#rfc.section.10">10.</a> Security Concerns</h1><p
id="rfc.section.10.p.1">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.</p><p id="r
fc.section.10.p.2">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.</p><hr class="noprint"><h1 id="rfc.section.11"
class="np"><a href="#rfc.section.11">11.</a> Appendices</h1><h2
id="rfc.section.11.1"><a
href="#rfc.section.11.1">11.1</a> Acknowledgements</h2><h1 class="np"
id="rfc.references"><a href="#rfc.section.12">12.</a> References</h1><table
summary="References" border="0" cellpadding="2"><tr><td class="topnowrap"><b
id="tridentcom">[1]</b></td><td class="top">Zurawski, J., Swany, M., and D. Gu
nter, “A Scalable Framework for Representation and Exc!
hange of
+ </pre> </p><hr class="noprint"><h1 id="rfc.section.10"
class="np"><a href="#rfc.section.10">10.</a> Topology Schema</h1><p
id="rfc.section.10.p.1"> <pre>
+# ##############################################################
+#
+# 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 }
+
+ </pre> </p><hr class="noprint"><h1 id="rfc.section.11"
class="np"><a href="#rfc.section.11">11.</a> Examples</h1><p
id="rfc.section.11.p.1">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.</p><h2
id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> Schema for
ping</h2><p id="rfc.section.11.1.p.1"> <pre>
+
+# ##############################################################
+#
+# File: ping.rnc - Specialized schema for the ping
+# tool
+# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z zurawski $
+# Purpose: Describes specific elements to be used in the
+# representation and handling of ping
+# measurements.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
+#
+# ##############################################################
+
+
+# ##############################################################
+# 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 is the 'data' that describes physical measurements.
+# Metadata can be something such as a physical address, or
+# a geographical location; any form of static, re-usable
+# designation. It is important to note that the subject
+# namespace and parameters namespace MUST match (or the parameters
+# can be a generic NMWG) or bad things will occur.
+#
+# 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>
+#
+# ##############################################################
+
+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 is used a a shortcut able to 'factor out' a frequently
+# occurring time range that a bunch of datum (or other) elements
+# might share, thus reducing complexity of XML representation.
+# CommonTime is similar to the other NMWG time stamps (from
+# nmtime.rnc) in its potential time representations.
+#
+# 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>
+#
+# ##############################################################
+
+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
+ )?
+ }
+
+ </pre> </p><h2 id="rfc.section.11.2"><a
href="#rfc.section.11.2">11.2</a> Instance document for ping</h2><p
id="rfc.section.11.2.p.1"> <pre>
+ </pre> </p><hr class="noprint"><h1 id="rfc.section.12"
class="np"><a href="#rfc.section.12">12.</a> Security Concerns</h1><p
id="rfc.section.12.p.1">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.</p><p id="rfc
.section.12.p.2">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.</p><hr class="noprint"><h1 id="rfc.section.13"
class="np"><a href="#rfc.section.13">13.</a> Appendices</h1><h2
id="rfc.section.13.1"><a
href="#rfc.section.13.1">13.1</a> Acknowledgements</h2><p
id="rfc.section.13.1.p.1">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.</p><h1
class="np" id="rfc.references"><a href="#rfc.section.14">14!
.</a> Re
ferences</h1><table summary="References" border="0" cellpadding="2"><tr><td
class="topnowrap"><b id="tridentcom">[1]</b></td><td class="top">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
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
===================================================================
(Binary files differ)
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml 2007-05-06 16:45:28
UTC (rev 227)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml 2007-05-07 11:26:43
UTC (rev 228)
@@ -1,7 +1,7 @@
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
-<!--<rfc category="info" ipr="full3978" docName="schema-overview.txt">-->
+<!--<rfc category="info" ipr="full3978" docName="nm-schema-base.txt">-->
<rfc>
<?xml-stylesheet type='text/xsl'
href='rfc2629.xslt' ?>
@@ -101,11 +101,25 @@
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 passed repeatedly, saving
+ 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.
</t>
+
+ <t>
+ 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.)
+ </t>
<section id="metadata" title="Metadata">
<t>
@@ -150,16 +164,18 @@
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.</t>
+ should be included here. Parameters take the form of name,
+ value pairs. The value of a parameter can itself be a
+ complex XML element.</t>
</section>
</section>
<section id="data" title="Data">
<t>
- The "Data" element has an Identifier and an Identifier
- Reference that refers to the "Metadata" that describes it. It
- contains some number of "Datum" elements.
+ 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.
</t>
@@ -273,41 +289,63 @@
</t>
</section>
-
- <!--
- <section id="examples" title="Examples">
-
- <example>
- <title>Example Ping Encoding</title>
- <programlisting><xi:include href="ping1.xml" parse="text"
xmlns:xi="http://www.w3.org/2001/XInclude"/></programlisting>
- </example>
-
- </section>
- -->
-
<section id="base_schema" title="Base Schema">
-
<t>
<artwork><![CDATA[
<inline file="schema/nmbase.rnc"/>
]]></artwork>
-
</t>
</section>
<section id="time_schema" title="Time Schema">
-
<t>
<artwork><![CDATA[
<inline file="schema/nmtime.rnc"/>
]]></artwork>
+ </t>
+ </section>
+ <section id="topo_schema" title="Topology Schema">
+ <t>
+ <artwork><![CDATA[
+ <inline file="schema/nmtopo.rnc"/>
+ ]]></artwork>
</t>
</section>
+ <section id="examples" title="Examples">
+
+ <t>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.</t>
+
+
+ <section id="ping.rnc" title="Schema for ping">
+ <t>
+ <artwork>
+ <![CDATA[
+ <inline file="schema/ping.rnc"/>
+ ]]>
+ </artwork>
+ </t>
+ </section>
+
+ <section id="ping.xml" title="Instance document for ping">
+ <t>
+ <artwork>
+ <![CDATA[
+ <inline file="example-instances/ping.xml"/>
+ ]]>
+ </artwork>
+ </t>
+ </section>
+
+ </section>
+
+
<section title="Security Concerns">
<t>There are important security concerns associated with the
@@ -340,9 +378,12 @@
<section title="Appendices">
<section title="Acknowledgements">
- We gratefully acknowledge the contributions of: Jeff Boote, Eric
- Boyd, Dan Gunter, and Jason Zurawski and (who else??) the other
- members of the Network Measurements Working Group.
+ <t>
+ 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.
+ </t>
</section>
</section>
- nmwg: r228 - trunk/nmwg/doc/nm-schema-base, svnlog, 05/07/2007
Archive powered by MHonArc 2.6.16.