RS FEC, e.g. KP4 and KR4, can be designed to coexist without paying much hardware cost. Looking at the AM schemes in Mark and Ali’s presentations, hardware could
be shared as well.
Thanks,
Phil
From: Rob Stone [mailto:rob.stone@xxxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 11:06 AM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
I think practically speaking most if not all silicon vendors build a large amount of flexibility into their chips these days to support many different combinations
of FEC and serdes modes (even non-standard combinations). From what I have seen, this trend will only increase as we move forward to higher electrical and optical lane speeds in the interest of offering customers better flexibility to optimize for their use
cases. The challenge for IEEE isn’t implementing this logic, but in making it simply and robustly interoperable.
So I think the question for the group is in terms of objectives - what do we want, and does this meet the CSD. I would argue that rather than spend too much time
being concerned about precedent, we should focus our efforts on making sure we have good objectives. To that end, defining the “best” PCS architecture which extracts maximum value from the candidate PMDs in terms of reach etc. (most likely based on an RS-544
code and has commonality with 802.3bs) as well as something which offers easy backwards compatibility of the 50G IO technologies to what will be the large installed base of CAUI-4 ports (with RS-528) makes sense in my opinion.
Thanks
Rob
From: John D'Ambrosia [mailto:jdambrosia@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 11:01 AM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes
Chris,
I think this highlights an issue that we now need to be careful of – perhaps we need to consider some terminology
FEC protected interface – interface where FEC is needed to meet the necessary BER target
Non-FEC Protected interface – interface where FEC is not needed to meet the necessary BER Target
-SR4 is a very good case-study –
The CAUI-4 does not need to be FEC-protected, but can carry FEC-protected data. SR4, however, does require FEC protected data.
Perhaps there is better terminology, but I think this discussion resulted from our terminology and perception of what was meant.
Feedback?
So it would seem for 2x25G, we could do a non-FEC protected interface. Can we get away with a non-FEC protected interface for CAUI-2? Well, the 8x50Gb/s CDAUI-8 is FEC protected.
So it would seem that would be the real issue.
And Chris, I want to apologize for the brevity of my previous response. No disrespect meant, just going crazy with all of this stuff happening at same time.
John
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 1:54 PM
To: John D'Ambrosia <jdambrosia@xxxxxxxxx>;
STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_50G] CAUI-4 operating modes
John,
Thank you for the clarification. Yes, P802.3bj defined a 4-lane with RS-528 FEC CR4 copper cable solution. P802.3bm then defined CAUI-4.
To repeat the key take away point, we defined the CAUI-4 C2M interface with two FEC operating modes, one to support legacy PMDs (no FEC), and one to support new
PMDs (with KR4 FEC). The suggestion is that we now face an analogous situation, where we need one FEC operating mode to support legacy PMDs (those that use KR4 RS-528 FEC), and one to support new PMDs (those that will use KP4 RS-544 FEC).
And I agree with you that Dan Dove was a saint while chairing P802.3bm. He and his TF deserve a lot of the credit for what will be explosive growth of 100G in the datacenter. CAUI-4 is the foundation of that growth, and the criticism leveled at the IEEE and
P802.3bm at that time for not defining all possible SMF PMDs was unfounded and self-serving.
Chris
From: John D'Ambrosia [mailto:jdambrosia@xxxxxxxxx]
Sent: Wednesday, February 24, 2016 10:32 AM
To: Chris Cole; STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_50G] CAUI-4 operating modes
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