Telecominfraproject / oopt-gnpy

Optical Route Planning Library, Based on a Gaussian Noise Model
http://telecominfraproject.com
BSD 3-Clause "New" or "Revised" License
197 stars 87 forks source link

Can we introduce termination-port in GNPy ROADM attributes ? #425

Open EstherLerouzic opened 2 years ago

EstherLerouzic commented 2 years ago

There is no way today to identify which OMS is reversed from a given OMS on a bidirectional topology. This matching is only implicit: if there is only one OMS from ROADMA to ROADMB, and only one from ROADMB to ROADMA then these two can be associated. But in case of parallel OMS (several with the same ROADM end points) we have no clue about how the bidir entity should be associated. This is in particular an issue for spectrum assignment, and also for GUI representation if bidir links need to be represented out of a topology. eg: what is the correct association ? OMS1 + OMS3 or OMS1 + OMS4 OMS1 : ROADMA -->- element1 --- element2 --- element3 --- ROADMB OMS2 : ROADMA -->- element4 --- element5 --- element6 --- ROADMB OMS3 : ROADMA --<- element9 --- element8 --- element7 --- ROADMB OMS4 : ROADMA --<- element12 --- element11 --- element10 --- ROADMB

Since we plan to base the model on the ietf network topology RFC8345, we will benefit from source-tp and dest-tp which can be used to associate links in case of bidir

" An OMS Media link is terminated on both ends by a link termination point (LTP) as defined in [RFC8345]. Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional links following the [RFC8345] modeling approach. Unlike TE links, which are unidirectional, the LTPs on either end of the TE link pair forming the bidirectional link, are bidirectional as described in [I-D.ietf-teas-te-topo-and-tunnel-modeling] and the pair of unidirectional links are connected to the same bidirectional LTP on either end of the link pair."

So if we also introduce tp in the ROADM attributes, we may also use the same property, i.e use tp identifier to identify parallel OMS:

for example: it could be a tp dict:

eg ROADMA { tp-c: [element1, element9], tp-f: [element4, element12] } ROADMB { tp-a: [element3, element7], tp-b: [element6, element10] }

OMS1 (tp-c) : ROADMA -->- element1 --- element2 --- element3 --- (tp-a) ROADMB OMS2 (tp-f) : ROADMA -->- element4 --- element5 --- element6 --- (tp-b) ROADMB OMS3 (tp-c) : ROADMA --<- element9 --- element8 --- element7 --- (tp-a) ROADMB OMS4 (tp-f): ROADMA --<- element12 --- element11 --- element10 --- (tp-b )ROADMB

jktjkt commented 2 years ago

This sounds related to the per-degree parameters (currently only the launch power) we discussed in #365, where we also indicated that adopting the concept of "ports" is one possibility.

This particular problem, however, can be probably also solved by adding an explicit notion of "bidirectional mapping" to other elments, though (typically to fibers and in-line amplifiers). That way it would be possible to say that element1 and element4 refer to the same fiber pair, and that element2 and element5 are the W->E and E->W stages of the same ILA. I'm not saying that this is better, just offering another (possible) approach. Also, I think this is something that we need to address for the GUI anyway.

Let's talk about this today on the coders call.

ojnas commented 2 years ago

For reference, here is how OpenROADM handles bidirectionality by introducing an "opposite-link" attribute in the network model:

https://github.com/OpenROADM/OpenROADM_MSA_Public/blob/9ae5192c79f9b1bbcefd2344b24a71d55670b02c/model/Network/org-openroadm-common-network.yang#L212