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.
----------------------------------------------------------------------