Re: Issues concerning 10GbE speed standards

[Dae Young KIM <dykim@xxxxxxxxxxxxxxxxxx>]

How would people like the idea of using a new 8B10B code that would require half
the bandwidth of the known IBM's 8B10B code and even less (40% less) than the
scrambled NRZ? Believe it or not, there IS such a code, and will be presented in
the Montreal meeting.

Looking forwards to having your comments there on our proposal, MB810 code...


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

--
Dae Young