Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Thomas and everybody,
The "PCS" overhead (which is the 64b66b overhead) can be taken together with
the FEC. To do so, we can see that the two header bits in each 66b block
contain 1 bit of PCS framing information, and 1 bit of Ethernet framing
information. The first can be taken back, as long as the FEC code method
gives us alignment. The second bit can not be taken back so easily, because
it carries the information of when Ethernet frames start and stop. So, we
can compress the 66b blocks to 65b blocks.
So, it seems straightforward to reduce the PCS overhead from 1/32nd to
1/64th, keeping in mind, however, that the FEC overhead will then need to
rise from the pure ~7% value to something slightly worse. The 'slightly
worse' depends on how much redundant information content we want to have.
More redundancy equals faster and more reliable framing lock, and vice
versa.
To focus this discussion on the various proposals on the table for FEC
framing, the Mandin variants are examples of the 65b compression, with
differing amounts of 'slightly worse'. The Effenberger/Kramer framing
proposal considers leaving the 66b code alone, but therefore not requiring
the FEC to add any additional framing bits.
In my opinion, there is a style linkage between the super/sub rating
question, and the framing question. To put it simply:
Sub-rating would suggest the Effenberger/Kramer approach.
Super-rating would suggest the Mandin approach.
My reasoning it as follows: If we are sub-rating, the whole reason for
doing so is to keep the PHY rate 10.3125. This rate exists because of
64b66b coding. Using a non-64b66b code at the 10.3125 rate is a misfit (not
impossible, just awkward.) And, if you believe in sub-rating, then you must
agree that a 1.5% bandwidth tax is a small price to pay for compatibility,
since you already have cut the MAC rate by ~10% to achieve re-use of 10.3125
optics.
In the reverse, if we are super-rating, we are pushing the optics with every
fraction of increasing bit rate. So, we need to be concerned with every
scrap of bit rate, and we would want to recover that 1.5%. Also, if we are
abandoning the 10.3125 Gb/s rate, then there is nothing sacred about the
64b66b code. So, super-rating and 65b block compression goes together.
The reason for drawing attention to this style linkage is that it eliminates
2 of the 4 possible combinations of the two choices we have. And, I think
that will help our decision-making process.
Sincerely,
Frank E.
-----Original Message-----
From: Thomas Schrans [mailto:TSchrans@OCP-INC.COM]
Sent: Thursday, February 08, 2007 12:41 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
I'm neither a FEC expert nor a PCS expert, so I have what may look like
a simple question:
Why can we not combine the PCS overhead (64B/66B =3%) and FEC overhead
(~7%), so that the combined overhead is less than the sum of the two.
Regards,
Thomas Schrans, Ph.D.
Design Engineering Manager
Optical Communication Products, Inc.
-----Original Message-----
From: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
Sent: Wednesday, February 07, 2007 11:35 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
The actual rate is the repeating fraction. But, it is not a problem to
have a rate that is not expressible in a short fraction. However, a
round number has a 'prettiness factor.'
What is important that the rates have a reasonably simple ratio.
Frank E.
----- Original Message -----
From: glen kramer <glen.kramer@TEKNOVUS.COM>
Date: Tuesday, February 6, 2007 5:16 pm
Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> Frank,
>
> > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
> 10.3125.
>
> I calculate that 15/14ths of 10.3125 is equal
> 11.049107142857142857142857142857...
>
> Is this a problem? Should super-rating employ additional rate
> adaptationmechanism to make it a "nice" number?
>
> For example, inserting one extra block every 1875 blocks will
> bring the
> rate up to 11.055.
>
>
> Glen
>
>
>
>
> > -----Original Message-----
> > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
> > Sent: Tuesday, February 06, 2007 1:41 AM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> >
> > Frank,
> >
> > I think you might be conflating the loop timing issue with some
> other> issue raised earlier.
> >
> > The point I intended to raise about loop timing is that the upstream
> > frequency of 1.25 GHz is fixed already, and in the asymmetric 10/1
> case
> > the ONU needs to derive the upstream clock from the downstream
> signal.Of
> > course how easy or difficult it is to do that depends both on the
> > dividability of the downstream frequency by 1.25 Ghz and also
> on the
> > jitter of the downstream signal.
> >
> > 11.25 Ghz (rather than 11.049 GHz) would be fine. Can XFI/SPI
> components
> > go that fast?
> >
> > - Jeff
> >
> > -----Original Message-----
> > From: Frank Effenberger [feffenberger@HUAWEI.COM]
> > Sent: Monday, February 05, 2007 6:02 PM
> > To: STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> >
> > All,
> >
> > I don't think that clock management is so strong an advantage
> for one
> > scheme over the other. In all the cases, in all the technologies,
> there
> > are a set of frequencies that are phase-locked to each other.
> Dividers
> > and PLLs do a fine job of inter-converting them. One is not much
> harder
> > than the other, unless we choose a poor frequency for the
> super-rating.
> > We should be more careful!
> >
> > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
> 10.3125.
> > Those are reasonably small clock dividers, and not a big problem to
> > implement. Note that this division builds on top of the 33/32nds
> clock
> > ratio of 64b66b. If we go with super-rating, then I see no
> reason to
> > maintain the redundant framing bit. Rather, I think we would
> look for
> a
> > clock relationship from the FEC super-rate directly to the 10G base
> rate.
> >
> > In any case, I will add the item to the list, for completeness sake.
> >
> > Regards,
> > Frank E.
> >
> >
> >
> >
> > -----Original Message-----
> > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
> > Sent: Monday, February 05, 2007 9:19 AM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> >
> > Frank hi,
> >
> > Loop-timing for the asymmetric 10/1 case would appear to be another
> "pro"
> > for the subrating scheme.
> >
> > The ONU can - perhaps - use the recovered 10.3125 clock to
> derive one
> of
> > 312.5 Mhz (divide by 33), and then use a PLL to generate the
> upstreamrate
> > (multiply by 4). With 11.1 Gb/s XSBI this would probably be
> much more
> > difficult.
> >
> > - Jeff
> >
> > -----Original Message-----
> > From: Frank Effenberger [feffenberger@HUAWEI.COM]
> > Sent: Wednesday, January 31, 2007 10:32 PM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: [8023-10GEPON] [FEC Superating] - kickoff preso
> >
> > Dear All,
> >
> > I have put together the following presentation on the issue of
> FEC and
> > line-rate vs. MAC-rate modification. I tried to include in these
> slides
> > all the arguments I have heard favoring one method or the other.
> If I
> > have forgotten your favorite, you can shoot an Email to me, and I'll
> add
> > it to the list.
> >
> > You may also note that the last slide, entitled "Reaching a
> decision"is
> > blank. I don't know a truly objective way to solve this
> problem... It
> > seems to me that when you stack up the pros and cons, these two
> schemes
> > are pretty equal.
> >
> > One last thought: The one 'hard' (objective) con for the super-
> rating> scheme is the loss of 0.3 dB of sensitivity. The one
> 'hard' con for
> the
> > sub-rating scheme is the loss of bandwidth (7% lost). How can
> we put
> > these two items
> > on a common comparative base? Usually, the common denominator in
> these
> > situations is cost, so...
> > What is the relative system cost increase due to 0.3dB optical loss?
> > What is the relative system cost increase due to a 7% capacity loss?
> > If someone wants to hazard an answer to these questions, please do.
> >
> > Regards,
> > Frank E.
>