ERICSSON-ALARM-TC-MIB

TEXTUAL-CONVENTION

Additional Information, structured in a way that is suitable for machine-to-machine communication. Comprises a number of name=value pairs, separated by a semicolon in the following format: name1=value1;name2=value2;.. Allowed strings for use as 'name' are defined in The Ericsson Architecture and updated upon internal requests from Ericsson organizations. This is a small size range in order to guarantee delivery of notifications without fragmentation. There is a corresponding textual convention, EriLargeAdditionalInfo, to be used for scalar and columnar objects. The string should adhere to the rules for SnmpAdminString of SNMPv3 framework MIBs.

TEXTUAL-CONVENTION

The string used in additional text notifications. This MUST contain enough information for an operator to be able to understand the problem. If this string contains structure, this format should be clearly documented for programs to be able to parse that information. This is a small size range in order to guarantee delivery of notifications without fragmentation. There is a corresponding textual convention, EriLargeAdditionalText, to be used for scalar and columnar objects. The string should adhere to the rules for SnmpAdminString of SNMPv3 framework MIBs.

TEXTUAL-CONVENTION

Index used in the active alarm table. A row shall never change its index during the lifetime of the entry; for example renumbering entries is not allowed when entries are deleted. Renumbering after an agent restart is allowed. Note that this index shall not be used to identify alarms when performing resynchronization, etc. The logical identity for an alarm instance is the managed object and alarm type.

TEXTUAL-CONVENTION

This defines the alarm record type that is being reported in an alarm notification.

TEXTUAL-CONVENTION

This is a monotonically increasing counter. It is increased every time a notification is sent. The value is NOT increased for heartbeat notifications. It is carried as a varbind in the alarm notifications as well as in the heartbeat notifications. Management systems can use these varbinds to detect lost notifications.

TEXTUAL-CONVENTION

A value that represents a type of source identifier. This is needed for deployments where the Source IP Address of the IP packet does not reflect the original source of the alarm. unknown(0) An unknown identifier type. This value MUST be used if the value of the corresponding EriAlarmSourceIdentifier object is a zero-length string. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. Each definition of a concrete EriAlarmSourceIdentifierType value must be accompanied by a definition of a textual convention for use with that EriAlarmSourceIdentifierType. To support future extensions, the EriAlarmSourceIdentifierType Textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that EriAlarmSourceIdentifierType objects and any dependent objects (e.g. EriAlarmSourceIdentifier objects) are consistent. An inconsistentValue error must be generated if an attempt to change an EriAlarmSourceIdentifierType object would, for example, lead to an undefined EriAlarmSourceIdentifier value. In particular, EriAlarmSourceIdentifierType/EriAlarmSourceIdentifier pairs must be changed together if the address type changes (e.g. from ipv6(2) to ipv4(1)). If extending the allowed values, it may be advisable to maintain consistency with the values for InetAddressType in the INET-ADDRESS-MIB.

TEXTUAL-CONVENTION

Unique string for the Alarm Type. No different alarm types may share specific problem. Specific Problem and Alarm Type have a one-to-one correspondance.

TEXTUAL-CONVENTION

A unique identification of the fault, not including the managed object. Alarm types are used to identify if alarms indicate the same problem or not, for lookup into external alarm documentation, etc. A unique alarm type is identified using the combination of two instances of EriAlarmType. Different managed object types and instances can share alarm types. But if the same managed object reports the same alarm type, it is to be considered to be the same alarm state. The alarm type is a simplification of the different X.733 and 3GPP alarm IRP alarm correlation mechanisms based on EventType, ProbableCause, SpecificProblem and NotificationId.

TEXTUAL-CONVENTION

Used for spillover of Additional Info in the append trap.

TEXTUAL-CONVENTION

Additional Information, structured in a way that is suitable for machine-to-machine communication. Comprises a number of name=value pairs, separated by a semicolon in the following format: name1=value1;name2=value2;.. Allowed strings for use as 'name' are defined in The Ericsson Architecture and updated upon internal requests from Ericsson organizations. This is a large additional info to be used in tables. There is a corresponding textual convention to be used in alarm notifications, EriAdditionalInfo. The string should adhere to the rules for SnmpAdminString of SNMPv3 framework MIBs.

TEXTUAL-CONVENTION

The string used in additional text. This MUST contain enough information for an operator to be able to understand the problem. If this string contains structure, this format should be clearly documented for programs to be able to parse that information. This is a large additional text to be used in tables. There is a corresponding textual convention to be used in alarm notifications, EriAdditionalText. The string should adhere to the rules for SnmpAdminString of SNMPv3 framework MIBs.