Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Issues concerning 10GbE speed standards




Peter,

I am not talking about developing a specific new chip set.  I am talking about not
using all of the configurable functionality of the existing chip sets.

This would be similar to what was done years ago with the early Z80 SIO.  The Z80
SIO had a lot of different functionalities.  Because of the comparibly poor process
control, not all of the functions worked all of the time on any given chip.  As the
chips were tested on the wafer, it was found what did and did not work.  From the
wafer test results, different specific types of Z80 SIO devices were asembled.  The
highest grade device was used for SDLC/HDLC.  The lowest grade device was used for
asyncronous only communications.

While I have been out of the chip manufacturing industry for severl years, I am sure
that SONET/SDH chip set manufacturers today have different grades of devices that
are derived from the same chips.  I am sure that sometimes they have devices that
have specific functional "flaws".  Today, in the telephony devices, where all
fuctions have to operate, there is little, if any, market for the "flawed" devices.
In a market that required only certain functions to be operable, some of those
"flawed" devices can be sold.  This will allow the chip set manufacturers to
increase their market, increase their yeld, and decrease the cost of the devices to
the system manufacturers, without doing any major development work.

Roy Bynum


Peter_Wang@xxxxxxxx wrote:

> 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