Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1666

Definitions of Managed Objects for SNA NAUs using SMIv2

Pages: 68
Historic
Obsoletes:  1665
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC1666 - Page 1
Network Working Group                                    Z. Kielczewski
Request for Comments: 1666                 Eicon Technology Corporation
Obsoletes: 1665                                              D. Kostick
Category: Standards Track                  Bell Communications Research
                                                                K. Shih
                                                                 Novell
                                                                Editors
                                                            August 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 .............................................   67
   6. References ..................................................   67
   7. Security Considerations .....................................   68
   8. Authors' Addresses ..........................................   68
Top   ToC   RFC1666 - Page 2
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.
Top   ToC   RFC1666 - Page 3
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
Top   ToC   RFC1666 - Page 4
   This MIB module does not support:

   o    creation of 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 [6]) 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,
Top   ToC   RFC1666 - Page 5
   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'.
Top   ToC   RFC1666 - Page 6
      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's snaLuSessnOperState value changes to
      entry in the session table is created by the Agent.  When the
      snaLuSessionOperState value changes to will be removed from the
      session table by the Agent.  Entries are indexed by Node, local
      LU, remote LU and session indices.
Top   ToC   RFC1666 - Page 7
      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.
Top   ToC   RFC1666 - Page 8
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        pendingBind   bound      pendingUnbind
   --------------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)

Next Section