Re: Long distance links
Bruce,
Why are you assuming that there is always TCP/IP? Also, if voice over IP (VOI) is
ever to become reliable, 50ms restoration is a major plus. Wouldn't your customers
like, and be willing to pay for reliable voice services over their enterprise data
networks, without the need for ATM?
Thank you
Roy Bynum
MCI WorldCom
Bruce_Tolley@xxxxxxxx wrote:
> Rohit:
>
> If we assume that all the traffic over the WAN link is data and TCP/IP, why do
> we need 50 ms for signal restoration?
>
> This requirement makes sense for voice TDM traffic but not for data. Am I
> missing something?
>
> Bruce Tolley
> Manager, Business Development
> 3Com Corp.
>
> Rohit Mittal <mittal.rohit@xxxxxxxxxxx> on 08/30/99 01:17:33 PM
>
> Sent by: Rohit Mittal <mittal.rohit@xxxxxxxxxxx>
>
> To: rtaborek@xxxxxxxxxxxxxxxx
> cc: HSSG <stds-802-3-hssg@xxxxxxxx> (Bruce Tolley/HQ/3Com)
> 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
> > >
> > >