Obsoletes:
Keywords: APPN-MIB, Advanced Peer-to-Peer Networking, MIB, management information base
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
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,
with two objects that also apply to branch network nodes. This group
includes an object indicating the node's network node server.
Clouston & Moore Standards Track [Page 7]
RFC 2455 APPN MIB November 1998
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.2.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.2.3. appnLocalTopology group
The appnLocalTopology group consists of the following objects and
tables:
Clouston & Moore Standards Track [Page 8]
RFC 2455 APPN MIB November 1998
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.2.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.2.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.
Clouston & Moore Standards Track [Page 9]
RFC 2455 APPN MIB November 1998
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.2.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.2.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.
4. Definitions
APPN-MIB DEFINITIONS ::= BEGIN
IMPORTS
IANAifType
FROM IANAifType-MIB
DisplayString, VariablePointer, RowPointer, DateAndTime,
Clouston & Moore Standards Track [Page 10]
RFC 2455 APPN MIB November 1998
TruthValue, TimeStamp, TEXTUAL-CONVENTION
FROM SNMPv2-TC
Counter32, Gauge32, 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 "9807151800Z" -- July 15, 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 is the MIB module for objects used to
manage network devices with APPN capabilities."
-- Revision tracking starts with Proposed Standard (RFC 2155)
REVISION "9807151800Z"
DESCRIPTION
"Minor editorial fixes; new value 'none(5)' added
to the enumeration for the appnLocalTgBranchLinkType
object."
Clouston & Moore Standards Track [Page 11]
RFC 2455 APPN MIB November 1998
REVISION "9805261800Z"
DESCRIPTION
"Post-RFC 2155 conformance definitions added,
appnNodeLsCounterType and appnNodeBrNn objects
added, appnNodeMibVersion object deprecated."
REVISION "9707311800Z"
DESCRIPTION
"Branch network node (Branch Extender) objects added."
REVISION "9703311800Z"
DESCRIPTION
"MLTG objects added."
REVISION "9703201200Z"
DESCRIPTION
"RFC 2155 (Proposed Standard)"
::= { 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
Clouston & Moore Standards Track [Page 12]
RFC 2455 APPN MIB November 1998
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 '