RFC 1665
Definitions of Managed Objects for SNA NAUs using SMIv2
Network Working Group Z. Kielczewski Request for Comments: 1665 Eicon Technology Corporation Category: Standards Track D. Kostick Bell Communications Research K. Shih Novell Editors July 1994 Definitions of Managed Objects for SNA NAUs 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 ................................................ 2 2. The SNMPv2 Network Management Framework ..................... 2 2.1 Object Definitions ......................................... 2 3. Overview .................................................... 3 3.1 Applying MIB II to managing SNA NAUs ....................... 4 3.2 SNANAU MIB Structure ....................................... 4 3.2.1 snaNode group ............................................ 5 3.2.2 snaLu group .............................................. 6 3.2.3 snaMgtTools group ........................................ 7 3.2.4 Conformance statement .................................... 7 3.3 SNANAU MIB special feature ................................. 7 3.3.1 Row Creation mechanism ................................... 8 3.3.2 State Diagrams ........................................... 8 4. Object Definitions .......................................... 9 5. Acknowledgments ............................................. 66 6. References .................................................. 66 7. Security Considerations ..................................... 67 8. Authors' Addresses .......................................... 67
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 managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This memo identifies managed objects for PU Type 1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic objects defined here can also be used to manage LU 6.2 and any LU-LU session. The SNA terms and overall architecture are documented in [1]. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [2] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [3] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [4] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [5] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI (RFC 1442 [2]). In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type.
3. Overview This document identifies the proposed set of objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. In this document, the name "Node" is used to describe SNA Node Type 1.0, 2.0 and Type 2.1 and the name "LU" is used to describe Logical Unit of Type 0, 1, 2, 3, 4, 7 and 6.2. Note however that only objects common to all PU and LU types are covered here and LU 6.2 specific objects are not included in this MIB module. Highlights of the management functions supported by the SNANAU MIB module include the following: o Creation/deletion of Nodes and LUs via the RowStatus objects in the snaNodeAdminTable and in the snaLuAdminTable. o Creation/deletion of table entries associating Node instances with link instances via the RowStatus object in the snaNodeLinkAdminTable o Activation/Deactivation of Nodes via the AdminState object in the snaNodeAdminTable o Deactivation of sessions via the AdminState object in the snaLuSessnTable o Monitoring and modification of parameters related to Nodes, LUs, and Node/link associations o Monitoring of session operational parameters o PU2.0 operational statistics o Session operational statistics o RTM statistics o Traps for: + Node state change + Node activation failure + LU state change + LU session BIND failure
This MIB module does not support: o creation of links - the SNA DLC MIB [6] supports management capabilities for links, o activation or deactivation of LUs, nor o activation of sessions. 3.1. Applying MIB II to managing SNA NAUs This section identifies how MIB II objects, specifically the MIB II system group will be used in SNMP-based management of SNA NAUs. The MIB II system group applies to the SNMP Agent. The following object is from the MIB II system group: sysUpTime: clock in the SNMP Agent/proxy-Agent; expressed in TimeTicks (1/100s of a seconds). This MIB module uses the TimeStamp TEXTUAL-CONVENTION which is defined in the SNMPv2 Textual Conventions (RFC 1443 [7]) as "the value of MIB II's sysUpTime object when a specific occurrence happens." The specific occurrences related to SNA NAU management are defined in this MIB module. 3.2. SNANAU MIB Structure The SNANAU MIB module contains three groups of objects: o snaNode - objects related to Node configuration, monitoring and control. o snaLu - objects related to LU definition, monitoring and control. o snaMgtTools - objects related to specific management tools well known in SNA environment. These groups are described below in more detail. The objects related to PUs and LUs are organized into two types of tables: the Admin and Oper tables. The "Admin" table contains parameters which are used by a Management Station to affect the operation of the SNA service. Some parameters are used to initialize and configure the SNA service at the next startup, while others can take effect immediately. A Management Station can dynamically define SNA resources (PUs, LUs) by creating
new entries in the Admin table. It uses a special object, AdminState, to control the desired state of a defined PU or LU Session resource. Note that this MIB does not allow the manipulation of an LU's operational state. The "Oper" table is an extension (augment) of the corresponding Admin table. It contains objects which correspond to the values of parameters currently used by the SNA system. 3.2.1. snaNode group The snaNode group consists of the following tables: 1) snaNodeAdminTable This table contains objects which describe the configuration parameters of an SNA Node. Link-specific configuration objects are contained in a separate MIB module (e.g., the SNA DLC MIB module) corresponding to link type. Entries in this table can be created, modified and deleted by either an Agent or a Management Station. The snaNodeAdminRowStatus object describes the status of an entry and is used to change the status of that entry. The snaNodeAdminState object describes the desired operational state of a Node and is used to change the operational state of a Node. How an Agent or a Management Station obtains the initial value of each object at creation time is an implementation specific issue not addressed in this memo. For each entry in the snaNodeAdminTable, there is a corresponding entry in the snaNodeOperTable. While the objects in this table describe the desired or configured operational values of the SNA Node, the actual runtime values are contained in snaNodeOperTable. 2) snaNodeOperTable - Each row contains runtime and operational state variables for a Node. It is an extension of snaNodeAdminTable and as such uses the same index. The rows in this table are created by an Agent as soon as the entry in the Admin Table become 'active'. The entries in this table cannot be modified by a Management Station. 3) snaPu20StatsTable - Each row contains statistics variables (counters) for a PU 2.0. The entries in this table are indexed by snaNodeAdminIndex. The rows in this table are created by an Agent as soon as the corresponding entry in the snaNodeAdminTable becomes 'active'.
4) snaNodeLinkAdminTable - This table contains all references to
link- specific tables. If a Node is configured with multiple
links, then it will have multiple entries in this table. The
entries in this table can be generated initially, after startup of
SNA service, by the Agent which uses information from Node
configuration file. Subsequent modifications of parameters,
creation of new Node link entries and deletion of entries is
possible. The modifications to this table can be saved in the Node
configuration file for the next startup (i.e., restart or next
initialization) of SNA service, but the mechanism for this
function is not defined in this memo. Each entry contains the
configuration information that associates a Node instance to one
link instance. The entries are indexed by snaNodeAdminIndex and
snaNodeLinkAdminIndex.
5) snaNodeLinkOperTable - This table contains all references to
link- specific tables for operational parameters. If the Node is
configured for multiple links, then it will have multiple entries
in this table. This table augments the snaNodeLinkAdminTable.
6) snaNodeTraps - Two traps are defined for Nodes. The
snaNodeStateChangeTrap indicates that the operational state of a
Node has changed. The snaNodeActFailTrap indicates the failure of
ACTPU received from host.
3.2.2. snaLu group
The snaLu group consists of the following tables:
1) snaLuAdminTable - Table containing LU configuration
information. The rows in this table can be created and deleted by
a Management Station. Only objects which are common to all types
of LUs are included in this table. The entries are indexed by Node
and LU indices.
2) snaLuOperTable - Table containing dynamic runtime information
and control variables relating to LUs. Only objects which are
common to all types of LUs are included in this table. This table
augments the snaLuAdminTable.
3) snaLuSessnTable - This is a table containing objects which
describe the operational state of LU-LU sessions. Only objects
which are common to all types of LU-LU sessions are included in
this table. When a session enters the state 'pending-bind (2)',
the corresponding entry in the session table is created by the
Agent. When the session state becomes 'unbound (1)', then the
session will be removed from the session table by the Agent.
Entries are indexed by Node, Link, LU and session indices.
4) snaLuSessnStatsTable - Table containing dynamic statistics
information relating to LU-LU sessions. The entries in this table
augment the entries in the snaLuSessnTable and cannot be created
by a Management Station.
5) snaLuTraps - Two traps are defined for LUs. The
snaLuStateChangeTrap indicates that the operational state of an LU
has changed. The snaLuSessnBindFailTrap indicates the failure of
a BIND request.
3.2.3. snaMgtTools group
This is an optional group. The snaMgtTools group consists of the
following table:
1) snaLuRtmTable Each row contains Response Time Monitor (RTM)
variables for an LU. The table is indexed by Node and LU indices.
Entries correspond to LU 2 entries in the snaLuAdminTable. A
Management Station can read collection of RTM statistics for a
given LU.
3.2.4. Conformance statement
Compliance of the SNMPv2 management entity to the SNANAU MIB is
defined in terms of following conformance units called groups.
Unconditionally mandatory groups: snaNodeGroup, snaLuGroup,
snaSessionGroup.
Conditionally mandatory groups: snaPu20Group - mandatory only for
those entities which implement PU type 2.0. The snaMgtToolsRtmGroup
- mandatory only for those entities which implement LU type 2 and
RTM.
Refinement of requirements for objects access: an Agent which does
not implement row creation for snaNodeAdminTable
snaNodeLinkAdminTable and snaLuAdminTable must at least support
object modification requests (i.e., read-write access instead of
read-create).
3.3. SNANAU MIB special feature
This section describes the mechanism used for row creation in the
Admin tables and also presents critical state transitions for PUs,
LUs and Sessions.
3.3.1. Row Creation mechanism The row creation mechanism for the Admin tables in this MIB module is based on the use of the RowStatus object. Restriction of some operations for specific tables are described in each table. In particular, before accepting the 'destroy' value for an entry, an Agent has to verify the operational state of the corresponding entry in the Oper table. 3.3.2. State Diagrams The following state diagram models the state transitions for Nodes. When a row is created by a Management Station, an Agent creates the Oper table entry for that Node with the OperState equal to 'inactive'. An Agent cannot accept any operations for that Node until the RowStatus is set to 'active'. OperState -> inactive active waiting stopping --------------I--------------I--------------I-------------I--------- AdminState: I I I I active I active I active I waiting I no I I I I inactive I inactive I stopping I inactive I stopping I or inactive I The following state diagram models state transitions for Sessions. When a session goes to the 'unbound' state [1], the corresponding entry will be removed from the Session table by the Agent. OperState -> unbound pending-bind bound pending-unbind --------------I--------------I--------------I---------I-------------- AdminState: I I I I bound I no I no I no I no I I I I unbound I unbound I unbound I unbound I unbound
(next page on part 2)
