RE: Issues concerning 10GbE speed standards
- To: "'nuss@xxxxxxxxxx'" <nuss@xxxxxxxxxx>, BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx
- Subject: RE: Issues concerning 10GbE speed standards
- From: Drew Perkins <drew.perkins@xxxxxxxxxxxx>
- Date: Mon, 28 Jun 1999 13:10:57 -0700
- Cc: Drew Perkins <drew.perkins@xxxxxxxxxxxx>, pbottorf@xxxxxxxxxxxxxxxxxx, Peter_Wang@xxxxxxxx, rabynum@xxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
You're probably both right depending on your time frame. If 2.5 G and 10 G
follow normal historical cost reduction curves, 2.5 G will probably be less
expensive for a while until 10 G catches up and surpasses it. The question
is when will that happen relative to completion of the standard.
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: Martin Nuss [mailto:nuss@xxxxxxxxxx]
Sent: Monday, June 28, 1999 12:43 PM
To: BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx
Cc: nuss@xxxxxxxxxx; drew.perkins@xxxxxxxxxxxx;
pbottorf@xxxxxxxxxxxxxxxxxx; Peter_Wang@xxxxxxxx; rabynum@xxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: Re: Issues concerning 10GbE speed standards
Brian:
I don't think my claim is outrageous, otherwise I would not have made
it. I don't want to position one solution versus the other, I just
wanted to make sure that we are getting a balanced view.
Here is why I believe that 10G serial is ultimaltely the lowest cost
solution:
1) most of our lasers (e.g., FP or uncooled DFB) that you can buy spec'd
at 2.5 Gb/s actually work at 10 Gb/s directly modulated with minor
packaging modifications.
2) 10 Gigabit electronics is becoming a lot cheaper. We are seeing 10
Gb/s electronics in SiGe, BiCMOS, and straight CMOS coming out, with
cost erosion curves that are highly encouraging.
I believe that your point was that you currently have to pay thousands
of dollars for a 10Gb/s line card. But these line cards are telecom
grade, and are still using the older and more costly optics and
electronics.
You are actually using the same argument for WWDM. If you buy WWDM
combiners and splitters today from commercial vendors like E-TEK or JDS,
you also have to pay thousands of dollars. But lower-cost packaging and
datacom mentality hopefully will bring these costs down to where we need
them to be.
Martin
BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
> Martin,
>
> Your claim that "... a serial 10-Gig solution is definitely going to
> be the cheapest one by the time 10G Ethernet sales seriously take
off"
> is absolutely outrageous, and has no place on this reflector.
Perhaps,
> relative to other solutions that Lucent has been able to develop,
this is
> true, but there have been several other proposals (including the HP
WWDM,
> Blaze WWDM, Transcendata MAS) that could very well be cheaper than
serial
> 10-Gig for MANY YEARS TO COME.
>
> Your argument in favor of scrambling is valid, but it also has to be
> balanced against the disadvantage of designing electronics that
support
> very low frequencies. AC balanced electronics (both TX and RX) with
> relatively high low frequency cutoffs tend to have less jitter and
result
> in higher sensitivity. In the regime that we are working on (i.e.
our
> low-cost 4 channel WWDM module) the trade-off between 2.5-Gbaud
scrambled
> and 3.125-Gbaud 8B/10B is a close call. There are pros and cons to
both
> sides. Certainly both are well within the realm of low-cost
electronic
> processes.
>
> -Brian Lemoff
> HP Labs
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Re: Issues concerning 10GbE speed standards
> Author: Non-HP-nuss (nuss@xxxxxxxxxx) at HP-PaloAlto,mimegw2
> Date: 6/28/99 8:20 AM
>
> All,
>
> I think we are making a mistake by talking about scrambling in the WAN
> and 8B/10B in the LAN. There are a lot of good reasons why we need to
> look at scrambling in the LAN as well:
>
> 1) a serial 10-Gig solution is definitely going to be the cheapest one
> by the time 10G Ethernet sales seriously take off. That is true in the
> LAN as well. You do not want to exclude an option that promises to be
> the cheapest one!
>
> 2) there is no significant cost advantage in 8B/10B coding over
> scrambling from an optics and electronics point of view
>
> 3) there is however a cost penalty going to higher speed optics and
> electronics. 10 Gb/s can be achieved rather readily for both optics and
> electronics, but a 25% overhead likely makes things more expensive
>
> 4) the lower line rate (10.00 vs. 12.5 Gb/s) directly translates into
> longer distances supported, more power budget, and less penalties (such
> as DMD).
>
> Martin Nuss
>
> Drew Perkins wrote:
> >
> > Paul,
> > You hit on another very good reason for the WAN version to use
> > scrambled encoding. Let me rephrase it for emphasis. I believe it is a
> > requirement that 10 Gb/s Ethernet be able to ride over existing DWDM
spans.
> > These spans have already been engineered for 10 Gb/s channels.
Increasing
> > the bit rate would increase the optical bandwidth, and would require
> > increasing the optical power as well. Thus an 8B/10B 12.5 Gb/s signal
would
> > not be able to ride on most existing spans, but would instead require
> > completely new spans to be engineered. This will not be acceptable to
many
> > carriers. Therefore, using scrambling is clearly a hard requirement for
10
> > Gb/s Ethernet over DWDM systems.
> >
> > This is, of course, not a factor in the decision whether to use 8B/10B
or
> > scrambling in the LAN.
> >
> > 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 Paul
> > Bottorff
> > Sent: Saturday, June 26, 1999 9:20 AM
> > To: Drew Perkins; 'Peter_Wang@xxxxxxxx'; 'rabynum@xxxxxxxxxxx'
> > Cc: 'stds-802-3-hssg@xxxxxxxx'
> > Subject: RE: Issues concerning 10GbE speed standards
> >
> > Drew:
> >
> > The data I've seen agrees exactly with your outlook that the total
system
> > cost is considerably higher using 12.5 Gig rather than 10 Gig. In
addition,
> > the installed base of transmission systems, which has many available
> > lambda, is definitely 10 Gig. The 12.5 Gig solutions can only be used in
> > for new installations.
> >
> > Our current research indicates that the scrambled encoders do not
increase
> > the cost of components versus 8b/10b when used for the same application.
> > Infact, we believe scramblers are less costly than 8b/10b due to the
lower
> > frequencies. The current analysis of 8b/10b considers the effects of
jitter
> > compared to the worst case conditions for scrambled coding. This
analysis
> > does not give an accurate picture of the requirements for scrambled
> > encoding since the probability of the imbalance used in the comparison
is
> > once in more than 10,000 years. Scramblers are statically DC balanced,
it
> > is necessary to look at the requirements statistically rather than in
the
> > worst case.
> >
> > Paul
> >
> > At 10:21 PM 6/25/99 -0700, Drew Perkins wrote:
> > >
> > >Peter and Roy,
> > > The cost of higher speed in the WAN is not so much that of the
> > >electronic parts, but rather the fact that you need more of them for
long
> > >distances. This is because most optical effects such as dispersion
increase
> > >with the square of the distance. Thus increasing the speed by 25%
increases
> > >the optical effects by 56%, and that tends to decrease the distance you
can
> > >go by about a third. Then you need 33% more spans to go the same
distance.
> > >Also, in order to send 25% more bits, you wind up increasing the power
by
> > >25%, and you use more optical bandwidth. And since you are sending more
> > >bits, you are using more optical bandwidth. These facts result in fewer
> > >optical channels being supportable on a fiber, resulting in more fibers
> > >being used, resulting in more line systems, etc. The result again is
more
> > >equipment and higher costs.
> > >
> > >Actually, the electronic parts might become less expensive with the 25%
> > >extra speed. The balanced nature of the 8B10B code decreases the cost
and
> > >attention that must be paid to jitter.
> > >
> > >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
> > >Peter_Wang@xxxxxxxx
> > >Sent: Friday, June 25, 1999 8:35 PM
> > >To: rabynum@xxxxxxxxxxx
> > >Cc: stds-802-3-hssg@xxxxxxxx
> > >Subject: Re: Issues concerning 10GbE speed standards
> > >
> > >
> > >
> > >
> > >
> > >Roy,
> > >
> > >>From a number of the component vendors' presentations at CFI, I don't
> > recall
> > >anyone claiming that the cost of the electronic parts (SiGe or GaAs)
will
> > be
> > >much different between 10 & 12.5 Gbps. The primary cost issue seemed
that
> > >of
> > >the relative laser performance (e.g. temperature stablization). Also,
if
> > >you
> > >are talking about "converting" an existing Sonet chip to silicon
(meaning
> > >that
> > >the existing desing is in GaAs) and throwing away a bunch of circuits,
I
> > >wouldn't be so sure that the development cost would be much less. In
any
> > >case,
> > >assuming the volume is large (which I'm sure everyone's hoping), the
> > >development
> > >cost will be amortized, and hence not a significant factor. But this
is a
> > >discussion for LAN (or enterprise) applications. I was trying to
> > understand
> > >the
> > >economics of applying Ethernet to WAN but forcing it within the
existing
> > WAN
> > >practice, and hoping you could provide some insight.
> > >
> > >Peter
> > >
> > >
> > >
> > >
> > >Roy Bynum <rabynum@xxxxxxxxxxx> on 06/25/99 04:50:23 PM
> > >
> > >Please respond to rabynum@xxxxxxxxxxx
> > >
> > >Sent by: Roy Bynum <rabynum@xxxxxxxxxxx>
> > >
> > >
> > >To: Peter Wang/HQ/3Com
> > >cc: stds-802-3-hssg@xxxxxxxx
> > >Subject: Re: Issues concerning 10GbE speed standards
> > >
> > >
> > >
> > >
> > >
> > >Peter,
> > >
> > >Just because a SONET OC192C framing is used, does not mean that the
OAMP
> > >functionality is active in the LAN interface. If OAMP processing is
not
> > >needed, only the existing SONET chip set, converted to silicon, with
> > >most active functionality, other than path BER can be disabled. This
> > >will leverage the existing technology without the higher cost of the
> > >APS, line and section overhead, etc.
> > >
> > >Having worked on devices before, I know that the higher the bit signal
> > >rate the more expensive the devices. With a PHY that is 1/4 higher in
> > >bit rate, compared the 8B/10B signal rate, the OC192 rate may be less
> > >expensive.
> > >
> > >Roy
> > >
> > >
> > >
> > >Peter_Wang@xxxxxxxx wrote:
> > >>
> > >> It will help a great deal if you could point out specific aspects and
> > >approaches
> > >> where an Ethernet extended to support all of the existing common
carrier
> > >O&M
> > >> requirements, encapsulated within the existing Sonet/SDH structure,
> > >running
> > >over
> > >> existing OC192/STM64 facilities, will actually come out costing
> > >significantly
> > >> less that the current solution?
> > >> - Peter
> > >>
> > >> Roy Bynum <rabynum@xxxxxxxxxxx> on 06/20/99 07:34:08 AM
> > >>
> > >> Please respond to rabynum@xxxxxxxxxxx
> > >>
> > >> Sent by: Roy Bynum <rabynum@xxxxxxxxxxx>
> > >>
> > >> To: wthirion@xxxxxxxxxx
> > >> cc: stds-802-3-hssg@xxxxxxxx, stds-802-3-hssg-speed@xxxxxxxx (Peter
> > >> Wang/HQ/3Com)
> > >> Subject: Issues concerning 10GbE speed standards
> > >>
> > >> Walt, et al,
> > >>
> > >> The issue of speed is one of economics. The existing GbE standard
does
> > >> not allow for any operations support for the optical fiber facility.
> > >> This makes GbE very expensive to maintain and support over a MAN/WAN
> > >> environment. The cost of ownership of GbE will prevent it from
having a
> > >> masive impact directly on the cost of MAN and WAN data
communications.
> > >>
> > >> Common carrier protocols, such as DS1/DS3/SONET/SDH have operations
and
> > >> maintencance functionality incorporated in the overhead of the
> > >> protocol. DS1 and DS3 have a subcarrier that provides remote and
> > >> reverse signalling outside of the transport "payload". This allows
> > >> carriers to troubleshoot and maintain remote systems without haveing
to
> > >> dispatch someone for every little issue. In some respects, GbE fails
to
> > >> meet the 802.3 functional requirements for interoperation with common
> > >> carrier systems.
> > >>
> > >> 1000BaseSX and 1000BaseLX are optical networking standards. Whether
> > >> this was the intention or even the perception of the 802.3 working
> > >> group. The working group did not include any support for operations
or
> > >> maintenance in the optical domain for this protocol. The functional
> > >> operations of copper LAN facilities are well understood by the 802.3
> > >> working group, but when you get beyond multi-mode, 850nm, optical
> > >> transport, it is no longer a LAN, it is a WAN. Some will say that
30km
> > >> is a MAN, not a WAN. If you apply the same function processes
> > >> distictions to optical systems that are applied to copper systems,
you
> > >> will discover that a MAN is actually a WAN within a single central
> > >> office domain. When I was actively working on Ethernet, when it left
the
> > >> building, it was no longer a LAN, it was a WAN.
> > >>
> > >> In order for 10000BaseX to support MAN/WAN systems within common
carrier
> > >> facilities, common carrier operations and maintance support must be
> > >> within the protocol. SONET/SDH are the current, and most widely
> > >> deployed transport protocols within the common carrier domain.
> > >> SONET/SDH use the transport overhead to provide that functionality.
> > >> That functionality allows the common carriers to reduce the
operations
> > >> and support costs for the fiber optic transport systems, and thus
lower
> > >> the overall costs passed on to the end users. This will be the
economic
> > >> breaking point for 10GbE. Can it directly support the fiber optic
> > >> transmission system? Is there any reason why it should not be able
to
> > >> directly provide operations support for the optical fiber systems?
> > >>
> > >> A second economic issue of speed for 10GbE is one of utilizing
existing
> > >> technology and standards at the ~10Gigabit speed range. A masive
> > >> install base of facilities and support already exist for OC192/STM64
on
> > >> a global scale. Optical amplifers, signal and clock recovery
> > >> regenerators, and other systems are already in place to carry
> > >> OC192/STM64 signals in metropolitan as well as wide are networks. I
> > >> would not want to contemplate the economic impact of having to
install
> > >> totally seperate technology to support 10GbE. If it can not use the
> > >> existing ~10Gb technology and facilities, Other than "dark fiber",
10GbE
> > >> will have to be installed over a totaly new, and totaly seperate
> > >> facilities. Is there any reason why 10GbE should not support and
make
> > >> use of the existing ~10Gb transport facilities?
> > >>
> > >> I hope that this message has not been too long. As an employee of a
> > >> common carrier company, I have a recognizable vested interest in
looking
> > >> toward 10GbE as a major economical alternative to existing data
tranport
> > >> technolgy, such as TDM or ATM. I have almost 20 years of designing,
> > >> installing, and supporting LAN, MAN, and WAN systems. I have seen
the
> > >> economics change as more self-supporting protocols and technologies
have
> > >> become available. The key is to provide a protocol that allows
remote
> > >> operations support, which reduces the number of "warm bodies" that
are
> > >> required to support the systems. This is what I am asking for. Is
> > >> there any reason why this can not be done?
> > >>
> > >> Thank you,
> > >> Roy Bynum
> > >> MCI WorldCom
> > >
> > >
> > >
> > >
> > >
> > >
> > Paul A. Bottorff, Director Switching Architecture
> > Bay Architecture Laboratory
> > Nortel Networks, Inc.
> > 4401 Great America Parkway
> > Santa Clara, CA 95052-8185
> > Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
> > email: pbottorf@xxxxxxxxxxxxxxxxxx