Subject: Compiled Alarm MIB Requirements

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Mar 2001 14:19:53 -0500

hi

Here are the updated Alarm MIB Requirements compiled off
the mailing list.  I've also taken a stab at a compliance
matrix.

I've added a removed a "priority" column to the compliance
matrix a couple time.  I've added it because I think it's
important to consider which features are most important,
so we optimise the architecture for them.  I've removed
it because I think it might distract us more than help
us.  I'll just say, that my number one priority is the
active alarm table, so I'm interested in an architecture
optimised around that.

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.1               |  What             |  Yes       |
 1.2               |  State            |  Yes       |
 1.3               |  Notification     |  Yes       |
 1.4               |  Where            |  Maybe     |
 1.5               |  By Whom          |  Maybe     |
 1.6               |  ITU Info         |  Yes       |
 1.7               |  Map to Trap      |  Yes       |
 1.8               |  Configuration    |  Yes       |
2.                 | Real-time Alarm   | Yes        |
3.                 | Distributed Alarm | Yes        |
4.                 | Historical Alarm  | Maybe      |
5.                 | Suppression       | Maybe      |
 5.1               |  ARC              |  Maybe     |
 5.2               |  By Severity      |  Maybe     |
6.                 | Correlation       | No         |
----------------------------------------------------|

Requirements
-------------

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
   or sub-agent detected the problem. (I think.  Device is covered in
   the distributed management requirement)

   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.
   (Of course I have more to say here, but I'm trying to keep this
   somewhat neutral.)

   1.9 Dynamic definition of new alarms

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

2. Real-time Alarm Management

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

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.

5. Alarm Notification Suppression

   The requirement is for a mechanism to not send out the associated SNMP
   notification related to a given alarm under controlled
   conditions.
	5.1 ITU's Alarm Reporting Control (ARC)
      5.2 Suppression by severity

6. Alarm Correlation

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

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 04 Mar 2001 22:16:41 -0800

HI,

Sorry, I cannot respond to this complete list at this time.
However, there is one item that needs comment and clarification,
which is alarm ID.

The term "Alarm ID", can be used to mean the type of alarm,
or the instance of the alarm. The list below was very unclear
to me.

If the below is proposing that an alarm type can be created
dynamically, then I'm much opposed to that approach. Operationally,
it really doesn't work well.

More on this list later.

Regards,
/david t. perkins

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 Mar 2001 12:37:37 -0500

hi

I'd like to put the modular architecture onto the
requirements list, since I think it is a discussion
that should be had somewhat independent of other
requirements and implementations.

--
7 Modular Alarm Architecture

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

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.

--

I've also updated the numbering in the compliance matrix.  To
paragraph Mike's Highlander reference, there can only be one 1.1

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            |  Maybe     |
 1.6               |  By Whom          |  Maybe     |
 1.7               |  ITU Info         |  Yes       |
 1.8               |  Map to Trap      |  Yes       |
 1.9               |  Configuration    |  Yes       |
2.                 | Real-time Alarm   | Yes        |
3.                 | Distributed Alarm | Yes        |
4.                 | Historical Alarm  | Maybe      |
5.                 | Suppression       | Maybe      |
 5.1               |  ARC              |  Maybe     |
 5.2               |  By Severity      |  Maybe     |
6.                 | Correlation       | No         |
7.                 | Modular Arch.     | Maybe      |
----------------------------------------------------|

Sharon

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 6 Mar 2001 13:17:14 -0500

Sharon:

	I think we should first look at the required information for alarm
mib
	before we talk about the architecture.  In my view modular alarm
architecture is
            not a requirement.

 	I'd like to have a mib that is good enough for most cases.  Most of
the requirements that
	      you compliled are general, excep some of the  ITU-T specific
information.

		Comments on the matrix:
>  1.5               |  Where            |  Yes     |  -- based on my
> expression from the email discussions.
>  1.6               |  By Whom          |  Maybe     |
>  1.7               |  ITU Info         |  Yes       |
	 2.                 | Real-time Alarm   | Yes        |
	 3.                 | Distributed Alarm | Yes        |
	 4.                 | Historical Alarm  | Yes      |   -- same as
above
	 5.                 | Suppression       | Maybe      |
       6.                 | Correlation       | No         |

Regards,

Anni

> ----------
> From: 	Sharon Chisholm[SMTP:[email-masked]]
> Sent: 	Tuesday, March 06, 2001 12:37 PM
> To: 	[email-masked]
> Subject: 	RE: Compiled Alarm MIB Requirements
>
>
> hi
>