RE: Long distance links
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
>
>