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

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