perfsonar development work

[Freek Dijkstra <>]

Hi all,

In Geant3, we want to add cross-layer functionality to E2Emon. We're
currently considering a few options, and have a few questions we like to
get straightened up before we propose those options.

For ease of discussion, here is an example topology information as
served by our current E2Emon service.
(see also e.g.
http://cnmdev.lrz-muenchen.de/e2e/lhc/mon/G2_E2E_view_e2elink_CERN-TRIUMF-LHCOPN-001.html)

 <?xml version="1.0" encoding="UTF-8"?>
 <nmwg:message
   xmlns:nmtl2="http://ggf.org/ns/nmwg/topology/l2/3.0/";
   xmlns:nmwgtopo3="http://ggf.org/ns/nmwg/topology/base/3.0/";>
 [...]
   <nmwg:metadata id="metadata.11891256">
     <nmwg:subject id="sub.8014380">
       <nmtl2:link>
         <nmtl2:name type="logical">
           5004LE-asd001a_ome13-1-13-2</nmtl2:name>
         <nmtl2:globalName type="logical">
           CERN-TRIUMF-LHCOPN-001</nmtl2:globalName>
         <nmtl2:type>ID_LinkPartialInfo</nmtl2:type>
         <nmwgtopo3:node nodeIdRef="NETHERLIGHT-AMS">
           <nmwgtopo3:role>demarcpoint</nmwgtopo3:role>
         </nmwgtopo3:node>
         <nmwgtopo3:node nodeIdRef="CANARIE-CHCG1OME2">
           <nmwgtopo3:role>demarcpoint</nmwgtopo3:role>
         </nmwgtopo3:node>
       </nmtl2:link>
     </nmwg:subject>
   </nmwg:metadata>
 [...]
 </nmwg:message>

Basically, this describes a port with attached link,
"5004LE-asd001a_ome13-1-13-2", which is part of the end-to-end circuit
"CERN-TRIUMF-LHCOPN-001". Furthermore, this link is between nodes
NETHERLIGHT-AMS and CANARIE-CHCG1OME2.

We have a few observations (or assumptions if you will). Can you confirm
if those are correct?

- The name "5004LE-asd001a_ome13-1-13-2" refers to the bidirectional
link between NETHERLIGHT-AMS and CANARIE-CHCG1OME2, even though the
peering domain would use another link description (in this case, CANARIE
describes it as "CANARIE-TRIUMF-CERN_ChiNYC").

- The links are matched based on the nodes (nodeIdRefs) and end-to-end
path name (globalName).

- The node names are supposed to refer to device names, not to domain
names. Thus if the (name of a) node at a domain boundary chances, all
peering domains must chance their description as well.

- However, if the link name chance (e.g. because the interface chances)
at a domain boundary, the peering domains need NOT to chance their
descriptions.

- It is possible to describe multiple channels over a single physical
interface by describing each channel with a different logical name. For
example, assume that the above link between NETHERLIGHT-AMS and
CANARIE-CHCG1OME2 carries 2 channels, the link logical names could be
5004LE-asd001a_ome13-1-13-2-channel-1 and
5004LE-asd001a_ome13-1-13-2-channel-2. In this case, the peering domain
must also describe each channel with the same end-to-end path name
(globalName) and node names.

- The matching assumes that all LinkPartialInfo descriptions with one
common nodeIdRef are connected (have a cross-connect) at that node. Thus
a theoretical scenario where one would have two separate cross connects
for the same end-to-end path in the same device can not be described in
E2Emon (for a single layer this indeed makes no sense, for multiple
layers, such "loops" may indeed exists, even though they are not still
rare).

Regards,
Freek Dijkstra and Peter Tavenier
SARA