💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc2155.txt captured on 2022-06-04 at 03:36:41.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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. Clouston & Moore Standards Track [Page 1] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 2] RFC 2155 Definitions of Managed Objects for APPN June 1997 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". Clouston & Moore Standards Track [Page 3] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 4] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 5] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 6] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 7] RFC 2155 Definitions of Managed Objects for APPN June 1997 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. Clouston & Moore Standards Track [Page 8] RFC 2155 Definitions of Managed Objects for APPN June 1997 4. Definitions APPN-MIB DEFINITIONS ::= BEGIN IMPORTS IANAifType FROM IANAifType-MIB DisplayString, VariablePointer, RowPointer, DateAndTime, TruthValue, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC experimental, Counter32, Gauge32, Integer32, Unsigned32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF snanauMIB FROM SNA-NAU-MIB; appnMIB MODULE-IDENTITY LAST-UPDATED "9703201200Z" 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 800 Park Offices Drive RHJA/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@ralvm6.vnet.ibm.com " DESCRIPTION Clouston & Moore Standards Track [Page 9] RFC 2155 Definitions of Managed Objects for APPN June 1997 "This is the MIB module for objects used to manage network devices with APPN capabilities." ::= { snanauMIB 4 } -- snanauMIB ::= { mib-2 34 } -- ********************************************************************* -- Textual Conventions -- ********************************************************************* SnaNodeIdentification ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNA Node Identification consists of two parts, which together comprise four bytes of hexadecimal data. In SNA the Node Identification is transported in bytes 2-5 of the XID. The block number is the first three digits of the Node Identification. These 3 hexadecimal digits identify the product. The ID number is the last 5 digits of the Node Identification. These 5 hexadecimal digits are administratively defined and combined with the 3-digit block number form the 8-digit Node Identification. A unique value is required for connections to SNA subarea. In some implementations, the value 'bbb00000' (where 'bbb' represents a 3-digit block number) is returned to mean that the ID number is not unique on this node. An SNA Node Identification is represented as eight ASCII-encoded hexadecimal digits, using the characters '0' - '9' and 'A' - 'F'." SYNTAX OCTET STRING (SIZE (8)) SnaControlPointName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A fully qualified SNA control point name, consisting of a 1 to 8 character network identifier (NetId), a period ('.'), and a 1 to 8 character control point name (CpName). The NetId and CpName are constructed from the uppercase letters 'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII, with the restriction that the first character of each must be a letter. Trailing blanks are not allowed. Earlier versions of SNA permitted three additional characters in NetIds and CpNames: '#', '@', and '