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

Re: [HSSG] 10 x 4 = 40



Hugh,

I have reviewed your proposal regarding 40G = 4 X 10G and think there
may be a disconnect between 40GBase-SR and 4 X 10GBase-SR. The HSSG is
considering defining 100GBase-SR (and thus 40GBase-SR) to span only 100
meters instead of 300 meters defined in 10GBase-SR.  Each lane of 100G
and 40G does not need to be defined with the difficult 300 meter
requirements of the 10GBase-SR standard.  If each 10G lane of the 100G
or 40G PMDs would only be required to span 100 meters, the cost of the
HSSG solution would be lower cost per channel than 10GBase-SR.

The supported distance of each 10G lane is important because it has
large cost implications. I would like to quote a Finisar proposal
regarding the manufacturability of 10GBase-SR transceivers that can
found here: http://www.t11.org/ftp/t11/pub/fc/pi-4/06-036v0.pdf 

On slide 5, the Finisar presentation states: 

Practical 10G VCSELs to date have been small aperture MM devices.
- Yield VERY poorly even to largest allowed spectral width - This is
largest single cost driver for 10GBASE-SR

Then on slide, 6, Finisar and Advanced Optical Components - the largest
VCSEL manufacturer in the world states: 

Practical TX design almost impossible. Requires high ER and expensive
yielding and testing


Finisar showed the difficulties of manufacturing 10GBase-SR transmitters
(5 years after standardization) because of the 300 meter requirement
over OM3 fiber.  This presentation was pivotal in defining 8 Gigabit
Fibre Channel (8GFC) in a low cost manner that only spans 150 meters at
8.5 Gbps.  If the 300 meter requirement is placed on 100G Ethernet and
thus on 40G Ethernet, then the cost of 40G and 100G will be tremendous
and will see low adoption.

Therefore, the 4 X 10GBase-SR = 40G argument is not necessarily true and
will depend on how the HSSG defines each 10G lane.  

If the HSSG defines 10G lanes to only 100 meters, then the PMDs may not
require clock and data recovery (CDR) chips in the transceiver like
those used in the XFP transceiver.  The QSFP transceiver that supports
four lanes of 10G does not use a CDR and is expected to be significantly
lower cost than 4 XFPs.  In other words, 4 XFPs do not equate to 1 QSFP.
The cost of a QSFP may equate to 4 SFP+s. Likewise, a low cost QSFP may
be made that is compliant to 40GBase-SR, but not compliant to 4 X
10GBase-SR.   

One of the goals of 40G is not to have a 'perception of being "low-end"'
but to actually be low end in cost.  If history repeats itself, cost
will be a determining factor in adoption of 100G and 40G. 

An interesting example of high speed links, can be seen in
telecommunications. OC-768 systems that run at 40G serial are state of
the art right now and should be for the foreseeable future.   OC-192 is
seeing very low volumes and this could be a problem with 100GE if there
is a "early adopter premium".  OC-768 is not economical now at 6x or 7x
the costs of 10G according to an  article titled "What's holding up
40G?" (
http://lw.pennnet.com/display_article/279721/13/ARTCL/none/none/What%E2%
80%99s-holding-up-40G.)  An interesting aspect of this article states:

"What's attractive about 10-GigE isn't necessarily the technology. It's
that once a chip is manufactured, it gets shipped in volumes of
millions, not in volumes of a few thousand."

With less than a million ports of 10GE ever shipped worldwide, this
statement is false and 10GBase-SR's lofty distance requirements is one
of the reasons why.  The HSSG should look into examples of high data
rate connections (especially 10G) to get 100GE and 40GE right.

Regards,
Scott Kipp
QSFP Chair and Editor
Office of the CTO, Brocade 

-----Original Message-----
From: Hugh Barrass [mailto:hbarrass@CISCO.COM] 
Sent: Friday, April 13, 2007 3:53 PM
To: STDS-802-3-HSSG@listserv.ieee.org
Subject: [HSSG] 10 x 4 = 40

All,

There's been some discussion (!) around the existence of an MSA for a
40G module format. The module is actually based on 4 x 10G channels,
this leaves system implementors 2 choices:

1. Simply define the MSA to use LAG . The MAC & PCS are already defined
for 10GBASE-R, the PMD definitions are already available for SR, LR &
LRM. This could be incorporated into systems being developed
immediately, exploiting existing MAC and fabric silicon. From a
standards perspective, I would classify this as another 10G format (no
fundamental difference to X2, XFP or SFP+).

Additionally, a breakout device could allow compatibility with discrete
10G systems (using SFP+, XFP, X2 etc.) and also would allow the use of a
40G socket to connect to multiple 10G destinations (redundant
connections, multipath routing etc.).

2. Try to push through a new definition in 802.3 for 40G MAC and PCS. 
This would almost certainly be tied to the same schedule as the 100G MAC
& PCS definition, it might be available to start development in 3-4
years. It would require new MAC/fabric silicon, that would have to start
development after the standard is in its last stages of development.

A socket using the single 40G approach could not be connected to a
breakout for legacy compatibility.

Notes:

If #1 happens (almost impossible to "prevent" it) then confusion will
ensue as option #1 & option #2 products mix in the market. It will be
very difficult to distinguish or differentiate between the two. I don't
know how those who commit to the "proper" approach of #2 will be able to
recoup their extra development costs compared to those who get a 3-4
year headstart by implementing #1. Additionally, option #2 based
products will hit the market at the same time as 100G products become
available. They will start with the perception of being "low-end" and
will not be able to command the "early adopter premium" that is often
relied on to recover leading edge development costs.

Frankly, looking at this, I would not recommend to my employer that we
should spend time (and money) to develop the silicon to support option
#2 vs option #1. Of course, others may feel free to spend their
development differently. Additionally, if I was a component vendor, I
know which option I would pursue.

With regards,

Hugh.