Re: WAN Protocol For WAN Applications

[Roy Bynum <rabynum@xxxxxxxxxxx>]

Thomas,

I am very glad that we agree that LANs should implement LAN protocols and WANs
should implement WAN protocols.  I am also glad that we agree on some distinctions
between LAN and WAN implementations.

I note that you do not mention MANs.  I recognize that a MAN is actually a sort
distance WAN.

I am also questioning why , what some consider to be a LAN protocol, is being
implemented over WANs.  Could it be that something was missed in the
specifications of the LAN protocol that did not limit it to a LAN?

Can the next version of protocol have a specification defined that specifically
limits it to a LAN implementation?  Can the next version of the protocol have a
specification that provides for it being implemented over WANs?  How easy would it
be to define the specifications that make the distinction between LAN and WAN
implementation?  Should the LAN vs WAN distinction be made in the next version of
the protocol?

What I, as an end user, enterprise data network architect, and enterprise data
services provider employee, am asking for, is that specification distinction
between LAN and WAN.  That distinction could very easily be made at the PHY
level.  The LAN only specification could be a four channel, 3.125 signal rate
using 8B/10B block encoding at a data rate of 2.5Gbps per channel PHY.  The WAN
specification could be a serial ~10Gb signal rate using scramble encoding at a
~10Gb data rate PHY.

Thank you for agreeing with me,
Roy Bynum



Thomas Dineen wrote:

> Roy:
>
>         I have been listening to this go round and round now for some time,
> and it all seems to come back to what I attempted to try to explain to
> you
> at the last meeting.
>
>         For WAN Applications it is best to use a WAN Protocol!
>
>         For LAN Applications it is best to use a LAN Protocol!
>
>         Now, the question is why?
>
>         Well that answer is features versus cost.
>
>         LAN Protocols are designed to operate over relatively short distances,
> in environments
> with relatively low bit error rates, which are typically contained
> within a single autonomous
> zone, which is under the control of one proprietorship. These operating
> constraints, are
> typically used as the justification for the selection of  relatively
> simple protocols which may be implemented in a cost effective manor,
> which in turn has resulted in high volume and high revenue
> in LAN market area.
>
>         WAN protocols in turn are quite a different bird. WAN Protocols are
> designed to operate
> over relatively large distances, typically of a geographic scale, with
> relatively high bit error
> rates, in environments which consist of multiple carriers or providers.
> The geographic scale of
> WAN Networks presents a number of challenges in the field of Network
> Management. These challenges
> are addressed with inclusion of Operations And Maintenance Protocols as
> part of WAN Standards.
> The WAN environment also includes requirements for high reliability or
> service availability.
> These requirements are addressed with the inclusion of Physical Layer
> redundancy and automatic
> protection switching. When the above requirements are compiled into a
> real world design, the
> cost of WAN devices is substantially higher than that of corresponding
> LAN devices.
>
>         This is the reason I oppose the inclusion of WAN functionality within
> the proposed
> 10 GBit/Sec Ethernet standard.  By the way, I too speak from real world
> experience here, having
> designed both types of devices.
>
>         Continuing success, requires that you know why you are successful.
> Ethernet is successful
> because it is cheap, Ethernet is cheap because it is simple. KEEP IT
> SIMPLE.
>
> Thomas Dineen
>
> 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