Subject: Examples and Potential Delta for Alarm & ITU Alarm MIBs

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 9 Mar 2001 08:22:50 -0500

hi

We've seen lots of discussion on the mailing list in the last
couple of weeks in the form of potential new requirements and
general feedback.  As a result of all that discussion, we propose
the following changes, mostly to the Alarm MIB, put there is 
also one potential change for the ITU Alarm MIB.

We've also included several examples of defining alarms, which
should hopefully better demonstrate how this MIB(s) can be
used to do alarm management in different situations. 

If these changes make sense, we'd like to use them in our 
discussions in Minneapolis.

So far there has only been one reply to the requirements and
compliance matrix.  It would be good to get some more discussion
going on that, so, as Randy said, we can focus in on the bits
we don't agree on in Minneapolis.

Suggested Changes
----------------

1) Rename alarmDetailsType to be alarmDetailsState to more descriptive, 
   include more states and make it an index into the table.  This ties
   the individual states into a cohesive alarm and also greatly 
   simplifies the M:N mapping.  We can also remove the extra OID
   object of alarmDetailsClearNotification as well as
   ituAlarmPerceivedSeverity.

alarmDetailsTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF AlarmDetailsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of information about possible alarms on the system."
    ::= { alarmDetails 2 }

alarmDetailsEntry OBJECT-TYPE
    SYNTAX      AlarmDetailsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Entries appear in this table for each possible alarm."
    INDEX       { alarmListName, alarmDetailsIndex, alarmDetailsState }
    ::= { alarmDetailsTable 1 }   
    
AlarmDetailsEntry ::= SEQUENCE {
    alarmDetailsIndex                 Unsigned32,  
    alarmDetailsState                 INTEGER,       
    alarmDetailsNotificationId        OBJECT IDENTIFIER,     
    alarmDetailsModelPointer          RowPointer,
    alarmDetailsRowStatus             RowStatus
    }

...

alarmDetailsState OBJECT-TYPE
    SYNTAX  INTEGER 
			{
            cleared (1),
            indeterminate (2),
            critical (3),
            major (4),
            minor (5),
            warning (6)
            } 	
    MAX-ACCESS	read-only
    STATUS       current                   
    DESCRIPTION
             "The possible states that an alarm can be in." 
     ::= { alarmDetails 2 }    

2) To better support the examples 3 and 4, we suggest the addition of
   the following definitions

2.1) Active Alarm instance identifier
	  
  One possibility:
  alarmActiveEntity    OBJECT-TYPE
    SYNTAX      PhysicalIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "This object is the same as entPhysicalIndex"
    ::= { alarmActiveEntry xx }  

2.2) Generic Alarm Notifications

   alarmRaise NOTIFICATION-TYPE
       OBJECTS     { alarmDetailsIndex,
		     alarmDetailsState,
                     alarmActiveEntity }
       STATUS      current
       DESCRIPTION "An instance of the alarm indicated by alarmDetailsIndex 
		   has been raised against the entity indicated by

               alarmActiveEntity."
       ::= { alarmNotifications 0 1 }

   alarmClear NOTIFICATION-TYPE
       OBJECTS     { alarmDetailsIndex,
                     alarmActiveEntity }
       STATUS      current
       DESCRIPTION "An instance of the alarm indicated by alarmDetailsIndex 
		   has been cleared against the entity indicated by
               alarmActiveEntity."
       ::= { alarmNotifications 0 2 }

Examples
--------

Overview:
1) Alarms based on notifications (1:1 mapping)
2) Alarms based on notifications (M:N mapping)
3) Alarms without notifications, but that still want
   to send out a notification
4) Alarms without notifications that don't want to
   send out notifications

1) Alarms based on notifications (1:1 mapping)

    alarmDetailsIndex                  3
    alarmDetailsState                  warning (6)
    alarmDetailsNotificationId         1.3.6.1.6.3.1.1.5.3
    alarmDetailsModelPointer           ituAlarmEntry.3
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  communicationsAlarm (2)
    ituAlarmProbableCause              cableTamper(61)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  3
    alarmDetailsState                  cleared (1)
    alarmDetailsNotificationId         1.3.6.1.6.3.1.1.5.4
    alarmDetailsModelPointer           ituAlarmEntry.4
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  communicationsAlarm (2)
    ituAlarmProbableCause              cableTamper(61)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

2) Alarms based on notifications (M:N)

   Assume 4 traps.
   acmeWidgetTemperatureNormal acme.traps.1
   acmeWidgetTemperatureMinor  acme.traps.2
   acmeWidgetTemperatureMajor  acme.traps.3
   acmeWidgetTemperatureCritical acme.traps.4

    alarmDetailsIndex                  4
    alarmDetailsState		         cleared (1)
    alarmDetailsNotificationId         acme.traps.1
    alarmDetailsModelPointer           ituAlarmEntry.5
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  4
    alarmDetailsState		         minor (5)
    alarmDetailsNotificationId         acme.traps.2
    alarmDetailsModelPointer           ituAlarmEntry.6
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  4
    alarmDetaisState		         major (4)
    alarmDetailsNotificationId         acme.traps.3
    alarmDetailsModelPointer           ituAlarmEntry.7
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  4
    alarmDetailsState			   critical (3)
    alarmDetailsNotificationId         acme.traps.4
    alarmDetailsModelPointer           ituAlarmEntry.8
    alarmDetailsRowStatus              active (1)
    ituAlarmEventState                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

3) Alarms without notifications, but that still want
   to send out a notification

   Don't assume 4 traps.
   acmeWidgetTemperatureNormal acme.traps.1
   acmeWidgetTemperatureMinor  acme.traps.2
   acmeWidgetTemperatureMajor  acme.traps.3
   acmeWidgetTemperatureCritical acme.traps.4

    alarmDetailsIndex                  5
    alarmDetailsState			   cleared (1)
    alarmDetailsNotificationId         alarmNotifications.0.2
    alarmDetailsModelPointer           ituAlarmEntry.9
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  5
    alarmDetailsState			   minor (5)
    alarmDetailsNotificationId         alarmNotifications.0.1
    alarmDetailsModelPointer           ituAlarmEntry.10
    alarmDetailsRowStatus              active (1)
    ituAlarmEventState                 environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  5
    alarmDetailsState		         major (4)
    alarmDetailsNotificationId         alarmNotifications.0.1
    alarmDetailsModelPointer           ituAlarmEntry.11
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  5
    alarmDetailsState                  critical (3)
    alarmDetailsNotificationId         alarmNotifications.0.1
    alarmDetailsModelPointer           ituAlarmEntry.12
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

4) Alarms without notifications that don't want to
   send out notifications

   Don't assume 4 traps.
   acmeWidgetTemperatureNormal acme.traps.1
   acmeWidgetTemperatureMinor  acme.traps.2
   acmeWidgetTemperatureMajor  acme.traps.3
   acmeWidgetTemperatureCritical acme.traps.4

    alarmDetailsIndex                  6
    alarmDetailsState		         cleared (1)
    alarmDetailsNotificationId         0.0
    alarmDetailsModelPointer           ituAlarmEntry.13
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  6
    alarmDetailsState                  minor (5)
    alarmDetailsNotificationId         0.0
    alarmDetailsModelPointer           ituAlarmEntry.14
    alarmDetailsRowStatus              active (1)
    ituAlarmEventState                 environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmPerceivedSeverity          minor (5)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  6
    alarmDetailsState		         major (4)
    alarmDetailsNotificationId         0.0
    alarmDetailsModelPointer           ituAlarmEntry.15
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  6
    alarmDetailsState                  critical (3)
    alarmDetailsNotificationId         0.0
    alarmDetailsModelPointer           ituAlarmEntry.8
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  environmentalAlarm (6)
    ituAlarmProbableCause              equipmentMalfunction (16)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2001 15:26:25 +0100

>>>>> Sharon Chisholm writes:

Sharon> We've seen lots of discussion on the mailing list in the last
Sharon> couple of weeks in the form of potential new requirements and
Sharon> general feedback.  As a result of all that discussion, we
Sharon> propose the following changes, mostly to the Alarm MIB, put
Sharon> there is also one potential change for the ITU Alarm MIB.

I am confused.

The alarmDetailsTable is used in <draft-ietf-disman-alarm-mib-01.txt>
as "a table of information about possible alarms on the system." Now
you want to have an alarmDetailsState in there, which is in my view an
attribute of a concrete instance of an alarm. Or do you propose to
have entries for all possible states just in case you need to point to
such an entry? In fact, I believe the name "alarmDetailsTable" is a
confusing name in <draft-ietf-disman-alarm-mib-01.txt>. (But perhaps I
am just mis-understanding the document?)

What precisely is the relationship between the alarmDetailsTable and
the alarmActiveTable table? And why do both tables have an
alarmActiveModelPointer? Can they be different? And if the ituAlarm*
objects are so useful for all the examples, why do we not put them
into the alarm MIB tables right away? There are already "don't care"
defaults (zeroDotZero) and we can always use the compliance statements
to indicate the subset of objects that are required for compliance.

I think it would be really helpful to draw UML diagrams for the
various proposals in order to compare them. I tried to do so (since we
have tools to semi-automatically generate UML diagrams from MIBs) but
I was not able to cleanup things as I am obviously lacking some
understanding how things are supposed to work together.

If you can't do a diagram, can you perhaps expand the examples so that
they show the instance identifiers for the variables? Can you add all
the additional details that are needed to represent a concrete
instance of an active alarm? This might help me to get the big picture
which I am obviously missing.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Frank Strauss <[email-masked]>
Date: 12 Mar 2001 10:40:10 +0100

Hi!

Sharon> [...]
Sharon> alarmDetailsState OBJECT-TYPE
Sharon>     SYNTAX  INTEGER 
Sharon> 			{
Sharon>             cleared (1),
Sharon>             indeterminate (2),
Sharon>             critical (3),
Sharon>             major (4),
Sharon>             minor (5),
Sharon>             warning (6)
Sharon>             } 	
Sharon> [...]

Sharon>    Assume 4 traps.
Sharon>    acmeWidgetTemperatureNormal acme.traps.1
Sharon>    acmeWidgetTemperatureMinor  acme.traps.2
Sharon>    acmeWidgetTemperatureMajor  acme.traps.3
Sharon>    acmeWidgetTemperatureCritical acme.traps.4

Sharon>     alarmDetailsIndex                  4
Sharon>     alarmDetailsState		         cleared (1)
Sharon>     alarmDetailsNotificationId         acme.traps.1
Sharon> [...]

Sharon>     alarmDetailsIndex                  4
Sharon>     alarmDetailsState		         minor (5)
Sharon>     alarmDetailsNotificationId         acme.traps.2
Sharon> [...]

Sharon>     alarmDetailsIndex                  4
Sharon>     alarmDetaisState		         major (4)
Sharon>     alarmDetailsNotificationId         acme.traps.3
Sharon> [...]

Sharon>     alarmDetailsIndex                  4
Sharon>     alarmDetailsState			   critical (3)
Sharon>     alarmDetailsNotificationId         acme.traps.4
Sharon> [...]

Sorry, I have some more doubts about your `favorite example'. ;-)

You are mapping a group individual notifications that have rather
individual characteristics to the values of an enumeration type that
is defined in the Alarm MIB, right?

I think this not a good idea.

Furthermore, I think it would not be the appropriate MIB design to
define the four notifications of your example in a MIB module. Usually,
you would have only one notification definition and an object
assigned to that notification that denotes the current state (in this
example the temperature value).

Hence, it's not appropriate to build your example on an untypical
basis.  Maybe, there are real examples from standard MIBs that are
more appropriate.

 -frank