Re: Why wrong LINE rate could cost dear
- To: "Perkins, Drew" <drew.perkins@xxxxxxxxxxxx>
- Subject: Re: Why wrong LINE rate could cost dear
- From: Roy Bynum <rabynum@xxxxxxxxxxx>
- Date: Tue, 29 Jun 1999 07:54:44 -0500
- CC: "'stds-802-3-hssg-speed@xxxxxxxx'" <stds-802-3-hssg-speed@xxxxxxxx>, "'stds-802-3-hssg@xxxxxxxx'" <stds-802-3-hssg@xxxxxxxx>
- Organization: .
- References: <2072E1221F1DD211848C00104B938E7B733591@xxxxxxxxxxxx>
- Reply-To: rabynum@xxxxxxxxxxx
- Sender: owner-stds-802-3-hssg-speed@xxxxxxxxxxxxxxxxxx
I have received documentation sheets on 10Gb transmitter and receiver chips
using bipolar silicon technology. These chips are expected to be seen in
commercially available OC192 transmission interfaces sometime this year. The G2
technology is already here.
"Perkins, Drew" wrote:
> It seems to me that we're drawing to a conclusion something like the
> Semiconductor technology is continuing to follow Moore's Law. That suggests
> that the next generation of silicon will support something in the
> neighborhood of 2.5 - 3.125 Gb/s since the current generation supports 1.25
> Gb/s. Some day, however, another generation (maybe the next) will support
> something in the neighborhood of 10 Gb/s. This may be using SiGe instead of
> Si. So, we should plan for two or more generations to occur: 2.5 - 3.125
> (G1) and 10 Gb/s (G2). Of course GaAs supports 10 Gb/s today, but is seen as
> being more expensive than Si or SiGe. So we probably want to specify a
> serial version of 10 Gb/s immediately as well, but we should expect that we
> may have to revise it when G2 becomes available.
> G1: For Generation 1, we will want to use a non-serial protocol
> implementation that leverages G1 silicon. This may be WWDM/CWDM/etc. and/or
> MAS. We may also need to do this because of fiber impairments that don't
> allow 10 Gb/s serial anyway. For G1, we may want to specify multiple
> standards, just like Gigabit Ethernet did. We may want equivalents of SX and
> LX. In fact, perhaps these two standards were well enough matched to market
> demands that we should copy the requirements and try to meet them. Also,
> these standards may have not set a good set of expectations that the market
> will force us to meet. I would propose that we take these two as baseline
> goals. I.e. let's use the same fiber types and lengths as our goals and try
> to work with them. This probably implies that we want an SX-like solution
> that uses 850 nm VCSELs, and an LX-like solution that uses 1310 nm FP
> G2: For Generation 2, we will want to use a serial protocol implementation
> that leverages G2 semiconductors on fiber that supports it. In fact, we
> probably want to specify and standardize a 10 Gb/s solution immediately as
> well for use with GaAs technology.
> Ciena Corporation Email: ddp@xxxxxxxxxxxx
> Core Switching Division Tel: 408-865-6202
> 10201 Bubb Road Fax: 408-865-6291
> Cupertino, CA 95014 Cell/Pager: 408-829-8298
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Sent: Monday, June 28, 1999 5:46 PM
> To: piers_dawe@xxxxxx; stds-802-3-hssg-speed@xxxxxxxx;
> Subject: Re: Why wrong LINE rate could cost dear
> In a message dated 6/28/99 2:41:48 PM Eastern Daylight Time,
> piers_dawe@xxxxxx writes:
> > Why wrong LINE rate could cost dear
> > 1. Cost JUMPS as bit rate goes up.
> > Faster IC technologies, more heat, possibly substantial extra complexity
> > around the optoelectronics.
> > Lasers don't follow Moore's Law.
> > Unlike transistors, there is no virtuous circle of smaller -> faster and
> > cheaper -> better. The guts of a laser are sized for the wavelength.
> > Laser speed has increased slowly and unevenly, but until now, they were
> > fast enough (for 2.5 Gbit/s line rate). Optical modulator type
> > transmitters as used in OC-192 are very expensive.
> > Picking a line rate that's faster than the state of the art will delay
> > product availability and cause extra costs into the future (25% to 150%
> > more? make your own guess).
> > 2. Standards are good.
> > Line clock ICs take time and money to design. Other parts
> > (multiplexers, receivers, whatever) may be in the market now for ~9.95
> > Gbit/s, a very few at OC-192+FEC rates, none for 12.5 Gbit/s. Analog
> > parts are rarely right first time, respins add to the delays...
> > Picking a non-standard line rate could cause delay and further fragment
> > the market for parts which we believe are currently too expensive but
> > where volumes are driving costs down.
> > So, I believe that raising the line rate of optical transmitters
> > four-fold is a worthwhile achievement, and then we attach ourselves to
> > the nearest standard, the OC-192 line rate of 9.95328 Gbit/s. Raising
> > the line rate of optical transmitters five-fold, out ahead of the state
> > of a slow-moving art and away from any standard, will cost money and
> > delay and needs very good justification. There's an obvious direct hit
> > on link length too (dispersion limited) but what I'm talking about is
> > more severe than that.
> > Can we get back the difference between what's desired and what's
> > affordable by looking at line codes, interframe gap or what? Maybe
> > settle for 95% of what we would like and get a good-enough job done on
> > time and affordably?
> > "Keep it simple, follow standards, keep it cheap."
> > Piers Dawe
> > --
> To all:
> I heartily agree with Piers' recommendation!
> As a receiver manufacturer looking for better 10g amplifier solutions,
> it becomes clear very quickly that good IC's for anything above 10g
> are simply not readily available, while 10g components are receiving
> considerable attention from several suppliers, and are in fact providing
> acceptable sensitivity performance at both 850 and 1310nm.
> Although the needs for FEC will be addressed by speciality products,
> this certainly will not be the main stream, and also will not reach the cost
> structure necessary for a viable product on the anticipated timeline.
> The most elegant, cost-effective, and especially, timely solution will
> exploit those components that are already being developed for related
> applications (OC-192).
> Common sense is a good thing.
> Janis Valdmanis
> Picometrix Inc.
> (734) 998-4502