Re: Issues concerning 10GbE speed standards

[Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>]

Roy,

I interpret your desires/requirements for 10 GbE as follows:

- Payload rate of 9,584,640,000 bps
-  SONET/SDH signaling (to support a subset of the SONET/SDH operations support
functionality)

Is this correct? If correct, is there anything else.

Best Regards,
Rich

--

Roy Bynum wrote:

> Walt,
>
> I do not specifically want to add the complexity of all of the existing
> SONET/SDH functionality in 10GbE.  Even the SONET compatible POS router
> interfaces do not implement true SONET restoration and operations
> support functionality.  The ability to support a subset of the SONET/SDH
> operations support functionality would greatly reduce the support costs
> for extended link 10GbE.
>
> I am pointing out that the existing facilities install base for
> commercial extended link services at 10Gb is based on SONET/SDH
> signaling.  By leveraging that existing install base, the implementation
> costs for extended link 10GbE can be greatly reduced in the commercial
> services
> market.  Those reduced costs will directly impact the magnitude of the
> market penetration of 10GbE.
>
> Thank you,
> Roy Bynum,
> MCI WorldCom
>
> (PS. Sorry for the delay in responding to your message.  I am still not
> on the "speed" reflector.)
>
> Walt Thirion wrote:
> ____________________________________________________________________________
>
> Roy,
>
> Are you specifically advocating that 802.3 support not only the same
> rate as Sonet, but that we also support:
>
> "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."
>
> Walter Thirion
> Level One Communications
> 512-407-2110
>
> > -----Original Message-----
> > From: owner-stds-802-3-hssg-speed@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-3-hssg-speed@xxxxxxxxxxxxxxxxxx]On
> > Behalf Of Roy
> > Bynum
> > Sent: Sunday, June 20, 1999 9:34 AM
> > To: Thirion, Walt
> > Cc: stds-802-3-hssg@xxxxxxxx; stds-802-3-hssg-speed@xxxxxxxx
> > 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
> >

-------------------------------------------------------------
Richard Taborek Sr.    Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect         Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc.           Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way              http://www.transcendata.com
Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx