Re: [8023-10GEPON] [FEC] Start-of-frame alignment
Hi Jeff,
I never argued with the fact that the "no alignment" scheme adds 4 extra
bytes to a burst and that ONU must have a coding overhead awareness.
But here are some additional points to consider:
1) In existing 1G EPON, the reporting function has the physical coding
overhead awareness, as it calculates the FEC overhead to determine the
queue length values for REPORT messages. (See Clause 63.3.6.2 "The
reported length shall be adjusted to account for the necessary
inter-frame spacing and FEC parity data overhead, if FEC is enabled.")
2) In 10G EPON the reporting function must as well be aware of the
physical coding overhead, no matter whether we align the first
start-of-packet or not. This is so because, in addition to 4 extra bytes
due to /S/ misalignment, there are two additional overheads:
a) 16 bytes of leading idles (two 66-bit blocks) needed at the beginning
of a burst. These idles are not stored in the queue, but must be
accounted for when ONU decides which frames can fit under a threshold.
b) An additional overhead introduced by the deficit Idle Counter in RS.
As you indicated in your presentation, "RS adds variable overhead for
aligning /S/ to the first XGMII column. If Deficit IDLE count is
implemented, then this overhead will be between 0 and 3 bytes."
So, the question is really, whether ONU should add 23 bytes of overhead
(16+3+4) when we do no alignment, or only 19 (16+3) bytes (in case we
align the 1st /S/ character).
3) If the group decides to use the "1st alignment" scheme, alignment of
the first start-of-packet should happen above 64b/66b encoder, i.e., as
the top-most function in PCS. This alignment will probably require
several extra states in a state machine. It doesn't seem to be an overly
complicated thing, I agree. The one issue, though, is that this function
at the top of PCS now should differentiate first frame in a burst from
the all other frames, i.e., it should have a notion of bursts.
With the decision we made in Orlando to keep line rate at 10.3125 Gbps,
it does appear that we will need two new state machines in PCS:
1) At the top of PCS (above Scrambler, possibly even above the 64b/66b
encoder) we will need to remove extra IDLEs (and possibly do the
alignment).
2) Below scrambler, we need to have FEC and insert sync sequence and
burst delimiter.
I would like to hear more opinions on the topic. Having fewer states in
a state machine vs. up to 8 Mbps of additional bandwidth (this is only
0.08%) pretty much cancels each other. Are there any additional pros
and cons for doing or not doing the alignment?
Should we have a call before the Geneva meeting?
Regards,
Glen
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
> Sent: Monday, May 07, 2007 5:54 AM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] [FEC] Start-of-frame alignment
>
> Glen hi,
>
> It seems that you do in fact agree with the main points about overhead
> from the "Data detector considerations" presentation ... Ie. that "no
> alignment" means that the ONU MPCP must have coding overhead awareness
for
> REPORT, and that "Align First Frame" is trivially simple and results
in
> less overhead.
>
> As I said in Orlando, other issues that we've identified might more
> directly impact our main task (ie. incorporating our baseline framing
> scheme into the logical stack) ie.
>
> - is there a need to be concerned about the impact of
XAUI-induced
> bit errors on the data detector mechanism?
>
> - where in the logical stack are IDLEs deleted?
>
> - how can we avoid the necessity of lower layers in the stack
giving
> instructions to the higher layers (eg. What happens to scrambler
output
> during the FEC parity cycles?)
>
>
> Thanks,
>
> - Jeff
>
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@TEKNOVUS.COM]
> Sent: Sunday, May 06, 2007 7:05 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: [8023-10GEPON] [FEC] Start-of-frame alignment
>
> All,
>
> Following an action item I've taken in Orlando, here is a short report
on
> advantages and disadvantages of aligning start-of-frame characters
> (/S/) to byte 0 of the 66-bit block.
>
> I would appreciate your feedback on the slides as well as expression
of
> opinion of whether such alignment should or should not be done.
>
> Thank you,
> Glen
>
> ----------------------------------------------------------------------
> NOTE: This e-mail and the attached document express my views as an
> individual contributor to the task force, not as task force chair.
> ----------------------------------------------------------------------