Re: Long distance links
Rich:
At 02:01 PM 8/31/99 -0700, Rich Taborek wrote:
>
>Jonathan,
>
>I don't think we're communicating. I may be completely off base, but it
seems to
>me that you're confusing SONET with the WAN.
Rich, I think you are completely (and totally) off base. From a market
share point of view SONET is the WAN. In all the history of Ethernet a
major factor to success has been the support of the installed base. In the
early days of Ethernet we adapted Ethernet systems to carry the existing
protocols for the terminals, hosts, and printers of that day. Though each
generation of Ethernet we have provided support for existing cabling and
infrastructure. It is not possible to address the WAN without addressing
SONET. Ethernet is just not viable as a mainstream WAN protocol without
some consideration of SONET.
>Ethernet includes MAC and PHY
>layers as its primary OSI layers. SONET does the same. Carrying one MAC
and PHY
>layer over another is not normal practice nor recommended.
It is not only normal practice, but the main objective of SONET networks to
carry other protocols. SONET is not a LAN and does not behave or model like
an OSI data network. Any analogy between what should be done for an OSI
data network link and SONET links is misplaced. The best way to think of
SONET and of DWDM photonic networks is like intelligent wire.
>Please allow me to
>make the following analogy:
>
>For example, the SAN market today is being driven by Fibre Channel. Fibre
>Channel is essentially equivalent to Ethernet in that the MAC and PHY
layers are
>supported. To provide SAN support, Fibre Channel transports (carries) the
>SCSI-3 Command Set. Fibre Channel DOES NOT transport the SCSI Physical Layer.
>Doing so would be ludicrous except to satisfy the migration requirements of
>legacy products.
SONET is not a data protocol. This analogy to Fibre Channel is completely
mistaken.
>
>For the same reason, it is ludicrous to speak about 10 GbE
transporting/carrying
>SONET.
Since when are we talking about 10 GigE transporting/carrying SONET? I
thought we were only talking about SONET transporting/carrying 10 GigE.
>In my mind, it is feasible to expand current HSSG objectives to include
>the WAN market.
An incredibly small portion of the WAN market could be addressed by
ignoring the installed base. We are talking about take 10 GigE into the WAN
mainstream.
>It is NOT prudent nor cost effective for the HSSG to consider
>carrying Ethernet over SONET.
So why not? Do you have any data to backup these claims? What data makes
you believe that using the installed base is not prudent or cost effective.
I'd like to see your market study on the potential and an analysis of where
these cost are you're talking about.
>IEEE 802 is not the proper forum in which to
>address such an effort even if it deemed worthy to address. My suggestion
to you
>is to call any discussion of carrying Ethernet over SONET out of order.
I can't believe you want some other forum to design Ethernet.
>
>P.S. I have no objections and would STRONGLY support an HSSG objective to
have
>Ethernet support the WAN environment. My current view is that Ethernet is
king
>in the LAN and that the MAN is the "DMZ" between the LAN and WAN.
>
>Best Regards,
>Rich
Cheers,
Paul
>
>--
>
>Jonathan Thatcher wrote:
>
>> Rich,
>>
>> It is certainly true that our current objectives do not support
developing a
>> standard supporting Ethernet over SONET. Neither is there an anti-objective
>> directing us to not look at support of Ethernet over SONET. Had the later
>> been true, I would have called all discussion out-of-order (like was done
>> with jumbo frames).
>>
>> As you suggest, the basis for the discussion is to resolve the issue of
>> 10.0000 vs 9.58464 Gb/s. If germane to this decision is a decision on
>> whether or not to support Ethernet over SONET, then let us make it. To make
>> that decision, we must understand the pro's and con's. As best as I can
tell
>> the pro is simple: we can directly ship packets over the WAN
infrastructure.
>> The con's are those things that complicate Ethernet; things that require
>> changes to Ethernet; things that add cost to Ethernet.
>>
>> My interest in a clear, concise list of requirements is that it will focus
>> the discussion, provide a less ambiguous backdrop for making decisions, and
>> allow the group to progress more rapidly. The process is one we have all
>> used many times: 1. write down the list of requirements; 2. prioritize the
>> list; 3. identify alternatives; 4. evaluate the cost/benefit; 5. make a
>> decision; 6. execute. 7. Iterate as necessary, research as necessary.
>>
>> The onus of the first step is on the proponents of the idea.
>>
>> jonathan
>>
>> > -----Original Message-----
>> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
>> > Sent: Tuesday, August 31, 1999 12:05 PM
>> > To: HSSG
>> > Subject: Re: Long distance links
>> >
>> >
>> >
>> > Jonathan,
>> >
>> > I agree that Paul's statement is concise, but please bear in
>> > mind that it has
>> > NOTHING to do with HSSG work as far as I can tell. I'm not
>> > sure if this was
>> > Paul's intention in his note containing this original text.
>> > There are no HSSG
>> > objectives that even remotely address the issue of "carrying
>> > Ethernet frames on
>> > a SONET system". The closest one is an objective to choose
>> > one of two MAC/PLS
>> > data rates: 10 or 9.584640 Gbps.
>> >
>> > I would strongly encourage all proponents of Ethernet over
>> > SONET to either
>> > propose new HSSG objectives addressing these issues, put
>> > forth a Call for
>> > Interest on this issue, or find another forum.
>> >
>> > Personally, I don't see any benefit to Ethernet by meeting
>> > ANY of Paul's
>> > requirements and I DO see clear disadvantages with meeting
>> > ANY of them. SONET
>> > transports Ethernet frames just fine today. SONET will be
>> > able to transport 10
>> > GbE frames just fine in the future. Forcing SONET/WAN
>> > architectures upon
>> > Ethernet is not cost effective for either the WAN or LAN environment.
>> >
>> > Best Regards,
>> > Rich
>> >
>> > --
>> >
>> > Jonathan Thatcher wrote:
>> >
>> > > Paul. Thank you!
>> > >
>> > > Your words (copied from below) represent the simplest, most
>> > concise (perhaps
>> > > the ONLY concise) set of requirements I remember seeing to
>> > date regarding
>> > > this topic.
>> > >
>> > > I would strongly encourage all proponents of Ethernet over
>> > SONET to set
>> > > aside the diatribe and modify, expand upon, or otherwise
>> > improve upon this
>> > > list.
>> > >
>> > > -------------- from Paul --------------------------
>> > > To carry Ethernet frames on a SONET system:
>> > >
>> > > 1)Ethernet must match the payload rate of 9.584640 Gbps
>> > > 2)Ethernet frames must be encoded with NRZ efficiency
>> > > 3)Ethernet frame delimiting must operate without special symbols
>> > > ------------ end from Paul ------------------------
>> > >
>> > > jonathan
>> > >
>> > > > -----Original Message-----
>> > > > From: pbottorf@xxxxxxxxxxxxxxxxxx
>> > [mailto:pbottorf@xxxxxxxxxxxxxxxxxx]
>> > > > Sent: Monday, August 30, 1999 4:36 PM
>> > > > To: Rohit Mittal; rtaborek@xxxxxxxxxxxxxxxx
>> > > > Cc: HSSG
>> > > > Subject: Re: Long distance links
>> > > >
>> > > >
>> > > >
>> > > > Rohit:
>> > > >
>> > > > At 01:17 PM 8/30/99 -0700, Rohit Mittal wrote:
>> > > > >
>> > > > >Rich et al,
>> > > > >
>> > > > >One of the things you need to consider is that SONET has
>> > > > extensive error
>> > > > monitoring
>> > > > >"built-in" the overhead to allow speedy detection of
>> > > > failures before they
>> > > > degrade
>> > > > >to serious levels. SONET provides rapid fault isolation.
>> > > > >
>> > > > >Now, if you use TCP/IP for the same tasks, you are going to
>> > > > add latency etc.
>> > > > >because the frame/data will have to pass through many layers
>> > > > before any
>> > > > fault is
>> > > > >detected. That is the problem in moving up the protocol stack.
>> > > > >
>> > > > >For instance, SONET allows less than 50ms time for signal
>> > > > restoration (due
>> > > > to cut
>> > > > >fiber etc.). I do not see anything in Ethernet which can provide
>> > > > equivalent support
>> > > > >- maybe Far end fault detector but doesn't that takes a long
>> > > > time to detect?
>> > > > >
>> > > > >IMO, the best solution is just to encapsulate ethernet
>> > > > frames as data bits
>> > > > in a
>> > > > >SONET frame. That way SONET can provide the management
>> > features for
>> > > > preventing
>> > > > >expensive mantainence and Ethernet can travel as is. Am
>> > I overlooking
>> > > > something?
>> > > >
>> > > > To carry Ethernet frames on a SONET system:
>> > > >
>> > > > 1)Ethernet must match the payload rate of 9.584640 Gbps
>> > > > 2)Ethernet frames must be encoded with NRZ efficiency
>> > > > 3)Ethernet frame delimiting must operate without special symbols
>> > > >
>> > > > >
>> > > > >Rohit Mittal
>> > > > >Engineering, Microlinear Corp.
>> > > > >
>> > > > >> Mark,
>> > > > >>
>> > > > >> I believe you're on the right track insofar as digging to
>> > > > the root of the
>> > > > >> management issue. The fact of the matter is that Ethernet
>> > > > does it one
>> > > > way, and
>> > > > >> SONET does it another. My sense is the same as yours:
>> > > > "...instead of
>> > > > >> transporting management info on dedicated
>> > > > >> circuits, use TCP/IP and packets. It's the histroric
>> > > > trend, moving up the
>> > > > >> protocol stack."
>> > > > >>
>> > > > >> I have asked numerous questions over this reflector trying
>> > > > to get at the
>> > > > core of
>> > > > >> requirements for WAN management. I've seen no
>> > responses to those
>> > > > questions. BTW,
>> > > > >> I'm sill very much interested in hearing the responses to
>> > > > these questions.
>> > > > >>
>> > > > >> Without knowing the requirements for SONET WAN management,
>> > > > I have to
>> > > > believe
>> > > > >> that Ethernet Management, ULP (e.g. Ping, SNMP,
>> > Browser) management
>> > > > mechanisms,
>> > > > >> Etherenet PHY capabilities for determining things like the
>> > > > BER of each
>> > > > link,
>> > > > >> represent sufficient architecture to implement WAN
>> > > > management equivalent or
>> > > > >> superior to that of SONET.
>> > > > >>
>> > > > >> Best Regards,
>> > > > >> Rich
>> > > > >>
>> > > > >> --
>> > > > >>
>> > > > >> "Gerhold, Mark" wrote:
>> > > > >>
>> > > > >> > All,
>> > > > >> >
>> > > > >> > It sounds as if one of the biggest issues here is with
>> > > > the optical
>> > > > >> > repeaters. If I understand correctly, Sonet repeaters are
>> > > > instrumented so
>> > > > >> > that the administrator can isolate problems without
>> > > > sending out a truck.
>> > > > >> >
>> > > > >> > Consider using a 2-port "LAN" switch instead of a
>> > > > repeater. Switches
>> > > > today
>> > > > >> > provide lots of remote maintenance features, including
>> > > > >> >
>> > > > >> > o Ping (for I'm alive)
>> > > > >> > o SNMP (for tons of performance statistics, and alarms)
>> > > > >> > o Browser management (for ease of use)
>> > > > >> >
>> > > > >> > With a switch, instead of transporting management info
>> > > > on dedicated
>> > > > >> > circuits, use TCP/IP and packets. It's the histroric
>> > > > trend, moving up
>> > > > the
>> > > > >> > protocol stack.
>> > > > >> >
>> > > > >> > Here's a question on a similar vein. Are WDM amplifiers
>> > > > instrumented to
>> > > > >> > isolate BER problems? I thought they did optical
>> > amplification.
>> > > > Capturing
>> > > > >> > BER info sounds tough.
>> > > > >> >
>> > > > >> > Thanks,(signing off)
>> > > > >> >
>> > > > >> > Mark Gerhold
>> > > > >> > Unisys
>> > > > >> >
>> > > > >> >
>> > > > >
>> > > > >
>> > > > >
>> > > > Paul A. Bottorff, Director Switching Architecture
>> > > > Enterprise Solutions Technology Center
>> > > > Nortel Networks, Inc.
>> > > > 4401 Great America Parkway
>> > > > Santa Clara, CA 95052-8185
>> > > > Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
>> > > > email: pbottorf@xxxxxxxxxxxxxxxxxx
>> >
>> > -------------------------------------------------------------
>> > 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
>
>-------------------------------------------------------------
>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
>
>
>
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx