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