Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Answered below.
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
Sent: Monday, December 11, 2006 9:13 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Frank,
Thanks for this initial work. I like the general approach. Some questions:
1. What is intended by the statement that the signal on the fiber
would include "IDLE blocks" at the start of a burst (slide 8)? Does this
mean FEC codewords that consist entirely of 66b blocks which (in turn)
consist solely of IDLEs??
>"Idle blocks" would be just 66b blocks containing all idle bytes. I tried
to always use "block" to mean 66b units, and 'codeword' to mean FEC units
(data+parity). I may have made mistakes, of course.
2. Would the leader frame be a new MPCP type? Is it the case that the
leader frame won't actually be passed to the receiving MAC?
>I suppose it could be a new type of MPCP type. It certainly needs some
special 'marking' so that if it somehow got onto a network, it would be
discarded as not a real frame. It is true that the leader frame gets eaten
by the receiving unit's PCS layer, so it doesn't arrive at the MAC. (I
suppose the receiving PCS could re-generate the leader, since it is always
the same content... I don't know if that is worth much of anything.
3. The transmitting PCS apparently performs special handling for the
leader frame. Is it correct to say that the payload of the leader frame is
"tailor-made" for the PCS framing/coding scheme and for the requirements of
the PMD?
>Absolutely. The leader frame's sole purpose in life is to make the PCS
(and the PMA's and PMD's) life easier. Both the transmitting and receiving
PCS treat the leader specially, in that they both synchronize their block
and codeword clocks to the correlating pattern. Once that sync is done, the
Tx and Rx go back to their 'ordinary' mode.
Best Regards,
- Jeff Mandin
-----Original Message-----
From: Jeff Mandin
Sent: Monday, December 11, 2006 3:43 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
All,
1. I made minor changes to Frank Effenberger's ppt. (attached) ... slides
now have numbers on them, and I moved the downstream synchronization slides
to an appendix for later consideration (as it was primarily upstream issues
that led to the adhoc). Some technical comments from me will follow
shortly.
2. Telecon:
Can people attend a telecon this coming Wednesday/Thursday (Dec 13/14) at
1500 PST (2300 GMT, 0800 JST)?
3. Updated Adhoc participants list:
- Ryan Hirth
- Frank Effenberger
- Frank Chang
- Marek Hajduczenia
- Keiji Tanaka
- Piers Dawe
- Fumio Daido
- Glen Kramer
- Shoichiro Seno
Regards,
- Jeff Mandin
-----Original Message-----
From: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
Sent: Tuesday, December 05, 2006 12:04 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing adhoc
Dear All,
Please find attached my draft contribution regarding delineation of FEC
encoded 10G EPON signals. This considers both the continuous downstream and
the burst upstream. I thought this way of discussing things was more
logical, since we needed to know what the speed of locking of the continuous
method was before we considered the burst mode problem.
Anyway, there it is.
On the issue of a conference call, I, too happen to be traveling in Asia
(there is a conference in Hong Kong that many are attending). So, next week
would be good for me as well.
Sincerely,
Frank Effenberger