rfc2455.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,856 行 · 第 1/5 页

Network Working Group                                     B. Clouston
Request for Comments: 2455                              Cisco Systems
Obsoletes: 2155                                              B. Moore
Category: Standards Track                             IBM Corporation
                                                        November 1998


                     Definitions of Managed Objects
                                for APPN

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

Table of Contents

   1.     Introduction  ..........................................   2
   2.     The SNMPv2 Network Management Framework  ...............   2
   3.     Overview  ..............................................   3
   3.1      Relationship with RFC 2155 ...........................   6
   3.2      APPN MIB structure ...................................   7
   4.     Definitions  ...........................................  10
   5.     Security Considerations  ............................... 135
   6.     Intellectual Property  ................................. 136
   7.     Acknowledgments  ....................................... 137
   8.     References  ............................................ 137
   9.     Authors' Addresses  .................................... 139
   10.    Full Copyright Statement  .............................. 140






Clouston & Moore            Standards Track                     [Page 1]

RFC 2455                        APPN MIB                   November 1998


1.  Introduction

   This document is a product of the SNA NAU Services MIB Working Group.
   It defines a MIB module for managing devices with Advanced Peer-to-
   Peer Networking (APPN) 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 [17].

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 2455                        APPN 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 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 [21] and the
   SNA NAU MIB [22] for management of these sessions.  See also RFC
   2232, the DLUR MIB [23], and RFC 2238, the HPR MIB [24] 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.  A branch network
   node (BrNN) is a network node that is similar to a border node, but
   with only minimal functions to build a large APPN network within an
   enterprise.  Although a BrNN is defined to be a network node in the
   APPN architecture, it also has an end node (EN) appearance to
   upstream NNs in the network.  In this MIB module it is treated as a
   separate node type since it does not fit cleanly as an EN or NN, and
   this module explicity identifies those objects returned by a BrNN.
   For example, a BrNN does not implement the appnNnTopo objects since
   it is the only node in its network topology table; but it does
   implement the appnSessIntermediate objects since it does have
   intermediate session support.  It also implements two of the
   appnEnUniqueCaps objects that could be useful to a management
   application.  A BrNN identifies itself as 'endNode' in the
   appnNodeType object but further identifies itself as a BrNN in the
   appnNodeBrNn object.

   End nodes 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



Clouston & Moore            Standards Track                     [Page 3]

RFC 2455                        APPN MIB                   November 1998


   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[25], the SNADLC LLC
   MIB[26], and the DLSw MIB[27].  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. A node that supports
   APPN function set 1120, branch awareness, also saves information on
   TGs to adjacent BrNNs.  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 to all node types are kept in a local
   topology database. Local topology information is shared with other
   nodes only during the session establishment process, to give the NN
   responsible for route calculation the necessary information for end-
   to-end route calculation.

   A management application can show a full representation of the APPN
   network from the network and local topology information.  To show the
   network topology, the application need only query the network



Clouston & Moore            Standards Track                     [Page 4]

RFC 2455                        APPN MIB                   November 1998


   topology tables from a single NN. To show all of the BrNNs, the
   application must also directly query all destinations of TGs that
   indicate they are branch TGs (indicated by the appnNnTgFRBranchTg
   object) to see if they have any cascaded BrNNs. For any NNs that do
   not indicate branch awareness support (indicated by the
   appnNnNodeFRBranchAwareness object), the application must query each
   NN's appnLocalTgTable, and then the appnNodeBrNn object of each row's
   destination node to identify BrNNs.  To show all of the nodes in the
   network, including ENs and LEN nodes, the application must query
   every NN's appnLocalTgTable, and iteratively do the same for each
   BrNN it finds.

   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 [18],
   [19], [20], and [28].

   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.



Clouston & Moore            Standards Track                     [Page 5]

RFC 2455                        APPN MIB                   November 1998


   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.  Relationship with RFC 2155

   This MIB obsoletes RFC 2155 [29] with changes due to additions to the
   APPN architecture and some implementation experience of RFC 2155.
   The changes from RFC 2155 are as follows:

   o    New objects for the multi-link TG architecture enhancement:
        appnLsMltgMember, appnNnTgFRMltgLinkType,
        appnLocalTgMltgLinkType, and appnLocalEnTgMltgLinkType.

   o    New objects, and explanations for values for existing objects,
        for the branch network node architecture enhancement:
        appnNodeBrNn, appnNnNodeFRBranchAwareness, appnNnTgFRBranchTg,
        and appnLocalTgBranchLinkType.

   o    New object, appnNodeLsCounterType, to indicate which type of ANR
        traffic is returned in the appnLsTable traffic counters.

   o    Deprecated appnNodeMibVersion object.

   o    Miscellaneous editorial changes.








Clouston & Moore            Standards Track                     [Page 6]

RFC 2455                        APPN MIB                   November 1998


3.2.  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.2.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