Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
All,
I appreciate Frank initiating the FEC synchronization discussion.
While I agree with all the issues he outlined, I want to note that burst
synchronization and FEC delineation are physical layer problems. We should
not try to solve physical layer problems using MAC or MAC control sublayers.
I don't think that using a special leader frame is a reasonable solution.
Attached is an alternative proposal. Please, review and hopefully we can
discuss this during the call as well.
Glen
> -----Original Message-----
> From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> Sent: Tuesday, December 12, 2006 5:23 PM
> 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
upstream_sync_v02.pdf