[HSSG] Proposal for traget bit rate
One of the questions before the HSSG is to determine what data rate (or data rates) should be the basis for the next Ethernet standard. While the formation of the HSSG was motivated by a desire for 100Gb Ethernet, the question whether this is the right data rate is still properly under consideration. That is why the Study Group is called High Speed. The candidate data rates before the group are 40Gb, 80Gb, 100Gb, 120Gb, 160Gb, and others may be proposed. Hopefully, the Group will make this question one of the first to be investigated and resolved.
In parallel, it has been very useful to use 100Gb as a candidate data rate for investigating issues associated with the physical layer and system design. For example, the recent rich discussion on the reflector about BER or differential latency would have been superficial if the various example calculations were done with "High Speed" instead of 100Gb/s.
In this spirit, I propose that for the purpos of investigating physical layer technologies (optical components, fiber propagation, signal integrity, IC speeds, etc.) we agree on a target definition for the maximum raw bit rate required to achieve a 100Gb data rate. Different bit rates have been used in discussions during the past year, including 100Gb/s, 103Gb/s, 110Gb/s, 111Gb/s, and there may have been others. This leads to some imprecision in the discussion, and potentially optimistic assumptions about what is possible.
All of the bit rates used have multiplied an existing 10Gb Ethernet bit rate (or bit rate approximation) by a factor of 10. However, it is likely that 100Gb coding will be different then for 10Gb, and probably higher. Therefore, for the purpose of investigating physical layer limits I propose we use a conservative target bit rate of 120Gb/s. This is not a proposal for a specific coding overhead or actual bit rate, simply a target to enable uniform discussion and evaluation of various technologies. It is unlikely that we will end up with a coding overhead as high as 20%, but we may come close. It is prudent to not artificially limit one of our greater degrees of freedom (coding gain.)
Let me offer the following simplified link budget example to motivate how important we will find coding gain. One of the 100Gb approaches proposed by individuals from many companies has been a five channel CWDM system using five un-cooled DMLs, for 10km 1310nm applications. It has been described as 5 x 20Gb/s or 5 x 22Gb/s (I would describe it as 5 x 24Gb/s.) A simple extension of the 10GBASE SMF 10km link budget model to 20Gb suggests an 8 dB path penalty versus about a 2dB path penalty at 10Gb. In addition, we have to account for optical mux and optical demux losses, which are 2dB to 3dB each, and penalty due to crosstalk in the receiver, which could be 1dB to 2dB. That adds up to 11dB to 14dB of extra penalty versus the 10Gb link. While there are simple ways of dealing with some of these penalty terms like turning up the DML optical output power, (and the path penalty term is artificial,) we will find as very valuable methods that can gain us back each dB. For multi-chann!
el systems, coding gain may even prove useful as a simply mechanism to transfer DC power from the optics to CMOS logic performing coding on the line card.
A target bit rate is useful in evaluating channel alternatives. For example, to demonstrate feasibility of a four channel system, it is risky to show that a 25Gb/s diode exists or that 25Gb/s is possible through a connector. At this very early stage of considering alternatives, a four channel system proposal should be able to show operation at 30Gb/s, even if two or three years from now we decide that the actual bit rate is 4 x 28.5Gb/s. Given a 120Gb/s target bit rate, the following are the resulting channel alternatives.
We could define multiple target bit rates for different wavelength and distance applications, and use a lower overhead for 10 channel applications (back to 11Gb/s.)
However for a single simple set of targets the above should serve us well for a period of time. It also doesn't hurt that these are round numbers, and don't require us to carry around decimal points at this early stage of the discussion.