Re: Long distance links
Rich:
I must both agree and disagree with you.
My own personal leaning is towards the traditional Ethernet approach but the
HSSG has not really finished defining its goals and no goal decided upon to
date excludes Paul's proposal.
From the very first call for interest there has been discussion of taking
Ethernet into the WAN.
What has been lacking in the debate is a short concise definition of the
requirements for Ethernet into the WAN. We might well decide to exclude support
for SONET for a host of good reasons, but no such decision has yet been made.
We might set for ourselves the goal that not one pint of Yorkshire beer will be
consumed by any member HSSG until we settle the speed issue!! :-))
Bruce Tolley
Manager, Business Development
3Com Corporation
Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx> on 08/31/99 11:04:39 AM
Please respond to rtaborek@xxxxxxxxxxxxxxxx
Sent by: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
cc: (Bruce Tolley/HQ/3Com)
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