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

Re: [802.3_DWDM] On SC-Frame alignment

Hi Eric,

 

Thanks for your inputs. I am going to present the probabilities for sync and sync loss using both schemes.

 

I agree with you that the sync time will be longer using the proposed scheme compared to the D1.1 scheme, but according to my calculation the average additional time will be low and will not affect operation.

The advantage is a simpler process that is in line with the ITU processes.

 

Best regards,

Leon

 

From: Eric Maniloff [mailto:eric.maniloff.ieee@xxxxxxxxx]
Sent: שבת 11 ינואר 2020 00:09
To: Leon Bruckman <leon.bruckman@xxxxxxxxxx>
Cc: STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DWDM] On SC-Frame alignment

 

 

Hi Leon,

 

Thanks for bringing this forward, I agree we should look at it to make sure we're aligning with ITU where possible and using optimal approaches. I went through a bit of math on this today, it seemed like a useful Friday afternoon project. 

 

I am a bit confused why you recommend using a fixed subset of frames for the OOF->IF framing. G.798 does, as you note, use an unspecified 4 byte subset. But, I was curious what the probabilities looked like 

 

I ran calculations assuming pre FEC BER values of 5e-3 and 1e-2. Using these values I calculated the probability of achieving frame lock (OOF-> IF) in either the first two or three FAS’s to arrive after the process begins for two cases:

 

  1. OOF-> IF requires matching any 4/5 FAS bytes
  2. OOF-> IF requires matching a specific set of 4 FAS bytes

 

For case A:

 

Probability of framing after the first two FAS’s I calculated 97%  & 90% for 5E-3 & 1E-2 pre FEC BER. Probability of framing after 3 FAS’s: 99.9% amd 99% for the same BERs.

 

For case B:

 

Probability of framing after the first two FAS’s I calculated 73% & 53% for 5E-3 & 1E-2 pre FEC BER. Probability of framing after 3 FAS’s: 92% and 77% for the same BERs.

 

I didn’t look at the OOF-> IF transition yet, but maybe before Geneva.

 

On your point regarding separating the Frame alignment from Lane alignment, I’m in agreement with separating the processes.

 

Regards,  Eric

 

On Mon, Dec 23, 2019 at 3:51 AM Leon Bruckman <leon.bruckman@xxxxxxxxxx> wrote:

Dear experts,

The alignment/alignment loss processes defined in 802.3ct D1.1 for 100GBASE-ZR are different from the ones usually defined by ITU-T G.798 for similar signals. As far as I understand, the processes defined are:

-          Alignment:

o   Search for four octets that match four of the first five octets of the alignment (FAS) pattern + verify that the 6th octet value is <240.

o   Count the bits to the next framing position candidate and verify again that four octets match four of the first five octets of the alignment (FAS) pattern and that the 6th octet value is the same as in the previous frame. If yes, then alignment is achieved.

-          Alignment loss:

o   If for 5 consecutive frames there are more than four octets out of the first five octets of the FAS that do not match the pattern, OR the 6th octet value is not equal to the one detected during the alignment process, then alignment is lost.

Some observations regarding the draft text:

-          The four octets that match the FAS are not necessarily adjacent

-          The octets that match the FAS may be different each consecutive frame.

-          The alignment and lane identification processes are linked together.

In ITU-T G.798 the alignment/alignment loss processes for the OTU4-SC_A_Sk signal (the one our SC-FEC frame is based on) is for further study, but for other similar signals the definition is:

-          Alignment:

o   In the OOF state (loss of alignment), the framing pattern searched for shall be a 4-byte subset of the FAS bytes. The IF state shall be entered if this subset is found and confirmed one frame period later.

-          Alignment loss:

o   In the IF state (aligned), the frame signal shall be continuously checked with the presumed frame start position for correct alignment. The framing pattern checked for shall be the OA1OA2OA2 pattern (bytes 3, 4 and 5 of the FAS). The OOF state (loss of alignment) shall be entered if this subset is not found at the correct position in five consecutive frames.

-          Lane marker (identification) process:

o   A new value of the logical lane marker is accepted when in five consecutive 16320‑byte periods the same value is present in bits 7 and 8 of the MFAS byte (their equivalent to our lane identification), and the recovery process will enter the in-recovery (IR) state.

o   In the IR state, recovery will be lost and the out-of-recovery (OOR) state will be entered, when in each of five consecutive 16320-byte periods a value is received that is not the same as the accepted logical lane marker value

Some observations regarding the G.798 text:

-          The four octets that match the FAS are not necessarily adjacent

-          The same subset is verified every frame

-          The alignment and lane identification processes are separate.

I am aware that pre-FEC BER in the 100GBASE-ZR signal is very high, but I did some math and the results indicate that the G.798 processes will also perform well enough for 100GBASE-ZR. Assuming this assumption is right (I am still working on the results, but I hope to be able to present them in the interim. Note that in any case alignment will be lost and regained frequently without impairing the reception) then I would recommend to adopt similar processes as the ones defined in G.798 for 100GBASE-ZR:

-          The 4 octets subset shall be fixed (for example: 2nd, 3rd, 4th and 5th FAS octets) and the same subset shall be verified

-          Separate the alignment process from the lane identification process.

The advantage will be that developers will be able to reuse the same functions/hardware they developed for other OTN similar signals.

Leon

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