rfc-2456

Definitions of Managed Objects for APPN TRAPS

B. Clouston, B. Moore
date1998-11 streamIETF areartg wgsnanau statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc2456 doi10.17487/RFC2456
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]

Extracted elements (21)

design-rationale §4

appnIsrAccountingDataTrap is explicitly not a substitute for polling the ISR counts, because counter values in the notification may have wrapped during the session's lifetime. The notification provides only the final delta since the last poll, not cumulative session totals.

snmp

design-rationale §3

Each notification carries a cumulative table-change counter so that a management station can detect missed notifications by checking whether received notifications are in numerical sequence. If they are not in sequence, the station should re-fetch the entire relevant table to restore consistent state.

snmp

design-rationale §3

The appnLocalTgCpCpChangeTrap is never sent for appnLocalTgTable row creation or deletion, and is only sent when the CP-CP session state changes while the TG itself remains operational. This avoids redundant notifications when a TG goes down (which is already captured by appnLocalTgOperStateChangeTrap).

snmp

design-rationale §3.1

The appnTrapControl object exists in this MIB so that implementations are not required to implement RFC 2273 (SNMPv3 Applications / snmpNotificationMIB) solely to control APPN notification generation. For a notification to be sent, it must be enabled by appnTrapControl AND not disabled by an snmpNotificationMIB entry.

snmp

interoperability-note §2

This MIB is compliant to SMIv2. A conforming SMIv1 translation can be produced, but objects using Counter64 must be omitted since no SMIv1 translation is possible for them. Some machine-readable SMIv2 information will be converted to textual descriptions in the translation, which is not considered a semantic change.

snmp

normative-requirement §3 MUST

Implementors of this MIB MUST also implement the APPN MIB (RFC 2455). Implementations that support the appnTrapMibDlurConfGroup and appnTrapMibDlurNotifGroup MUST also implement the DLUR MIB (RFC 2232).

snmp

normative-requirement §5 SHOULD

In network environments where MIB data is considered sensitive, authentication of received SNMP requests and controlled access to management information SHOULD be employed. The USM authentication protocol (RFC 2274) and VACM access control (RFC 2275) are referenced for this purpose.

snmp, security

normative-requirement §3 SHOULD

Notifications are only sent for row creation if the new state is active (or operational/true). This rule prevents sending a notification when a row is created with an inactive initial state, which would then immediately be followed by another notification upon activation.

snmp

normative-requirement §3 MUST

Notifications are only sent for row deletion if the last state of the row was active (or operational). For a deleted row whose last state was active, the notification MUST indicate an inactive state, since a deleted resource can no longer be active.

snmp

normative-requirement §4 REQUIRED

The appnTrapMibTopoConfGroup and appnTrapMibTopoNotifGroup are co-mandatory: nodes implementing one SHALL also implement the other. Likewise, appnTrapMibDlurConfGroup and appnTrapMibDlurNotifGroup are co-mandatory for DLUR support.

snmp

protocol-element §4

appnIsrAccountingDataTrap is generated when an ISR (intermediate session routing) session passing through an APPN node is taken down, carrying final values of bidirectional FMD/non-FMD PIU and byte counts plus session uptime (appnIsInSessUpTime). It is controlled by appnIsInGlobeCtrAdminStatus in the APPN MIB, not by appnTrapControl.

snmp

protocol-element §4

appnLocalTgCpCpChangeTrap notifies of control-point to control-point (CP-CP) session state changes on a TG while the TG remains operational; it is sent only when appnLocalTgCpCpSession changes but appnLocalTgOperational does not, and is never sent for appnLocalTgTable row creation or deletion.

snmp

protocol-element §4

appnLocalTgOperStateChangeTrap notifies management stations of local transmission group (TG) operational state changes by carrying appnLocalTgTableChanges (a cumulative change counter) and appnLocalTgOperational. It is sent on transitions to 'true' or 'false', on row creation only if initial state is 'true', and on deletion only if the last state was 'true' (with the notification value set to 'false').

snmp

protocol-element §4

appnLsOperStateChangeTrap notifies of APPN link station operational state transitions, carrying appnLsTableChanges and appnLsOperState. Sending rules are the same as for the port trap: only on transitions to 'active' or 'inactive', row creation only if active, row deletion only if last state was active.

snmp

protocol-element §4

appnPortOperStateChangeTrap notifies of APPN port operational state transitions, carrying appnPortTableChanges and appnPortOperState. It is only sent when appnPortOperState transitions to 'active' or 'inactive', on row creation only if initial state is 'active', and on row deletion only if the last state was 'active'.

snmp

protocol-element §4

appnTrapControl is a read-write BITS object with one bit per notification type (appnLocalTgOperStateChangeTrap through dlurDlusStateChangeTrap). Setting a bit to 1 enables that notification type; setting it to 0 disables it. It does not control appnIsrAccountingDataTrap, which has its own control object in the APPN MIB.

snmp

protocol-element §4

dlurDlusStateChangeTrap notifies of DLUR-DLUS session state changes, carrying dlurDlusTableChanges and dlurDlusSessnStatus. It follows the same active/inactive-only sending rules as the other state-change traps and is controlled by appnTrapControl.

snmp

protocol-element §4

Four Counter32 supporting objects—appnLocalTgTableChanges, appnPortTableChanges, appnLsTableChanges, and dlurDlusTableChanges—count the number of status changes in each respective table since the APPN node was last reinitialized. These counters are incremented whenever a notification-worthy condition is detected, regardless of whether the notification is enabled.

snmp

protocol-element §3.1

The APPN-TRAP-MIB module defines a set of SNMP notifications (traps/informs) for devices with APPN and DLUR capabilities, covering local TG operational state, CP-CP session state, port state, link station state, DLUR-DLUS session state, and final ISR accounting statistics. It is rooted at appnMIB 0 and presupposes the APPN MIB (RFC 2455).

snmp, registry

security-consideration §5

The APPN TRAP MIB contains one read-write object, appnTrapControl, which controls notification generation; unauthorized modification could suppress or flood SNMP notifications. The read-only objects do not expose passwords or user data, but network configuration, usage, and performance data may be considered sensitive corporate assets warranting restricted SNMP access.

snmp, security

state-machine §3

For port and link station notifications, only transitions to 'active' or 'inactive' trigger a notification; intermediate operational states are not reported. For TG operational state, the boolean appnLocalTgOperational ('true'/'false') triggers notifications on any change. For DLUR-DLUS sessions, only transitions to 'active' or 'inactive' trigger dlurDlusStateChangeTrap.

snmp