RE: Long distance links
Just as a point of information, with 8B/10B code, a bit error will almost
always be detected within a few bytes and will always be detected within a
packet in real time.
1600 BYTES * 10 Bits / 10 gigabits per second = 1.6 microseconds (worst
case!).
Even without 8B/10B, the CRC will do the job if it is watched. If scrambled,
checking on the fly should not be a problem either.
It seems that we are getting caught on nits.
If what is really being requested is that 10 Gig transceivers support analog
sniffing of the receive signal to determine quality of signal, then please
just say so.
jonathan
p.s. By the way, can everyone stop beating their chests about how reliable
the telephone networks are. I am personally not ready to worship at the
alter of SONET. I have my own religion -- thank you very much. My personal
experience and perception is that my networks (sans software problems) have
been far more reliable than my telephone. My network has never switched my
connection over to another line mid-stream in the "conversation." I have
never had to hit the redial button on my computer because my home number "is
not in service." I have never had to redial a connection because of excess
noise. I have never "heard" other conversations leaking through to mine and
not allowing me the satisfaction of disturbing theirs also. Shall I go on???
Yes, I have seen the statistics published by my provider. According to the
stats, I am the only one who ever had a problem and most of them I didn't
really have!
I know of systems that have run for many years at gigabit speeds without a
single bit flip!
Please, please, please, let's get to the requirments!!! Please. Specific,
concise, requirements. Please. jt
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxx]
> Sent: Monday, August 30, 1999 9:45 PM
> To: Brian MacLeod
> Cc: HSSG
> 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
> > >> >
> > >> >
> > >
>