Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Dear Frank,
Thanks for the answer.
The preamble sequence (0x55) now make sense for me with this little explanation You did in the email below. What You propose therefore is to have a payload filled with 0x55 and a correlation sequence (longer than a single block possibly) inserted somewhere in the middle. I must have misinterpreted that point :P Preamble itself will have most likely to remian at 8 bits for backward compatibility issues and even though there were proposals in the past to do away with it, nobody takes that seriously. It is Ethernet after all and a preamble is part of its legacy :-) (thanks for the confirmation n the Hamming distance !)
The Barker-like sequences must be characterizes by very low cross-correlation value right ? I believe there are some longer sequences to be found ... I can try to investigate this issue.
I do not know whether we have a call - no confirmation from Jeff as for now.
One more thing - could You shed some light on the way You estimated the mean time between locking errors (the little thingy I asked about in the first email) ?
Thanks
Marek Hajduczenia (141238)
SIEMENS Networks S.A. - IC COM D1 R
Rua Irmãos Siemens, 1
Ed. 1, Piso 1
Alfragide
2720-093 Amadora
Portugal
* Marek.Hajduczenia@siemens.com
http://marekhaj.easyisp.pl/index.php
(+351.21.416.7472 4+351.21.424.2082
-----Original Message-----
From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
Sent: quarta-feira, 13 de Dezembro de 2006 1:23
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
CM first, then Burst. That's what I thought, too!
To Marek's questions on the MPCP peer-to-peer issues, the frame sizes, and
that such frames cannot get to the bridged network - Those are all
reasonable points. I'm sure, however, that we can find a editorial solution
that satisfies all the legalities in the 802.3 world.
On the issue of the preamble - Marek states that the 'preamble' should be
enough to synchronize the PHY. That isn't generally true. The Ethernet
preamble is no longer used for 'preamble' functions, and instead in EPON is
used for LLID purposes. And, in general, I think most implementers would
like to have a preamble pattern that is much longer than 8 bytes, especially
for 10G speeds.
The final reason for the preamble before the delimiter is that it provides a
fixed backdrop on which to see the delimiter. And, to answer your other
question, yes, the hamming distance is found by comparing the shifted
delimiter to the whole leader frame payload. That's the idea.
Barker sequences: There are a limited number of Barker sequences, but there
are as many 'barker-like' sequences as I want to make up. '-like' gives me
the license to create new ones.
I'm sure we can discuss more on the phone tomorrow.
Frank E.
p.s. Do we have a conference bridge?
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Tuesday, December 12, 2006 1:13 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Jeff,
I was similarly confused by the mentioning of 2-stage locking without
explanation of what it is. I think it doesn't make sense to move the
continuous locking scheme to the appendix if it also serves as an
introduction to the upstream locking scheme. I suggest the continuous scheme
is described first, even if the emphasis of the presentation is on the burst
locking.
Regards,
Glen
> -----Original Message-----
> From: Hajduczenia, Marek [mailto:marek.hajduczenia@SIEMENS.COM]
> Sent: Tuesday, December 12, 2006 9:20 AM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
>
> Jeff,
> Then I believe there should be a reference saying that the method
> description is in the appendix. Sorry for the confusion - it was not so
> clear to me.
> Best wishes
>
> Marek Hajduczenia (141238)
> SIEMENS Networks S.A. - IC COM D1 R
> Rua Irmãos Siemens, 1
> Ed. 1, Piso 1
> Alfragide
> 2720-093 Amadora
> Portugal
> * Marek.Hajduczenia@siemens.com
> http://marekhaj.easyisp.pl/index.php
> (+351.21.416.7472 4+351.21.424.2082
>
>
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@pmc-sierra.com]
> Sent: terça-feira, 12 de Dezembro de 2006 17:16
> To: Hajduczenia, Marek; STDS-802-3-10GEPON@listserv.ieee.org
> Subject: RE: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
>
> > 1. slide 5: "Proposed method of two stage locking is relatively fast" ->
> what method ? There is no reference to any method before that - was
> something removed from the presentation ? The paer that was moved to
> > the Annex should also therefore include current page 5 ... Here, we want
> only to mention that in general, the existing FEC locking methods working
> fine with continuous data stream are too slow to operate in the
> > upstream channel for 10G systems ..
>
> See the appendix. Frank supplied text on downstream algorithms to provide
> context on lock timing.
>
>
> -----Original Message-----
> From: Hajduczenia, Marek [mailto:marek.hajduczenia@SIEMENS.COM]
> Sent: Tuesday, December 12, 2006 7:08 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
>
> Dear all,
> I had some time to look through the presentation and here are my comments
> (version updated by Jeff):
> 1. slide 5: "Proposed method of two stage locking is relatively fast" ->
> what method ? There is no reference to any method before that - was
> something removed from the presentation ? The paer that was moved to
> the Annex should also therefore include current page 5 ... Here, we want
> only to mention that in general, the existing FEC locking methods working
> fine with continuous data stream are too slow to operate in the
> upstream channel for 10G systems ..
> 2. pages >=7. I agree that the "burst leader" frame would probably solve a
> lot of problems in terms of FEC alignment etc. Regarding the issues with
> its lifecycle - correct me if I am wrong, but I think that in accordance
> with the Figure 64.10 "OLT Control Parser state diagram" in 802.3, upon
> reception of a properly formed data frame with the MAC_Control_type value
> in the Length/Type field, it is never passed to the MAC client and thus
> will never reach the upper network layers, thus cannot never get into the
> network beyond the EPON structure. I am not sure what happens at the
> 802.1D compliant bridges when a MAC_Control_type frame is received on one
> of the ports. From what I know, if a bridge receives sucha frame, it
> would not be relayed onto any of the output ports since it is transmitted
> with a broadcast target MAC address, thus it would be received by the MAC
> Control layer of the bridge and dropped eventually since the Opcode is not
> know to the bridge ..
> There is one issue though - if we want to assure that such a frame
> dissapears at the PCS level, wouldn't it be a violation of the protocol
> stack ? The MAC_Control_type frames should be relayed in a transparent
> manner to the MAC control layer residing above MAC. Could You please
> clarify this point? Perhaps I am wrong ...
>
> 3. If I am not mistaken (again), introduction of new MPCP DUs would
> require revision of Annex31.A (and probably some more I am not aware of).
> Are we chartered to do that ?
> 4. page 10: I think the payload of a hypothetical "burst leader" frame
> should consist completely of an identifying sequence - the preamble should
> be sufficient for the synchronization for the OLT burst mode receiver and
> the 46 byte long payload should be rather devoted to carrying strictly
> identyfing sequence rather than 0x55 stream. Barker-like sequences are
> relatively short (the longest one has 13 characters only ->
> http://www.research.att.com/~njas/sequences/A091704) and we should have a
> look into longer sequences to assure large Hamming distance from any
> possible data patterns ...
> Additionally, the size of the MPCP DU message (MAC_Control_type frame) is
> strictly defined and the size mentioned on slide 10 is larger than the
> currently valid MPCP size limit. Is there a problem with that ? 180 blocks
> x 64 bits = 1440 bytes ?? How was the value of 180 blocks derived ?
> 5. page 12 - the chart depicts the mean time to lost burst based on the
> formula depicted on page 11 ?
> 6. noob question: on page 13, it is said that "The 64 bit block that has
> maximal distance 31 from every shift of itself and the preamble is the
> 'Golden Block'" Could You clarify that ? I would like to understand that
> in more depth ... Is it simply based on shifting a copy of the block and
> counting the 1s after the XOR operation on the two blocks ??
> 7. page 14: "For delimiter with 2X+1 distance, apply following rule ..." -
> in previous slides, the N symbol was used to indicate the block sizes and
> distances ...
>
> Thank You for Your time
> Best wishes
>
> Marek Hajduczenia (141238)
> SIEMENS Networks S.A. - IC COM D1 R
> Rua Irmãos Siemens, 1
> Ed. 1, Piso 1
> Alfragide
> 2720-093 Amadora
> Portugal
> * Marek.Hajduczenia@siemens.com
> http://marekhaj.easyisp.pl/index.php
> (+351.21.416.7472 4+351.21.424.2082
>
>
> -----Original Message-----
> From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> Sent: segunda-feira, 11 de Dezembro de 2006 15:48
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: 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