Re: 10GE data rate?

[Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>]

Drew,

The Ethernet/WAN schemes #1 and #2 I've summarized were discussed at length
during a 1-1/2 hour HSSG Speed conference call this past Tuesday. The minimum
difference between #1 an #2 is an unencoded speed difference of  exactly 10 Gbps
and SONET rates, respectively. The scarier scenario is the maximum difference
where many other SONET characteristics are imposed upon Ethernet, potentially
rendering it not-so-simple and not-so-inexpensive at 10 Gbps. A straw poll was
taken, and there were not many supporters of both data rates. According to the
same straw poll, it will be difficult to sell a SONET rate Ethernet PHY to the
HSSG.

Please also consider the LAN environment where the WAN connection requirements
are nowhere close to 10 Gbps, but the LAN backbone requirements are already
there. Howard Frazier has very eloquently pointed out the reasons why a SONET
rate Ethernet PHY is not such an easy sell in the LAN environment in a June 22
note to this reflector. Points A through D in that note, which I agree with, are
why I say that scheme #2 is a bad idea.

Also in Howard's note (point E) and discussed during the conference call was the
concept of a simple and cheap rate converter between a native 10 GbE and SONET.
I believe that such a converter falls into scheme #1. A single native 10 GbE
port will have no problem keeping a single SONET port full from a receive and
transmit direction. 802.3 Flow Control can simply and cost effectively perform
the necessary speed matching.

Turning the argument around, I'd like to hear sound technical and economic
reasons why scheme #1 is not the best solution for Ethernet/WAN access support
providing exactly 10 Gbps to LAN directly coupled to full OC-192 SONET support
for the WAN.

--

Drew Perkins wrote:

> Rich,
>         As already said, at the end of the day #1 and #2 are the same. The
> only difference might be internal implementation difference (chip
> interfaces). The resulting protocol on the wire may be precisely the same,
> or may differ only by inclusion of preambles, IFGs, etc. vs. POS encodings.
> Why do you say that #2 is a step in the wrong direction?
>
> 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 Rich
> Taborek
> Sent: Wednesday, June 23, 1999 1:18 AM
> To: nuss@xxxxxxxxxx; HSSG; HSSG Speed
> Subject: Re: 10GE data rate?
>
> In an early note to the HSSG Speed reflector, I summarized my view of all
> schemes discussed thus far to support the WAN at Ethernet rates of ~10 Gbps.
> I'll repost that summary here to make it available to the larger HSSG
> reflector. The three schemes I have come up with are:
>
> 1) Legacy: 10Gbps Ethernet switched/bridged/routed to Sonet. We simply need
> to specify a 10 Gbps PHY to make this fly.
>
> 2) SONET-based PHY: A new Ethernet PHY compatible with OC-192 SONET that
> connects directly to the Ethernet MAC, which runs at SONET OC-192 rates.
> This is the new PHY suggested by Paul. Looking forward, the next higher
> Ethernet speed variant would likely be OC-768.
>
> 3) 10 Gbps Ethernet WAN PHY: A new Ethernet PHY supporting WAN dark fiber
> and/or DWDM equipment, sans SONET. I believe that this is one of the options
> proposed by Bill St. Arnaud among others.
>
> My scheme (3) seems to correspond with Martin's (1) and (3) below and is a
> PHY variant which supports a data rate of exactly 10.0 Gbps. Other qualities
> of this PHY may include any or all of the following:
> a) Direct drive of long-haul dark fiber and/or DWDM equipment;
> b) Simplex and/or duplex channels;
> c) Standard Ethernet facilities for out-of-band signaling and cable plant
> management including MAC Control frames, Auto-Negotiation, and (I hate to
> even suggest it) Primitive Signaling using alternate "Idle" codes. Ethernet
> out-of-band signaling capabilities are actually more extensive than most
> protocols I'm aware of.
>
> (1) above seems supports the existing SONET infrastructure quite adequeately
> and allows high performance switch/bridge/router products to be implemeted
> in a manner of highest compatibility with the LAN and WAN.
>
> (2) sabove ignificantly affects the existing LAN market through its dictate
> of SONET speeds and other peculiarities not applicable to existing LANs and
> is a step in the wrong direction .
>
> (3) above takes Ethernet where no Ethernet has gone before and treads
> directly on the existing WAN infrastructure. This latter alternative will be
> difficult to go forward with also since the "LAN" folks consider it to be
> outside the scope of 802, and the "WAN" folks view it as a significant
> territorial encroachment. However, once (1) happens, the cost advantages of
> it will inevitably drive implementations and products based on (3).
>
> --
>
> Martin Nuss wrote:
>
> > Roy:
> > I wanted to get your expert opinion on a few issues that would be of
> > interest to me as we go forward in the standard:
> >
> > 1) do you really believe that we need to support all the WAN OAMP
> > features in 10GE?  I would rather prefer a light-weight 10ge protocol
> > that guarantees the lowest cost in the LAN, but make sure that it can be
> > wrapped easily into a WAN envelope to support all the WAN features.
> >
> > 2) at the last meeting, Paul Bottorff as well as Mike Salzman presented
> > approaches to a serial 10GE standard based on scrambling as opposed to
> > block coding.  Both of these could be used for a low-cost serial LAN
> > standard, and wrapped into WAN envelopes like SONET to provide WAN OAMP
> > features.  The 10GE data rate would have to be kept to around 9.6 Gb/s
> > to make that possible at the lowest cost.  Presumably, that would
> > accelerate the acceptance of 10GE in the WAN.
> >
> > 3) Alternatively, we could propose to allow for additional control
> > fields in the 10GE standard that duplicate the functions most important
> > for WAN apps.  This may be the cleanest solution, but it will require
> > 802.3 to venture into an area that it has not worried about before...
> >
> > Any thoughts?
> >
> > Martin
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------------
> 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

--

Best Regards,
Rich

-------------------------------------------------------------
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