Re: [8023-10GEPON] Presentation on FEC for 10G
Ben,
Your initial e-mail suggested that 10GEPON progress depends on approval of
802.3ar, and I felt compelled to clarify this.
Also, your e-mail stated that the 802.3ar may get killed in November, but
with 10GEPON votes, it has a chance to survive. To me, this is a very
disturbing thought. It is very unlikely that the 10GEPON group will settle
on FEC scheme before the November meeting. If indeed, the 802.3ar survives
only because of 10GEPON votes, it would mean that its only merit is its
**potential** utility to future 10GEPON amendment, an application not even
mentioned in 5 criteria for .ar.
I hope 802.3ar has enough merit to be kept alive on its own, without
dragging 10GEPON into this debate.
Cheers,
Glen
P.S. I re-read mine and Howard's e-mails -- I don't think either of them has
shown any strong emotions.
> -----Original Message-----
> From: Brown Benjamin-W00135 [mailto:benjamin.brown@MOTOROLA.COM]
> Sent: Monday, September 11, 2006 5:28 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
>
> Glen, Howard,
>
> Wow, I didn't think there were such strong emotions around this topic! I
> guess I've been out of the loop for too long.
>
> I agree that this issue was handled differently with 1G EPON and can
> certainly be handled in the same way. I was also not intending to impose
> any particular solution on this group. Perhaps I could have chosen my
> words better but my intention was to let folks know, that otherwise
> might not be involved in other projects within 802.3, that there was
> another project that could satisfy one of their concerns.
>
> Since you haven't yet chosen solutions to the various problems, I was
> under the impression that you might want to keep all of your options
> open and that this was one some of you might not be aware of. If 802.3ar
> does get killed, it is indeed true that this will remove one of the
> options for solving this problem.
>
> Regards,
> Ben
>
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@teknovus.com]
> Sent: Monday, September 11, 2006 3:09 PM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
>
> Hi Ben,
>
> I'd like to make two comments regarding your post:
>
> 1) I disagree with your statement that 10GEPON group should "move this
> [802.3ar] project along. Otherwise, you may not have a choice regarding
> your options to item #7"
>
> It is too early to impose any solution on how FEC will be accommodated.
> The group is looking at line super-rating, as well as data sub-rating.
> Even if we do decide to reduce data rate, using Congestion Management is
> only one option that could be available, the other potential approaches
> could be IPG stretching, CS line in the Annex 4A MAC, or using MPCP to
> slow down the data as is done in 1G EPON. In short, 802.3ar is not the
> only choice.
>
>
> 2) The issue of the 802.3ar was brought up at 802.3 opening and closing
> sessions in July, and it will be again brought up at 802.3 opening and
> closing sessions in November. The members of 802.3 working group,
> including those participating in 10GEPON will have a chance to
> familiarize themselves with the issues and express their opinions on how
> to move this project forward. The decision that will be taken on 802.3ar
> [and I am not taking any sides here] has nothing to do with 10GEPON
> activities, and the two should not be tied together.
>
>
> Regards,
> Glen
>
>
> > -----Original Message-----
> > From: Brown Benjamin-W00135 [mailto:benjamin.brown@MOTOROLA.COM]
> > Sent: Sunday, September 10, 2006 6:53 PM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
> >
> > Frank and all members of 802.3 10GEPON,
> >
> > Your item 7 below sparked my interest. There's currently a project,
> > 802.3ar, that would provide the appropriate MAC parameters to allow
> > exactly what you're looking for: slowing down the MAC to precisely the
>
> > rate you need to support whatever FEC overhead is eventually agreed
> > upon. However, as I understand it, 802.3ar is in grave danger of being
>
> > killed before it is allowed to go to working group ballot. I urge all
> > members of 10GEPON, specifically those members with voting rights in
> > 802.3, to come up to speed with the intentions of 802.3ar and show up
> > in November to move this project along. Otherwise, you may not have a
> > choice regarding your options to item #7.
> >
> > Regards,
> > Ben Brown
> >
> > -----Original Message-----
> > From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> > Sent: Sunday, September 10, 2006 10:18 PM
> > To: STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
> >
> > All,
> >
> > Here is a short summary of the call that on FEC.
> >
> > The attendees were: Ryan Hirth, Frank Chang, Roger Berrel, Jeff
> > Mandin, and Frank Effenberger. Frank Chang kindly provided the
> > conference call number.
> >
> > Frank E. prepared a short slideset to discuss some of the
> > byte/block/codeword alignment issues (see first attached preso).
> > These slides served as a sort of conversation starter...
> >
> > The main topics of discussion were:
> > 1. The topic of FEC can be broken into two parts: the FEC algorithm
> > and its effect on the optical performance, and the framing of FEC into
>
> > the 10G Ethernet signal. The slides coming into the meeting focused
> > on the framing aspects. Frank Chang offered to prepare some slides on
>
> > the algorithm/performance topic. In fact, Frank C. has done this,
> > which is the second file attachment.
> >
> > 2. It seemed agreed that FEC needs to be at the lowest layer, and that
>
> > the 64b code blocks should fit evenly into the FEC code input (in
> > other words, the FEC input should be a multiple of 66bits or 65bits).
> >
> > 3. Time quanta - there was a variety of opinions on whether the time
> > quanta should stay the same as 1G EPON (16 ns), or if it should be
> > changed to fit the new speed better. No conclusions were drawn on
> > this issue on the call, although some people on the call needed to do
> > more work on the topic.
> >
> > 4. The line rate - there was a divergence of opinions on this issue,
> > too.
> > The original slideset presented the super-rate approach, where the MAC
>
> > rate stays at 10Gb/s, and the optics are speed-up to permit space for
> > the parity.
> > On deciding this super-rate, there were a variety of values, some
> > based on numerical theory and others on practical availability of
> > serdes parts.
> > Others on the call suggested that the PHY should stay at 10.3125 Gb/s,
>
> > and the MAC should be slowed down. It was also noted that increasing
> > the data rate will also increase receiver noise, so that must be
> > balanced against the bandwidth and architectural advantages. Once
> > again, a question to be discussed more.
> >
> > 5. 66b versus 65b coding - The first presentation presents the use of
> > 66 bit versus 65 bit representation as a question. It seems that some
>
> > people like to stay with 66b code (for familiarity sake), and others
> > see the efficiency advantage of 65b representation.
> >
> > 6. Synchronization patterns - The first presentation illustrates a few
>
> > synchronization patterns that are intended for continuous synch. State
>
> > machine. It was noted that in the upstream, a special 'leader'
> > pattern would likely be needed to get FEC codeword delimitation
> > quickly, so that the state-machine could be kick-started. The length
> > and operation of these patterns was another issue that needs more
> work.
> >
> > 7. Layer-scope question - There was some disagreement on what is in or
>
> > out of scope of the current work, with some people claiming that it
> > was 'easy'
> > to change parameters of the MAC, while others claiming the opposite.
> > This certainly will be an ongoing area of contention.
> >
> > 8. Agreed path forward - the involved parties agreed that it would be
> > good to re-draft the collected materials into a sort of presentation
> > which presented each design issue as a question, and avoided making a
> > position statement on any of the issues. This was seen as helping
> > bring the whole group up to speed on the topics. Frank C. and Ryan H.
>
> > would volunteer additional materials to the effort.
> >
> > Thanks,
> > Frank Effenberger
> >
> > -----Original Message-----
> > From: Glen Kramer [mailto:glen.kramer@teknovus.com]
> > Sent: Friday, September 08, 2006 1:08 PM
> > To: 'Frank Effenberger'; STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: RE: [8023-10GEPON] Presentation on FEC for 10G
> >
> > Frank,
> >
> > Thank you for organizing the FEC discussions.
> >
> > Few people have asked me for a summary of the FEC call. Would you
> > please, post to the reflector a short overview of the call: what was
> > discussed and any steps planned next.
> >
> > Also, if you plan another conf call, please announce it on the
> > reflector, so that those who are interested, but missed the first call
>
> > could join this time.
> >
> > I also want to remind everybody that the Ethernet Alliance has offered
>
> > 10GEPON group a sponsorship in a form of hosting conference calls.
> > Please, let me know if you would like to have a conference call in
> > preparation for the September meeting.
> >
> >
> > Regards,
> > Glen