Subject: Re: question regarding RFC2558

From: "C. M. Heard" <[email-masked]>
Date: Tue, 7 Nov 2000 11:35:15 -0800 (PST)

On Tue, 31 Oct 2000, Ray Reno wrote:
>
>I am an engineer currently writing a driver for a SONET/SDH interface and
>I am implementing RFC2558 as a part of that.
>
>I was hoping that you could answer a quick question for me regarding the
>'sonetXXXXXXXCurrentStatus' objects (sonetSectionCurrentStatus,
>sonetPathCurrentStatus, etc.).  Are these status fields intended to
>represent pure defects (which can change in a fraction of a second), or on
>an integrated defect (for instance, a failure as defined by ANSI
>T1.231-1997 which would change only over the course of multiple
>seconds)?  The reason I ask is that RFC2558 makes a clear correlation
>between the state of the 'sonetXXXXXXXCurrentStatus' fields and the
>ifOperStatus objects of the ifTable.
>
>So, is the associated ifOperStatus supposed to be allowed to (in a worst
>case scenario) change multiple times per second, or am I misinterpreting
>the definition of the current status objects as being pure defects when
>they really are integrated defects?

On Tue, 31 Oct 2000, Kaj Tesink replied:
>
> the preamble of the mib definition makes a terminology distinction between
> defects and failures (see e.g., LOS, LOF definitions), and the mib objects
> are defined in terms of defects. so in the terminology you use above i'd
> conclude that the objects reflect defects and not integrated defects.

I agree with this interpretation:  when polled, the xxxCurrentStatus objects
should return some approximation of the current value of each defect.

This is usually not too hard to do if the agent resides on the same machine
as the line interface devices.  In that case the device driver can provide
a call that the agent can use to retrieve the current defect values from
hardware registers or from variables that are updated by an interrupt
service routine (or even by periodic polling).

The job becomes more difficult if, as is the case in a typical SONET NE,
the agent lives on one card, e.g., a shelf controller but the line
interface devices reside elsewhere, e.g., on a line card.  In the case
the agent faces some difficult choices.  One would be to poll the line
card to get the most current status.  Another would be to use a "cached"
value obtained by periodically polling the line card.  The latter will
often cause sounds of dismay but from a practical perspective it does not
make much dufference -- after all, the value may be stale anyway one it
gets to the NMS, thanks to polling delays.

In retrospect it probably would have been better to have made these objects
report failure conditions instead of defects.  The currently standardized
SNMP stuff in RFC2558 and in RFC2863 does not cover SONET failures, which
are very important to many network operators.

Mike