Subject: Alarm Information ...

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 10 Aug 2000 15:13:26 -0500

hi

I know this work has not found a home yet, but I thought I would 
summarize the requirements we have seen so far:
	1) Mechanism to identify which notifications are alarms
	2) Mechanism to identify Raise/Clear relationship between
notifications/alarms
	3) Mechanism to map from notifications into ITU alarm definitions
	4) Mechanism to maintain list of active alarms
 
One possible way to proceed with this would be a new table which covers
the first three points.

For example:
AlarmEntry {
	alarmNotificationId OBJECT IDENTIFIER,
      alarmClearNotificationId OBJECT IDENTIFIER,
	alarmEventType	Integer32, (enumerated type relating to X.731 8.1.1)
      alarmProbableCause Integer32, (enumerated type relating to X.733
section 8.1.2.1 
					     and X.736)  
	alarmSpecificProblem Integer32,
	alarmPerceivedSeverity Integer32, (enumerated type relating to X.733
section 8.1.2.3)
	alarmTrendIndication Integer32, (enumerated type relating to X.733
section 8.1.2.6)
      ... more fields if people find them necessary,      
  }

Separate tables makes sense from three perspectives:
	1) Some alarm information is fairly static, so should probably be
separated from
	   the more dynamic information in the active alarm table
	2) A particular alarm could be active on more than one entity, so
separating
  	   this information out means less duplication
	3) The separate tables decouples the active alarm list from the
alarm definition,
	   making the active alarm list implementable on systems not
ready/willing to
	   support the ITU alarm model. 
	   
This could either be done in a separate MIB, or the Active Alarm MIB could
be renamed
to the Alarm MIB.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario