Re: Issues concerning 10GbE speed standards
- To: Drew Perkins <drew.perkins@xxxxxxxxxxxx>
- Subject: Re: Issues concerning 10GbE speed standards
- From: Roy Bynum <rabynum@xxxxxxxxxxx>
- Date: Mon, 28 Jun 1999 21:46:17 -0500
- CC: "'stds-802-3-hssg@xxxxxxxx'" <stds-802-3-hssg@xxxxxxxx>
- Organization: .
- References: <2072E1221F1DD211848C00104B938E7B733580@xxxxxxxxxxxx>
- Reply-To: rabynum@xxxxxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Drew,
I have had several discussions about FEC with several people from MCI WorldCom's
Network Technology organization, which defines the deployment standards for all
of our optical transmission systems. Their take on FEC is that it extends the
distance that can be achieved for a given optical launch power. In DWDM
systems, one of the problems it is often the combined launch power of multiple
wavelengths. Being able to reduce launch power for a given distance or increase
distance for a given launch power is major benefit according to these people. I
am wondering if it could not be used in LAN implementations to improve
performance for "gofer-bait" fiber. If so, it could be a major economic
benefit.
As a side note, there was a lot of commentary by Lucent about a "digital
wrapper" for optical data. As it was explained to me, said "digital wrapper"
operated a lot a SONET/SDH header in functionality.
Thank you,
Roy Bynum
MCI WorldCom
Drew Perkins wrote:
> 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