Re: Issues concerning 10GbE speed standards

[Colin Mick--The Mick Group <ckm@xxxxxxxxxxxxx>]

I think multiuple competing solutions and a "let the market decide" is a
sure recipe for disaster. 
It guarantees inoperable solutions and promotes market confusion.

Making decisions among competing techincal solutions is a tough but
necessary part of the standards process. 

Colin

At 01:42 PM 6/28/99 -0700, BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
>     Bruce,
>     
>     We have not yet had any such presentations.  It will be difficult to 
>     get an accurate picture since products are not yet available, and each 
>     PMD advocate believes his/her approach to be the lowest cost.  Ed 
>     Chang wants to let the market decide, and that might not be a bad 
>     idea.  I think the best we can do is to continue to present results as 
>     they become available.  Efforts to exclude an approach from the 
>     standard due to cost, before any products are available, and before 
>     reliable cost information is available could be very dangerous, unless 
>     there is widespread agreement on relative cost, time-to-market, and 
>     probability of success.
>     
>     -Brian Lemoff
>      HP Labs
>     
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: Issues concerning 10GbE speed standards
>Author:  Non-HP-Bruce-Tolley (Bruce_Tolley@xxxxxxxx) at HP-PaloAlto,mimegw2
>Date:    6/28/99 10:42 AM
>
>
>
>
>
>Have we seen any formal detailed presentations on the relative costs of
any of
>the proposals???
>
>
>Bruce Tolley
>3Com Corp
>
>
>
>
>BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx on 06/28/99 10:17:37 AM
>
>Sent by:  BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>To:   nuss@xxxxxxxxxx
>cc:   drew.perkins@xxxxxxxxxxxx, pbottorf@xxxxxxxxxxxxxxxxxx, Peter
>      Wang/HQ/3Com, rabynum@xxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx (Bruce
>      Tolley/HQ/3Com)
>Subject:  Re: Issues concerning 10GbE speed standards
>
>
>
>
>
>     Martin,
>
>     Your claim that "... a serial 10-Gig solution is definitely going to
>     be the cheapest one by the time 10G Ethernet sales seriously take off"
>     is absolutely outrageous, and has no place on this reflector.  Perhaps,
>     relative to other solutions that Lucent has been able to develop,
this is
>     true, but there have been several other proposals (including the HP
WWDM,
>     Blaze WWDM, Transcendata MAS) that could very well be cheaper than
serial
>     10-Gig for MANY YEARS TO COME.
>
>     Your argument in favor of scrambling is valid, but it also has to be
>     balanced against the disadvantage of designing electronics that support
>     very low frequencies.  AC balanced electronics (both TX and RX) with
>     relatively high low frequency cutoffs tend to have less jitter and
result
>     in higher sensitivity.  In the regime that we are working on (i.e. our
>     low-cost 4 channel WWDM module) the trade-off between 2.5-Gbaud
scrambled
>     and 3.125-Gbaud 8B/10B is a close call.  There are pros and cons to both
>     sides.  Certainly both are well within the realm of low-cost electronic
>     processes.
>
>     -Brian Lemoff
>      HP Labs
>
>     ______________________________ Reply Separator
>     _________________________________
>     Subject: Re: Issues concerning 10GbE speed standards
>Author:  Non-HP-nuss (nuss@xxxxxxxxxx) at HP-PaloAlto,mimegw2
>Date:    6/28/99 8:20 AM
>
>
>All,
>
>I think we are making a mistake by talking about scrambling in the WAN
>and 8B/10B in the LAN.  There are a lot of good reasons why we need to
>look at scrambling in the LAN as well:
>
>1) a serial 10-Gig solution is definitely going to be the cheapest one
>by the time 10G Ethernet sales seriously take off.  That is true in the
>LAN as well.  You do not want to exclude an option that promises to be
>the cheapest one!
>
>2) there is no significant cost advantage in 8B/10B coding over
>scrambling from an optics and electronics point of view
>
>3) there is however a cost penalty going to higher speed optics and
>electronics.  10 Gb/s can be achieved rather readily for both optics and
>electronics, but a 25% overhead likely makes things more expensive
>
>4) the lower line rate (10.00 vs. 12.5 Gb/s) directly translates into
>longer distances supported, more power budget, and less penalties (such
>as DMD).
>
>
>Martin Nuss
>
>
>
>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
> 
Colin K. Mick
The Mick Group
2130 Hanover St,
Palo Alto, CA  94306
voice: (650) 856-3666
FAX: (650) 494-3737
email: ckm@xxxxxxxxxxxxx
URL: www.mickgroup.com