Subject: RE: alarm definitions

From: "Mak, L (Leen)" <[email-masked]>
Date: Fri, 16 Mar 2001 15:48:46 +0100

Just FYI, let me explain some work done in the pre internet 
age. Maybe it helps.

The basic observation is that, from a fault management point
of view, an entity can behave satisfactorily (be in the ok_state), 
or can behave unsatisfactorily (be in the not_ok_state). 
Leaving out some details, we call the transition from the 
ok_state to the not_ok_state: "declaring a failure";
the other way around it is called "clearing the failure".
Between declaration and clearing, the entity has a "fault".
Note that this is just an internal condition of the entity, no-one
knows yet about it.

Now (again leaving out some details) if the entity is configured
to inform the outside world about these things, it will
emit a "notification" for each failure declaration and clearing.
This notification in general carries info about the nature
of the fault and whether the failure was declared or cleared,
and probably some more data.

Usually, such notification will finally cause some form of 
alerting on a display (simple lamp, or nice GUI) or ring a bell. 
This alerting is what is called an "alarm". 

In general, the alarm is on the display as long as the fault exists.
However, sometimes, people want to silence the alarm, even 
before the failure has been cleared. 
In other cases, systems are configured such that the alarm 
will stay on ("latching"), even after the failure has been cleared  
(you would like the burglar alarm to continue to sound, even 
when the intruder very quickly closed the door after he/she 
stepped into the kitchen, wouldn't you?).
In such cases the observer has to tell the display to shut up. 
This is called "acknowledgment".

A basically different form of malfunction is that the entity
burps. Then there is no such thing as declaration and clearing 
of a failure, no fault, there is just an event.
Again, the entity will communicate this to the outside world 
by means of a notification, which contains the info that there 
was a hickup.
This notification will also end up on some display and be shown 
as an alarm. This will remain there until the observer 
acknowledges the alarm.
This may happen a second or an hour or a day after the
hickup occured.

So, an alarm is the presentation to an observer that there is
or was a malfunction, and from these various scenarios it is 
clear that the alarm is and should be distinguished from the 
events and/or conditions causing the alarm.

BTW, in the same project we concluded that carrying strings 
indicating faulttypes over management interfaces is not
a very good idea.
We used integers, and the displaying machines used 
a lookup table to find the correct string. This is very handy
if the users of the system want the strings in another
language.

Leen.

> -----Original Message-----
> From: Ayers, Mike [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 2:10
> To: 'Rutt, T E (Tom)'; [email-masked]; 'Tammy Ferris'
> Subject: RE: alarm definitions
> 
> 
> 
> 
> > From: Rutt, T E (Tom) [mailto:[email-masked]]
> > 
> > Tammy Ferris writes
> > 
> > >All,
> > In reviewing the alarm definition in the Alarm MIB and also 
> > used in the ITU
> > Alarm MIB, I had the following questions/comments/conerns:
> > 1)	The current definition of Fault is:  Lasting error or warning
> > condition.  I am uncomfortable with the word lasting.  A 
> > fault need not be
> > persistent and it is not clear what is meant by lasting.  
> > X.733 defines a
> > Fault as the cause of a malfunction which may be manifest by 
> > errors.  I
> > interpret a fault to be the root cause of possibly many 
> > symptoms using the
> > X.733 definition.
> > ---------------
> > 
> > I agree.   The definition of fault should be as tammy states. 
> >  This does not
> > change anything
> > in the MIB.
> > 
> > The definition of alarm is not that important, but I tend to 
> > think we can
> > relate it to "potential
> > fault indication" or something like that.  Maybe we just can let the
> > definition be loose.
> 
> 	Awww, for Pete's sake!
> 
> 	The definiton of "alarm" is the only thing that matters 
> here!  It's
> the thing we're trying to model!  All these definitions were 
> brought about
> in an effort to clarify the difference between "alarm" and 
> "notification",
> which is thus:  notifications represent instantaneous things, 
> and alarms
> represent things which have a duration.  All the other definitions of
> events, faults, etc. can (and should, given the confusion 
> that they have
> generated just within this group) be discarded.
> 
> > I  generally like the Dave Perkins mib, but I note He is also 
> > using the
> > integer probable
> > cause, like the Nortel MIB
> > 
> >    SnmpItuAlarmProbCause ::= TEXTUAL-CONVENTION 
> >        STATUS      current 
> >        DESCRIPTION "The probable cause of the alarm as 
> >                    specified in [X.733] and [X.736]. 
> >                    <expand this>" 
> >        SYNTAX      INTEGER { 
> >                    other (1), 
> >                    adapterError (2), 
> >                    applicationSubsystemFailure (3), 
> > 
> > I think this is problematic.  Either use a string, or an 
> > ObjectIdentifier,
> > for greater flexibility
> > is needed than can be offered by named numbers hard coded in the
> > specification of the MIB.
> 
> 	OID: maybe
> 
> 	String: NO NO NO NO NO!  I don't even want to think 
> about all the
> hullabaloo over whether they're case sensitive strings or 
> not, what encoding
> we use, whether a tab character is differentiated from a 
> space, etc.  There
> is no need for this much flexibility.
> 
> 	Also, if we want to sort (and ARC) on severity, integer 
> is the best
> way to go.  I was thinking about this recently, and I'd like to have:
> 
> 	clear:           0
> 	informational:  25
> 	indeterminate:  50
> 	warning:       100
> 	minor:         150
> 	major:         200
> 	critical:      250
> 
> 	this would permit (non-ITU) users to choose appropriate 
> numbers for
> finer-grained severity levels while still being amenable to a 
> simple sort
> for severity ranking and single compare for ARC filtering.  
> Sound good?
> 
> > Look forward to talking about this at the meeting.
> 
> 	Ouch.  I won't be there.  Someone carry the fight there for me,
> please.
> 
> 	;-)
> 
> 
> /|/|ike
>

---

From: arif <[email-masked]>
Date: Fri, 16 Mar 2001 22:24:11 +0530

Hi,

Please look for <arif> inline.

> and probably some more data.

<arif>

This is fine. Details of the alarms are sent in the notifications.
I have two questions

a) What  are these details ?
b) Is it possible to define a set of 'must have' details or 'should have'
details, common to all notifications that signify alarms ?

> by means of a notification, which contains the info that there

<arif>

This is also fine. 'minor' alarms or plain non alarming events are also sent
out as notifications.

The same two questions apply.

> events and/or conditions causing the alarm.

<arif>

Is it not, then , possible for us to combine the two cases above, and
conclude that some event was being signalled by the notifications, and
comparisions with a pre-defined set of events gave us an idea of whether or
not this event is alarming, and if so to what degree. If such is the case,
then it may not really be possible to delink alarms for their basic events -
what can be debated is the nature of notifications signalling the alarm, and
the amount and form of the information contiained therein.

> if the users of the system want the strings in another

<arif>

I agree. The only point that is hidden here is that we will have to define a
pre-determined set of alarms( and, by inference, their basic events causing
them) . The point I'm trying to make is that events are notified, some of
them are alarms, some burps, some pleseant happenings, and therefore alarms
can best be represented by the basic events that cause them - we really
cannot seperate alarms from their root events.

Thanks,
Airf