Open-Network-Models-and-Interfaces-ONMI
RI: Clarification about Layer Protocol information in Node and NodeEdgePoint object classes
If I recall correctly, in this version of T-API, we are assuming that Nodes and (non transitional) Links have only one LayerProtocol. All the multi-layer use cases/examples have been described in line with this assumption.
However:
- The Node object class has the following attribute: layerProtocolName [1..*]
Does it mean that in this version it is [1] and [2..*] is considered experimental? Is this written somewhere?
- The NEP has the following association: NodeEPIncludesLP [1...*]
Does it mean that in this version it is [1] and [2..*] is considered experimental? Is this written somewhere?
What is the relationship between the layerProtocolName in the associated LayerProtocol instance and the layerProtocolName attribute of the node that owns this NEP?
It seems that they should be the same. If so, why the information is duplicated?
Looking at the RI, I am getting even more confused since I see that: -node 1 owns NEPs with different layer protocols
- node 1 has only one layer protocol "OCH"
"_ownedNodeEdgePoint": [ { "_layerProtocol": [ { "layerProtocolName": "ETH", } ], "uuid": "pe113" }, { "_layerProtocol": [ { "layerProtocolName": "OCH", } ], "uuid": "pe11" }, ], }, "layerProtocolName": [ "OCH" ], "uuid": "node1" },
What does it mean?
What would have been the differences with respect to these cases:
a) ETH
"layerProtocolName": [ "ETH" ],
b) ETH+OCH
"layerProtocolName": [ "ETH" "OCH" ],
c) OCH+ETH
"layerProtocolName": [ "OCH" "ETH" ],
d) ODU
"layerProtocolName": [ "ODU" ],
I am missed in this multi-layer issues. Typically the NEPs which serves as SEPs are ETH. Which is the combination/topology that should be enforced? @karthik-sethuraman please comment
@rvilalta : When I try to map detailed attributes to the the multi-layer use cases/examples I am getting confused. I was planning to raise the question for clarification with a reference to onf2016.303.02 but I then decided to use the RI since it is in the public domain. I think we can easily update the RI once it is clear how to use these attributes.
- In Node/NodeEdgePoint/regular-Link model, the layerProtocolName is a list, but TAPI examples have only considered/illustrated single layer Node/ NEP/ regular-Link scenarios since we expect the bulk of practical use cases/implementations to be like this.
- In (unspecified) general case, the layerProtocolName of the Node is expected to be a super-set of all the encompassed NodeEdgePoint layerProtocols.
- TransitionalLink – multi-layer by definition, NEP at each end is of different layer
- Topology – typically multi-layer – could contain Nodes of different layers interconnected by Transitional-Link - so layerProtocol of the Topology is a super-set of all Node and Link layerProtocols
The current RI network database is very simple and more geared towards testing the API. We should draft multi-layer network examples for the RI, which considers various combinations.
Notes from the T-API call (January 10, 2017):
We agreed to clarify that:
- In the general case, the layerProtocolName of the Node is expected to be a super-set of all the encompassed NodeEdgePoint layerProtocols.
- In this version, a Node encompasses single-layer NodeEdgePoints at the same layer and therefore the cardinality [2..*] for the layerProtocolName attribute of the Node object is experimental.
- In this version, a NodeEdgePoint is single-layer and therefore the cardinality [2..*] for the NodeEPIncludesLP association is experimental.
@karthik-sethuraman : please update UML descriptions
This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.
