perfsonar development work

Author: aaron
Date: 2007-09-14 13:27:04 -0400 (Fri, 14 Sep 2007)
New Revision: 266

Modified:
   trunk/nmwg/doc/nm-topo/nm-topo.xml
Log:
Add the identifier information from the wiki to nm-topo.xml



Modified: trunk/nmwg/doc/nm-topo/nm-topo.xml
===================================================================
--- trunk/nmwg/doc/nm-topo/nm-topo.xml  2007-09-13 23:24:25 UTC (rev 265)
+++ trunk/nmwg/doc/nm-topo/nm-topo.xml  2007-09-14 17:27:04 UTC (rev 266)
@@ -67,6 +67,128 @@
 
   </section>
 
+  <section id="identifiers" title="Identifiers">
+
+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 the various URNs in the OGF
+namespace. Thus, all identifiers must begin with "urn:ogf:network:".
+
+The format for the rest of the namespace consists of a set of name/value 
pairs.
+Each pair is separated by a ``:'' and each name and value is separated by a
+``=''.
+
+The only exception to this rule is when the identifier is ambiguous. If one
+wishes to construct an identifier, but does not know the address of the
+specific network element, 
+
+The ordering of the name/value pairs goes from the most general network 
element
+to most specific network element.
+
+Unidirectional Links
+
+An identifier for a unidirectional link consists of all the network elements
+required to 
+
+Bidirectional Links
+
+Unlike unidirectional links, bidirectional links can be specified either at 
the
+top-level or inside of a domain. Bidirectional links can include links that
+exists completely in one domain, as well as, links that cross domain
+boundaries. In these scenarios, the link identifiers would be different. For
+the link that exists completely inside a single domain, the identifier must
+include the domain field. If a link crosses domain boundaries, it must be
+identified with a top-level link identifier. 
+
+
+The Topology identifiers have been designed to be flexible, be very explicit 
in
+its meaning and still be reasonably human-readable. The identifier builds off
+the standard URN format described in RFC 2141. Thus, each ID begins with:
+
+<pre>
+urn:ogf:network:
+</pre>
+
+The format for the rest of the message consists of a series of name/value 
pairs
+separated by colons. The ordering of the name/value pairs is important 
because
+that defines the hierarchical structure of the device. It starts with the 
most
+general portion (the domain) and proceeds to the most specific portion of 
each
+id. 
+
+A domain id might look like this:
+
+urn:ogf:network:domain=Internet2
+
+Nodes, Paths, Networks and Bidirectional Links can come immediately 
following the domain. For example:
+
+urn:ogf:network:domain=Internet2:node=packrat
+urn:ogf:network:domain=Internet2:link=WASH to ATLA OC192
+urn:ogf:network:domain=Internet2:path=Mark's Path
+urn:ogf:network:domain=Internet2:network=192.168.0.0%2F24
+
+Below a node can exist ports. For example:
+
+urn:ogf:network:domain=Internet2:node=packrat:port=eth0
+
+Below a port can exist a unidirectional link corresponding to the link that 
can be written via this port. For example:
+
+urn:ogf:network:domain=Internet2:node=packrat:port=eth0:link=1
+
+Paths and Network can be global in scope as well as beneath a domain. For 
example:
+
+urn:ogf:network:path=anna-11537-176
+urn:ogf:network=128.4.0.0%2F16
+
+Partially-Known IDs:
+
+Replace the unknown element of the id with a '*'. It is only applicable, 
however, to the final
+piece of the ID. 
+
+Global domain, path and network IDs
+urn:ogf:network:domain=*
+urn:ogf:network:path=*
+urn:ogf:network:network=*
+
+Top-Level Domain IDs:
+urn:ogf:network:domain=Internet2:node=* 
+urn:ogf:network:domain=Internet2:link=*
+urn:ogf:network:domain=Internet2:path=*
+urn:ogf:network:domain=Internet2:network=*
+
+Node-specific IDs:
+urn:ogf:network:domain=Internet2:node=packrat:port=*
+urn:ogf:network:domain=Internet2:node=packrat:port=eth0:link=*
+
+Each element of the id is encoded using the URN syntax as stated in RFC 2141.
+This requires encoding the characters as follows:
+
+{| border="1" cellpadding="5" align="center"
+ | : || %3A
+ |-
+ | / || %2F
+ |-
+ | ? || %3F
+ |-
+ | # || %23
+ |-
+ | % || %25
+ |}
+
+
+The actual contents of each of the id's elements can be anything. The domain 
id element will be registered with an LS to allow an individual with an ID to 
easily find where to obtain information on the ID while minimizing the amount 
of information needed to be store in the LS.
+
+To look up information on an ID, a user would extract the domain id from the 
full id(e.g. if the user has the ID 
"urn:ogf:network:domain=Internet2:node=packrat:port=eth0", the domain id 
would be "urn:ogf:network:domain=Internet2"). The user would then connect to 
the LS (an easier task once the Multi-LS is widely available) and lookup the 
Topology MA using a query like:
+
+declare namespace nmwg="http://ggf.org/ns/nmwg/base/2.0/";;
+
+for $data in /nmwg:data
+  let $metadata_id := $data/@metadataIdRef
+  where 
$data//*:domain[@id="urn:ogf:network:domain=Internet2"]
+        and 
$data//nmwg:eventType[text()="http://ggf.org/ns/nmwg/topology/query/xquery/20070809";]
+  return 
/nmwg:metadata[@id=$metadata_id]
+
+  </section>
+
   <section id="basic_elements" title="Basic Elements">
     <t>This schema defines the basic elements that can be used to
     describe network topologies.