Subject: disman alarm mib comments

From: Stefan Wallin <[email-masked]>
Date: Wed, 02 Jan 2002 15:39:12 +0100 (CET)

Hi!
Here are some comments to the alarm mib:

**************
* ALARM-MIB  *
**************
============
Alarm States
============
Can an active alarm have different states then active and cleared?

Conceptual model 1:
-------------------
An alarm goes on with a severity, stays in that state/severity until it is 
cleared.
Example:
lifecycle 1: [linkDown, major]->[linkDown, clear]
lifecycle 2: [linkDown, minor]->[linkDown, clear]

Conceptual model 2:
-------------------
An alarm goes on with a severity, the same active alarm can then change 
severity during its lifetime and finally it is cleared.
Example:
lifecycle 1: [linkDown, major]->[linkDown, minor]->[linkDown, clear]

Comments:
---------
Model 1 is easy to implement in managers where the alarm list handles alarms
and cleared alarms, not changed alarms. It is also more easy handled where the 
alarm manager is integrated with a trouble ticket manager. Complex integration 
issues arises where alarms changes states and how trouble tickets then shall be 
handled.

Model 2 is proposed by the 3GPP Alarm Model, (http:/www.3gpp.org). They have 
three generic notifications (CORBA and Q3, not SNMP...), alarmNew, 
alarmChanged, alarmCleared.

It is not really clear which model the Disman Alarm Mib supports/recommends:
the generic traps seems to imply model 1, since there is no changedAlarm 
notification.

Recommendation 1: We should strongly recommend model 1.
---------------------------------------------------------------
Note however that the alarmModelTable still can have several "states"/entries 
for the same problem.
The different entries models an alarm becoming active with different severities.

Recommendation 2: Change name of OBJECT-TYPE alarmModelState to 
alarmModelSeverity
--------------------------------------------------------------------------------
--
Even if we stick to model 2 the alarmModelState OBJECT-TYPE models severity so 
the model
is easier to understand if we use that name.

====================
Notification design
====================

Issue 1a: user friendly information var-bind in traps
------------------------------------------------------
Traps carrying alarm information should fulfill following requirements:
 a) identify object/resource
 b) indicate severity
 c) carry user friendly information so that it can be displayed in real-time
 d) correlate alarm and alarm clear traps

(C) is important since traps are often displayed in real-time in alarm logs and
the user must be able to understand the alarm without chasing OIDs using a MIB 
Browser.
The use of generic alarm traps also increases the requirement for (C) since the 
trap name
does not tell the user what problem it is.

The alarmRaise and alarmClear traps almost fulfill these requirements but c) is 
missing.
There are two existing OBJECT-TYPES that could be used for this purpose:
- alarmModelDescription		(SnmpAdminString)
- ituAlarmAdditionalText        (DisplayString)

Solution 1:
The straightforward solution would be to include alarmModelDescription in the 
traps.
The risk is that the text is a little too "static" and not generated by the 
agent at
the event generation time including important dynamic information from the user.

Solution 2:
ituAlarmAdditionalText is the classical X733 variable used for this purpose.
But we probably do not want to have a dependency to the itu module.
Furthermore it is 7-bit ASCII...

Solution 3: define a new columnar object-type, included in the alarmActiveTable:

alarmInformation OBJECT-TYPE
      SYNTAX     SnmpAdminString
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
          "...."
      ::= { alarmActiveEntry ... }

Proposal for trap var-bind: solution 1.

Issue 1b: user-friendly resource identification
-----------------------------------------------
The reference to the resource emitting the alarm should of course be a valid 
reference
to an object as done in the current alarm MIB. This enables the management 
application
to chase the reference and do "whatever". But again, traps are displayed in 
real-time
for end-users and it is critical for them to quickly identify the resource.

Example: an ifIndex does not tell the typical alarm operator that much...
The alarm should say: "Slot 1, port 17, link is down administratively."

My recommendation is that the user-friendly var-bind above has this information 
embedded.
This requirement must than be expressed in the DESCRIPTION clause of the OBJECT-
TYPE.
This also implies that the information is generated dynamically and therefore 
the alarmModelDescription
in the alarmModelTable does not tell the whole story:

Imagine the following example from the drarft:
   alarmModelIndex                  3
   alarmModelState                  2
   alarmModelNotificationId         linkDown
   alarmModelVarbindIndex           2
   alarmModelVarbindValue           down (2)
   alarmModelDescription            "linkDown administratively"

In the trap we would like to carry the alarmModelDescription.3.2 = "Slot 1, 
port 17, linkDown administratively".
Solution: allow dynamic information to be added in the string prefix, or suffix 
and include this as a
requirement in the DESCRIPTION clause of alarmModelDescription.

Issue 2: index variables in notifications
-----------------------------------------
Notifications should not be carried by traps, see "7.7.  Mapping of the INDEX 
clause", rfc2578.
If we go for Solution 1 above, sending the alarmModelDescription in the traps, 
we would implicit send 
the index variables in the var bind:
alarmModelDescription.<alarmModelIndex>.<alarmModelState> = "Toaster burning"

The definition would be:
alarmRaise NOTIFICATION-TYPE
    OBJECTS     { alarmModelDescription,
                  alarmActiveResourceType,
                  alarmActiveResourceId }
    STATUS      current
    
============================
Notification sequence number
============================
In order for the manager and agent to be synchronized regarding alarms a 
sequence number
mechanism of alarms are useful. Every alarmRaise carries a sequence number 
which also is
stored in the alarmActiveTable.
Why is it useful:

a) It is a useful index for the manager to map its alarms to the ones in 
alarmActiveTable.
b) It can be used as an indicatin of missed alarms if there are wholes in the 
sequence.
(Of course trap filtering makes this not too useful...)

==============================
OBJECT-TYPE descriptions
============================

Below follows some, I hope ;) , improvements on the object descriptions:

alarmModelIndex
----------------
"The alarm model index is the index for a possible
alarm object. To model e.g. link failure, there
will be two entries in the alarmModelTable which
share the same alarmModelIndex; linkUp and linkDown,
but with different alarmModelStates"

alarmModelState
----------------
"A value of 1 MUST indicate a clear alarm state.
The value is an indication of the severity of the
alarm state.  Higher values MUST imply more severe
alarm states.  An example using link failure:
alarmModelindex	alarmModelState
================================
17		1   -- linkDown: clear alarm state 
17		3   -- linkUp

Alignment with the ItuPerceivedSeverity defined in ITU-ALARM-TC is recommended
"

alarmModelVarbindIndex
-----------------------
"The index into the varbind listing of the notification
           indicated by alarmModelNotificationId which helps
           signal that the given alarm has changed state.
           If there is no applicable varbind, the value of this
           object MUST be zero. 
           This must be used if the different states can
           not be separated by individual notification
           types. Imagine a toaster notification:
           toasterProblem(toasterProblemState) where the
           toasterProblemState var bind has the following
           values:
           0 : OK
           1 : toasterJam
           2 : burning

           index  ModelState  ModelNotificationId ModelVarbindIndex
           ========================================================
           77     1           toasterProblem      1
           77     3           toasterProblem      1
           77     5           toasterProblem      1
           This tells the manager that var bind 1 must be
           checked in order to indicate the severity "

alarmModelVarBindValue
----------------------
"The value that the varbind indicated by
        alarmModelVarbindIndex takes to indicate
        that the alarm has entered this state.
        Using the previous toaster example:
        alarmModelVarbindIndex	alarmModelVarbindValue
        ==============================================
        index ModelState ModelNotificationId ModelVarbindIndex ModelVarbindValue
        77    1          toasterProblem      1                 0 -- OK
        77    3          toasterProblem      1                 1 -- jam
        77    5          toasterProblem      1                 2 -- burning
        "

*********************
* ITU-ALARM modules *
*********************

Severity TC
-------------------
What is the motivation for not using the same values as X733?
See below.
I assume one of the reasons is not having 0 as value in the enumerated
since it is not recommended in SMIv1.
Anyhow, I recommend that we reuse the values and possibly move indeterminate(0) 
to
something else.

X733			ITU-ALARM-TC
====================================
indeterminate(0),	cleared (1),
critical(1),		indeterminate (2),
major(2),		critical (3),
minor(3),		major (4),
warning(4),		minor (5),
cleared(5)		warning (6)

ituAlarmAdditionalText 
-------------------------
Change DisplayString to SNMPAdminString.

IANAItuProbableCause 
----------------------
I have serious problems with probable cause both in the old ITU standards and 
now when
applied to SNMP.
The problem is that the definition lacks extensibility. The values in X733 
M3100 etc
are for transmission systems and not useful for modern systems. But since it is 
not
an OID structure it is impossible to extend for new standards and enterprise 
specific values. This has resulted in different vendors just added to the enum, 
which typically implies collisions when integrating several MIBs.

Any thoughts?

Stefan Wallin
Data Ductus AB
+46 70 5233262
[email-masked]