search

openconfig / public

Repository for publishing OpenConfig models, documentation, and other material for the community.
Apache License 2.0
891 stars 645 forks source link

Attenuator mode - system controlled #1146

Closed ejbrever closed 4 weeks ago

ejbrever commented 1 month ago

@kcroussore

Today in the optical attenuator model, modes are supported for constant power and constant attenuation. In some platforms, Nokia OLS for example, the system can derive the appropriate targets and adjust as necessary. An example of this use is taking into account a fiber span loss measurement which can be used to derive the optimal optical attenuation. As the the span loss will vary over time, the system would adjust as needed.

I'd like to propose adding a new attenuation mode of SYSTEM_CONTROLLED for this use case.

kcroussore commented 1 month ago

I think this makes sense and will prove useful: CONSTANT_POWER = system is respecting a fixed, externally defined power target CONSTANT_ATTENUATION = system is respecting a fixed defined attenation regardless of input, output power SYSTEM_CONTROLED = system is determining the proper power target and setting attenuation to meet that target

ggrammel commented 1 month ago

@ejbrever in the example https://github.com/openconfig/public/issues/1146#issue-2401891193 you mention OLS and "system" and I wonder about two points: which entity is actually controlling the span loss compensation and how (in general terms) this is supposed to operate in an OC context? My understanding is: to figure out the span loss, a control logic needs to know the TX power of the upstream U-AMP and the Rx power at the downstream D-AMP so that the U-AMP can adjust the Tx-power according to what the D-AMP is measuring as rx-power. IOW if the controller does not set the power or attenuation, then SYSTEM_CONTROLLED would require an undefined communication protocol running between U-AMP and D-AMP. The other point is about which entity ("system") is supposed to perform the calculation of "appropriate targets". The proposal seems to suggest it is not the OC-controller but perhaps the AMP itself is setting its own targets. In that case, would computing those targets require (initial) configuration by an OC-controller and would it require additional input such as e.g. Rx-power at U-AMP to get the job done?

ejbrever commented 1 month ago
  1. There is a protocol running between the near/far end amps, it is the optical supervisory channel.
  2. Correct, the device itself (and not the OC controller) would calculate its own targets, but there isn't a need for additional OC driven configs. If that becomes necessary in the future, I think we can decide how to add support for it.
dplore commented 1 month ago

I think it's ok to add the state leafs for this in https://github.com/openconfig/public/pull/1147 without the config in the same pull request if you don't have the need to read/write such config. (Guess it might be enabled by default on some devices?)