Re: [802.3_50G] CAUI-4 operating modes

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Thanks,

Ali Ghiasi

Ghiasi Quantum LLC

On Feb 25, 2016, at 6:59 AM, Mark Nowell (mnowell) <mnowell@xxxxxxxxx> wrote:

Thanks Ali,

I guess my main point is that if the new additional proposed AUIs result in there being a different data pattern or signal on the physical media (different FEC, different PCS architecture, or different bit rate) then it isn’t as simple as just adding that additional AUI in isolation.

Your example of XSBI is consistent with this. We can add new AUIs in isolation as much as we want either in IEEE or in MSAs. We saw 10GBASE-R running over XSBI (16 lanes), XAUI (4 lanes), XFI (1 lane) and SFI (1 lane). But in all those cases the PCS was unchanged and the bits on the physical media where unchanged for a particular PHY through all those different AUIsso we had guaranteed interop, regardless of implementation. You can still connect a 10GE port using SFP modules and SFI AUI to a 10GE port using a 300 pin module and XSBI today (if you can find one).

Since we seem to love trawling back through the spec to see how we did things in the past, I’d suggest looking at 10GE where we defined the XSBI. We had a backwards compatibility goal there with OC192 and handled that with the definition of the WIS layer (Cl 50). If you look at the 10GE introduction section table (Table 44-1) you can see where the WIS was included it was associated with unique PHYs (10GBASE-W) since the bits on the wire were different and wouldn’t interoperate with the other 10GBASE-R PHYs.

Please be very clear, I’m not saying what you are proposing can’t be done. I’m just pointing out that from an IEEE perspective where our goal is to develop interoperable specs it is not as simple as just adding in an optional AUI in isolation and we therefore need to work through what needs to be done so the SG understands what is actually being asked of it.

Mark

On 2/24/16, 11:28 PM, "Ali Ghiasi" <aghiasi@xxxxxxxxx> wrote:

Mark

Thank you detail replay, please see my comments below inline, hopefully the inline will get through this time!

Thanks,

Ali Ghiasi

<Logo3b.png>

On Feb 24, 2016, at 7:02 PM, Mark Nowell (mnowell) <mnowell@xxxxxxxxx> wrote:

All,

Since I started this burst of activity with my questions on the ad hoc call today, let me re-iterate the point I was making. This is purely coming from my chair’s perspective and looking at what the SG needs to close out in terms of objectives and making sure we all understand the implications and consequences of what we adopt so we don’t get wrapped into knots in Task Force.

The proposal from Ali today was to support an objective for an optional 50GAUI-2 and an optional 100GAUI-4.

My question was whether that was sufficient to achieve what is intended. I think 50GE and 100GE cases are slightly different, so I’ll tackle them separately.

A general comment first

To try and clarify the confusion that is happening around CAUI-4 modes, let me try another way. We only have one mode of CAUI-4 defined (by 802.3bm), and we have a FECs defined RS(528) and RS(544) (by 802.3bj). Because the RS(528) FEC runs at the same bit rate as CAUI-4 and because CAUI-4 was defined to run @ a BER that doesn’t require FEC, we can run the RS(528) FEC over CAUI-4 without consequence and have the advantage of the FEC gain being able to be used completely for the optical PMD link. Key point here is that we’re not running the CAUi-4 at different bit rates.

50GE

As Ali says we do not want to sacrifice performance on the single lane specifications which I’m guessing will be based on an end to end RS(544) FEC that covers both the AUI and the PMD and this family of PHYs will be defined by the TF in line with the objectives set (which for the PHYs with AUIs are 100m MMF, 2km SMF and 10km SMF).

If an optional 50GAUI-2 is defined, I’m assuming that the interest is to use a RS(528) FEC and therefore this is a new family of PHYs since they won’t interoperate with the above family of PHYs from a bits on the wire perspective. Further assumptions as to different PCSes reinforce this non-interoperable conclusion. Since, I believe the assumption is that the PMD is still a single lane PMD, it’s tx/rx specs will either be different from the single lane PHY to achieve the same reaches as above or the reaches will be different to use the same tx/rx as above.

As you stated CAUI-4 can operate without needing FEC protection but end to end FEC is enabled for 100GBase-SR4 operation. If 50 GbE PMD operates with RS(528,514) then there is no speed up. In case we need RS(544,514) for 50 GbE PMDs the PMA-PMA system interface can operate naked just as the case of CAUI-4 the PMA-PMA adds the RS(544,514) form bit/symbol mux.

The “simple” addition of an option 50GAUI-2 to the 50GAUI-1 is more complex as they will be running at different bit rates, different modulation formats and different BERs.

There are already products in the market place as shown in SSCC2016 paper below with CAUI-4/50GAUI-2 to 2x50G/1x50G, the input bit rate is different than output bit rate and the device initiates FEC.

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

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.

For what it is worth, I think we can achieve all of the intended goals that Ali and Rob Stone are trying to achieve without causing any of these specification challenges just by selecting the other options in their slides. The bottom option on Ali’s slide 7 and 8 http://www.ieee802.org/3/50G/public/adhoc/archive/ghiasi_022416_50GE_NGOATH_adhoc.pdf and Rob’s “Brown Field Option B” on Slide 5 of http://www.ieee802.org/3/50G/public/adhoc/archive/stone_021716_50GE_NGOATH_adhoc-v2.pdf. These all support the legacy hosts, do not require the creation of a new family of PHYs and PMDs in the industry (or the IEEE specification), and are essentially already architecturally supported.

Mark

On 2/24/16, 6:04 PM, "Jeffery Maki" <jmaki@xxxxxxxxxxx> wrote:

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

From: Rob Stone [mailto:rob.stone@xxxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 2:53 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes

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

From: Jeffery Maki [mailto:jmaki@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 2:41 PM
To: STDS-802-3-50G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_50G] CAUI-4 operating modes

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

From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Sent: Wednesday, February 24, 2016 1:47 PM
To: 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

<Logo3b.png>