Open-Network-Models-and-Interfaces-ONMI
RI: Clarification about Transitional Links key attributes
It is not clear how to use the different attributes to qualify the transitional link.
Let's consider as an example the TL in slide 5 of onf2016.303.02.
I think that the two NEPs of this TL should have:
{
"_layerProtocol": [
{
"layerProtocolName": "ODU",
}
],
"uuid": "D1-o-TL"
},
{
"_layerProtocol": [
{
"layerProtocolName": "ETH",
}
],
"uuid": "D1-e-TL"
},
The transitional link can be defined as follows:
"_link": [ { "_linkPort": [ { "_nodeEdgePoint": ".../D1-o-TL/", }, { "_nodeEdgePoint": ".../D1-e-TL/", } ], "_node": [ ".../D1-o/", ".../D1-e/" ], "uuid": "transitional-link" } ],
In onf2016.355 there are also Total Pool Capacity, supported granularity and Max # instances attributes for the NEPS which are not present in T-API Topology IM. From that description, it seems that the OTN NEP can support 400G but the ETH NEP can only use 200G.
I guess that the TL capacity would then be 200G and we can represent this information using the Link attributes:
` "_link": [ "_transferCapacity": { "totalPotentialCapacity": { "totalSize": "200GBPS" } }, "uuid": "transitional-link" } ],
` Is my understanding correct? If so, why do we need the Total Pool Capacity attribute for the NEPs?
The Link has also the _lpTransition [1] package. This package seems applicable only to TL so why it is [1] and not [0..1]?
From the UML description, it is also not clear what information should be provided in this package:
transitionedLayerProtocolName: Provides the ordered structure of layer protocol transitions encapsulated in the TopologicalEntity. The ordering relates to the LinkPort role.
_nodeEdgePoint: Lists the LTPs that define the layer protocol transition of the transitional link.
How are these attributes used? Since the TL connects an ODU NEP with and ETH NEP, we can understand it is a TL. However, we need some additional information to indicate that the transition is from ETH client to ODU server and not vice-versa.
Also the use of the layerProtocolName [1..*] for the Link is not clear. Should it be ETH, ODU or [ ETH, ODU ]? Why this information cannot be inferrred from the fact that the two NEPs are ETH and ODU?
It would be easier t understand/discuss your questions by drafting an RI network database for the scenario you are describing.
Notes from the T-API call (January 10, 2017):
We agreed to that the _lpTransition package is applicable only to Transitional Links and to update its cardinality to [0..1]
@karthik-sethuraman : please update UML description and cardinality
Notes from the T-API call (January 10, 2017):
We agreed that the order in the transitionedLayerProtocolName is describing which layer is the client and which is the server. Therefore its cardinality should be [2..*] since there is always at least one client and one server layer.
@karthik-sethuraman : please update UML description and cardinality
Notes from the T-API call (January 10, 2017):
Remaining issues for further discussion:
- _nodeEdgePoint list in the pac – is it needed?
- How does the layerProtocolName list in the pac relate to the layerProtocolName list attribute of the Link
- Is the case of multiple layer transitions even valid for TAPI ?
While reporting the notes of the latest call, I have noted that we have not summarized previous discussion about the Total Pool Capacity, supported granularity and Max # instances attributes for the NEPs which are not present in T-API Topology IM but described in onf2016.355
If there is no need to support multiple layer transitions, then I think the cardinality of the transitionedLayerProtocolName attribute should become [2] instead of [2..*]
This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.
