RE: Issues concerning 10GbE speed standards
- To: ka@xxxxxxxxxxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx
- Subject: RE: Issues concerning 10GbE speed standards
- From: Fred Weniger <weniger@xxxxxxxxxxx>
- Date: Mon, 28 Jun 1999 23:43:59 -0700
- In-Reply-To: <199906281719.NAA20629@xxxxxxxxxxxxxxxxxxx>
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Kamran,
You have touched on some very key points here. If I may pursue them:
1. Why is latency of less concern in a WAN than in a LAN? I would have
thought just the opposite (consider noticeable delay in voice communication
via satellite, for example).
2. Multiple FEC schemes are referred to. How do they differ? Are they
interoperable among multiple vendors? How much power do they consume?
3. Same question for scrambling. Is it always interoperable among vendors?
How much power does it consume?
4. You state that one benefit of FEC is lower cost optics. Why does FEC
permit lower cost optics? Will the same benefit be realized with less
system power penalty by using 8B/10B? My suspicion is, yes - it will!
Regards,
At 01:19 PM 6/28/99 -0400, ka@xxxxxxxxxxxxxxxxxxx wrote:
>Fred,
>
> FEC is definitly worth being considered by the HSSG group both
>for LAN and WAN. There are FEC schemes that require lot less than
>25% overhead. Actually some FEC schemes used in optical communication
>use as low as 0.05% overhead (BCH codes), few bits out of thousands of
>bytes. A popular code is the Reed-Solomon code RS(255,239). Its
>redundancy is 255-239=16 Bytes for 239 Bytes of information, that
>is 7% overhead. It has a very good performance (5dB optical gain).
>
>There are many FEC schemes that are suitable for optical communications
>and provide a high gain for a modest overhead (maybe zero overhead if
>parity bits are transmitted in a reserved header or in the IPG of
>Ethernet packets). The drawback of using FEC is an increase in logic
>circuit cost (which is less and less of a problem with increase of
>logic density in CMOS technology), and increase in PHY latency. For
>WAN applications the increase in latency is insignificant, however
>for LAN depending on which code is being cosidered, latency could
>be significant compared to propagation time in the fiber and require
>an increase of buffer size in a switch. This can rule out certain codes.
>
>Finally, I believe both LAN and WAN can benefit from FEC (and from
>zero overhead scrambled codes as well but that's a seperate discussion).
>In WAN it is important to increase the maximum operating link distance to
>minimize overall system cost, and this can be achieved by FEC. The
>benefits of FEC can potentially be greater in LAN, because of DMD.
>Optical gain depends very much on the optical response of the receiver
>and on the channel. Usually the worse the channel, the greater the
>benefits from FEC.
>
>Implementing an FEC technique in 10G Ethernet can greatly help supporting
>existing installed base of fiber + increase operating distance on new
>low-cost multi-mode fibers.
>
>In my humble opinion, the extra cost of X gates is well worth-while
>if this allows a considerable decrease in overall system cost, and
>relaxing requirements of the optics including the fiber itself.
>
>Regards,
>
>Kamran
>
>===========================================================================
===
>
>----- Begin Included Message -----
>
>>From owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx Mon Jun 28 12:42:40 1999
>Return-Path: <owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
>To: pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff),
> Drew Perkins <drew.perkins@xxxxxxxxxxxx>,
> "'Peter_Wang@xxxxxxxx'" <Peter_Wang@xxxxxxxx>,
> "'rabynum@xxxxxxxxxxx'" <rabynum@xxxxxxxxxxx>
>X-Sender: weniger@pop3host
>From: Fred Weniger <weniger@xxxxxxxxxxx>
>Subject: RE: Issues concerning 10GbE speed standards
>Cc: "'stds-802-3-hssg@xxxxxxxx'" <stds-802-3-hssg@xxxxxxxx>
>Mime-Version: 1.0
>Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
>Precedence: bulk
>X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
>X-Listname: stds-802-3-hssg
>X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
>X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
>X-Lines: 252
>
>
>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
>
>
>----- End Included Message -----
>
>
>
Fred Weniger