Re: Please help to clarify some things!
Rich,
If the methodology that is used for Ethernet is less expensive, why has the telephony
industry not implemented it? Could it be that the inband nature of IP based SNMP
network management on a particular link introduces more problems than it solves. SNMP
uses UDP, not TCP so it is an unreliable information delivery system. Could it be
that the unreliable delivery of alarm and fault information is considered unreliable.
If you have done any research, you would know that IP based out of band network
management for telephony systems is based on TCP, UDP. TL1 over IP uses TCP.
Ethernet does not gather any information at the optical level. The lowest common
denominator for Ethernet network management is the "frame" not the optical path or
signal. As such, any SNMP management system that is dependent on Ethernet as it is
currently implemented does not have visibility to the optical level, not even
indirectly.
Thank you,
Roy Bynum
MCI WorldCom
Rich Taborek wrote:
> Roy Bynum wrote:
>
> > Mick,
> >
> > The splice points are just physical joinings of the fiber. The problem is that
> > they can be inconsistent to the point of effecting the functionality of the data
> > transmission. They can also be effected by people messing with them in the
> > process of working on the fiber cable. As a cable degrades or is damaged the
> > link level may fail to the point of not being able to use "ping", yet the remote
> > status information can inform you of whether the problem is in both directions
> > of the traffic, or just one, and which one. A ping can not tell you if the link
> > failed in one direction only. As a transmission laser starts to fail, the remote
> > system returning its receive status information can cause an allert/trap against
> > the local system, even though the problem was seen on the remote system.
>
> Roy,
>
> Ethernet is at capable as SONET, at detecting the same conditions. Management
> protocols above Ethernet are, in general, more capable of assisting service
> personnel in maintaining links. I see no SONET advantage here. If anything, the
> Ethernet advantage, once again, is lower cost.
>
> > At present, SNMP can only tell you if there are excessive error frames. It does
> > not have visibility at the optical level.
>
> I believe that SNMP stands for something like Simple Network Management Protocol.
> Ethernet has visibility at the optical level. Ethernet gathers information at the
> optical level and SNMP presents the information for processing by a management
> application. Therefore, SNMP indirectly has visibility at the optical level.
>
> > Having a network management system be
> > able to properly report where the problem is will save a lot of time, effort,
> > and expensive support people in the process of resolving the problem. Part of
> > what I am recommending is adding to SNMP the visibility to the optical level.
>
> Too late.
>
> > Thank you,
> > Roy Bynum
> > MCI WorldCom
> >
> > Mick Seaman wrote:
> >
> > > Roy,
> > >
> > > I'm sorry, I feel you are repeating "full duplex 10Gb 802.3 is in need of
> > > protocol
> > > level operations support functionality" but not adding to my understanding
> > > of why at all. I am probably not alone.
> > >
> > > Can we be more specific about those things that the functionality you
> > > propose will enable us to diagnose that can not be accomplished by
> > > collecting data in the systems attached to the Gigabit MAC and then sharing
> > > that data or responding to queries using that MAC to transmit and receive.
> > >
> > > Is it possible to see or manage the splice points you refer to using an
> > > embedded protocol? I thought they were just physical splice points and that
> > > none of the protocols you were discussing contained embedded OTDR. So the
> > > only thing that would help me to manage these would be better insight into
> > > BER or 'physical' level signal conditioning at the end stations. Why can't I
> > > get at the information provided by this using SNMP, or check connectivity
> > > using 'ping' etc. etc. What is there here that needs support in the MAC? It
> > > may be that the world needs better management protocols but why is that a
> > > subject for HSSG discussion?
> > >
> > > Mick
> > >
> > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy Bynum
> > > Sent: Sunday, August 29, 1999 10:24 PM
> > > To: Henry Ngai
> > > Cc: stds-802-3-hssg@xxxxxxxx
> > > Subject: Re: Please help to clarify some things!
> > >
> > > Henry,
> > >
> > > In your document, your first and second drawings are somewhat correct. I
> > > doubt
> > > that 10GbE would ever be implemented as you are showing it in your third
> > > drawing. In your first drawing, you need to add a fiber plant that has
> > > things
> > > like splice points every 5 km at most, access to the fiber cable by people
> > > that
> > > have nothing to do with your data, and other issues. The traditional 802.3
> > > LAN
> > > environment was outgrown when full duplex 802.3 over optical transport was
> > > standardized. It is even possible to take full duplex 100BaseFX over WAN
> > > distances with optical converters that are sold by several different
> > > vendors.
> > > As seen by individuals that are attempting to create manageable enterprise
> > > level data networks with GbE, full duplex 10Gb 802.3 is in need of protocol
> > > level operations support functionality in order to grow to its true
> > > potential.
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------------
> Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
> Principal Architect Fax: 650 940 1898 or 408 374 3645
> Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
> 1029 Corporation Way http://www.transcendata.com
> Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx