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

RE: Issues concerning 10GbE speed standards




That's the mathematical results. However customer's real results don't
always match this in real-life testing. I've spoken with a few of them, but
obviously can't say too much more on that.

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: David Martin [mailto:dwmartin@xxxxxxxxxxxxxxxxxx]
Sent: Monday, June 28, 1999 1:31 PM
To: Drew Perkins
Cc: 'stds-802-3-hssg@xxxxxxxx'
Subject: RE: Issues concerning 10GbE speed standards



Some 1% overhead, in-band SONET, FEC numbers for reference:
*	Single Error Correcting BCH-1 code, with ~ 2 dB gain, takes 1E-09
raw down to ~1E-15
*	Double Error Correcting BCH-2 code, with ~ 3 dB gain, takes 1E-09
raw down to ~1E-20
*	Triple Error Correcting BCH-3 code, with ~ 4 dB gain, takes 1E-09
raw down to ~1E-25

I've never heard any debate on this type of performance. 

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901   
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx
========================

	-----Original Message-----
	From:	Drew Perkins [SMTP:drew.perkins@xxxxxxxxxxxx]
	Sent:	Monday, June 28, 1999 3:06 PM
	To:	Martin, David [SKY:1I63-M:EXCH]; 'Fred Weniger'
	Cc:	'stds-802-3-hssg@xxxxxxxx'
	Subject:	RE: Issues concerning 10GbE speed standards

	Also note that the in-band FEC used by many SONET systems today have
	debatable performance. Many customers believe that the 2-3 dB that
these
	systems get you doesn't do much for them aside from insure good
performance
	at end of life. Many customers prefer the 5-6 dB that out-of-band
systems
	give you. This allows you to go extra difference or have more system
	margin/optical budget.

	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 David
	Martin
	Sent: Monday, June 28, 1999 10:10 AM
	To: Fred Weniger
	Cc: 'stds-802-3-hssg@xxxxxxxx'
	Subject: RE: Issues concerning 10GbE speed standards




	Note that the FEC schemes in SONET systems deployed today use
in-band
	carriage of
	the FEC checkbits, so the line rate isn't changed. The checkbits are
located
	in unused SONET
	overhead and typically consume only around 1% of the line bandwidth.

	...Dave

	David W. Martin
	Nortel Networks
	+1 613 765-2901   
	+1 613 763-2388 (fax)
	dwmartin@xxxxxxxxxxxxxxxxxx
	========================

		-----Original Message-----
		From:	Fred Weniger [SMTP:weniger@xxxxxxxxxxx]
		Sent:	Tuesday, June 29, 1999 12:37 AM
		To:	Paul Bottorff; Drew Perkins; 'Peter_Wang@xxxxxxxx';
	'rabynum@xxxxxxxxxxx'
		Cc:	'stds-802-3-hssg@xxxxxxxx'
		Subject:	RE: Issues concerning 10GbE speed standards


		All,

		Could one deduce from this discussion that FEC, which lowers
BER at
	the
		expense of requiring up to 25% higher bandwidth, is
therefore a bad
	thing?
		And, if it's a bad thing, are any of you advocating that
therefore,
	FEC
		should not be employed on existing SONET rings?





		At 09:20 AM 6/26/99 -0700, Paul Bottorff wrote:
		>
		>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
		>


		Fred Weniger
		Product Marketing Manager, Gigabit Products
		Vitesse Semiconductor Corporation
		741 Calle Plano, Camarillo, CA 93012
		Phone: 805-388-7571   Fax: 805-987-5896
		E-mail: weniger@xxxxxxxxxxx