| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Steve, I am planning a presentation for the Geneva meeting regarding the framing/loss-of-frame process, I understand that a lot of details are not evident from my comments and my email. I will try to address also all
the issues you indicated. I hope that once the details of both options are clear we will be able to make a decision. Regarding the new state diagram drawing that may be required if we decide to split the lane identification process, although I recognize the “joy” involved, I am ready to assist in any way I can. Best regards, Leon From: Trowbridge, Steve (Nokia - US) [mailto:steve.trowbridge@xxxxxxxxx]
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>
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:
A.
OOF-> IF requires matching any 4/5 FAS bytes
B.
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:
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 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 |