RE: 10GE data rate?

[Drew Perkins <drew.perkins@xxxxxxxxxxxx>]

Roy,
	You are correct about part of the difference. Router interfaces are
much more expensive for at least the following reasons:

1) The task of packet "classification" is much more difficult on a router
(i.e. L3 switch). L2 switches look at a relatively short and simple tag like
an Ethernet address, VPCI, DLCI, etc. Routers look at a much larger set of
bits arranged in a less straightforward manner using fairly complex
algorithms that require far more state. This typically requires additional
chips and memories vs. an Ethernet switch.

2) Routers often provide much more sophisticated buffering and scheduling
algorithms such as multiple-priority weighted round-robin with a large set
of queues. Again this translates into more chips and memories than the
simple FIFO algorithms often used with Ethernet switches.

3) Routers usually require much larger packet buffers than Ethernet
switches. Routers are required to include at least one bandwidth*delay
product worth of buffer, where they delay is that necessary for continental
or intercontinental distances. Ethernet switches generally assume a LAN
environment with very short distances and delays.

4) Ethernet switches are sold in much higher volumes. Simple economics and
business realities require higher prices and/or margins.

5) Routers often have much more complicated control processors with large
amounts of memory. This may not be on the same interface card, but is
included in the entire system cost.

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 Roy Bynum
Sent: Friday, June 25, 1999 5:32 PM
To: Rich Taborek
Cc: nuss@xxxxxxxxxx; HSSG; HSSG Speed
Subject: Re: 10GE data rate?



Rich,

I have been trying to discover why a router GbE interface costs more
than an L2/L3 data switch GbE interface does.  The answer I got was the
router does a lot of route processing on the card in order to do the
line speed routing of each packet.  I was told that a router requires
much more processing per packet than an L2/L3 switch does.  Is this
true?  If it is, then the current high costs of OC rate router cards for
routers would not apply if an OC rate was applied to 10GbE.  

By the way rich, who is going to pay for the non-telephony standard
support systems, applifiers, regenerators, etc. that would have to be
developed for a non-OC rate long distance version of 10GbE.  Better yet,
how many people would it take to support a single optical path that
spaned the globe that could not be managed globally?

Thank you,
Roy Bynum

Rich Taborek wrote:
> 
> 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