All of this CAN be considered by the SG/TF BUT just adopting only an objective to support an optional 50GAUI-2 doesn’t really seem to provide any insight into what the TF needs to do. It also doesn’t enable the TF to develop a more than one solution for an objective (e.g. 100m MMF). Unless there are PHYs that this proposed 50GAUI-2 is associated with – it is not clear to me that we have a way of including this 50GAUI-2 in the specification alone but need more consideration on how to do it.
We have had presendance defining optional interfaces and not defining PMD for the optional AUI. XSBI (16 lane) which was the interface on the 300 pin MSA had no 16 lanes PMD associated. The largest application for 10 lanes 100 GbE was CAUI-10, even though we end up defining 10 lanes SR and CU.
100GE
I originally thought 100GE was different but the discussion above actually carries across almost the same. The difference we have is that with 100GE we only have one objective adopted that need an AUI right now – 2-fiber 100m MMF.
My assumption again is that there is interest in this objective being met with a baseline based on end-to-end RS(544) FEC.
I agree likely RS(544,514) but we need to perform the diligence during the study group.
As I understand the optional AUI proposal, the goal would be to have the 100GAUI-2 end of the link to run the existing PCS/RS(528)FEC (defined in 802.3ba and 802.3bj) in order to interoperate with a host at the other end that is using the CAUI-4 (and supporting RS(528)). Again the consequence of this is that this is a different PHY as it is running at a different bit rate. There are potentially two different 100GAUI-2 interfaces here running at different bit rates with different FEC gain coverage. This will also obviously impact the PMD specification too so either reach or PMD specs will need to change.
If RS(544,514) FEC required for operation of new 100 GbE PMD in that case the CAUI-4 interface will operate naked then FEC will be initiated in the PMA-PMA (4:2) device. We know CAUI-4 can operate with BER 1E-15 so we can simplify the problem and assume RS(544,514) FEC is available for the 50G/lane PMD, in effect you can view CAUI-4 to CAUI-2 as logical interface. A logical PCS implementation will support 4/2 lanes so the question is wouldn’t be better that the AUI is defined in the IEEE instead of an MSA?
Below is ISSCC2106 paper showing an implementation with 4:2 PMA mux with different input output rate and FEC initiation.
3.4 A 40/50/100Gb/s PAM-4 Ethernet Transceiver in 28nm CMOS
K. Gopalakrishnan1, A. Ren1, A. Tan1, A. Farhood1, A. Tiruvur1, B. Helal1, C-F. Loi2,
C. Jiang1, H. Cirit1, I. Quek2, J. Riani1, J. Gorecki1, J. Wu1, J. Pernillo1, L. Tse1,
M. Le3, M. Ranjbar1, P-S. Wong1, P. Khandelwal1, R. Narayanan1, R. Mohanavelu1,
S. Herlekar1, S. Bhoja1, V. Shvydun1
1Inphi, Santa Clara, CA; 2Inphi, Singapore, Singapore; 3Inphi, Irvine, CA
Again, anything CAN be defined as long as we know what we are defining. I believe that it is insufficient to suggest that an objective to define an optional AUI is enough. It is a good in providing clarity on the intention of what people want to specify though.
In summary, if these proposals are to be brought into the SG for adoption, I would hope we have some better clarity on how it would fit into the specification we would write (as that is our only goal within IEEE). I’d suggest looking at Table 80-2, as Gary pointed out, and figuring out how this table would be updated with these proposals.
Thank you for suggestion and I will take look at the Table 80-2 to further refine the proposal.
I do recognize that it is hard to separate the implementations issues in the products we are all looking to build from the IEEE specifications that we are trying to write, but as chair, I need to remind the group on the IEEE specification aspects.
Mark
Rob, My “strictly speaking” was meant at a head nod to what you say. I was trying to narrow subject when trying to understand Chris. Confusion is occurring from the use of the terms KR4 and KP4, and what all is meant in the context of 50G connects. Below, I have a typo. “…LAUI-2 could be devised to need to coding gain…” should be “…LAUI-2 could be devised to need no coding gain…”. Jeff Hi Jeff You are correct that there is no IEEE 50G Ethernet, but there is a 50G Ethernet standard out there based on 2 x 25G lanes (25G Consortium) – and it has been put into hosts supplied by several companies. This data was shared in the Atlanta meeting, it can be seen in the Dell Oro forecast on slide 3, (http://www.ieee802.org/3/50G/public/Jan16/stone_50GE_NGOATH_02a_0116.pdf). Thanks Rob Chris and others, I am a bit confused. Strictly speaking, no host has 50G Ethernet today so when one is built to have 50G Ethernet it can also be built to have any required FEC. Are you mentioning KR4 and KP4 just to give a flavor of the difference in these two potential codes to be adopted? In this way, when mentioning KR4, you mean LAUI-2 could be devised to need to coding gain itself just as CAUI-4 does not need any coding gain to operate. Jeff 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 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. 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. 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. 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 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
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. Correct, CAUI-4 does not include FEC. Rick Rabinovich Hardware Architect – Signal Integrity 26601 W. Agoura Rd. Calabasas, CA 91302 US Perhaps, but 802.3bj did not define CAUI-4 and Chris’s comment was specifically on CAUI-4. 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 26601 W. Agoura Rd. Calabasas, CA 91302 US 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.
|
