Re: [802.3_DWDM] Implications of SIGNAL

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi All,

The info in this discussion is useful. There have been a few discussions in the background on this, and I notice in the responses to comments that some of the responses mention for TF discussion. I won’t be on this Thursday’s call but hopefully we can dig into this next week.

There are (at least) two issues to address here.

As Matt points out, most of the concern is about SIGNAL_DETECT = FAIL not being raised for amplified applications. This is unavoidable if total power detection is used for SIGNAL_DETECT in an amplified system with the power and OSNR ranges we’ve specified in 802.3ct. We could consider addressing this by allowing SIGNAL_DETECT to be based on a measured signal power rather than total power. Some of the SFF specs provide registers to indicate whether client module powers are being reported in OMA vs Average Power. It’s worth considering including Signal Power as an optional metric. At minimum the language needs to indicate that using total power for this may result in SIGNAL_DETECT failing to be raised – there is a comment to this effect.

The other issue is support for the two applications. It’s worth pointing out that OIF published IA has a requirement that for modules supporting both the amplified and unamplified applications the LOS level be programmable to support the two applications.

There are other alternatives such as gating the SIGNAL_DETECT with Lock_Detect before reporting, this could be useful from an alarming perspective, it prevents SIGNAL_DETECT from bringing a link down which could be a bug or a feature depending on perspective. So, we should have plenty to discuss.

Regards, Eric

On Tue, Jun 30, 2020 at 3:18 PM Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx> wrote:

Leon and Pete,

Thanks much for the clarification – that’s more or less what I suspected, but I wanted to confirm that I wasn’t coming to an incorrect conclusion.

In that case, it seems like we would want to bias things to not set SIGNAL_DETECT to FAIL if there is, in fact, a valid signal. In looking at the proposed response to the various comments that touch on this topic – which seems to go in the other direction, but with a TBD note about this case – I will be very interested in seeing how such a proposal would address this issue. Especially since sensitivity down to -30 dBm is critical for the MSO access network business case, which is a key part of the broad market potential.

Thanks again.

Matt

From: "pete@xxxxxxxxxxxxxxx" <pete@xxxxxxxxxxxxxxx>
Date: Tuesday, June 30, 2020 at 1:22 AM
To: Matt Schmitt <m.schmitt@xxxxxxxxxxxxx>, "STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx" <STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx>
Cc: 'Leon Bruckman' <leon.bruckman@xxxxxxxxxx>
Subject: RE: [802.3_DWDM] Implications of SIGNAL_DETECT = FAIL

CableLabs WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

Matt,

The value of the SIGNAL_DETECT variable is passed upwards in the stack via the PMD:IS_SIGNAL.indication primitive. See 154.2.

This signal is passed through successive layers above this as shown in Figure 80-4a.

The PMA sublayer combines the signal passed to it by the PMD sublayer with its own logic (SIL) as described in Figure 83-5 and the text below it. The combined signal is passed to the SC-FEC sublayer via PMA:IS_SIGNAL.indication primitive.

The SC-FEC sublayer uses this signal to set the variable signal_ok (see 153.2.4.1.1):

This variable is used in Figure 153-7 (SC-FEC synchronization state diagram) where it is one of the conditions causing the synchronization process to restart.

As a consequence of the above, if the PMD sublayer sets SIGNAL_DETECT to FAIL, the link is brought down.

Regards,

Pete Anslow (pete@xxxxxxxxxxxxxxx)

From: Leon Bruckman <leon.bruckman@xxxxxxxxxx>
Sent: 30 June 2020 07:03
To: STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DWDM] Implications of SIGNAL_DETECT = FAIL

Hi Matt,

I think you are right. According to 802.3 clause 91.2: When SIGNAL_OK is FAIL, the rx_bit parameters of the FEC:IS_UNITDATA_i.indication primitives are undefined.

This implies that if this signal is FAIL data is not reliable. According to Table 154-5, there are very specific conditions for SIGNAL_OK to be set to OK or FAIL, while for other conditions (last row in the table) it is unspecified, so in my opinion it may be set to FAIL or OK, but you can not rely on it.

To summarize: For the data to flow normally SIGNAL_OK must be set to OK. Note that this was the reason for changing the 802.3ct framing scheme (avoid frequent frame losses). You can see the details in trowbridge_3ct_01_200528.pdf.

Best regards,

Leon

From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: יום ב 29 יוני 2020 21:18
To: STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx
Subject: [802.3_DWDM] Implications of SIGNAL_DETECT = FAIL

One of the key issues I believe that we as a group are going to need to resolve to move 802.3ct forward is the definition of when to set SIGNAL_DETECT to FAIL.

As a part of that discussion, it would help me to better understand what happens when SIGNAL_DETECT is set to FAIL. My assumption is that a device would use that to determine that there was not a valid signal and therefore could not operate. However, I’m also aware enough to know that I’m making an assumption which may or may not be correct. Therefore, it would help me greatly if some of those that know 802.3 better than I could help me understand the implications to the system for setting SIGNAL_DETECT to FAIL, particularly when there is in fact a valid signal present.

Thanks for any help.

Matt

To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1

To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1

Virus-free. www.avg.com

To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1

To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1