Remote Monitoring MIB Extensions for High Capacity Alarms
Extracted elements (24)
64-bit threshold values are represented as two Unsigned32 fields (Lo and Hi) plus an HcValueStatus sign indicator rather than using Counter64 directly, allowing signed threshold values and explicit indication of value unavailability. ABS(threshold) = Lo + (Hi * 2^32).
The HC-ALARM MIB extends RMON-1's alarmTable to support Counter64 objects because at high interface speeds (1Gbps+), 32-bit counters wrap in as little as 34 seconds, making threshold monitoring of ifHCInOctets and ifHCOutOctets impossible with the existing RMON-1 Alarm Group.
The hcAlarmTable objects are cloned from alarmTable rather than extending it because the DESCRIPTION clauses of existing alarmTable objects are specific to the alarmTable itself and their defined semantics do not allow reuse for a different table.
The HC-ALARM MIB is completely independent of the RMON-1 alarm mechanisms; hcAlarmTable entries and hcRising/FallingAlarm notifications are separate from and do not replace the existing RMON-1 alarmTable and risingAlarm/fallingAlarm notifications. Both may coexist in an implementation.
The hcAlarmTable differs from RMON-1's alarmTable in four key ways: Counter64 is properly supported; an entry is not destroyed if the monitored instance is unavailable during a polling interval; RowStatus replaces EntryStatus for hcAlarmStatus; and StorageType is added for explicit non-volatile storage control.
An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value as described in the DESCRIPTION clause for each writable object.
Conformant implementations MUST implement hcAlarmControlGroup, hcAlarmCapabilitiesGroup, and hcAlarmNotificationsGroup from HC-ALARM-MIB, plus rmonEventGroup from RMON-MIB.
For deltaValue sampling, the hcAlarmInterval SHOULD be set short enough that the sampled variable is very unlikely to increase or decrease by more than 2^63 - 1 during a single sampling interval, to avoid counter delta overflow.
hcAlarmInterval, hcAlarmVariable, hcAlarmSampleType, hcAlarmStartupAlarm, hcAlarmRisingThresh*, and hcAlarmFallingThresh* objects may not be modified if the associated hcAlarmStatus is equal to active(1).
The hcAlarmRisingThresholdValStatus and hcAlarmFallingThresholdValStatus objects MUST NOT be set to 'valueNotAvailable(1)'; an hcAlarmStatus of active(1) is not allowed if either threshold status is valueNotAvailable.
When hcAlarmStorageType is permanent(4), the associated hcAlarmRisingEventIndex and hcAlarmFallingEventIndex objects must be writable to allow management of the permanent entry.
hcAlarmCapabilities is a BITS object indicating agent-level support for: hcAlarmCreation(0) — NMS can create hcAlarmTable entries; hcAlarmNvStorage(1) — entries can be persisted across restarts via hcAlarmStorageType.
hcAlarmSampleType specifies either absoluteValue(1), where the variable is compared directly with thresholds, or deltaValue(2), where the difference between current and previous sample values is compared. If the previous sample was unavailable, delta sampling yields valueNotAvailable(1).
hcAlarmStartupAlarm controls which alarm type may fire when an entry first becomes active: risingAlarm(1), fallingAlarm(2), or risingOrFallingAlarm(3). This determines initial threshold evaluation behavior before hysteresis takes effect.
hcAlarmValueFailedAttempts (Counter32) tracks the number of times the hcAlarmVariable instance was polled while active but the value was unavailable. This counter may be discontinuous after an agent restart, as indicated by sysUpTime.
hcRisingAlarm and hcFallingAlarm are SNMP NOTIFICATION-TYPEs generated when a high capacity alarm entry crosses its rising or falling threshold respectively. Each notification carries the alarm variable OID, sample type, current absolute value, value status, threshold values, and event index.
The hcAlarmTable contains one conceptual row per high capacity alarm entry, indexed by hcAlarmIndex (Integer32 1..65535). Each entry specifies a variable to sample, thresholds, sample type, and associated event indices for rising and falling alarms.
The HcValueStatus textual convention encodes the validity and sign of a high-capacity absolute value using three enumerated states: valueNotAvailable(1) when the instance could not be accessed, valuePositive(2) for non-negative values, and valueNegative(3) for negative values (the absolute value must be multiplied by -1).
This document registers the HC-ALARM-MIB module under the RMON OID arc at { rmon 29 }, defining hcAlarmObjects (1), hcAlarmNotifications (2), and hcAlarmConformance (3) beneath it.
hcAlarmAbsValue and hcAlarmValueStatus may expose sensitive MIB instance values identified by hcAlarmVariable. SNMPv3 with USM (RFC 3414) and VACM (RFC 3415) is recommended to secure access to these read-write and read-create objects.
SNMPv1 alone provides no access control even on a secure network. Implementors are recommended to use the SNMPv3 framework, specifically USM (STD 62, RFC 3414) and VACM (STD 62, RFC 3415), to control GET/SET access to HC-ALARM-MIB objects.
The hcAlarmVariable object can be used to read any MIB object accessible to the probe via the alarm polling mechanism, bypassing normal view-based access control. Write access to hcAlarmVariable MUST only be granted in views that already have read access to all objects on the probe.
Hysteresis for rising alarms: after a rising alarm fires (sampled value >= rising threshold from below), no further rising alarm is generated until the value falls below the rising threshold and then reaches the falling threshold. The reverse applies for falling alarms, preventing alarm storms.
Rising and falling thresholds are each encoded as three fields: hcAlarm{Rising|Falling}ThreshAbsValueLo (Unsigned32, lower 32 bits), hcAlarm{Rising|Falling}ThreshAbsValueHi (Unsigned32, upper 32 bits), and hcAlarm{Rising|Falling}ThresholdValStatus (HcValueStatus, sign/validity). The combined absolute value is Lo + Hi * 2^32.