RE: Long distance links
If my condensing the words: "carrying Ethernet frames on a SONET system" to
"Ethernet over SONET" has offended anyone, my apologies. I really don't care
what we call it. I just want the requirements!
jonathan
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, August 31, 1999 3:01 PM
> To: HSSG
> Subject: Re: Long distance links
>
>
>
> 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. 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.
> 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.
>
> For the same reason, it is ludicrous to speak about 10 GbE
> transporting/carrying
> SONET. In my mind, it is feasible to expand current HSSG
> objectives to include
> the WAN market. It is NOT prudent nor cost effective for the
> HSSG to consider
> carrying Ethernet over SONET. 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.
>
> 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
>
> --
>
> 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
>
>