perfsonar-dev - nmwg: r278 - trunk/nmwg/doc/nm-topo

Subject: perfsonar development work

List archive

nmwg: r278 - trunk/nmwg/doc/nm-topo

From:
To: ,
Subject: nmwg: r278 - trunk/nmwg/doc/nm-topo
Date: Mon, 1 Oct 2007 11:59:49 -0400

Author: aaron
Date: 2007-10-01 11:59:49 -0400 (Mon, 01 Oct 2007)
New Revision: 278

Modified:
trunk/nmwg/doc/nm-topo/nm-topo.xml
Log:
Commit the little bit i've added about nodes

Modified: trunk/nmwg/doc/nm-topo/nm-topo.xml
===================================================================
--- trunk/nmwg/doc/nm-topo/nm-topo.xml 2007-09-28 20:47:38 UTC (rev 277)
+++ trunk/nmwg/doc/nm-topo/nm-topo.xml 2007-10-01 15:59:49 UTC (rev 278)
@@ -2,427 +2,602 @@
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">


-<rfc>
-<?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" ?>
-
-<front>
- <title>
- An Extensible Schema for Network Topology
- </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>
+ <rfc>
+ <?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" ?>
+ 
+ <front>
+ <title>
+ An Extensible Schema for Network Topology
+ </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>

-<middle>
- <section anchor="intro" title="Introduction">
+ <middle>
+ <section anchor="intro" title="Introduction">

- <t>
- This document presents an extensible encoding standard for
- network topology. It provides a decription for the measured
- entities in the Network Measurement schema. In addition, this
- schema makes the relationship between those entities explicit.
- Like in the Network Measurement schema, we define basic
- structural elements and vary the XML namespace to allow for
- layer- or technology-specific information.
- </t>
+ <t>
+ This document presents an extensible encoding standard
for
+ network topology. It provides a decription for the
measured
+ entities in the Network Measurement schema. In
addition, this
+ schema makes the relationship between those entities
explicit.
+ Like in the Network Measurement schema, we define basic
+ structural elements and vary the XML namespace to allow
for
+ layer- or technology-specific information.
+ </t>

- <section id="goals" title="Goals">
- <t>
- The goal is to define a neutral representation for network
- topology that can be easily extended to support new types of
- networks and to serve the NM schema in terms of representing
- the subjects of network measurements, and their relationships.
- In addition, a representation of the topology of the network
- in this schema should allow NM clients and servers to discover
- appropriate peers for measurements and to determine if any
- available data is relevant to a given path.
- </t>
- </section>
+ <section id="goals" title="Goals">
+ <t>
+ The goal is to define a neutral representation for
network
+ topology that can be easily extended to support new
types of
+ networks and to serve the NM schema in terms of
representing
+ the subjects of network measurements, and their
relationships.
+ In addition, a representation of the topology of the
network
+ in this schema should allow NM clients and servers
to discover
+ appropriate peers for measurements and to determine
if any
+ available data is relevant to a given path.
+ </t>
+ </section>

- </section>
+ </section>

- <section id="design_philosophy" title="Design Philosophy">
+ <section id="design_philosophy" title="Design Philosophy">

- <t>
- Reuse the namespace thing from NM.
- </t>
+ <t>
+ Reuse the namespace thing from NM.
+ </t>
+ </section>

+ <section id="identifiers" title="Identifiers">

+ The network topology identifiers have been designed to be
flexible, be explicit
+ in their meaning and still be reasonably human-readable.

- </section>
+ The identifiers are encoded using the standard URN syntax as
described in RFC
+ 2141. The namespace for the urn is ``ogf''. The ``network''
namespace inside
+ the ``ogf'' namespace is used to differentiate identifiers
from others in the
+ OGF namespace. Thus, all identifiers MUST begin with
"urn:ogf:network:".

- <section id="identifiers" title="Identifiers">
+ The format for the rest of the namespace consists of a set
of name/value pairs.
+ Each of these fields is separated by a ``:'' and each name
and value is
+ separated by a ``=''. The value MUST be encoded using the
standard URN encoding
+ scheme with one addition. The ``='' character MUST be
encoded with the value
+ ``%D3''.

-The network topology identifiers have been designed to be flexible, be
explicit
-in their meaning and still be reasonably human-readable.
+ A single ``*'' may appear instead of a name/value field to
connote an ambiguous
+ identifier. If a '*' field is included, that field MUST be
the last field in
+ the identifier.

-The identifiers are encoded using the standard URN syntax as described in RFC
-2141. The namespace for the urn is ``ogf''. The ``network'' namespace inside
-the ``ogf'' namespace is used to differentiate identifiers from others in the
-OGF namespace. Thus, all identifiers MUST begin with "urn:ogf:network:".
+ The name/value pairs MUST be ordered from most general
network element to most
+ specific network element. For example, the domain field MUST
come before the
+ node field which MUST come before the port field.

-The format for the rest of the namespace consists of a set of name/value
pairs.
-Each of these fields is separated by a ``:'' and each name and value is
-separated by a ``=''. The value MUST be encoded using the standard URN
encoding
-scheme with one addition. The ``='' character MUST be encoded with the value
-``%D3''.
+ There MUST NOT exist repeated fields in the identifier.

-A single ``*'' may appear instead of a name/value field to connote an
ambiguous
-identifier. If a '*' field is included, that field MUST be the last field in
-the identifier.
+ <section id="fields">
+ <section title="Domain" id="fields_domain">

-The name/value pairs MUST be ordered from most general network element to
most
-specific network element. For example, the domain field MUST come before the
-node field which MUST come before the port field.
+ The domain field MUST be used to identify an
administrative domain. The
+ identifier for the domain MUST ONLY include the
domain field. The actual value
+ of this field MUST correspond to the AS number for
the given network, and MUST
+ NOT include any trailing spaces. Setting the value
of this field to '*'
+ connotes the domain is unknown. However, if the
value of this field is
+ '*', the field MUST be the last one in the
identifier.

-There MUST NOT exist repeated fields in the identifier.
+ urn:ogf:network:domain=237
+ urn:ogf:network:domain=*
+ </section>

-<section id="fields">
-<section title="Domain" id="fields_domain">
+ <section title="Node" id="fields_node">

-The domain field MUST be used to identify an administrative domain. The
-identifier for the domain MUST ONLY include the domain field. The actual
value
-of this field MUST correspond to the AS number for the given network, and
MUST
-NOT include any trailing spaces. Setting the value of this field to '*'
-connotes the domain is unknown. However, if the value of this field is
-'*', the field MUST be the last one in the identifier.
+ An identifier for a physical, logical or virtual
device in a domain MUST
+ include the domain and node fields. The domain field
MUST be identicial to
+ the domain field in the identifier for the domain
containing the device. The
+ value of the node field can be anything, but MUST be
unique inside the domain
+ and MUST NOT include any trailing spaces. The value
SHOULD be a human readable
+ description of the device. Setting the value of the
node field to '*' connotes
+ the device is unknown. If the value of the node
field is '*', the field MUST be
+ the last one in the identifier.

-urn:ogf:network:domain=237
-urn:ogf:network:domain=*
-</section>
+ Examples:

-<section title="Node" id="fields_node">
+ urn:ogf:network:domain=237:node=packrat
+ urn:ogf:network:domain=237:node=207.75.164.10
+ urn:ogf:network:domain=237:node=Joe's Machine
+ urn:ogf:network:domain=237:node=Los Angeles NOC
+ urn:ogf:network:domain=237:node=*
+ </section>

-An identifier for a physical, logical or virtual device in a domain MUST
-include the domain and node fields. The domain field MUST be identicial to
-the domain field in the identifier for the domain containing the device. The
-value of the node field can be anything, but MUST be unique inside the domain
-and MUST NOT include any trailing spaces. The value SHOULD be a human
readable
-description of the device. Setting the value of the node field to '*'
connotes
-the device is unknown. If the value of the node field is '*', the field MUST
be
-the last one in the identifier.
+ <section title="Interfaces" id="fields_interfaces">

-Examples:
+ An identifier for a physical, logical or virtual
interface to a device MUST
+ include the domain, node and port fields. The node
and domain fields MUST be
+ identicial to those fields in the identifier for the
device containing the
+ interface. The value of the port field can be
anything, but MUST be unique
+ inside the device and MUST NOT include any trailing
spaces. The value SHOULD be a
+ human readable description of the port. Setting the
value of the port field to
+ '*' connotes that the actual interface is unknown.
However, if the value of the
+ port field is '*', the field MUST be the last one in
the identifier.

-urn:ogf:network:domain=237:node=packrat
-urn:ogf:network:domain=237:node=207.75.164.10
-urn:ogf:network:domain=237:node=Joe's Machine
-urn:ogf:network:domain=237:node=Los Angeles NOC
-urn:ogf:network:domain=237:node=*
-</section>
+ Examples:

-<section title="Interfaces" id="fields_interfaces">
+ urn:ogf:network:domain=237:node=packrat:port=eth0
+
urn:ogf:network:domain=237:node=packrat:port=207.75.164.10
+ urn:ogf:network:domain=237:node=packrat:port=*
+ </section>

-An identifier for a physical, logical or virtual interface to a device MUST
-include the domain, node and port fields. The node and domain fields MUST be
-identicial to those fields in the identifier for the device containing the
-interface. The value of the port field can be anything, but MUST be unique
-inside the device and MUST NOT include any trailing spaces. The value SHOULD
be a
-human readable description of the port. Setting the value of the port field
to
-'*' connotes that the actual interface is unknown. However, if the value of
the
-port field is '*', the field MUST be the last one in the identifier.
+ <section title="Unidirectional Intra-domain/Inter-domain
Links" id="fields_unilinks">

-Examples:
+ An identifier for a unidirectional link MUST include
the domain, node, port and
+ link fields. The undirectional link belongs to the
port which can write to the
+ link. Thus, the domain, node and port fields in the
identifier MUST be
+ identical to those fields in the identifier for the
port to which the link
+ belongs. The value of the link field can be
anything, but MUST be unique inside
+ the port and MUST NOT include any trailing spaces.
The value SHOULD be a human
+ readable description of the link. If the
unidirectional link is one side of a
+ bidirectional link, the value of the link field
SHOULD be the same as the link
+ field on the identifier for the other direction of
the bidirectional link.
+ Setting the value of the link field to '*' connotes
that the actual link is
+ unknown.

-urn:ogf:network:domain=237:node=packrat:port=eth0
-urn:ogf:network:domain=237:node=packrat:port=207.75.164.10
-urn:ogf:network:domain=237:node=packrat:port=*
-</section>
+ Examples:

-<section title="Unidirectional Intra-domain/Inter-domain Links"
id="fields_unilinks">
+
urn:ogf:network:domain=237:node=packrat:port=eth0:link=Link Between Packrat
And Router1
+
urn:ogf:network:domain=237:node=packrat:port=eth0:link=*
+ </section>

-An identifier for a unidirectional link MUST include the domain, node, port
and
-link fields. The undirectional link belongs to the port which can write to
the
-link. Thus, the domain, node and port fields in the identifier MUST be
-identical to those fields in the identifier for the port to which the link
-belongs. The value of the link field can be anything, but MUST be unique
inside
-the port and MUST NOT include any trailing spaces. The value SHOULD be a
human
-readable description of the link. If the unidirectional link is one side of a
-bidirectional link, the value of the link field SHOULD be the same as the
link
-field on the identifier for the other direction of the bidirectional link.
-Setting the value of the link field to '*' connotes that the actual link is
-unknown.
+ <section title="Bidirectional Domain Links"
id="fields_bidilinks">

-Examples:
+ An identifier for a bidirectional link that begins
and ends solely in one domain
+ MUST include the link field. Since the link begins
and ends in one domain, the identifier
+ SHOULD include the domain field. If the domain field
is included, it MUST be
+ identical to the domain field in the identifier for
the domain to which the link
+ belongs. The value of the link field can be
anything, but MUST be unique inside
+ the domain if the domain field is included or
globally unique if not and MUST
+ NOT include any trailing spaces. The value SHOULD
be a human readable
+ description of the link and SHOULD be the same value
as the undirectional links
+ that make up the link. Setting the value of the link
field to '*' connotes the
+ actual link is unknown.

-urn:ogf:network:domain=237:node=packrat:port=eth0:link=Link Between Packrat
And Router1
-urn:ogf:network:domain=237:node=packrat:port=eth0:link=*
-</section>
+ Examples:

-<section title="Bidirectional Domain Links" id="fields_bidilinks">
+ urn:ogf:network:domain=237:link=Link Between Packrat
And Router1
+ urn:ogf:network:domain=237:link=*
+ </section>

-An identifier for a bidirectional link that begins and ends solely in one
domain
-MUST include the link field. Since the link begins and ends in one domain,
the identifier
-SHOULD include the domain field. If the domain field is included, it MUST be
-identical to the domain field in the identifier for the domain to which the
link
-belongs. The value of the link field can be anything, but MUST be unique
inside
-the domain if the domain field is included or globally unique if not and MUST
-NOT include any trailing spaces. The value SHOULD be a human readable
-description of the link and SHOULD be the same value as the undirectional
links
-that make up the link. Setting the value of the link field to '*' connotes
the
-actual link is unknown.
+ <section title="Bidirectional Inter-domain Links"
id="fields_bidiinterlinks">

-Examples:
+ An identifier for a bidirectional link that begins
and ends in different
+ domains MUST include ONLY the link field. The value
of the link field can be
+ anything, but MUST be globally unique and MUST NOT
include any trailing spaces.
+ The value SHOULD be a human readable description of
the link and SHOULD be the
+ same value as the undirectional links that make up
the link. Setting the value
+ of the link field to '*' connotes the link is
unknown. However, if the value
+ of the link field is '*', the field MUST be the last
one in the identifier.

-urn:ogf:network:domain=237:link=Link Between Packrat And Router1
-urn:ogf:network:domain=237:link=*
-</section>
+ Examples:

-<section title="Bidirectional Inter-domain Links" id="fields_bidiinterlinks">
+ urn:ogf:network:link=Link Between Internet2 And ESNet
+ urn:ogf:network:link=*
+ </section>

-An identifier for a bidirectional link that begins and ends in different
-domains MUST include ONLY the link field. The value of the link field can be
-anything, but MUST be globally unique and MUST NOT include any trailing
spaces.
-The value SHOULD be a human readable description of the link and SHOULD be
the
-same value as the undirectional links that make up the link. Setting the
value
-of the link field to '*' connotes the link is unknown. However, if the
value
-of the link field is '*', the field MUST be the last one in the identifier.
+ <section title="Intra-domain Path" id="fields_intrapath">

-Examples:
+ An identifier for a named path that passes begins
and ends inside a domain MUST
+ include the path field. An intra-domain path
identifier SHOULD include the
+ domain field for the domain common to all elements
in the path. The value of
+ the path field can be anything but MUST NOT include
any trailing spaces. If the
+ identifier includes the domain field, the value of
the path field MUST be
+ unique inside the domain. If the domain field is not
included, the value of the
+ path field MUST be globally unique. Setting the
value of the path field to '*'
+ connotes the path is unknown. However, if the value
of the path field is '*',
+ the field MUST be the last one in the identifier.

-urn:ogf:network:link=Link Between Internet2 And ESNet
-urn:ogf:network:link=*
-</section>
+ Examples:

-<section title="Intra-domain Path" id="fields_intrapath">
+ urn:ogf:network:domain=237:path=DRAGON Path From
207.75.164.10 to 207.75.160.5
+ urn:ogf:network:path=DRAGON Path From 207.75.164.10
to 207.75.160.5
+ urn:ogf:network:path=*
+ </section>

-An identifier for a named path that passes begins and ends inside a domain
MUST
-include the path field. An intra-domain path identifier SHOULD include the
-domain field for the domain common to all elements in the path. The value of
-the path field can be anything but MUST NOT include any trailing spaces. If
the
-identifier includes the domain field, the value of the path field MUST be
-unique inside the domain. If the domain field is not included, the value of
the
-path field MUST be globally unique. Setting the value of the path field to
'*'
-connotes the path is unknown. However, if the value of the path field is
'*',
-the field MUST be the last one in the identifier.
+ <section title="Inter-domain Path" id="fields_interpath">

-Examples:
+ An identifier for a named path which passes through
multiple domains MUST
+ include ONLY the path field. The value of the path
field can be anything but
+ MUST be globally unique and MUST NOT include any
trailing spaces. Setting the
+ value of the path field to '*' connotes the path is
unknown.

-urn:ogf:network:domain=237:path=DRAGON Path From 207.75.164.10 to
207.75.160.5
-urn:ogf:network:path=DRAGON Path From 207.75.164.10 to 207.75.160.5
-urn:ogf:network:path=*
-</section>
+ Examples:

-<section title="Inter-domain Path" id="fields_interpath">
+ urn:ogf:network:path=DRAGON Path From 207.75.164.10
to 134.55.209.97
+ urn:ogf:network:path=*
+ </section>

-An identifier for a named path which passes through multiple domains MUST
-include ONLY the path field. The value of the path field can be anything but
-MUST be globally unique and MUST NOT include any trailing spaces. Setting the
-value of the path field to '*' connotes the path is unknown.
+ <section title="Network" id="fields_network">

-Examples:
+ An identifier for an arbitrary grouping of network
elements MUST include the
+ network field. If all the elements in the network
fall under the same domain,
+ the identifier SHOULD include the domain field. If
the identifier includes the
+ domain field, the domain field MUST contain the same
value as the domain field
+ in the identifier for the domain containing all the
elements. The value of the
+ network field can be anything but MUST NOT include
any trailing spaces. If the
+ identifier includes the domain field, the value of
the network field MUST be
+ unique inside the domain. If the domain field is not
included, the value of the
+ network field MUST be globally unique. Setting the
value of the network field
+ to '*' connotes the network is unknown. However, if
the value of the network field
+ is '*', the field MUST be the last one in the
identifier.

-urn:ogf:network:path=DRAGON Path From 207.75.164.10 to 134.55.209.97
-urn:ogf:network:path=*
-</section>
+ Examples:

-<section title="Network" id="fields_network">
+ urn:ogf:network:domain=237:network=207.75.164.0%2F24
+ urn:ogf:network:network=207.0.0.0%2F8
+ urn:ogf:network:network=*
+ </section>

-An identifier for an arbitrary grouping of network elements MUST include the
-network field. If all the elements in the network fall under the same
domain,
-the identifier SHOULD include the domain field. If the identifier includes
the
-domain field, the domain field MUST contain the same value as the domain
field
-in the identifier for the domain containing all the elements. The value of
the
-network field can be anything but MUST NOT include any trailing spaces. If
the
-identifier includes the domain field, the value of the network field MUST be
-unique inside the domain. If the domain field is not included, the value of
the
-network field MUST be globally unique. Setting the value of the network field
-to '*' connotes the network is unknown. However, if the value of the network
field
-is '*', the field MUST be the last one in the identifier.
+ </section>

-Examples:
+ <section id="basic_elements" title="Basic Elements">
+ <t>This schema defines the basic elements that can be
used to
+ describe network topologies.
+ </t>

-urn:ogf:network:domain=237:network=207.75.164.0%2F24
-urn:ogf:network:network=207.0.0.0%2F8
-urn:ogf:network:network=*
-</section>
+ <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
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 a remote URI.)
+ </t>

- </section>
+ <section id="node" title="Node">
+ <t>
+ This is a typical node in a graph context.
Depending on the
+ context, this can be a host, a network device,
or something more
+ abstract like a "site". The node element contains
+ basic properties that apply to all nodes.
+ </t>
+ <section id="node_id" title="id Attribute">
+ <t>
+ Each node has an id attribute that contains
the identifier for this node. It can contain a role attribute or element to
describe the purpose of this node.

- <section id="basic_elements" title="Basic Elements">
- <t>This schema defines the basic elements that can be used to
- describe network topologies.
- </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 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 a remote URI.)
- </t>
+ </t>
+ </section>
+ <section id="node_idref" title="idRef Attribute">
+ <t>
+ Another identifying attribute is the idRef
attribute. If this is included, the id attribute must not be included. This
attribute is a way of defining partial information about a node. If a node
element has this attribute, it means that this node element is not the
authoritative, it simply contains additional information about the element.

- <section id="node" title="Node">
- <t>This is a typical node in a graph context. Depending on the
- context, this can be a host, a network device, or something more
- abstract like a "site".
- </t>
- </section>
+ </t>
+ </section>

- <section id="links" title="Links">
- <t>
- Nodes are connected by Links, which are edges in the graph
- model. These Links have properties associated with them.
- </t>
- </section>
+ <section id="node_type" title="Type">
+ <t>
+ Each node can also include a type element to
+ describe what type of network element this
node is.
+ The contents of this element are
unspecified, but
+ could be "logical" if the node wasn't a
physical
+ piece of hardware, "router" if it were a
physical
+ router or anything like that. If the node
isn't a
+ physical piece of equipment, the contents of
this
+ element should be "logical".
+ </t>
+ </section>
+ <section id="node_role" title="Role">
+ <t>
+ </t>
+ </section>

- <section id="interface" title="Interface">
- <t>
- Nodes have interfaces, which are the attachment points of
- links. They have properties which are independent of the
- Node.
- </t>
- </section>
+ <section id="node_hostname" title="Hostname">
+ <t>
+ Each node can have a hostName element to
+ describe its hostName as seen by the outside
+ world. This must not be included if the
device
+ is a virtual device. The element is a string
+ that contains a resolvable DNS name.
+ </t>
+ </section>

+ <section id="node_address" title="Address">
+ <t>
+ Each node can have an address element to
+ describe an address that the outside world
can
+ use to contact this node. This must not be
+ included if the device is a virtual device.
+ </t>
+ <t>
+ The element may contain a type attribute that
+ describes the contents of the element. If the
+ type is set to "ipv4", the element must
contain
+ an ipv4 address in dotted decimal format. If
+ the type is set to "ipv6", the element must
+ contain an ipv6 address in colon-separated
+ hexadecimal format. Any other value for type
+ leaves the format unspecified and an
+ implementation may try to parse the element's
+ contents on its own. However, the parsing of
+ the element is outside the scope of this
+ document.
+ </t>
+ </section>

+ <section id="node_location" title="Location
Information">
+ <t>
+ Each node may contain one location element
+ which can be used to describe the physical
+ location of the node. The purpose of
including
+ this element is for people to be able to get
+ some basic information about where this
machine
+ is located. The element can consist of any of
+ the following elements: latitude, longitude,
+ continent, country, zipcode, state, city,
+ streetAddress, floor, room, cage, rack,
shelf.
+ </t>
+ <t>
+ The latitude and longitude elements are
+ floating point values that describe the
+ location on earth where the node is located.
+ The streetAddress, city, state, zipcode and
+ country can be included to specify the actual
+ address of the building where the node is
+ located. The room, cage, rack and shelf can
be
+ used to describe precisely where in the
+ building a node is located.
+ </t>
+ </section>

- <section id="network" title="Network">
- <t>
- A Network is essentially a scoping construct.
- </t>
- </section>
+ <section id="node_contact" title="Contact
Information">
+ <t>
+ Each node may contain one or more contact
+ elements containing information about
+ who to contact for questions about the
+ specified node. The elements may have a
+ priority attribute set which is a
non-negative
+ number. The priority attribute can be used to
+ specify an ordering of the contact
information
+ with the primary contact being "0". If
multiple
+ contact elements share a priority, the
ordering
+ is unspecified among them. The lowest
priority
+ group consists of all nodes with no priority
+ attribute set.
+ </t>

+ <t>
+ The contents of the contact element may
consist
+ of the following elements: administrator,
+ email, phoneNumber, institution. The
+ administrator element is a string that should
+ contain the name of the administrator for the
+ machine. The institution element is a string
+ that should contain the name of the
institution
+ that has been tasked with administering this
+ machine. The email element is a string that
+ should contain the email address of the
+ administrator or a help desk where questions
+ about the node can be asked. The phoneNumber
+ element is a string that should contain the
+ phone number of the administrator or the
+ institution's help desk where questions about
+ the node can be asked.
+ </t>
+ </section>
+ <t>
+ Each node can include a description element. This
+ element should include a human readable
description
+ of the node.

- </section>
+ </t>
+ </section>

- <section id="xml_namespace" title="XML Namespaces">
+ <section id="links" title="Links">
+ <t>
+ Nodes are connected by Links, which are edges in
the graph
+ model. These Links have properties associated
with them.
+ </t>
+ </section>

- <t>
- Like the NM schema, a key facet in this schema is the
- observation that the above elements can be used to describe any
- network topology layer, but the exact contents of the each will
- vary with the layer. 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 describing properties at
- various layers.
- </t>
+ <section id="interface" title="Interface">
+ <t>
+ Nodes have interfaces, which are the attachment
points of
+ links. They have properties which are
independent of the
+ Node.
+ </t>
+ </section>

- <t>This version of the schema includes layers subdivided by the
- layer of the OSI protocol model. </t>

- </section>

- <section id="versioning" title="Versioning">
- <t>Completely lifted from NM doc.. the issues are the same.
- maybe we just reference</t>
+ <section id="network" title="Network">
+ <t>
+ A Network is essentially a scoping construct.
+ </t>
+ </section>

- <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>
- 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>

- <section id="relationships" title="Relationships Among Elements">
- <t>
-
- </t>
- </section>
+ <section id="xml_namespace" title="XML Namespaces">

- <section id="topo_base_schema" title="Base Topolgy Schema">
- <t>
- <artwork><![CDATA[
- <inline file="schema/nmtopo_base.rnc"/>
- ]]></artwork>
- </t>
- </section>
+ <t>
+ Like the NM schema, a key facet in this schema is the
+ observation that the above elements can be used to
describe any
+ network topology layer, but the exact contents of
the each will
+ vary with the layer. 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 describing
properties at
+ various layers.
+ </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>
-
- <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>
+ <t>This version of the schema includes layers subdivided
by the
+ layer of the OSI protocol model. </t>

+ </section>

- </section>
+ <section id="versioning" title="Versioning">
+ <t>Completely lifted from NM doc.. the issues are the
same.
+ maybe we just reference</t>

- 
+ <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>

-</middle>
+ <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>

-<back>
+ <section id="relationships" title="Relationships Among
Elements">
+ <t>
+ There are some relationships that are built directly
+ into the schema. For example, a port may be defined
+ inside of the node on which it exists or a
+ unidirectional link may have a remoteLinkId field
+ containing its opposite unidirectional link in a
+ logical bidirectional link. However, for every
relation
+ that one can think of, there exists another possible
+ relation. This implies the need for a general way of
+ creating relations between arbitrary topology
elements.
+ </t>
+ <t>
+ To this end, there exists an xml element named
+ "relation" that can have one or more instances in
every
+ topology element. This xml element contains a
required
+ attribute "type" which defines what kind of
+ relationship this element is defining. Contained
within
+ the element is a list idRef elements containing
+ pointers to all the topology elements related to the
+ current topology element in the specified fashion.
+ </t>
+ <t>
+ There is one type of relationship that is defined in
+ the schema using these elements: over. The over
+ relationship can be used to describe any situation
+ where a given logical topology element has other
+ logical elements underneat it. For example, a
+ bidirectional link is actually made up of two
+ unidirectional that it logically sits over.
Therefore,
+ a bidirectional link definition would have a relation
+ block of type "over" with two idRefs in it containing
+ the identifiers for the undirectional links that make
+ it up.
+ </t>
+ <t>
+ The over relation can also be used in the
construction
+ of higher level logical constructs. For example, a
+ logical description of a domain could consist of a
+ single node with a large number of logical ports to
the
+ outside world. Thus, a domain could choose to export
a
+ topology consisting of a single node with a large
+ number of logical ports, and internally, this node
and
+ these ports could each have an over relation that
+ pointed to the various physical components that they
+ represent.
+ </t>

- <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">
-
<email></email>
- </author>
- <author initials="D." surname="Gunter">
-
<email></email>
- </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 id="topo_base_schema" title="Base Topolgy Schema">
+ <t>
+ <artwork><![CDATA[
+ <inline file="schema/nmtopo_base.rnc"/>
+ ]]></artwork>
+ </t>
+ </section>

- </references>
-</back>
+ <section title="Security Concerns">

-</rfc>
+ <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>
+
+ 
+
+ </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">
+
<email></email>
+ </author>
+ <author initials="D." surname="Gunter">
+
<email></email>
+ </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>
+
+ 
+
+ </references>
+ </back>
+
+ </rfc>

nmwg: r278 - trunk/nmwg/doc/nm-topo, svnlog, 10/01/2007

List archive

nmwg: r278 - trunk/nmwg/doc/nm-topo