Alarm Management Information Base (MIB)
Extracted elements (32)
Named alarm lists (alarmListName) allow a mid-level manager to maintain separate alarm lists per managed device and support distributed alarm management scenarios, while the zero-length list name is reserved as the default for systems that do not support multiple named lists.
The modular architecture (generic ALARM-MIB optionally extended by ITU-ALARM-MIB or other specific MIBs) was chosen so that implementation cost is proportional to the number of alarm management features supported, avoiding mandatory overhead for simple deployments.
The Opaque type is included in alarmActiveVariableOpaqueVal despite RFC 2578 forbidding its use in standard MIB modules. This is justified by the need to accurately represent any well-formed notification and to maintain backward compatibility with existing notification definitions that use Opaque.
The ResourceId computation mechanism using alarmModelVarbindSubtree and alarmModelResourcePrefix was designed to let both the managed element and a manager independently compute the same resource identifier from Notification varbinds, enabling correlation of separate alarm instances against the same physical or logical resource without a shared registry.
For SNMPv1 Trap-PDU varbind indexing, alarmModelVarbindIndex values must be adjusted by two relative to the trap's SMI definition because the InformRequest-PDU and SNMPv2-Trap-PDU prepend sysUpTime.0 and snmpTrapOID.0 as obligatory varbinds. RFC 3584 section 3.1 rules are used to synthesise these values for SNMPv1 traps.
The alarmActiveLogPointer and alarmClearLogIndex objects provide cross-references into the Notification Log MIB (RFC 3014), allowing the notification log to serve as a hedge against missed alarms due to throttling or transmission loss and to support historical alarm management.
The alarmListName SHOULD match nlmLogName if the Notification Log MIB (RFC 3014) is supported, and SHOULD match or be a prefix of snmpNotifyFilterProfileName if SNMP-NOTIFICATION-MIB (RFC 3413) is supported, facilitating coordinated operation across these MIBs.
A value of 1 MUST indicate a clear alarm state in alarmModelState. The value MUST be less than more severe states and more than less severe states, enforcing a strict severity ordering.
alarmActiveDateAndTime and alarmClearDateAndTime implementations MUST include the offset from UTC if available. Implementation in environments where the UTC offset is not available is NOT RECOMMENDED.
alarmActiveEngineAddress and alarmClearEngineAddress MUST always be instantiated, even if the list can only contain alarms from a single engine, to consistently identify the alarm source.
Alarms SHOULD be modelled so that Notifications are sent on alarm Clear, enabling management stations to detect problem resolution without polling.
IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values 1–1023 are reserved for ITU-T probable causes; all other new causes are assigned starting at 1025 on a first-come basis.
If alarmModelNotificationId has no associated notification, its value MUST be '0.0'. Similarly, alarmActiveResourceId MUST be 0.0 when there is no corresponding resource.
The agent MUST throttle generation of consecutive alarmActiveState and alarmClearState traps so that there is at least a two-second gap between traps of the same type against the same alarmActiveModelPointer and alarmActiveResourceId. Throttled traps are dropped, not queued.
The alarmModelTable MUST be persistent across system reboots. This ensures alarm models survive restarts and the management station always has a complete picture of possible alarms.
The managed system SHOULD NOT apply access control when processing remotely-generated Notifications; instead, security of alarm table information SHOULD be left to normal, overall access control for those tables.
When processing locally-generated Notifications, the managed system MUST use the security credentials associated with each alarm model and MUST apply the same access control rules as described for a Notification Originator in RFC 3413.
The alarmActiveState and alarmClearState NOTIFICATION-TYPEs are generic alarm notifications carrying alarmActiveModelPointer and alarmActiveResourceId, intended for use when no pre-existing domain-specific notification exists for a fault.
The alarmActiveStatsTable provides per-named-alarm-list statistics: current active alarm count (Gauge32), total alarms since restart (ZeroBasedCounter32), and sysUpTime of last raise and last clear.
The alarmActiveTable stores currently active alarms indexed by alarmListName, alarmActiveDateAndTime, and alarmActiveIndex. Each entry captures the engine ID, engine address, context, notification ID, resource ID, description, and pointers to the log, model, and any specific extension table.
The alarmActiveVariableTable stores all varbinds from the triggering Notification for each active alarm. Entries are always normalised to SNMPv2-Trap-PDU format: index 1 is sysUpTime, index 2 is snmpTrapOID, with subsequent varbinds following.
The alarmClearTable stores recently cleared alarms up to alarmClearMaximum entries; when full, entries with the earliest clear time are removed. Each entry mirrors active alarm metadata plus alarmClearLogIndex linking to the Notification Log MIB.
The alarmModelTable defines all possible alarm states on a system, indexed by alarmListName, alarmModelIndex, and alarmModelState. Each entry specifies the associated NotificationId, varbind index/value for state discrimination, description, resource prefix, and a pointer to model-specific extensions.
The ituAlarmTable and ituAlarmActiveTable are model-specific extensions providing ITU M.3100/X.733/X.736 alarm attributes (probable cause, event type, perceived severity, etc.) that augment the generic alarm and active alarm tables.
The ALARM-MIB module is registered at OID mib-2 118. The IANA-ITU-ALARM-TC-MIB is registered at mib-2 119. Both are established by this document.
The IANA-ITU-ALARM-TC-MIB (OID mib-2 119) defines the IANAItuProbableCause and IANAITUEventType textual conventions. IANA manages enumeration assignments; values 1–1023 are reserved for ITU-T causes, new causes assigned from 1025 upward on a first-come basis with OPS Area Director-appointed expert review.
Community or context names that are not well-formed SnmpAdminStrings will be mapped to zero-length strings in alarmActiveContextName and alarmClearContextName, which could cause loss of source context for SNMPv1 traps if community strings contain non-UTF8 bytes.
Several writable objects (alarmModelTable entries, alarmClearMaximum) can be used to disrupt alarm management: an adversary with write access could remove alarm models, suppress active alarms from appearing, or delete historical cleared alarm records. SNMPv3 with authentication and privacy is strongly recommended.
VACM-based access control for alarm objects is inherently awkward: checking whether varbinds in a Notification are accessible can only be done where the Notification originates, and only when security credentials are available. The security credentials of the alarm model creator are bound to the model and constrain what information may populate the active alarm, variable, cleared alarm, and ITU alarm tables.
An alarm follows a lifecycle of states defined by alarmModelState values: state 1 is always Clear; higher integer values represent raise states of increasing severity (e.g., warning, minor, major, critical). Transitions are triggered by matching incoming Notifications to alarmModelNotificationId and the optional alarmModelVarbindIndex/Value discriminator.
alarmActiveVariableValueType is an INTEGER discriminant (counter32, unsigned32, timeTicks, integer32, ipAddress, octetString, objectId, counter64, opaque) selecting exactly one of the typed value columns in alarmActiveVariableTable for a given row.
Varbinds are normalised on storage: sysUpTime.0 and snmpTrapOID.0 are stored as alarmActiveVariableIndex 1 and 2 respectively for all PDU types. For SNMPv1 Trap-PDUs, appropriate values are derived using RFC 3584 section 3.1 translation rules.