[TRNSPRTPCE-199] OTN Topo update from Renderer

Blocks — Fri, 3 Sep 2021 13:20:11 +0000

OTN services are created sequentially. This implies needed supporting services are present and supporting links have been populated in the topology to allow path calculation. Thus we need to populate OTN link in topology after OTN service has been succesfully provisionned:
_Links (OTU4, ODTU4)
_Available trib-slots/ trib ports

This stories includes the creation of all methods required in both OTN Renderer as well as Topology management. Link discovery based on accepted SAPI and DAPI on the interfaces has been put temporarly aside because SAPI and DAPI are optional parameters that may or may not be in the device models depending on the vendors.

The PCE needs these information to validate the node tp during path calculation :
_Creation of ODU4 implies the presence of an OTU4 link and that no ODU4 is already present on the tp (no available trib-slot in xpdr-tp-port-connection-attributes)
_Creation of ODU LO implies the presence of available trib-slot on th tp
Even if ideally the topology shall be updated dynamically from notification coming from the device, we need a feasible intermediate solution to handle service creation

Evaluation indicators: code pushed on master branch, not necessarily merged, build + Junit OK, functests passed. Number of Spotbugs issues for Network model and Renderer has not increased.

OpenDaylight JIRA

[TRNSPRTPCE-199] OTN Topo update from Renderer