Hi,
In case of pS, wouldn't be usedful to have a representation of the interface as bidirectional?
It is possible to group unidirectional nml:Ports and have nml:BidirectionalPort
an example:
<nml:BidirectionalPort id="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-in"> </nml:BidirectionalPort>
In case of these ps measurements I would even argue that it is useful to have directed ports. The example is about bandwidth utilization, which is really a measurement in one specific direction.
the node could be related to the BidirectionalPort (as a router/switches has physical interfaces that at the same time allows in and out traffic.
Currently, in NML the nml:Node is related to (unidirectional) nml:Ports, and two nml:Ports can be related to a nml:BidirectionalPort. The reason for this is that it unambiguously encodes the direction of each Port. Note that nml:Ports represent logical datatransports, so it's not necessary a physical interface of a router or switch. I once asked how useful it would be to represent a physical interface, but making that explicit relation was considered unneeded, as NML is mostly used in a multi-domain environment, thus for exchanging topology info between domain, and in that scenario you are likely to describe the function rather than the implementation of that function at specific devices. That hasn't prevented people from assigning nml:Port identifiers to physical interfaces. I'm very interested to hear about practical use cases where such distinction is relevant and how you like to relate the different elements. FV: I am kind of following you know.
As Roman correctly pointed out, it is possible to associate both directed Ports together, so you can programmatically find the two RRD files and put them in the same graph.
FV: How would you do that without a BidirectionalPort? Parsing IDs? I think it would look more robust to have the BidirectionalPort representation and have the nodes composed of BidirectionalPort's.
No, parsing IDs is kind of "not done" (as it would imply adding attributes to an identifier, which is problematic if those attributes change. Got a long discussion with some URN zealots on this, and fear they brainwashed me too ;) ). A Node is related to (unidirectional) Ports using the "hasInboundPort" and "hasOutboundPort" relations. If a node has such a relation with two of Ports, and these two Ports are grouped as a BidirectionalPort, then you can say that the Node contains this BidirectionalPort. FV: Fine, I am following you now.
In this case, the direction is indicated by the relation between the node and the port:
<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboudPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasOutboubdPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out" /> </nml:Relation> </nml:Node>
FV: Indeed, but if you start having several Port elements for each direction, how would you represent the bidirection for a single interface? ID parsing?
Combine the two XML examples, so you have all four relations Node --hasOutboundPort--> Port 1 --hasInboundPort--> Port 2 BidirectionalPort Port 1 Port 2 Or: Node --hasOutboundPort--> Port 1 --hasInboundPort--> Port 2 BidirectionalPort Port 1 Port 2 We are aware that this is not ideal XML, but an unfortunate consequence that our UML schema is not fully hierarchical, and contains circular relations (such as in this common case), which we can only describe in XML using the id/idRefs. Here is the full XML:
<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboudPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasOutboubdPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out" /> </nml:Relation> </nml:Node> <nml:BidirectionalPort id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out"> </nml:BidirectionalPort>
FV: Fine, I am following you now. Thanks, Fausto Vetter Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br Telefone: +55 (21) 2102 9696 E-mail: fausto.vetter@rnp.br