Jeff,
I am aware of your point that some users may require better-than-standard BER. This applies to applications with and w/o FEC.
We used to have discussions putting stricter BER target on no-FEC link (compared to links with FEC) to achieve safe MTTFPA, because MTTFPA failure mechanism for
links w/ FEC and w/o FEC are a little different. So what my last email means is – for the standard, if BER with FEC is defined at 1e-12, no-FEC BER does not have to be defined at 1e-15 JUST FOR MTTFPA. Silicon vendors are free to provide better-than-standard
PMDs for links both with and w/o FEC.
Thanks,
Phil
From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 4:13 PM
To: Phil Sun <phil.sun@xxxxxxxxxxxxx>; STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_50G] CAUI-4 operating modes
Phil,
What do you believe is a MARKET acceptable BER when operating an Ethernet interface at 50 Gb/s?
·
Routing market
·
TOR switch / server market
Jeff
From: Phil Sun [mailto:phil.sun@xxxxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 3:52 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Chris/Gary,
I agree that most 50G PAM4 optical links today need FEC to cover its error floor – either KP4, KR4, or another lower-latency FEC, e.g.
RS(272,257), with similar coding gain.
For low-latency cable link we discussed, there is no optical link. So if LAUI-1 can achieve 1e-12, no FEC will be needed for the whole link with active cables.
A very low latency (~50ns) FEC could also be used to if we prefer to relax PMD parameters.
BTW,
For no-FEC links, we do not have to achieve 1e-15 for MTTFPA. MTTFPA for 66B/64B encoding can be achieved by multiple ways – either 1e-15 BER, or 1e-12 BER with
limited error propagation.
Thanks,
Phil
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 2:57 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Gary,
Your summary is accurate, including pointing out that the differences between LAUI and xAUI-2 with KR4 and KP4 FEC modes are more complex than the differences
between CAUI-4 with no FEC and with FEC modes.
LAUI-2 with no FEC is not an option because of error floors in optical 50G PAM4 links. We have seen some demonstrations of electrical 50G PAM4 links operating
error free with no FEC, but that cannot be extrapolated to optical links. The proposal is to have LAUI-2 with KR4 FEC for backwards interoperability with existing MSA defined interface. We would also bring in this interface definition into the IEEE. We can
handle it the same way as we handle KR4 FEC for CAUI-4, leave all the FEC gain for the optical link.
If the latency of KR4 FEC is excessive, as brought up by Brad and Phil, we would need to define a new, lower latency FEC for use with 50G PAM4 optical links to
deal with the error floor.
Chris
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 2:42 PM
To: Chris Cole; STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Chris,
I presume you were joking about the chipmunks !
So can you clarify what you are proposing then ?
For LAUI and CAUI-2, it is probably not practical to run with no FEC anyway, so in both cases the AUI will have to steal some FEC gain from the end-to-end FEC in use. I can update
my diagrams to reflect this. For LAUI-2 is is still not clear to me if you are thinking of stealing some of the RS-528 FEC gain for the LAUI-2 itself, or whether you would rather use all the FEC gain for the PMD (as we did for CAUI-4) ?
In any case what you are proposing still results in two different specifications for LAUI, LAUI-2 and CAUI-2 for the two different FEC modes, because the bit rate and the BER requirements
will be different between the two FEC operating modes. This is very different to the case of CAUI4, where the CAUI-4 specification did not change (same bit rate and 1e-15 BER) between the two operating modes (no FEC and RS-528). This is the point that I was
trying to make in my original email.
It also results in two different 50G PCS blocks being required in the ASIC (at the end of the day this may not be a big deal, but I am pointing it out in the interest of full disclosure),
and also two different 50G PCS Clauses to be defined in the standard (and one Clause with no supported PHYs, and therefore no entrees in the equivalent of Table 80-2).
I want to make it clear that I am not necessarily against with your proposal. At this point I am just trying to ensure I fully understand it and all of the associated implications,
both in terms of hardware implementations and IEEE standards.
Gary
From:
Chris Cole <chris.cole@xxxxxxxxxxx>
Date: Wednesday, February 24, 2016 at 5:09 PM
To: Gary Nicholl <gnicholl@xxxxxxxxx>, "STDS-802-3-50G@xxxxxxxxxxxxxxxxx"
<STDS-802-3-50G@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_50G] CAUI-4 operating modes
Gary
I had not proposed adding a no FEC mode to LAUI, LAUI-2 or CAUI-2. That was proposed by Brad and others for low latency applications.
My proposal is that LAUI, LAUI-2, and CAUI-2 have two FEC operating modes: KR4 RS-528 and KP4 RS-544.
Chris
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 1:59 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
I am sending this again because I am not sure the reflector was working the first time.
Gary
From: Gary Nicholl <gnicholl@xxxxxxxxx>
Date: Wednesday, February 24, 2016 at 4:36 PM
To: Jeffery Maki <jmaki@xxxxxxxxxxx>, "STDS-802-3-50G@xxxxxxxxxxxxxxxxx"
<STDS-802-3-50G@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_50G] CAUI-4 operating modes
I was getting confused so I started to draw out what I think Chris wants. Please see attached.
For now I have only focused on 50G.
I have also assumed that FEC, if required, would be included in a single PCS Clause (like we did for 400G).
Rocks welcomed :)
Gary
From:
Chris Cole <chris.cole@xxxxxxxxxxx>
Reply-To: Chris Cole <chris.cole@xxxxxxxxxxx>
Date: Wednesday, February 24, 2016 at 4:46 PM
To: "STDS-802-3-50G@xxxxxxxxxxxxxxxxx" <STDS-802-3-50G@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_50G] CAUI-4 operating modes
Mike,
The optics we would use with LAUI-2 with KR4 RS-528 FEC would be the same optics as those we would use with LAUI-2 with KP4 RS-544 FEC, except running at 3% lower
rate. The SG will have to decide which we define in the project, and which outside of the project, if any.
Chris
From: Mike Dudek [mailto:mike.dudek@xxxxxxxxxx]
Sent: Wednesday, February 24, 2016 12:05 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
But what PMD is LAUI-2 going to support. If we don’t have an objective for a PMD that requires it then in my opinion it would be out of scope to develop it
without an explicit objective.
Mike Dudek
QLogic Corporation
Director Signal Integrity
26650 Aliso Viejo Parkway
Aliso Viejo CA 92656
949 389 6269 - office.
From: Kapil Shrikhande [mailto:kapils@xxxxxxxx]
Sent: Wednesday, February 24, 2016 11:32 AM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
To match the capabilities of CAUI-4 (4x25G), the LAUI-2 (2x25G) C2M interface should operate without FEC at a BER of 1e-15 or better (Gary also points to the BER requirement for CAUI-4), so that a no-FEC PHY using
LAUI-2 could operate at 1e-12. And as stated by Chris, LAUI-2 will also support RS-FEC encoded signal (KR4 and KP4 FEC) for those PMDs that require FEC.
Kapil.
On Wed, Feb 24, 2016 at 10:53 AM, Brad Booth <bbooth@xxxxxxxx> wrote:
I like this topic as it does highlight one of the aspects previously mentioned in January about the need to have a low or zero FEC latency AUI.
For the 25G-based interface (CAUI-4), the task force(s) wisely provided the ability for the interface to operate with and without FEC. This has permitted flexibility in implementations. For example, the ability to use a CAUI-4 without FEC between an Ethernet adapter's ASIC and FPGA will permit a low latency interface; whereas, between the adapter's FPGA and the switch's ASIC, FEC can be used to provide end-to-end error correction.
It would be great if we continue to provide interfaces like CAUI-4 that can transport either FEC or non-FEC data. This would provide the greatest level of flexibility for various implementations that could occur.
I've requested time to make a presentation in Macau to discuss these use cases in both the 50G and 100G market.
Thanks,
Brad
On Wed, Feb 24, 2016 at 10:31 AM, John D'Ambrosia <jdambrosia@xxxxxxxxx> wrote:
Chris,
You are mistaken.
The FS FEC was developed and a 4 lane solution was developed but it was not CAUI-4. That was done in 802.3bm. There is no way I would ever try to steal that credit away from Dan Dove who had the fortitude of a saint with that effort.
I think the confusion is coming from FEC and non-FEC protected interfaces.
From what I see
802.3bj RS-FEC clause developed to support the cr4, -kr4, -kp4
802.3bm developed CAUI-4 and specified its operation to 10^-15 without FEC. However the architecture itself can be done in such a way that the CAUI-4 is carrying either non-FEC or FEC protected data. 802.3bm also developed -sr4 where FEC is mandatory.
So the AUI based on 25Gb/s signaling can be independent of whether there is FEC or not.
I think everyone is right, but it clearly points out we have to be very specific with language.
John
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 1:24 PM
To: John D'Ambrosia <jdambrosia@xxxxxxxxx>; STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_50G] CAUI-4 operating modes
CAUI-4 with KR4 RS-528 FEC was developed in the P802.3bj project you led to first support CR4. P802.3bm then defined SR4 with CAUI-4 with KR4 FEC. This enable subsequent efforts to quickly define optical PMDs that use KR4 FEC. P802.3bm also defined CAUI-4 with no FEC to support existing PMDs; LR4 and ER4.
So coming out of 802.3bm we had two CAUI-4 operating modes, one without FEC for backwards compatibility, and one with FEC for new PMDs.
Chris
From: John D'Ambrosia [mailto:jdambrosia@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 10:04 AM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Reading the spec – it looks more like the specification of CAUI-4 is done not assuming FEC, but a port type may include FEC that could go over the CAUI-4.
From: Rick Rabinovich [mailto:rrabinovich@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 12:20 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Correct, CAUI-4 does not include FEC.
Rick Rabinovich
Hardware Architect – Signal Integrity
Phone: +1 (818) 208-7328
26601 W. Agoura Rd.
Calabasas, CA 91302 US
visit: www.ixiacom.com
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 9:18 AM
To: Rick Rabinovich <rrabinovich@xxxxxxxxxxx>
Cc: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: CAUI-4 operating modes
Perhaps, but 802.3bj did not define CAUI-4 and Chris’s comment was specifically on CAUI-4.
Gary
From: Rick Rabinovich <rrabinovich@xxxxxxxxxxx>
Date: Wednesday, February 24, 2016 at 12:15 PM
To: Gary Nicholl <gnicholl@xxxxxxxxx>
Cc: "STDS-802-3-50G@xxxxxxxxxxxxxxxxx" <STDS-802-3-50G@xxxxxxxxxxxxxxxxx>
Subject: RE: CAUI-4 operating modes
Hi Gary,
Thank you for bringing this up . CAUI-4 defined in IEEE802.3bm was specified without FEC to eliminate the latency incurred.
Perhaps Chris was also referring to 4x25G as defined in IEEE802.3bj which includes RS-FEC for 100GBASE-CR4.
Cordially,
Rick Rabinovich
Hardware Architect – Signal Integrity
Phone: +1 (818) 208-7328
26601 W. Agoura Rd.
Calabasas, CA 91302 US
visit: www.ixiacom.com
From: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 9:08 AM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: [802.3_50G] CAUI-4 operating modes
Following on from the discussion this morning I checked 802.3bm and there is only a single operating mode for CAUI-4.
CAUI-4 C2M is defined in Annex 83E. There is only one operating mode and that assumes no FEC.
There is no separate FEC operating mode, where some of the FEC gain is used to relax the CAUI-4 electrical specifications.
In 802.3bm if RS-FEC is being used, it is carried completely transparently over the CAUI-4 interface, and all of the FEC gain is used for the PMD (i.e. 100GBASE-SR4). The CAUI-4 specification is completely independent of whether FEC is being used on the link or not. Perhaps this is what Chris meant by “two CAUI-4 operating modes” on the call this morning, even though from a CAUI-4 perspective there is only a single operating mode?
Another way to state this is that the FEC requirements for the host are defined by the PMDs to be supported and not the CAUI.
Gary
