Re: Long distance links
Roy and All,
As many of you know, I've been heavily involved with using Gigabit Ethernet
in MAN applications supporting voice, video and data. Several of these
systems are mixed at the media level in that there is dark fiber leased from
another entity connecting to fiber and copper in buildings and campuses.
Roy's OAMP comments on leasing dark fiber caused my radar to go up as I
expected to learn new things that I have not yet encountered in the MAN. So
far, I'm still confused as we don't seem to have a clear understanding of
the issues. With Roy's experience, I'm sure there are some things I'm just
"not getting". If I fly a trial balloon, perhaps we can come to grips with
the details.
In my view, we have an originating LAN (may be building or campus) connected
to dark fiber that is leased from someone, in turn connected to a second
LAN:
<----------------> <------------------------------------------->
<------------------------>
LAN A X Leased Dark Fiber Y LAN B
Clearly, in the all-Ethernet case, points X and Y have switches in place and
the LANs could be a different medium from the leased fiber.
Now if you are leasing fiber that may stretch for many miles, there are
probably lots of splice points along the way. However, when you spec the
contract and during the acceptance phase, you will specify the loss budget
and verify the fusing of the link with an OTDR. Once you are in service,
you will have no other entity running on your fiber pair(s) so you have
clear visibility of link performance just like you were connected to the
switch down the hall. If a fiber/cable fault occurs, you would presumably
call the owner of the fiber who will locate the fault and fix it for you.
Degradation over time of fiber, lasers or detectors would be factored into
the link design budget. Control of the launch and receiving equipment
remains with the organization leasing the fiber (this is dark fiber not a
lit service). The latter point usually remains true even if we have several
concatenated links such as might occur when connecting many schools in a
district.
OK, there's my simplistic (but practical) model. Will the more
knowledgeable members extrapolate to cases where this will not work and also
pick holes in this model.
thanks in advance
Brian MacLeod
Project 101, Inc.
PO Box 14347
Spokane WA 99214-0347
Tel 509-892-6955
Fax 509-892-6955 (automatic)
>
>-----Original Message-----
>From: Roy Bynum <rabynum@xxxxxxxxxxx>
>To: Brian MacLeod <bmacleod@xxxxxxx>
>Cc: HSSG <stds-802-3-hssg@xxxxxxxx>
>Date: Monday, August 30, 1999 8:47 PM
>Subject: Re: Long distance links
>
>
>>Brian,
>>
>>There is a misconception that it takes 50 milliseconds to detect a failure
>in
>>the telecom industry. The 50 milliseconds is the amount of time the
>telecom
>>industry requires the transmission system to correct for the failure. The
>>actual amount of time that it takes to detect the failure can be less than
>a
>>microsecond, bounded by the speed of light. I have seen a SONET OC192
>system
>>switch traffic from a cut fiber to an operational fiber in 6 milliseconds.
>You
>>can imagine the reliability of applications running over such a data
>network.
>>
>>Thank you,
>>Roy Bynum
>>MCI WorldCom
>>
>>Brian MacLeod wrote:
>>
>>> Rohit,
>>>
>>> Please be aware that there are currently Gigabit Ethernet products in
the
>>> market that can detect a link failure in several microseconds. Of
course
>>> detection is different from "management resolution" such as the opening
>of
>>> an alternative path. However, this is at least three orders of
magnitude
>>> less than the telecom industry goal of 50 milliseconds. Smart silicon
>and
>>> software engineers should be able to do lots with that :-)
>>>
>>> Brian MacLeod
>>>
>>> -----Original Message-----
>>> From: Rohit Mittal <mittal.rohit@xxxxxxxxxxx>
>>> To: rtaborek@xxxxxxxxxxxxxxxx <rtaborek@xxxxxxxxxxxxxxxx>
>>> Cc: HSSG <stds-802-3-hssg@xxxxxxxx>
>>> Date: Monday, August 30, 1999 2:34 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
>>> >> >
>>> >> >
>>> >
>>
>