RE: Why wrong LINE rate could cost dear
- To: "'JVpico@xxxxxxx'" <JVpico@xxxxxxx>, "'piers_dawe@xxxxxx'" <piers_dawe@xxxxxx>, "'stds-802-3-hssg-speed@xxxxxxxx'" <stds-802-3-hssg-speed@xxxxxxxx>, "'stds-802-3-hssg@xxxxxxxx'" <stds-802-3-hssg@xxxxxxxx>
- Subject: RE: Why wrong LINE rate could cost dear
- From: "Perkins, Drew" <drew.perkins@xxxxxxxxxxxx>
- Date: Mon, 28 Jun 1999 21:38:27 -0700
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Oops, I was interrupted and this escaped too soon. Try again...
It seems to me that we're drawing to a conclusion something like the
following:
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 will probably use 8B/10B in
addition to 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 lasers.
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. Because G2 stretches the limits of
inexpensive semiconductor technology, it should probably use scrambling and
not 8B/10B. In fact, we may want to use the same bit rate as SONET/SDH
OC192/STM64 in order to leverage all of the same components and operate well
across the WAN.
Drew
---------------------------------------------------------
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
JVpico@xxxxxxx
Sent: Monday, June 28, 1999 5:46 PM
To: piers_dawe@xxxxxx; stds-802-3-hssg-speed@xxxxxxxx;
stds-802-3-hssg@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