summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2456.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2456.txt')
-rw-r--r--doc/rfc/rfc2456.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc2456.txt b/doc/rfc/rfc2456.txt
new file mode 100644
index 0000000..3126e32
--- /dev/null
+++ b/doc/rfc/rfc2456.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group B. Clouston
+Request for Comments: 2456 Cisco Systems
+Category: Standards Track B. Moore
+ IBM Corporation
+ November 1998
+
+
+ Definitions of Managed Objects
+ for APPN TRAPS
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction ........................................... 2
+ 2. The SNMP Network Management Framework .................. 2
+ 3. Overview ............................................... 3
+ 3.1 APPN TRAP MIB structure .............................. 5
+ 4. Definitions ............................................ 6
+ 5. Security Considerations ................................ 17
+ 6. Intellectual Property .................................. 17
+ 7. Acknowledgments ........................................ 18
+ 8. References ............................................. 18
+ 9. Authors' Addresses ..................................... 20
+ 10. Full Copyright Statement ............................... 21
+
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 1]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+1. Introduction
+
+ This document is a product of the SNA NAU Services MIB Working Group.
+ It defines a MIB module for notifications for devices with Advanced
+ Peer-to-Peer Networking (APPN) and Dependent LU Requester (DLUR)
+ capabilities.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [13].
+
+2. The SNMP Network Management Framework
+
+ The SNMP Management Framework presently consists of five major
+ components:
+
+ o An overall architecture, described in RFC 2271 [1].
+
+ o Mechanisms for describing and naming objects and events for the
+ purpose of management. The first version of this Structure of
+ Management Information (SMI) is called SMIv1 and described in
+ STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
+ second version, called SMIv2, is described in RFC 1902 [5], RFC
+ 1903 [6] and RFC 1904 [7].
+
+ o Message protocols for transferring management information. The
+ first version of the SNMP message protocol is called SNMPv1 and
+ described in STD 15, RFC 1157 [8]. A second version of the SNMP
+ message protocol, which is not an Internet standards track
+ protocol, is called SNMPv2c and described in RFC 1901 [9] and
+ RFC 1906 [10]. The third version of the message protocol is
+ called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
+ RFC 2274 [12].
+
+ o Protocol operations for accessing management information. The
+ first set of protocol operations and associated PDU formats is
+ described in STD 15, RFC 1157 [8]. A second set of protocol
+ operations and associated PDU formats is described in RFC 1905
+ [13].
+
+ o A set of fundamental applications described in RFC 2273 [14] and
+ the view-based access control mechanism described in RFC 2275
+ [15].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using the mechanisms defined in the SMI.
+
+
+
+
+Clouston & Moore Standards Track [Page 2]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ This memo specifies a MIB module that is compliant to the SMIv2. A
+ MIB conforming to the SMIv1 can be produced through the appropriate
+ translations. The resulting translated MIB must be semantically
+ equivalent, except where objects or events are omitted because no
+ translation is possible (use of Counter64). Some machine readable
+ information in SMIv2 will be converted into textual descriptions in
+ SMIv1 during the translation process. However, this loss of machine
+ readable information is not considered to change the semantics of the
+ MIB.
+
+3. Overview
+
+ This document identifies the set of objects for reporting the status
+ of devices with APPN and DLUR capabilities via notifications.
+
+ See the SNANAU APPN MIB [18] and SNANAU DLUR MIB [19] for the objects
+ for monitoring the configuration and active characteristics of the
+ devices with APPN and DLUR capabilities. Many objects contained in
+ the notifications of this MIB are imported from the APPN and DLUR
+ MIBs. Implementors of this MIB must also implement the APPN MIB.
+ Implementations that support the appnTrapMibDlurConfGroup and the
+ appnTrapMibDlurNotifGroup must also implement the DLUR MIB.
+
+ The SNANAU APPN MIB allows a management station to collect the
+ network topology of an APPN network (the network nodes (NNs) in the
+ network and all of transmission groups (TGs) between the network
+ nodes) from an APPN device. It also allows the management station to
+ collect the local topology (TGs to end stations, and locally defined
+ ports and link stations) from an APPN device. While the SNANAU APPN
+ MIB has an efficient way to poll the APPN device for updates to the
+ network topology, using flow reduction sequence numbers (FRSNs) as a
+ table index; it does not have a mechanism to poll the local topology
+ tables (appnLocalTgTable, appnPortTable, and appnLsTable) for status
+ changes.
+
+ This MIB provides a mechanism for an APPN device to send
+ notifications to inform the management station of status changes to
+ rows of these tables. Status changes include operational state
+ changes, and for TGs also include control-point to control-point
+ (CP-CP) session state changes. A notification is defined for each
+ type of status change for each table.
+
+ The port and link operational state objects have intermediate states.
+ Notifications are only sent for transition to active or inactive
+ state.
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 3]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ Notifications are only sent for row creation if the state is active
+ or operational. This is done to avoid sending a notification as the
+ row is created with an inactive initial state, followed by another
+ notification as the resource is activated.
+
+ Notifications are only sent for row deletion if the last state was
+ active or operational. In most cases, a resource must be deactivated
+ before it can be deleted, and the deactivation will cause a
+ notification to be sent. There is no need for a second notification
+ to be sent for the row deletion, except for the case where the
+ deletion occurred without deactivation. In this case, the state of
+ the object in the notification will indicate an inactve state, since
+ a deleted resource can no longer be active.
+
+ The purpose of the appnLocalTgCpCpStateChangeTrap notification is to
+ identify the loss or recovery of CP-CP sessions on a TG while the TG
+ remains operational. Thus this notification is only sent if there is
+ a change to an appnLocalTgCpCpSession object, but not a change to the
+ appnLocalTgOperational object. This notification is never sent for
+ the creation or deletion of a row in the appnLocalTgTable.
+
+ Each notification always contains an object which is a count of the
+ number of times the status of a row in table has changed since the
+ APPN node was last reinitialized. This enables a management station
+ to detect that it has missed a notification, if it does not get the
+ notifications in numerical sequence. If the notifications are not in
+ sequence, the management station should retrieve the entire table to
+ get the correct status for all rows.
+
+ Similarly, the SNANAU DLUR MIB provides a mechanism for retrieving
+ the configuration and status of dependent LU server (DLUS) sessions
+ on a device with DLUR capabilities. This MIB defines a notification
+ for a DLUR-DLUS session state change of a row in the dlurDlusTable,
+ in the manner described above. A notification is only sent for a
+ session state transition to active or inactive. As with the above
+ notifications, it is only sent on row creation if the initial state
+ is active; and on row deletion is the last state was active, in which
+ case the notification indicates that the state is now inactive.
+
+ The SNANAU APPN MIB also provides a mechanism for a management
+ station to collect traffic statistics on intermediate sessions,
+ primarily for accounting purposes. However, when the session is
+ terminated, all statistics from the last poll until the session
+ termination time are lost, since the row for that session is deleted
+ from the appnIsInTable. This MIB defines a notification so that the
+ session's final statistics can be sent to a management station. If
+ the notification is not delivered, the final session statistics are
+ lost. If this is a concern, polling of the appnIsInTable in the APPN
+
+
+
+Clouston & Moore Standards Track [Page 4]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ MIB should be increased to more likely reduce the time between the
+ last poll and the session termination, thereby reducing the amount of
+ data lost.
+
+ Highlights of the management functions supported by the APPN TRAP MIB
+ module include the following:
+
+ o A notification for an APPN local TG operational state change.
+
+ o A notification for an APPN local TG CP-CP session state change.
+
+ o A notification for an APPN port operational state change.
+
+ o A notification for an APPN link station operational state
+ change.
+
+ o A notification for a DLUR-DLUS session state change.
+
+ o A notification for reporting final APPN intermediate session
+ statistics.
+
+ This MIB module does not support:
+
+ o Objects to query the configuration or status of APPN nodes on
+ demand.
+
+ o Notifications for changes to local topology tables not related
+ to status.
+
+3.1. APPN TRAP MIB Structure
+
+ The APPN TRAP MIB module contains a group of notifications, and a
+ group of supporting objects.
+
+ The group of notifications consists of the following notifications:
+
+ 1) appnIsrAccountingDataTrap
+
+ This notification is generated by an APPN device when an intermediate
+ session is terminating, to report the final accounting statistics of
+ the session.
+
+ 2) appnLocalTgOperStateChangeTrap
+
+ This notification identifies a change to the appnLocalTgOperational
+ object in a row of the SNANAU APPN MIB appnLocalTgTable.
+
+
+
+
+
+Clouston & Moore Standards Track [Page 5]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ 3) appnLocalTgCpCpStateChangeTrap
+
+ This notification identifies a change to the appnLocalTgCpCpSession
+ object in a row of the SNANAU APPN MIB appnLocalTgTable.
+
+ 4) appnPortOperStateChangeTrap
+
+ This notification identifies a change to the appnPortOperState object
+ in a row of the SNANAU APPN MIB appnPortTable.
+
+ 5) appnLsOperStateChangeTrap
+
+ This notification identifies a change to the appnLsOperState object
+ in a row of the SNANAU APPN MIB appnLsTable.
+
+ 6) dlurDlusStateChangeTrap
+
+ This notification identifies a change to the dlurDlusSessnStatus
+ object in a row of the SNANAU DLUR MIB dlurDlusTable.
+
+ The group of supporting objects contains the appnTrapControl object,
+ which controls whether the APPN device generates each type of
+ notification. Note that generation of the appnIsrAccountingDataTrap
+ is not controlled by this object; instead it is controlled by the
+ appnIsInGlobalCtrAdminStatus object in the SNANAU APPN MIB.
+
+ Although APPN notification generation could be controlled solely by
+ entries in the snmpNotificationMIB, RFC 2273 [9], the appnTrapControl
+ object exists in this MIB so that implementations are not required to
+ implement RFC 2273 to control generation of APPN notifications. For
+ a notification to be generated and sent as a TRAP or INFORM, the
+ notification type must first be enabled by the appnTrapControl
+ object. It must also not be disabled by an snmpNotificationMIB
+ entry. The destination of notifications is not within the scope of
+ this MIB.
+
+ Also contained in this group are objects for the TG, port, link, and
+ DLUR-DLUS session notifications to indicate the number of times each
+ of the tables has had a status change of a row since the APPN node
+ was last reinitialized.
+
+4. Definitions
+
+APPN-TRAP-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+
+ Counter32, OBJECT-TYPE, MODULE-IDENTITY,
+
+
+
+Clouston & Moore Standards Track [Page 6]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ NOTIFICATION-TYPE
+ FROM SNMPv2-SMI
+
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF
+
+ appnMIB, appnIsInP2SFmdPius, appnIsInS2PFmdPius,
+ appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius,
+ appnIsInP2SFmdBytes, appnIsInS2PFmdBytes,
+ appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes,
+ appnIsInSessUpTime, appnObjects,
+ appnLocalTgOperational, appnLocalTgCpCpSession,
+ appnPortOperState, appnLsOperState,
+ appnCompliances, appnGroups
+ FROM APPN-MIB
+
+ dlurDlusSessnStatus
+ FROM APPN-DLUR-MIB;
+
+appnTrapMIB MODULE-IDENTITY
+ LAST-UPDATED "9808310000Z" -- August 31, 1998
+ ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG"
+ CONTACT-INFO
+
+ "
+ Bob Clouston
+ Cisco Systems
+ 7025 Kit Creek Road
+ P.O. Box 14987
+ Research Triangle Park, NC 27709, USA
+ Tel: 1 919 472 2333
+ E-mail: clouston@cisco.com
+
+ Bob Moore
+ IBM Corporation
+ 4205 S. Miami Boulevard
+ BRQA/501
+ P.O. Box 12195
+ Research Triangle Park, NC 27709, USA
+ Tel: 1 919 254 4436
+ E-mail: remoore@us.ibm.com
+ "
+ DESCRIPTION
+ "This MIB module defines notifications to be generated by
+ network devices with APPN capabilities. It presupposes
+ support for the APPN MIB. It also presupposes
+ support for the DLUR MIB for implementations
+ that support the DLUR-related groups."
+
+
+
+Clouston & Moore Standards Track [Page 7]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+::= { appnMIB 0 }
+
+-- *********************************************************************
+-- Notifications
+-- *********************************************************************
+
+appnIsrAccountingDataTrap NOTIFICATION-TYPE
+ OBJECTS {
+ appnIsInP2SFmdPius,
+ appnIsInS2PFmdPius,
+ appnIsInP2SNonFmdPius,
+ appnIsInS2PNonFmdPius,
+ appnIsInP2SFmdBytes,
+ appnIsInS2PFmdBytes,
+ appnIsInP2SNonFmdBytes,
+ appnIsInS2PNonFmdBytes,
+ appnIsInSessUpTime
+ }
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification is generated by an
+ APPN node whenever an ISR session passing through the node is
+ taken down, regardless of whether the session went down
+ normally or abnormally. Its purpose is to allow a management
+ application (primarily an accounting application) that is
+ monitoring the ISR counts to receive the final values of these
+ counts, so that the application can properly account for the
+ amounts the counts were incremented since the last time the
+ application polled them. The appnIsInSessUpTime object
+ provides the total amount of time that the session was active.
+
+ This notification is not a substitute for polling the ISR
+ counts. In particular, the count values reported in this
+ notification cannot be assumed to be the complete totals for
+ the life of the session, since they may have wrapped while the
+ session was up.
+
+ The session to which the objects in this notification apply is
+ identified by the fully qualified CP name and PCID that make up
+ the table index. An instance of this notification will contain
+ exactly one instance of each of its objects, and these objects
+ will all belong to the same conceptual row of the
+ appnIsInTable.
+
+ Generation of this notification is controlled by the same
+ object in the APPN MIB, appnIsInGlobeCtrAdminStatus, that
+ controls whether the count objects themselves are being
+ incremented."
+
+
+
+Clouston & Moore Standards Track [Page 8]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ ::= { appnTrapMIB 1 }
+
+appnLocalTgOperStateChangeTrap NOTIFICATION-TYPE
+ OBJECTS {
+ appnLocalTgTableChanges,
+ appnLocalTgOperational
+ }
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification makes it possible
+ for an APPN topology application to get asynchronous
+ notifications of local TG operational state changes,
+ and thus to reduce the frequency with which it polls
+ for these changes.
+
+ This notification is sent whenever there is a change to
+ the appnLocalTgOperational object in a row of the
+ appnLocalTgTable. This notification is only sent for row
+ creation if the row is created with a value of 'true' for
+ appnLocalTgOperational. This notification is only sent for
+ row deletion if the last value of appnLocalTgOperational was
+ 'true'. In this case, the value of appnLocalTgOperational
+ in the notification shall be 'false', since the deletion of
+ a row indicates that the TG is no longer operational.
+
+ The notification is more than a simple 'poll me now' indication.
+ It carries both a count of local TG topology changes, and the
+ current operational state itself. The count of changes allows an
+ application to detect lost notifications, either when polling
+ or upon receiving a subsequent notification, at which point it
+ knows it must retrieve the entire appnLocalTgTable again.
+ This is the same count as used in the appnLocalCpCpStateChangeTrap.
+ A lost notification could indicate a local TG CP-CP session state
+ change or an operational state change.
+
+ Generation of this notification is controlled by the
+ appnTrapControl object."
+
+ ::= { appnTrapMIB 2 }
+
+appnLocalTgCpCpChangeTrap NOTIFICATION-TYPE
+ OBJECTS {
+ appnLocalTgTableChanges,
+ appnLocalTgCpCpSession
+ }
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification makes it possible
+
+
+
+Clouston & Moore Standards Track [Page 9]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ for an APPN topology application to get asynchronous
+ notifications of local TG control-point to control-point (CP-CP)
+ session state changes, and thus to reduce the
+ frequency with which it polls for these changes.
+
+ This notification is sent whenever there is a change to
+ the appnLocalTgCpCpSession object but NOT the
+ appnLocalTgOperational object in a row of the appnLocalTgTable.
+ This notification is never sent for appnLocalTgTable row
+ creation or deletion.
+
+ The notification is more than a simple 'poll me now' indication.
+ It carries both a count of local TG topology changes, and the
+ current CP-CP session state itself. The count of changes allows
+ an application to detect lost notifications, either when polling
+ or upon receiving a subsequent notification, at which point it
+ knows it must retrieve the entire appnLocalTgTable again. This
+ is the same count as used in the appnLocalTgOperStateChangeTrap.
+ A lost notification could indicate a local TG CP-CP session
+ state change or an operational state change.
+
+ Generation of this notification is controlled by the
+ appnTrapControl object."
+
+ ::= { appnTrapMIB 3 }
+
+appnPortOperStateChangeTrap NOTIFICATION-TYPE
+ OBJECTS {
+ appnPortTableChanges,
+ appnPortOperState
+ }
+
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification makes it possible
+ for an APPN topology application to get asynchronous
+ notifications of port operational state changes, and thus to
+ reduce the frequency with which it polls for these changes.
+ This notification is only sent when a appnPortOperState has
+ transitioned to a value of 'active' or 'inactive'.
+
+ This notification is sent whenever there is a appnPortOperState
+ object transition to 'inactive' or 'active' state in the
+ appnPortTable. This notification is only sent for row creation
+ if the row is created with a value of 'active' for
+ appnPortOperState. This notification is only sent for
+ row deletion if the last value of appnPortOperState was
+ 'active'. In this case, the value of appnPortOperState
+
+
+
+Clouston & Moore Standards Track [Page 10]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ in the notification shall be 'inactive', since the deletion of
+ a row indicates that the port is no longer active.
+
+ The notification is more than a simple 'poll me now' indication.
+ It carries both a count of port table changes, and the
+ operational state itself. The count of changes allows an
+ application to detect lost notifications, either when polling
+ or upon receiving a subsequent notification, at which point
+ it knows it must retrieve the entire appnPortTable again.
+
+ Generation of this notification is controlled by the
+ appnTrapControl object."
+
+ ::= { appnTrapMIB 4 }
+
+appnLsOperStateChangeTrap NOTIFICATION-TYPE
+ OBJECTS {
+ appnLsTableChanges,
+ appnLsOperState
+ }
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification makes it possible
+ for an APPN topology application to get asynchronous
+ notifications of link station operational state changes, and
+ thus to reduce the frequency with which it polls for these
+ changes. This notification is only sent when a appnLsOperState
+ has transitioned to a value of 'active' or 'inactive'.
+
+ This notification is sent whenever there is a appnLsOperState
+ object transition to 'inactive' or 'active' state in the
+ appnLsTable. This notification is only sent for row creation
+ if the row is created with a value of 'active' for
+ appnLsOperState. This notification is only sent for
+ row deletion if the last value of appnLsOperState was
+ 'active'. In this case, the value of appnLsOperState
+ in the notification shall be 'inactive', since the deletion of
+ a row indicates that the link station is no longer active.
+
+ The notification is more than a simple 'poll me now' indication.
+ It carries both a count of link station table changes, and the
+ operational state itself. The count of changes allows an
+ application to detect lost notifications, either when polling
+ or upon receiving a subsequent notification, at which point it
+ knows it must retrieve the entire appnLsTable again.
+
+ Generation of this notification is controlled by the
+ appnTrapControl object."
+
+
+
+Clouston & Moore Standards Track [Page 11]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ ::= { appnTrapMIB 5 }
+
+dlurDlusStateChangeTrap NOTIFICATION-TYPE
+ OBJECTS {
+ dlurDlusTableChanges,
+ dlurDlusSessnStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "When it has been enabled, this notification makes it possible
+ for an APPN topology application to get asynchronous
+ notifications of DLUR-DLUS session changes, and thus to reduce
+ the frequency with which it polls for these changes.
+
+ This notification is sent whenever there is a dlurDlusSessnStatus
+ object transition to 'inactive' or 'active' state in the
+ dlurDlusTable. This notification is only sent for row creation
+ if the row is created with a value of 'active' for
+ dlurDlusSessnStatus. This notification is only sent for
+ row deletion if the last value of dlurDlusSessnStatus was
+ 'active'. In this case, the value of dlurDlusSessnStatus
+ in the notification shall be 'inactive', since the deletion of
+ a row indicates that the session is no longer active.
+
+ The notification is more than a simple 'poll me now' indication.
+ It carries both a count of DLUR-DLUS table changes, and the
+ session status itself. The count of changes allows an
+ application to detect lost notifications, either when polling
+ or upon receiving a subsequent notification, at which point it
+ knows it must retrieve the entire dlurDlusTable again.
+
+ Generation of this notification is controlled by the
+ appnTrapControl object."
+
+ ::= { appnTrapMIB 6 }
+
+-- *********************************************************************
+-- Supporting Objects
+-- *********************************************************************
+
+appnTrapObjects OBJECT IDENTIFIER ::= { appnObjects 7 }
+
+appnTrapControl OBJECT-TYPE
+
+ SYNTAX BITS {
+ appnLocalTgOperStateChangeTrap(0),
+ appnLocalTgCpCpChangeTrap(1),
+ appnPortOperStateChangeTrap(2),
+
+
+
+Clouston & Moore Standards Track [Page 12]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ appnLsOperStateChangeTrap(3),
+ dlurDlusStateChangeTrap(4)
+ -- add other notification types here
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "An object to turn APPN notification generation on and off.
+ Setting a notification type's bit to 1 enables generation of
+ notifications of that type, subject to further filtering
+ resulting from entries in the snmpNotificationMIB. Setting
+ this bit to 0 disables generation of notifications of that
+ type.
+
+ Note that generation of the appnIsrAccountingDataTrap is
+ controlled by the appnIsInGlobeCtrAdminStatus object in
+ the APPN MIB: if counts of intermediate session traffic
+ are being kept at all, then the notification is also enabled."
+
+ ::= { appnTrapObjects 1 }
+
+appnLocalTgTableChanges OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of times a row in the appnLocalTgTable
+ has changed status since the APPN node was last reinitialized.
+ This counter is incremented whenever a condition is detected
+ that would cause a appnLocalTgOperStateChangeTrap or
+ appnLocalTgCpCpChangeTrap notification to be sent, whether
+ or not those notifications are enabled."
+
+ ::= { appnTrapObjects 2 }
+
+appnPortTableChanges OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of times a row in the appnPortTable
+ has changed status since the APPN node was last reinitialized.
+ This counter is incremented whenever a condition is detected
+ that would cause a appnPortOperStateChangeTrap notification
+ to be sent, whether or not this notification is enabled."
+
+ ::= { appnTrapObjects 3 }
+
+
+
+
+Clouston & Moore Standards Track [Page 13]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+appnLsTableChanges OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of times a row in the appnLsTable
+ has changed status since the APPN node was last reinitialized.
+ This counter is incremented whenever a condition is detected
+ that would cause a appnLsOperStateChangeTrap notification
+ to be sent, whether or not this notification is enabled."
+
+ ::= { appnTrapObjects 4 }
+
+dlurDlusTableChanges OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of times a row in the dlurDlusTable
+ has changed status since the APPN node was last reinitialized.
+ This counter is incremented whenever a condition is detected
+ that would cause a dlurDlusStateChangeTrap notification
+ to be sent, whether or not this notification is enabled."
+
+ ::= { appnTrapObjects 5 }
+
+-- *********************************************************************
+-- Conformance information
+-- *********************************************************************
+
+-- Tie into the conformance structure in the APPN MIB:
+-- appnConformance OBJECT IDENTIFIER ::= {appnMIB 3 }
+--
+-- appnCompliances OBJECT IDENTIFIER ::= {appnConformance 1 }
+-- appnGroups OBJECT IDENTIFIER ::= {appnConformance 2 }
+
+-- Compliance statement
+appnTrapMibCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for the SNMP entities that
+ implement the APPN-TRAP-MIB."
+
+ MODULE -- this module
+
+-- Conditionally mandatory groups
+ GROUP appnTrapMibIsrNotifGroup
+ DESCRIPTION
+
+
+
+Clouston & Moore Standards Track [Page 14]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ "This group is mandatory for APPN nodes supporting
+ reporting of final ISR counter values via notifications."
+
+ GROUP appnTrapMibTopoConfGroup
+ DESCRIPTION
+ "This group is mandatory for APPN nodes supporting
+ polling reduction for local topology."
+
+ GROUP appnTrapMibTopoNotifGroup
+ DESCRIPTION
+ "This group is mandatory for APPN nodes supporting
+ polling reduction for local topology."
+
+ GROUP appnTrapMibDlurConfGroup
+ DESCRIPTION
+ "This group is mandatory for APPN nodes supporting
+ polling reduction for the dlurDlusTable."
+
+ GROUP appnTrapMibDlurNotifGroup
+ DESCRIPTION
+ "This group is mandatory for APPN nodes supporting
+ polling reduction for the dlurDlusTable."
+
+ OBJECT appnTrapControl
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "An agent is not required to support a set to
+ this object."
+
+ ::= {appnCompliances 2 }
+
+-- Units of conformance
+appnTrapMibIsrNotifGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ appnIsrAccountingDataTrap
+ }
+ STATUS current
+ DESCRIPTION
+ "A notification for reporting the final values of the
+ APPN MIB's ISR counters."
+
+ ::= { appnGroups 21 }
+
+appnTrapMibTopoConfGroup OBJECT-GROUP
+ OBJECTS {
+ appnTrapControl,
+ appnLocalTgTableChanges,
+ appnPortTableChanges,
+
+
+
+Clouston & Moore Standards Track [Page 15]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ appnLsTableChanges
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects for reducing the polling
+ associated with the local topology tables in the
+ APPN MIB. Nodes that implement this group SHALL
+ also implement the appnTrapMibTopoNotifGroup."
+
+ ::= { appnGroups 22 }
+
+appnTrapMibTopoNotifGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ appnLocalTgOperStateChangeTrap,
+ appnLocalTgCpCpChangeTrap,
+ appnPortOperStateChangeTrap,
+ appnLsOperStateChangeTrap
+
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of notifications for reducing the polling
+ associated with the local topology tables in the
+ APPN MIB. Nodes that implement this group SHALL
+ also implement the appnTrapMibTopoConfGroup."
+
+ ::= { appnGroups 23 }
+
+appnTrapMibDlurConfGroup OBJECT-GROUP
+ OBJECTS {
+ appnTrapControl,
+ dlurDlusTableChanges
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects for reducing the polling
+ associated with the dlurDlusTable in the DLUR
+ MIB. Nodes that implement this group SHALL also
+ implement the appnTrapMibDlurNotifGroup."
+
+ ::= { appnGroups 24 }
+
+appnTrapMibDlurNotifGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ dlurDlusStateChangeTrap
+ }
+ STATUS current
+ DESCRIPTION
+
+
+
+Clouston & Moore Standards Track [Page 16]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ "A notification for reducing the polling associated
+ with the dlurDlusTable in the DLUR MIB. Nodes that
+ implement this group SHALL also implement the
+ appnTrapMibDlurConfGroup."
+
+ ::= { appnGroups 25 }
+
+END
+
+5. Security Considerations
+
+ Certain management information defined in this MIB may be considered
+ sensitive in some network environments. Therefore, authentication of
+ received SNMP requests and controlled access to management
+ information SHOULD be employed in such environments. An
+ authentication protocol is defined in [12]. A protocol for access
+ control is defined in [15].
+
+ None of the read-only objects in the APPN TRAP MIB reports a
+ password, user data, or anything else that is particularly sensitive.
+ Some enterprises view their network configuration itself, as well as
+ information about network usage and performance, as corporate assets;
+ such enterprises may wish to restrict SNMP access to most of the
+ objects in the MIB.
+
+ There is one read-write object in the APPN TRAP MIB, appnTrapControl.
+ This object controls the generation of the notifications defined in
+ the APPN TRAP MIB.
+
+6. Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards- related documentation can be found in BCP-11 [16]. Copies
+ of claims of rights made available for publication and any assurances
+ of licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementers or users of this specification can
+ be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 17]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+7. Acknowledgments
+
+ This MIB module is the product of the IETF SNA NAU MIB WG and the AIW
+ APPN/HPR MIBs SIG.
+
+8. References
+
+ [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
+ Describing SNMP Management Frameworks", RFC 2271, Cabletron
+ Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
+ January 1998.
+
+ [2] Rose, M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based Internets", STD 16, RFC
+ 1155, May 1990.
+
+ [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+ RFC 1212, March 1991.
+
+ [4] Rose, M., "A Convention for Defining Traps for use with the
+ SNMP", RFC 1215, March 1991.
+
+ [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+ "Structure of Management Information for Version 2 of the Simple
+ Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
+
+ [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+ Conventions for Version 2 of the Simple Network Management
+ Protocol (SNMPv2)", RFC 1903, January 1996.
+
+ [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+ "Conformance Statements for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1904, January 1996.
+
+ [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+ [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901, January
+ 1996.
+
+
+
+
+
+Clouston & Moore Standards Track [Page 18]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+ [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+ "Transport Mappings for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+ [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
+ Processing and Dispatching for the Simple Network Management
+ Protocol (SNMP)", RFC 2272, January 1998.
+
+ [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
+ for version 3 of the Simple Network Management Protocol
+ (SNMPv3)", RFC 2274, January 1998.
+
+ [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+ Operations for Version 2 of the Simple Network Management
+ Protocol (SNMPv2)", RFC 1905, January 1996.
+
+ [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
+ 2273, January 1998.
+
+ [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
+ Control Model (VACM) for the Simple Network Management Protocol
+ (SNMP)", RFC 2275, January 1998
+
+ [16] Hovey, R., and S. Bradner, "The Organizations Involved in the
+ IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+ [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [18] Clouston, B., and B. Moore, "Definition of Managed Objects for
+ APPN", RFC 2455, November 1998.
+
+ [19] Clouston, B., and B. Moore, "Definitions of Managed Objects for
+ DLUR", RFC 2232, November 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 19]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+9. Authors' Addresses
+
+ Bob Clouston
+ Cisco Systems
+ 7025 Kit Creek Road
+ P.O. Box 14987
+ Research Triangle Park, NC 27709, USA
+
+ Phone: +1 919 472 2333
+ EMail: clouston@cisco.com
+
+
+ Robert Moore
+ Dept. BRQA/Bldg. 501/G114
+ IBM Corporation
+ P.O.Box 12195
+ 3039 Cornwallis
+ Research Triangle Park, NC 27709, USA
+
+ Phone: +1 919 254 4436
+ EMail: remoore@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 20]
+
+RFC 2456 APPN TRAPS MIB November 1998
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore Standards Track [Page 21]
+