Re: Long distance links
In response to your recovery time on cable fault. Can we specify that as a
bridge function using the link status? If a single strand of fible is cut,
link will go down on the receiving end. It can send a management packet to
the repeater at the other end of the link and trigger a re-mapping. May be
link aggregation can do that already.
If both strands were cut at the same time, then both repeaters will
experience link lost and switch to alternate link. Does that solve the
problem?
Henry Ngai
----- Original Message -----
From: Rohit Mittal <mittal.rohit@xxxxxxxxxxx>
To: <rtaborek@xxxxxxxxxxxxxxxx>
Cc: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Monday, August 30, 1999 1:17 PM
Subject: Re: Long distance links
>
> 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?
>
> 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
> > >
> > >
>
>