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