modeling measured OSNR

[aguoietf]

This is what actual GSNR is modeled today in WDM tunnel:

augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information:
    +--ro wdm-path-state
       +--ro gsnr?   l0-types:snr

There are scenarios where there is 3R regens on an LSP, resulting in multiple receivers along the path. There is also the inverse multiplexing scenario where there can be multiple receivers of the same LSP.

The principle for modeling a state parameter is that if that parameter is needed for path computation then it should be defined in l0-types and exposed in the OI topology.

For example, channel-power could be needed by path computation. OSNR is an estimated value for an established OTSi, and it is not needed by path computation but rather it is monitored during maintenance.

The "snr value" is measured and reported by a coherent transceiver. It is implementation specific and can be reported by a transceiver as osnr or esnr. It should not be called gsnr

Q: should snr values be reported on a transceiver?

• Yes. And also the type of transceiver must be reported as well. Q: should gsnr be reported by both OI topology and WDM tunnel?
• OI topology does not report actual information but only needed information for path computation and service provisioning
• Also the WDM tunnel model should not report SNR (or GSNR) values
• (Pre-FEC) BER, (pre-FEC) Q-factor, channel power should be reported by the WDM tunnel.
• Also the timestamp of the BER/Q-factor indicating the last updated time of these parameters from the controller.
• An alternative proposal is to report all service assurance related attributes in a separate model, similar to the TAPI definition. This can be explored in the future (and can be explained in the WDM tunnel document).

Q: should gsnr definitions be moved to l0-types?

• No because gsnr is not needed for path computation.

We need to further decide whether service-assurance related parameters should be reported by the WDM tunnel or be reported separately. Therefore it is agreed that these parameters will not be included in the WDM tunnel model for now.

[EstherLerouzic]

Hello

regarding the discussion on snr discussion. It is not clear to me what is meant by snr here and what will it be used for:

case 1: this is a value computed at commissioning thanks to BER or Q factor, then the method should be reported. Besides, an old value it is not anymore a valid value because of system loading or ageing. So I can not really exploit it. I would rather look at the current BER or Q factor and refer to the B2B curve.

case 2: this is a value reported by transceiver: I have no clue of what is exactly reported, because there is no common (standard?) method used by transceivers to expose SNR, so that I don't know what I am looking at. so I can not exploit it.

case 3: I could monitor the value on the long term to monitor service degradation, but I can not assume that the value reported in tunnel is fresh: it may be from last week, last month... so not really useful to monitor quality.

case 4: this is a value computed at planning phase including expected degration till end of life (eg full load, ...). Then I can not exploit it, because I don't know what are the assumption and methods used for computing it. So I can not compare with computations I would do today.

In all case, I can not exploit what is reported, because I don't know:

• how this was measured/computed
• when it was measured/computed

My take is that:

• BER and Q factor would be enough for my usage of the tunnels (precising in the model definition that this is last extracted values for example), to have a snapshot of my tunnel health and compute possible remaining margin (provided I have BtB curves).
• If some snr value is reported by transceivers, this should be added in interface so that I can use PM telemetry to monitor its evolution (relative values being already a good insight of health, even if I don't really know what it is). a reference to the method used to compute it would be appreciated.
• if some snr value is reported in the tunnel, then this should include the measurement/computation method and time of measurement (last extraction or initial values or planning for example).

Lastly, the only standard I know about GSNR measurement is [T-REC-G.977.1-202010-I!!PDF-E.pdf] and it says "Standardized techniques for the measurement of SNRi, are still under study". The example in the doc relies on btb curves. So we should be careful when using the term SNR or GSNR.

regards

[sergiobelotti]

This is what actual GSNR is modeled today in WDM tunnel:

augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information:
    +--ro wdm-path-state
       +--ro gsnr?   l0-types:snr

There are scenarios where there is 3R regens on an LSP, resulting in multiple receivers along the path. There is also the inverse multiplexing scenario where there can be multiple receivers of the same LSP.

The principle for modeling a state parameter is that if that parameter is needed for path computation then it should be defined in l0-types and exposed in the OI topology.

For example, channel-power could be needed by path computation. OSNR is an estimated value for an established OTSi, and it is not needed by path computation but rather it is monitored during maintenance.

The "snr value" is measured and reported by a coherent transceiver. It is implementation specific and can be reported by a transceiver as osnr or esnr. It should not be called gsnr

Q: should snr values be reported on a transceiver? - Yes. And also the type of transceiver must be reported as well. Q: should gsnr be reported by both OI topology and WDM tunnel? - OI topology does not report actual information but only needed information for path computation and service provisioning - Also the WDM tunnel model should not report SNR (or GSNR) values - (Pre-FEC) BER, (pre-FEC) Q-factor, channel power should be reported by the WDM tunnel. - Also the timestamp of the BER/Q-factor indicating the last updated time of these parameters from the controller. - An alternative proposal is to report all service assurance related attributes in a separate model, similar to the TAPI definition. This can be explored in the future (and can be explained in the WDM tunnel document).

Q: should gsnr definitions be moved to l0-types? - No because gsnr is not needed for path computation.

We need to further decide whether service-assurance related parameters should be reported by the WDM tunnel or be reported separately. Therefore it is agreed that these parameters will not be included in the WDM tunnel model for now.

Q: should gsnr definitions be moved to l0-types? - No because gsnr is not needed for path computation @aguoietf : not clear to me this comment since gsnr is already there in l0-types. Should we remove from that? l0-type has already:

• gsnr-extra-margin as constraint

and as path-properties

• estimated-gsnr
• estimated-eol-gsnr
• estimated-lowest-gsnr

Optical Impairment topology model has:

• generalized-snr under OMS-attributes