Status in source: unspecified.
Technical details
{
"smi_kind": "MODULE-IDENTITY",
"definition": [
"ericssonAlarmMIB",
"MODULE-IDENTITY",
"LAST-UPDATED",
[
"literal",
"223230303831303137303030305a22"
],
"ORGANIZATION",
"\"Ericsson AB\"",
"CONTACT-INFO",
"\"Email: snmp.mib.contact@ericsson.com \"",
"DESCRIPTION",
"\"See also Documentation and Use of the Ericsson SNMP Alarm MIB, Document number EAB/OP-07:0139. This MIB Module is an Ericsson-wide SNMP interface for managing alarms. Main inputs to the MIB design are the 3GPP Alarm IRP and X.733. However, an important restriction is that the MIB only represents the resource view and not management activities like acknowledgment, etc. It describes generic notifications used to send alarm state changes and a table which represents the current active alarms in the system. The MIB supports both stateful alarms and stateless alarms (that have no clear notification). Stateless alarms are called alerts. It is important to identify clearly what is to be considered the same alarm object instance. All unique alarm *types* are identified by 'AlarmType'. An AlarmType is a one-to-one mapping with X.733 EventType, ProbabableCause and SpecificProblem. A pair of integers are used to specify the alarm type. A unique alarm object *instance* is the combination of managed object and AlarmType. In this way there, is no ambiguity about how alarm and alarm clear correlation should be performed: the same managed object instance and AlarmType shall be used. The same is true for changing existing alarm states. Severity and additionalText can be changed on an existing alarm. For stateful alarms there are notifications to report a new alarm and a cleared alarm. Changing an alarm is done via the new alarm notification. The management system shall match the alarm by using alarm type and managed object instance in the same way as for clear notifications. The MIB has different notifications for different severities in order to support SNMP managers which maps severities based on notification identifiers. For stateless alarms, there are generic notifications to send the alarm raise with different severities. A table lists all active alarms so that a manager can read an initial state and also perform an alarm resynchronization procedure. There is also a table of latest stateless alarms. Since the stateless alarms do not have a corresponding clear message, the table size is limited by the agent instrumentation. The MIB supports two approaches for detecting lost notifications: - sequence numbers are used in the alarm notifications, and are shown in the active alarm table. The last used sequence number can be read in a scalar variable - a time stamp indicates the last time alarm tables where updated. Heartbeat mechanisms are supported both in pull and push mode: - Pull: the classical SNMP polling where a manager polls a scalar variable, for example the last sequence number used - Push: the agent can be configured to send heartbeat notifications. These contains the last used sequence numbers. Document number: 5/196 03-CXC 172 7549, Rev A\"",
"REVISION",
[
"literal",
"223230303831303137303030305a22"
],
"DESCRIPTION",
"\"Initial version of this MIB module.\"",
"::=",
"{",
"ericssonModules",
"4",
"}"
],
"syntax_tree": [
[
"LAST-UPDATED",
"200810170000Z"
],
[
"ORGANIZATION",
"Ericsson AB"
],
[
"CONTACT-INFO",
"Email: snmp.mib.contact@ericsson.com"
],
[
"DESCRIPTION",
"See also Documentation and Use of the Ericsson SNMP Alarm MIB, Document number EAB/OP-07:0139. This MIB Module is an Ericsson-wide SNMP interface for managing alarms. Main inputs to the MIB design are the 3GPP Alarm IRP and X.733. However, an important restriction is that the MIB only represents the resource view and not management activities like acknowledgment, etc. It describes generic notifications used to send alarm state changes and a table which represents the current active alarms in the system. The MIB supports both stateful alarms and stateless alarms (that have no clear notification). Stateless alarms are called alerts. It is important to identify clearly what is to be considered the same alarm object instance. All unique alarm *types* are identified by 'AlarmType'. An AlarmType is a one-to-one mapping with X.733 EventType, ProbabableCause and SpecificProblem. A pair of integers are used to specify the alarm type. A unique alarm object *instance* is the combination of managed object and AlarmType. In this way there, is no ambiguity about how alarm and alarm clear correlation should be performed: the same managed object instance and AlarmType shall be used. The same is true for changing existing alarm states. Severity and additionalText can be changed on an existing alarm. For stateful alarms there are notifications to report a new alarm and a cleared alarm. Changing an alarm is done via the new alarm notification. The management system shall match the alarm by using alarm type and managed object instance in the same way as for clear notifications. The MIB has different notifications for different severities in order to support SNMP managers which maps severities based on notification identifiers. For stateless alarms, there are generic notifications to send the alarm raise with different severities. A table lists all active alarms so that a manager can read an initial state and also perform an alarm resynchronization procedure. There is also a table of latest stateless alarms. Since the stateless alarms do not have a corresponding clear message, the table size is limited by the agent instrumentation. The MIB supports two approaches for detecting lost notifications: - sequence numbers are used in the alarm notifications, and are shown in the active alarm table. The last used sequence number can be read in a scalar variable - a time stamp indicates the last time alarm tables where updated. Heartbeat mechanisms are supported both in pull and push mode: - Pull: the classical SNMP polling where a manager polls a scalar variable, for example the last sequence number used - Push: the agent can be configured to send heartbeat notifications. These contains the last used sequence numbers. Document number: 5/196 03-CXC 172 7549, Rev A"
],
[
"Revisions",
[
[
"200810170000Z",
[
"DESCRIPTION",
"Initial version of this MIB module."
]
]
]
]
]
}