Re: WAN Protocol For WAN Applications

[Fred Weniger <weniger@xxxxxxxxxxx>]

All,

Does anyone else feel that it would be very enlightening to hear from
others who have actually implemented true GbE in MAN/WAN environments?
This could help us to better understand GbE MAN/WAN provisioning,
management & maintenance issues from others with direct experience.  A lot
of what I am reading here is conjectural, I believe.


At 10:15 AM 6/27/99 -0500, Roy Bynum wrote:
>
>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
>
>


Fred Weniger
Product Marketing Manager, Gigabit Products
Vitesse Semiconductor Corporation
741 Calle Plano, Camarillo, CA 93012
Phone: 805-388-7571   Fax: 805-987-5896
E-mail: weniger@xxxxxxxxxxx