Status in source: unspecified.
Technical details
{
"smi_kind": "MODULE-IDENTITY",
"definition": [
"ericssonAlarmXpathMIB",
"MODULE-IDENTITY",
"LAST-UPDATED",
[
"literal",
"223230313730383131303030305a22"
],
"ORGANIZATION",
"\"Ericsson AB\"",
"CONTACT-INFO",
"\"EEIEMY\"",
"DESCRIPTION",
"\"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 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 YangNodeInstance and AlarmType. In this way, there is no ambiguity about how alarm and alarm clear correlation should be performed: the same YANG resource instance and AlarmType shall be used. The same is true for changing existing alarm states. Severity, Additional Text and Additional Info 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 YangNodeInstance 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 alerts, there are generic notifications to send the alerts with different severities. NOTE - Updated Definition of Alerts in TEA (The Ericsson Architecture): Alerts are used by service management systems to evaluate service impact, and are only applicable to very specific state changes with potential service impact like restart and redundancy shifts. Alerts SHALL NOT be used for fault indication. Alerts should always have Perceived Severity Indeterminate, and should only be sent using eriAlarmXIndAlert notification. The other severity alert notifications should not be used, and are only present in this specification for backward compatibility reasons. 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 were 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: 11/196 03-CXC 172 7549.\"",
"REVISION",
[
"literal",
"223230313730383131303030305a22"
],
"DESCRIPTION",
"\"Fixed duplicate object names issue, by replacing prefix eriAlarm with prefix eriAlarmX where needed. Increased overall size of Additional Info. Added new OBJECT-TYPE: eriAlarmXNObjAppendedAdditionalInfo. Added new IMPORT: EriAppendedAdditionalInfo. Fixed CONFORMANCE GROUPS issue by separating recently added OBJECT-TYPES into new CONFORMANCE GROUPS. Added new GROUPS: eriAlarmXActiveAlarmsAdditionalInfoGroup, eriAlarmXAlertsAdditionalInfoGroup, eriAlarmXRecordTypeGroup. Added more detail to DESCRIPTION for each REVISION. Document number: 11/196 03-CXC 172 7549, Rev C.\"",
"REVISION",
[
"literal",
"223230313730343133303030305a22"
],
"DESCRIPTION",
"\"Updated as part of ERICSSON ALARM MIB 2.1 package. Added new OBJECT-TYPES: eriAlarmNObjAdditionalInfo, eriAlarmNObjMoreAdditionalInfo, eriAlarmNObjRecordType, eriAlarmActiveAdditionalInfo, eriAlarmAlertAdditionalInfo. Added new IMPORTS: EriAdditionalInfo, EriLargeAdditionalInfo, EriAlarmRecordType. Document number: 11/196 03-CXC 172 7549, Rev B.\"",
"REVISION",
[
"literal",
"223230313630363234303030305a22"
],
"DESCRIPTION",
"\"Initial version of this MIB module. Document number: 11/196 03-CXC 172 7549, Rev A.\"",
"::=",
"{",
"ericssonModules",
"6",
"}"
],
"syntax_tree": [
[
"LAST-UPDATED",
"201708110000Z"
],
[
"ORGANIZATION",
"Ericsson AB"
],
[
"CONTACT-INFO",
"EEIEMY"
],
[
"DESCRIPTION",
"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 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 YangNodeInstance and AlarmType. In this way, there is no ambiguity about how alarm and alarm clear correlation should be performed: the same YANG resource instance and AlarmType shall be used. The same is true for changing existing alarm states. Severity, Additional Text and Additional Info 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 YangNodeInstance 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 alerts, there are generic notifications to send the alerts with different severities. NOTE - Updated Definition of Alerts in TEA (The Ericsson Architecture): Alerts are used by service management systems to evaluate service impact, and are only applicable to very specific state changes with potential service impact like restart and redundancy shifts. Alerts SHALL NOT be used for fault indication. Alerts should always have Perceived Severity Indeterminate, and should only be sent using eriAlarmXIndAlert notification. The other severity alert notifications should not be used, and are only present in this specification for backward compatibility reasons. 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 were 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: 11/196 03-CXC 172 7549."
],
[
"Revisions",
[
[
"201708110000Z",
[
"DESCRIPTION",
"Fixed duplicate object names issue, by replacing prefix eriAlarm with prefix eriAlarmX where needed. Increased overall size of Additional Info. Added new OBJECT-TYPE: eriAlarmXNObjAppendedAdditionalInfo. Added new IMPORT: EriAppendedAdditionalInfo. Fixed CONFORMANCE GROUPS issue by separating recently added OBJECT-TYPES into new CONFORMANCE GROUPS. Added new GROUPS: eriAlarmXActiveAlarmsAdditionalInfoGroup, eriAlarmXAlertsAdditionalInfoGroup, eriAlarmXRecordTypeGroup. Added more detail to DESCRIPTION for each REVISION. Document number: 11/196 03-CXC 172 7549, Rev C."
]
],
[
"201704130000Z",
[
"DESCRIPTION",
"Updated as part of ERICSSON ALARM MIB 2.1 package. Added new OBJECT-TYPES: eriAlarmNObjAdditionalInfo, eriAlarmNObjMoreAdditionalInfo, eriAlarmNObjRecordType, eriAlarmActiveAdditionalInfo, eriAlarmAlertAdditionalInfo. Added new IMPORTS: EriAdditionalInfo, EriLargeAdditionalInfo, EriAlarmRecordType. Document number: 11/196 03-CXC 172 7549, Rev B."
]
],
[
"201606240000Z",
[
"DESCRIPTION",
"Initial version of this MIB module. Document number: 11/196 03-CXC 172 7549, Rev A."
]
]
]
]
]
}