Re: [802.3_DWDM] On SC-Frame alignment

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

Hi Eric & Leon,

I think it would be useful if you would plan a presentation for the Geneva meeting concerning the framing processes and how they are described.

Just from an editorial perspective, the proposed responses on several of these comments will begin as PROPOSED REJECT.

A bit of background for why things are described in the draft the way they are: we have been trying to strike a balance between facilitating reuse and possible interconnection with prior implementations, while not burdening the designer who is just building 100GBASE-ZR with having to build a full-blown OTN interface.

Regarding Frame Alignment, the original OTN process (circa 2001), based on the original SDH process, was designed for a single-lane interface looking for a fixed bit pattern (the 6-octet FAS) at regular intervals on the interface.

When multi-lane interfaces were first introduced (circa 2010), this same process was patched to apply to the multi-lane case. The base frame alignment process was kept basically the same, trimmed to look only at the 5 fixed octets, adding a secondary process to recover the lane number which only ran after the basic frame alignment was recovered.

So now in the context of 100GBASE-ZR, there are no single-lane interfaces at this position in the stack – there is only this one, particular, multi-lane interface with 20 logical lanes. Since there is never a case where you acquire frame alignment without looking for lane identification, this process is described as a single step, very much in the same way as alignment marker lock is described in other 802.3 clauses. It is a simple thing to describe, using a paradigm that the 802.3 community is familiar with.

So, does this mean that you can’t reuse your existing OTN kit that does the frame alignment in two steps? I don’t actually think so: the externally observable behavior is exactly the same with a valid input signal, and you would have to create a “contrived” test pattern that kept the frame alignment fixed pattern in place and swapped around the lane assignments while the link was in service to tell the difference (and even then, both lose and re-acquire lock when that happens, with only a small number of frames difference when it happens). So I don’t think anybody’s customer is going to shoot them for using an OTN-style of frame alignment process on a 100GBASE-ZR interface – it is just whether you want to require that someone building a new 100GBASE-ZR only interface must separate the processes in their implementation.

In terms of naked self-interest, splitting out the process means another state diagram to draw in FrameMaker, which is always a joy.

Regards,

Steve

From: Eric Maniloff <eric.maniloff.ieee@xxxxxxxxx>
Sent: Friday, January 10, 2020 3:09 PM
To: 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:

OOF-> IF requires matching any 4/5 FAS bytes
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 6^th 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 6^th 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 6^th 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: 2^nd, 3^rd, 4^th and 5^th 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