Network Working Group                                      B. Clouston
Request for Comments: 2155                               Cisco Systems
Category: Standards Track                                     B. Moore
                                                       IBM Corporation
                                                             June 1997


                     Definitions of Managed Objects
                          for APPN using SMIv2

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.

Table of Contents

   1.     Introduction  ...........................................  1
   2.     The SNMPv2 Network Management Framework  ................  1
   3.     Overview  ...............................................  2
   3.1      APPN MIB structure ....................................  4
   4.     Definitions  ............................................  9
   5.     Acknowledgments  ......................................  122
   6.     References  ...........................................  122
   7.     Security Considerations  ..............................  123
   8.     Author's Addresses  ...................................  124

1.  Introduction

   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 monitoring and controlling
   network devices with APPN (Advanced Peer-to-Peer Networking)
   capabilities.  This memo identifies managed objects for the APPN
   protocol.

2.  The SNMPv2 Network Management Framework

   The SNMP Network Management Framework consists of several components.
   For the purpose of this specification, the applicable components of
   the Framework are the SMI and related documents [1, 2, 3], which
   define the mechanisms used for describing and naming objects for the
   purpose of management.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

3.  Overview

   This document identifies a set of objects for monitoring the
   configuration and active characteristics of devices with APPN
   capabilities, and for controlling certain characteristics.  APPN is
   the aspect of Systems Network Architecture (SNA) that supports peer-
   to-peer networking.  These networks transport both independent and
   dependent LU session traffic.  See the SNANAU APPC MIB [7] and the
   SNA NAU MIB [8] for management of these sessions.  See also the DLUR
   MIB[9], and the HPR MIB[10] for management of extensions to the APPN
   architecture.  In this document, we describe APPN managed objects.

   An APPN network comprises various types of nodes, and transmission
   groups (TGs) that connect the nodes. Network nodes (NNs) provide
   directory and routing functions for session establishment.  NNs may
   be session end points or intermediate nodes in a session.  A border
   node is a type of network node that connects networks together for
   session establishment without fully merging them.  End nodes (ENs)
   are session end points that receive directory and routing functions
   from network nodes, over control-point to control-point (CP-CP)
   sessions.  Low-entry networking (LEN) nodes are also session end
   points, but do not support CP-CP sessions, and therefore need
   additional manual configuration definitions to establish sessions in
   an APPN network.  ENs and LEN nodes may have minimal directory and
   routing functions to establish control sessions (ENs) or to connect
   into the APPN network (LEN nodes).  Virtual routing nodes (VRNs) are
   not really nodes, but rather common definitions among actual nodes in
   a shared transport facility such as a local area network (LAN) that
   allow these actual nodes to temporarily establish a logical link with
   one another without defining each other's link-level addressing
   information.

   Ports and link stations are the node's interface to the data link
   control (DLC), which provides the physical transport, or to another
   protocol such as Data Link Switching (DLSw), which provides transport
   over an IP network.  See the SNADLC SDLC MIB[11], the SNADLC LLC
   MIB[12], and the DLSw MIB[13].  A link station uses a port to make a
   connection to another node.  This connection establishes a TG between
   the two nodes.

   The directory and routing functions enable an NN to find where an LU
   is located in the network, and calculate the optimal route for the
   session based on the requested class of service (COS).  A network
   node saves the LU information in a directory database, which is built
   from LUs defined locally, LU registration from served end nodes, and
   LUs learned from network searches.

   Each NN maintains a local COS database that assigns a routing weight,
   or relative cost, to each resource for each class of service.  For
   example, the #INTER COS assigns a lower weight to TGs with a greater
   effective capacity, while the #BATCH COS favors TGs with a lower
   relative cost per byte.

   A node saves network topology information (on NNs, VRNs, and TGs
   between them) in a network topology database.  The topology
   information includes state and routing characteristics.  Topology
   information is exchanged between NNs over CP-CP sessions such that
   the database is fully replicated at each NN.  Information on TGs from
   NNs to ENs are kept in a local topology database.  Local topology
   information is shared with other NNs only during the session
   establishment process, to give the NN responsible for route
   calculation the necessary information for end-to- end route
   calculation.

   SNA names such as LU names, CP names, COS names, and mode names can
   be padded with blanks (space characters) in SNA formats.  These
   blanks are nonsignificant.  For example, in a BIND Request Unit (RU)
   a COS name of "#INTER" with a length of 6 is identical to a COS name
   of "#INTER  " with a length of 8.  However, in this MIB,
   nonsignificant blanks are not included by the agent.   Using the COS
   name from the previous example, an agent would return a length of 6
   and the string "#INTER" with no blanks for appnCosName, regardless of
   how it appears in the BIND RU or in internal storage.  The lone
   exception is the all blank mode name, for which the agent returns a
   length of 8 and the string "        " (8 blank spaces).  The MIB
   variables that this applies to are identified by a textual convention
   syntax that also describes this behavior.

   When an SNA name is functioning as a table index, an agent treats
   trailing blanks as significant.  If a management station requests the
   objects from a row with index "#INTER  ", the agent does not match
   this to the row with index "#INTER".  Since an agent has no
   nonsignificant blanks in any of its table indices, the only reason
   for a Management Station to include them would be to start GetNext
   processing at a chosen point in a table.  For example, a GetNext
   request with index "M       " would start retrieval from a table at
   the first row with an 8-character index beginning with "M" or a
   letter after "M".

   The SNA/APPN terms and overall architecture are documented in [4],
   [5], [6], and [14].

   Highlights of the management functions supported by the APPN MIB
   module include the following:

   o    Activating and deactivating ports and link stations.

   o    Monitoring of configuration parameters related to the node,
        ports, link stations, virtual routing nodes, and classes of
        service.

   o    Monitoring of operational parameters related to ports, link
        stations, virtual routing nodes, topology, directory, and
        intermediate sessions.

   o    Historical information about link station errors during
        connection establishment, or that caused the connection to
        terminate.

   o    Deactivating intermediate sessions.

   o    Traps for SNA Management Services (SNA/MS) Alert conditions.

   This MIB module does not support:

   o    Configuration of APPN nodes.

   o    Monitoring and control of endpoint sessions.

   o    Dependent LU Requester (DLUR) management.

   o    High-Performance Routing (HPR) management.

3.1.  APPN MIB Structure

   The APPN MIB module contains the following groups of objects:


   o    appnNode - objects related to the APPN node for all node types.

   o    appnNn   - objects to represent the network nodes, virtual
        routing nodes, and TGs between these nodes that make up the APPN
        network topology database maintained in NNs.

   o    appnLocalTopology  - objects to represent nodes and TGs between
        nodes in the local topology database maintained in all nodes.

   o    appnDir  - objects related to LU location information from the
        node's directory database.

   o    appnCos  - objects related to classes of service information.

   o    appnSessIntermediate - objects related to intermediate sessions
        that pass through this node.

        These groups are described below in more detail.

3.1.1.  appnNode group

   The appnNode group consists of the following tables and objects:

   1) appnGeneralInfoAndCaps

   This group of objects describes general information about the APPN
   node.  The type of information includes the node type and the time
   since this node was initialized.

   2) appnNnUniqueInfoAndCaps

   This group of objects describes information specific to network nodes
   such as node routing characteristics.

   3) appnEnUniqueInfoAndCaps

   This group of objects describes information specific to end nodes,
   including its network node server.

   4) appnPortInformation

   This includes the appnPortTable, which describes the configuration
   and current status of the ports used by APPN, including the port
   state and DLC type.

   5) appnLinkStationInformation

   This includes the appnNodeLsTable, which describes the configuration
   and current status of the link stations used by APPN, including the
   link state and port name; and the appnLsStatusTable, which provides
   information about errors this node encountered with connections to
   adjacent nodes, such as the sense data captured during connection
   failures.  It is a product option to decide how many
   appnLsStatusTable entries are kept.

   6) appnVrnInfo

   This includes the appnVrnTable, which describes the relationship
   between virtual routing nodes' TGs described in the appnLocalTgTable
   with ports in the appnPortTable.

3.1.2.  appnNn group

   The appnNn group consists of the following objects and tables

   1) appnNnTopo

   These objects contain general information about the network topology
   database including the number of nodes present, and the number of
   topology database updates (TDU) wars the node has detected.

   2) appnNnTopology

   This includes tables representing the APPN network topology database.
   This includes the network nodes, virtual routing nodes, and TGs
   between these nodes, as well as the information about these resources
   carried in topology updates.  The tables are first indexed by the
   same flow reduction sequence number (FRSN) used in topology exchanges
   between NNs.  This allows a management station to retrieve only
   incremental updates, since the agent will update the FRSN of new or
   changed resources.

3.1.3.  appnLocalTopology group

   The appnLocalTopology group consists of the following objects and
   tables:

   1) appnLocalThisNode

    a) appnLocalGeneral

    Contains the local node and type.

    b) appnLocalNnSpecific

    These objects contain routing information about the local network
    node.

    c) appnLocalTg

    This table represents information about this node's local TGs.

   2) appnLocalEnTopology

   This table represents TG information for EN TGs learned by the NN via
   TG registration with the local node.

3.1.4.  appnDir group

   The appnDir group consists of the following objects and tables:

   1) appnDirPerf

   These objects represent information related to information about the
   directory database and directory searches involving this node.

   2) appnDirTable

   This table represents the directory database, listing LUs known to
   this node, along with the owning node of the LU and the serving NN of
   the owning node.

3.1.5.  appnCos group

   The appnCos group consists of the following tables:

   1) appnCosModeTable

   This table represents the mode to class of service mapping.

   2) appnCosNameTable

   This table represents the tranmission priority for each class of
   service.

   3) appnCosNodeRowTable

   This table represents the node-row information for each class of
   service, including the weight of each node.

   3) appnCosTGRowTable

   This table represents the TG-row information for each class of
   service, including the weight of each TG.

3.1.6.  appnSessIntermediate group

   The appnSessIntermediate group consists of the following objects and
   tables:

   1) appnIsInGlobal

   These objects allow control of the collection of intermediate session
   information such as Route Selection Control Vectors (RSCVs) and
   counters.

   2) appnIsInTable

   This table contains information on active intermediate sessions.

   3) appnIsRtpTable

   This table contains information on active intermediate sessions that
   are being transported on Rapid Transport Protocol (RTP) connections
   by High Performance Routing (HPR).

3.1.7.  appnTraps

   One APPN trap is defined.  It is intended to correspond to SNA/MS
   Alerts, but is optional for a product to implement this trap.  The
   trap identifies the Alert ID number and, where possible, the affected
   resource.