RE: 10GE data rate?

["Chang, Edward S" <Edward.Chang@xxxxxxxxxx>]

It is right move to bring the issue to larger audience HSSG.  It will enable
us to receive more contributions to the issue, and educate all voters the
pro-and-cons, to whom this issue is outside of their expertise.  This is the
right way to achieve 75% votes in the future.

Both Datacom and Telecom are very successful in their own ways of doing
business for many years.  I think the purpose of HSSG is to provide the
smoothest way to connect LAN and WAN without change any of their business
practices.  In other words, what we need is the legacy Ethernet LAN, 10GbE,
with switch/router/bridge converting from LAN to WAN and vise versa. 

Datacom needs Telecom to connect LAN to each corner of the world, and
Telecom needs the cheap/efficient LAN to provide affordable connections to
reach end users.  Both need each other to be successful.  Any attempt to
impose one's approach to the other will upset the industry, and industry
will ignore any new specification generated by HSSG to continue to make
profit the way they know the best.  10GbE will survive mainly by LAN market
applications -- backward compatible, scalability, smooth migration,
coexisting in multiple rates ......etc, then we will add additional feature,
smooth LAN-to-WAN conversion to further open-up market, which is the
secondary objective.

Any attempt to make 10GbE like Sonet, or WAN like GbE to wish the conversion
from LAN to WAN, or  vice versa, will be SWITCH-LESS is wrong.  Even both
are exact protocol, we still need switch to do conversion, because there are
so many differences among them; namely, clock tolerance, BER requirement,
multiple addresses, QoS requirement, overhead requirement, fault detection
requirement, ..... name it.  One way or the other a switch is needed.  Even
both use OC-192, we still need a switch to provide buffer to accommodate the
clock tolerance and phase differences based on the largest frame size
requirement.  

Look at the ATM example.  ATM tried to be the SONET of LAN, which still
needs a switch to convert the differences among ATM for LAN  and Sonet for
WAN.  LAN and WAN have fundamental differences in requirement due to their
operating environment, which can not be forced to make equal by a protocol.

I believe we should spend our resources in how to make those
switch/bridge/router's LAN/WAN conversion task, as easy as possible, but do
not alter any Datacom or Telecom successful practices, or impose one to
another. 

Ed Chang
Unisys Corporation 
Edward.Chang@xxxxxxxxxx
 


 

          

 

          

-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
Sent: Wednesday, June 23, 1999 4: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