Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Dear Frank,
If I understand what Glen is suggesting, the PCS would not make data but only modify it in the Data Detector FIFO queue. I am not an expert on IEEE layering philosophy but I think that PCS can perform data modification as far as it is not required to spawn/remove frames before passing anything to MAC.
Regarding whether it is an acceptable scheme or not - let's wait and see what others think during the conference call ..
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: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
Sent: quarta-feira, 13 de Dezembro de 2006 9:49
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
All,
If everybody thinks it is ok for the data detector to generate the special patterns, then that is fine by me. It is much more direct. I introduced the concept of the leader frame because I thought people would get upset about the PCS making up data... if not, then great.
[It is funny - back in the EPON days, I proposed a similar scheme. It got shot down. Now, it seems to be in fashion. Go figure.]
However, keep in mind that the data detector needs to align the FEC coding layer, as well as send the special codes.
I disagree with the concept of doing two-step alignment in the upstream. While that is great for the downstream, it is pointless in the upstream. The delimiter gives us alignment to the FEC codeword, which is by definition aligned to the 66 blocks. Why would we need to do it twice?
Regards,
Frank E.
By the way, do we have a conference call number, yet????
----- Original Message -----
From: Glen Kramer <glen.kramer@TEKNOVUS.COM>
Date: Wednesday, December 13, 2006 4:21 pm
Subject: 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
> burstsynchronization 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 [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 [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 [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 [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 [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 [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 [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 [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
>