RE: Issues concerning 10GbE speed standards
- To: Drew Perkins <drew.perkins@xxxxxxxxxxxx>
- Subject: RE: Issues concerning 10GbE speed standards
- From: "David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 Jun 1999 15:30:49 -0500
- Cc: "'stds-802-3-hssg@xxxxxxxx'" <stds-802-3-hssg@xxxxxxxx>
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
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