perfsonar-dev - nmwg: r332 - trunk/nmwg/doc/nm-schema-base
Subject: perfsonar development work
List archive
- From:
- To: ,
- Subject: nmwg: r332 - trunk/nmwg/doc/nm-schema-base
- Date: Wed, 27 Feb 2008 12:10:03 -0500
Author: swany
Date: 2008-02-27 12:10:03 -0500 (Wed, 27 Feb 2008)
New Revision: 332
Modified:
trunk/nmwg/doc/nm-schema-base/inline.pl
trunk/nmwg/doc/nm-schema-base/make.sh
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:
changes from last OGF and preparations for OGF22 discussion.
Modified: trunk/nmwg/doc/nm-schema-base/inline.pl
===================================================================
--- trunk/nmwg/doc/nm-schema-base/inline.pl 2008-01-19 23:34:21 UTC (rev
331)
+++ trunk/nmwg/doc/nm-schema-base/inline.pl 2008-02-27 17:10:03 UTC (rev
332)
@@ -6,10 +6,11 @@
chop;
if ($_ =~ m/<inline/) {
($fn) = m/"(.*)"/;
- open F, "< $fn";
+ open F, "< $fn" or die "Can't open $fn\n";
while(<F>) {
print $_;
}
+ close F;
}
else {
print "$_\n";
Modified: trunk/nmwg/doc/nm-schema-base/make.sh
===================================================================
--- trunk/nmwg/doc/nm-schema-base/make.sh 2008-01-19 23:34:21 UTC (rev
331)
+++ trunk/nmwg/doc/nm-schema-base/make.sh 2008-02-27 17:10:03 UTC (rev
332)
@@ -22,7 +22,7 @@
rm -f $INSTANCE-2.html
-$JAVA -jar $SAXON -novw -w0 tmp.$INSTANCE.xml $STYLESHEET2 > $INSTANCE.fo
+$JAVA -jar $SAXON -novw -w0 tmp.$INSTANCE.xml $STYLESHEET2
xml2rfc-page-break-before=avoid > $INSTANCE.fo
cd $FOPDIR
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2008-01-19 23:34:21
UTC (rev 331)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2008-02-27 17:10:03
UTC (rev 332)
@@ -1,184 +1,145 @@
-<?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 Extending the
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11 Topology
Schema</fo:bookmark-title></fo:book
mark><fo:bookmark internal-destination="rfc.section.12"><fo:!
bookmark
-title>12 Examples</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.12.1"><fo:bookmark-title>12.1 Schema for
ping</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.12.2"><fo:bookmark-title>12.2 Instance
document for ping</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.13"><fo:bookmark-title>13 Security
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.14"><fo:bookmark-title>14
Appendices</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.14.1"><fo:bookmark-title>14.1
Acknowledgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.references"><fo:bookmark-title>15
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>Intellectu
al 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(9)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(9)"/><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>September
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="pro
portional-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">September
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
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block
id="rfc.status"/>Status of this Memo</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
+<?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" marg
in-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:book
mark><fo:bookmark internal-destination="rfc.section.2"><fo:b!
ookmark-
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
EventType</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 Extending the
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11 Topology
Schema</fo:bookmark-title></fo:bookmark><
fo:bookmark internal-destination="rfc.section.12"><fo:bookma!
rk-title
>12 Examples</fo:bookmark-title><fo:bookmark
>internal-destination="rfc.section.12.1"><fo:bookmark-title>12.1 Schema for
>ping</fo:bookmark-title></fo:bookmark><fo:bookmark
>internal-destination="rfc.section.12.2"><fo:bookmark-title>12.2 Instance
>document for
>ping</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
>internal-destination="rfc.section.13"><fo:bookmark-title>13 Security
>Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
>internal-destination="rfc.section.14"><fo:bookmark-title>14
>Appendices</fo:bookmark-title><fo:bookmark
>internal-destination="rfc.section.14.1"><fo:bookmark-title>14.1
>Acknowledgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
>internal-destination="rfc.references"><fo:bookmark-title>15
>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 Pro
perty 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(8.5)"/><fo:table-column
column-width="proportional-column-width(73)"/><fo:table-column
column-width="proportional-column-width(8.5)"/><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>February
2008</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-colu
mn
column-width="proportional-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">February
2008</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 </fo:block><fo:block font-weight="bold"
font-size="14pt" keep-with-next="always" space-before="14pt"
space-after="7pt"><fo:block id="rfc.status"/>Status of this
Memo</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
This memo provides information for the Grid community.
It does not specify any standards or technical recommendations.
Distribution is unlimited.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block
id="rfc.copyrightnotice"/>Copyright Notice</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- Copyright © The Open Grid Forum (2007). All Rights Reserved.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.1"><fo:block id="intro"/>1. Introduction</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.1.1">1.1 Goals</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
- 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.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.2">2. Design Philosophy</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.3">3. Basic Elements</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.
- </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
- things:
- </fo:block><fo:list-block
provisional-distance-between-starts="2em"><fo:list-item space-before=".25em"
space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>
- "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.
- </fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-before=".25em" space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>
- "EventType" -- The EventType identifies exactly what sort
- of measurement Event occurred.
- </fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-before=".25em" space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>
- "Parameters" -- The Parameters describe the details of
- the measurement.
-
</fo:block></fo:list-item-body></fo:list-item></fo:list-block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt"
id="rfc.section.3.1.1">3.1.1 Subject</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">The "Subject" identifies the measured
entity. For networks,
- this may represent a path between two hosts or an interface
- on a network device.</fo:block><fo:block font-weight="bold"
font-size="11pt" keep-with-next="always" space-before="11pt"
space-after="3pt" id="rfc.section.3.1.2">3.1.2 Event
Type</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">The "Event Type" is the canonical name of the aspect of the
- subject being measured, or the actual event
- (i.e. "characteristic") being reported.</fo:block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt"
id="rfc.section.3.1.3">3.1.3 Parameters</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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.</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
- measurement data sources, this can be a time-series of
- timestamp, value pairs. For other measurement types,
the
- result value may be a vector.
- </fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.3.3">3.3 Container Elements</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.4">4. XML Namespaces</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
- 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.
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.5">5. Extending the Schema</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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.</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">This needs some
textual description.</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.6">6. Versioning</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- To accomplish this, each of the URIs that comprise the
- namespaces end in a version number. TBD, conforming to recent
- GFD on namespaces.
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.7">7. Metadata Chaining</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
- </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. Operation Metadata</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- 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.
-
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
- 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.
- </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. 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">#
##############################################################
+ Copyright © The Open Grid Forum (2008). All Rights Reserved.
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.1"><fo:block id="intro"/>1. Introduction</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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.</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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 monitoring 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. </fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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.</fo:block><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.1.1"><fo:block id="goals"/>1.1 Goals</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.2"><fo:block id="design_philosophy"/>2. Design
Philosophy</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em"> 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.
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.3"><fo:block id="basic_elements"/>3. Basic
Elements</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">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. </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 with 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"><fo:block
id="metadata"/>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 things:
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
+ <fo:list-block
provisional-distance-between-starts="2em"><fo:list-item space-before=".25em"
space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block> "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.
</fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-before=".25em" space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block> "EventType" -- The EventType
identifies exactly what
+ sort of measurement Event occurred.
</fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-before=".25em" space-after=".25em"><fo:list-item-label
end-indent="label-end()"><fo:block/></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block> "Parameters" -- The Parameters
describe the details of
+ the measurement.
</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
+ </fo:block><fo:block font-weight="bold" font-size="11pt"
keep-with-next="always" space-before="11pt" space-after="3pt"
id="rfc.section.3.1.1"><fo:block
id="subject"/>3.1.1 Subject</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">The "Subject" identifies the measured
entity. For
+ networks, this may represent a path between two hosts or
+ an interface on a network device.</fo:block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt" id="rfc.section.3.1.2"><fo:block
id="eventtype"/>3.1.2 EventType</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">The "EventType" is the canonical name
of the aspect of
+ the subject being measured, or the actual event (i.e.
+ "characteristic") being reported.</fo:block><fo:block
font-weight="bold" font-size="11pt" keep-with-next="always"
space-before="11pt" space-after="3pt" id="rfc.section.3.1.3"><fo:block
id="parameters"/>3.1.3 Parameters</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</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"><fo:block
id="data"/>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"><fo:block
id="datum"/>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
+ measurement data sources, this can be a time-series of
+ timestamp, value pairs. For other measurement types, the
+ result value may be a vector. </fo:block><fo:block
font-weight="bold" font-size="12pt" keep-with-next="always"
space-before="12pt" space-after="6pt" id="rfc.section.3.3"><fo:block
id="containers"/>3.3 Container Elements</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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.</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.4"><fo:block id="xml_namespace"/>4. XML
Namespaces</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em"> 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. </fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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. </fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em"> 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<fo:basic-link
color="#000080" internal-destination="refs.hierarchy">[2]</fo:basic-link>.
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. </fo:block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always" id="rfc.section.5"><fo:block
id="extending"/>5. Extending the Schema</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">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.</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">This needs some
textual description.</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.6"><fo:block
id="versioning"/>6. Versioning</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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.</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em"> To accomplish this, each of the URIs that comprise the
+ namespaces end in a version number. TBD, conforming to recent
+ GFD on namespaces. </fo:block><fo:block font-weight="bold"
font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always" id="rfc.section.7"><fo:block
id="metadata_chaining"/>7. Metadata Chaining</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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. </fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">This means that not all Metadata blocks
will
+ explicitly include an eventType. There must be an eventType
somewhere
+ in the the joined Metadata elements. </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"><fo:block
id="operation_metadata"/>8. Operation Metadata</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em"> 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.
+
+ </fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em"> 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.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em"> 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.
</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"><fo:block id="base_schema"/>9. Base
Schema</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
+
+ <fo:block space-before=".5em" space-after=".5em"
id="rfc.figure.u.1"><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 230 2007-05-07 13:12:03Z swany $
@@ -619,10 +580,10 @@
anyNMWGAttribute |
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.10">10. Time Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
+ </fo:block></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"><fo:block id="time_schema"/>10. 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">#
##############################################################
+ <fo:block space-before=".5em" space-after=".5em"
id="rfc.figure.u.2"><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 230 2007-05-07 13:12:03Z swany $
@@ -703,10 +664,10 @@
element nmtm:end {
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.11">11. Topology Schema</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ </fo:block></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"><fo:block id="topo_schema"/>11. 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">#
##############################################################
+ <fo:block space-before=".5em" space-after=".5em"
id="rfc.figure.u.3"><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.
@@ -846,11 +807,12 @@
) &
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.12">12. 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.12.1">12.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">
+ </fo:block></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"><fo:block
id="examples"/>12. 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.12.1"><fo:block id="ping.rnc"/>12.1 Schema for
ping</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
+ <fo:block space-before=".5em" space-after=".5em"
id="rfc.figure.u.4"><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
@@ -1109,48 +1071,278 @@
)?
}
- </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.12.2">12.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><fo:block font-weight="bold" font-size="12pt"
keep-with-next="always" space-before="12pt" space-after="6pt"
id="rfc.section.12.2"><fo:block id="ping.xml"/>12.2 Instance document for
ping</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
+ <fo:block space-before=".5em" space-after=".5em"
id="rfc.figure.u.5"><fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">
+<?xml version="1.0" encoding="UTF-8"?>
+<nmwg:message type="store"
+ xmlns="http://ggf.org/ns/nmwg/base/2.0/";
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
+ xmlns:ping="http://ggf.org/ns/nmwg/tools/ping/2.0/";
+ xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
+ xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/";
+ xmlns:nmtl4="http://ggf.org/ns/nmwg/topology/l4/3.0/";
+ xmlns:nmtl3="http://ggf.org/ns/nmwg/topology/l3/3.0/";
+ xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";
+ xmlns:average="http://ggf.org/ns/nmwg/ops/average/2.0/";
+ xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/">
+
+ <!-- Metadata using original topology schema -->
+
+ <nmwg:metadata id="pingmeta1">
+ <ping:subject id="pingsub1">
+ <nmwgt:endPointPair>
+ <nmwgt:src type="hostname" value="dreadnought.cis.udel.edu"
port="4543"/>
+ <nmwgt:dst type="hostname" value="alderaan.cse.psu.edu"
port="34343"/>
+ </nmwgt:endPointPair>
+ </ping:subject>
+ <ping:parameters id="pingparam1">
+ <nmwg:parameter name="count">2</nmwg:parameter>
+ <nmwg:parameter name="interval">3</nmwg:parameter>
+ <nmwg:parameter name="deadline">10</nmwg:parameter>
+ </ping:parameters>
+ </nmwg:metadata>
+
+
+ <!-- Metadata(s) using new topology schema -->
+
+ <nmwg:metadata id="pingmeta2">
+ <ping:subject id="pingsub2">
+ <nmtl4:endPointPair>
+ <nmtl4:endPoint role="src" port="4543" protocol="icpm">
+ <nmtl4:address value="dreadnought.cis.udel.edu"
type="hostname"/>
+ </nmtl4:endPoint>
+ <nmtl4:endPoint role="dst" port="34343" protocol="icpm">
+ <nmtl4:address value="alderaan.cse.psu.edu" type="hostname"/>
+ </nmtl4:endPoint>
+ </nmtl4:endPointPair>
+ </ping:subject>
+ <ping:parameters id="pingparam2">
+ <nmwg:parameter name="count">2</nmwg:parameter>
+ <nmwg:parameter name="interval">3</nmwg:parameter>
+ <nmwg:parameter name="deadline">10</nmwg:parameter>
+ </ping:parameters>
+ </nmwg:metadata>
+
+ <nmwg:metadata id="pingmeta3">
+ <ping:subject id="pingsub3">
+ <nmtl4:endPointPair>
+ <nmtl4:endPoint role="src" port="4543" protocol="icpm">
+ <nmtl3:interface id="d1">
+ <nmtl3:ipAddress value="128.4.133.200" type="ipv4"/>
+ <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
+ <nmtl3:ifName>eth0</nmtl3:ifName>
+ <nmtl3:ifDescription>External
Connection</nmtl3:ifDescription>
+ <nmtl3:ifAddress value="128.4.133.200" type="ipv4"/>
+
<nmtl3:ifHostName>dreadnought.cis.udel.edu</nmtl3:ifHostName>
+ <nmtl3:ifIndex>0</nmtl3:ifIndex>
+ <nmtl3:type>1000BaseT Ethernet</nmtl3:type>
+ <nmtl3:capacity>1000000000</nmtl3:capacity>
+ </nmtl3:interface>
+ </nmtl4:endPoint>
+ <nmtl4:endPoint role="dst" port="34343" protocol="icpm">
+ <nmtl3:interface id="a1">
+ <nmtl3:ipAddress value="130.203.16.20" type="ipv4"/>
+ <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
+ <nmtl3:ifName>eth0</nmtl3:ifName>
+ <nmtl3:ifDescription>External
Connection</nmtl3:ifDescription>
+ <nmtl3:ifAddress value="130.203.16.20" type="ipv4"/>
+
<nmtl3:ifHostName>alderaan.cse.psu.edu</nmtl3:ifHostName>
+ <nmtl3:ifIndex>0</nmtl3:ifIndex>
+ <nmtl3:type>1000BaseT Ethernet</nmtl3:type>
+ <nmtl3:capacity>1000000000</nmtl3:capacity>
+ </nmtl3:interface>
+ </nmtl4:endPoint>
+ </nmtl4:endPointPair>
+ </ping:subject>
+ <ping:parameters id="pingparam3">
+ <nmwg:parameter name="count">2</nmwg:parameter>
+ <nmwg:parameter name="interval">3</nmwg:parameter>
+ <nmwg:parameter name="deadline">10</nmwg:parameter>
+ </ping:parameters>
+ </nmwg:metadata>
+
+ <!-- metadata(s) with filter chaining -->
+
+ <nmwg:metadata id="pingmeta4">
+ <ping:subject id="pingsub4">
+ <nmwgt:endPointPair>
+ <nmwgt:src type="hostname" value="dreadnought.cis.udel.edu"
port="4543"/>
+ <nmwgt:dst type="hostname" value="alderaan.cse.psu.edu"
port="34343"/>
+ </nmwgt:endPointPair>
+ </ping:subject>
+ <ping:parameters id="pingparam4">
+ <nmwg:parameter name="count">2</nmwg:parameter>
+ <nmwg:parameter name="interval">3</nmwg:parameter>
+ <nmwg:parameter name="deadline">10</nmwg:parameter>
+ </ping:parameters>
+ </nmwg:metadata>
+
+ <nmwg:metadata id="pingmeta5">
+ <select:subject id="pingsub5" metadataIdRef="pingmeta4" />
+ <select:parameters id="pingparam5">
+ <nmwg:parameter name="timeValue">
+ <nmwg:parameter
name="greaterThan">1107492199</nmwg:parameter>
+ </nmwg:parameter>
+ </select:parameters>
+ </nmwg:metadata>
+
+ <nmwg:metadata id="pingmeta6">
+ <select:subject id="pingsub6" metadataIdRef="pingmeta5" />
+ <select:parameters id="pingparam6">
+ <nmwg:parameter name="timeValue">
+ <nmwg:parameter
name="lessThan">1107492207</nmwg:parameter>
+ </nmwg:parameter>
+ </select:parameters>
+ </nmwg:metadata>
+
+ <nmwg:metadata id="pingmeta7">
+ <average:subject id="pingsub7" metadataIdRef="pingmeta6" />
+ <average:parameters id="pingparam7">
+ <nmwg:parameter name="value" />
+ </average:parameters>
+ </nmwg:metadata>
+
+
+ <!-- Data block, with a time block, with multiple datum blocks -->
+ <nmwg:data id="data1" metadataIdRef="pingmeta1">
+ <nmwg:commonTime type="unix" value="1107492095">
+ <ping:datum seqNum="0" value="19.1" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="1" value="19.2" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block, with multiple datum blocks (other
way to show time) -->
+ <nmwg:data id="data2" metadataIdRef="pingmeta1">
+ <nmwg:commonTime type="unix">
+ <nmtm:value>1107492096</nmtm:value>
+ <ping:datum seqNum="0" value="19.3" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="1" value="19.4" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block (range), with multiple datum blocks
-->
+ <nmwg:data id="data3" metadataIdRef="pingmeta1">
+ <nmwg:commonTime type="range">
+ <nmtm:start type="unix" value="1107492097"/>
+ <nmtm:end type="unix" value="1107492395"/>
+ <ping:datum seqNum="0" value="19.2" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="1" value="17.3" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="3" value="45.4" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="88" value="21.9" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block (durration), with multiple datum
blocks -->
+ <nmwg:data id="data4" metadataIdRef="pingmeta1">
+ <nmwg:commonTime type="durration" duration="300">
+ <nmtm:start type="unix" value="1107492097"/>
+ <ping:datum seqNum="0" value="19.2" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="1" value="17.3" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="3" value="45.4" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ <ping:datum seqNum="88" value="21.9" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" />
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- data with datum blocks, time is inline (two ways to represent
time) -->
+ <nmwg:data id="data5" metadataIdRef="pingmeta1">
+ <ping:datum seqNum="0" value="14.3" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" timeType="unix" timeValue="1107492199"
/>
+ <ping:datum seqNum="1" value="17.4" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes" timeType="unix" timeValue="1107492201"
/>
+ </nmwg:data>
+
+ <!-- data with datum blocks, time is a sub element -->
+ <nmwg:data id="data6" metadataIdRef="pingmeta1">
+ <ping:datum seqNum="0" value="19.6" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="unix" value="1107493095" />
+ </ping:datum>
+ <ping:datum seqNum="0" value="18.5" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="unix" value="1107493095" />
+ </ping:datum>
+ </nmwg:data>
+
+ <!-- data with datum blocks, time is a sub element -->
+ <nmwg:data id="data7" metadataIdRef="pingmeta1">
+ <ping:datum seqNum="0" value="19.6" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="unix">
+ <nmtm:value>1107493095</nmtm:value>
+ </nmtm:time>
+ </ping:datum>
+ <ping:datum seqNum="0" value="18.5" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="unix">
+ <nmtm:value>1107493095</nmtm:value>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+ <!-- data with datum blocks, time is a sub element (other way to show
time) -->
+ <nmwg:data id="data8" metadataIdRef="pingmeta1">
+ <ping:datum seqNum="0" value="19.6" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="range">
+ <nmtm:start type="unix" value="1107492095"/>
+ <nmtm:end type="unix" value="1107492395"/>
+ </nmtm:time>
+ </ping:datum>
+ <ping:datum seqNum="0" value="18.5" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="range">
+ <nmtm:start type="unix" value="1107492095"/>
+ <nmtm:end type="unix" value="1107492395"/>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+ <nmwg:data id="data9" metadataIdRef="pingmeta1">
+ <ping:datum seqNum="0" value="19.6" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="durration" duration="300">
+ <nmtm:start type="unix" value="1107492095"/>
+ </nmtm:time>
+ </ping:datum>
+ <ping:datum seqNum="0" value="18.5" valueUnits="ms" ttl="241"
numBytes="64" numBytesUnits="bytes">
+ <nmtm:time type="durration" duration="300">
+ <nmtm:start type="unix" value="1107492095"/>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+ <!-- result datum elements -->
+ <nmwg:data id="data10" metadataIdRef="pingmeta1">
+ <nmwgr:datum type="error.ping.mp">From lager (192.168.0.200)
icmp_seq=1 Destination Host Unreachable</nmwgr:datum>
+ </nmwg:data>
+
+</nmwg:message>
- </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.13">13. 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
- 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. </fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">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. </fo:block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always"
id="rfc.section.14">14. Appendices</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt"
id="rfc.section.14.1">14.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">15
- 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
- Development of Networks and Communities (Tridentcom
-
2006).</fo:block></fo:list-item-body></fo:list-item></fo:list-block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always" id="rfc.authors">Author's
Address</fo:block><fo:block space-before="1em"><fo:wrapper
font-weight="bold">D. Martin Swany</fo:wrapper><fo:wrapper>
(Editor)</fo:wrapper></fo:block><fo:block>
- University of Delaware
- Department of Computer and Information Sciences
- Newark, DE 19716
- </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block
id="rfc.copyright"/>Full Copyright Statement</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
- Copyright © The Open Grid Forum (2007). All Rights Reserved.
+ </fo:block></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.13">13. 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 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.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">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. </fo:block><fo:block font-weight="bold"
font-size="14pt" keep-with-next="always" space-after="7pt"
page-break-before="always"
id="rfc.section.14">14. Appendices</fo:block><fo:block font-weight="bold"
font-size="12pt" keep-with-next="always" space-before="12pt"
space-after="6pt"
id="rfc.section.14.1">14.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, Jason Zurawski and 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">15
+ 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="refs.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 Development of Networks and Communities (Tridentcom 2006),
2006.</fo:block></fo:list-item-body></fo:list-item><fo:list-item
space-after=".5em"><fo:list-item-label end-indent="label-end()"><fo:block
id="refs.hierarchy">[2]</fo:block></fo:list-item-label><fo:list-item-body
start-indent="body-start()"><fo:block>Lowekamp, B., Tierney, B., Cottrell,
L., Hughes-Jones, R., Kielmann, T., and M. Swany, "Enabling Network
Measurement Portability Through a
+ Hierarchy of Characteristics", 4th International Workshop on
Grid Computing (Grid2003),
November 2003.</fo:block></fo:list-item-body></fo:list-item></fo:list-block><fo:block
font-weight="bold" font-size="14pt" keep-with-next="always"
space-after="7pt" page-break-before="always" id="rfc.authors">Author's
Address</fo:block><fo:block space-before="1em"><fo:wrapper
font-weight="bold">D. Martin Swany</fo:wrapper><fo:wrapper>
(editor)</fo:wrapper></fo:block><fo:block> University of Delaware Department
+ of Computer and Information Sciences Newark, DE 19716
+ </fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-before="14pt" space-after="7pt"><fo:block
id="rfc.copyright"/>Full Copyright Statement</fo:block><fo:block
space-before=".5em" space-after=".5em" start-indent="2em">
+ Copyright © The Open Grid Forum (2008). All Rights Reserved.
</fo:block><fo:block space-before=".5em" space-after=".5em"
start-indent="2em">
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2008-01-19 23:34:21
UTC (rev 331)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2008-02-27 17:10:03
UTC (rev 332)
@@ -3,9 +3,8 @@
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<title>
- An Extensible Schema for Network Measurement and Performance Data
- </title>
+<title> An Extensible Schema for Network Measurement and
+ Performance Data </title>
<style type="text/css" title="Xml2Rfc (sans serif)">
a {
text-decoration: none;
@@ -268,12 +267,11 @@
content: "RFC ";
}
@top-right {
- content: "September 2007";
+ content: "February 2008";
}
@top-center {
- content: "
- An Extensible Schema for Network Measurement and Performance Data
- ";
+ content: " An Extensible Schema for Network Measurement and
+ Performance Data ";
}
@bottom-left {
content: "Swany";
@@ -318,7 +316,7 @@
<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-09">
+<meta name="DC.Date.Issued" scheme="ISO8601" content="2008-02">
</head>
<body>
<table summary="header information" class="header" border="0"
cellpadding="1" cellspacing="1">
@@ -333,7 +331,7 @@
</tr>
<tr>
<td class="front left">Intended status: Informational</td>
-<td class="front right">September 2007</td>
+<td class="front right">February 2008</td>
</tr>
</table>
<p class="title">An Extensible Schema for Network Measurement and
Performance Data</p>
@@ -344,82 +342,106 @@
<h1>
<a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
-<p>Copyright � The Open Grid Forum (2007). All Rights Reserved.</p>
+<p>Copyright � The Open Grid Forum (2008). 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>
+<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 monitoring 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>
+<a href="#rfc.section.1.1">1.1</a> <a id="goals" href="#goals">Goals</a>
+</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>
+<a href="#rfc.section.2">2.</a> <a id="design_philosophy"
href="#design_philosophy">Design Philosophy</a>
+</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 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>
+<a href="#rfc.section.3">3.</a> <a id="basic_elements"
href="#basic_elements">Basic Elements</a>
+</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 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
resolve the local ID and point to remote Metadata.)</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 with 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.)</p>
<h2 id="rfc.section.3.1">
-<a href="#rfc.section.3.1">3.1</a> Metadata</h2>
+<a href="#rfc.section.3.1">3.1</a> <a id="metadata"
href="#metadata">Metadata</a>
+</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>
+<p id="rfc.section.3.1.p.2">
+</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>
+<a href="#rfc.section.3.1.1">3.1.1</a> <a id="subject"
href="#subject">Subject</a>
+</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>
+<a href="#rfc.section.3.1.2">3.1.2</a> <a id="eventtype"
href="#eventtype">EventType</a>
+</h3>
+<p id="rfc.section.3.1.2.p.1">The "EventType" 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>
+<a href="#rfc.section.3.1.3">3.1.3</a> <a id="parameters"
href="#parameters">Parameters</a>
+</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>
+<a href="#rfc.section.3.2">3.2</a> <a id="data" href="#data">Data</a>
+</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>
+<a href="#rfc.section.3.2.1">3.2.1</a> <a id="datum"
href="#datum">Datum</a>
+</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>
+<a href="#rfc.section.3.3">3.3</a> <a id="containers"
href="#containers">Container Elements</a>
+</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.</p>
<hr class="noprint">
<h1 id="rfc.section.4" class="np">
-<a href="#rfc.section.4">4.</a> XML Namespaces</h1>
+<a href="#rfc.section.4">4.</a> <a id="xml_namespace"
href="#xml_namespace">XML Namespaces</a>
+</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 modification.</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. 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.</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<a href="#refs.hierarchy">
+<cite title="Enabling Network Measurement Portability Through a Hierarchy of
Characteristics">[2]</cite>
+</a>. 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.</p>
<hr class="noprint">
<h1 id="rfc.section.5" class="np">
-<a href="#rfc.section.5">5.</a> Extending the Schema</h1>
+<a href="#rfc.section.5">5.</a> <a id="extending"
href="#extending">Extending the Schema</a>
+</h1>
<p id="rfc.section.5.p.1">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.</p>
<p id="rfc.section.5.p.2">This needs some textual description.</p>
<hr class="noprint">
<h1 id="rfc.section.6" class="np">
-<a href="#rfc.section.6">6.</a> Versioning</h1>
+<a href="#rfc.section.6">6.</a> <a id="versioning"
href="#versioning">Versioning</a>
+</h1>
<p id="rfc.section.6.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.6.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.7" class="np">
-<a href="#rfc.section.7">7.</a> Metadata Chaining</h1>
-<p id="rfc.section.7.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 type.</p>
+<a href="#rfc.section.7">7.</a> <a id="metadata_chaining"
href="#metadata_chaining">Metadata Chaining</a>
+</h1>
+<p id="rfc.section.7.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.</p>
+<p id="rfc.section.7.p.2">This means that not all Metadata blocks will
explicitly include an eventType. There must be an eventType somewhere in the
the joined Metadata elements.</p>
<hr class="noprint">
<h1 id="rfc.section.8" class="np">
-<a href="#rfc.section.8">8.</a> Operation Metadata</h1>
+<a href="#rfc.section.8">8.</a> <a id="operation_metadata"
href="#operation_metadata">Operation Metadata</a>
+</h1>
<p id="rfc.section.8.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.8.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.8.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.9" class="np">
-<a href="#rfc.section.9">9.</a> Base Schema</h1>
+<a href="#rfc.section.9">9.</a> <a id="base_schema"
href="#base_schema">Base Schema</a>
+</h1>
<p id="rfc.section.9.p.1">
+</p>
+<div id="rfc.figure.u.1">
+</div>
<pre>
<font color=red>#
##############################################################</font>
<font color=red># </font>
@@ -863,11 +885,14 @@
text
)*
</pre>
-</p>
<hr class="noprint">
<h1 id="rfc.section.10" class="np">
-<a href="#rfc.section.10">10.</a> Time Schema</h1>
+<a href="#rfc.section.10">10.</a> <a id="time_schema"
href="#time_schema">Time Schema</a>
+</h1>
<p id="rfc.section.10.p.1">
+</p>
+<div id="rfc.figure.u.2">
+</div>
<pre>
<font color=red>#
##############################################################</font>
<font color=red># </font>
@@ -951,11 +976,14 @@
TimeContent
}
</pre>
-</p>
<hr class="noprint">
<h1 id="rfc.section.11" class="np">
-<a href="#rfc.section.11">11.</a> Topology Schema</h1>
+<a href="#rfc.section.11">11.</a> <a id="topo_schema"
href="#topo_schema">Topology Schema</a>
+</h1>
<p id="rfc.section.11.p.1">
+</p>
+<div id="rfc.figure.u.3">
+</div>
<pre>
<font color=red>#
##############################################################</font>
<font color=red># </font>
@@ -1098,16 +1126,20 @@
attribute type { xsd:string }
</pre>
-</p>
<hr class="noprint">
<h1 id="rfc.section.12" class="np">
-<a href="#rfc.section.12">12.</a> Examples</h1>
+<a href="#rfc.section.12">12.</a> <a id="examples"
href="#examples">Examples</a>
+</h1>
<p id="rfc.section.12.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.12.1">
-<a href="#rfc.section.12.1">12.1</a> Schema for ping</h2>
+<a href="#rfc.section.12.1">12.1</a> <a id="ping.rnc"
href="#ping.rnc">Schema for ping</a>
+</h2>
<p id="rfc.section.12.1.p.1">
+</p>
+<div id="rfc.figure.u.4">
+</div>
<pre>
-
+
<font color=red>#
##############################################################</font>
<font color=red># </font>
<font color=red># File: ping.rnc - Specialized schema for the ping
</font>
@@ -1366,14 +1398,253 @@
)?
}
- </pre>
-</p>
+ </pre>
<h2 id="rfc.section.12.2">
-<a href="#rfc.section.12.2">12.2</a> Instance document for ping</h2>
+<a href="#rfc.section.12.2">12.2</a> <a id="ping.xml"
href="#ping.xml">Instance document for ping</a>
+</h2>
<p id="rfc.section.12.2.p.1">
-<pre>
- </pre>
</p>
+<div id="rfc.figure.u.5">
+</div>
+<pre>
+
+<font color=orange><?xml version="1.0" encoding="UTF-8"?></font>
+<font color=orange><nmwg:message type="store" </font>
+<font color=orange>
xmlns="http://ggf.org/ns/nmwg/base/2.0/";</font>
+<font color=orange>
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; </font>
+<font color=orange>
xmlns:ping="http://ggf.org/ns/nmwg/tools/ping/2.0/"; </font>
+<font color=orange>
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/"; </font>
+<font color=orange>
xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/";</font>
+<font color=orange>
xmlns:nmtl4="http://ggf.org/ns/nmwg/topology/l4/3.0/";</font>
+<font color=orange>
xmlns:nmtl3="http://ggf.org/ns/nmwg/topology/l3/3.0/";</font>
+<font color=orange>
xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";</font>
+<font color=orange>
xmlns:average="http://ggf.org/ns/nmwg/ops/average/2.0/";</font>
+<font color=orange>
xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/"></font>
+
+ <!-- Metadata using original topology schema -->
+
+<font color=orange> <nmwg:metadata id="pingmeta1"></font>
+<font color=orange> <ping:subject id="pingsub1"></font>
+ <nmwgt:endPointPair>
+<font color=orange> <nmwgt:src type="hostname"
value="dreadnought.cis.udel.edu" port="4543"/></font>
+<font color=orange> <nmwgt:dst type="hostname"
value="alderaan.cse.psu.edu" port="34343"/></font>
+ </nmwgt:endPointPair>
+ </ping:subject>
+<font color=orange> <ping:parameters id="pingparam1"></font>
+<font color=orange> <nmwg:parameter
name="count">2</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="interval">3</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="deadline">10</nmwg:parameter> </font>
+ </ping:parameters>
+ </nmwg:metadata>
+
+
+ <!-- Metadata(s) using new topology schema -->
+
+<font color=orange> <nmwg:metadata id="pingmeta2"></font>
+<font color=orange> <ping:subject id="pingsub2"></font>
+ <nmtl4:endPointPair>
+<font color=orange> <nmtl4:endPoint role="src" port="4543"
protocol="icpm"></font>
+<font color=orange> <nmtl4:address
value="dreadnought.cis.udel.edu" type="hostname"/></font>
+ </nmtl4:endPoint>
+<font color=orange> <nmtl4:endPoint role="dst" port="34343"
protocol="icpm"></font>
+<font color=orange> <nmtl4:address value="alderaan.cse.psu.edu"
type="hostname"/></font>
+ </nmtl4:endPoint>
+ </nmtl4:endPointPair>
+ </ping:subject>
+<font color=orange> <ping:parameters id="pingparam2"></font>
+<font color=orange> <nmwg:parameter
name="count">2</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="interval">3</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="deadline">10</nmwg:parameter> </font>
+ </ping:parameters>
+ </nmwg:metadata>
+
+<font color=orange> <nmwg:metadata id="pingmeta3"></font>
+<font color=orange> <ping:subject id="pingsub3"></font>
+ <nmtl4:endPointPair>
+<font color=orange> <nmtl4:endPoint role="src" port="4543"
protocol="icpm"></font>
+<font color=orange> <nmtl3:interface id="d1"></font>
+<font color=orange> <nmtl3:ipAddress value="128.4.133.200"
type="ipv4"/></font>
+ <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
+ <nmtl3:ifName>eth0</nmtl3:ifName>
+ <nmtl3:ifDescription>External
Connection</nmtl3:ifDescription>
+<font color=orange> <nmtl3:ifAddress value="128.4.133.200"
type="ipv4"/></font>
+
<nmtl3:ifHostName>dreadnought.cis.udel.edu</nmtl3:ifHostName>
+ <nmtl3:ifIndex>0</nmtl3:ifIndex>
+ <nmtl3:type>1000BaseT Ethernet</nmtl3:type>
+ <nmtl3:capacity>1000000000</nmtl3:capacity>
+ </nmtl3:interface>
+ </nmtl4:endPoint>
+<font color=orange> <nmtl4:endPoint role="dst" port="34343"
protocol="icpm"></font>
+<font color=orange> <nmtl3:interface id="a1"></font>
+<font color=orange> <nmtl3:ipAddress value="130.203.16.20"
type="ipv4"/></font>
+ <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
+ <nmtl3:ifName>eth0</nmtl3:ifName>
+ <nmtl3:ifDescription>External
Connection</nmtl3:ifDescription>
+<font color=orange> <nmtl3:ifAddress value="130.203.16.20"
type="ipv4"/></font>
+
<nmtl3:ifHostName>alderaan.cse.psu.edu</nmtl3:ifHostName>
+ <nmtl3:ifIndex>0</nmtl3:ifIndex>
+ <nmtl3:type>1000BaseT Ethernet</nmtl3:type>
+ <nmtl3:capacity>1000000000</nmtl3:capacity>
+ </nmtl3:interface>
+ </nmtl4:endPoint>
+ </nmtl4:endPointPair>
+ </ping:subject>
+<font color=orange> <ping:parameters id="pingparam3"></font>
+<font color=orange> <nmwg:parameter
name="count">2</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="interval">3</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="deadline">10</nmwg:parameter> </font>
+ </ping:parameters>
+ </nmwg:metadata>
+
+ <!-- metadata(s) with filter chaining -->
+
+<font color=orange> <nmwg:metadata id="pingmeta4"></font>
+<font color=orange> <ping:subject id="pingsub4"></font>
+ <nmwgt:endPointPair>
+<font color=orange> <nmwgt:src type="hostname"
value="dreadnought.cis.udel.edu" port="4543"/></font>
+<font color=orange> <nmwgt:dst type="hostname"
value="alderaan.cse.psu.edu" port="34343"/></font>
+ </nmwgt:endPointPair>
+ </ping:subject>
+<font color=orange> <ping:parameters id="pingparam4"></font>
+<font color=orange> <nmwg:parameter
name="count">2</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="interval">3</nmwg:parameter></font>
+<font color=orange> <nmwg:parameter
name="deadline">10</nmwg:parameter> </font>
+ </ping:parameters>
+ </nmwg:metadata>
+
+<font color=orange> <nmwg:metadata id="pingmeta5"> </font>
+<font color=orange> <select:subject id="pingsub5"
metadataIdRef="pingmeta4" /> </font>
+<font color=orange> <select:parameters id="pingparam5"></font>
+<font color=orange> <nmwg:parameter name="timeValue"></font>
+<font color=orange> <nmwg:parameter
name="greaterThan">1107492199</nmwg:parameter> </font>
+ </nmwg:parameter>
+ </select:parameters>
+ </nmwg:metadata>
+
+<font color=orange> <nmwg:metadata id="pingmeta6"> </font>
+<font color=orange> <select:subject id="pingsub6"
metadataIdRef="pingmeta5" /> </font>
+<font color=orange> <select:parameters id="pingparam6"></font>
+<font color=orange> <nmwg:parameter name="timeValue"></font>
+<font color=orange> <nmwg:parameter
name="lessThan">1107492207</nmwg:parameter> </font>
+ </nmwg:parameter>
+ </select:parameters>
+ </nmwg:metadata>
+
+<font color=orange> <nmwg:metadata id="pingmeta7"> </font>
+<font color=orange> <average:subject id="pingsub7"
metadataIdRef="pingmeta6" /> </font>
+<font color=orange> <average:parameters id="pingparam7"></font>
+<font color=orange> <nmwg:parameter name="value" /></font>
+ </average:parameters>
+ </nmwg:metadata>
+
+
+ <!-- Data block, with a time block, with multiple datum blocks -->
+<font color=orange> <nmwg:data id="data1"
metadataIdRef="pingmeta1"></font>
+<font color=orange> <nmwg:commonTime type="unix"
value="1107492095"></font>
+<font color=orange> <ping:datum seqNum="0" value="19.1"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /> </font>
+<font color=orange> <ping:datum seqNum="1" value="19.2"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block, with multiple datum blocks (other
way to show time) -->
+<font color=orange> <nmwg:data id="data2" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <nmwg:commonTime type="unix"></font>
+ <nmtm:value>1107492096</nmtm:value>
+<font color=orange> <ping:datum seqNum="0" value="19.3"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /> </font>
+<font color=orange> <ping:datum seqNum="1" value="19.4"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block (range), with multiple datum blocks
-->
+<font color=orange> <nmwg:data id="data3" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <nmwg:commonTime type="range"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492097"/></font>
+<font color=orange> <nmtm:end type="unix"
value="1107492395"/></font>
+<font color=orange> <ping:datum seqNum="0" value="19.2"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /> </font>
+<font color=orange> <ping:datum seqNum="1" value="17.3"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+<font color=orange> <ping:datum seqNum="3" value="45.4"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+<font color=orange> <ping:datum seqNum="88" value="21.9"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" />
</font>
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- Data block, with a time block (durration), with multiple datum
blocks -->
+<font color=orange> <nmwg:data id="data4" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <nmwg:commonTime type="durration"
duration="300"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492097"/></font>
+<font color=orange> <ping:datum seqNum="0" value="19.2"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /> </font>
+<font color=orange> <ping:datum seqNum="1" value="17.3"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+<font color=orange> <ping:datum seqNum="3" value="45.4"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+<font color=orange> <ping:datum seqNum="88" value="21.9"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" /></font>
+ </nmwg:commonTime>
+ </nmwg:data>
+
+ <!-- data with datum blocks, time is inline (two ways to represent
time) -->
+<font color=orange> <nmwg:data id="data5" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <ping:datum seqNum="0" value="14.3"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" timeType="unix"
timeValue="1107492199" /> </font>
+<font color=orange> <ping:datum seqNum="1" value="17.4"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes" timeType="unix"
timeValue="1107492201" /></font>
+ </nmwg:data>
+
+ <font color=green><!--</font> <font color=blue>data</font> with datum
blocks, time is a sub element -->
+<font color=orange> <nmwg:data id="data6" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <ping:datum seqNum="0" value="19.6"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="unix" value="1107493095"
/></font>
+ </ping:datum>
+<font color=orange> <ping:datum seqNum="0" value="18.5"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="unix" value="1107493095"
/></font>
+ </ping:datum>
+ </nmwg:data>
+
+ <font color=green><!--</font> <font color=blue>data</font> with datum
blocks, time is a sub element -->
+<font color=orange> <nmwg:data id="data7" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <ping:datum seqNum="0" value="19.6"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="unix"></font>
+ <nmtm:value>1107493095</nmtm:value>
+ </nmtm:time>
+ </ping:datum>
+<font color=orange> <ping:datum seqNum="0" value="18.5"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="unix"></font>
+ <nmtm:value>1107493095</nmtm:value>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+ <font color=green><!--</font> <font color=blue>data</font> with datum
blocks, time is a sub element (other way to show time) -->
+<font color=orange> <nmwg:data id="data8"
metadataIdRef="pingmeta1"></font>
+<font color=orange> <ping:datum seqNum="0" value="19.6"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="range"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492095"/></font>
+<font color=orange> <nmtm:end type="unix"
value="1107492395"/></font>
+ </nmtm:time>
+ </ping:datum>
+<font color=orange> <ping:datum seqNum="0" value="18.5"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="range"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492095"/></font>
+<font color=orange> <nmtm:end type="unix"
value="1107492395"/></font>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+<font color=orange> <nmwg:data id="data9"
metadataIdRef="pingmeta1"></font>
+<font color=orange> <ping:datum seqNum="0" value="19.6"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="durration"
duration="300"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492095"/></font>
+ </nmtm:time>
+ </ping:datum>
+<font color=orange> <ping:datum seqNum="0" value="18.5"
valueUnits="ms" ttl="241" numBytes="64" numBytesUnits="bytes"></font>
+<font color=orange> <nmtm:time type="durration"
duration="300"></font>
+<font color=orange> <nmtm:start type="unix"
value="1107492095"/></font>
+ </nmtm:time>
+ </ping:datum>
+ </nmwg:data>
+
+ <!-- result datum elements -->
+<font color=orange> <nmwg:data id="data10" metadataIdRef="pingmeta1">
</font>
+<font color=orange> <nmwgr:datum type="error.ping.mp">From lager
(192.168.0.200) icmp_seq=1 Destination Host
Unreachable</nmwgr:datum></font>
+ </nmwg:data>
+
+</nmwg:message>
+
+ </pre>
<hr class="noprint">
<h1 id="rfc.section.13" class="np">
<a href="#rfc.section.13">13.</a> Security Concerns</h1>
@@ -1384,42 +1655,44 @@
<a href="#rfc.section.14">14.</a> Appendices</h1>
<h2 id="rfc.section.14.1">
<a href="#rfc.section.14.1">14.1</a> Acknowledgements</h2>
-<p id="rfc.section.14.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>
+<p id="rfc.section.14.1.p.1">We gratefully acknowledge the contributions of:
Jeff Boote, Eric Boyd, Mark Leese, Dan Gunter, Richard Hughes-Jones, Jason
Zurawski and the other members of the Network Measurements Working Group.</p>
<h1 class="np" id="rfc.references">
<a href="#rfc.section.15">15.</a> References</h1>
<table summary="References" border="0" cellpadding="2">
<tr>
<td class="topnowrap">
-<b id="tridentcom">[1]</b>
+<b id="refs.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
- 2006).</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 2006), 2006.</td>
</tr>
+<tr>
+<td class="topnowrap">
+<b id="refs.hierarchy">[2]</b>
+</td>
+<td class="top">Lowekamp, B., Tierney, B., Cottrell, L., Hughes-Jones, R.,
Kielmann, T., and M. Swany, “Enabling Network Measurement Portability
Through a
+ Hierarchy of Characteristics”, 4th International Workshop
on Grid Computing (Grid2003), November 2003.</td>
+</tr>
</table>
<hr class="noprint">
<h1 id="rfc.authors" class="np">Author's Address</h1>
<address class="vcard">
<span class="vcardline">
<span class="fn">D. Martin Swany</span>
- (Editor)
+ (editor)
<span class="n hidden">
<span class="family-name">Swany</span>
<span class="given-name">D. Martin</span>
</span>
</span>
-<span class="org vcardline">
- University of Delaware
- Department of Computer and Information Sciences
- Newark, DE 19716
- </span>
+<span class="org vcardline"> University of Delaware Department
+ of Computer and Information Sciences Newark, DE 19716
+ </span>
</address>
<h1>
<a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a>
</h1>
-<p>Copyright � The Open Grid Forum (2007). All Rights Reserved.</p>
+<p>Copyright � The Open Grid Forum (2008). All Rights Reserved.</p>
<p>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.</p>
<p>The limited permissions granted above are perpetual and will not be
revoked by the OGF or its successors or assignees.</p>
<p>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.</p>
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 2008-01-19 23:34:21
UTC (rev 331)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.xml 2008-02-27 17:10:03
UTC (rev 332)
@@ -3,430 +3,431 @@
<!--<rfc category="info" ipr="full3978" docName="nm-schema-base.txt">-->
<rfc>
-<?xml-stylesheet type='text/xsl'
+ <?xml-stylesheet type='text/xsl'
href='rfc2629.xslt' ?>
-<?rfc toc="yes" ?>
-<?rfc symrefs="yes" ?>
-<?rfc sortrefs="yes"?>
-<?rfc iprnotified="no" ?>
-<?rfc private="1" ?>
-<?rfc strict="no" ?>
-<!-- <?rfc-ext support-rfc2731="no"?>
+ <?rfc toc="yes" ?>
+ <?rfc symrefs="yes" ?>
+ <?rfc sortrefs="yes"?>
+ <?rfc iprnotified="no" ?>
+ <?rfc private="1" ?>
+ <?rfc strict="no" ?>
+ <?rfc page-break-before="avoid" ?>
+ <!-- <?rfc-ext support-rfc2731="no"?>
<?rfc-ext authors-section="no"?> -->
-<front>
- <title>
- An Extensible Schema for Network Measurement and Performance Data
- </title>
- <author initials='M' surname='Swany'
- fullname='D. Martin Swany'
- role='Editor'>
- <organization abbrev='UDel'>
- University of Delaware
- Department of Computer and Information Sciences
- Newark, DE 19716
- </organization>
- </author>
- <date month="September" year="2007"/>
-</front>
+ <front>
+ <title> An Extensible Schema for Network Measurement and
+ Performance Data </title>
+ <author initials="M" surname="Swany" fullname="D. Martin Swany"
+ role="editor">
+ <organization abbrev="UDel"> University of Delaware Department
+ of Computer and Information Sciences Newark, DE 19716
+ </organization>
+ </author>
+ <date month="February" year="2008"/>
+ </front>
-<middle>
- <section anchor="intro" title="Introduction">
+ <middle>
+ <section anchor="intro" title="Introduction">
- <t>
- 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.
- </t>
+ <t>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.</t>
- <t>
- 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.
- </t>
+ <t>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 monitoring 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. </t>
- <t>
- 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.
- </t>
+ <t> 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.</t>
- <section id="goals" title="Goals">
- <t>
- 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.
- </t>
- </section>
+ <section anchor="goals" title="Goals">
+ <t> 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. </t>
+ </section>
- </section>
-
- <section id="design_philosophy" title="Design Philosophy">
+ </section>
- <t>
- 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.
- </t>
-
+ <section anchor="design_philosophy" title="Design Philosophy">
- </section>
+ <t> 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. </t>
- <section id="basic_elements" title="Basic Elements">
- <t>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.
- </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>
- The Metadata must describe the Data unambiguously. To
- accomplish this, the Metadata must include three key
- things:
- </t>
+ </section>
- <list>
+ <section anchor="basic_elements" title="Basic Elements">
+ <t>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. </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 with 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 anchor="metadata" title="Metadata">
+ <t> The Metadata must describe the Data unambiguously. To
+ accomplish this, the Metadata must include three key things: </t>
<t>
- "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.
- </t>
- <t>
- "EventType" -- The EventType identifies exactly what sort
- of measurement Event occurred.
+ <list>
+ <t> "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. </t>
+ <t> "EventType" -- The EventType identifies exactly what
+ sort of measurement Event occurred. </t>
+ <t> "Parameters" -- The Parameters describe the details of
+ the measurement. </t>
+ </list>
</t>
- <t>
- "Parameters" -- The Parameters describe the details of
- the measurement.
- </t>
- </list>
-
- <section id="subject" title="Subject">
- <t>The "Subject" identifies the measured entity. For networks,
- this may represent a path between two hosts or an interface
- on a network device.</t>
+ <section anchor="subject" title="Subject">
+ <t>The "Subject" identifies the measured entity. For
+ networks, this may represent a path between two hosts or
+ an interface on a network device.</t>
+ </section>
+
+ <section anchor="eventtype" title="EventType">
+ <t>The "EventType" is the canonical name of the aspect of
+ the subject being measured, or the actual event (i.e.
+ "characteristic") being reported.</t>
+ </section>
+
+ <section anchor="parameters" title="Parameters">
+ <t>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.</t>
+ </section>
+
</section>
-
- <section id="eventtype" title="Event Type">
- <t>The "Event Type" is the canonical name of the aspect of the
- subject being measured, or the actual event
- (i.e. "characteristic") being reported.</t>
+
+ <section anchor="data" title="Data">
+ <t> 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>
+
+
+ <section anchor="datum" title="Datum">
+ <t> 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. </t>
+ </section>
</section>
- <section id="parameters" title="Parameters">
- <t>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.</t>
+ <section anchor="containers" title="Container Elements">
+ <t> 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.</t>
</section>
-
</section>
-
- <section id="data" title="Data">
- <t>
- 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>
-
- <section id="datum" title="Datum">
- <t>
- 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.
- </t>
- </section>
- </section>
+ <section anchor="xml_namespace" title="XML Namespaces">
- <section id="containers" title="Container Elements">
- <t>
- 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.
- </t>
- </section>
- </section>
+ <t> 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. </t>
- <section id="xml_namespace" title="XML Namespaces">
+ <t> 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. </t>
- <t>
- 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.
- </t>
+ <t> 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<xref
+ target="refs.hierarchy"/>. 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. </t>
- <t>
- 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.
- </t>
+ </section>
- <t>
- 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.
- </t>
+ <section anchor="extending" title="Extending the Schema">
+ <t>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.</t>
- </section>
+ <t>This needs some textual description.</t>
+ </section>
- <section id="extending" title="Extending the Schema">
- <t>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.</t>
+ <section anchor="versioning" title="Versioning">
+ <t>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.</t>
- <t>This needs some textual description.</t>
- </section>
+ <t> To accomplish this, each of the URIs that comprise the
+ namespaces end in a version number. TBD, conforming to recent
+ GFD on namespaces. </t>
+ </section>
- <section id="versioning" title="Versioning">
- <t>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.</t>
+ <section anchor="metadata_chaining" title="Metadata Chaining">
- <t>
- To accomplish this, each of the URIs that comprise the
- namespaces end in a version number. TBD, conforming to recent
- GFD on namespaces.
- </t>
- </section>
+ <t> 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. </t>
+
+
+ <t>This means that not all Metadata blocks will
+ explicitly include an eventType. There must be an eventType
somewhere
+ in the the joined Metadata elements. </t>
+ </section>
- <section id="metadata_chaining" title="Metadata Chaining">
+ <section anchor="operation_metadata" title="Operation Metadata">
+ <t> 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.
+ <!-- give example of nfdump or rrdtool ? -->
+ </t>
- <t>
- 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.
- </t>
- </section>
+ <t> 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. </t>
- <section id="operation_metadata" title="Operation Metadata">
- <t>
- 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.
- <!-- give example of nfdump or rrdtool ? -->
- </t>
+ <t> 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. </t>
+ </section>
- <t>
- 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.
- </t>
+ <section anchor="base_schema" title="Base Schema">
+ <t>
- <t>
- 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.
- </t>
- </section>
-
- <section id="base_schema" title="Base Schema">
- <t>
- <artwork><![CDATA[
+ <figure>
+ <artwork><![CDATA[
<inline file="schema/nmbase.rnc"/>
]]></artwork>
- </t>
- </section>
+ </figure>
+ </t>
+ </section>
- <section id="time_schema" title="Time Schema">
- <t>
+ <section anchor="time_schema" title="Time Schema">
+ <t>
- <artwork><![CDATA[
+ <figure>
+ <artwork><![CDATA[
<inline file="schema/nmtime.rnc"/>
]]></artwork>
- </t>
- </section>
+ </figure>
+ </t>
+ </section>
- <section id="topo_schema" title="Topology Schema">
- <t>
+ <section anchor="topo_schema" title="Topology Schema">
+ <t>
- <artwork><![CDATA[
+ <figure>
+ <artwork><![CDATA[
<inline file="schema/nmtopo.rnc"/>
]]></artwork>
- </t>
- </section>
+ </figure>
+ </t>
+ </section>
- <section id="examples" title="Examples">
+ <section anchor="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>
+ <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[
+
+ <section anchor="ping.rnc" title="Schema for ping">
+ <t>
+ <figure>
+ <artwork>
+ <![CDATA[
<inline file="schema/ping.rnc"/>
]]>
- </artwork>
- </t>
- </section>
+ </artwork>
+ </figure>
+ </t>
+ </section>
- <section id="ping.xml" title="Instance document for ping">
- <t>
- <artwork>
- <![CDATA[
- <inline file="example-instances/ping.xml"/>
+ <section anchor="ping.xml" title="Instance document for ping">
+ <t>
+ <figure>
+ <artwork>
+ <![CDATA[
+ <inline file="example_instances/ping.xml"/>
]]>
- </artwork>
- </t>
- </section>
+ </artwork>
+ </figure>
+ </t>
+ </section>
- </section>
+ </section>
- <section title="Security Concerns">
-
- <t>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. </t>
-
- <t>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. </t>
+ <section title="Security Concerns">
+ <t>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. </t>
- </section>
+ <t>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. </t>
- <section title="Appendices">
- <section title="Acknowledgements">
- <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>
-
-</middle>
-<back>
- <references>
- <reference anchor="tridentcom">
- <front>
- <title>A Scalable Framework for Representation and Exchange of
- Network Measurements</title>
- <author initials="J." surname="Zurawski" fullname="Jason
Zurawski">
-
<email></email>
- </author>
- <author initials="M." surname="Swany">
- </author>
- <author initials="D." surname="Gunter">
- </author>
- </front>
- <seriesInfo>In Proceedings of 2nd International IEEE/Create-Net
- Conference on Testbeds and Research Infrastructures for the
- Development of Networks and Communities (Tridentcom
- 2006)</seriesInfo>
- <year>2006</year>
- </reference>
+ </section>
- <!--
-B. Lowekamp, B. Tierney, Les Cottrell, R. Hughes-Jones, T. Kielmann, M.
Swany, Enabling Network Measurement Portability Through a Hierarchy of
Characteristics, 4th International Workshop on Grid Computing (Grid2003),
November, 2003.
+ <section title="Appendices">
+ <section title="Acknowledgements">
+ <t> We gratefully acknowledge the contributions of: Jeff
+ Boote, Eric Boyd, Mark Leese, Dan Gunter, Richard
+ Hughes-Jones, Jason Zurawski and the other members of the
+ Network Measurements Working Group. </t>
+ </section>
+ </section>
--->
+ </middle>
- </references>
-</back>
+ <back>
+ <references>
+ <reference anchor="refs.tridentcom">
+ <front>
+ <title>A Scalable Framework for Representation and Exchange
+ of Network Measurements</title>
+ <author initials="J." surname="Zurawski"
+ fullname="Jason Zurawski">
+ <organization>University of Delaware</organization>
+ </author>
+ <author initials="M." surname="Swany">
+ <organization>University of Delaware</organization>
+ </author>
+ <author initials="D." surname="Gunter">
+ <organization>Lawrence Berkeley National
+ Laboratory</organization>
+ </author>
+ <date year="2006"/>
+ </front>
+ <seriesInfo
+ name="In Proceedings of 2nd International IEEE/Create-Net
+ Conference on Testbeds and Research Infrastructures for the
+ Development of Networks and Communities (Tridentcom
+ 2006)"
+ value=""/>
+ </reference>
+ <reference anchor="refs.hierarchy">
+ <front>
+ <title>Enabling Network Measurement Portability Through a
+ Hierarchy of Characteristics</title>
+ <author initials="B." surname="Lowekamp">
+ <organization/>
+ </author>
+ <author initials="B." surname="Tierney">
+ <organization/>
+ </author>
+ <author initials="L." surname="Cottrell">
+ <organization/>
+ </author>
+ <author initials="R." surname="Hughes-Jones">
+ <organization/>
+ </author>
+ <author initials="T." surname="Kielmann">
+ <organization/>
+ </author>
+ <author initials="M." surname="Swany">
+ <organization/>
+ </author>
+ <date month="November" year="2003"/>
+ </front>
+ <seriesInfo
+ name="4th International Workshop on Grid Computing (Grid2003)"
+ value=""/>
+ </reference>
+ </references>
+ </back>
+
</rfc>
- nmwg: r332 - trunk/nmwg/doc/nm-schema-base, svnlog, 02/27/2008
Archive powered by MHonArc 2.6.16.