rfc2456.txt

RFC 的详细文档！

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:    [phone]
                        E-mail: [e-mail]

                        Bob Moore
                        IBM Corporation
                        4205 S. Miami Boulevard
                        BRQA/501
                        P.O. Box 12195
                        Research Triangle Park, NC 27709, USA
                        Tel:    [phone]
                        E-mail: [e-mail]
                "
      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]