Subject: making AlarmModel more explicit

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 14:26:21 -0700 (PDT)

Hi -

As a technical contributor, for the sake of discussion I'd like to
suggest thinking about slightly different approach to the problem
of making the alarm models more explicit.

First, a slightly different information flow would eliminate
any "specialness" from the processing of the alarmActive/Clear
notifications, and allow the alarm processing module to be
built from the same components (including access control)
as one would need to support logging.

                 (internal)
                notification
                  stream
                     |             alarmActiveState / alarmClearState
                     |<-----------------------------------------------+
                     |                                                |
  +------------------V-------------+                                  |
  |                  |             |                                  |
  |  +---------------V----------+  |                                  |
  |  |         RFC 2573         |  |                                  |
  |  |     SNMP-TARGET-MIB      |  |                                  |
  |  +---+------+-------------+-+  |   +----------------------------+ |
  |      |      |             |    |   |  +------------------+      | |
  |      V      |             +-------->--> Alarm Modelling  |      | |
  |  +-------+  |                  |   |  | (descriptions)   |      | |
  |  |  Log  |  |                  |   |  +--------+---------+      | |
  |  |  MIB  |  |                  |   |           |                | |
  |  +-------+  |                  |   |  +--------V------------+   | |
  |             |                  |   |  | Generic: Model-     |   | |
  |             |                  |   |  | Active : Specific   |   | |
  |  +----------V---------------+  |   |  | Alarms : Extensions |   | |
  |  |         RFC 2573         |  |   |  +---------------------+   | |
  |  | SNMP-NOTIFICATION-MIB    |  |   |           |                | |
  |  +----------+---------------+  |   |           +------------------+
  |             |                  |   +----------------------------+
  +-------------|------------------+
                |
                V
          "wire" notifications

Secondly, I'd suggest a slightly different way of handling the
"alarm modeling".  Although this may seem more elaborate than
the current i-d, I think it has the advantage of requiring
no magic at all.

The current alarmModelTable I would replace with three
tables: AlarmKind, AlarmKindStates, and AlarmKindPatterns.
Each entry in AlarmKind identifies a particular alarm type
that is of interest.  The set of entries in AlarmKindStates
corresponding to a particular entry in AlarmKind defines all of
the states in that particular alarm's FSM.  AlarmKindPatterns
defines the patterns of interest in the notification stream.
A particular notification may cause any number of patterns
to "fire".  The indexing structure associates patterns
with the defined states for the various defined alarm
types. Each pattern definition includes rules for extracting
instance identification information from the notification.
When a pattern associated with a particular alarm kind in a
particular state for a particular resource fires, either an
existing active alarm will be transitioned to a new state,
or if appropriate, a new active alarm will be created.

AlarmKind ---+---> AlarmKindState ----+---> AlarmKindPattern
             +---> AlarmKindState     +---> AlarmKindPattern
             +---> ...                +---> ...

A particular active alarm could be matched back to its
AlarmKind and AlarmKindState.  Given an AlarmKind and
AlarmKindState, one could consult the AlarmKindPatterns
to figure out the possibilities for the next transition.

A sketch:

AlarmKind[Owner, AlarmKind]
        - RowStatus, StorageType
        - description of alarm for humans
        - +/- enabled (this kind of alarm)
        - +/- notify on raise 
        - +/- notify on clear 
        - an entry in this table describes a particular kind
          of alarm that is being modeled.

AlarmKindStates[Owner, AlarmKind, StateNumber]
        - description of particular node in alarm's state machine
        - RowStatus, StorageType
        - +/- notify on entering this state
        - +/- notify on leaving this state

(Having both the AlarmKind and AlarmKindStates notification enablers
is overkill.  I think just having the enables on AlarmKind is sufficient,
but folks interested in escalation might argue otherwise.)

AlarmKindPatterns[Owner, AlarmKind, StateNumber, PatternNumber]
        - entries in this table describe the patterns in the
          notification stream that can trigger state transitions
          for the various kinds of alarms that are of interest.
          When a notification matches the pattern described in
          an entry in this table, the resource identification
          information is extracted (see below), and if an Active
          Alarm of this AlarmKind for the identified resource
          exists and its sate matches StateNumber, then the
          active alarm will be transitioned to "nextState".

          If StateNumber is 0 (reserved for "clear"), a match
          will cause creation of a new active alarm of this
          kind for the extracted resource id.

        - Notification OID matching rule
        - varbind matching
                - if any varbind is in subtree of given oid
                  (0.0 means don't care)
        - resource id extraction use context from notification,
          and define a small number of objects
          to control choice of:
                - spliced object id: extract index part of
                  varbind name (subtree of given OID), tack
                  onto another oid base.
                - object id if varbind is in subtree of given oid
                  (this is special case of previous one)
                - object id of resource specified in model
                - value of a matching varbind (of type oid)
                - etc.
        - nextState, 0 for clear
        - RowStatus, StorageType

What are important differences from current id?
   1) explicit rules for resource id extraction, part of
      notification pattern matching
   2) permits multiple notification types to trigger
      a given transition in state machine
   3) varbind processing is *not* positional

This model permits powerful extensions with relatively little
effort.  For example, aging, escalation, and supplemental varbinds
would all be done with simple extensions of these tables.

Just a (lengthy) thought.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Apr 2002 15:04:52 -0700

HI,

Randy - thanks for the assistance. More comments on it after I've read
through it thoroughly.  

Just a few now...
1) this, like the previous one seems to want to use the existing
   notification mechanisms. However, there are problems, because
   some notification definitions require that the code that
   internally generates calls to the API to the SNMP engine to
   distribute the notification MUST rate-limit the calls to the
   API. If so, you may not see all alarms (you don't see the
   raise), and more importantly you don't see the clear.
2) the picture below (I believe) incorrect in describing the flow
   from the engine API. The notification table from the
   notification MIB module is first consulted, not the targets
   table from the target MIB module. Not sure that the notification
   log MIB module fits where you have placed it. So, not sure
   that all of the plumbing results in water with pressure where
   you want it instead of water on the floor.

                 (internal)
                notification
                  stream
     internal API to |<-----------------------------------------------+
       SNMP engine -\|                                                |

3) It sort of seemed to me that if this system was to use the
   existing notification stream, that the system would convert
   existing notifications to new notifications that were 
   "alarm reports". And if one was to follow the ITU module,
   then the 10s of IETF notifications and 100s of vendor
   notifications would be converted to one the four ITU
   alarm reports (ignoring the security ones for now).
   (For example, a potential linkDown would be converted
   into a "communicationsAlarm notification" and it sent
   out, and not the linkDown notification. If so, how is
   this done? Otherwise, on alarms a manager would receive
   the original notification and the alarm notification
   (if these were not filtered by the notification
    filters specified in RFC 2573.)
 
Regards,
/david t. perkins