Subject: Updated Alarm MIBs Requirements

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 28 Mar 2001 12:46:44 -0500

hi

I've updated the requirements document to include condition
management and some other recently introduced requirements.
Since the terminology is still in flux, I have not updated
the terms in this document.  For the sake of this document,
assume an alarm is a persistent indication of a problem or
abnormal activity of interest to a manager.  The alarm is 
persistent as long as its underlying problem is occurring.

Compliance Matrix
-----------------
Yes - there is rough consensus that this feature is necessary
Mostly - This requirement contains sub requirements, most of
         which will be met
Maybe - there is some interest in this requirement
No - there is rough consensus that this feature is beyond the
     scope of this work
----------------------------------------------------
Requirement Number | Brief Description | Compliance |
-------------------|-------------------|------------|
1                  | Alarm Definitions | Mostly     |
 1.1               |  ID               |  Yes       |
 1.2               |  What             |  Yes       |
 1.3               |  State            |  Yes       |
 1.4               |  Notification     |  Yes       |
 1.5               |  Where            |  Yes       |
 1.6               |  By Whom          |  Maybe     |
 1.7               |  ITU Info         |  Yes       |
 1.8               |  Map to Trap      |  Yes       |
 1.9               |  Configuration    |  Mostly    |
  1.9.1            |    Non-used Alarm |   Yes      |
  1.9.2            |    Used Alarm     |   Maybe/No |
2.                 | Real-time Alarm   | Mostly     |
  2.1              |   Active          |   Yes      | 
  2.2              |   Suppressed      |   Maybe    |
3.                 | Distributed Alarm | Yes        |
4.                 | Historical Alarm  | Mostly     |
  4.1              |   Active          |   Yes      | 
  4.2              |   Suppressed      |   Maybe    |
5.                 | Suppression       | Maybe      |
 5.1               |  ARC              |  Maybe     |
 5.2               |  By Severity      |  Maybe     |
6.                 | Correlation       | No         |
7.                 | Modular Arch.     | Yes        |
 7.1               |  Scalable         |  Yes       |
 7.2               |  Extensible       |  Yes       |
8.                 | Condition Defns   | Maybe      |
----------------------------------------------------|

1. Alarm Definitions

   1.1 Alarm ID

   A unique identifier for an alarm.  This could be dynamic,
   like a table index or static like a formally managed name
   space.

   1.2 Unambiguously tells you what condition needs attention

   This requirement covers off the elimination of informational
   events, as well as being able to tell exactly what error or
   warning condition this is indicating.

   This requirement can be fulfilled explicitly by defining new
   objects or by exploiting existing notifications where applicable.

   1.3 Clearly defined state and transition mechanism

   As a minimum, alarms states are raise and clear. They could also
   include severity information such as defined by perceived severity
   in the ITU model - cleared, indeterminate, critical, major, minor,
   warning.

   A state transition mechanism is the way that signals that the alarm
   has transitioned from one state to another. This is primarily through
   the detection of a fault, or through the detection that the fault
   is no longer occurring.  It can also be the detection that a fault
   has become more or less severe.
   
   1.4 Means of optionally alerting management station of state transition

   Many implementations will want interested managers to detect a change
   of alarm state in a timely manner.  Some will not.  There should be
   a means of sending a notification to interested managers when an alarm
   transitions state.

   1.5 Unambiguously tells you where the problem is (machine, port, etc)

   Since one of the main goals of alarm management is to ensure that
   any detected problems get fixed, it is necessary to know exactly
   where this problems is occurring. This goes beyond simply
   the box that is experiencing the problem and includes physical
   things like slots and ports and logical things like interfaces.

   This requirement can be fulfilled explicitly by defining new
   objects or by exploiting existing notifications and objects
   where applicable.
 
   1.6 Unambiguously tells you who detected the problem

   This requirement is to be able to tell which sub-system detected
   the problem.

   1.7 Means of obtaining ITU alarm information

   Alarm Information as defined in X.733 and X.736 should be optionally
   available to implementations.

   1.8 Mapping of relationship between alarm and notifications

   It is important to understand the relationship between alarms and
   notifications.  Even if the eventual definition of alarms puts them
   in a completely separate naming space, they can't really be used
   without understanding their relationship to existing notifications.
   At the very least, this is an issue of transitioning and coexistence.

   1.9 Configuration of Alarms

     1.9.1 Dynamic definition/deletion/update of non-used alarms

     Alarm definitions can be added, updated or removed during runtime, 
     assuming no entry in the active alarm table is using it.

     1.9.1 Dynamic updates to instantiated alarms

     In general, this is a requirement to be able to update alarm
     model definitions which have specific instances of that alarm
     instantiated.

     Specifically, this is a requirement for alarm severities to be 
     modifiable during the life of an alarm by either the agent or
     the manager.  In other words, the ability to escalate and
     de-escalate Alarms/Conditions must be supported.

     Alarm severities modified during the life of an
     alarm must take effect immediately and active
     tables updated accordingly.

2. Real-time Alarm Management

   2.1 Active Alarm
   This is a requirement for a list of currently active alarms on
   a system and supporting statistics.

   2.2 Non-alarm and Suppressed Alarms

3. Distributed Alarm Management

   This is a requirement that all aspects of the alarm MIB can be supported
   both on the device experiencing the alarms and on any middle managers
   that might be monitoring such devices.

4. Historical Alarm Management

   This requirement is that information on alarms that are no longer active
   is available. This can take the form of a log of cleared alarms, support
   of the notification log MIB, etc.

   4.1 Alarms
   4.2 Non-alarm and Suppressed Alarms

5. Alarm Suppression 

   The requirement is for a mechanism to not add a particular alarm to the
   active alarm table or to send out the associated SNMP
   notification related to a given alarm state transition under controlled
   conditions.  
      5.1 ITU's Alarm Reporting Control (ARC)
      5.2 Suppression by severity (includes non-alarms)

6. Alarm Correlation

   This is a mechanism to describe the relationship and co-dependencies
   between alarms.

7 Modular Alarm Architecture

  The architecture is designed to be modular to allow the evolution of
  SNMP alarm management over time.

  7.1 Extensible

  Additional alarm models can be supported as required.
  Support of specific alarm models should not be mandatory.

  This can be done to varying degrees.  It can be done by having
  separate MIBs in the form of a model-neutral MIB and a model-specific
  MIB.  It can also be done by keeping model-specific information,
  like ITU alarm content in separate tables or at the very least
  make them non-mandatory in the compliance/conformance statements.

  7.2 Scalable 

  Cost of implementation is proportional to the features supported

8. Condition Definitions

  This is a requirement to be able to define both alarm and non-alarm
  abnormal activity profiles. Conditions may or may not be persistent for
the
  duration of the abnormal activity they are indicating.  They, therefore,
  may or may not clear. Whether or not a condition is an alarm condition, 
  may change over the lifetime of a condition. 

  Conditions contain some information similar to that of an alarm, as 
  defined in 1). Conditions would likely be defined independently of alarms,
  but a relationship between the two needs to be defined in case a system
  supports both.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Tammy Ferris <[email-masked]>
Date: Thu, 29 Mar 2001 13:21:07 -0600

Sharon,
This is a good summary.  I currently have one comment and
one question and
possibly more subsequently.

You currently have:
For the sake of this document, assume an alarm is a
persistent indication of a
problem or abnormal activity of interest to a manager.  The
alarm is persistent
as long as its underlying problem is occurring.

I thought we agreed to remove the first instance of
persistence so it would
read:
For the sake of this document, assume an alarm is an
indication of a problem or
abnormal activity of interest to a manager.  The alarm is
persistent as long as
its underlying problem is occurring.

This statement and the requirements definitions do not
reflect our discussions
regarding alarms that are not persistent.  Did I miss
something about a decision
not to send alarm notifications for alarmed conditions that
did not persist?  I
see this discussed regarding Conditions but not Alarms. 
Does this group feel
that conditions such as security violations, for example
invalid login attempt,
which have no duration are not possible alarms?  Or are you
expecting to send a
raise  immediately following by a clear and add a row and
immediately remove a
row from the active alarm table?

Please clarify.

Thanks,
Tammy