perfsonar development work

Author: aaron
Date: 2008-05-20 12:05:26 -0400 (Tue, 20 May 2008)
New Revision: 348

Added:
   trunk/nmwg/doc/nm-topo/examples/
   trunk/nmwg/doc/nm-topo/examples/basic_network.xml
   trunk/nmwg/doc/nm-topo/examples/basic_network_more_details.xml
   trunk/nmwg/doc/nm-topo/examples/l2l3_network_more_details.xml
   trunk/nmwg/doc/nm-topo/examples/nmtopo_base_node.xml
Modified:
   trunk/nmwg/doc/nm-topo/nm-topo.fo
   trunk/nmwg/doc/nm-topo/nm-topo.html
   trunk/nmwg/doc/nm-topo/nm-topo.pdf
   trunk/nmwg/doc/nm-topo/nm-topo.xml
   trunk/nmwg/doc/nm-topo/tmp.nm-topo.xml
Log:
Update the documentation for the topology changes that were made.



Added: trunk/nmwg/doc/nm-topo/examples/basic_network.xml

Added: trunk/nmwg/doc/nm-topo/examples/basic_network_more_details.xml

Added: trunk/nmwg/doc/nm-topo/examples/l2l3_network_more_details.xml

Added: trunk/nmwg/doc/nm-topo/examples/nmtopo_base_node.xml

Modified: trunk/nmwg/doc/nm-topo/nm-topo.fo
===================================================================
--- trunk/nmwg/doc/nm-topo/nm-topo.fo   2008-05-20 15:55:47 UTC (rev 347)
+++ trunk/nmwg/doc/nm-topo/nm-topo.fo   2008-05-20 16:05:26 UTC (rev 348)
@@ -1,546 +1,1700 @@
-<?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="&#xA;&#x9;An Extensible Schema for Network Topology&#xA;  
"/><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" margi
 n-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 i
 nternal-destination="rfc.section.2"><fo:bookmark-title>2 Des!
 ign Phil
osophy</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 
Node</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2 
Links</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.3"><fo:bookmark-title>3.3 
Interface</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.4"><fo:bookmark-title>3.4 
Network</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML 
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5"><fo:bookmark-title>5 
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6"><fo:bookmark-title>6 Relationships Among 
Elements</fo:bookmark-title></fo:bookmark><fo
 :bookmark internal-destination="rfc.section.7"><fo:bookmark-title>7 Base 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.8"><fo:bookmark-title>8 Security 
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.references"><fo:bookmark-title>9 
References</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.authors"><fo:bookmark-title>Author's 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and 
Copyright 
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
 master-reference="sequence" language="en"><fo:static-content 
flow-name="header"><fo:table width="100%" text-align="center" 
space-before=".2cm" table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(6)"/><fo:table-column 
column-width="proportional-column-width(46)"/><fo:table-column 
column-width="proportional-column-w
 idth(6)"/><fo:table-body><fo:table-row><fo:table-cell><fo:bl!
 ock text
-align="start">RFC </fo:block></fo:table-cell><fo:table-cell 
text-align="center"><fo:block>
-       An Extensible Schema for Network Topology
-  </fo:block></fo:table-cell><fo:table-cell text-align="end"><fo:block>May 
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:static-content
 flow-name="footer"><fo:table text-align="center" width="100%" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(7.5)"/><fo:table-column 
column-width="proportional-column-width(13)"/><fo:table-column 
column-width="proportional-column-width(7.5)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
 text-align="start">Swany</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="center">Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
 text-align="end">[Page 
<fo:page-number/>]</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:flow
 flow-name="xsl-region-body"><fo:table width="100%" 
table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(1)"/><fo:table-column 
column-width="proportio
 
nal-column-width(1)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block>Network
 Measurement Working Group</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="right">M Swany, 
Editor</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block/></fo:table-cell><fo:table-cell><fo:block
 
text-align="right">UDel</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block>Intended
 status: Informational</fo:block></fo:table-cell><fo:table-cell><fo:block 
text-align="right">May 
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table><fo:block
 text-align="center" font-weight="bold" font-size="18pt" space-before="3em" 
space-after="3em">
-       An Extensible Schema for Network Topology
-  </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 Topology "/><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" p
 age-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-destina
 tion="rfc.section.2"><fo:bookmark-title>2 Design Philosophy<!
 /fo:book
mark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3"><fo:bookmark-title>3 
Identifiers</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1 Description of 
Fields</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1 
Domain</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 
Node</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3 
Service</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.4"><fo:bookmark-title>3.1.4 
Interfaces</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.5"><fo:bookmark-title>3.1.5 
Unidirectional Intra-domain/Inter-domain 
Links</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.6"><fo:bookmark-title>3.1.6 
Bidirectional Domain Links</fo
 :bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.7"><fo:bookmark-title>3.1.7 
Bidirectional Inter-domain 
Links</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.8"><fo:bookmark-title>3.1.8 
Intra-domain Path</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.9"><fo:bookmark-title>3.1.9 
Inter-domain Path</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.3.1.10"><fo:bookmark-title>3.1.10 
Network</fo:bookmark-title></fo:bookmark></fo:bookmark></fo:bookmark><fo:bookmark
 internal-destination="rfc.section.4"><fo:bookmark-title>4 Basic 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.1"><fo:bookmark-title>4.1 
Domain</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.1.1"><fo:bookmark-title>4.1.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.1.2"><fo:bookmark-title>
 4.1.2 idRef Attribute</fo:bookmark-title></fo:bookmark><fo:b!
 ookmark 
internal-destination="rfc.section.4.1.3"><fo:bookmark-title>4.1.3 Entities In 
The Domain</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2"><fo:bookmark-title>4.2 
Node</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.2.1"><fo:bookmark-title>4.2.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.2"><fo:bookmark-title>4.2.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.3"><fo:bookmark-title>4.2.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.2.3.1"><fo:bookmark-title>4.2.3.1 
Type</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.4"><fo:bookmark-title>4.2.4 
Role</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.5"><fo:bookmark-title>4.2.5 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark internal-desti
 nation="rfc.section.4.2.6"><fo:bookmark-title>4.2.6 Location 
Information</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.7"><fo:bookmark-title>4.2.7 Contact 
Information</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.8"><fo:bookmark-title>4.2.8 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.9"><fo:bookmark-title>4.2.9 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.10"><fo:bookmark-title>4.2.10 
Relations</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.11"><fo:bookmark-title>4.2.11 
Lifetime</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.2.12"><fo:bookmark-title>4.2.12 
Interfaces</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3"><fo:bookmark-title>4.3 
Links</fo:bookmark-title><fo:bookmark interna
 l-destination="rfc.section.4.3.1"><fo:bookmark-title>4.3.1 i!
 d Attrib
ute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.2"><fo:bookmark-title>4.3.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.3"><fo:bookmark-title>4.3.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.3.3.1"><fo:bookmark-title>4.3.3.1 
Type</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.4"><fo:bookmark-title>4.3.4 Global 
Name</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.5"><fo:bookmark-title>4.3.5 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.6"><fo:bookmark-title>4.3.6 Remote Link 
Id</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.7"><fo:bookmark-title>4.3.7 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.8"><fo:bookmark-title>4.3.8 
Comments</fo:boo
 kmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.9"><fo:bookmark-title>4.3.9 
Relations</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.3.9.1"><fo:bookmark-title>4.3.9.1 
Bidirectional 
Relations</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.3.10"><fo:bookmark-title>4.3.10 
Lifetime</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4"><fo:bookmark-title>4.4 
Interfaces</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.4.1"><fo:bookmark-title>4.4.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.2"><fo:bookmark-title>4.4.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.3"><fo:bookmark-title>4.4.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.4.3.1"><fo:bookmark-title>4.4.3.1 
Type</fo:bookmark-ti
 tle></fo:bookmark></fo:bookmark><fo:bookmark internal-destin!
 ation="r
fc.section.4.4.4"><fo:bookmark-title>4.4.4 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.5"><fo:bookmark-title>4.4.5 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.6"><fo:bookmark-title>4.4.6 
Capactity</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.7"><fo:bookmark-title>4.4.7 
MTU</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.8"><fo:bookmark-title>4.4.8 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.9"><fo:bookmark-title>4.4.9 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.10"><fo:bookmark-title>4.4.10 
Relations</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.11"><fo:bookmark-title>4.4.11 
Lifetime</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.4.12"><fo:
 bookmark-title>4.4.12 
Links</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5"><fo:bookmark-title>4.5 
Service</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.5.1"><fo:bookmark-title>4.5.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5.2"><fo:bookmark-title>4.5.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5.3"><fo:bookmark-title>4.5.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.5.3.1"><fo:bookmark-title>4.5.3.1 
Type</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5.4"><fo:bookmark-title>4.5.4 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5.5"><fo:bookmark-title>4.5.5 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.5.6"><fo:bookmark-title>4.5
 .6 Relations</fo:bookmark-title></fo:bookmark><fo:bookmark i!
 nternal-
destination="rfc.section.4.5.7"><fo:bookmark-title>4.5.7 
Lifetime</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6"><fo:bookmark-title>4.6 
Network</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.6.1"><fo:bookmark-title>4.6.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.2"><fo:bookmark-title>4.6.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.3"><fo:bookmark-title>4.6.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.6.3.1"><fo:bookmark-title>4.6.3.1 
Type</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.4"><fo:bookmark-title>4.6.4 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.5"><fo:bookmark-title>4.6.5 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.sect
 ion.4.6.6"><fo:bookmark-title>4.6.6 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.7"><fo:bookmark-title>4.6.7 
Relations</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.8"><fo:bookmark-title>4.6.8 
Lifetime</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.6.9"><fo:bookmark-title>4.6.9 Entities In 
The Network</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7"><fo:bookmark-title>4.7 
Path</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.7.1"><fo:bookmark-title>4.7.1 id 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.2"><fo:bookmark-title>4.7.2 idRef 
Attribute</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.3"><fo:bookmark-title>4.7.3 
Name</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.7.3.1"><fo:boo
 kmark-title>4.7.3.1 Type</fo:bookmark-title></fo:bookmark></!
 fo:bookm
ark><fo:bookmark 
internal-destination="rfc.section.4.7.4"><fo:bookmark-title>4.7.4 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.5"><fo:bookmark-title>4.7.5 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.6"><fo:bookmark-title>4.7.6 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.7"><fo:bookmark-title>4.7.7 
Relations</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.8"><fo:bookmark-title>4.7.8 
Lifetime</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.7.9"><fo:bookmark-title>4.7.9 Entities In 
The Network</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8"><fo:bookmark-title>4.8 Endpoint 
Pairs</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.4.8.1"><fo:bookmark-title>4.8.1 
Name</fo:bookmark-title><fo:bookmark intern
 al-destination="rfc.section.4.8.1.1"><fo:bookmark-title>4.8.1.1 
Type</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8.2"><fo:bookmark-title>4.8.2 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8.3"><fo:bookmark-title>4.8.3 
Description</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8.4"><fo:bookmark-title>4.8.4 
Comments</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8.5"><fo:bookmark-title>4.8.5 
Source</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.4.8.6"><fo:bookmark-title>4.8.6 
Destination</fo:bookmark-title></fo:bookmark></fo:bookmark></fo:bookmark><fo:bookmark
 internal-destination="rfc.section.5"><fo:bookmark-title>5 Layer 2 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.5.1"><fo:bookmark-title>5.1 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark interna
 l-destination="rfc.section.5.2"><fo:bookmark-title>5.2 Port<!
 /fo:book
mark-title><fo:bookmark 
internal-destination="rfc.section.5.2.1"><fo:bookmark-title>5.2.1 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.2.2"><fo:bookmark-title>5.2.2 
ifName</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.2.3"><fo:bookmark-title>5.2.3 
ifIndex</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.2.4"><fo:bookmark-title>5.2.4 Vlan 
Tag</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.2.5"><fo:bookmark-title>5.2.5 Vlan Range 
Availability</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.3"><fo:bookmark-title>5.3 
Link</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.5.3.1"><fo:bookmark-title>5.3.1 Vlan 
Tag</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.5.4"><fo:bookmark-title>5.4 
Network</fo:bookmark-title><fo:bookmark 
 internal-destination="rfc.section.5.4.1"><fo:bookmark-title>5.4.1 Vlan 
Tag</fo:bookmark-title></fo:bookmark></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6"><fo:bookmark-title>6 Layer 3 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.6.1"><fo:bookmark-title>6.1 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6.2"><fo:bookmark-title>6.2 
Port</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.6.2.1"><fo:bookmark-title>6.2.1 
Name</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6.2.2"><fo:bookmark-title>6.2.2 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6.2.3"><fo:bookmark-title>6.2.3 
Netmask</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.6.3"><fo:bookmark-title>6.3 
Network</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.6.3.1"><fo:boo
 kmark-title>6.3.1 Subnet</fo:bookmark-title></fo:bookmark><f!
 o:bookma
rk internal-destination="rfc.section.6.3.2"><fo:bookmark-title>6.3.2 
ASN</fo:bookmark-title></fo:bookmark></fo:bookmark></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7"><fo:bookmark-title>7 Layer 4 
Elements</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.7.1"><fo:bookmark-title>7.1 
Type</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7.2"><fo:bookmark-title>7.2 
Port</fo:bookmark-title><fo:bookmark 
internal-destination="rfc.section.7.2.1"><fo:bookmark-title>7.2.1 
Name</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7.2.2"><fo:bookmark-title>7.2.2 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.7.2.3"><fo:bookmark-title>7.2.3 Port 
Number</fo:bookmark-title></fo:bookmark></fo:bookmark></fo:bookmark><fo:bookmark
 internal-destination="rfc.section.8"><fo:bookmark-title>8 Control Plane 
Elements</fo:bookmark-title></fo:bookmark><fo:bookmark internal
 -destination="rfc.section.9"><fo:bookmark-title>9 XML 
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.10"><fo:bookmark-title>10 
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.11"><fo:bookmark-title>11 Relationships 
Among Elements</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.12"><fo:bookmark-title>12 Base Topology 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.13"><fo:bookmark-title>13 Layer 2 Topology 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.14"><fo:bookmark-title>14 Layer 3 Topology 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.15"><fo:bookmark-title>15 Layer 4 Topology 
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.section.16"><fo:bookmark-title>16 Control Plane 
Topology Schema</fo:bookmark-title>
 </fo:bookmark><fo:bookmark internal-destination="rfc.section!
 .17"><fo
:bookmark-title>17 Security 
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.references"><fo:bookmark-title>18 
References</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.authors"><fo:bookmark-title>Author's 
Address</fo:bookmark-title></fo:bookmark><fo:bookmark 
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectual Property and 
Copyright 
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
 master-reference="sequence" language="en"><fo:static-content 
flow-name="header"><fo:table width="100%" text-align="center" 
space-before=".2cm" table-layout="fixed"><fo:table-column 
column-width="proportional-column-width(9)"/><fo:table-column 
column-width="proportional-column-width(43)"/><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 Ex
 tensible Schema for Network Topology 
</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="proportional-column-width(1)!
 "/><fo:t
able-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 Topology 
</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 topology based on the NM performance data 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
-        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.
-         </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">
-         Reuse the namespace thing from NM.
-       </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
-    describe network topologies.
-       </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 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.)
-       </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  Node</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">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".
-         </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  Links</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
-               Nodes are connected by Links, which are edges in the graph
-               model.  These Links have properties associated with them.
-         </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  Interface</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
-               Nodes have interfaces, which are the attachment points of
-               links.  They have properties which are independent of the
-               Node. 
-         </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.3.4">3.4  Network</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
-               A Network is essentially a scoping construct.  
-         </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">
-         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.
-       </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">This version of the schema includes layers subdivided by 
the
-       layer of the OSI protocol model.  </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.  Versioning</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">Completely lifted from NM doc..  the 
issues are the same.
-       maybe we just reference</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.6">6.  Relationships Among Elements</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
-         
-       </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.  Base Schema</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
-         <fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
-# 
-# File:      nmbase.rnc - Main schema definition
-# Version:   $Id: nmbase.rnc 230 2007-05-07 13:12:03Z swany $
-# Purpose:   This is the main schema file, it defines the
-#             general structure of an NMWG message or store
-# 
-# ##############################################################
+      </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 topology. It provides a description 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. </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
+          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. </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"> Networks have basic components and any network
+        representation must include these basic elements. Like the
+        Network Measurement schema, we define the basic elements and
+        vary the namespace of them to indicate specific components. 
</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="identifiers"/>3.  Identifiers</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em"> The network topology identifiers have 
been designed to be
+        flexible, be explicit in their meaning and still be reasonably
+        human-readable. </fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">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:".</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">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''.</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">A single ``*'' may appear instead of a 
name/value field to
+       connote an identifier for an unknown network element of unknown type.
+       If a '*' field is included, that field MUST be the last field in the
+       identifier.</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">The name/value pairs MUST be ordered 
from most general
+        network entity to most specific network entity. For example,
+        the domain field MUST come before the node field which MUST
+        come before the port field. There MUST NOT exist repeated
+        fields in the identifier.</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="fields"/>3.1  Description of Fields</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="fields_domain"/>3.1.1  Domain</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           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 be a globally unique DNS name for that domain, and MUST
+           NOT include any trailing spaces. Setting the value of this field 
to
+           '*' connotes the domain is unknown.
+          </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"> 
urn:ogf:network:domain=dcn.internet2.edu
+                urn:ogf:network:domain=* (this)
+                urn:ogf:network:domain=dcn.internet2.edu:* (is shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </fo:block></fo: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.2"><fo:block 
id="fields_node"/>3.1.2  Node</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">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. 
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Examples: <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"> 
urn:ogf:network:domain=internet2.edu:node=packrat
+                urn:ogf:network:domain=internet2.edu:node=207.75.164.10
+                urn:ogf:network:domain=internet2.edu:node=Joe's Machine
+                urn:ogf:network:domain=internet2.edu:node=Los Angeles NOC
+                
urn:ogf:network:domain=internet2.edu:node=*</fo:block></fo: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.3"><fo:block 
id="fields_service"/>3.1.3  Service</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           An identifier for a network-available service MUST include the
+           domain, node and service fields. The node and domain fields MUST 
be
+           identicial to those in the identifier for the node containing the
+           service. The value of the service field can be anything, but MUST
+           be unique in the node and MUST NOT include any trailing spaces. 
The
+           value SHOULD be a human readable description of the service.
+           Setting the value of the node field to '*' connotes the service is
+           unknown. 
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Examples: <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">             
urn:ogf:network:domain=internet2.edu:node=packrat:service=http
+               
urn:ogf:network:domain=internet2.edu:node=packrat:service=perfSONAR%20SNMP%20MA
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=ping
+              </fo:block></fo: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.4"><fo:block 
id="fields_interfaces"/>3.1.4  Interfaces</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">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.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Examples: <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">                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=207.75.164.10
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=*</fo:block></fo: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.5"><fo:block 
id="fields_unilinks"/>3.1.5  Unidirectional Intra-domain/Inter-domain 
Links</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">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. 
</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Examples: <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">                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=Link
+                Between Packrat And Router1
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=*
+                (this) urn:ogf:network:domain=dcn.internet2.edu:*
+                (could be shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </fo:block></fo: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.6"><fo:block id="fields_bidilinks"/>3.1.6  Bidirectional 
Domain Links</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">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. Examples: </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.6"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"> 
urn:ogf:network:domain=internet2.edu:link=Link Between
+                Packrat And Router1 
urn:ogf:network:domain=internet2.edu:link=*
+              </fo:block></fo: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.7"><fo:block 
id="fields_bidiinterlinks"/>3.1.7  Bidirectional Inter-domain 
Links</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">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. 
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Examples: <fo:block space-before=".5em" 
space-after=".5em" id="rfc.figure.u.7"><fo:block font-family="monospace" 
font-size="9pt" background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"> 
urn:ogf:network:link=Link Between Internet2
+                And ESNet 
urn:ogf:network:link=*</fo:block></fo: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.8"><fo:block 
id="fields_intrapath"/>3.1.8  Intra-domain Path</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">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. </fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> Examples: 
<fo:block space-before=".5em" space-after=".5em" 
id="rfc.figure.u.8"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"> 
urn:ogf:network:domain=internet2.edu: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=* </fo:block></fo: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.9"><fo:block id="fields_interpath"/>3.1.9  Inter-domain 
Path</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">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.</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em"> Examples: <fo:block 
space-before=".5em" space-after=".5em" id="rfc.figure.u.9"><fo:block 
font-family="monospace" font-size="9pt" background-color="#dddddd" 
white-space-treatment="preserve" linefeed-treatment="preserve" 
white-space-collapse="false"> urn:ogf:network:path=DRAGON Path From
+                207.75.164.10 to 134.55.209.97 urn:ogf:network:path=*
+              </fo:block></fo: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.10"><fo:block 
id="fields_network"/>3.1.10  Network</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">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.</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">Examples: <fo:block 
space-before=".5em" space-after=".5em" id="rfc.figure.u.10"><fo:block 
font-family="monospace" font-size="9pt" background-color="#dddddd" 
white-space-treatment="preserve" linefeed-treatment="preserve" 
white-space-collapse="false">urn:ogf:network:domain=internet2.edu:network=207.75.164.0%2F24
+                urn:ogf:network:network=207.0.0.0%2F8
+                urn:ogf:network:network=*</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.4"><fo:block id="basic_elements"/>4.  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
+        describe network topologies. </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 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.) </fo:block><fo:block font-weight="bold" 
font-size="12pt" keep-with-next="always" space-before="12pt" 
space-after="6pt" id="rfc.section.4.1"><fo:block 
id="domain"/>4.1  Domain</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+          A domain is a point demarcation used to divide the entities in a
+          topology into administrative groupings according to the
+          administrative domain that controls the entity.
+        </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.1.1"><fo:block id="domain_id"/>4.1.1  id 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            Each domain has an id attribute that contains the
+            fully-qualified identifier for this domain.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.1.2"><fo:block id="domain_idref"/>4.1.2  idRef 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            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 domain. If a domain element has this attribute, it
+            means that this domain element is not the authoritative, it
+            simply contains additional information about the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.1.3"><fo:block id="domain_entities"/>4.1.3  Entities In The 
Domain</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            A domain can have any number of node, link, network and path
+            entities defined immediately underneath it. The entities defined
+            there must all correspond to entities that are in the actual
+            domain. The links that are defined must be bidirectional links.
+            Unidirectional links can only be defined inside of ports.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.2"><fo:block id="node"/>4.2  Node</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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. 
</fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.1"><fo:block id="node_id"/>4.2.1  id 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Each node has an id attribute that contains the
+            fully-qualified identifier for this node. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.2.2"><fo:block 
id="node_idref"/>4.2.2  idRef Attribute</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.3"><fo:block 
id="node_name"/>4.2.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Node elements can contain one or more name elements to describe 
the
+           node. The name element contains a string and can be filled with 
any
+           value that can be used to name the node. This could include the
+           node's hostname, its default ip address or simply a description of
+           the node.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.3.1"><fo:block 
id="node_name_type"/>4.2.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.4"><fo:block 
id="node_role"/>4.2.4  Role</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each node can also include a role element to describe
+            what role this network entity has. The contents of
+           this element are unspecified, but should correspond to the job of
+           the node. If the node is a router, the contents should be 
"router".
+           If the node is an endpoint, the contents should be "endpoint".
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing defined values for the role field are listed in the
+            appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.5"><fo:block 
id="node_address"/>4.2.5  Address</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Each node can have one or more address element to describe the
+           addresses that the outside world can use to contact this node.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client may try to
+            parse the element's contents on its own. However, the
+            parsing of the element is outside the scope of this
+            document.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.6"><fo:block id="node_location"/>4.2.6  Location 
Information</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> 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. </fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em"> 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. </fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           Longitude and latitude information SHOULD be included with each
+           node to ease the drawing of topologies.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.7"><fo:block id="node_contact"/>4.2.7  Contact 
Information</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> 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. 
</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> 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. </fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.4.2.8"><fo:block 
id="node_description"/>4.2.8  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> Each node can 
include a description element. This
+            element should include a human readable description of the
+            node. </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.9"><fo:block 
id="node_comments"/>4.2.9  Comments</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em"> Each node can include one or more 
comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the node. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.2.10"><fo:block 
id="node_relations"/>4.2.10  Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> One or more 
relation elements, which are described
+            later, may be defined inside the node. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.2.11"><fo:block 
id="node_lifetime"/>4.2.11  Lifetime</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            A node has an optional field lifetime that can be used to 
describe
+            the time during which the node had the properties being described
+            or, in the case of ephemeral nodes, the time during which the 
node
+            actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.2.12"><fo:block 
id="node_ports"/>4.2.12  Interfaces</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            One or more port elements, which are described later, may be
+            defined inside the node as well. These port elements must
+            correspond to interfaces inside the node being described. The
+            actual namespaces of the interfaces can consist of any of the
+            namespaces defined in these schema that have a "port" element.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.3">4.3  Links</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+          Nodes are connected by Links, which are edges in the graph
+          model. These Links have properties associated with them.
+        </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.1">4.3.1  id Attribute</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each link has an id attribute that contains the
+            fully-qualified identifier for the link. 
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.2">4.3.2  idRef Attribute</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            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 link. If a link element has this attribute,
+            it means that this link element is not the
+            authoritative link element, it simply contains
+            additional information about the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.3">4.3.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Links elements can contain one or more name elements to describe
+           the link. The name element contains a string and can be filled 
with
+           any value that can be used to name the link. This could include an
+           e2emon style link name, a local name for the link or simply a
+           description of the link.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.3.1"><fo:block 
id="link_name_type"/>4.3.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.4">4.3.4  Global Name</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The globalName element can be used to give a
+            globally-unique name to describe the link. This
+            element contains an attribute describing what type
+            of name this element contains. 
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The types and contents of the element are unspecified as the
+            element is deprecated. Its inclusion in here is due to the
+            prevelance of e2emon services that exist which make use of a
+            globalName field.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.5">4.3.5  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each link can also include a type element to describe the 
protocol
+            of the link.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the link is a
+            virtual link, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define the
+            protocol being used, e.g. ethernet, or could be set to something
+            general like 'layer2' to state generally what kind of protocol is
+            being run over it. If the link is unidirectional, it must have 
the
+            same type as the port it is defined in. If the link is
+            bidirectional, it must have the same type as the two 
undirectional
+            links that underly it.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing type definitions are included in the appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.6">4.3.6  Remote Link Id</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Bidirectional links are made up of two
+            unidirectional links. Each undirectional link may
+            contain a reference to its sibling link using the
+            remoteLinkId element. If included, the remoteLinkId
+            element must contain the fully-qualified identifier for the 
sibling
+            unidirectional link. If the remoteLinkId element is specified in 
an
+            element, the sibling link must have the same type as the link 
being
+            described.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.7">4.3.7  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each link can include a description element. This
+            element should include a human readable description
+            of the link.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.8">4.3.8  Comments</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each link can include one or more comments
+            elements. These elements can be used to add
+            human-readable comments about the link. These
+            should not be used to store necessary information
+            about the link.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.9">4.3.9  Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            One or more relation elements, which are described
+            later, may be defined inside the link.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.9.1">4.3.9.1  Bidirectional Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+              Bidirectional links should include an over relation containing
+              references to the two unidirectional links that make up the
+              bidirectional link.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.3.10"><fo:block 
id="link_lifetime"/>4.3.10  Lifetime</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            A link has an optional field lifetime that can be used to 
describe
+            the time during which the link had the properties being described
+            or, in the case of ephemeral links, the time during which the 
link
+            actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.4"><fo:block id="port"/>4.4  Interfaces</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> Nodes have 
interfaces, which are the attachment points of
+          links. They have properties which are independent of the
+          Node. Interfaces are defined in the schema in port elements. 
</fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.1"><fo:block id="port_id"/>4.4.1  id 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> Each port has an id attribute that contains the
+            fully-qualified identifier for the port. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.4.2"><fo:block 
id="port_idref"/>4.4.2  idRef Attribute</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element. </fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.4.4.3"><fo:block 
id="port_name"/>4.4.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           The port element can have one or more name elements to describe 
the
+           port. The name element contains a string and can be filled with 
any
+           value that can be used to name the port. This could include the
+           name of the interface on the host, the ip address for a layer 3
+           port or a simple description of the port.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.3.1"><fo:block 
id="port_name_type"/>4.4.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.4"><fo:block 
id="port_address"/>4.4.4  Address</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Each port can have one or more address elements to describe the
+           addresses that the outside world can use to contact this port.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client may try to
+            parse the element's contents on its own. However, the
+            parsing of the element is outside the scope of this
+            document.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.5"><fo:block 
id="port_type"/>4.4.5  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each port can also include a type element to describe the 
protocol
+            of the interface.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the port is a
+            virtual port, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define what
+            protocol is being used, e.g. ethernet, or could be set to 
something
+            like 'layer2' to state generally what kind of protocol is being 
run
+            over it.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing type definitions are included in the appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.6"><fo:block 
id="port_capacity"/>4.4.6  Capactity</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            
+            Every interface has a maximum physical bandwidth
+            attainable by it. This value can be influenced by both the
+            physical capacity of the interface's card or the physical
+            capacity of the link plugged in to the card. This element
+            should contain the minimum of those two values. The
+            element to describe this property of the interface is
+            capacity. It contains a string formatted according to the
+            speeds defined by the GMPLS standard.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.7"><fo:block 
id="port_mtu"/>4.4.7  MTU</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Every port element may contain an element, mtu, containing the
+           maximum size an individual segment of data that can be transmitted
+           with this port can contain. If the port were an ethernet port,
+           this would be the configured MTU for the port. If the port were a
+           UDP port, the value would contain the maximum segment size for the
+          port. This field must contain an integer corresponding to the 
number
+          of bytes in the maximum size. If the specified value is "0", this
+          means that the particular interface has no maximum segment size.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.8"><fo:block 
id="port_description"/>4.4.8  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           Each port can include a description element. This
+            element should include a human readable description of the
+            port.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.9"><fo:block 
id="port_comments"/>4.4.9  Comments</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em"> Each port can include one or more 
comments elements.
+            These elements can be used to add human-readable comments
+            about the port. These should not be used to store
+            necessary information about the port. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.4.10"><fo:block 
id="port_relations"/>4.4.10  Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> One or more 
relation elements, which are described
+            later, may be defined inside the port. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.4.11"><fo:block 
id="port_lifetime"/>4.4.11  Lifetime</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            A port has an optional field lifetime that can be used to 
describe
+            the time during which the port had the properties being described
+            or, in the case of ephemeral ports, the time during which the 
port
+            actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.4.12"><fo:block 
id="port_links"/>4.4.12  Links</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            One or more link elements, which are described earlier,
+            may be defined inside the port as well. The only links that can 
be
+            defined inside a port are unidirectional links whose source is 
the
+            port in which they are being defined. The type of the
+            unidirectional link must be the same as the type of the port it's
+            defined in. For example, an ipv4 link cannot be created inside an
+            802.11 port. It must be created inside an ipv4 port.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.5"><fo:block id="service"/>4.5  Service</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+         The service element can be used to describe services. This could
+         include high-level services like web-services or low-level services
+         like a translator between optical wavelengths.
+       </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.1"><fo:block id="service_id"/>4.5.1  id 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+           Each service has an id attribute that contains the
+            fully-qualified identifier for this service.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.2"><fo:block id="service_idref"/>4.5.2  idRef 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+           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 service.  If a
+           service element has this attribute, it means that this service
+           element is not the authoritative, it simply contains additional
+           information about the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.3"><fo:block 
id="service_name"/>4.5.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Service elements can contain one or more name elements to describe
+           the service. The name element contains a string and can be filled
+           with any value that can be used to name the service.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.3.1"><fo:block 
id="service_name_type"/>4.5.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.4"><fo:block 
id="service_description"/>4.5.4  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           Each service can include a description element. This
+            element should include a human readable description of the
+            service.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.5"><fo:block 
id="service_comments"/>4.5.5  Comments</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           Each service can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific service. These should not be used to store
+            necessary information about the service.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.6"><fo:block 
id="service_relations"/>4.5.6  Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           One or more relation elements, which are described
+            later, may be defined inside the service.
+         </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+           If a service is only available on a certain number of interfaces,
+           it should include an 'over' relation containing the set of
+           interfaces that the service is reachable via.
+         </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.5.7"><fo:block 
id="service_lifetime"/>4.5.7  Lifetime</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            A service has an optional field lifetime that can be used to 
describe
+            the time during which the service had the properties being 
described
+            or, in the case of ephemeral services, the time during which the 
service 
+            actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.6"><fo:block id="network"/>4.6  Network</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> A Network is 
essentially a scoping construct. </fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.4.6.1"><fo:block id="network_id"/>4.6.1  id 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            Each network element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.2"><fo:block id="network_idref"/>4.6.2  idRef 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.3"><fo:block 
id="network_name"/>4.6.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           Network elements can contain one or more name elements to describe
+           the network. The name element contains a string and can be filled
+           with any value that can be used to name the network. This could be
+           the subnet for an ipv4 or ipv6 network or a simple description of
+           the network.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.3.1"><fo:block 
id="network_name_type"/>4.6.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.4"><fo:block 
id="network_type"/>4.6.4  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each network element can also include a type element to describe
+            the protocol of the network being described. The contents of this
+            element are unspecified, howerever, there exist a set of 
predefined
+            values that this may contain. For example, "ethernet" if the
+            network were an ethernet network, "tcp" if it were a tcp overlay
+            network. New type defintions should be created in a fashion 
similar
+            to the existing ones, or simply "layer2" for a general layer2
+            network. If a type is specified, every element in the network 
must
+            be connected via the specified protocol.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing type definitions are included in the appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.5"><fo:block 
id="network_description"/>4.6.5  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each network can include a description element. This
+            element should include a human readable description of the
+            network.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.6"><fo:block 
id="network_comments"/>4.6.6  Comments</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each network can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the network. These should not be used to store
+            necessary information about the network.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.7"><fo:block 
id="network_relations"/>4.6.7  Relations</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            One or more relation elements, which are described
+            later, may be defined inside the network.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.8"><fo:block 
id="network_lifetime"/>4.6.8  Lifetime</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            A network has an optional field lifetime that can be used to
+            describe the time during which the network had the properties 
being
+            described or, in the case of ephemeral networks, the time during
+            which the network actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.6.9"><fo:block id="network_children"/>4.6.9  Entities In 
The Network</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The network may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the network. If the type of the network
+            has been set, all the elements in the network must be connected
+            using the specified type.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.7"><fo:block id="path"/>4.7  Path</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> A Path defines a 
discrete path between two topological points. </fo:block><fo:block 
font-weight="bold" font-size="11pt" keep-with-next="always" 
space-before="11pt" space-after="3pt" id="rfc.section.4.7.1"><fo:block 
id="path_id"/>4.7.1  id Attribute</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each path element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.2"><fo:block id="path_idref"/>4.7.2  idRef 
Attribute</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            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 path. If a path element has this attribute, it
+            means that this path element is not the authoritative path
+            element, it simply contains additional information about
+            the element.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.3"><fo:block 
id="path_name"/>4.7.3  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           The path element can contain one or more name elements to describe
+           the path. The name element contains a string and can be filled 
with
+           any value that can be used to name the path. This could be an
+           e2emon style global circuit name, an identifier from a path
+           construction service or simply a description of the path.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.3.1"><fo:block 
id="path_name_type"/>4.7.3.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.4"><fo:block 
id="path_type"/>4.7.4  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each path element can also include a type element to describe
+            the protocol used by the path being defined. The contents of 
this element
+            are unspecified, howerever, there exist a set of predefined 
values
+            that this may contain. For example, "ethernet" if every element 
in
+            that path were ethernet, "tcp" if every step were tcp or simply
+            "layer2" if every step were at layer2. New type defintions should
+            be created in a fashion similar to the existing ones.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing type definitions are included in the appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.5"><fo:block 
id="path_description"/>4.7.5  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each path can include a description element. This
+            element should include a human readable description of the
+            path.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.6"><fo:block 
id="path_comments"/>4.7.6  Comments</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each path can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the path. These should not be used to store
+            necessary information about the path.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.7"><fo:block 
id="path_relations"/>4.7.7  Relations</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            One or more relation elements, which are described
+            later, may be defined inside the path.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.8"><fo:block 
id="path_lifetime"/>4.7.8  Lifetime</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            A path has an optional field lifetime that can be used to
+            describe the time during which the path had the properties being
+            described or, in the case of ephemeral path, the time during
+            which the path actually existed.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.7.9"><fo:block id="path_children"/>4.7.9  Entities In The 
Network</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            The path may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the path. These id references take the
+            form "nodeIdRef", "portIdRef" and "linkIdRef". The contents of 
each
+            them must contain a fully-qualified identifier for a network 
entity of the
+            reference type.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> 
+            If the type of the path
+            has been set, all the elements in the path must be connected
+            using the specified type.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.4.8"><fo:block id="epp"/>4.8  Endpoint 
Pairs</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+          Conceptually, endpoint pairs could be provided by creating two port
+          elements and a link element. The two ports and a link element is 
the
+          preferred method for creation of these kinds of entities. However,
+          due to the common appearance of these concepts in network
+          measurements, the endpoint pair is provided as a shorthand for the
+          link/port construct in measurement requests. These elements must 
not
+          be returned as part of a description of physical topology.
+        </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.1"><fo:block 
id="epp_name"/>4.8.1  Name</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+           End-point pairs elements can contain one or more name elements to
+           describe the endpoint pair. The name element contains a string and
+           can be filled with any value that can be used to name the pair.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.1.1"><fo:block 
id="epp_name_type"/>4.8.1.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              
+              Existing type definitions are included in the appendix.
+            </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or try to parse the element's contents 
on
+              its own. However, the parsing of the element is outside the 
scope
+              of this document.
+            </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.2"><fo:block 
id="epp_type"/>4.8.2  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each epp element can also include a type element to describe
+            the protocol used by the endpoints for communication. The 
contents
+            of this element are unspecified, howerever, there exist a set of
+            predefined values that this may contain. For example, "ethernet" 
if
+            the endpoints communicated via "ethernet", "tcp" if they
+            communicate via tcp or simply "layer2" if they communicate via 
some
+            layer2 protocol.  New type defintions should be created in a
+            fashion similar to the existing ones.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            
+            Existing type definitions are included in the appendix.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.3"><fo:block 
id="epp_description"/>4.8.3  Description</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            Each endpoint pair can include a description element. This
+            element should include a human readable description of the
+            pair.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.4"><fo:block 
id="epp_comments"/>4.8.4  Comments</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            Each endpoint pair can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the pair.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.5"><fo:block 
id="epp_src"/>4.8.5  Source</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The source for an endpoint pair is described using a src element.
+            This element can consist of the set of elements in a port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the source endpoint.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.4.8.6"><fo:block 
id="epp_dst"/>4.8.6  Destination</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The destination for an endpoint pair is described using a dst
+            element.  This element can consist of the set of elements in a 
port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the destination endpoint.
+          </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.  Layer 2 Elements</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+        
 
+        If the network entity being describing is layer 2, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 2 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.5.1">5.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+          The type in layer 2 elements, if included, must be the link layer
+          protocol of that element. For example, an ethernet link would have
+          type "ethernet".
+        </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.5.2">5.2  Port</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.5.2.1">5.2.1  Address</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The address element in layer 2 ports must consist of the layer 2 
address
+            for the port.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.5.2.2">5.2.2  ifName</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The layer 2 namespace adds a new element, ifName, that can be 
used to
+            specify the SNMP name of the interface. The ifName element 
contains a
+            string representation of the port's ifName.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.5.2.3">5.2.3  ifIndex</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The layer 2 namespace adds a new element, ifIndex, that can be 
used to
+            specify the SNMP index of the interface. The ifIndex field must 
be
+            filled in with the integer SNMP index for the interface.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.5.2.4">5.2.4  Vlan Tag</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified port. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that port.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.5.2.5">5.2.5  Vlan Range Availability</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+           The layer 2 namespace adds an element, vlanRangeAvailability, that
+           can be used to specify which tags are still available for use to
+           create new vlans on the specified port. The element must contain a
+           string containing a comma-separated list of vlan tag identifiers.
+           Ranges of tags can be specified by listing two vlan tags separated
+           by a "-".
+         </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.5.3">5.3  Link</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.5.3.1">5.3.1  Vlan Tag</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified link. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that link. 
If the
+            vlan tag is specified for the port associated with this link, 
this
+            value must be the same as the one in the port.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.5.4">5.4  Network</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.5.4.1">5.4.1  Vlan Tag</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified network. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that 
network. If
+            the vlan tag is specified, all the elements referenced by the 
network
+            need to have the same vlan tag. 
+          </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.  Layer 3 Elements</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+        
 
+        If the network entity being describing is layer 3, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 3 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.6.1">6.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+          The type in layer 3 elements, if included, must be the network 
layer
+          protocol of that element. For example, an ipv4 network would have
+          type "ipv4".
+        </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.6.2">6.2  Port</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.6.2.1">6.2.1  Name</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The name for the layer 3 element should be the layer 3 address 
for that
+            element. The type attribute must be specified.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.6.2.2">6.2.2  Address</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The address element in layer 3 ports must consist of the layer 3 
address
+            for the port.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.6.2.3">6.2.3  Netmask</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The layer 3 port has an optional element netmask. This element 
is a
+            string that containing the netmask for the address. If the 
address
+            type is ipv4, the contents must consist of a netmask in
+            dotted-decimal form. If the address type is ipv6, the contents 
must
+            consist of an ipv6 netmask in colon-separated hexadecimal 
format. If
+            the address type is any other value, the contents of the netmask 
are
+            unspecified.
+          </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.6.3">6.3  Network</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.6.3.1">6.3.1  Subnet</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The layer 3 network element may contain a subnet element to 
describe the
+            range of addresses contained in the network. This element must 
contain
+            a layer 3 address element and a netmask element. The layer 3 
address
+            element may contain any address in the range contained in the 
network.
+            The contents of the netmask element depend on the type of the 
address.
+            If the address type is ipv4, the netmask element must contain a 
netmask
+            in dotted-decimal form. If the address type is ipv6, the netmask
+            element must contain a number corresponding to the ipv6 netmask.
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.6.3.2">6.3.2  ASN</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The layer 3 network element may contain an ASN element to 
specify which
+            autonomous system the network is describing. The element must 
contain
+            the autonomous system number as an integer.
+          </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.  Layer 4 Elements</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+        
+
+        If the network entity being describing is layer 4, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 4 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.7.1">7.1  Type</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+          The type in layer 4 elements, if included, must be the transport
+          layer protocol of that element.  For example, a tcp overlap network
+          would have type "tcp".
+        </fo:block><fo:block font-weight="bold" font-size="12pt" 
keep-with-next="always" space-before="12pt" space-after="6pt" 
id="rfc.section.7.2">7.2  Port</fo:block><fo:block font-weight="bold" 
font-size="11pt" keep-with-next="always" space-before="11pt" 
space-after="3pt" id="rfc.section.7.2.1">7.2.1  Name</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The name element in layer 4 ports may use the type "port". If 
so, the
+            element must contain the number for that port. If a layer4 
element name
+            has no "type" specified, the format of the element should be of 
the form
+            "protocol:port". For example, a tcp service listening on port 80 
would be
+            described as "tcp:80".
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.7.2.2">7.2.2  Address</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">
+            The format of the address element differs in a layer 4 port. If 
no
+            type is specified, the address must be of the form "ip:port". 
The ip
+            corresponds to the underlying layer3 address. If the underlying 
address
+            is an ipv6 address, the convention is "[ip]:port". In this 
context, the
+            ip must be the same as the interface underlying the layer 4 port.
+          </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+            Another possible form can be used if the type is set to "url" 
which means
+            that the element is formatted as a URL. In this case, the format 
of the
+            element must be of the form "protocol://layer3 address:port". If 
the
+            layer 3 address if of type ipv6, the format of the url must be 
of the
+            form "protocol://[ipv6 address]:port". 
+          </fo:block><fo:block font-weight="bold" font-size="11pt" 
keep-with-next="always" space-before="11pt" space-after="3pt" 
id="rfc.section.7.2.3">7.2.3  Port Number</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+            The layer 4 port has a required element portNum. This element 
consists
+            of an integer that contains the port number that the protocol is
+            listening on.
+          </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.  Control Plane 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.9"><fo:block 
id="xml_namespace"/>9.  XML Namespaces</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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. </fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">This version of the schema includes 
layers subdivided by the
+        layer of the OSI protocol model. </fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em">
+        All namespaces contain the elements defined in the base namespace.
+       The elements in each subnamespace contain all the elements and
+       properties defined previously. Each namespace may redefine the meaning
+       of elements or add new elements. However, it may not remove any
+       elements that were previously defined.
+      </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+       When released, each version of a namespace must specify the versions 
of
+       their parent namespaces. If a new version of a parent namespace comes
+       out, the version of the child namespace MUST be incremented to add any
+       new elements or properties added in the parent namespace.
+      </fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em">
+        Example Namespaces:
+       Base: http://ogf.org/schema/network/topology/base/20070707/
+       Layer 2: http://ogf.org/schema/network/topology/l2/20070707/
+       Ethernet: http://ogf.org/schema/network/topology/l2/ethernet/20070707/
+      </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="versioning"/>10.  Versioning</fo:block><fo:block space-before=".5em" 
space-after=".5em" start-indent="2em">Completely lifted from NM doc.. the 
issues are the same.
+        maybe we just reference</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.11"><fo:block 
id="relationships"/>11.  Relationships Among Elements</fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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. </fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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. 
</fo:block><fo:block space-before=".5em" space-after=".5em" 
start-indent="2em"> 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 underneath 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 fully-qualified 
identifiers
+        for the unidirectional links that make it up. </fo:block><fo:block 
space-before=".5em" space-after=".5em" start-indent="2em"> 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. </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="topo_base_schema"/>12.  Base Topology 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.11"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
+#
+# File:    nmtopo_base.rnc - Schema to describe network elements
+# Version: $Id: nmtopo_base.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
+
+# ##############################################################
 # Namespace definitions
 # ##############################################################
-namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
+ default namespace nmtb =
+   "http://ogf.org/schema/network/topology/base/20070707/";
 
+# External schema files
+ include "nmtypes.rnc"
 
-# ##############################################################
-# Include additional functionality from other files
-# ##############################################################
-include "nmtime.rnc"
-include "filter.rnc"
+# generic Topology can be a root element
+ start |= Topology
 
-# ##############################################################
-# Every NMWG document should begin with either a 'store' or 
-# 'message' element
-# Patterns are defined for the content of each element.
-# 
-# Example (using message):
-# 
-# &lt;nmwg:message id="OPTIONAL_ID" 
-#               messageIdRef="OPTIONAL_REFERENCE_ID"
-#               type="REQUIRED_TYPE"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL PARAMETERS --&gt;
-#
-#   &lt;!-- OPTIONAL (MULTIPLE) METADATA --&gt;
-# 
-#   &lt;!-- OPTIONAL (MULTIPLE) DATA --&gt;
-#  
-# &lt;/nmwg:message&gt;
-# 
-# ##############################################################
+ Topology = element topology {
+     Domain*
+     &amp; BaseNode*
+     &amp; BaseLink*
+     &amp; BasePort*
+     &amp; BaseNetwork*
+     &amp; BasePath*
+   }
 
-start =
-        (
-                element nmwg:message {
-                        MessageContent
-                } |
-                element nmwg:store {
-                        StoreContent
-                }
-        )
+ Domain = element domain {
+     Identifier?
+     &amp; IdReference?
+     &amp; BaseNode*
+     &amp; BaseLink*
+     &amp; BaseNetwork*
+     &amp; BasePath*
+   }
 
-MessageContent =
-        Identifier? &amp; 
-        MessageIdentifierRef? &amp;
-        Type &amp;
-        Parameters? &amp;                        
-        (
-                Metadata |  
-                Data
-        )+
-        
-        
-StoreContent = 
-        Identifier? &amp; 
-        MessageIdentifierRef? &amp;
-        Type &amp;
-        Parameters? &amp;                        
-        (
-                Metadata |  
-                Data
-        )+        
+## ########################
+## generic node
+## ########################
+ BaseNode = element node { BaseNodeContent }
+ BaseNodeContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element role { xsd:string }?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element location { LocationContent }?
+   &amp; element contact { ContactInformationContent }*
+   &amp; element comments { xsd:string }*
+   &amp; BasePort*
+   &amp; BaseService*
 
+ ContactInformationContent =
+   attribute priority { xsd:integer }?
+   &amp; element email { xsd:string }?
+   &amp; element phoneNumber { xsd:string }?
+   &amp; element administrator { xsd:string }?
+   &amp; element institution { xsd:string }?
 
-# ##############################################################
-# Metadata is the information that describes data.  This
-# information doesn't change over time
+ LocationContent =
+   element continent { xsd:string }?
+   &amp; element country { xsd:string }?
+   &amp; element zipcode { xsd:integer }?
+   &amp; element state { xsd:string }?
+   &amp; element institution { xsd:string }?
+   &amp; element city { xsd:string }?
+   &amp; element streetAddress { xsd:string }?
+   &amp; element floor { xsd:string }?
+   &amp; element room { xsd:string }?
+   &amp; element cage { xsd:string }?
+   &amp; element rack { xsd:string }?
+   &amp; element shelf { xsd:string }?
+   &amp; element latitude { xsd:float }?
+   &amp; element longitude { xsd:float }?
+
+## ########################
+## generic port
+## ########################
+ BasePort = element port { BasePortContent }
+ BasePortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; BaseLink*
+
+## ########################
+## generic link
+## ########################
+ BaseLink = element link { BaseLinkContent }
+ BaseLinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## generic network
+## ########################
+ BaseNetwork = element network { BaseNetworkContent }
+ BaseNetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## generic path
+## ########################
+ BasePath =
+   element path { BasePathContent }
+
+# a path consists of a list of hops
+ BasePathContent =
+   Identifier
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element comments { xsd:string }*
+   &amp; element hop { HopContent }*
+
+ HopContent =
+   Identifier,
+   (
+     DomainIdRef
+     | NodeIdRef
+     | PortIdRef
+     | LinkIdRef
+     | PathIdRef
+     | NetworkIdRef
+   )
+
+## ########################
+## generic endpoint pair
+## ########################
+ BaseEndPointPair =
+   element endPointPair { BaseEndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ BaseEndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (BasePortContent | PortIdRef) }
+   &amp; element dst { (BasePortContent | PortIdRef) }
+
+## ########################
+## generic service
+## ########################
+ BaseService =
+   element service { BaseServiceContent }
+
+ BaseServiceContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; Relation*
+   &amp; Lifetime?
+                        </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"><fo:block id="topo_l2_schema"/>13.  Layer 2 Topology 
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.12"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 #
+# File:    nmtopo_l2.rnc - Schema to describe L2 network elements
+# Version: $Id: nmtopo_l2.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# &lt;nmwg:metadata id="REQUIRED_ID" 
-#                metadataIdRef="OPTIONAL_REFERENCE_ID"
-#                xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TBD OPTIONAL SUBJECT --&gt;
-# 
-#   &lt;!-- TBD OPTIONAL PARAMETERS --&gt;
-#
-#   &lt;!-- TBD OPTIONAL EVENTTYPE --&gt;
-# 
-#   &lt;!-- TBD OPTIONAL KEY --&gt;
-#  
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt; 
-#
-# &lt;/nmwg:metadata&gt;
-# 
 # ##############################################################
-        
-Metadata = 
-        element nmwg:metadata {
-                (
-                        Identifier &amp;
-                        MetadataIdentifierRef? &amp;
-                        MetadataContent
-                ),
-                anyElement*
-        }
 
-MetadataBlock =
-        Subject? &amp;
-        Parameters?
-        
-MetadataContent = 
-        (
-                MetadataBlock |
-                FilterMetadataBlock                
-        ) &amp;        
-        EventType? &amp;
-        Key?        
-
-
 # ##############################################################
-# Subject identifies an endPoint (or points), perhaps the name of
-# a service or some other form of physical location. For the
-# purpose of the general case, we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.  
-#
-# Example: 
-# 
-# &lt;nmwg:subject id="REQUIRED_ID" 
-#               metadataIdRef="OPTIONAL_REFERENCE_ID"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- ANY ELEMENT IN ANY NAMESPACE --&gt;
-#  
-# &lt;/nmwg:subject&gt;
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl2 =
+           "http://ogf.org/schema/network/topology/l2/20070707/";
 
-Subject = 
-        element nmwg:subject {
-                SubjectContent
-        }
+# External schema files
+ include "nmtypes.rnc"
 
-SubjectContent = 
-        (
-                Identifier &amp;
-                MetadataIdentifierRef?        
-        ),
-        anyElement*
-        
+## ########################
+## layer 2 port
+## ########################
+ L2Port = element port { L2PortContent }
+ L2PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element ifName {xsd:string }?
+   &amp; element ifIndex {xsd:integer }?
+   &amp; element vlan {xsd:integer }?
+   &amp; element vlanRangeAvailability { xsd:string }
+   &amp; L2Link*
 
-# ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways in: 1) the message to signify items such as time stamp
-# or authorization or 2) metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id and encloses one to many 'parameter' elements.
-# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please;
-# software using this should consider complex elements, then
-# text, and finally the value attribute; exceptions should
-# be thrown on duplicates).
+## ########################
+## layer 2 link
+## ########################
+ L2Link = element link { L2LinkContent }
+ L2LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+   &amp; element vlan {xsd:integer }?
+
+## ########################
+## layer 2 network
+## ########################
+ L2Network = element network { L2NetworkContent }
+ L2NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element vlan {xsd:integer }?
+
+## ########################
+## layer 2 endpoint pair
+## ########################
+ L2EndPointPair =
+   element endPointPair { L2EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L2EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L2PortContent | PortIdRef | Address) }
+   &amp; element dst { (L2PortContent | PortIdRef | Address) }
+                        </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.14"><fo:block id="topo_l3_schema"/>14.  Layer 3 Topology 
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.13"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 #
-# Example: 
-# 
-# &lt;nmwg:parameters id="REQUIRED_ID" 
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;nmwg:parameter name="REQUIRED_NAME" value="OPTIONAL_VALUE"
-#                   xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#     &lt;!-- ANY TEXT, OR ANY ELEMENT ANY NAMESPACE (IF YOU DID NOT 
-#          USE THE VALUE ATTRIBUTE) --&gt;
-# 
-#   &lt;/nmwg:parameter&gt;
-#  
-#   &lt;!-- MORE PARAMETERS --&gt;
-#   
-# &lt;/nmwg:parameters&gt;
-# 
-# The namespaces can of course be different.
-# 
+# File:    nmtopo_l3.rnc - Schema to describe L3 network elements
+# Version: $Id: nmtopo_l3.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
 
-Parameters = 
-        element nmwg:parameters {
-                ParametersContent
-        }
-   
-ParametersContent =    
-        Identifier &amp;
-        Parameter+
-   
-Parameter = 
-        element nmwg:parameter { 
-                attribute name { xsd:string } &amp;
-                (
-                        attribute value { xsd:string } |
-                        (
-                                anyElement |
-                                text
-                        )
-                )
-        }   
+# ##############################################################
+# Namespace definitions
+# ##############################################################
+ default namespace nmtl3 =
+           "http://ogf.org/schema/network/topology/l3/20070707/";
 
+# External schema files
+ include "nmtypes.rnc"
 
-# ##############################################################
-# Event type is a simple text element used to describe the
-# characteristic or event of the data.
-#
-# Example: 
-# 
-# &lt;nmwg:eventType xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TEXT --&gt;
-#  
-# &lt;/nmwg:eventType&gt;
-# 
-# ##############################################################        
+## ########################
+## layer 3 port
+## ########################
+ L3Port = element port { L3PortContent }
+ L3PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element netmask { xsd:string }?
+   &amp; L3Link*
 
-EventType =
-        element nmwg:eventType { xsd:string }      
+## ########################
+## layer 3 link
+## ########################
+ L3Link = element link { L3LinkContent }
+ L3LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+   &amp; element netmask { xsd:string }?
 
-   
-# ##############################################################
-# The key is used to return a 'pointer' or otherwise special piece
-# of identifying information in response to a request. For now, 
-# this information is enclosed only within a parameters block.
-# The optional ID can be used to track past searches.
+## ########################
+## layer 3 network
+## ########################
+ L3Network = element network { L3NetworkContent }
+ L3NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element subnet {
+        Address
+        &amp; element netmask { xsd:string }
+     }?
+   &amp; element asn { xsd:integer }
+
+## ########################
+## layer 3 endpoint pair
+## ########################
+ L3EndPointPair =
+   element endPointPair { L3EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L3EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L3PortContent | PortIdRef | Address) }
+   &amp; element dst { (L3PortContent | PortIdRef | Address) }
+                        </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.15"><fo:block id="topo_l4_schema"/>15.  Layer 4 Topology 
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.14"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 #
-# Example: 
-# 
-# &lt;nmwg:key id="OPTIONAL_ID" 
-#           xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL PARAMETERS --&gt;
-#  
-# &lt;/nmwg:key&gt;
-# 
-# ##############################################################
-   
-Key = 
-        element nmwg:key {
-                Identifier? &amp;
-                (
-                        Parameters |
-                        FilterParameters                                
-                )
-        }        
-        
-           
-# ##############################################################
-# The data block is complex and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet. 
+# File:    nmtopo_l4.rnc - Schema to describe L4 network elements
+# Version: $Id: nmtopo_l4.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# &lt;nmwg:data id="REQUIRED_ID" 
-#            metadataIdRef="OPTIONAL_REFERENCE_ID" 
-#            xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL (MULTIPLE) METADATA --&gt;
-# 
-#           &lt;!-- OR --&gt;
-#
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND 
-#        OPTIONAL (MULTIPLE) DATUM ELEMENTS--&gt;
-# 
-#           &lt;!-- OR --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS --&gt;
-# 
-#           &lt;!-- OR --&gt;
-#  
-#   &lt;!-- OPTIONAL (MULTIPLE) KEY ELEMENTS --&gt;
-# 
-#           &lt;!-- OR --&gt;
-# 
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt;
-#   
-# &lt;/nmwg:data&gt;
-# 
 # ##############################################################
-   
-Data =
-        element nmwg:data {
-                (
-                        Identifier &amp;
-                        MetadataIdentifierRef? &amp;
-                        (
-                                Metadata* |
-                                (
-                                        commonTime+ &amp; 
-                                        Datum*
-                                ) |
-                                Datum* |
-                                Key*
-                        )
-                ),
-                anyElement*
-        }
 
 # ##############################################################
-# CommonTime is used as a shortcut that is able to 'factor out' 
-# a frequently occurring time range that a group of datum (or 
-# other) elements might share, thus reducing the verbosity of the 
-# XML representation. CommonTime is similar to the other NMWG time 
-# stamps (from nmtime.rnc) in its potential time representations.
-#
-# It is unfortunate that it needs to be in this file and not
-# nmtime.rnc, but as it occurs outside the datum, it is here.
-#
-# Example: 
-# 
-# &lt;nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
-#                  duration="OPTIONAL_DURATION" 
-#                  inclusive="OPTIONAL_INCLUSIVE_FLAG"
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR
-#         DURATION) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE
-#         ATTRIBUTE) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS --&gt;
-# 
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt;
-# &lt;/nmwg:commonTime&gt;
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl4 =
+           "http://ogf.org/schema/network/topology/l4/20070707/";
 
-commonTime = 
-        element nmwg:commonTime {
-                (
-                        Type &amp;
-                        (
-                                TimeStamp |
-                                (
-                                        StartTime &amp; 
-                                        (
-                                                EndTime | 
-                                                Duration 
-                                        )
-                                )
-                        ) &amp;
-                        Datum*
-                ),
-                anyElement*
-        }
+# External schema files
+ include "nmtypes.rnc"
 
+## ########################
+## layer 4 port
+## ########################
+ L4Port = element port { L4PortContent }
+ L4PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element portNum { xsd:integer }?
+   &amp; L4Link*
 
-# ##############################################################
-# The datum is meant to be generic in this case because specific
-# namespace declarations should be used to better define what
-# format that datum should have.
-#
-# Example: 
+## ########################
+## layer 4 link
+## ########################
+ L4Link = element link { L4LinkContent }
+ L4LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## layer 4 network
+## ########################
+ L4Network = element network { L4NetworkContent }
+ L4NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## layer 4 endpoint pair
+## ########################
+ L4EndPointPair =
+   element endPointPair { L4EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L4EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L4PortContent | PortIdRef | Address) }
+   &amp; element dst { (L4PortContent | PortIdRef | Address) }
+                        </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.16"><fo:block id="topo_ctrlplane_schema"/>16.  Control Plane 
Topology 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.15"><fo:block font-family="monospace" font-size="9pt" 
background-color="#dddddd" white-space-treatment="preserve" 
linefeed-treatment="preserve" white-space-collapse="false"># 
##############################################################
 # 
-# &lt;nmwg:datum ANY_ATTRIBUTE
-#             xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
+# File:        nmtopo_ctrlplane.rnc
+# Version: $Id: nmtopo_ctrlplane.rnc 267 2007-09-14 17:56:01Z swany $
 # 
-#   &lt;!-- ANY ELEMENT IN ANY NAMESPACE OR ANY TEXT --&gt;
-#  
-# &lt;/nmwg:datum&gt;
-# 
 # ##############################################################
 
-Datum =
-        element nmwg:datum {
-                anyThing  
-        }
-        
-         
-# ##############################################################
-# Common elements are defined as named patterns as they are re- 
-# used several times.
-# ##############################################################
-                
-Identifier =
-        attribute id { xsd:string }
+namespace CtrlPlane =
+  "http://ogf.org/schema/network/topology/ctrlPlane/20070707/";
+namespace nmtl3 =
+  "http://ogf.org/schema/network/topology/l3/20070707/";
 
-MetadataIdentifierRef =
-        attribute metadataIdRef { xsd:string }
+include "nmtopo_l3.rnc"
 
-MessageIdentifierRef =
-        attribute messageIdRef { xsd:string }
-    
-Type = 
-        attribute type { xsd:string }    
+## Definition of the topology element
+start |= element CtrlPlane:topology { CtrlPlaneTopologyContent }
 
 
-# ##############################################################
-# This sequence allows any element, attribute, or text (regardless 
-# of name or namespace) into the document when invoked.
-# ##############################################################
+CtrlPlaneTopologyContent =
+  Identifier,
+ # Parameters,
+  element CtrlPlane:idcId { xsd:string }?,
+  (
+    CtrlPlaneDomain |
+    element CtrlPlane:domainSignature {
+      CtrlPlaneDomainSignatureContent
+    }
+  )*
 
-anyElement = 
-        element * { 
-                anyThing 
-        }
+## this a placeholder until we discuss and experiment with signatures
+CtrlPlaneDomainSignatureContent =
+  attribute domainId { xsd:string },
+  anyElement
+  
+CtrlPlaneDomain =
+  element CtrlPlane:domain {
+    Identifier,
+    ( 
+      CtrlPlaneNode*
+      &amp; CtrlPlanePort*
+      &amp; CtrlPlaneLink*
+    )
+  }
+  
+CtrlPlaneNode =
+  element CtrlPlane:node {
+    Identifier,
+    element CtrlPlane:address { xsd:string | L3Address }?,
+    CtrlPlanePort*
+  }
+  
+CtrlPlanePort =
+  element CtrlPlane:port {
+    Identifier,
+    CtrlPlaneCapacityContent,
+    CtrlPlaneLink*
+  }
+  
+CtrlPlaneLink =
+  element CtrlPlane:link {
+    Identifier,
+    ( 
+      element CtrlPlane:remoteLinkId { L3Address }
+      &amp; element CtrlPlane:remotePortId { L3Address }
+      &amp; 
+      ## only use when remotePortId isn't fully qualified
+        element CtrlPlane:remoteNodeId { L3Address }
+      &amp; element CtrlPlane:remoteDomainId { L3Address }
+      &amp; element CtrlPlane:trafficEngineeringMetric { xsd:string }
+      &amp; element CtrlPlane:linkProtectionTypes { xsd:string }*
+      &amp; CtrlPlaneCapacityContent
+      &amp; element CtrlPlane:administrativeGroups {
+        CtrlPlaneAdministrativeGroup
+      }*
+      &amp; element CtrlPlane:SwitchingCapabilityDescriptors {
+        CtrlPlaneSwitchingCapabilityDescriptor+
+      }
+    )
+  }
+  
+# Begin path and endpoint additions
+CtrlPlanePath =
+  element CtrlPlane:path { CtrlPlanePathContent }
 
-anyAttribute = 
-        attribute * { text }
+# a path consists of a list of hops, and/or links
+CtrlPlanePathContent =
+  Identifier &amp;
+    element CtrlPlane:hop { CtrlPlaneHopContent }*
 
-anyThing = 
-        ( 
-                anyElement | 
-                anyAttribute | 
-                text 
-        )*
-        
-        
-# ##############################################################
-# This sequence allows any element, attribute, or text (only in the 
-# NMWG namespace) into the document when invoked.
-# ##############################################################
-        
-anyNMWGElement = 
-        element nmwg:* { 
-                anyNMWGThing 
-        }
+  
+CtrlPlaneHopContent =
+  Identifier,
+  ( 
+    DomainIdRef |
+    NodeIdRef |
+    PortIdRef |
+    LinkIdRef
+  )
+  
+# End path and endpoint
 
-anyNMWGAttribute = 
-        attribute * { text }
+CtrlPlaneAdministrativeGroup =
+  element CtrlPlane:group { xsd:int }
+  &amp; element CtrlPlane:groupID { xsd:string }?
+  
+CtrlPlaneSwitchingCapabilityDescriptor =
+  element switchingcapType {
+    "psc-1"
+    | "psc-2"
+    | "psc-3"
+    | "psc-4"
+    | "l2sc"
+    | "tdm"
+    | "lsc"
+    | "fsc"
+  }
+  &amp; element encodingType {
+      "packet"
+      | "ethernet"
+      | "pdh"
+      | "sdh/sonet"
+      | "digital wrapper"
+      | "lambda"
+      | "fiber"
+      | "fiberchannel"
+      | xsd:string
+    }
+  &amp; element switchingCapabilitySpecficInfo {
+      CtrlPlaneSwitchingCapabilitySpecficInfo
+    }+
+    
+CtrlPlaneSwitchingCapabilitySpecficInfo =
+  CtrlPlaneSwitchingCapabilitySpecficInfo_psc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_tdm
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_lsc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_fsc
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_psc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_tdm =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_lsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_fsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc =
+  element interfaceMTU { xsd:int }
+  &amp; element vlanRangeAvailability { xsd:string }
 
-anyNMWGThing = 
-        ( 
-                anyNMWGElement | 
-                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.8">8.  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-before="0pt" space-after="7pt" id="rfc.references" 
page-break-before="always">9  
-        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">
+## Capacity Description Pattern  
+CtrlPlaneCapacityContent =
+  element CtrlPlane:capacity { xsd:string }?
+  &amp; element CtrlPlane:maximumReservableCapacity { xsd:string }?
+  &amp; element CtrlPlane:minimumReservableCapacity { xsd:string }?
+  &amp; element CtrlPlane:granularity { xsd:string }?
+  &amp; element CtrlPlane:unreservedCapacity { xsd:string }?
+                          </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.17">17.  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-before="0pt" space-after="7pt" 
id="rfc.references" page-break-before="always">18  
+        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 (2007). 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

Modified: trunk/nmwg/doc/nm-topo/nm-topo.html
===================================================================
--- trunk/nmwg/doc/nm-topo/nm-topo.html 2008-05-20 15:55:47 UTC (rev 347)
+++ trunk/nmwg/doc/nm-topo/nm-topo.html 2008-05-20 16:05:26 UTC (rev 348)
@@ -1,8 +1,6 @@
 <!DOCTYPE html
   PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; 
charset=iso-8859-1"><title>
-       An Extensible Schema for Network Topology
-  </title><style type="text/css" title="Xml2Rfc (sans serif)">
+<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; 
charset=iso-8859-1"><title> An Extensible Schema for Network Topology 
</title><style type="text/css" title="Xml2Rfc (sans serif)">
 a {
   text-decoration: none;
 }
@@ -264,12 +262,10 @@
        content: "RFC "; 
   } 
   @top-right {
-       content: "May 2007"; 
+       content: "September 2007"; 
   } 
   @top-center {
-       content: "
-       An Extensible Schema for Network Topology
-  "; 
+       content: " An Extensible Schema for Network Topology "; 
   } 
   @bottom-left {
        content: "Swany"; 
@@ -293,456 +289,663 @@
       content: normal;
     }
 }
-</style><link rel="Author" href="#rfc.authors"><link rel="Copyright" 
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" 
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy" 
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements" 
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces" 
href="#rfc.section.4"><link rel="Chapter" title="5 Versioning" 
href="#rfc.section.5"><link rel="Chapter" title="6 Relationships Among 
Elements" href="#rfc.section.6"><link rel="Chapter" title="7 Base Schema" 
href="#rfc.section.7"><link rel="Chapter" title="8 Security Concerns" 
href="#rfc.section.8"><link rel="Chapter" href="#rfc.section.9" title="9 
References"><meta name="generator" 
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291, 
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica 
http://www.saxonica.com/";><link rel="schema.DC" 
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator" 
content="Swany, M"><met
 a name="DC.Date.Issued" scheme="ISO8601" 
content="2007-05"></head><body><table summary="header information" 
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td 
class="front left">Network Measurement Working Group</td><td class="front 
right">M Swany, Editor</td></tr><tr><td class="front left"></td><td 
class="front right">UDel</td></tr><tr><td class="front left">Intended status: 
Informational</td><td class="front right">May 2007</td></tr></table><p 
class="title">An Extensible Schema for Network Topology</p><h1><a 
id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This memo 
provides information for the Grid community. It does not specify any 
standards or technical recommendations. Distribution is unlimited.</p><h1><a 
id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright 
Notice</a></h1><p>Copyright � The Open Grid Forum (2007). All Rights 
Reserved.</p><hr class="noprint"><h1 id="rfc.section.1" class="np"><a 
href="#rfc.section.1">1.</a>&nbsp;
 <a id="intro" href="#intro">Introduction</a></h1><p id="rfc.!
 section.
1.p.1">This document presents an extensible encoding standard for network 
topology based on the NM performance data schema.</p><h2 
id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Goals</h2><p 
id="rfc.section.1.1.p.1">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.</p><hr class="noprint"><h1 
id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Design 
Philosophy</h1><p id="rfc.section.2.p.1">Reuse the namespace thing from 
NM.</p><hr class="noprint"><h1 id="rfc.section.3" class="np"><a 
href="#rfc.section.3">3.</a>&nbsp;Basic Elements</h1
 ><p id="rfc.section.3.p.1">This schema defines the basic elements that can 
 >be used to describe network topologies.</p><p id="rfc.section.3.p.2"> 
 ></p><h2 id="rfc.section.3.1"><a 
 >href="#rfc.section.3.1">3.1</a>&nbsp;Node</h2><p 
 >id="rfc.section.3.1.p.1">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".</p><h2 id="rfc.section.3.2"><a 
 >href="#rfc.section.3.2">3.2</a>&nbsp;Links</h2><p 
 >id="rfc.section.3.2.p.1">Nodes are connected by Links, which are edges in 
 >the graph model. These Links have properties associated with them.</p><h2 
 >id="rfc.section.3.3"><a 
 >href="#rfc.section.3.3">3.3</a>&nbsp;Interface</h2><p 
 >id="rfc.section.3.3.p.1">Nodes have interfaces, which are the attachment 
 >points of links. They have properties which are independent of the 
 >Node.</p><h2 id="rfc.section.3.4"><a 
 >href="#rfc.section.3.4">3.4</a>&nbsp;Network</h2><p 
 >id="rfc.section.3.4.p.1">A Network is essentially a s
 coping construct.</p><hr class="noprint"><h1 id="rfc.section!
 .4" clas
s="np"><a href="#rfc.section.4">4.</a>&nbsp;XML Namespaces</h1><p 
id="rfc.section.4.p.1">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.</p><p id="rfc.section.4.p.2">This version of 
the schema includes layers subdivided by the layer of the OSI protocol 
model.</p><hr class="noprint"><h1 id="rfc.section.5" class="np"><a 
href="#rfc.section.5">5.</a>&nbsp;Versioning</h1><p 
id="rfc.section.5.p.1">Completely lifted from NM doc.. the issues are the 
same. maybe we just reference</p><p id="rfc.section.5.p.2">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 repre
 sent them, may change. For this reason, each of the schema areas must have a 
version number.</p><p id="rfc.section.5.p.3">To accomplish this, each of the 
URIs that comprise the namespaces end in a version number. TBD, conforming to 
recent GFD on namespaces.</p><hr class="noprint"><h1 id="rfc.section.6" 
class="np"><a href="#rfc.section.6">6.</a>&nbsp;Relationships Among 
Elements</h1><hr class="noprint"><h1 id="rfc.section.7" class="np"><a 
href="#rfc.section.7">7.</a>&nbsp;Base Schema</h1><p id="rfc.section.7.p.1"> 
<pre>
+</style><link rel="Author" href="#rfc.authors"><link rel="Copyright" 
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" 
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy" 
href="#rfc.section.2"><link rel="Chapter" title="3 Identifiers" 
href="#rfc.section.3"><link rel="Chapter" title="4 Basic Elements" 
href="#rfc.section.4"><link rel="Chapter" title="5 Layer 2 Elements" 
href="#rfc.section.5"><link rel="Chapter" title="6 Layer 3 Elements" 
href="#rfc.section.6"><link rel="Chapter" title="7 Layer 4 Elements" 
href="#rfc.section.7"><link rel="Chapter" title="8 Control Plane Elements" 
href="#rfc.section.8"><link rel="Chapter" title="9 XML Namespaces" 
href="#rfc.section.9"><link rel="Chapter" title="10 Versioning" 
href="#rfc.section.10"><link rel="Chapter" title="11 Relationships Among 
Elements" href="#rfc.section.11"><link rel="Chapter" title="12 Base Topology 
Schema" href="#rfc.section.12"><link rel="Chapter" title="13 Layer 2 Topology 
Schema" href=
 "#rfc.section.13"><link rel="Chapter" title="14 Layer 3 Topology Schema" 
href="#rfc.section.14"><link rel="Chapter" title="15 Layer 4 Topology Schema" 
href="#rfc.section.15"><link rel="Chapter" title="16 Control Plane Topology 
Schema" href="#rfc.section.16"><link rel="Chapter" title="17 Security 
Concerns" href="#rfc.section.17"><link rel="Chapter" href="#rfc.section.18" 
title="18 References"><meta name="generator" 
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291, 
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica 
http://www.saxonica.com/";><link rel="schema.DC" 
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator" 
content="Swany, M"><meta name="DC.Date.Issued" scheme="ISO8601" 
content="2007-09"></head><body><table summary="header information" 
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td 
class="front left">Network Measurement Working Group</td><td class="front 
right">M Swany, Editor</td></tr><tr><td class="front left"
 ></td><td class="front right">UDel</td></tr><tr><td class="f!
 ront lef
t">Intended status: Informational</td><td class="front right">September 
2007</td></tr></table><p class="title">An Extensible Schema for Network 
Topology</p><h1><a id="rfc.status" href="#rfc.status">Status of this 
Memo</a></h1><p>This memo provides information for the Grid community. It 
does not specify any standards or technical recommendations. Distribution is 
unlimited.</p><h1><a id="rfc.copyrightnotice" 
href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright � The Open 
Grid Forum (2007). All Rights Reserved.</p><hr class="noprint"><h1 
id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a 
id="intro" href="#intro">Introduction</a></h1><p id="rfc.section.1.p.1">This 
document presents an extensible encoding standard for network topology. It 
provides a description 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.</p><h2 id="rfc.section.1.1"><a 
href="#rfc.section.1.1">1.1</a>&nbsp;<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 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.</p><hr class="noprint"><h1 id="rfc.section.2" class="np"><a 
href="#rfc.section.2">2.</a>&nbsp;<a id="design_philosophy" 
href="#design_philosophy">Design Philosophy</a></h1><p 
id="rfc.section.2.p.1">Networks have basic components and any network 
representation must inclu
 de these basic elements. Like the Network Measurement schema!
 , we def
ine the basic elements and vary the namespace of them to indicate specific 
components.</p><hr class="noprint"><h1 id="rfc.section.3" class="np"><a 
href="#rfc.section.3">3.</a>&nbsp;<a id="identifiers" 
href="#identifiers">Identifiers</a></h1><p id="rfc.section.3.p.1">The network 
topology identifiers have been designed to be flexible, be explicit in their 
meaning and still be reasonably human-readable.</p><p 
id="rfc.section.3.p.2">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:".</p><p id="rfc.section.3.p.3">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''.</p><p id="rfc.section.3.p.4">A single ``*'' may appear 
instead of a name/value field to connote an identifier for an unknown network 
element of unknown type. If a '*' field is included, that field MUST be the 
last field in the identifier.</p><p id="rfc.section.3.p.5">The name/value 
pairs MUST be ordered from most general network entity to most specific 
network entity. For example, the domain field MUST come before the node field 
which MUST come before the port field. There MUST NOT exist repeated fields 
in the identifier.</p><h2 id="rfc.section.3.1"><a 
href="#rfc.section.3.1">3.1</a>&nbsp;<a id="fields" 
href="#fields">Description of Fields</a></h2><h3 id="rfc.section.3.1.1"><a 
href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="fields_domain" 
href="#fields_domain">Domain</a></h3><p id="rfc.section.3.1.1.p.1">The domain 
field MUST be used to identify an administrative domain. The ident
 ifier for the domain MUST ONLY include the domain field. The!
  actual 
value of this field MUST be a globally unique DNS name for that domain, and 
MUST NOT include any trailing spaces. Setting the value of this field to '*' 
connotes the domain is unknown.</p><p id="rfc.section.3.1.1.p.2"> </p><div 
id="rfc.figure.u.1"></div><pre> urn:ogf:network:domain=dcn.internet2.edu
+                urn:ogf:network:domain=* (this)
+                urn:ogf:network:domain=dcn.internet2.edu:* (is shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </pre><h3 id="rfc.section.3.1.2"><a 
href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="fields_node" 
href="#fields_node">Node</a></h3><p id="rfc.section.3.1.2.p.1">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.</p><p id="rfc.section.3.1.2.p.2">Examples: </p><div 
id="rfc.figure.u.2"></div><pre> 
urn:ogf:network:domain=internet2.edu:node=packrat
+                urn:ogf:network:domain=internet2.edu:node=207.75.164.10
+                urn:ogf:network:domain=internet2.edu:node=Joe's Machine
+                urn:ogf:network:domain=internet2.edu:node=Los Angeles NOC
+                urn:ogf:network:domain=internet2.edu:node=*</pre><h3 
id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;<a 
id="fields_service" href="#fields_service">Service</a></h3><p 
id="rfc.section.3.1.3.p.1">An identifier for a network-available service MUST 
include the domain, node and service fields. The node and domain fields MUST 
be identicial to those in the identifier for the node containing the service. 
The value of the service field can be anything, but MUST be unique in the 
node and MUST NOT include any trailing spaces. The value SHOULD be a human 
readable description of the service. Setting the value of the node field to 
'*' connotes the service is unknown.</p><p 
id="rfc.section.3.1.3.p.2">Examples: </p><div id="rfc.figure.u.3"></div><pre>
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=http
+               
urn:ogf:network:domain=internet2.edu:node=packrat:service=perfSONAR%20SNMP%20MA
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=ping
+              </pre><h3 id="rfc.section.3.1.4"><a 
href="#rfc.section.3.1.4">3.1.4</a>&nbsp;<a id="fields_interfaces" 
href="#fields_interfaces">Interfaces</a></h3><p id="rfc.section.3.1.4.p.1">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.</p><p 
id="rfc.section.3.1.4.p.2">Examples: </p><div id="rfc.figure.u.4"></div><pre>
+                urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=207.75.164.10
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=*</pre><h3 
id="rfc.section.3.1.5"><a href="#rfc.section.3.1.5">3.1.5</a>&nbsp;<a 
id="fields_unilinks" href="#fields_unilinks">Unidirectional 
Intra-domain/Inter-domain Links</a></h3><p id="rfc.section.3.1.5.p.1">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.</p><p id="rfc.section.3.1.5.p.2">Examples: </p><div 
id="rfc.figure.u.5"></div><pre>
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=Link
+                Between Packrat And Router1
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=*
+                (this) urn:ogf:network:domain=dcn.internet2.edu:*
+                (could be shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </pre><h3 id="rfc.section.3.1.6"><a 
href="#rfc.section.3.1.6">3.1.6</a>&nbsp;<a id="fields_bidilinks" 
href="#fields_bidilinks">Bidirectional Domain Links</a></h3><p 
id="rfc.section.3.1.6.p.1">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. Examples:</p><p id="rfc.section.3.1.6.p.2">
  </p><div id="rfc.figure.u.6"></div><pre> 
urn:ogf:network:domain=internet2.edu:link=Link Between
+                Packrat And Router1 
urn:ogf:network:domain=internet2.edu:link=*
+              </pre><h3 id="rfc.section.3.1.7"><a 
href="#rfc.section.3.1.7">3.1.7</a>&nbsp;<a id="fields_bidiinterlinks" 
href="#fields_bidiinterlinks">Bidirectional Inter-domain Links</a></h3><p 
id="rfc.section.3.1.7.p.1">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.</p><p id="rfc.section.3.1.7.p.2">Examples: </p><div 
id="rfc.figure.u.7"></div><pre> urn:ogf:network:link=Link Between Internet2
+                And ESNet urn:ogf:network:link=*</pre><h3 
id="rfc.section.3.1.8"><a href="#rfc.section.3.1.8">3.1.8</a>&nbsp;<a 
id="fields_intrapath" href="#fields_intrapath">Intra-domain Path</a></h3><p 
id="rfc.section.3.1.8.p.1">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.</p><p id="rfc.section.3.1.8.p.2">Examples: </p><div 
id="rfc.figure.u.8"></div><pre> 
urn:ogf:network:domain=internet2.edu: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=* </pre><h3 
id="rfc.section.3.1.9"><a href="#rfc.section.3.1.9">3.1.9</a>&nbsp;<a 
id="fields_interpath" href="#fields_interpath">Inter-domain Path</a></h3><p 
id="rfc.section.3.1.9.p.1">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.</p><p id="rfc.section.3.1.9.p.2">Examples: </p><div 
id="rfc.figure.u.9"></div><pre> urn:ogf:network:path=DRAGON Path From
+                207.75.164.10 to 134.55.209.97 urn:ogf:network:path=*
+              </pre><h3 id="rfc.section.3.1.10"><a 
href="#rfc.section.3.1.10">3.1.10</a>&nbsp;<a id="fields_network" 
href="#fields_network">Network</a></h3><p id="rfc.section.3.1.10.p.1">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.</p><p 
id="rfc.section.3.1.10.p.2">Examples: </p><div id=
 
"rfc.figure.u.10"></div><pre>urn:ogf:network:domain=internet2.edu:network=207.75.164.0%2F24
+                urn:ogf:network:network=207.0.0.0%2F8
+                urn:ogf:network:network=*</pre><hr class="noprint"><h1 
id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;<a 
id="basic_elements" href="#basic_elements">Basic Elements</a></h1><p 
id="rfc.section.4.p.1">This schema defines the basic elements that can be 
used to describe network topologies.</p><p id="rfc.section.4.p.2"> </p><h2 
id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="domain" 
href="#domain">Domain</a></h2><p id="rfc.section.4.1.p.1">A domain is a point 
demarcation used to divide the entities in a topology into administrative 
groupings according to the administrative domain that controls the 
entity.</p><h3 id="rfc.section.4.1.1"><a 
href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="domain_id" 
href="#domain_id">id Attribute</a></h3><p id="rfc.section.4.1.1.p.1">Each 
domain has an id attribute that contains the fully-qualified identifier for 
this domain.</p><h3 id="rfc.section.4.1.2"><a 
href="#rfc.section.4.1.2">4.1.2</a>&nbs
 p;<a id="domain_idref" href="#domain_idref">idRef Attribute</a></h3><p 
id="rfc.section.4.1.2.p.1">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 domain. If a 
domain element has this attribute, it means that this domain element is not 
the authoritative, it simply contains additional information about the 
element.</p><h3 id="rfc.section.4.1.3"><a 
href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<a id="domain_entities" 
href="#domain_entities">Entities In The Domain</a></h3><p 
id="rfc.section.4.1.3.p.1">A domain can have any number of node, link, 
network and path entities defined immediately underneath it. The entities 
defined there must all correspond to entities that are in the actual domain. 
The links that are defined must be bidirectional links. Unidirectional links 
can only be defined inside of ports.</p><h2 id="rfc.section.4.2"><a 
href="#rfc.section.4.
 2">4.2</a>&nbsp;<a id="node" href="#node">Node</a></h2><p id!
 ="rfc.se
ction.4.2.p.1">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.</p><h3 id="rfc.section.4.2.1"><a 
href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="node_id" href="#node_id">id 
Attribute</a></h3><p id="rfc.section.4.2.1.p.1">Each node has an id attribute 
that contains the fully-qualified identifier for this node.</p><h3 
id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a 
id="node_idref" href="#node_idref">idRef Attribute</a></h3><p 
id="rfc.section.4.2.2.p.1">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.</p><
 h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a 
id="node_name" href="#node_name">Name</a></h3><p 
id="rfc.section.4.2.3.p.1">Node elements can contain one or more name 
elements to describe the node. The name element contains a string and can be 
filled with any value that can be used to name the node. This could include 
the node's hostname, its default ip address or simply a description of the 
node.</p><h4 id="rfc.section.4.2.3.1"><a 
href="#rfc.section.4.2.3.1">4.2.3.1</a>&nbsp;<a id="node_name_type" 
href="#node_name_type">Type</a></h4><p id="rfc.section.4.2.3.1.p.1">The name 
element contains an attribute type that should be used to specify the format 
of the contents of the name element.</p><p id="rfc.section.4.2.3.1.p.2"> 
</p><p id="rfc.section.4.2.3.1.p.3">If the type of the element is unspecified 
or is unknown to the client parsing the topology, the client may either treat 
it as an opaque string or try to parse the element's contents on its own. How
 ever, the parsing of the element is outside the scope of thi!
 s docume
nt.</p><h3 id="rfc.section.4.2.4"><a 
href="#rfc.section.4.2.4">4.2.4</a>&nbsp;<a id="node_role" 
href="#node_role">Role</a></h3><p id="rfc.section.4.2.4.p.1">Each node can 
also include a role element to describe what role this network entity has. 
The contents of this element are unspecified, but should correspond to the 
job of the node. If the node is a router, the contents should be "router". If 
the node is an endpoint, the contents should be "endpoint".</p><p 
id="rfc.section.4.2.4.p.2"> </p><h3 id="rfc.section.4.2.5"><a 
href="#rfc.section.4.2.5">4.2.5</a>&nbsp;<a id="node_address" 
href="#node_address">Address</a></h3><p id="rfc.section.4.2.5.p.1">Each node 
can have one or more address element to describe the addresses that the 
outside world can use to contact this node.</p><p id="rfc.section.4.2.5.p.2"> 
</p><p id="rfc.section.4.2.5.p.3">If the type of the element is unspecified 
or is unknown to the client parsing the topology, the client may try to parse 
the element's conten
 ts on its own. However, the parsing of the element is outside the scope of 
this document.</p><h3 id="rfc.section.4.2.6"><a 
href="#rfc.section.4.2.6">4.2.6</a>&nbsp;<a id="node_location" 
href="#node_location">Location Information</a></h3><p 
id="rfc.section.4.2.6.p.1">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.</p><p 
id="rfc.section.4.2.6.p.2">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, r
 ack and shelf can be used to describe precisely where in the!
  buildin
g a node is located.</p><p id="rfc.section.4.2.6.p.3">Longitude and latitude 
information SHOULD be included with each node to ease the drawing of 
topologies.</p><h3 id="rfc.section.4.2.7"><a 
href="#rfc.section.4.2.7">4.2.7</a>&nbsp;<a id="node_contact" 
href="#node_contact">Contact Information</a></h3><p 
id="rfc.section.4.2.7.p.1">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.</p><p 
id="rfc.section.4.2.7.p.2">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.</p><h3 id="rfc.section.4.2.8"><a 
href="#rfc.section.4.2.8">4.2.8</a>&nbsp;<a id="node_description" 
href="#node_description">Description</a></h3><p 
id="rfc.section.4.2.8.p.1">Each node can include a description element. This 
element should include a human readable description of the node.</p><h3 
id="rfc.section.4.2.9"><a href="#rfc.section.4.2.9">4.2.9</a>&nbsp;<a 
id="node_comments" href="#node_comments">Comments</a></h3><p 
 id="rfc.section.4.2.9.p.1">Each node can include one or more!
  comment
s elements. These elements can be used to add human-readable comments about a 
specific node. These should not be used to store necessary information about 
the node.</p><h3 id="rfc.section.4.2.10"><a 
href="#rfc.section.4.2.10">4.2.10</a>&nbsp;<a id="node_relations" 
href="#node_relations">Relations</a></h3><p id="rfc.section.4.2.10.p.1">One 
or more relation elements, which are described later, may be defined inside 
the node.</p><h3 id="rfc.section.4.2.11"><a 
href="#rfc.section.4.2.11">4.2.11</a>&nbsp;<a id="node_lifetime" 
href="#node_lifetime">Lifetime</a></h3><p id="rfc.section.4.2.11.p.1">A node 
has an optional field lifetime that can be used to describe the time during 
which the node had the properties being described or, in the case of 
ephemeral nodes, the time during which the node actually existed.</p><p 
id="rfc.section.4.2.11.p.2">The lifetime element must include an element, 
start, which describes the beginning of the time range. The start element 
contains a string desc
 ribing the start time. The start element has one attribute, type. Type is 
required and describes the format of the time value. For example, it could be 
"iso" to describe an ISO-formatted time string or "unix" to describe a unix 
timestamp.</p><p id="rfc.section.4.2.11.p.3">The lifetime element may also 
include either a duration element or an end element. The duration element 
contains a string describing the amount of time that the entity persisted. 
Like start, it also contains a type attribute that specifies the format of 
the string. The end element contains a string describing the end point of the 
time range. Like start, the end element also contains a type attribute that 
specifies the format of the string.</p><p id="rfc.section.4.2.11.p.4">If the 
lifetime element does not include an end time or a duration, the end time is 
unspecified and can be assumed to be infinite.</p><p 
id="rfc.section.4.2.11.p.5"> </p><h3 id="rfc.section.4.2.12"><a 
href="#rfc.section.4.2.12">4.2.12</a>
 &nbsp;<a id="node_ports" href="#node_ports">Interfaces</a></!
 h3><p id
="rfc.section.4.2.12.p.1">One or more port elements, which are described 
later, may be defined inside the node as well. These port elements must 
correspond to interfaces inside the node being described. The actual 
namespaces of the interfaces can consist of any of the namespaces defined in 
these schema that have a "port" element.</p><h2 id="rfc.section.4.3"><a 
href="#rfc.section.4.3">4.3</a>&nbsp;Links</h2><p 
id="rfc.section.4.3.p.1">Nodes are connected by Links, which are edges in the 
graph model. These Links have properties associated with them.</p><h3 
id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;id 
Attribute</h3><p id="rfc.section.4.3.1.p.1">Each link has an id attribute 
that contains the fully-qualified identifier for the link.</p><h3 
id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;idRef 
Attribute</h3><p id="rfc.section.4.3.2.p.1">Another identifying attribute is 
the idRef attribute. If this is included, the id attribute must not b
 e included. This attribute is a way of defining partial information about a 
link. If a link element has this attribute, it means that this link element 
is not the authoritative link element, it simply contains additional 
information about the element.</p><h3 id="rfc.section.4.3.3"><a 
href="#rfc.section.4.3.3">4.3.3</a>&nbsp;Name</h3><p 
id="rfc.section.4.3.3.p.1">Links elements can contain one or more name 
elements to describe the link. The name element contains a string and can be 
filled with any value that can be used to name the link. This could include 
an e2emon style link name, a local name for the link or simply a description 
of the link.</p><h4 id="rfc.section.4.3.3.1"><a 
href="#rfc.section.4.3.3.1">4.3.3.1</a>&nbsp;<a id="link_name_type" 
href="#link_name_type">Type</a></h4><p id="rfc.section.4.3.3.1.p.1">The name 
element contains an attribute type that should be used to specify the format 
of the contents of the name element.</p><p id="rfc.section.4.3.3.1.p.2"> 
</p><p 
 id="rfc.section.4.3.3.1.p.3">If the type of the element is u!
 nspecifi
ed or is unknown to the client parsing the topology, the client may either 
treat it as an opaque string or try to parse the element's contents on its 
own. However, the parsing of the element is outside the scope of this 
document.</p><h3 id="rfc.section.4.3.4"><a 
href="#rfc.section.4.3.4">4.3.4</a>&nbsp;Global Name</h3><p 
id="rfc.section.4.3.4.p.1">The globalName element can be used to give a 
globally-unique name to describe the link. This element contains an attribute 
describing what type of name this element contains.</p><p 
id="rfc.section.4.3.4.p.2">The types and contents of the element are 
unspecified as the element is deprecated. Its inclusion in here is due to the 
prevelance of e2emon services that exist which make use of a globalName 
field.</p><h3 id="rfc.section.4.3.5"><a 
href="#rfc.section.4.3.5">4.3.5</a>&nbsp;Type</h3><p 
id="rfc.section.4.3.5.p.1">Each link can also include a type element to 
describe the protocol of the link. There are a number of predefined values 
 for this element, but the contents of the type need not be confined to those 
values in list included in the appendix. If the link is a virtual link, the 
contents of the type element should be "logical". In the base elements, the 
type can specifically define the protocol being used, e.g. ethernet, or could 
be set to something general like 'layer2' to state generally what kind of 
protocol is being run over it. If the link is unidirectional, it must have 
the same type as the port it is defined in. If the link is bidirectional, it 
must have the same type as the two undirectional links that underly it.</p><p 
id="rfc.section.4.3.5.p.2"> </p><h3 id="rfc.section.4.3.6"><a 
href="#rfc.section.4.3.6">4.3.6</a>&nbsp;Remote Link Id</h3><p 
id="rfc.section.4.3.6.p.1">Bidirectional links are made up of two 
unidirectional links. Each undirectional link may contain a reference to its 
sibling link using the remoteLinkId element. If included, the remoteLinkId 
element must contain the fully-qual
 ified identifier for the sibling unidirectional link. If the!
  remoteL
inkId element is specified in an element, the sibling link must have the same 
type as the link being described.</p><h3 id="rfc.section.4.3.7"><a 
href="#rfc.section.4.3.7">4.3.7</a>&nbsp;Description</h3><p 
id="rfc.section.4.3.7.p.1">Each link can include a description element. This 
element should include a human readable description of the link.</p><h3 
id="rfc.section.4.3.8"><a 
href="#rfc.section.4.3.8">4.3.8</a>&nbsp;Comments</h3><p 
id="rfc.section.4.3.8.p.1">Each link can include one or more comments 
elements. These elements can be used to add human-readable comments about the 
link. These should not be used to store necessary information about the 
link.</p><h3 id="rfc.section.4.3.9"><a 
href="#rfc.section.4.3.9">4.3.9</a>&nbsp;Relations</h3><p 
id="rfc.section.4.3.9.p.1">One or more relation elements, which are described 
later, may be defined inside the link.</p><h4 id="rfc.section.4.3.9.1"><a 
href="#rfc.section.4.3.9.1">4.3.9.1</a>&nbsp;Bidirectional Relations</h4><p 
id="rfc.
 section.4.3.9.1.p.1">Bidirectional links should include an over relation 
containing references to the two unidirectional links that make up the 
bidirectional link.</p><h3 id="rfc.section.4.3.10"><a 
href="#rfc.section.4.3.10">4.3.10</a>&nbsp;<a id="link_lifetime" 
href="#link_lifetime">Lifetime</a></h3><p id="rfc.section.4.3.10.p.1">A link 
has an optional field lifetime that can be used to describe the time during 
which the link had the properties being described or, in the case of 
ephemeral links, the time during which the link actually existed.</p><p 
id="rfc.section.4.3.10.p.2">The lifetime element must include an element, 
start, which describes the beginning of the time range. The start element 
contains a string describing the start time. The start element has one 
attribute, type. Type is required and describes the format of the time value. 
For example, it could be "iso" to describe an ISO-formatted time string or 
"unix" to describe a unix timestamp.</p><p id="rfc.section.4
 .3.10.p.3">The lifetime element may also include either a du!
 ration e
lement or an end element. The duration element contains a string describing 
the amount of time that the entity persisted. Like start, it also contains a 
type attribute that specifies the format of the string. The end element 
contains a string describing the end point of the time range. Like start, the 
end element also contains a type attribute that specifies the format of the 
string.</p><p id="rfc.section.4.3.10.p.4">If the lifetime element does not 
include an end time or a duration, the end time is unspecified and can be 
assumed to be infinite.</p><p id="rfc.section.4.3.10.p.5"> </p><h2 
id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="port" 
href="#port">Interfaces</a></h2><p id="rfc.section.4.4.p.1">Nodes have 
interfaces, which are the attachment points of links. They have properties 
which are independent of the Node. Interfaces are defined in the schema in 
port elements.</p><h3 id="rfc.section.4.4.1"><a 
href="#rfc.section.4.4.1">4.4.1</a>&nbsp;<a id="port
 _id" href="#port_id">id Attribute</a></h3><p id="rfc.section.4.4.1.p.1">Each 
port has an id attribute that contains the fully-qualified identifier for the 
port.</p><h3 id="rfc.section.4.4.2"><a 
href="#rfc.section.4.4.2">4.4.2</a>&nbsp;<a id="port_idref" 
href="#port_idref">idRef Attribute</a></h3><p 
id="rfc.section.4.4.2.p.1">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 port. If a port 
element has this attribute, it means that this port element is not the 
authoritative port element, it simply contains additional information about 
the element.</p><h3 id="rfc.section.4.4.3"><a 
href="#rfc.section.4.4.3">4.4.3</a>&nbsp;<a id="port_name" 
href="#port_name">Name</a></h3><p id="rfc.section.4.4.3.p.1">The port element 
can have one or more name elements to describe the port. The name element 
contains a string and can be filled with any value that can be u
 sed to name the port. This could include the name of the int!
 erface o
n the host, the ip address for a layer 3 port or a simple description of the 
port.</p><h4 id="rfc.section.4.4.3.1"><a 
href="#rfc.section.4.4.3.1">4.4.3.1</a>&nbsp;<a id="port_name_type" 
href="#port_name_type">Type</a></h4><p id="rfc.section.4.4.3.1.p.1">The name 
element contains an attribute type that should be used to specify the format 
of the contents of the name element.</p><p id="rfc.section.4.4.3.1.p.2"> 
</p><p id="rfc.section.4.4.3.1.p.3">If the type of the element is unspecified 
or is unknown to the client parsing the topology, the client may either treat 
it as an opaque string or try to parse the element's contents on its own. 
However, the parsing of the element is outside the scope of this 
document.</p><h3 id="rfc.section.4.4.4"><a 
href="#rfc.section.4.4.4">4.4.4</a>&nbsp;<a id="port_address" 
href="#port_address">Address</a></h3><p id="rfc.section.4.4.4.p.1">Each port 
can have one or more address elements to describe the addresses that the 
outside world can use to co
 ntact this port.</p><p id="rfc.section.4.4.4.p.2"> </p><p 
id="rfc.section.4.4.4.p.3">If the type of the element is unspecified or is 
unknown to the client parsing the topology, the client may try to parse the 
element's contents on its own. However, the parsing of the element is outside 
the scope of this document.</p><h3 id="rfc.section.4.4.5"><a 
href="#rfc.section.4.4.5">4.4.5</a>&nbsp;<a id="port_type" 
href="#port_type">Type</a></h3><p id="rfc.section.4.4.5.p.1">Each port can 
also include a type element to describe the protocol of the interface. There 
are a number of predefined values for this element, but the contents of the 
type need not be confined to those values in list included in the appendix. 
If the port is a virtual port, the contents of the type element should be 
"logical". In the base elements, the type can specifically define what 
protocol is being used, e.g. ethernet, or could be set to something like 
'layer2' to state generally what kind of protocol is being r
 un over it.</p><p id="rfc.section.4.4.5.p.2"> </p><h3 id="rf!
 c.sectio
n.4.4.6"><a href="#rfc.section.4.4.6">4.4.6</a>&nbsp;<a id="port_capacity" 
href="#port_capacity">Capactity</a></h3><p id="rfc.section.4.4.6.p.1"> 
</p><h3 id="rfc.section.4.4.7"><a href="#rfc.section.4.4.7">4.4.7</a>&nbsp;<a 
id="port_mtu" href="#port_mtu">MTU</a></h3><p 
id="rfc.section.4.4.7.p.1">Every port element may contain an element, mtu, 
containing the maximum size an individual segment of data that can be 
transmitted with this port can contain. If the port were an ethernet port, 
this would be the configured MTU for the port. If the port were a UDP port, 
the value would contain the maximum segment size for the port. This field 
must contain an integer corresponding to the number of bytes in the maximum 
size. If the specified value is "0", this means that the particular interface 
has no maximum segment size.</p><h3 id="rfc.section.4.4.8"><a 
href="#rfc.section.4.4.8">4.4.8</a>&nbsp;<a id="port_description" 
href="#port_description">Description</a></h3><p id="rfc.section.4.4.
 8.p.1">Each port can include a description element. This element should 
include a human readable description of the port.</p><h3 
id="rfc.section.4.4.9"><a href="#rfc.section.4.4.9">4.4.9</a>&nbsp;<a 
id="port_comments" href="#port_comments">Comments</a></h3><p 
id="rfc.section.4.4.9.p.1">Each port can include one or more comments 
elements. These elements can be used to add human-readable comments about the 
port. These should not be used to store necessary information about the 
port.</p><h3 id="rfc.section.4.4.10"><a 
href="#rfc.section.4.4.10">4.4.10</a>&nbsp;<a id="port_relations" 
href="#port_relations">Relations</a></h3><p id="rfc.section.4.4.10.p.1">One 
or more relation elements, which are described later, may be defined inside 
the port.</p><h3 id="rfc.section.4.4.11"><a 
href="#rfc.section.4.4.11">4.4.11</a>&nbsp;<a id="port_lifetime" 
href="#port_lifetime">Lifetime</a></h3><p id="rfc.section.4.4.11.p.1">A port 
has an optional field lifetime that can be used to describe the t
 ime during which the port had the properties being described!
  or, in 
the case of ephemeral ports, the time during which the port actually 
existed.</p><p id="rfc.section.4.4.11.p.2">The lifetime element must include 
an element, start, which describes the beginning of the time range. The start 
element contains a string describing the start time. The start element has 
one attribute, type. Type is required and describes the format of the time 
value. For example, it could be "iso" to describe an ISO-formatted time 
string or "unix" to describe a unix timestamp.</p><p 
id="rfc.section.4.4.11.p.3">The lifetime element may also include either a 
duration element or an end element. The duration element contains a string 
describing the amount of time that the entity persisted. Like start, it also 
contains a type attribute that specifies the format of the string. The end 
element contains a string describing the end point of the time range. Like 
start, the end element also contains a type attribute that specifies the 
format of the string.</p><p id="rfc.secti
 on.4.4.11.p.4">If the lifetime element does not include an end time or a 
duration, the end time is unspecified and can be assumed to be 
infinite.</p><p id="rfc.section.4.4.11.p.5"> </p><h3 
id="rfc.section.4.4.12"><a href="#rfc.section.4.4.12">4.4.12</a>&nbsp;<a 
id="port_links" href="#port_links">Links</a></h3><p 
id="rfc.section.4.4.12.p.1">One or more link elements, which are described 
earlier, may be defined inside the port as well. The only links that can be 
defined inside a port are unidirectional links whose source is the port in 
which they are being defined. The type of the unidirectional link must be the 
same as the type of the port it's defined in. For example, an ipv4 link 
cannot be created inside an 802.11 port. It must be created inside an ipv4 
port.</p><h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a 
id="service" href="#service">Service</a></h2><p id="rfc.section.4.5.p.1">The 
service element can be used to describe services. This could include h
 igh-level services like web-services or low-level services l!
 ike a tr
anslator between optical wavelengths.</p><h3 id="rfc.section.4.5.1"><a 
href="#rfc.section.4.5.1">4.5.1</a>&nbsp;<a id="service_id" 
href="#service_id">id Attribute</a></h3><p id="rfc.section.4.5.1.p.1">Each 
service has an id attribute that contains the fully-qualified identifier for 
this service.</p><h3 id="rfc.section.4.5.2"><a 
href="#rfc.section.4.5.2">4.5.2</a>&nbsp;<a id="service_idref" 
href="#service_idref">idRef Attribute</a></h3><p 
id="rfc.section.4.5.2.p.1">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 service. If a 
service element has this attribute, it means that this service element is not 
the authoritative, it simply contains additional information about the 
element.</p><h3 id="rfc.section.4.5.3"><a 
href="#rfc.section.4.5.3">4.5.3</a>&nbsp;<a id="service_name" 
href="#service_name">Name</a></h3><p id="rfc.section.4.5.3.p.1">Service elem
 ents can contain one or more name elements to describe the service. The name 
element contains a string and can be filled with any value that can be used 
to name the service.</p><h4 id="rfc.section.4.5.3.1"><a 
href="#rfc.section.4.5.3.1">4.5.3.1</a>&nbsp;<a id="service_name_type" 
href="#service_name_type">Type</a></h4><p id="rfc.section.4.5.3.1.p.1">The 
name element contains an attribute type that should be used to specify the 
format of the contents of the name element.</p><p 
id="rfc.section.4.5.3.1.p.2"> </p><p id="rfc.section.4.5.3.1.p.3">If the type 
of the element is unspecified or is unknown to the client parsing the 
topology, the client may either treat it as an opaque string or try to parse 
the element's contents on its own. However, the parsing of the element is 
outside the scope of this document.</p><h3 id="rfc.section.4.5.4"><a 
href="#rfc.section.4.5.4">4.5.4</a>&nbsp;<a id="service_description" 
href="#service_description">Description</a></h3><p id="rfc.section.4.5.4
 .p.1">Each service can include a description element. This e!
 lement s
hould include a human readable description of the service.</p><h3 
id="rfc.section.4.5.5"><a href="#rfc.section.4.5.5">4.5.5</a>&nbsp;<a 
id="service_comments" href="#service_comments">Comments</a></h3><p 
id="rfc.section.4.5.5.p.1">Each service can include one or more comments 
elements. These elements can be used to add human-readable comments about a 
specific service. These should not be used to store necessary information 
about the service.</p><h3 id="rfc.section.4.5.6"><a 
href="#rfc.section.4.5.6">4.5.6</a>&nbsp;<a id="service_relations" 
href="#service_relations">Relations</a></h3><p id="rfc.section.4.5.6.p.1">One 
or more relation elements, which are described later, may be defined inside 
the service.</p><p id="rfc.section.4.5.6.p.2">If a service is only available 
on a certain number of interfaces, it should include an 'over' relation 
containing the set of interfaces that the service is reachable via.</p><h3 
id="rfc.section.4.5.7"><a href="#rfc.section.4.5.7">4.5.7</a>&nbsp;
 <a id="service_lifetime" href="#service_lifetime">Lifetime</a></h3><p 
id="rfc.section.4.5.7.p.1">A service has an optional field lifetime that can 
be used to describe the time during which the service had the properties 
being described or, in the case of ephemeral services, the time during which 
the service actually existed.</p><p id="rfc.section.4.5.7.p.2">The lifetime 
element must include an element, start, which describes the beginning of the 
time range. The start element contains a string describing the start time. 
The start element has one attribute, type. Type is required and describes the 
format of the time value. For example, it could be "iso" to describe an 
ISO-formatted time string or "unix" to describe a unix timestamp.</p><p 
id="rfc.section.4.5.7.p.3">The lifetime element may also include either a 
duration element or an end element. The duration element contains a string 
describing the amount of time that the entity persisted. Like start, it also 
contains a type 
 attribute that specifies the format of the string. The end e!
 lement c
ontains a string describing the end point of the time range. Like start, the 
end element also contains a type attribute that specifies the format of the 
string.</p><p id="rfc.section.4.5.7.p.4">If the lifetime element does not 
include an end time or a duration, the end time is unspecified and can be 
assumed to be infinite.</p><p id="rfc.section.4.5.7.p.5"> </p><h2 
id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="network" 
href="#network">Network</a></h2><p id="rfc.section.4.6.p.1">A Network is 
essentially a scoping construct.</p><h3 id="rfc.section.4.6.1"><a 
href="#rfc.section.4.6.1">4.6.1</a>&nbsp;<a id="network_id" 
href="#network_id">id Attribute</a></h3><p id="rfc.section.4.6.1.p.1">Each 
network element has an id attribute that contains the fully-qualified 
identifier for the element.</p><h3 id="rfc.section.4.6.2"><a 
href="#rfc.section.4.6.2">4.6.2</a>&nbsp;<a id="network_idref" 
href="#network_idref">idRef Attribute</a></h3><p id="rfc.section.4.6.2.p.1">An
 other 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 port. If a port element has this attribute, it 
means that this port element is not the authoritative port element, it simply 
contains additional information about the element.</p><h3 
id="rfc.section.4.6.3"><a href="#rfc.section.4.6.3">4.6.3</a>&nbsp;<a 
id="network_name" href="#network_name">Name</a></h3><p 
id="rfc.section.4.6.3.p.1">Network elements can contain one or more name 
elements to describe the network. The name element contains a string and can 
be filled with any value that can be used to name the network. This could be 
the subnet for an ipv4 or ipv6 network or a simple description of the 
network.</p><h4 id="rfc.section.4.6.3.1"><a 
href="#rfc.section.4.6.3.1">4.6.3.1</a>&nbsp;<a id="network_name_type" 
href="#network_name_type">Type</a></h4><p id="rfc.section.4.6.3.1.p.1">The 
name element conta
 ins an attribute type that should be used to specify the for!
 mat of t
he contents of the name element.</p><p id="rfc.section.4.6.3.1.p.2"> </p><p 
id="rfc.section.4.6.3.1.p.3">If the type of the element is unspecified or is 
unknown to the client parsing the topology, the client may either treat it as 
an opaque string or try to parse the element's contents on its own. However, 
the parsing of the element is outside the scope of this document.</p><h3 
id="rfc.section.4.6.4"><a href="#rfc.section.4.6.4">4.6.4</a>&nbsp;<a 
id="network_type" href="#network_type">Type</a></h3><p 
id="rfc.section.4.6.4.p.1">Each network element can also include a type 
element to describe the protocol of the network being described. The contents 
of this element are unspecified, howerever, there exist a set of predefined 
values that this may contain. For example, "ethernet" if the network were an 
ethernet network, "tcp" if it were a tcp overlay network. New type defintions 
should be created in a fashion similar to the existing ones, or simply 
"layer2" for a general layer2 ne
 twork. If a type is specified, every element in the network must be 
connected via the specified protocol.</p><p id="rfc.section.4.6.4.p.2"> 
</p><h3 id="rfc.section.4.6.5"><a href="#rfc.section.4.6.5">4.6.5</a>&nbsp;<a 
id="network_description" href="#network_description">Description</a></h3><p 
id="rfc.section.4.6.5.p.1">Each network can include a description element. 
This element should include a human readable description of the 
network.</p><h3 id="rfc.section.4.6.6"><a 
href="#rfc.section.4.6.6">4.6.6</a>&nbsp;<a id="network_comments" 
href="#network_comments">Comments</a></h3><p id="rfc.section.4.6.6.p.1">Each 
network can include one or more comments elements. These elements can be used 
to add human-readable comments about the network. These should not be used to 
store necessary information about the network.</p><h3 
id="rfc.section.4.6.7"><a href="#rfc.section.4.6.7">4.6.7</a>&nbsp;<a 
id="network_relations" href="#network_relations">Relations</a></h3><p 
id="rfc.section.4.6.7
 .p.1">One or more relation elements, which are described lat!
 er, may 
be defined inside the network.</p><h3 id="rfc.section.4.6.8"><a 
href="#rfc.section.4.6.8">4.6.8</a>&nbsp;<a id="network_lifetime" 
href="#network_lifetime">Lifetime</a></h3><p id="rfc.section.4.6.8.p.1">A 
network has an optional field lifetime that can be used to describe the time 
during which the network had the properties being described or, in the case 
of ephemeral networks, the time during which the network actually 
existed.</p><p id="rfc.section.4.6.8.p.2">The lifetime element must include 
an element, start, which describes the beginning of the time range. The start 
element contains a string describing the start time. The start element has 
one attribute, type. Type is required and describes the format of the time 
value. For example, it could be "iso" to describe an ISO-formatted time 
string or "unix" to describe a unix timestamp.</p><p 
id="rfc.section.4.6.8.p.3">The lifetime element may also include either a 
duration element or an end element. The duration element contain
 s a string describing the amount of time that the entity persisted. Like 
start, it also contains a type attribute that specifies the format of the 
string. The end element contains a string describing the end point of the 
time range. Like start, the end element also contains a type attribute that 
specifies the format of the string.</p><p id="rfc.section.4.6.8.p.4">If the 
lifetime element does not include an end time or a duration, the end time is 
unspecified and can be assumed to be infinite.</p><p 
id="rfc.section.4.6.8.p.5"> </p><h3 id="rfc.section.4.6.9"><a 
href="#rfc.section.4.6.9">4.6.9</a>&nbsp;<a id="network_children" 
href="#network_children">Entities In The Network</a></h3><p 
id="rfc.section.4.6.9.p.1">The network may contain any number of node id 
references, link id references or link id references which are used to define 
the set of elements contained in the network. If the type of the network has 
been set, all the elements in the network must be connected using the 
 specified type.</p><h2 id="rfc.section.4.7"><a href="#rfc.se!
 ction.4.
7">4.7</a>&nbsp;<a id="path" href="#path">Path</a></h2><p 
id="rfc.section.4.7.p.1">A Path defines a discrete path between two 
topological points.</p><h3 id="rfc.section.4.7.1"><a 
href="#rfc.section.4.7.1">4.7.1</a>&nbsp;<a id="path_id" href="#path_id">id 
Attribute</a></h3><p id="rfc.section.4.7.1.p.1">Each path element has an id 
attribute that contains the fully-qualified identifier for the 
element.</p><h3 id="rfc.section.4.7.2"><a 
href="#rfc.section.4.7.2">4.7.2</a>&nbsp;<a id="path_idref" 
href="#path_idref">idRef Attribute</a></h3><p 
id="rfc.section.4.7.2.p.1">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 path. If a path 
element has this attribute, it means that this path element is not the 
authoritative path element, it simply contains additional information about 
the element.</p><h3 id="rfc.section.4.7.3"><a 
href="#rfc.section.4.7.3">4.7.3</a
 >&nbsp;<a id="path_name" href="#path_name">Name</a></h3><p 
 >id="rfc.section.4.7.3.p.1">The path element can contain one or more name 
 >elements to describe the path. The name element contains a string and can 
 >be filled with any value that can be used to name the path. This could be 
 >an e2emon style global circuit name, an identifier from a path construction 
 >service or simply a description of the path.</p><h4 
 >id="rfc.section.4.7.3.1"><a href="#rfc.section.4.7.3.1">4.7.3.1</a>&nbsp;<a 
 >id="path_name_type" href="#path_name_type">Type</a></h4><p 
 >id="rfc.section.4.7.3.1.p.1">The name element contains an attribute type 
 >that should be used to specify the format of the contents of the name 
 >element.</p><p id="rfc.section.4.7.3.1.p.2"> </p><p 
 >id="rfc.section.4.7.3.1.p.3">If the type of the element is unspecified or 
 >is unknown to the client parsing the topology, the client may either treat 
 >it as an opaque string or try to parse the element's contents on its own. 
 >However, the parsing of the 
 element is outside the scope of this document.</p><h3 id="rf!
 c.sectio
n.4.7.4"><a href="#rfc.section.4.7.4">4.7.4</a>&nbsp;<a id="path_type" 
href="#path_type">Type</a></h3><p id="rfc.section.4.7.4.p.1">Each path 
element can also include a type element to describe the protocol used by the 
path being defined. The contents of this element are unspecified, howerever, 
there exist a set of predefined values that this may contain. For example, 
"ethernet" if every element in that path were ethernet, "tcp" if every step 
were tcp or simply "layer2" if every step were at layer2. New type defintions 
should be created in a fashion similar to the existing ones.</p><p 
id="rfc.section.4.7.4.p.2"> </p><h3 id="rfc.section.4.7.5"><a 
href="#rfc.section.4.7.5">4.7.5</a>&nbsp;<a id="path_description" 
href="#path_description">Description</a></h3><p 
id="rfc.section.4.7.5.p.1">Each path can include a description element. This 
element should include a human readable description of the path.</p><h3 
id="rfc.section.4.7.6"><a href="#rfc.section.4.7.6">4.7.6</a>&nbsp;<a id=
 "path_comments" href="#path_comments">Comments</a></h3><p 
id="rfc.section.4.7.6.p.1">Each path can include one or more comments 
elements. These elements can be used to add human-readable comments about the 
path. These should not be used to store necessary information about the 
path.</p><h3 id="rfc.section.4.7.7"><a 
href="#rfc.section.4.7.7">4.7.7</a>&nbsp;<a id="path_relations" 
href="#path_relations">Relations</a></h3><p id="rfc.section.4.7.7.p.1">One or 
more relation elements, which are described later, may be defined inside the 
path.</p><h3 id="rfc.section.4.7.8"><a 
href="#rfc.section.4.7.8">4.7.8</a>&nbsp;<a id="path_lifetime" 
href="#path_lifetime">Lifetime</a></h3><p id="rfc.section.4.7.8.p.1">A path 
has an optional field lifetime that can be used to describe the time during 
which the path had the properties being described or, in the case of 
ephemeral path, the time during which the path actually existed.</p><p 
id="rfc.section.4.7.8.p.2">The lifetime element must includ
 e an element, start, which describes the beginning of the ti!
 me range
. The start element contains a string describing the start time. The start 
element has one attribute, type. Type is required and describes the format of 
the time value. For example, it could be "iso" to describe an ISO-formatted 
time string or "unix" to describe a unix timestamp.</p><p 
id="rfc.section.4.7.8.p.3">The lifetime element may also include either a 
duration element or an end element. The duration element contains a string 
describing the amount of time that the entity persisted. Like start, it also 
contains a type attribute that specifies the format of the string. The end 
element contains a string describing the end point of the time range. Like 
start, the end element also contains a type attribute that specifies the 
format of the string.</p><p id="rfc.section.4.7.8.p.4">If the lifetime 
element does not include an end time or a duration, the end time is 
unspecified and can be assumed to be infinite.</p><p 
id="rfc.section.4.7.8.p.5"> </p><h3 id="rfc.section.4.7.9"><a 
 href="#rfc.section.4.7.9">4.7.9</a>&nbsp;<a id="path_children" 
href="#path_children">Entities In The Network</a></h3><p 
id="rfc.section.4.7.9.p.1">The path may contain any number of node id 
references, link id references or link id references which are used to define 
the set of elements contained in the path. These id references take the form 
"nodeIdRef", "portIdRef" and "linkIdRef". The contents of each them must 
contain a fully-qualified identifier for a network entity of the reference 
type.</p><p id="rfc.section.4.7.9.p.2">If the type of the path has been set, 
all the elements in the path must be connected using the specified 
type.</p><h2 id="rfc.section.4.8"><a href="#rfc.section.4.8">4.8</a>&nbsp;<a 
id="epp" href="#epp">Endpoint Pairs</a></h2><p 
id="rfc.section.4.8.p.1">Conceptually, endpoint pairs could be provided by 
creating two port elements and a link element. The two ports and a link 
element is the preferred method for creation of these kinds of entities. 
However,
  due to the common appearance of these concepts in network m!
 easureme
nts, the endpoint pair is provided as a shorthand for the link/port construct 
in measurement requests. These elements must not be returned as part of a 
description of physical topology.</p><h3 id="rfc.section.4.8.1"><a 
href="#rfc.section.4.8.1">4.8.1</a>&nbsp;<a id="epp_name" 
href="#epp_name">Name</a></h3><p id="rfc.section.4.8.1.p.1">End-point pairs 
elements can contain one or more name elements to describe the endpoint pair. 
The name element contains a string and can be filled with any value that can 
be used to name the pair.</p><h4 id="rfc.section.4.8.1.1"><a 
href="#rfc.section.4.8.1.1">4.8.1.1</a>&nbsp;<a id="epp_name_type" 
href="#epp_name_type">Type</a></h4><p id="rfc.section.4.8.1.1.p.1">The name 
element contains an attribute type that should be used to specify the format 
of the contents of the name element.</p><p id="rfc.section.4.8.1.1.p.2"> 
</p><p id="rfc.section.4.8.1.1.p.3">If the type of the element is unspecified 
or is unknown to the client parsing the topology, 
 the client may either treat it as an opaque string or try to parse the 
element's contents on its own. However, the parsing of the element is outside 
the scope of this document.</p><h3 id="rfc.section.4.8.2"><a 
href="#rfc.section.4.8.2">4.8.2</a>&nbsp;<a id="epp_type" 
href="#epp_type">Type</a></h3><p id="rfc.section.4.8.2.p.1">Each epp element 
can also include a type element to describe the protocol used by the 
endpoints for communication. The contents of this element are unspecified, 
howerever, there exist a set of predefined values that this may contain. For 
example, "ethernet" if the endpoints communicated via "ethernet", "tcp" if 
they communicate via tcp or simply "layer2" if they communicate via some 
layer2 protocol. New type defintions should be created in a fashion similar 
to the existing ones.</p><p id="rfc.section.4.8.2.p.2"> </p><h3 
id="rfc.section.4.8.3"><a href="#rfc.section.4.8.3">4.8.3</a>&nbsp;<a 
id="epp_description" href="#epp_description">Description</a></h3>
 <p id="rfc.section.4.8.3.p.1">Each endpoint pair can include!
  a descr
iption element. This element should include a human readable description of 
the pair.</p><h3 id="rfc.section.4.8.4"><a 
href="#rfc.section.4.8.4">4.8.4</a>&nbsp;<a id="epp_comments" 
href="#epp_comments">Comments</a></h3><p id="rfc.section.4.8.4.p.1">Each 
endpoint pair can include one or more comments elements. These elements can 
be used to add human-readable comments about a specific node. These should 
not be used to store necessary information about the pair.</p><h3 
id="rfc.section.4.8.5"><a href="#rfc.section.4.8.5">4.8.5</a>&nbsp;<a 
id="epp_src" href="#epp_src">Source</a></h3><p id="rfc.section.4.8.5.p.1">The 
source for an endpoint pair is described using a src element. This element 
can consist of the set of elements in a port defintion as described above. It 
may also consist of simply a portIdRef element which contains the 
fully-qualified id of the port functioning as the source endpoint.</p><h3 
id="rfc.section.4.8.6"><a href="#rfc.section.4.8.6">4.8.6</a>&nbsp;<a id="epp_
 dst" href="#epp_dst">Destination</a></h3><p id="rfc.section.4.8.6.p.1">The 
destination for an endpoint pair is described using a dst element. This 
element can consist of the set of elements in a port defintion as described 
above. It may also consist of simply a portIdRef element which contains the 
fully-qualified id of the port functioning as the destination 
endpoint.</p><hr class="noprint"><h1 id="rfc.section.5" class="np"><a 
href="#rfc.section.5">5.</a>&nbsp;Layer 2 Elements</h1><p 
id="rfc.section.5.p.1"> </p><h2 id="rfc.section.5.1"><a 
href="#rfc.section.5.1">5.1</a>&nbsp;Type</h2><p id="rfc.section.5.1.p.1">The 
type in layer 2 elements, if included, must be the link layer protocol of 
that element. For example, an ethernet link would have type 
"ethernet".</p><h2 id="rfc.section.5.2"><a 
href="#rfc.section.5.2">5.2</a>&nbsp;Port</h2><h3 id="rfc.section.5.2.1"><a 
href="#rfc.section.5.2.1">5.2.1</a>&nbsp;Address</h3><p 
id="rfc.section.5.2.1.p.1">The address element in layer 2
  ports must consist of the layer 2 address for the port.</p>!
 <h3 id="
rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;ifName</h3><p 
id="rfc.section.5.2.2.p.1">The layer 2 namespace adds a new element, ifName, 
that can be used to specify the SNMP name of the interface. The ifName 
element contains a string representation of the port's ifName.</p><h3 
id="rfc.section.5.2.3"><a 
href="#rfc.section.5.2.3">5.2.3</a>&nbsp;ifIndex</h3><p 
id="rfc.section.5.2.3.p.1">The layer 2 namespace adds a new element, ifIndex, 
that can be used to specify the SNMP index of the interface. The ifIndex 
field must be filled in with the integer SNMP index for the interface.</p><h3 
id="rfc.section.5.2.4"><a href="#rfc.section.5.2.4">5.2.4</a>&nbsp;Vlan 
Tag</h3><p id="rfc.section.5.2.4.p.1">The layer 2 namespace adds a new 
element, vlan, that can be used to specify the vlan tag for the specified 
port. The vlan element must contain an integer corresponding to the vlan tag 
for that port.</p><h3 id="rfc.section.5.2.5"><a 
href="#rfc.section.5.2.5">5.2.5</a>&nbsp;V
 lan Range Availability</h3><p id="rfc.section.5.2.5.p.1">The layer 2 
namespace adds an element, vlanRangeAvailability, that can be used to specify 
which tags are still available for use to create new vlans on the specified 
port. The element must contain a string containing a comma-separated list of 
vlan tag identifiers. Ranges of tags can be specified by listing two vlan 
tags separated by a "-".</p><h2 id="rfc.section.5.3"><a 
href="#rfc.section.5.3">5.3</a>&nbsp;Link</h2><h3 id="rfc.section.5.3.1"><a 
href="#rfc.section.5.3.1">5.3.1</a>&nbsp;Vlan Tag</h3><p 
id="rfc.section.5.3.1.p.1">The layer 2 namespace adds a new element, vlan, 
that can be used to specify the vlan tag for the specified link. The vlan 
element must contain an integer corresponding to the vlan tag for that link. 
If the vlan tag is specified for the port associated with this link, this 
value must be the same as the one in the port.</p><h2 id="rfc.section.5.4"><a 
href="#rfc.section.5.4">5.4</a>&nbsp;Network</h2
 ><h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4!
 .1</a>&n
bsp;Vlan Tag</h3><p id="rfc.section.5.4.1.p.1">The layer 2 namespace adds a 
new element, vlan, that can be used to specify the vlan tag for the specified 
network. The vlan element must contain an integer corresponding to the vlan 
tag for that network. If the vlan tag is specified, all the elements 
referenced by the network need to have the same vlan tag.</p><hr 
class="noprint"><h1 id="rfc.section.6" class="np"><a 
href="#rfc.section.6">6.</a>&nbsp;Layer 3 Elements</h1><p 
id="rfc.section.6.p.1"> </p><h2 id="rfc.section.6.1"><a 
href="#rfc.section.6.1">6.1</a>&nbsp;Type</h2><p id="rfc.section.6.1.p.1">The 
type in layer 3 elements, if included, must be the network layer protocol of 
that element. For example, an ipv4 network would have type "ipv4".</p><h2 
id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;Port</h2><h3 
id="rfc.section.6.2.1"><a 
href="#rfc.section.6.2.1">6.2.1</a>&nbsp;Name</h3><p 
id="rfc.section.6.2.1.p.1">The name for the layer 3 element should be the lay
 er 3 address for that element. The type attribute must be specified.</p><h3 
id="rfc.section.6.2.2"><a 
href="#rfc.section.6.2.2">6.2.2</a>&nbsp;Address</h3><p 
id="rfc.section.6.2.2.p.1">The address element in layer 3 ports must consist 
of the layer 3 address for the port.</p><h3 id="rfc.section.6.2.3"><a 
href="#rfc.section.6.2.3">6.2.3</a>&nbsp;Netmask</h3><p 
id="rfc.section.6.2.3.p.1">The layer 3 port has an optional element netmask. 
This element is a string that containing the netmask for the address. If the 
address type is ipv4, the contents must consist of a netmask in 
dotted-decimal form. If the address type is ipv6, the contents must consist 
of an ipv6 netmask in colon-separated hexadecimal format. If the address type 
is any other value, the contents of the netmask are unspecified.</p><h2 
id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;Network</h2><h3 
id="rfc.section.6.3.1"><a 
href="#rfc.section.6.3.1">6.3.1</a>&nbsp;Subnet</h3><p 
id="rfc.section.6.3.1.p.1"
 >The layer 3 network element may contain a subnet element to!
  describ
e the range of addresses contained in the network. This element must contain 
a layer 3 address element and a netmask element. The layer 3 address element 
may contain any address in the range contained in the network. The contents 
of the netmask element depend on the type of the address. If the address type 
is ipv4, the netmask element must contain a netmask in dotted-decimal form. 
If the address type is ipv6, the netmask element must contain a number 
corresponding to the ipv6 netmask.</p><h3 id="rfc.section.6.3.2"><a 
href="#rfc.section.6.3.2">6.3.2</a>&nbsp;ASN</h3><p 
id="rfc.section.6.3.2.p.1">The layer 3 network element may contain an ASN 
element to specify which autonomous system the network is describing. The 
element must contain the autonomous system number as an integer.</p><hr 
class="noprint"><h1 id="rfc.section.7" class="np"><a 
href="#rfc.section.7">7.</a>&nbsp;Layer 4 Elements</h1><p 
id="rfc.section.7.p.1"> </p><h2 id="rfc.section.7.1"><a 
href="#rfc.section.7.1">7.1<
 /a>&nbsp;Type</h2><p id="rfc.section.7.1.p.1">The type in layer 4 elements, 
if included, must be the transport layer protocol of that element. For 
example, a tcp overlap network would have type "tcp".</p><h2 
id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;Port</h2><h3 
id="rfc.section.7.2.1"><a 
href="#rfc.section.7.2.1">7.2.1</a>&nbsp;Name</h3><p 
id="rfc.section.7.2.1.p.1">The name element in layer 4 ports may use the type 
"port". If so, the element must contain the number for that port. If a layer4 
element name has no "type" specified, the format of the element should be of 
the form "protocol:port". For example, a tcp service listening on port 80 
would be described as "tcp:80".</p><h3 id="rfc.section.7.2.2"><a 
href="#rfc.section.7.2.2">7.2.2</a>&nbsp;Address</h3><p 
id="rfc.section.7.2.2.p.1">The format of the address element differs in a 
layer 4 port. If no type is specified, the address must be of the form 
"ip:port". The ip corresponds to the underlying layer3 
 address. If the underlying address is an ipv6 address, the c!
 onventio
n is "[ip]:port". In this context, the ip must be the same as the interface 
underlying the layer 4 port.</p><p id="rfc.section.7.2.2.p.2">Another 
possible form can be used if the type is set to "url" which means that the 
element is formatted as a URL. In this case, the format of the element must 
be of the form "protocol://layer3 address:port". If the layer 3 address if of 
type ipv6, the format of the url must be of the form "protocol://[ipv6 
address]:port".</p><h3 id="rfc.section.7.2.3"><a 
href="#rfc.section.7.2.3">7.2.3</a>&nbsp;Port Number</h3><p 
id="rfc.section.7.2.3.p.1">The layer 4 port has a required element portNum. 
This element consists of an integer that contains the port number that the 
protocol is listening on.</p><hr class="noprint"><h1 id="rfc.section.8" 
class="np"><a href="#rfc.section.8">8.</a>&nbsp;Control Plane 
Elements</h1><hr class="noprint"><h1 id="rfc.section.9" class="np"><a 
href="#rfc.section.9">9.</a>&nbsp;<a id="xml_namespace" 
href="#xml_namespace">XM
 L Namespaces</a></h1><p id="rfc.section.9.p.1">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.</p><p 
id="rfc.section.9.p.2">This version of the schema includes layers subdivided 
by the layer of the OSI protocol model.</p><p id="rfc.section.9.p.3">All 
namespaces contain the elements defined in the base namespace. The elements 
in each subnamespace contain all the elements and properties defined 
previously. Each namespace may redefine the meaning of elements or add new 
elements. However, it may not remove any elements that were previously 
defined.</p><p id="rfc.section.9.p.4">When released, each version of a 
namespace must specify the versions of thei
 r parent namespaces. If a new version of a parent namespace !
 comes ou
t, the version of the child namespace MUST be incremented to add any new 
elements or properties added in the parent namespace.</p><p 
id="rfc.section.9.p.5">Example Namespaces: Base: 
http://ogf.org/schema/network/topology/base/20070707/ Layer 2: 
http://ogf.org/schema/network/topology/l2/20070707/ Ethernet: 
http://ogf.org/schema/network/topology/l2/ethernet/20070707/</p><hr 
class="noprint"><h1 id="rfc.section.10" class="np"><a 
href="#rfc.section.10">10.</a>&nbsp;<a id="versioning" 
href="#versioning">Versioning</a></h1><p id="rfc.section.10.p.1">Completely 
lifted from NM doc.. the issues are the same. maybe we just reference</p><p 
id="rfc.section.10.p.2">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.10.p.3">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.11" class="np"><a 
href="#rfc.section.11">11.</a>&nbsp;<a id="relationships" 
href="#relationships">Relationships Among Elements</a></h1><p 
id="rfc.section.11.p.1">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.</p><p 
id="rfc.section.11.p.2">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 relati
 onship this element is defining. Contained within the elemen!
 t is a l
ist idRef elements containing pointers to all the topology elements related 
to the current topology element in the specified fashion.</p><p 
id="rfc.section.11.p.3">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 underneath 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 fully-qualified identifiers for the 
unidirectional links that make it up.</p><p id="rfc.section.11.p.4">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 ex
 port 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.</p><hr class="noprint"><h1 id="rfc.section.12" class="np"><a 
href="#rfc.section.12">12.</a>&nbsp;<a id="topo_base_schema" 
href="#topo_base_schema">Base Topology Schema</a></h1><p 
id="rfc.section.12.p.1"> </p><div id="rfc.figure.u.11"></div><pre>
 # ##############################################################
-# 
-# File:      nmbase.rnc - Main schema definition
-# Version:   $Id: nmbase.rnc 230 2007-05-07 13:12:03Z swany $
-# Purpose:   This is the main schema file, it defines the
-#             general structure of an NMWG message or store
-# 
+#
+# File:    nmtopo_base.rnc - Schema to describe network elements
+# Version: $Id: nmtopo_base.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
 
-
 # ##############################################################
 # Namespace definitions
 # ##############################################################
-namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
+ default namespace nmtb =
+   "http://ogf.org/schema/network/topology/base/20070707/";
 
+# External schema files
+ include "nmtypes.rnc"
 
-# ##############################################################
-# Include additional functionality from other files
-# ##############################################################
-include "nmtime.rnc"
-include "filter.rnc"
+# generic Topology can be a root element
+ start |= Topology
 
-# ##############################################################
-# Every NMWG document should begin with either a 'store' or 
-# 'message' element
-# Patterns are defined for the content of each element.
-# 
-# Example (using message):
-# 
-# &lt;nmwg:message id="OPTIONAL_ID" 
-#               messageIdRef="OPTIONAL_REFERENCE_ID"
-#               type="REQUIRED_TYPE"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL PARAMETERS --&gt;
-#
-#   &lt;!-- OPTIONAL (MULTIPLE) METADATA --&gt;
-# 
-#   &lt;!-- OPTIONAL (MULTIPLE) DATA --&gt;
-#  
-# &lt;/nmwg:message&gt;
-# 
-# ##############################################################
+ Topology = element topology {
+     Domain*
+     &amp; BaseNode*
+     &amp; BaseLink*
+     &amp; BasePort*
+     &amp; BaseNetwork*
+     &amp; BasePath*
+   }
 
-start =
-        (
-                element nmwg:message {
-                        MessageContent
-                } |
-                element nmwg:store {
-                        StoreContent
-                }
-        )
+ Domain = element domain {
+     Identifier?
+     &amp; IdReference?
+     &amp; BaseNode*
+     &amp; BaseLink*
+     &amp; BaseNetwork*
+     &amp; BasePath*
+   }
 
-MessageContent =
-        Identifier? &amp; 
-        MessageIdentifierRef? &amp;
-        Type &amp;
-        Parameters? &amp;                        
-        (
-                Metadata |  
-                Data
-        )+
-        
-        
-StoreContent = 
-        Identifier? &amp; 
-        MessageIdentifierRef? &amp;
-        Type &amp;
-        Parameters? &amp;                        
-        (
-                Metadata |  
-                Data
-        )+        
+## ########################
+## generic node
+## ########################
+ BaseNode = element node { BaseNodeContent }
+ BaseNodeContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element role { xsd:string }?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element location { LocationContent }?
+   &amp; element contact { ContactInformationContent }*
+   &amp; element comments { xsd:string }*
+   &amp; BasePort*
+   &amp; BaseService*
 
+ ContactInformationContent =
+   attribute priority { xsd:integer }?
+   &amp; element email { xsd:string }?
+   &amp; element phoneNumber { xsd:string }?
+   &amp; element administrator { xsd:string }?
+   &amp; element institution { xsd:string }?
 
+ LocationContent =
+   element continent { xsd:string }?
+   &amp; element country { xsd:string }?
+   &amp; element zipcode { xsd:integer }?
+   &amp; element state { xsd:string }?
+   &amp; element institution { xsd:string }?
+   &amp; element city { xsd:string }?
+   &amp; element streetAddress { xsd:string }?
+   &amp; element floor { xsd:string }?
+   &amp; element room { xsd:string }?
+   &amp; element cage { xsd:string }?
+   &amp; element rack { xsd:string }?
+   &amp; element shelf { xsd:string }?
+   &amp; element latitude { xsd:float }?
+   &amp; element longitude { xsd:float }?
+
+## ########################
+## generic port
+## ########################
+ BasePort = element port { BasePortContent }
+ BasePortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; BaseLink*
+
+## ########################
+## generic link
+## ########################
+ BaseLink = element link { BaseLinkContent }
+ BaseLinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## generic network
+## ########################
+ BaseNetwork = element network { BaseNetworkContent }
+ BaseNetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## generic path
+## ########################
+ BasePath =
+   element path { BasePathContent }
+
+# a path consists of a list of hops
+ BasePathContent =
+   Identifier
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element comments { xsd:string }*
+   &amp; element hop { HopContent }*
+
+ HopContent =
+   Identifier,
+   (
+     DomainIdRef
+     | NodeIdRef
+     | PortIdRef
+     | LinkIdRef
+     | PathIdRef
+     | NetworkIdRef
+   )
+
+## ########################
+## generic endpoint pair
+## ########################
+ BaseEndPointPair =
+   element endPointPair { BaseEndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ BaseEndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (BasePortContent | PortIdRef) }
+   &amp; element dst { (BasePortContent | PortIdRef) }
+
+## ########################
+## generic service
+## ########################
+ BaseService =
+   element service { BaseServiceContent }
+
+ BaseServiceContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; Relation*
+   &amp; Lifetime?
+                        </pre><hr class="noprint"><h1 id="rfc.section.13" 
class="np"><a href="#rfc.section.13">13.</a>&nbsp;<a id="topo_l2_schema" 
href="#topo_l2_schema">Layer 2 Topology Schema</a></h1><p 
id="rfc.section.13.p.1"> </p><div id="rfc.figure.u.12"></div><pre>
 # ##############################################################
-# Metadata is the information that describes data.  This
-# information doesn't change over time
 #
+# File:    nmtopo_l2.rnc - Schema to describe L2 network elements
+# Version: $Id: nmtopo_l2.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# &lt;nmwg:metadata id="REQUIRED_ID" 
-#                metadataIdRef="OPTIONAL_REFERENCE_ID"
-#                xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TBD OPTIONAL SUBJECT --&gt;
-# 
-#   &lt;!-- TBD OPTIONAL PARAMETERS --&gt;
-#
-#   &lt;!-- TBD OPTIONAL EVENTTYPE --&gt;
-# 
-#   &lt;!-- TBD OPTIONAL KEY --&gt;
-#  
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt; 
-#
-# &lt;/nmwg:metadata&gt;
-# 
 # ##############################################################
-        
-Metadata = 
-        element nmwg:metadata {
-                (
-                        Identifier &amp;
-                        MetadataIdentifierRef? &amp;
-                        MetadataContent
-                ),
-                anyElement*
-        }
 
-MetadataBlock =
-        Subject? &amp;
-        Parameters?
-        
-MetadataContent = 
-        (
-                MetadataBlock |
-                FilterMetadataBlock                
-        ) &amp;        
-        EventType? &amp;
-        Key?        
-
-
 # ##############################################################
-# Subject identifies an endPoint (or points), perhaps the name of
-# a service or some other form of physical location. For the
-# purpose of the general case, we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.  
-#
-# Example: 
-# 
-# &lt;nmwg:subject id="REQUIRED_ID" 
-#               metadataIdRef="OPTIONAL_REFERENCE_ID"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- ANY ELEMENT IN ANY NAMESPACE --&gt;
-#  
-# &lt;/nmwg:subject&gt;
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl2 =
+           "http://ogf.org/schema/network/topology/l2/20070707/";
 
-Subject = 
-        element nmwg:subject {
-                SubjectContent
-        }
+# External schema files
+ include "nmtypes.rnc"
 
-SubjectContent = 
-        (
-                Identifier &amp;
-                MetadataIdentifierRef?        
-        ),
-        anyElement*
-        
+## ########################
+## layer 2 port
+## ########################
+ L2Port = element port { L2PortContent }
+ L2PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element ifName {xsd:string }?
+   &amp; element ifIndex {xsd:integer }?
+   &amp; element vlan {xsd:integer }?
+   &amp; element vlanRangeAvailability { xsd:string }
+   &amp; L2Link*
 
+## ########################
+## layer 2 link
+## ########################
+ L2Link = element link { L2LinkContent }
+ L2LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+   &amp; element vlan {xsd:integer }?
+
+## ########################
+## layer 2 network
+## ########################
+ L2Network = element network { L2NetworkContent }
+ L2NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element vlan {xsd:integer }?
+
+## ########################
+## layer 2 endpoint pair
+## ########################
+ L2EndPointPair =
+   element endPointPair { L2EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L2EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L2PortContent | PortIdRef | Address) }
+   &amp; element dst { (L2PortContent | PortIdRef | Address) }
+                        </pre><hr class="noprint"><h1 id="rfc.section.14" 
class="np"><a href="#rfc.section.14">14.</a>&nbsp;<a id="topo_l3_schema" 
href="#topo_l3_schema">Layer 3 Topology Schema</a></h1><p 
id="rfc.section.14.p.1"> </p><div id="rfc.figure.u.13"></div><pre>
 # ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways in: 1) the message to signify items such as time stamp
-# or authorization or 2) metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id and encloses one to many 'parameter' elements.
-# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please;
-# software using this should consider complex elements, then
-# text, and finally the value attribute; exceptions should
-# be thrown on duplicates).
 #
-# Example: 
-# 
-# &lt;nmwg:parameters id="REQUIRED_ID" 
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;nmwg:parameter name="REQUIRED_NAME" value="OPTIONAL_VALUE"
-#                   xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#     &lt;!-- ANY TEXT, OR ANY ELEMENT ANY NAMESPACE (IF YOU DID NOT 
-#          USE THE VALUE ATTRIBUTE) --&gt;
-# 
-#   &lt;/nmwg:parameter&gt;
-#  
-#   &lt;!-- MORE PARAMETERS --&gt;
-#   
-# &lt;/nmwg:parameters&gt;
-# 
-# The namespaces can of course be different.
-# 
+# File:    nmtopo_l3.rnc - Schema to describe L3 network elements
+# Version: $Id: nmtopo_l3.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
 
-Parameters = 
-        element nmwg:parameters {
-                ParametersContent
-        }
-   
-ParametersContent =    
-        Identifier &amp;
-        Parameter+
-   
-Parameter = 
-        element nmwg:parameter { 
-                attribute name { xsd:string } &amp;
-                (
-                        attribute value { xsd:string } |
-                        (
-                                anyElement |
-                                text
-                        )
-                )
-        }   
+# ##############################################################
+# Namespace definitions
+# ##############################################################
+ default namespace nmtl3 =
+           "http://ogf.org/schema/network/topology/l3/20070707/";
 
+# External schema files
+ include "nmtypes.rnc"
 
-# ##############################################################
-# Event type is a simple text element used to describe the
-# characteristic or event of the data.
-#
-# Example: 
-# 
-# &lt;nmwg:eventType xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TEXT --&gt;
-#  
-# &lt;/nmwg:eventType&gt;
-# 
-# ##############################################################        
+## ########################
+## layer 3 port
+## ########################
+ L3Port = element port { L3PortContent }
+ L3PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element netmask { xsd:string }?
+   &amp; L3Link*
 
-EventType =
-        element nmwg:eventType { xsd:string }      
+## ########################
+## layer 3 link
+## ########################
+ L3Link = element link { L3LinkContent }
+ L3LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+   &amp; element netmask { xsd:string }?
 
-   
+## ########################
+## layer 3 network
+## ########################
+ L3Network = element network { L3NetworkContent }
+ L3NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element subnet {
+        Address
+        &amp; element netmask { xsd:string }
+     }?
+   &amp; element asn { xsd:integer }
+
+## ########################
+## layer 3 endpoint pair
+## ########################
+ L3EndPointPair =
+   element endPointPair { L3EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L3EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L3PortContent | PortIdRef | Address) }
+   &amp; element dst { (L3PortContent | PortIdRef | Address) }
+                        </pre><hr class="noprint"><h1 id="rfc.section.15" 
class="np"><a href="#rfc.section.15">15.</a>&nbsp;<a id="topo_l4_schema" 
href="#topo_l4_schema">Layer 4 Topology Schema</a></h1><p 
id="rfc.section.15.p.1"> </p><div id="rfc.figure.u.14"></div><pre>
 # ##############################################################
-# The key is used to return a 'pointer' or otherwise special piece
-# of identifying information in response to a request. For now, 
-# this information is enclosed only within a parameters block.
-# The optional ID can be used to track past searches.
 #
-# Example: 
-# 
-# &lt;nmwg:key id="OPTIONAL_ID" 
-#           xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL PARAMETERS --&gt;
-#  
-# &lt;/nmwg:key&gt;
-# 
-# ##############################################################
-   
-Key = 
-        element nmwg:key {
-                Identifier? &amp;
-                (
-                        Parameters |
-                        FilterParameters                                
-                )
-        }        
-        
-           
-# ##############################################################
-# The data block is complex and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet. 
+# File:    nmtopo_l4.rnc - Schema to describe L4 network elements
+# Version: $Id: nmtopo_l4.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# &lt;nmwg:data id="REQUIRED_ID" 
-#            metadataIdRef="OPTIONAL_REFERENCE_ID" 
-#            xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- OPTIONAL (MULTIPLE) METADATA --&gt;
-# 
-#           &lt;!-- OR --&gt;
-#
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND 
-#        OPTIONAL (MULTIPLE) DATUM ELEMENTS--&gt;
-# 
-#           &lt;!-- OR --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS --&gt;
-# 
-#           &lt;!-- OR --&gt;
-#  
-#   &lt;!-- OPTIONAL (MULTIPLE) KEY ELEMENTS --&gt;
-# 
-#           &lt;!-- OR --&gt;
-# 
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt;
-#   
-# &lt;/nmwg:data&gt;
-# 
 # ##############################################################
-   
-Data =
-        element nmwg:data {
-                (
-                        Identifier &amp;
-                        MetadataIdentifierRef? &amp;
-                        (
-                                Metadata* |
-                                (
-                                        commonTime+ &amp; 
-                                        Datum*
-                                ) |
-                                Datum* |
-                                Key*
-                        )
-                ),
-                anyElement*
-        }
 
 # ##############################################################
-# CommonTime is used as a shortcut that is able to 'factor out' 
-# a frequently occurring time range that a group of datum (or 
-# other) elements might share, thus reducing the verbosity of the 
-# XML representation. CommonTime is similar to the other NMWG time 
-# stamps (from nmtime.rnc) in its potential time representations.
-#
-# It is unfortunate that it needs to be in this file and not
-# nmtime.rnc, but as it occurs outside the datum, it is here.
-#
-# Example: 
-# 
-# &lt;nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
-#                  duration="OPTIONAL_DURATION" 
-#                  inclusive="OPTIONAL_INCLUSIVE_FLAG"
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
-# 
-#   &lt;!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR
-#         DURATION) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE
-#         ATTRIBUTE) --&gt;
-#  
-#   &lt;!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS --&gt;
-# 
-#   &lt;!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --&gt;
-# &lt;/nmwg:commonTime&gt;
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl4 =
+           "http://ogf.org/schema/network/topology/l4/20070707/";
 
-commonTime = 
-        element nmwg:commonTime {
-                (
-                        Type &amp;
-                        (
-                                TimeStamp |
-                                (
-                                        StartTime &amp; 
-                                        (
-                                                EndTime | 
-                                                Duration 
-                                        )
-                                )
-                        ) &amp;
-                        Datum*
-                ),
-                anyElement*
-        }
+# External schema files
+ include "nmtypes.rnc"
 
+## ########################
+## layer 4 port
+## ########################
+ L4Port = element port { L4PortContent }
+ L4PortContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Address*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element capacity { xsd:string }?
+   &amp; element mtu { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element portNum { xsd:integer }?
+   &amp; L4Link*
 
+## ########################
+## layer 4 link
+## ########################
+ L4Link = element link { L4LinkContent }
+ L4LinkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element remoteLinkId { xsd:string }
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element globalName {
+       attribute type { xsd:string }?
+       &amp; xsd:string
+     }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## layer 4 network
+## ########################
+ L4Network = element network { L4NetworkContent }
+ L4NetworkContent =
+   Identifier?
+   &amp; IdReference?
+   &amp; NodeIdRef*
+   &amp; PortIdRef*
+   &amp; LinkIdRef*
+   &amp; Name*
+   &amp; Relation*
+   &amp; Lifetime?
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+
+## ########################
+## layer 4 endpoint pair
+## ########################
+ L4EndPointPair =
+   element endPointPair { L4EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L4EndPointPairContent =
+   Name*
+   &amp; element type { xsd:string }?
+   &amp; element description { xsd:string }?
+   &amp; element comments { xsd:string }*
+   &amp; element src { (L4PortContent | PortIdRef | Address) }
+   &amp; element dst { (L4PortContent | PortIdRef | Address) }
+                        </pre><hr class="noprint"><h1 id="rfc.section.16" 
class="np"><a href="#rfc.section.16">16.</a>&nbsp;<a 
id="topo_ctrlplane_schema" href="#topo_ctrlplane_schema">Control Plane 
Topology Schema</a></h1><p id="rfc.section.16.p.1"> </p><div 
id="rfc.figure.u.15"></div><pre>
 # ##############################################################
-# The datum is meant to be generic in this case because specific
-# namespace declarations should be used to better define what
-# format that datum should have.
-#
-# Example: 
 # 
-# &lt;nmwg:datum ANY_ATTRIBUTE
-#             xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"&gt;
+# File:        nmtopo_ctrlplane.rnc
+# Version: $Id: nmtopo_ctrlplane.rnc 267 2007-09-14 17:56:01Z swany $
 # 
-#   &lt;!-- ANY ELEMENT IN ANY NAMESPACE OR ANY TEXT --&gt;
-#  
-# &lt;/nmwg:datum&gt;
-# 
 # ##############################################################
 
-Datum =
-        element nmwg:datum {
-                anyThing  
-        }
-        
-         
-# ##############################################################
-# Common elements are defined as named patterns as they are re- 
-# used several times.
-# ##############################################################
-                
-Identifier =
-        attribute id { xsd:string }
+namespace CtrlPlane =
+  "http://ogf.org/schema/network/topology/ctrlPlane/20070707/";
+namespace nmtl3 =
+  "http://ogf.org/schema/network/topology/l3/20070707/";
 
-MetadataIdentifierRef =
-        attribute metadataIdRef { xsd:string }
+include "nmtopo_l3.rnc"
 
-MessageIdentifierRef =
-        attribute messageIdRef { xsd:string }
-    
-Type = 
-        attribute type { xsd:string }    
+## Definition of the topology element
+start |= element CtrlPlane:topology { CtrlPlaneTopologyContent }
 
 
-# ##############################################################
-# This sequence allows any element, attribute, or text (regardless 
-# of name or namespace) into the document when invoked.
-# ##############################################################
+CtrlPlaneTopologyContent =
+  Identifier,
+ # Parameters,
+  element CtrlPlane:idcId { xsd:string }?,
+  (
+    CtrlPlaneDomain |
+    element CtrlPlane:domainSignature {
+      CtrlPlaneDomainSignatureContent
+    }
+  )*
 
-anyElement = 
-        element * { 
-                anyThing 
-        }
+## this a placeholder until we discuss and experiment with signatures
+CtrlPlaneDomainSignatureContent =
+  attribute domainId { xsd:string },
+  anyElement
+  
+CtrlPlaneDomain =
+  element CtrlPlane:domain {
+    Identifier,
+    ( 
+      CtrlPlaneNode*
+      &amp; CtrlPlanePort*
+      &amp; CtrlPlaneLink*
+    )
+  }
+  
+CtrlPlaneNode =
+  element CtrlPlane:node {
+    Identifier,
+    element CtrlPlane:address { xsd:string | L3Address }?,
+    CtrlPlanePort*
+  }
+  
+CtrlPlanePort =
+  element CtrlPlane:port {
+    Identifier,
+    CtrlPlaneCapacityContent,
+    CtrlPlaneLink*
+  }
+  
+CtrlPlaneLink =
+  element CtrlPlane:link {
+    Identifier,
+    ( 
+      element CtrlPlane:remoteLinkId { L3Address }
+      &amp; element CtrlPlane:remotePortId { L3Address }
+      &amp; 
+      ## only use when remotePortId isn't fully qualified
+        element CtrlPlane:remoteNodeId { L3Address }
+      &amp; element CtrlPlane:remoteDomainId { L3Address }
+      &amp; element CtrlPlane:trafficEngineeringMetric { xsd:string }
+      &amp; element CtrlPlane:linkProtectionTypes { xsd:string }*
+      &amp; CtrlPlaneCapacityContent
+      &amp; element CtrlPlane:administrativeGroups {
+        CtrlPlaneAdministrativeGroup
+      }*
+      &amp; element CtrlPlane:SwitchingCapabilityDescriptors {
+        CtrlPlaneSwitchingCapabilityDescriptor+
+      }
+    )
+  }
+  
+# Begin path and endpoint additions
+CtrlPlanePath =
+  element CtrlPlane:path { CtrlPlanePathContent }
 
-anyAttribute = 
-        attribute * { text }
+# a path consists of a list of hops, and/or links
+CtrlPlanePathContent =
+  Identifier &amp;
+    element CtrlPlane:hop { CtrlPlaneHopContent }*
 
-anyThing = 
-        ( 
-                anyElement | 
-                anyAttribute | 
-                text 
-        )*
-        
-        
-# ##############################################################
-# This sequence allows any element, attribute, or text (only in the 
-# NMWG namespace) into the document when invoked.
-# ##############################################################
-        
-anyNMWGElement = 
-        element nmwg:* { 
-                anyNMWGThing 
-        }
+  
+CtrlPlaneHopContent =
+  Identifier,
+  ( 
+    DomainIdRef |
+    NodeIdRef |
+    PortIdRef |
+    LinkIdRef
+  )
+  
+# End path and endpoint
 
-anyNMWGAttribute = 
-        attribute * { text }
+CtrlPlaneAdministrativeGroup =
+  element CtrlPlane:group { xsd:int }
+  &amp; element CtrlPlane:groupID { xsd:string }?
+  
+CtrlPlaneSwitchingCapabilityDescriptor =
+  element switchingcapType {
+    "psc-1"
+    | "psc-2"
+    | "psc-3"
+    | "psc-4"
+    | "l2sc"
+    | "tdm"
+    | "lsc"
+    | "fsc"
+  }
+  &amp; element encodingType {
+      "packet"
+      | "ethernet"
+      | "pdh"
+      | "sdh/sonet"
+      | "digital wrapper"
+      | "lambda"
+      | "fiber"
+      | "fiberchannel"
+      | xsd:string
+    }
+  &amp; element switchingCapabilitySpecficInfo {
+      CtrlPlaneSwitchingCapabilitySpecficInfo
+    }+
+    
+CtrlPlaneSwitchingCapabilitySpecficInfo =
+  CtrlPlaneSwitchingCapabilitySpecficInfo_psc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_tdm
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_lsc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_fsc
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_psc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_tdm =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_lsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_fsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc =
+  element interfaceMTU { xsd:int }
+  &amp; element vlanRangeAvailability { xsd:string }
 
-anyNMWGThing = 
-        ( 
-                anyNMWGElement | 
-                anyNMWGAttribute | 
-                text 
-        )*        
-           </pre> </p><hr class="noprint"><h1 id="rfc.section.8" 
class="np"><a href="#rfc.section.8">8.</a>&nbsp;Security Concerns</h1><p 
id="rfc.section.8.p.1">There are important security concerns associated with 
the generation and distribution of network measurement information. For 
example, ISPs frequently consider network configuration and performance 
information to be proprietary. Furthermore, observing traffic, and, in 
particular, collecting packet headers, is frequently considered a violation 
of the presumption of privacy on the network. Systems that collect the 
measurements described here are sometimes regarded as invasive, and, indeed, 
poorly designed or configured monitoring tools can consume a disproportionate 
amount of network bandwidth. Port blocking, protocol blocking, and traffic 
shaping can impact many measurement tools. Tools, such as traceroute, that 
send UDP probes to increasing port numbers can appear to be port scans and 
raise security alerts.</p><p id="rfc.s
 ection.8.p.2">We do not address those concerns in this document, but 
implementers are encouraged to consider the security implications of 
generating and distributing measurement information. While distribution of 
end-to-end application-level measurements is generally accepted, measurements 
that identify individual users or consume noticeable amounts of resources 
should be taken carefully, and the distribution of information to other sites 
that cannot be obtained readily by other users at those sites should be 
considered carefully.</p><h1 class="np" id="rfc.references"><a 
href="#rfc.section.9">9.</a> References</h1><table summary="References" 
border="0" cellpadding="2"><tr><td class="topnowrap"><b 
id="tridentcom">[1]</b></td><td class="top">Zurawski, J., Swany, M., and D. 
Gunter, &#8220;A Scalable Framework for Representation and Exchange of
-                 Network Measurements&#8221;, In Proceedings of 2nd 
International IEEE/Create-Net
-         Conference on Testbeds and Research Infrastructures for the
-         Development of Networks and Communities (Tridentcom
-         2006).</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)
-        <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></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>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 &#8220;As Is&#8221; 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><hr class="noprint"><h1 class="np"><a id="rfc.ipr" 
href="#rfc.ipr">Intellectual Property</a></h1><p>The OGF takes no position 
regarding the validity or scope of any intellectual property or other rights 
that might be claimed to pertain to the implementation or use of the 
technology described in this document or the extent to which any license 
under such rights might or might not be available; neither does it represent 
that it has made any effort to identify any such rights. Copies of claims of 
rights made available for publication and any assurance
 s of licenses to be made available, or the result of an atte!
 mpt made
 to obtain a general license or permission for the use of such proprietary 
rights by implementers or users of this specification can be obtained from 
the OGF Secretariat.</p><p>The OGF invites any interested party to bring to 
its attention any copyrights, patents or patent applications, or other 
proprietary rights, which may cover technology that may be required to 
practice this recommendation. Please address the information to the OGF 
Executive Director.</p></body></html>
\ No newline at end of file
+## Capacity Description Pattern  
+CtrlPlaneCapacityContent =
+  element CtrlPlane:capacity { xsd:string }?
+  &amp; element CtrlPlane:maximumReservableCapacity { xsd:string }?
+  &amp; element CtrlPlane:minimumReservableCapacity { xsd:string }?
+  &amp; element CtrlPlane:granularity { xsd:string }?
+  &amp; element CtrlPlane:unreservedCapacity { xsd:string }?
+                          </pre><hr class="noprint"><h1 id="rfc.section.17" 
class="np"><a href="#rfc.section.17">17.</a>&nbsp;Security Concerns</h1><p 
id="rfc.section.17.p.1">There are important security concerns associated with 
the generation and distribution of network measurement information. For 
example, ISPs frequently consider network configuration and performance 
information to be proprietary. Furthermore, observing traffic, and, in 
particular, collecting packet headers, is frequently considered a violation 
of the presumption of privacy on the network. Systems that collect the 
measurements described here are sometimes regarded as invasive, and, indeed, 
poorly designed or configured monitoring tools can consume a disproportionate 
amount of network bandwidth. Port blocking, protocol blocking, and traffic 
shaping can impact many measurement tools. Tools, such as traceroute, that 
send UDP probes to increasing port numbers can appear to be port scans and 
raise security ale
 rts.</p><p id="rfc.section.17.p.2">We do not address those concerns in this 
document, but implementers are encouraged to consider the security 
implications of generating and distributing measurement information. While 
distribution of end-to-end application-level measurements is generally 
accepted, measurements that identify individual users or consume noticeable 
amounts of resources should be taken carefully, and the distribution of 
information to other sites that cannot be obtained readily by other users at 
those sites should be considered carefully.</p><h1 class="np" 
id="rfc.references"><a href="#rfc.section.18">18.</a> References</h1><table 
summary="References" border="0" cellpadding="2"><tr><td class="topnowrap"><b 
id="refs.tridentcom">[1]</b></td><td class="top">Zurawski, J., Swany, M., and 
D. Gunter, &#8220;A Scalable Framework for Representation and Exchange
+            of Network Measurements&#8221;, 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, &#8220;Enabling Network Measurement Portability 
Through a
+            Hierarchy of Characteristics&#8221;, 4th International Workshop 
on Grid Computing (Grid2003), November&nbsp;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)
+        <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></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>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 abov
 e 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 &#8220;As Is&#8221; 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><hr class="noprint"><h1 class="np"><a id="rfc.ipr" 
href="#rfc.ipr">Intellectual Property</a></h1><p>The OGF takes no position 
regarding the validity or scope of any intellectual property or other rights 
that might be claimed to pertain to the implementation or use of the 
technology described in this document or the extent to which any license 
under such rights might or might not be available; neither does it represent 
that it has made any effort to identify any such rights. Copies of claims of 
rights made available for publication and any assuran
 ces of licenses to be made available, or the result of an at!
 tempt ma
de to obtain a general license or permission for the use of such proprietary 
rights by implementers or users of this specification can be obtained from 
the OGF Secretariat.</p><p>The OGF invites any interested party to bring to 
its attention any copyrights, patents or patent applications, or other 
proprietary rights, which may cover technology that may be required to 
practice this recommendation. Please address the information to the OGF 
Executive Director.</p></body></html>
\ No newline at end of file

Modified: trunk/nmwg/doc/nm-topo/nm-topo.pdf
===================================================================
(Binary files differ)

Modified: trunk/nmwg/doc/nm-topo/nm-topo.xml
===================================================================
--- trunk/nmwg/doc/nm-topo/nm-topo.xml  2008-05-20 15:55:47 UTC (rev 347)
+++ trunk/nmwg/doc/nm-topo/nm-topo.xml  2008-05-20 16:05:26 UTC (rev 348)
@@ -2,602 +2,1843 @@
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 
 <!--<rfc category="info" ipr="full3978" docName="schema-overview.txt">-->
-    <rfc>
-        <?xml-stylesheet type='text/xsl'
+<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" ?>
-        <!-- <?rfc-ext support-rfc2731="no"?>
+  <?rfc toc="yes" ?>
+  <?rfc symrefs="yes" ?>
+  <?rfc sortrefs="yes"?>
+  <?rfc iprnotified="no" ?>
+  <?rfc private="1" ?>
+  <?rfc strict="no" ?>
+  <!-- <?rfc-ext support-rfc2731="no"?>
         <?rfc-ext authors-section="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>
+  <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 description 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 anchor="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 anchor="design_philosophy" title="Design Philosophy">
 
-                <t>
-                    Reuse the namespace thing from NM.
-                </t>
-            </section>
+      <t> Networks have basic components and any network
+        representation must include these basic elements. Like the
+        Network Measurement schema, we define the basic elements and
+        vary the namespace of them to indicate specific components. </t>
 
-            <section id="identifiers" title="Identifiers">
+    </section>
 
-                The network topology identifiers have been designed to be 
flexible, be explicit
-                in their meaning and still be reasonably human-readable. 
+    <section anchor="identifiers" title="Identifiers">
+      <t> The network topology identifiers have been designed to be
+        flexible, be explicit in their meaning and still be reasonably
+        human-readable. </t>
 
-                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:".
+      <t>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:".</t>
 
-                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''. 
+      <t>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''.</t>
 
-                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.
+      <t>A single ``*'' may appear instead of a name/value field to
+       connote an identifier for an unknown network element of unknown type.
+       If a '*' field is included, that field MUST be the last field in the
+       identifier.</t>
 
-                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.
+      <t>The name/value pairs MUST be ordered from most general
+        network entity to most specific network entity. For example,
+        the domain field MUST come before the node field which MUST
+        come before the port field. There MUST NOT exist repeated
+        fields in the identifier.</t>
 
-                There MUST NOT exist repeated fields in the identifier.
+      <section anchor="fields" title="Description of Fields">
+        <section title="Domain" anchor="fields_domain">
 
-                <section id="fields">
-                    <section title="Domain" id="fields_domain">
+          <t>
+           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 be a globally unique DNS name for that domain, and MUST
+           NOT include any trailing spaces. Setting the value of this field 
to
+           '*' connotes the domain is unknown.
+          </t>
+          <t>
+            <figure>
+              <artwork> urn:ogf:network:domain=dcn.internet2.edu
+                urn:ogf:network:domain=* (this)
+                urn:ogf:network:domain=dcn.internet2.edu:* (is shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </artwork>
+            </figure>
+          </t>
 
-                        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.
+        </section>
 
-                        urn:ogf:network:domain=237
-                        urn:ogf:network:domain=*
-                    </section>
+        <section title="Node" anchor="fields_node">
 
-                    <section title="Node" id="fields_node">
+          <t>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. 
+          </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu:node=packrat
+                urn:ogf:network:domain=internet2.edu:node=207.75.164.10
+                urn:ogf:network:domain=internet2.edu:node=Joe's Machine
+                urn:ogf:network:domain=internet2.edu:node=Los Angeles NOC
+                urn:ogf:network:domain=internet2.edu:node=*</artwork>
+            </figure></t>
+        </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="Service" anchor="fields_service">
 
-                        Examples:
+          <t>
+           An identifier for a network-available service MUST include the
+           domain, node and service fields. The node and domain fields MUST 
be
+           identicial to those in the identifier for the node containing the
+           service. The value of the service field can be anything, but MUST
+           be unique in the node and MUST NOT include any trailing spaces. 
The
+           value SHOULD be a human readable description of the service.
+           Setting the value of the node field to '*' connotes the service is
+           unknown. 
+          </t>
+          <t> Examples: <figure>
+              <artwork>
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=http
+               
urn:ogf:network:domain=internet2.edu:node=packrat:service=perfSONAR%20SNMP%20MA
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=ping
+              </artwork>
+            </figure></t>
+        </section>
 
-                        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>
+        <section title="Interfaces" anchor="fields_interfaces">
 
-                    <section title="Interfaces" id="fields_interfaces">
+          <t>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.
+          </t>
+          <t> Examples: <figure>
+              <artwork>
+                urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=207.75.164.10
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=*</artwork>
+            </figure></t>
+        </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"
+          anchor="fields_unilinks">
 
-                        Examples:
+          <t>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. </t>
+          <t> Examples: <figure>
+              <artwork>
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=Link
+                Between Packrat And Router1
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=*
+                (this) urn:ogf:network:domain=dcn.internet2.edu:*
+                (could be shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </artwork>
+            </figure>
+          </t>
+        </section>
 
-                        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>
+        <section title="Bidirectional Domain Links"
+          anchor="fields_bidilinks">
 
-                    <section title="Unidirectional Intra-domain/Inter-domain 
Links" id="fields_unilinks">
+          <t>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. Examples: </t>
+          <t>
+            <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu:link=Link 
Between
+                Packrat And Router1 
urn:ogf:network:domain=internet2.edu:link=*
+              </artwork>
+            </figure>
+          </t>
+        </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 Inter-domain Links"
+          anchor="fields_bidiinterlinks">
 
-                        Examples:
+          <t>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. 
+          </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:link=Link Between Internet2
+                And ESNet urn:ogf:network:link=*</artwork>
+            </figure></t>
+        </section>
 
-                        
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>
+        <section title="Intra-domain Path" anchor="fields_intrapath">
 
-                    <section title="Bidirectional Domain Links" 
id="fields_bidilinks">
+          <t>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. </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu: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=* </artwork>
+            </figure>
+          </t>
+        </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="Inter-domain Path" anchor="fields_interpath">
 
-                        Examples:
+          <t>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.</t>
 
-                        urn:ogf:network:domain=237:link=Link Between Packrat 
And Router1
-                        urn:ogf:network:domain=237:link=*
-                    </section>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:path=DRAGON Path From
+                207.75.164.10 to 134.55.209.97 urn:ogf:network:path=*
+              </artwork>
+            </figure>
+          </t>
+        </section>
 
-                    <section title="Bidirectional Inter-domain Links" 
id="fields_bidiinterlinks">
+        <section title="Network" anchor="fields_network">
 
-                        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.
+          <t>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.</t>
 
-                        Examples:
+          <t>Examples: <figure>
+              
<artwork>urn:ogf:network:domain=internet2.edu:network=207.75.164.0%2F24
+                urn:ogf:network:network=207.0.0.0%2F8
+                urn:ogf:network:network=*</artwork>
+            </figure>
+          </t>
+        </section>
 
-                        urn:ogf:network:link=Link Between Internet2 And ESNet
-                        urn:ogf:network:link=*
-                    </section>
+      </section>
+    </section>
 
-                    <section title="Intra-domain Path" id="fields_intrapath">
+    <section anchor="basic_elements" title="Basic Elements">
+      <t>This schema defines the basic elements that can be used to
+        describe network topologies. </t>
 
-                        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.
+      <t>
+        <!-- exact duplicate of nm-schema-base --> 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>
 
-                        Examples:
+      <section anchor="domain" title="Domain">
+        <t>
+          A domain is a point demarcation used to divide the entities in a
+          topology into administrative groupings according to the
+          administrative domain that controls the entity.
+        </t>
+        <section anchor="domain_id" title="id Attribute">
+          <t>
+            Each domain has an id attribute that contains the
+            fully-qualified identifier for this domain.
+          </t>
+        </section>
+        <section anchor="domain_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 domain. If a domain element has this attribute, it
+            means that this domain element is not the authoritative, it
+            simply contains additional information about the element.
+          </t>
+        </section>
+        <section anchor="domain_entities" title="Entities In The Domain">
+          <t>
+            A domain can have any number of node, link, network and path
+            entities defined immediately underneath it. The entities defined
+            there must all correspond to entities that are in the actual
+            domain. The links that are defined must be bidirectional links.
+            Unidirectional links can only be defined inside of ports.
+          </t>
+        </section>
+      </section>
 
-                        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>
+      <section anchor="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 anchor="node_id" title="id Attribute">
+          <t> Each node has an id attribute that contains the
+            fully-qualified identifier for this node. </t>
+        </section>
+        <section anchor="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.
+          </t>
+        </section>
 
-                    <section title="Inter-domain Path" id="fields_interpath">
+        <section anchor="node_name" title="Name">
+          <t>
+           Node elements can contain one or more name elements to describe 
the
+           node. The name element contains a string and can be filled with 
any
+           value that can be used to name the node. This could include the
+           node's hostname, its default ip address or simply a description of
+           the node.
+          </t>
+          <section anchor="node_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
 
-                        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 anchor="node_role" title="Role">
+          <t>
+            Each node can also include a role element to describe
+            what role this network entity has. The contents of
+           this element are unspecified, but should correspond to the job of
+           the node. If the node is a router, the contents should be 
"router".
+           If the node is an endpoint, the contents should be "endpoint".
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            Existing defined values for the role field are listed in the
+            appendix.
+          </t>
+        </section>
 
-                        Examples:
+        <section anchor="node_address" title="Address">
+          <t>
+           Each node can have one or more address element to describe the
+           addresses that the outside world can use to contact this node.
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </t>
+          <t>
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client 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>
 
-                        urn:ogf:network:path=DRAGON Path From 207.75.164.10 
to 134.55.209.97
-                        urn:ogf:network:path=*
-                    </section>
+        <section anchor="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>
+          <t>
+           Longitude and latitude information SHOULD be included with each
+           node to ease the drawing of topologies.
+         </t>
+        </section>
 
-                    <section title="Network" id="fields_network">
+        <section anchor="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>
 
-                        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.
+          <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>
 
-                        Examples:
+        <section anchor="node_description" title="Description">
+          <t> Each node can include a description element. This
+            element should include a human readable description of the
+            node. </t>
+        </section>
 
-                        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>
+        <section anchor="node_comments" title="Comments">
+          <t> Each node can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the node. </t>
+        </section>
 
-                </section>
+        <section anchor="node_relations" title="Relations">
+          <t> One or more relation elements, which are described
+            later, may be defined inside the node. </t>
+        </section>
 
-                <section id="basic_elements" title="Basic Elements">
-                    <t>This schema defines the basic elements that can be 
used to
-                        describe network topologies.
-                    </t>
+        <section anchor="node_lifetime" title="Lifetime">
+          <t>
+            A node has an optional field lifetime that can be used to 
describe
+            the time during which the node had the properties being described
+            or, in the case of ephemeral nodes, the time during which the 
node
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
 
-                    <t>
-                        <!-- exact duplicate of nm-schema-base -->
-                        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 anchor="node_ports" title="Interfaces">
+          <t>
+            One or more port elements, which are described later, may be
+            defined inside the node as well. These port elements must
+            correspond to interfaces inside the node being described. The
+            actual namespaces of the interfaces can consist of any of the
+            namespaces defined in these schema that have a "port" element.
+          </t>
+        </section>
+      </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="links" title="Links">
+        <t>
+          Nodes are connected by Links, which are edges in the graph
+          model. These Links have properties associated with them.
+        </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="link_id" title="id Attribute">
+          <t>
+            Each link has an id attribute that contains the
+            fully-qualified identifier for the link. 
+          </t>
+        </section>
+        <section id="link_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 link. If a link element has this attribute,
+            it means that this link element is not the
+            authoritative link element, it simply contains
+            additional information about the element.
+          </t>
+        </section>
 
-                            </t>
-                        </section>
+        <section id="link_name" title="Name">
+          <t>
+           Links elements can contain one or more name elements to describe
+           the link. The name element contains a string and can be filled 
with
+           any value that can be used to name the link. This could include an
+           e2emon style link name, a local name for the link or simply a
+           description of the link.
+          </t>
+          <section anchor="link_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
 
-                        <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="link_global_name" title="Global Name">
+          <t>
+            The globalName element can be used to give a
+            globally-unique name to describe the link. This
+            element contains an attribute describing what type
+            of name this element contains. 
+          </t>
+          <t>
+            The types and contents of the element are unspecified as the
+            element is deprecated. Its inclusion in here is due to the
+            prevelance of e2emon services that exist which make use of a
+            globalName field.
+          </t>
+        </section>
+        <section id="link_type" title="Type">  
+          <t>
+            Each link can also include a type element to describe the 
protocol
+            of the link.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the link is a
+            virtual link, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define the
+            protocol being used, e.g. ethernet, or could be set to something
+            general like 'layer2' to state generally what kind of protocol is
+            being run over it. If the link is unidirectional, it must have 
the
+            same type as the port it is defined in. If the link is
+            bidirectional, it must have the same type as the two 
undirectional
+            links that underly it.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+        <section id="link_remoteLinkId" title="Remote Link Id">
+          <t>
+            Bidirectional links are made up of two
+            unidirectional links. Each undirectional link may
+            contain a reference to its sibling link using the
+            remoteLinkId element. If included, the remoteLinkId
+            element must contain the fully-qualified identifier for the 
sibling
+            unidirectional link. If the remoteLinkId element is specified in 
an
+            element, the sibling link must have the same type as the link 
being
+            described.
+          </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="link_description" title="Description">
+          <t>
+            Each link can include a description element. This
+            element should include a human readable description
+            of the link.
+          </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="link_comments" title="Comments">
+          <t>
+            Each link can include one or more comments
+            elements. These elements can be used to add
+            human-readable comments about the link. These
+            should not be used to store necessary information
+            about the link.
+          </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="link_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the link.
+          </t>
+          <section id="link_relations_bidi" title="Bidirectional Relations">
+            <t>
+              Bidirectional links should include an over relation containing
+              references to the two unidirectional links that make up the
+              bidirectional link.
+            </t>
+          </section>
+        </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 anchor="link_lifetime" title="Lifetime">
+          <t>
+            A link has an optional field lifetime that can be used to 
describe
+            the time during which the link had the properties being described
+            or, in the case of ephemeral links, the time during which the 
link
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+      </section>
 
-                        </t>
-                    </section>
+      <section anchor="port" title="Interfaces">
+        <t> Nodes have interfaces, which are the attachment points of
+          links. They have properties which are independent of the
+          Node. Interfaces are defined in the schema in port elements. </t>
 
-                    <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 anchor="port_id" title="id Attribute">
+          <t> Each port has an id attribute that contains the
+            fully-qualified identifier for the port. </t>
+        </section>
+        <section anchor="port_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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element. </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 anchor="port_name" title="Name">
+          <t>
+           The port element can have one or more name elements to describe 
the
+           port. The name element contains a string and can be filled with 
any
+           value that can be used to name the port. This could include the
+           name of the interface on the host, the ip address for a layer 3
+           port or a simple description of the port.
+          </t>
+          <section anchor="port_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
 
+        <section anchor="port_address" title="Address">
+          <t>
+           Each port can have one or more address elements to describe the
+           addresses that the outside world can use to contact this port.
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </t>
+          <t>
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client 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 anchor="port_type" title="Type">
+          <t>
+            Each port can also include a type element to describe the 
protocol
+            of the interface.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the port is a
+            virtual port, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define what
+            protocol is being used, e.g. ethernet, or could be set to 
something
+            like 'layer2' to state generally what kind of protocol is being 
run
+            over it.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
 
+        <section anchor="port_capacity" title="Capactity">
+          <t>
+            <!-- XXX get a ref to the actual rfc where they're defined -->
+            Every interface has a maximum physical bandwidth
+            attainable by it. This value can be influenced by both the
+            physical capacity of the interface's card or the physical
+            capacity of the link plugged in to the card. This element
+            should contain the minimum of those two values. The
+            element to describe this property of the interface is
+            capacity. It contains a string formatted according to the
+            speeds defined by the GMPLS standard.
+          </t>
+        </section>
 
-                    <section id="network" title="Network">
-                        <t>
-                            A Network is essentially a scoping construct.  
-                        </t>
-                    </section>
+        <section anchor="port_mtu" title="MTU">
+          <t>
+           Every port element may contain an element, mtu, containing the
+           maximum size an individual segment of data that can be transmitted
+           with this port can contain. If the port were an ethernet port,
+           this would be the configured MTU for the port. If the port were a
+           UDP port, the value would contain the maximum segment size for the
+          port. This field must contain an integer corresponding to the 
number
+          of bytes in the maximum size. If the specified value is "0", this
+          means that the particular interface has no maximum segment size.
+          </t>
+        </section>
 
+        <section anchor="port_description" title="Description">
+          <t>
+           Each port can include a description element. This
+            element should include a human readable description of the
+            port.
+         </t>
+        </section>
 
-                </section>
+        <section anchor="port_comments" title="Comments">
+          <t> Each port can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the port. These should not be used to store
+            necessary information about the port. </t>
+        </section>
 
-                <section id="xml_namespace" title="XML Namespaces">
+        <section anchor="port_relations" title="Relations">
+          <t> One or more relation elements, which are described
+            later, may be defined inside the port. </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 anchor="port_lifetime" title="Lifetime">
+          <t>
+            A port has an optional field lifetime that can be used to 
describe
+            the time during which the port had the properties being described
+            or, in the case of ephemeral ports, the time during which the 
port
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
 
-                    <t>This version of the schema includes layers subdivided 
by the
-                        layer of the OSI protocol model.  </t>
+        <section anchor="port_links" title="Links">
+          <t>
+            One or more link elements, which are described earlier,
+            may be defined inside the port as well. The only links that can 
be
+            defined inside a port are unidirectional links whose source is 
the
+            port in which they are being defined. The type of the
+            unidirectional link must be the same as the type of the port it's
+            defined in. For example, an ipv4 link cannot be created inside an
+            802.11 port. It must be created inside an ipv4 port.
+          </t>
+        </section>
+      </section>
 
-                </section>
+      <section anchor="service" title="Service">
+        <t>
+         The service element can be used to describe services. This could
+         include high-level services like web-services or low-level services
+         like a translator between optical wavelengths.
+       </t>
 
-                <section id="versioning" title="Versioning">
-                    <t>Completely lifted from NM doc..  the issues are the 
same.
-                        maybe we just reference</t>
+        <section anchor="service_id" title="id Attribute">
+          <t>
+           Each service has an id attribute that contains the
+            fully-qualified identifier for this service.
+         </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>
+        <section anchor="service_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 service.  If a
+           service element has this attribute, it means that this service
+           element is not the authoritative, it simply contains additional
+           information about the element.
+          </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 anchor="service_name" title="Name">
+          <t>
+           Service elements can contain one or more name elements to describe
+           the service. The name element contains a string and can be filled
+           with any value that can be used to name the service.
+          </t>
+          <section anchor="service_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
 
-                <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>
+        <section anchor="service_description" title="Description">
+          <t>
+           Each service can include a description element. This
+            element should include a human readable description of the
+            service.
+         </t>
+        </section>
 
-                    <!-- XXX Describe another relation like 
"shared_siblings" or "siblings" or whatever -->
+        <section anchor="service_comments" title="Comments">
+          <t>
+           Each service can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific service. These should not be used to store
+            necessary information about the service.
+         </t>
+        </section>
 
-                </section>
+        <section anchor="service_relations" title="Relations">
+          <t>
+           One or more relation elements, which are described
+            later, may be defined inside the service.
+         </t>
+          <t>
+           If a service is only available on a certain number of interfaces,
+           it should include an 'over' relation containing the set of
+           interfaces that the service is reachable via.
+         </t>
+        </section>
 
-                <section id="topo_base_schema" title="Base Topolgy Schema">
-                    <t>
-                        <artwork><![CDATA[
-                            <inline file="schema/nmtopo_base.rnc"/>
-                            ]]></artwork>
-                    </t>
-                </section>
+        <section anchor="service_lifetime" title="Lifetime">
+          <t>
+            A service has an optional field lifetime that can be used to 
describe
+            the time during which the service had the properties being 
described
+            or, in the case of ephemeral services, the time during which the 
service 
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </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>
+      <section anchor="network" title="Network">
+        <t> A Network is essentially a scoping construct. </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 anchor="network_id" title="id Attribute">
+          <t>
+            Each network element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </t>
+        </section>
 
+        <section anchor="network_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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element.
+          </t>
+        </section>
 
-                </section>
+        <section anchor="network_name" title="Name">
+          <t>
+           Network elements can contain one or more name elements to describe
+           the network. The name element contains a string and can be filled
+           with any value that can be used to name the network. This could be
+           the subnet for an ipv4 or ipv6 network or a simple description of
+           the network.
+          </t>
+          <section anchor="network_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
 
-                <!--
-                <section title="Appendices">
-                    <section title="Acknowledgements">
-                    </section>
+        <section anchor="network_type" title="Type">
+          <t>
+            Each network element can also include a type element to describe
+            the protocol of the network being described. The contents of this
+            element are unspecified, howerever, there exist a set of 
predefined
+            values that this may contain. For example, "ethernet" if the
+            network were an ethernet network, "tcp" if it were a tcp overlay
+            network. New type defintions should be created in a fashion 
similar
+            to the existing ones, or simply "layer2" for a general layer2
+            network. If a type is specified, every element in the network 
must
+            be connected via the specified protocol.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="network_description" title="Description">
+          <t>
+            Each network can include a description element. This
+            element should include a human readable description of the
+            network.
+          </t>
+        </section>
+
+        <section anchor="network_comments" title="Comments">
+          <t>
+            Each network can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the network. These should not be used to store
+            necessary information about the network.
+          </t>
+        </section>
+
+        <section anchor="network_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the network.
+          </t>
+        </section>
+
+        <section anchor="network_lifetime" title="Lifetime">
+          <t>
+            A network has an optional field lifetime that can be used to
+            describe the time during which the network had the properties 
being
+            described or, in the case of ephemeral networks, the time during
+            which the network actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="network_children" title="Entities In The Network">
+          <t>
+            The network may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the network. If the type of the network
+            has been set, all the elements in the network must be connected
+            using the specified type.
+          </t>
+        </section>
+
+      </section>
+
+      <section anchor="path" title="Path">
+        <t> A Path defines a discrete path between two topological points. 
</t>
+
+        <section anchor="path_id" title="id Attribute">
+          <t>
+            Each path element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </t>
+        </section>
+
+        <section anchor="path_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 path. If a path element has this attribute, it
+            means that this path element is not the authoritative path
+            element, it simply contains additional information about
+            the element.
+          </t>
+        </section>
+
+        <section anchor="path_name" title="Name">
+          <t>
+           The path element can contain one or more name elements to describe
+           the path. The name element contains a string and can be filled 
with
+           any value that can be used to name the path. This could be an
+           e2emon style global circuit name, an identifier from a path
+           construction service or simply a description of the path.
+          </t>
+          <section anchor="path_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="path_type" title="Type">
+          <t>
+            Each path element can also include a type element to describe
+            the protocol used by the path being defined. The contents of 
this element
+            are unspecified, howerever, there exist a set of predefined 
values
+            that this may contain. For example, "ethernet" if every element 
in
+            that path were ethernet, "tcp" if every step were tcp or simply
+            "layer2" if every step were at layer2. New type defintions should
+            be created in a fashion similar to the existing ones.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="path_description" title="Description">
+          <t>
+            Each path can include a description element. This
+            element should include a human readable description of the
+            path.
+          </t>
+        </section>
+
+        <section anchor="path_comments" title="Comments">
+          <t>
+            Each path can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the path. These should not be used to store
+            necessary information about the path.
+          </t>
+        </section>
+
+        <section anchor="path_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the path.
+          </t>
+        </section>
+
+        <section anchor="path_lifetime" title="Lifetime">
+          <t>
+            A path has an optional field lifetime that can be used to
+            describe the time during which the path had the properties being
+            described or, in the case of ephemeral path, the time during
+            which the path actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="path_children" title="Entities In The Network">
+          <t>
+            The path may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the path. These id references take the
+            form "nodeIdRef", "portIdRef" and "linkIdRef". The contents of 
each
+            them must contain a fully-qualified identifier for a network 
entity of the
+            reference type.
+          </t>
+          <t> 
+            If the type of the path
+            has been set, all the elements in the path must be connected
+            using the specified type.
+          </t>
+        </section>
+      </section>
+
+      <section anchor="epp" title="Endpoint Pairs">
+        <t>
+          Conceptually, endpoint pairs could be provided by creating two port
+          elements and a link element. The two ports and a link element is 
the
+          preferred method for creation of these kinds of entities. However,
+          due to the common appearance of these concepts in network
+          measurements, the endpoint pair is provided as a shorthand for the
+          link/port construct in measurement requests. These elements must 
not
+          be returned as part of a description of physical topology.
+        </t>
+
+        <section anchor="epp_name" title="Name">
+          <t>
+           End-point pairs elements can contain one or more name elements to
+           describe the endpoint pair. The name element contains a string and
+           can be filled with any value that can be used to name the pair.
+          </t>
+          <section anchor="epp_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="epp_type" title="Type">
+          <t>
+            Each epp element can also include a type element to describe
+            the protocol used by the endpoints for communication. The 
contents
+            of this element are unspecified, howerever, there exist a set of
+            predefined values that this may contain. For example, "ethernet" 
if
+            the endpoints communicated via "ethernet", "tcp" if they
+            communicate via tcp or simply "layer2" if they communicate via 
some
+            layer2 protocol.  New type defintions should be created in a
+            fashion similar to the existing ones.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="epp_description" title="Description">
+          <t>
+            Each endpoint pair can include a description element. This
+            element should include a human readable description of the
+            pair.
+          </t>
+        </section>
+
+        <section anchor="epp_comments" title="Comments">
+          <t>
+            Each endpoint pair can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the pair.
+          </t>
+        </section>
+
+        <section anchor="epp_src" title="Source">
+          <t>
+            The source for an endpoint pair is described using a src element.
+            This element can consist of the set of elements in a port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the source endpoint.
+          </t>
+        </section>
+
+        <section anchor="epp_dst" title="Destination">
+          <t>
+            The destination for an endpoint pair is described using a dst
+            element.  This element can consist of the set of elements in a 
port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the destination endpoint.
+          </t>
+        </section>
+      </section>
+    </section>
+
+    <section id="layer2_elements" title="Layer 2 Elements">
+      <t>
+        <!-- XXX put in the actual namespace -->
+
+        If the network entity being describing is layer 2, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 2 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer2_type" title="Type">
+        <t>
+          The type in layer 2 elements, if included, must be the link layer
+          protocol of that element. For example, an ethernet link would have
+          type "ethernet".
+        </t>
+      </section>
+
+      <section id="layer2_port" title="Port">
+        <section id="layer2_port_address" title="Address">
+          <t>
+            The address element in layer 2 ports must consist of the layer 2 
address
+            for the port.
+          </t>
+        </section>
+        <section id="layer2_ifname" title="ifName">
+          <t>
+            The layer 2 namespace adds a new element, ifName, that can be 
used to
+            specify the SNMP name of the interface. The ifName element 
contains a
+            string representation of the port's ifName.
+          </t>
+        </section>
+
+        <section id="layer2_ifindex" title="ifIndex">
+          <t>
+            The layer 2 namespace adds a new element, ifIndex, that can be 
used to
+            specify the SNMP index of the interface. The ifIndex field must 
be
+            filled in with the integer SNMP index for the interface.
+          </t>
+        </section>
+        <section id="layer2_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified port. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that port.
+          </t>
+        </section>
+       <section id="layer2_vlan_range_availability" title="Vlan Range 
Availability">
+         <t>
+           The layer 2 namespace adds an element, vlanRangeAvailability, that
+           can be used to specify which tags are still available for use to
+           create new vlans on the specified port. The element must contain a
+           string containing a comma-separated list of vlan tag identifiers.
+           Ranges of tags can be specified by listing two vlan tags separated
+           by a "-".
+         </t>
+       </section>
+      </section>
+      <section id="layer2_link" title="Link">
+        <section id="layer2_link_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified link. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that link. 
If the
+            vlan tag is specified for the port associated with this link, 
this
+            value must be the same as the one in the port.
+          </t>
+        </section>
+      </section>
+      <section id="layer2_network" title="Network">
+        <section id="layer2_network_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified network. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that 
network. If
+            the vlan tag is specified, all the elements referenced by the 
network
+            need to have the same vlan tag. 
+          </t>
+        </section>
+      </section>
+    </section>
+
+
+    <section id="layer3_elements" title="Layer 3 Elements">
+      <t>
+        <!-- XXX put in the actual namespace -->
+
+        If the network entity being describing is layer 3, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 3 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer3_type" title="Type">
+        <t>
+          The type in layer 3 elements, if included, must be the network 
layer
+          protocol of that element. For example, an ipv4 network would have
+          type "ipv4".
+        </t>
+      </section>
+
+      <section id="layer3_port" title="Port">
+        <section id="layer3_port_name" title="Name">
+          <t>
+            The name for the layer 3 element should be the layer 3 address 
for that
+            element. The type attribute must be specified.
+          </t>
+        </section>
+        <section id="layer3_port_address" title="Address">
+          <t>
+            The address element in layer 3 ports must consist of the layer 3 
address
+            for the port.
+          </t>
+        </section>
+        <section id="layer3_port_netmask" title="Netmask">
+          <t>
+            The layer 3 port has an optional element netmask. This element 
is a
+            string that containing the netmask for the address. If the 
address
+            type is ipv4, the contents must consist of a netmask in
+            dotted-decimal form. If the address type is ipv6, the contents 
must
+            consist of an ipv6 netmask in colon-separated hexadecimal 
format. If
+            the address type is any other value, the contents of the netmask 
are
+            unspecified.
+          </t>
+        </section>
+      </section>
+      <section id="layer3_network" title="Network">
+        <section id="layer3_network_address" title="Subnet">
+          <t>
+            The layer 3 network element may contain a subnet element to 
describe the
+            range of addresses contained in the network. This element must 
contain
+            a layer 3 address element and a netmask element. The layer 3 
address
+            element may contain any address in the range contained in the 
network.
+            The contents of the netmask element depend on the type of the 
address.
+            If the address type is ipv4, the netmask element must contain a 
netmask
+            in dotted-decimal form. If the address type is ipv6, the netmask
+            element must contain a number corresponding to the ipv6 netmask.
+          </t>
+        </section>
+        <section id="layer3_network_asn" title="ASN">
+          <t>
+            The layer 3 network element may contain an ASN element to 
specify which
+            autonomous system the network is describing. The element must 
contain
+            the autonomous system number as an integer.
+          </t>
+        </section>
+      </section>
+    </section>
+
+    <section id="layer4_elements" title="Layer 4 Elements">
+      <t>
+        <!-- XXX put in the actual namespace -->
+
+        If the network entity being describing is layer 4, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 4 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer4_type" title="Type">
+        <t>
+          The type in layer 4 elements, if included, must be the transport
+          layer protocol of that element.  For example, a tcp overlap network
+          would have type "tcp".
+        </t>
+      </section>
+
+      <section id="layer4_port" title="Port">
+        <section id="layer4_port_name" title="Name">
+          <t>
+            The name element in layer 4 ports may use the type "port". If 
so, the
+            element must contain the number for that port. If a layer4 
element name
+            has no "type" specified, the format of the element should be of 
the form
+            "protocol:port". For example, a tcp service listening on port 80 
would be
+            described as "tcp:80".
+          </t>
+        </section>
+
+        <section id="layer4_port_address" title="Address">
+          <t>
+            The format of the address element differs in a layer 4 port. If 
no
+            type is specified, the address must be of the form "ip:port". 
The ip
+            corresponds to the underlying layer3 address. If the underlying 
address
+            is an ipv6 address, the convention is "[ip]:port". In this 
context, the
+            ip must be the same as the interface underlying the layer 4 port.
+          </t>
+          <t>
+            Another possible form can be used if the type is set to "url" 
which means
+            that the element is formatted as a URL. In this case, the format 
of the
+            element must be of the form "protocol://layer3 address:port". If 
the
+            layer 3 address if of type ipv6, the format of the url must be 
of the
+            form "protocol://[ipv6 address]:port". 
+          </t>
+        </section>
+
+        <section id="layer4_port_portnum" title="Port Number">
+          <t>
+            The layer 4 port has a required element portNum. This element 
consists
+            of an integer that contains the port number that the protocol is
+            listening on.
+          </t>
+        </section>
+      </section>
+    </section>
+
+    <section id="ctrlplane_elements" title="Control Plane Elements">
+
+    </section>
+    
+    <section anchor="xml_namespace" title="XML Namespaces">
+
+      <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>
+
+      <t>This version of the schema includes layers subdivided by the
+        layer of the OSI protocol model. </t>
+
+      <t>
+        All namespaces contain the elements defined in the base namespace.
+       The elements in each subnamespace contain all the elements and
+       properties defined previously. Each namespace may redefine the meaning
+       of elements or add new elements. However, it may not remove any
+       elements that were previously defined.
+      </t>
+
+      <t>
+       When released, each version of a namespace must specify the versions 
of
+       their parent namespaces. If a new version of a parent namespace comes
+       out, the version of the child namespace MUST be incremented to add any
+       new elements or properties added in the parent namespace.
+      </t>
+
+      <t>
+        Example Namespaces:
+       Base: http://ogf.org/schema/network/topology/base/20070707/
+       Layer 2: http://ogf.org/schema/network/topology/l2/20070707/
+       Ethernet: http://ogf.org/schema/network/topology/l2/ethernet/20070707/
+      </t>
+    </section>
+
+    <section anchor="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>
+
+      <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 anchor="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 underneath 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 fully-qualified 
identifiers
+        for the unidirectional 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>
+
+      <!-- XXX Describe another relation like "shared_siblings" or 
"siblings" or whatever -->
+
+    </section>
+
+    <section anchor="topo_base_schema" title="Base Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
+                        <inline file="schema/nmtopo_base.rnc"/>
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_l2_schema" title="Layer 2 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
+                        <inline file="schema/nmtopo_l2.rnc"/>
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_l3_schema" title="Layer 3 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
+                        <inline file="schema/nmtopo_l3.rnc"/>
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_l4_schema" title="Layer 4 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
+                        <inline file="schema/nmtopo_l4.rnc"/>
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_ctrlplane_schema" title="Control Plane Topology 
Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
+                        <inline file="schema/nmtopo_ctrlplane.rnc"/>
+                        ]]></artwork>
+        </figure>
+      </t>
+    </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>
+
+    <!--
+            <section title="Appendices">
+                <section title="Acknowledgements">
                 </section>
-                -->
+            </section>
+            -->
 
-            </middle>
+  </middle>
 
-            <back>
+  <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>
+      <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>
 
-                    <!-- 
-                    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.
+          <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>
 
-                </references>
-            </back>
-
-        </rfc>
+</rfc>

Modified: trunk/nmwg/doc/nm-topo/tmp.nm-topo.xml
===================================================================
--- trunk/nmwg/doc/nm-topo/tmp.nm-topo.xml      2008-05-20 15:55:47 UTC (rev 
347)
+++ trunk/nmwg/doc/nm-topo/tmp.nm-topo.xml      2008-05-20 16:05:26 UTC (rev 
348)
@@ -3,674 +3,2453 @@
 
 <!--<rfc category="info" ipr="full3978" docName="schema-overview.txt">-->
 <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" ?>
-<!-- <?rfc-ext support-rfc2731="no"?>
-<?rfc-ext authors-section="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="May" year="2007"/>
-</front>
+  <?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-ext authors-section="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 based on the NM performance data schema.
-   </t>
+      <t> This document presents an extensible encoding standard for
+        network topology. It provides a description 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">
+      <section anchor="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 anchor="design_philosophy" title="Design Philosophy">
+
+      <t> Networks have basic components and any network
+        representation must include these basic elements. Like the
+        Network Measurement schema, we define the basic elements and
+        vary the namespace of them to indicate specific components. </t>
+
+    </section>
+
+    <section anchor="identifiers" title="Identifiers">
+      <t> The network topology identifiers have been designed to be
+        flexible, be explicit in their meaning and still be reasonably
+        human-readable. </t>
+
+      <t>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:".</t>
+
+      <t>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''.</t>
+
+      <t>A single ``*'' may appear instead of a name/value field to
+       connote an identifier for an unknown network element of unknown type.
+       If a '*' field is included, that field MUST be the last field in the
+       identifier.</t>
+
+      <t>The name/value pairs MUST be ordered from most general
+        network entity to most specific network entity. For example,
+        the domain field MUST come before the node field which MUST
+        come before the port field. There MUST NOT exist repeated
+        fields in the identifier.</t>
+
+      <section anchor="fields" title="Description of Fields">
+        <section title="Domain" anchor="fields_domain">
+
+          <t>
+           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 be a globally unique DNS name for that domain, and MUST
+           NOT include any trailing spaces. Setting the value of this field 
to
+           '*' connotes the domain is unknown.
+          </t>
+          <t>
+            <figure>
+              <artwork> urn:ogf:network:domain=dcn.internet2.edu
+                urn:ogf:network:domain=* (this)
+                urn:ogf:network:domain=dcn.internet2.edu:* (is shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </artwork>
+            </figure>
+          </t>
+
+        </section>
+
+        <section title="Node" anchor="fields_node">
+
+          <t>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. 
+          </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu:node=packrat
+                urn:ogf:network:domain=internet2.edu:node=207.75.164.10
+                urn:ogf:network:domain=internet2.edu:node=Joe's Machine
+                urn:ogf:network:domain=internet2.edu:node=Los Angeles NOC
+                urn:ogf:network:domain=internet2.edu:node=*</artwork>
+            </figure></t>
+        </section>
+
+        <section title="Service" anchor="fields_service">
+
+          <t>
+           An identifier for a network-available service MUST include the
+           domain, node and service fields. The node and domain fields MUST 
be
+           identicial to those in the identifier for the node containing the
+           service. The value of the service field can be anything, but MUST
+           be unique in the node and MUST NOT include any trailing spaces. 
The
+           value SHOULD be a human readable description of the service.
+           Setting the value of the node field to '*' connotes the service is
+           unknown. 
+          </t>
+          <t> Examples: <figure>
+              <artwork>
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=http
+               
urn:ogf:network:domain=internet2.edu:node=packrat:service=perfSONAR%20SNMP%20MA
+               urn:ogf:network:domain=internet2.edu:node=packrat:service=ping
+              </artwork>
+            </figure></t>
+        </section>
+
+        <section title="Interfaces" anchor="fields_interfaces">
+
+          <t>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.
+          </t>
+          <t> Examples: <figure>
+              <artwork>
+                urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=207.75.164.10
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=*</artwork>
+            </figure></t>
+        </section>
+
+        <section
+          title="Unidirectional Intra-domain/Inter-domain Links"
+          anchor="fields_unilinks">
+
+          <t>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. </t>
+          <t> Examples: <figure>
+              <artwork>
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=Link
+                Between Packrat And Router1
+                
urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0:link=*
+                (this) urn:ogf:network:domain=dcn.internet2.edu:*
+                (could be shorthand for)
+                urn:ogf:network:domain=dcn.internet2.edu:node=*:port=*:link=*
+              </artwork>
+            </figure>
+          </t>
+        </section>
+
+        <section title="Bidirectional Domain Links"
+          anchor="fields_bidilinks">
+
+          <t>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. Examples: </t>
+          <t>
+            <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu:link=Link 
Between
+                Packrat And Router1 
urn:ogf:network:domain=internet2.edu:link=*
+              </artwork>
+            </figure>
+          </t>
+        </section>
+
+        <section title="Bidirectional Inter-domain Links"
+          anchor="fields_bidiinterlinks">
+
+          <t>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. 
+          </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:link=Link Between Internet2
+                And ESNet urn:ogf:network:link=*</artwork>
+            </figure></t>
+        </section>
+
+        <section title="Intra-domain Path" anchor="fields_intrapath">
+
+          <t>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. </t>
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:domain=internet2.edu: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=* </artwork>
+            </figure>
+          </t>
+        </section>
+
+        <section title="Inter-domain Path" anchor="fields_interpath">
+
+          <t>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.</t>
+
+          <t> Examples: <figure>
+              <artwork> urn:ogf:network:path=DRAGON Path From
+                207.75.164.10 to 134.55.209.97 urn:ogf:network:path=*
+              </artwork>
+            </figure>
+          </t>
+        </section>
+
+        <section title="Network" anchor="fields_network">
+
+          <t>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.</t>
+
+          <t>Examples: <figure>
+              
<artwork>urn:ogf:network:domain=internet2.edu:network=207.75.164.0%2F24
+                urn:ogf:network:network=207.0.0.0%2F8
+                urn:ogf:network:network=*</artwork>
+            </figure>
+          </t>
+        </section>
+
+      </section>
+    </section>
+
+    <section anchor="basic_elements" title="Basic Elements">
+      <t>This schema defines the basic elements that can be used to
+        describe network topologies. </t>
+
       <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.
+        <!-- exact duplicate of nm-schema-base --> 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 anchor="domain" title="Domain">
+        <t>
+          A domain is a point demarcation used to divide the entities in a
+          topology into administrative groupings according to the
+          administrative domain that controls the entity.
+        </t>
+        <section anchor="domain_id" title="id Attribute">
+          <t>
+            Each domain has an id attribute that contains the
+            fully-qualified identifier for this domain.
+          </t>
+        </section>
+        <section anchor="domain_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 domain. If a domain element has this attribute, it
+            means that this domain element is not the authoritative, it
+            simply contains additional information about the element.
+          </t>
+        </section>
+        <section anchor="domain_entities" title="Entities In The Domain">
+          <t>
+            A domain can have any number of node, link, network and path
+            entities defined immediately underneath it. The entities defined
+            there must all correspond to entities that are in the actual
+            domain. The links that are defined must be bidirectional links.
+            Unidirectional links can only be defined inside of ports.
+          </t>
+        </section>
+      </section>
+
+      <section anchor="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 anchor="node_id" title="id Attribute">
+          <t> Each node has an id attribute that contains the
+            fully-qualified identifier for this node. </t>
+        </section>
+        <section anchor="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.
+          </t>
+        </section>
+
+        <section anchor="node_name" title="Name">
+          <t>
+           Node elements can contain one or more name elements to describe 
the
+           node. The name element contains a string and can be filled with 
any
+           value that can be used to name the node. This could include the
+           node's hostname, its default ip address or simply a description of
+           the node.
+          </t>
+          <section anchor="node_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="node_role" title="Role">
+          <t>
+            Each node can also include a role element to describe
+            what role this network entity has. The contents of
+           this element are unspecified, but should correspond to the job of
+           the node. If the node is a router, the contents should be 
"router".
+           If the node is an endpoint, the contents should be "endpoint".
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            Existing defined values for the role field are listed in the
+            appendix.
+          </t>
+        </section>
+
+        <section anchor="node_address" title="Address">
+          <t>
+           Each node can have one or more address element to describe the
+           addresses that the outside world can use to contact this node.
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </t>
+          <t>
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client 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 anchor="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>
+          <t>
+           Longitude and latitude information SHOULD be included with each
+           node to ease the drawing of topologies.
          </t>
-    </section>
+        </section>
 
-  </section>
+        <section anchor="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>
 
-  <section id="design_philosophy" title="Design Philosophy">
+          <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>
-         Reuse the namespace thing from NM.
-       </t>
+        <section anchor="node_description" title="Description">
+          <t> Each node can include a description element. This
+            element should include a human readable description of the
+            node. </t>
+        </section>
 
-       
+        <section anchor="node_comments" title="Comments">
+          <t> Each node can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the node. </t>
+        </section>
 
-  </section>
+        <section anchor="node_relations" title="Relations">
+          <t> One or more relation elements, which are described
+            later, may be defined inside the node. </t>
+        </section>
 
-  <section id="basic_elements" title="Basic Elements">
-    <t>This schema defines the basic elements that can be used to
-    describe network topologies.
+        <section anchor="node_lifetime" title="Lifetime">
+          <t>
+            A node has an optional field lifetime that can be used to 
describe
+            the time during which the node had the properties being described
+            or, in the case of ephemeral nodes, the time during which the 
node
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="node_ports" title="Interfaces">
+          <t>
+            One or more port elements, which are described later, may be
+            defined inside the node as well. These port elements must
+            correspond to interfaces inside the node being described. The
+            actual namespaces of the interfaces can consist of any of the
+            namespaces defined in these schema that have a "port" element.
+          </t>
+        </section>
+      </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 id="link_id" title="id Attribute">
+          <t>
+            Each link has an id attribute that contains the
+            fully-qualified identifier for the link. 
+          </t>
+        </section>
+        <section id="link_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 link. If a link element has this attribute,
+            it means that this link element is not the
+            authoritative link element, it simply contains
+            additional information about the element.
+          </t>
+        </section>
+
+        <section id="link_name" title="Name">
+          <t>
+           Links elements can contain one or more name elements to describe
+           the link. The name element contains a string and can be filled 
with
+           any value that can be used to name the link. This could include an
+           e2emon style link name, a local name for the link or simply a
+           description of the link.
+          </t>
+          <section anchor="link_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section id="link_global_name" title="Global Name">
+          <t>
+            The globalName element can be used to give a
+            globally-unique name to describe the link. This
+            element contains an attribute describing what type
+            of name this element contains. 
+          </t>
+          <t>
+            The types and contents of the element are unspecified as the
+            element is deprecated. Its inclusion in here is due to the
+            prevelance of e2emon services that exist which make use of a
+            globalName field.
+          </t>
+        </section>
+        <section id="link_type" title="Type">  
+          <t>
+            Each link can also include a type element to describe the 
protocol
+            of the link.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the link is a
+            virtual link, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define the
+            protocol being used, e.g. ethernet, or could be set to something
+            general like 'layer2' to state generally what kind of protocol is
+            being run over it. If the link is unidirectional, it must have 
the
+            same type as the port it is defined in. If the link is
+            bidirectional, it must have the same type as the two 
undirectional
+            links that underly it.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+        <section id="link_remoteLinkId" title="Remote Link Id">
+          <t>
+            Bidirectional links are made up of two
+            unidirectional links. Each undirectional link may
+            contain a reference to its sibling link using the
+            remoteLinkId element. If included, the remoteLinkId
+            element must contain the fully-qualified identifier for the 
sibling
+            unidirectional link. If the remoteLinkId element is specified in 
an
+            element, the sibling link must have the same type as the link 
being
+            described.
+          </t>
+        </section>
+
+        <section id="link_description" title="Description">
+          <t>
+            Each link can include a description element. This
+            element should include a human readable description
+            of the link.
+          </t>
+        </section>
+
+        <section id="link_comments" title="Comments">
+          <t>
+            Each link can include one or more comments
+            elements. These elements can be used to add
+            human-readable comments about the link. These
+            should not be used to store necessary information
+            about the link.
+          </t>
+        </section>
+
+        <section id="link_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the link.
+          </t>
+          <section id="link_relations_bidi" title="Bidirectional Relations">
+            <t>
+              Bidirectional links should include an over relation containing
+              references to the two unidirectional links that make up the
+              bidirectional link.
+            </t>
+          </section>
+        </section>
+
+
+        <section anchor="link_lifetime" title="Lifetime">
+          <t>
+            A link has an optional field lifetime that can be used to 
describe
+            the time during which the link had the properties being described
+            or, in the case of ephemeral links, the time during which the 
link
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+      </section>
+
+      <section anchor="port" title="Interfaces">
+        <t> Nodes have interfaces, which are the attachment points of
+          links. They have properties which are independent of the
+          Node. Interfaces are defined in the schema in port elements. </t>
+
+        <section anchor="port_id" title="id Attribute">
+          <t> Each port has an id attribute that contains the
+            fully-qualified identifier for the port. </t>
+        </section>
+        <section anchor="port_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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element. </t>
+        </section>
+
+        <section anchor="port_name" title="Name">
+          <t>
+           The port element can have one or more name elements to describe 
the
+           port. The name element contains a string and can be filled with 
any
+           value that can be used to name the port. This could include the
+           name of the interface on the host, the ip address for a layer 3
+           port or a simple description of the port.
+          </t>
+          <section anchor="port_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="port_address" title="Address">
+          <t>
+           Each port can have one or more address elements to describe the
+           addresses that the outside world can use to contact this port.
+          </t>
+          <t>
+            <!-- XXX include actual appendix references -->
+            The possible types and formats for the address element are listed
+            in the appendix.
+          </t>
+          <t>
+            If the type of the element is unspecified or is unknown
+            to the client parsing the topology, the client 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 anchor="port_type" title="Type">
+          <t>
+            Each port can also include a type element to describe the 
protocol
+            of the interface.  There are a number of predefined values for
+            this element, but the contents of the type need not be confined 
to
+            those values in list included in the appendix. If the port is a
+            virtual port, the contents of the type element should be 
"logical".
+            In the base elements, the type can specifically define what
+            protocol is being used, e.g. ethernet, or could be set to 
something
+            like 'layer2' to state generally what kind of protocol is being 
run
+            over it.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="port_capacity" title="Capactity">
+          <t>
+            <!-- XXX get a ref to the actual rfc where they're defined -->
+            Every interface has a maximum physical bandwidth
+            attainable by it. This value can be influenced by both the
+            physical capacity of the interface's card or the physical
+            capacity of the link plugged in to the card. This element
+            should contain the minimum of those two values. The
+            element to describe this property of the interface is
+            capacity. It contains a string formatted according to the
+            speeds defined by the GMPLS standard.
+          </t>
+        </section>
+
+        <section anchor="port_mtu" title="MTU">
+          <t>
+           Every port element may contain an element, mtu, containing the
+           maximum size an individual segment of data that can be transmitted
+           with this port can contain. If the port were an ethernet port,
+           this would be the configured MTU for the port. If the port were a
+           UDP port, the value would contain the maximum segment size for the
+          port. This field must contain an integer corresponding to the 
number
+          of bytes in the maximum size. If the specified value is "0", this
+          means that the particular interface has no maximum segment size.
+          </t>
+        </section>
+
+        <section anchor="port_description" title="Description">
+          <t>
+           Each port can include a description element. This
+            element should include a human readable description of the
+            port.
+         </t>
+        </section>
+
+        <section anchor="port_comments" title="Comments">
+          <t> Each port can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the port. These should not be used to store
+            necessary information about the port. </t>
+        </section>
+
+        <section anchor="port_relations" title="Relations">
+          <t> One or more relation elements, which are described
+            later, may be defined inside the port. </t>
+        </section>
+
+        <section anchor="port_lifetime" title="Lifetime">
+          <t>
+            A port has an optional field lifetime that can be used to 
describe
+            the time during which the port had the properties being described
+            or, in the case of ephemeral ports, the time during which the 
port
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="port_links" title="Links">
+          <t>
+            One or more link elements, which are described earlier,
+            may be defined inside the port as well. The only links that can 
be
+            defined inside a port are unidirectional links whose source is 
the
+            port in which they are being defined. The type of the
+            unidirectional link must be the same as the type of the port it's
+            defined in. For example, an ipv4 link cannot be created inside an
+            802.11 port. It must be created inside an ipv4 port.
+          </t>
+        </section>
+      </section>
+
+      <section anchor="service" title="Service">
+        <t>
+         The service element can be used to describe services. This could
+         include high-level services like web-services or low-level services
+         like a translator between optical wavelengths.
        </t>
-       
-       <t>
-         <!-- exact duplicate of nm-schema-base -->
-         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 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".
+        <section anchor="service_id" title="id Attribute">
+          <t>
+           Each service has an id attribute that contains the
+            fully-qualified identifier for this service.
          </t>
-       </section>
+        </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.
+        <section anchor="service_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 service.  If a
+           service element has this attribute, it means that this service
+           element is not the authoritative, it simply contains additional
+           information about the element.
+          </t>
+        </section>
+
+        <section anchor="service_name" title="Name">
+          <t>
+           Service elements can contain one or more name elements to describe
+           the service. The name element contains a string and can be filled
+           with any value that can be used to name the service.
+          </t>
+          <section anchor="service_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="service_description" title="Description">
+          <t>
+           Each service can include a description element. This
+            element should include a human readable description of the
+            service.
          </t>
+        </section>
+
+        <section anchor="service_comments" title="Comments">
+          <t>
+           Each service can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific service. These should not be used to store
+            necessary information about the service.
+         </t>
+        </section>
+
+        <section anchor="service_relations" title="Relations">
+          <t>
+           One or more relation elements, which are described
+            later, may be defined inside the service.
+         </t>
+          <t>
+           If a service is only available on a certain number of interfaces,
+           it should include an 'over' relation containing the set of
+           interfaces that the service is reachable via.
+         </t>
+        </section>
+
+        <section anchor="service_lifetime" title="Lifetime">
+          <t>
+            A service has an optional field lifetime that can be used to 
describe
+            the time during which the service had the properties being 
described
+            or, in the case of ephemeral services, the time during which the 
service 
+            actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+      </section>
+
+
+      <section anchor="network" title="Network">
+        <t> A Network is essentially a scoping construct. </t>
+
+        <section anchor="network_id" title="id Attribute">
+          <t>
+            Each network element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </t>
+        </section>
+
+        <section anchor="network_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 port. If a port element has this attribute, it
+            means that this port element is not the authoritative port
+            element, it simply contains additional information about
+            the element.
+          </t>
+        </section>
+
+        <section anchor="network_name" title="Name">
+          <t>
+           Network elements can contain one or more name elements to describe
+           the network. The name element contains a string and can be filled
+           with any value that can be used to name the network. This could be
+           the subnet for an ipv4 or ipv6 network or a simple description of
+           the network.
+          </t>
+          <section anchor="network_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="network_type" title="Type">
+          <t>
+            Each network element can also include a type element to describe
+            the protocol of the network being described. The contents of this
+            element are unspecified, howerever, there exist a set of 
predefined
+            values that this may contain. For example, "ethernet" if the
+            network were an ethernet network, "tcp" if it were a tcp overlay
+            network. New type defintions should be created in a fashion 
similar
+            to the existing ones, or simply "layer2" for a general layer2
+            network. If a type is specified, every element in the network 
must
+            be connected via the specified protocol.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="network_description" title="Description">
+          <t>
+            Each network can include a description element. This
+            element should include a human readable description of the
+            network.
+          </t>
+        </section>
+
+        <section anchor="network_comments" title="Comments">
+          <t>
+            Each network can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the network. These should not be used to store
+            necessary information about the network.
+          </t>
+        </section>
+
+        <section anchor="network_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the network.
+          </t>
+        </section>
+
+        <section anchor="network_lifetime" title="Lifetime">
+          <t>
+            A network has an optional field lifetime that can be used to
+            describe the time during which the network had the properties 
being
+            described or, in the case of ephemeral networks, the time during
+            which the network actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="network_children" title="Entities In The Network">
+          <t>
+            The network may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the network. If the type of the network
+            has been set, all the elements in the network must be connected
+            using the specified type.
+          </t>
+        </section>
+
+      </section>
+
+      <section anchor="path" title="Path">
+        <t> A Path defines a discrete path between two topological points. 
</t>
+
+        <section anchor="path_id" title="id Attribute">
+          <t>
+            Each path element has an id attribute that contains the
+            fully-qualified identifier for the element.
+          </t>
+        </section>
+
+        <section anchor="path_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 path. If a path element has this attribute, it
+            means that this path element is not the authoritative path
+            element, it simply contains additional information about
+            the element.
+          </t>
+        </section>
+
+        <section anchor="path_name" title="Name">
+          <t>
+           The path element can contain one or more name elements to describe
+           the path. The name element contains a string and can be filled 
with
+           any value that can be used to name the path. This could be an
+           e2emon style global circuit name, an identifier from a path
+           construction service or simply a description of the path.
+          </t>
+          <section anchor="path_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="path_type" title="Type">
+          <t>
+            Each path element can also include a type element to describe
+            the protocol used by the path being defined. The contents of 
this element
+            are unspecified, howerever, there exist a set of predefined 
values
+            that this may contain. For example, "ethernet" if every element 
in
+            that path were ethernet, "tcp" if every step were tcp or simply
+            "layer2" if every step were at layer2. New type defintions should
+            be created in a fashion similar to the existing ones.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="path_description" title="Description">
+          <t>
+            Each path can include a description element. This
+            element should include a human readable description of the
+            path.
+          </t>
+        </section>
+
+        <section anchor="path_comments" title="Comments">
+          <t>
+            Each path can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about the path. These should not be used to store
+            necessary information about the path.
+          </t>
+        </section>
+
+        <section anchor="path_relations" title="Relations">
+          <t>
+            One or more relation elements, which are described
+            later, may be defined inside the path.
+          </t>
+        </section>
+
+        <section anchor="path_lifetime" title="Lifetime">
+          <t>
+            A path has an optional field lifetime that can be used to
+            describe the time during which the path had the properties being
+            described or, in the case of ephemeral path, the time during
+            which the path actually existed.
+          </t>
+          <t>
+            The lifetime element must include an element, start, which
+            describes the beginning of the time range. The start element
+            contains a string describing the start time. The start element 
has
+            one attribute, type. Type is required and describes the format of
+            the time value.  For example, it could be "iso" to describe an
+            ISO-formatted time string or "unix" to describe a unix timestamp.
+          </t>
+          <t>
+            The lifetime element may also include either a duration element 
or
+            an end element. The duration element contains a string describing
+            the amount of time that the entity persisted. Like start, it also
+            contains a type attribute that specifies the format of the 
string.
+            The end element contains a string describing the end point of the
+            time range. Like start, the end element also contains a type
+            attribute that specifies the format of the string.
+          </t>
+          <t>
+            If the lifetime element does not include an end time or a 
duration,
+            the end time is unspecified and can be assumed to be infinite.
+          </t>
+          <t>
+            <!-- XXX put a pointer to the appendix here -->
+            A set of predefined types for each of the above elements is 
included in the appendix
+          </t>
+        </section>
+
+        <section anchor="path_children" title="Entities In The Network">
+          <t>
+            The path may contain any number of node id references, link id
+            references or link id references which are used to define the set
+            of elements contained in the path. These id references take the
+            form "nodeIdRef", "portIdRef" and "linkIdRef". The contents of 
each
+            them must contain a fully-qualified identifier for a network 
entity of the
+            reference type.
+          </t>
+          <t> 
+            If the type of the path
+            has been set, all the elements in the path must be connected
+            using the specified type.
+          </t>
+        </section>
+      </section>
+
+      <section anchor="epp" title="Endpoint Pairs">
+        <t>
+          Conceptually, endpoint pairs could be provided by creating two port
+          elements and a link element. The two ports and a link element is 
the
+          preferred method for creation of these kinds of entities. However,
+          due to the common appearance of these concepts in network
+          measurements, the endpoint pair is provided as a shorthand for the
+          link/port construct in measurement requests. These elements must 
not
+          be returned as part of a description of physical topology.
+        </t>
+
+        <section anchor="epp_name" title="Name">
+          <t>
+           End-point pairs elements can contain one or more name elements to
+           describe the endpoint pair. The name element contains a string and
+           can be filled with any value that can be used to name the pair.
+          </t>
+          <section anchor="epp_name_type" title="Type">
+            <t>
+              The name element contains an attribute type that should be used
+              to specify the format of the contents of the name element.
+            </t>
+            <t>
+              <!-- XXX create an actual reference to the appendix -->
+              Existing type definitions are included in the appendix.
+            </t>
+            <t>
+              If the type of the element is unspecified or is unknown
+              to the client parsing the topology, the client may either treat
+              it as an opaque string or 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>
+
+        <section anchor="epp_type" title="Type">
+          <t>
+            Each epp element can also include a type element to describe
+            the protocol used by the endpoints for communication. The 
contents
+            of this element are unspecified, howerever, there exist a set of
+            predefined values that this may contain. For example, "ethernet" 
if
+            the endpoints communicated via "ethernet", "tcp" if they
+            communicate via tcp or simply "layer2" if they communicate via 
some
+            layer2 protocol.  New type defintions should be created in a
+            fashion similar to the existing ones.
+          </t>
+          <t>
+            <!-- XXX create an actual reference to the appendix -->
+            Existing type definitions are included in the appendix.
+          </t>
+        </section>
+
+        <section anchor="epp_description" title="Description">
+          <t>
+            Each endpoint pair can include a description element. This
+            element should include a human readable description of the
+            pair.
+          </t>
+        </section>
+
+        <section anchor="epp_comments" title="Comments">
+          <t>
+            Each endpoint pair can include one or more comments elements.
+            These elements can be used to add human-readable comments
+            about a specific node. These should not be used to store
+            necessary information about the pair.
+          </t>
+        </section>
+
+        <section anchor="epp_src" title="Source">
+          <t>
+            The source for an endpoint pair is described using a src element.
+            This element can consist of the set of elements in a port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the source endpoint.
+          </t>
+        </section>
+
+        <section anchor="epp_dst" title="Destination">
+          <t>
+            The destination for an endpoint pair is described using a dst
+            element.  This element can consist of the set of elements in a 
port
+            defintion as described above. It may also consist of simply a
+            portIdRef element which contains the fully-qualified id of the 
port
+            functioning as the destination endpoint.
+          </t>
+        </section>
+      </section>
     </section>
 
-    <section id="interface" title="Interface">
+    <section id="layer2_elements" title="Layer 2 Elements">
       <t>
-               Nodes have interfaces, which are the attachment points of
-               links.  They have properties which are independent of the
-               Node. 
-         </t>
+        <!-- XXX put in the actual namespace -->
+
+        If the network entity being describing is layer 2, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 2 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer2_type" title="Type">
+        <t>
+          The type in layer 2 elements, if included, must be the link layer
+          protocol of that element. For example, an ethernet link would have
+          type "ethernet".
+        </t>
+      </section>
+
+      <section id="layer2_port" title="Port">
+        <section id="layer2_port_address" title="Address">
+          <t>
+            The address element in layer 2 ports must consist of the layer 2 
address
+            for the port.
+          </t>
+        </section>
+        <section id="layer2_ifname" title="ifName">
+          <t>
+            The layer 2 namespace adds a new element, ifName, that can be 
used to
+            specify the SNMP name of the interface. The ifName element 
contains a
+            string representation of the port's ifName.
+          </t>
+        </section>
+
+        <section id="layer2_ifindex" title="ifIndex">
+          <t>
+            The layer 2 namespace adds a new element, ifIndex, that can be 
used to
+            specify the SNMP index of the interface. The ifIndex field must 
be
+            filled in with the integer SNMP index for the interface.
+          </t>
+        </section>
+        <section id="layer2_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified port. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that port.
+          </t>
+        </section>
+       <section id="layer2_vlan_range_availability" title="Vlan Range 
Availability">
+         <t>
+           The layer 2 namespace adds an element, vlanRangeAvailability, that
+           can be used to specify which tags are still available for use to
+           create new vlans on the specified port. The element must contain a
+           string containing a comma-separated list of vlan tag identifiers.
+           Ranges of tags can be specified by listing two vlan tags separated
+           by a "-".
+         </t>
+       </section>
+      </section>
+      <section id="layer2_link" title="Link">
+        <section id="layer2_link_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified link. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that link. 
If the
+            vlan tag is specified for the port associated with this link, 
this
+            value must be the same as the one in the port.
+          </t>
+        </section>
+      </section>
+      <section id="layer2_network" title="Network">
+        <section id="layer2_network_vlan" title="Vlan Tag">
+          <t>
+            The layer 2 namespace adds a new element, vlan, that can be used 
to
+            specify the vlan tag for the specified network. The vlan element 
must
+            contain an integer corresponding to the vlan tag for that 
network. If
+            the vlan tag is specified, all the elements referenced by the 
network
+            need to have the same vlan tag. 
+          </t>
+        </section>
+      </section>
     </section>
 
 
+    <section id="layer3_elements" title="Layer 3 Elements">
+      <t>
+        <!-- XXX put in the actual namespace -->
 
-       <section id="network" title="Network">
+        If the network entity being describing is layer 3, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 3 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer3_type" title="Type">
+        <t>
+          The type in layer 3 elements, if included, must be the network 
layer
+          protocol of that element. For example, an ipv4 network would have
+          type "ipv4".
+        </t>
+      </section>
+
+      <section id="layer3_port" title="Port">
+        <section id="layer3_port_name" title="Name">
+          <t>
+            The name for the layer 3 element should be the layer 3 address 
for that
+            element. The type attribute must be specified.
+          </t>
+        </section>
+        <section id="layer3_port_address" title="Address">
+          <t>
+            The address element in layer 3 ports must consist of the layer 3 
address
+            for the port.
+          </t>
+        </section>
+        <section id="layer3_port_netmask" title="Netmask">
+          <t>
+            The layer 3 port has an optional element netmask. This element 
is a
+            string that containing the netmask for the address. If the 
address
+            type is ipv4, the contents must consist of a netmask in
+            dotted-decimal form. If the address type is ipv6, the contents 
must
+            consist of an ipv6 netmask in colon-separated hexadecimal 
format. If
+            the address type is any other value, the contents of the netmask 
are
+            unspecified.
+          </t>
+        </section>
+      </section>
+      <section id="layer3_network" title="Network">
+        <section id="layer3_network_address" title="Subnet">
+          <t>
+            The layer 3 network element may contain a subnet element to 
describe the
+            range of addresses contained in the network. This element must 
contain
+            a layer 3 address element and a netmask element. The layer 3 
address
+            element may contain any address in the range contained in the 
network.
+            The contents of the netmask element depend on the type of the 
address.
+            If the address type is ipv4, the netmask element must contain a 
netmask
+            in dotted-decimal form. If the address type is ipv6, the netmask
+            element must contain a number corresponding to the ipv6 netmask.
+          </t>
+        </section>
+        <section id="layer3_network_asn" title="ASN">
+          <t>
+            The layer 3 network element may contain an ASN element to 
specify which
+            autonomous system the network is describing. The element must 
contain
+            the autonomous system number as an integer.
+          </t>
+        </section>
+      </section>
+    </section>
+
+    <section id="layer4_elements" title="Layer 4 Elements">
       <t>
-               A Network is essentially a scoping construct.  
-         </t>
+        <!-- XXX put in the actual namespace -->
+
+        If the network entity being describing is layer 4, the namespace of
+        that element can be set to XXX and a more precise definition of the
+        element can be made. The layer 4 namespace inherits all the 
attributes
+        and elements described above, but changes the semantics on some of 
the
+        elements and adds some new elements as well. The changes in semantics
+        to existing elements and additional elements added are described 
below.
+      </t>
+
+      <section id="layer4_type" title="Type">
+        <t>
+          The type in layer 4 elements, if included, must be the transport
+          layer protocol of that element.  For example, a tcp overlap network
+          would have type "tcp".
+        </t>
+      </section>
+
+      <section id="layer4_port" title="Port">
+        <section id="layer4_port_name" title="Name">
+          <t>
+            The name element in layer 4 ports may use the type "port". If 
so, the
+            element must contain the number for that port. If a layer4 
element name
+            has no "type" specified, the format of the element should be of 
the form
+            "protocol:port". For example, a tcp service listening on port 80 
would be
+            described as "tcp:80".
+          </t>
+        </section>
+
+        <section id="layer4_port_address" title="Address">
+          <t>
+            The format of the address element differs in a layer 4 port. If 
no
+            type is specified, the address must be of the form "ip:port". 
The ip
+            corresponds to the underlying layer3 address. If the underlying 
address
+            is an ipv6 address, the convention is "[ip]:port". In this 
context, the
+            ip must be the same as the interface underlying the layer 4 port.
+          </t>
+          <t>
+            Another possible form can be used if the type is set to "url" 
which means
+            that the element is formatted as a URL. In this case, the format 
of the
+            element must be of the form "protocol://layer3 address:port". If 
the
+            layer 3 address if of type ipv6, the format of the url must be 
of the
+            form "protocol://[ipv6 address]:port". 
+          </t>
+        </section>
+
+        <section id="layer4_port_portnum" title="Port Number">
+          <t>
+            The layer 4 port has a required element portNum. This element 
consists
+            of an integer that contains the port number that the protocol is
+            listening on.
+          </t>
+        </section>
+      </section>
     </section>
 
+    <section id="ctrlplane_elements" title="Control Plane Elements">
+      <!-- XXX Martin fill this in -->
+    </section>
+    
+    <section anchor="xml_namespace" title="XML Namespaces">
 
-  </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="xml_namespace" title="XML Namespaces">
+      <t>This version of the schema includes layers subdivided by the
+        layer of the OSI protocol model. </t>
 
-    <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>
+      <t>
+        All namespaces contain the elements defined in the base namespace.
+       The elements in each subnamespace contain all the elements and
+       properties defined previously. Each namespace may redefine the meaning
+       of elements or add new elements. However, it may not remove any
+       elements that were previously defined.
+      </t>
 
-       <t>This version of the schema includes layers subdivided by the
-       layer of the OSI protocol model.  </t>
+      <t>
+       When released, each version of a namespace must specify the versions 
of
+       their parent namespaces. If a new version of a parent namespace comes
+       out, the version of the child namespace MUST be incremented to add any
+       new elements or properties added in the parent namespace.
+      </t>
 
-  </section>
+      <t>
+        Example Namespaces:
+       Base: http://ogf.org/schema/network/topology/base/20070707/
+       Layer 2: http://ogf.org/schema/network/topology/l2/20070707/
+       Ethernet: http://ogf.org/schema/network/topology/l2/ethernet/20070707/
+      </t>
+    </section>
 
-  <section id="versioning" title="Versioning">
-       <t>Completely lifted from NM doc..  the issues are the same.
-       maybe we just reference</t>
+    <section anchor="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>
+      <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>
+      <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="relationships" title="Relationships Among Elements">
-       <t>
-         
-       </t>
-  </section>
+    <section anchor="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 underneath 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 fully-qualified 
identifiers
+        for the unidirectional 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>
 
-  <section id="base_schema" title="Base Schema">
-    <t>
-         <artwork><![CDATA[
+      <!-- XXX Describe another relation like "shared_siblings" or 
"siblings" or whatever -->
+
+    </section>
+
+    <section anchor="topo_base_schema" title="Base Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
 # ##############################################################
-# 
-# File:      nmbase.rnc - Main schema definition
-# Version:   $Id: nmbase.rnc 230 2007-05-07 13:12:03Z swany $
-# Purpose:   This is the main schema file, it defines the
-#             general structure of an NMWG message or store
-# 
+#
+# File:    nmtopo_base.rnc - Schema to describe network elements
+# Version: $Id: nmtopo_base.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
 
-
 # ##############################################################
 # Namespace definitions
 # ##############################################################
-namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
+ default namespace nmtb =
+   "http://ogf.org/schema/network/topology/base/20070707/";
 
+# External schema files
+ include "nmtypes.rnc"
 
+# generic Topology can be a root element
+ start |= Topology
+
+ Topology = element topology {
+     Domain*
+     & BaseNode*
+     & BaseLink*
+     & BasePort*
+     & BaseNetwork*
+     & BasePath*
+   }
+
+ Domain = element domain {
+     Identifier?
+     & IdReference?
+     & BaseNode*
+     & BaseLink*
+     & BaseNetwork*
+     & BasePath*
+   }
+
+## ########################
+## generic node
+## ########################
+ BaseNode = element node { BaseNodeContent }
+ BaseNodeContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Address*
+   & Relation*
+   & Lifetime?
+   & element role { xsd:string }?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element location { LocationContent }?
+   & element contact { ContactInformationContent }*
+   & element comments { xsd:string }*
+   & BasePort*
+   & BaseService*
+
+ ContactInformationContent =
+   attribute priority { xsd:integer }?
+   & element email { xsd:string }?
+   & element phoneNumber { xsd:string }?
+   & element administrator { xsd:string }?
+   & element institution { xsd:string }?
+
+ LocationContent =
+   element continent { xsd:string }?
+   & element country { xsd:string }?
+   & element zipcode { xsd:integer }?
+   & element state { xsd:string }?
+   & element institution { xsd:string }?
+   & element city { xsd:string }?
+   & element streetAddress { xsd:string }?
+   & element floor { xsd:string }?
+   & element room { xsd:string }?
+   & element cage { xsd:string }?
+   & element rack { xsd:string }?
+   & element shelf { xsd:string }?
+   & element latitude { xsd:float }?
+   & element longitude { xsd:float }?
+
+## ########################
+## generic port
+## ########################
+ BasePort = element port { BasePortContent }
+ BasePortContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Address*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element capacity { xsd:string }?
+   & element mtu { xsd:string }?
+   & element comments { xsd:string }*
+   & BaseLink*
+
+## ########################
+## generic link
+## ########################
+ BaseLink = element link { BaseLinkContent }
+ BaseLinkContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element remoteLinkId { xsd:string }
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element globalName {
+       attribute type { xsd:string }?
+       & xsd:string
+     }?
+   & element comments { xsd:string }*
+
+## ########################
+## generic network
+## ########################
+ BaseNetwork = element network { BaseNetworkContent }
+ BaseNetworkContent =
+   Identifier?
+   & IdReference?
+   & NodeIdRef*
+   & PortIdRef*
+   & LinkIdRef*
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+
+## ########################
+## generic path
+## ########################
+ BasePath =
+   element path { BasePathContent }
+
+# a path consists of a list of hops
+ BasePathContent =
+   Identifier
+   & Relation*
+   & Lifetime?
+   & element comments { xsd:string }*
+   & element hop { HopContent }*
+
+ HopContent =
+   Identifier,
+   (
+     DomainIdRef
+     | NodeIdRef
+     | PortIdRef
+     | LinkIdRef
+     | PathIdRef
+     | NetworkIdRef
+   )
+
+## ########################
+## generic endpoint pair
+## ########################
+ BaseEndPointPair =
+   element endPointPair { BaseEndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ BaseEndPointPairContent =
+   Name*
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element src { (BasePortContent | PortIdRef) }
+   & element dst { (BasePortContent | PortIdRef) }
+
+## ########################
+## generic service
+## ########################
+ BaseService =
+   element service { BaseServiceContent }
+
+ BaseServiceContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & Relation*
+   & Lifetime?
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_l2_schema" title="Layer 2 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
 # ##############################################################
-# Include additional functionality from other files
+#
+# File:    nmtopo_l2.rnc - Schema to describe L2 network elements
+# Version: $Id: nmtopo_l2.rnc 347 2008-05-20 15:55:47Z aaron $
+#
 # ##############################################################
-include "nmtime.rnc"
-include "filter.rnc"
 
 # ##############################################################
-# Every NMWG document should begin with either a 'store' or 
-# 'message' element
-# Patterns are defined for the content of each element.
-# 
-# Example (using message):
-# 
-# <nmwg:message id="OPTIONAL_ID" 
-#               messageIdRef="OPTIONAL_REFERENCE_ID"
-#               type="REQUIRED_TYPE"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- OPTIONAL PARAMETERS -->
-#
-#   <!-- OPTIONAL (MULTIPLE) METADATA -->
-# 
-#   <!-- OPTIONAL (MULTIPLE) DATA -->
-#  
-# </nmwg:message>
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl2 =
+           "http://ogf.org/schema/network/topology/l2/20070707/";
 
-start =
-        (
-                element nmwg:message {
-                        MessageContent
-                } |
-                element nmwg:store {
-                        StoreContent
-                }
-        )
+# External schema files
+ include "nmtypes.rnc"
 
-MessageContent =
-        Identifier? & 
-        MessageIdentifierRef? &
-        Type &
-        Parameters? &                        
-        (
-                Metadata |  
-                Data
-        )+
-        
-        
-StoreContent = 
-        Identifier? & 
-        MessageIdentifierRef? &
-        Type &
-        Parameters? &                        
-        (
-                Metadata |  
-                Data
-        )+        
+## ########################
+## layer 2 port
+## ########################
+ L2Port = element port { L2PortContent }
+ L2PortContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Address*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element capacity { xsd:string }?
+   & element mtu { xsd:string }?
+   & element comments { xsd:string }*
+   & element ifName {xsd:string }?
+   & element ifIndex {xsd:integer }?
+   & element vlan {xsd:integer }?
+   & element vlanRangeAvailability { xsd:string }
+   & L2Link*
 
+## ########################
+## layer 2 link
+## ########################
+ L2Link = element link { L2LinkContent }
+ L2LinkContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element remoteLinkId { xsd:string }
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element globalName {
+       attribute type { xsd:string }?
+       & xsd:string
+     }?
+   & element comments { xsd:string }*
+   & element vlan {xsd:integer }?
 
+## ########################
+## layer 2 network
+## ########################
+ L2Network = element network { L2NetworkContent }
+ L2NetworkContent =
+   Identifier?
+   & IdReference?
+   & NodeIdRef*
+   & PortIdRef*
+   & LinkIdRef*
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element vlan {xsd:integer }?
+
+## ########################
+## layer 2 endpoint pair
+## ########################
+ L2EndPointPair =
+   element endPointPair { L2EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L2EndPointPairContent =
+   Name*
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element src { (L2PortContent | PortIdRef | Address) }
+   & element dst { (L2PortContent | PortIdRef | Address) }
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_l3_schema" title="Layer 3 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
 # ##############################################################
-# Metadata is the information that describes data.  This
-# information doesn't change over time
 #
+# File:    nmtopo_l3.rnc - Schema to describe L3 network elements
+# Version: $Id: nmtopo_l3.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# <nmwg:metadata id="REQUIRED_ID" 
-#                metadataIdRef="OPTIONAL_REFERENCE_ID"
-#                xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- TBD OPTIONAL SUBJECT -->
-# 
-#   <!-- TBD OPTIONAL PARAMETERS -->
-#
-#   <!-- TBD OPTIONAL EVENTTYPE -->
-# 
-#   <!-- TBD OPTIONAL KEY -->
-#  
-#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --> 
-#
-# </nmwg:metadata>
-# 
 # ##############################################################
-        
-Metadata = 
-        element nmwg:metadata {
-                (
-                        Identifier &
-                        MetadataIdentifierRef? &
-                        MetadataContent
-                ),
-                anyElement*
-        }
 
-MetadataBlock =
-        Subject? &
-        Parameters?
-        
-MetadataContent = 
-        (
-                MetadataBlock |
-                FilterMetadataBlock                
-        ) &        
-        EventType? &
-        Key?        
-
-
 # ##############################################################
-# Subject identifies an endPoint (or points), perhaps the name of
-# a service or some other form of physical location. For the
-# purpose of the general case, we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.  
-#
-# Example: 
-# 
-# <nmwg:subject id="REQUIRED_ID" 
-#               metadataIdRef="OPTIONAL_REFERENCE_ID"
-#               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- ANY ELEMENT IN ANY NAMESPACE -->
-#  
-# </nmwg:subject>
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl3 =
+           "http://ogf.org/schema/network/topology/l3/20070707/";
 
-Subject = 
-        element nmwg:subject {
-                SubjectContent
-        }
+# External schema files
+ include "nmtypes.rnc"
 
-SubjectContent = 
-        (
-                Identifier &
-                MetadataIdentifierRef?        
-        ),
-        anyElement*
-        
+## ########################
+## layer 3 port
+## ########################
+ L3Port = element port { L3PortContent }
+ L3PortContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Address*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element capacity { xsd:string }?
+   & element mtu { xsd:string }?
+   & element comments { xsd:string }*
+   & element netmask { xsd:string }?
+   & L3Link*
 
-# ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways in: 1) the message to signify items such as time stamp
-# or authorization or 2) metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id and encloses one to many 'parameter' elements.
-# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please;
-# software using this should consider complex elements, then
-# text, and finally the value attribute; exceptions should
-# be thrown on duplicates).
-#
-# Example: 
-# 
-# <nmwg:parameters id="REQUIRED_ID" 
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <nmwg:parameter name="REQUIRED_NAME" value="OPTIONAL_VALUE"
-#                   xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#     <!-- ANY TEXT, OR ANY ELEMENT ANY NAMESPACE (IF YOU DID NOT 
-#          USE THE VALUE ATTRIBUTE) -->
-# 
-#   </nmwg:parameter>
-#  
-#   <!-- MORE PARAMETERS -->
-#   
-# </nmwg:parameters>
-# 
-# The namespaces can of course be different.
-# 
-# ##############################################################
+## ########################
+## layer 3 link
+## ########################
+ L3Link = element link { L3LinkContent }
+ L3LinkContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element remoteLinkId { xsd:string }
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element globalName {
+       attribute type { xsd:string }?
+       & xsd:string
+     }?
+   & element comments { xsd:string }*
+   & element netmask { xsd:string }?
 
-Parameters = 
-        element nmwg:parameters {
-                ParametersContent
-        }
-   
-ParametersContent =    
-        Identifier &
-        Parameter+
-   
-Parameter = 
-        element nmwg:parameter { 
-                attribute name { xsd:string } &
-                (
-                        attribute value { xsd:string } |
-                        (
-                                anyElement |
-                                text
-                        )
-                )
-        }   
+## ########################
+## layer 3 network
+## ########################
+ L3Network = element network { L3NetworkContent }
+ L3NetworkContent =
+   Identifier?
+   & IdReference?
+   & NodeIdRef*
+   & PortIdRef*
+   & LinkIdRef*
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element subnet {
+        Address
+        & element netmask { xsd:string }
+     }?
+   & element asn { xsd:integer }
 
+## ########################
+## layer 3 endpoint pair
+## ########################
+ L3EndPointPair =
+   element endPointPair { L3EndPointPairContent }
 
-# ##############################################################
-# Event type is a simple text element used to describe the
-# characteristic or event of the data.
-#
-# Example: 
-# 
-# <nmwg:eventType xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- TEXT -->
-#  
-# </nmwg:eventType>
-# 
-# ##############################################################        
+# an endpoint pair consists of two endpoints in the form of ports
+ L3EndPointPairContent =
+   Name*
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element src { (L3PortContent | PortIdRef | Address) }
+   & element dst { (L3PortContent | PortIdRef | Address) }
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
 
-EventType =
-        element nmwg:eventType { xsd:string }      
-
-   
+    <section anchor="topo_l4_schema" title="Layer 4 Topology Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
 # ##############################################################
-# The key is used to return a 'pointer' or otherwise special piece
-# of identifying information in response to a request. For now, 
-# this information is enclosed only within a parameters block.
-# The optional ID can be used to track past searches.
 #
-# Example: 
-# 
-# <nmwg:key id="OPTIONAL_ID" 
-#           xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- OPTIONAL PARAMETERS -->
-#  
-# </nmwg:key>
-# 
-# ##############################################################
-   
-Key = 
-        element nmwg:key {
-                Identifier? &
-                (
-                        Parameters |
-                        FilterParameters                                
-                )
-        }        
-        
-           
-# ##############################################################
-# The data block is complex and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet. 
+# File:    nmtopo_l4.rnc - Schema to describe L4 network elements
+# Version: $Id: nmtopo_l4.rnc 347 2008-05-20 15:55:47Z aaron $
 #
-# Example: 
-# 
-# <nmwg:data id="REQUIRED_ID" 
-#            metadataIdRef="OPTIONAL_REFERENCE_ID" 
-#            xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- OPTIONAL (MULTIPLE) METADATA -->
-# 
-#           <!-- OR -->
-#
-#   <!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND 
-#        OPTIONAL (MULTIPLE) DATUM ELEMENTS-->
-# 
-#           <!-- OR -->
-#  
-#   <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
-# 
-#           <!-- OR -->
-#  
-#   <!-- OPTIONAL (MULTIPLE) KEY ELEMENTS -->
-# 
-#           <!-- OR -->
-# 
-#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
-#   
-# </nmwg:data>
-# 
 # ##############################################################
-   
-Data =
-        element nmwg:data {
-                (
-                        Identifier &
-                        MetadataIdentifierRef? &
-                        (
-                                Metadata* |
-                                (
-                                        commonTime+ & 
-                                        Datum*
-                                ) |
-                                Datum* |
-                                Key*
-                        )
-                ),
-                anyElement*
-        }
 
 # ##############################################################
-# CommonTime is used as a shortcut that is able to 'factor out' 
-# a frequently occurring time range that a group of datum (or 
-# other) elements might share, thus reducing the verbosity of the 
-# XML representation. CommonTime is similar to the other NMWG time 
-# stamps (from nmtime.rnc) in its potential time representations.
-#
-# It is unfortunate that it needs to be in this file and not
-# nmtime.rnc, but as it occurs outside the datum, it is here.
-#
-# Example: 
-# 
-# <nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
-#                  duration="OPTIONAL_DURATION" 
-#                  inclusive="OPTIONAL_INCLUSIVE_FLAG"
-#                  xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
-# 
-#   <!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR
-#         DURATION) -->
-#  
-#   <!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) -->
-#  
-#   <!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE
-#         ATTRIBUTE) -->
-#  
-#   <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
-# 
-#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
-# </nmwg:commonTime>
-# 
+# Namespace definitions
 # ##############################################################
+ default namespace nmtl4 =
+           "http://ogf.org/schema/network/topology/l4/20070707/";
 
-commonTime = 
-        element nmwg:commonTime {
-                (
-                        Type &
-                        (
-                                TimeStamp |
-                                (
-                                        StartTime & 
-                                        (
-                                                EndTime | 
-                                                Duration 
-                                        )
-                                )
-                        ) &
-                        Datum*
-                ),
-                anyElement*
-        }
+# External schema files
+ include "nmtypes.rnc"
 
+## ########################
+## layer 4 port
+## ########################
+ L4Port = element port { L4PortContent }
+ L4PortContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Address*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element capacity { xsd:string }?
+   & element mtu { xsd:string }?
+   & element comments { xsd:string }*
+   & element portNum { xsd:integer }?
+   & L4Link*
 
+## ########################
+## layer 4 link
+## ########################
+ L4Link = element link { L4LinkContent }
+ L4LinkContent =
+   Identifier?
+   & IdReference?
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element remoteLinkId { xsd:string }
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element globalName {
+       attribute type { xsd:string }?
+       & xsd:string
+     }?
+   & element comments { xsd:string }*
+
+## ########################
+## layer 4 network
+## ########################
+ L4Network = element network { L4NetworkContent }
+ L4NetworkContent =
+   Identifier?
+   & IdReference?
+   & NodeIdRef*
+   & PortIdRef*
+   & LinkIdRef*
+   & Name*
+   & Relation*
+   & Lifetime?
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+
+## ########################
+## layer 4 endpoint pair
+## ########################
+ L4EndPointPair =
+   element endPointPair { L4EndPointPairContent }
+
+# an endpoint pair consists of two endpoints in the form of ports
+ L4EndPointPairContent =
+   Name*
+   & element type { xsd:string }?
+   & element description { xsd:string }?
+   & element comments { xsd:string }*
+   & element src { (L4PortContent | PortIdRef | Address) }
+   & element dst { (L4PortContent | PortIdRef | Address) }
+                        ]]></artwork>
+        </figure>
+      </t>
+    </section>
+
+    <section anchor="topo_ctrlplane_schema" title="Control Plane Topology 
Schema">
+      <t>
+        <figure>
+          <artwork><![CDATA[
 # ##############################################################
-# The datum is meant to be generic in this case because specific
-# namespace declarations should be used to better define what
-# format that datum should have.
-#
-# Example: 
 # 
-# <nmwg:datum ANY_ATTRIBUTE
-#             xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
+# File:        nmtopo_ctrlplane.rnc
+# Version: $Id: nmtopo_ctrlplane.rnc 267 2007-09-14 17:56:01Z swany $
 # 
-#   <!-- ANY ELEMENT IN ANY NAMESPACE OR ANY TEXT -->
-#  
-# </nmwg:datum>
-# 
 # ##############################################################
 
-Datum =
-        element nmwg:datum {
-                anyThing  
-        }
-        
-         
-# ##############################################################
-# Common elements are defined as named patterns as they are re- 
-# used several times.
-# ##############################################################
-                
-Identifier =
-        attribute id { xsd:string }
+namespace CtrlPlane =
+  "http://ogf.org/schema/network/topology/ctrlPlane/20070707/";
+namespace nmtl3 =
+  "http://ogf.org/schema/network/topology/l3/20070707/";
 
-MetadataIdentifierRef =
-        attribute metadataIdRef { xsd:string }
+include "nmtopo_l3.rnc"
 
-MessageIdentifierRef =
-        attribute messageIdRef { xsd:string }
-    
-Type = 
-        attribute type { xsd:string }    
+## Definition of the topology element
+start |= element CtrlPlane:topology { CtrlPlaneTopologyContent }
 
 
-# ##############################################################
-# This sequence allows any element, attribute, or text (regardless 
-# of name or namespace) into the document when invoked.
-# ##############################################################
+CtrlPlaneTopologyContent =
+  Identifier,
+ # Parameters,
+  element CtrlPlane:idcId { xsd:string }?,
+  (
+    CtrlPlaneDomain |
+    element CtrlPlane:domainSignature {
+      CtrlPlaneDomainSignatureContent
+    }
+  )*
 
-anyElement = 
-        element * { 
-                anyThing 
-        }
+## this a placeholder until we discuss and experiment with signatures
+CtrlPlaneDomainSignatureContent =
+  attribute domainId { xsd:string },
+  anyElement
+  
+CtrlPlaneDomain =
+  element CtrlPlane:domain {
+    Identifier,
+    ( 
+      CtrlPlaneNode*
+      & CtrlPlanePort*
+      & CtrlPlaneLink*
+    )
+  }
+  
+CtrlPlaneNode =
+  element CtrlPlane:node {
+    Identifier,
+    element CtrlPlane:address { xsd:string | L3Address }?,
+    CtrlPlanePort*
+  }
+  
+CtrlPlanePort =
+  element CtrlPlane:port {
+    Identifier,
+    CtrlPlaneCapacityContent,
+    CtrlPlaneLink*
+  }
+  
+CtrlPlaneLink =
+  element CtrlPlane:link {
+    Identifier,
+    ( 
+      element CtrlPlane:remoteLinkId { L3Address }
+      & element CtrlPlane:remotePortId { L3Address }
+      & 
+      ## only use when remotePortId isn't fully qualified
+        element CtrlPlane:remoteNodeId { L3Address }
+      & element CtrlPlane:remoteDomainId { L3Address }
+      & element CtrlPlane:trafficEngineeringMetric { xsd:string }
+      & element CtrlPlane:linkProtectionTypes { xsd:string }*
+      & CtrlPlaneCapacityContent
+      & element CtrlPlane:administrativeGroups {
+        CtrlPlaneAdministrativeGroup
+      }*
+      & element CtrlPlane:SwitchingCapabilityDescriptors {
+        CtrlPlaneSwitchingCapabilityDescriptor+
+      }
+    )
+  }
+  
+# Begin path and endpoint additions
+CtrlPlanePath =
+  element CtrlPlane:path { CtrlPlanePathContent }
 
-anyAttribute = 
-        attribute * { text }
+# a path consists of a list of hops, and/or links
+CtrlPlanePathContent =
+  Identifier &
+    element CtrlPlane:hop { CtrlPlaneHopContent }*
 
-anyThing = 
-        ( 
-                anyElement | 
-                anyAttribute | 
-                text 
-        )*
-        
-        
-# ##############################################################
-# This sequence allows any element, attribute, or text (only in the 
-# NMWG namespace) into the document when invoked.
-# ##############################################################
-        
-anyNMWGElement = 
-        element nmwg:* { 
-                anyNMWGThing 
-        }
+  
+CtrlPlaneHopContent =
+  Identifier,
+  ( 
+    DomainIdRef |
+    NodeIdRef |
+    PortIdRef |
+    LinkIdRef
+  )
+  
+# End path and endpoint
 
-anyNMWGAttribute = 
-        attribute * { text }
+CtrlPlaneAdministrativeGroup =
+  element CtrlPlane:group { xsd:int }
+  & element CtrlPlane:groupID { xsd:string }?
+  
+CtrlPlaneSwitchingCapabilityDescriptor =
+  element switchingcapType {
+    "psc-1"
+    | "psc-2"
+    | "psc-3"
+    | "psc-4"
+    | "l2sc"
+    | "tdm"
+    | "lsc"
+    | "fsc"
+  }
+  & element encodingType {
+      "packet"
+      | "ethernet"
+      | "pdh"
+      | "sdh/sonet"
+      | "digital wrapper"
+      | "lambda"
+      | "fiber"
+      | "fiberchannel"
+      | xsd:string
+    }
+  & element switchingCapabilitySpecficInfo {
+      CtrlPlaneSwitchingCapabilitySpecficInfo
+    }+
+    
+CtrlPlaneSwitchingCapabilitySpecficInfo =
+  CtrlPlaneSwitchingCapabilitySpecficInfo_psc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_tdm
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_lsc
+  | CtrlPlaneSwitchingCapabilitySpecficInfo_fsc
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_psc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_tdm =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_lsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_fsc =
+  element CtrlPlane:capability { xsd:string }
+  
+CtrlPlaneSwitchingCapabilitySpecficInfo_l2sc =
+  element interfaceMTU { xsd:int }
+  & element vlanRangeAvailability { xsd:string }
 
-anyNMWGThing = 
-        ( 
-                anyNMWGElement | 
-                anyNMWGAttribute | 
-                text 
-        )*        
-           ]]></artwork>
-       </t>
-  </section>
+## Capacity Description Pattern  
+CtrlPlaneCapacityContent =
+  element CtrlPlane:capacity { xsd:string }?
+  & element CtrlPlane:maximumReservableCapacity { xsd:string }?
+  & element CtrlPlane:minimumReservableCapacity { xsd:string }?
+  & element CtrlPlane:granularity { xsd:string }?
+  & element CtrlPlane:unreservedCapacity { xsd:string }?
+                          ]]></artwork>
+        </figure>
+      </t>
+    </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">
-       </section>
-  </section>
-  -->
 
-</middle>
+    </section>
 
-<back>
+    <!--
+            <section title="Appendices">
+                <section title="Acknowledgements">
+                </section>
+            </section>
+            -->
 
+  </middle>
 
-  <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>
+  <back>
 
-       <!-- 
-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.
+    <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>
+    </references>
+  </back>
 
 </rfc>