ROADM: input channel power for boosters on different degrees of a ROADM

[jktjkt]

Following up from today's coders call with @EstherLerouzic, @ojnas and @ggrammel. The problem is that we want to have different input powers for different boosters within a single ROADM. This is important for integration with SDN controllers, for modelling of disaggregated ROADMs, and has been also seen in practical day-to-day operation by Esther's colleagues. Right now they are implementing manual workarounds, including manual tweaking of the ROADMs' output power once per each degree, etc.

Existing code

Today, we're using this topology:

Unfortunately it is not possible to have different power at the wide colored links because in our current code, the propagate method and the __call__ operator operate on one node only. There's a proposal to extend __call__ with another option, next_node, but only for ROADMs.

Per-degree "output stage"

One proposal (which I mistakenly attributed to Jonas, but in the end it's mine misunderstanding) was to do it like this:

That way we can control the input power to each booster. The cost of this solution is that it does not reflect the way how ROADMs are built. Suddenly there are multiple links from a preamp. That does not reflect reality; it implies that there's, maybe, a splitter, but the power is actually not being split. Also, for the route-and-select ROADM design, it moves out all of the route-side WSSes into the select-side box, which is once again rather confusing.

Per-degree "ROADM degree"

An abstraction like this won't work, unfortunately: If this needs, say, -20dBm per channel at point A, and this means that there will also be exactly -20dBm per channel at points B, C and D (because there's no next_node for Element.__call__). If "Booster 2" needs, say, -15dBm per channel at point E, then we have a discrepancy with reality because "Degree 2" suddenly has to "create power". That would be rather confusing when shown to the user.

Complex topology with "ROADM stage" per ingress and per egress of every degree

We could have one explicit GNPy-level Element for the ingress and egress stages of the express path, like this: This way per-degree output power is made explicit by setting it at the egress part of each ROADM degree. The drawback is that this model requires 2×N ROADM elements per N-degree real-world ROADM node, and plenty of internal links.

There's a question if we can effectively hide this to the user, so that they do not have to deal with the complex topology, and that the amount of explicit boilerplate is reduced. One option is splitting the internal representation within GNPy (the Python code) from the input JSON files (existing "legacy ones" as I'm calling them, and also the new, YANG-based inputs). From my point of view that's special-purpose code. The other option is using cross-layer adaptations from ietf-netowrk-topology YANG model. Essentially, this is about defining "higher level views" of the low-level network by aggregating certain network elements together, and offering the user a choice of seeing either the raw data, or a higher-level view.

Needs decision by the coders team

We have to decide what to do:

• We can take Esther's patch which adds per-degree per-channel TX power as a solution for this problem.
• We can say that the official solution is to use one ROADM GNPy element per degree. If we do that, then:
  • We can ignore users' concern about complexity, and expose all of the low-level elements and links to the users.
  • Or we can implement some element aggregation:
  • Perhaps at the YANG level via the ietf-network-topology cross-layer tie-ins. That could work for collapsing OMS, and presenting a high-level map in the UI showing "just the PoPs".
  • We could combine all ROADMs together "as a rule". That way, the text UI can (with a flag?) silently combine all "ROADM building blocks" that are propagated through into one virtual enity.
  • The configuration can be, possibly, decoupled from the in-memory data structures. That way, the configuration could contain one "ROADM" super-node with per-degree channel TX power, and this can be translated into the complex topology (one node per ingress and one node per egress per each degree) over which the Python code calls propagate.

[ojnas]

Thanks, this is a good summary. I think the discussion in today's call was good and useful. At least to me the issues with different proposals became clearer. I agree now that proposal 2 (Per-degree "ROADM degree") does not really make sense and the number of links required would anyway be the same as for proposal 3 ("ROADM stage" per ingress and per egress of every degree). I think proposal 3 is the cleanest solution and it would also help solving the problem of computing valid paths for non-directionless ROADMs (which are commonly deployed in today's networks).

I also think the idea of using a multi-level (two levels sufficient?) topology corresponding to different levels of aggregation + cross-level relationships is interesting.

[EstherLerouzic]

Thanks for the summary. I still believe that adding this complexity on ROADMs modelling is going on the wrong direction. In most cases (deployed single vendor roadm) the internal optical power propagating between ingress and egress is not known, and this model will give the impression to the user that he can have access to the internal power, which is wrong in my opinion. so this over modelling is adding confusion and complexity to user, just for simplifying the internal code for propagation and path computation. Besides, I have proposed a solution, the same one that has been part of all demos and which solves the issue for per degree power. So my preference is not to delay anymore on this , by developping another layer of modelling and go for pragmatic: we have users that have expressed the need for per degree, we have a solution. Let's not wait for a possible implementation that may come in some months if someone wants/has time to code it.

[ojnas]

One more point:

With proposal 3, besides 2xN degree elements, this solution would require additional add/drop elements and internal links not shown in the picture above. The advantage of this is that it would make it easier to take into account different OSNR contributions from ROADMs having different add/drop architectures. Currently in GNPy, the ROADM add/drop OSNR contribution is added after propagation based on a single default value from the equipment configuration file, i.e. the same contribution is added independently of which ROADM in the network the signal is added/dropped through. In my opinion this limitation is as severe as not being able to set different input powers for different boosters within a ROADM.

[EstherLerouzic]

I think that this can also be solved with the current modelling of fig 1, in the same way I did for the per degree power: using a per degree container collecting all needed attributes is enough.. No need to add multiple elements nor their modelling to solve this issue.

[ggrammel]

Is there really a need to decide for one XOR the other implementation? I would think that by adding a "degree-device" in line with 'Per-degree "ROADM degree"' the user can choose if a simple ROADM model is sufficient or a more complex per-degree node is better suited. The only issue I see is that the "assembly of degree devices + fibers etc" that would represent a ROADM would need a common reference or naming structure to be identified as a ROADM-node.

Am I missing something?

[jktjkt]

I think that this can also be solved with the current modelling of fig 1, in the same way I did for the per degree power: using a per degree container collecting all needed attributes is enough.. No need to add multiple elements nor their modelling to solve this issue.

I recognize that it would work, but I think that adding even more ad-hoc properties is not a good approach here. Where do we draw the line? It is true that GNPy doesn't really care whether the losses are split into a splitter and a WSS, or in any other way, but I think that it's a good thing to have the model aligned with (physical) reality. f we really require per-link properties, then we can consider putingt them into links -- but then again, the per-booster TX power is actually about something that controls the behavior of the ROADM Python class, so not really a "link property".

Anyway, I prefer modeling the ROADM stages separately because it's something that's already there, and in my eyes it's "beautiful", and better than adding one ad-hoc property for the pre-booster TX power.

Those who do not require that new feature can still use one "big whole ROADM" element as before, I do not plan to take that away.

Is there really a need to decide for one XOR the other implementation? I would think that by adding a "degree-device" in line with 'Per-degree "ROADM degree"' the user can choose if a simple ROADM model is sufficient or a more complex per-degree node is better suited. The only issue I see is that the "assembly of degree devices + fibers etc" that would represent a ROADM would need a common reference or naming structure to be identified as a ROADM-node.

Yes, I like this approach. From GNPy's point of view, this grouping of ROADM nodes is not needed, strictly speaking, because GNPy only cares about signal propagation, not (arbitrary) node naming. At the same time, we have attributes such as "city" which are not required for GSNR calculations; these are also candidates for moving to another layer.

But yeah, for GNPy the ROADM is really just a magic attenuator ("please attenuate to this dBm/ch, thanks") plus a "power broadcaster". The latter is not needed, strictly speaking, but several people said on Tuesday's call that it would be super-confusing to have multiple elements connected to one booster, for example. We might as well enforce that in the YANG constraints...

[EstherLerouzic]

but I think that adding even more ad-hoc properties is not a good approach here

That is precisely where we having diverging opinions. Colin Kelly's slide were perfectly inline with this per port modelling and that is my plan to use this way to implement his models.

Where do we draw the line?

what kind of line do you mean: I do not see any big issue here. Propagation model is not broken, Polito models still work. We are only talking about representation of ROADMS. And representation should be kept simple. So from my point of view that's the splitting into degree elements proposal that crosses the line

and in my eyes it's "beautiful"

maybe, but it will be really confusing to have this complex roadm that is not even capable to model the real physical roadm complex power equalization decisions.

still disagree to have this complex model to enable the per direction power différentiation, sorry.

[jktjkt]

On today's call we (@EstherLerouzic @ojnas @ggrammel @jktjkt) agreed that we're going to take this per-booster power level in and merge it as an exception. My understanding is that we won't be adding other per-degree properties to a single ROADM node in future. The alternatives, should a need for more properties/attributes arise, is to either model the full ROADM node as a set of smaller ROADM building blocks ("degrees"), or to figure out if it makes sense to use explicit ports for all nodes, and thereby add the explicit directionality to GNPy's internal network representation.

(Please comment here if this is not an accurate summary.)

[jktjkt]

And just rephrasing for clarity: we won't be adding other per-degree properties to a ROADM node in future.