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