Network Working Group                                  D. Throop, Editor
Request for Comments: 1382                      Data General Corporation
                                                           November 1992


              SNMP MIB Extension for the X.25 Packet Layer

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing the Packet Layer of
   X.25.  The objects defined here, along with the objects in the "SNMP
   MIB Extension for LAPB" [9] and the "Definitions of Managed Objects
   for RS-232-like Hardware Devices" [8], combine to allow management of
   an X.25 protocol stack.

Table of Contents

   1. The Network Management Framework .......................    2
   2. Objects ................................................    2
   2.1 Format of Definitions .................................    3
   3. Overview ...............................................    3
   3.1 Informal Overview .....................................    3
   3.2 Textual Conventions ...................................    4
   3.3 Structure of MIB ......................................    4
   3.4 Tables ................................................    5
   3.5 Table Usage ...........................................    6
   3.6 Conformance ...........................................    6
   4. Object Definitions .....................................    7
   5. Appendix: Revision History .............................   62
      July 30 1992 ...........................................   62
      June 26 1992 ...........................................   62
      June 1992 ..............................................   63
      April 1992 .............................................   63
      February 1992 ..........................................   65
      October 1991 ...........................................   65
      June 1991 ..............................................   66
      April 1991 .............................................   66
   6. Acknowledgements .......................................   66

   7. References .............................................   67
   8. Security Considerations ................................   68
   9. Author's Address .......................................   69

1.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  These components give the rules for defining objects,
   the definitions of objects, and the protocol for manipulating
   objects.

   The network management framework structures objects in an abstract
   information tree. The branches of the tree name objects and the
   leaves of the tree contain the values manipulated to effect
   management. This tree is called the Management Information Base or
   MIB. The concepts of this tree are given in STD 16/RFC 1155, "The
   Structure of Management Information" or SMI [1]. The SMI defines the
   trunk of the tree and the types of objects used when defining the
   leaves. STD 16/RFC 1212, "Towards Concise MIB Definitions" [4],
   defines a more concise description mechanism that preserves all the
   principals of the SMI.

   The core MIB definitions for the Internet suite of protocols can be
   found in RFC 1156 [2] "Management Information Base for Network
   Management of TCP/IP-based internets". STD 17/RFC 1213 [5] defines
   MIB-II, an evolution of MIB-I with changes to incorporate
   implementation experience and new operational requirements.

   STD 15/RFC 1157 [3] defines the SNMP protocol itself. The protocol
   defines how to manipulate the objects in a remote MIB.

   The tree structure of the MIB allows new objects to be defined for
   the purpose of experimentation and evaluation.

2.  Objects

   The definition of an object in the MIB requires an object name and
   type.  Object names and types are defined using the subset of
   Abstract Syntax Notation One (ASN.1) [6] defined in the SMI [1].
   Objects are named using ASN.1 object identifiers, administratively
   assigned names, to specify object types.  The object name, together
   with an optional object instance, uniquely identifies a specific
   instance of an object.  For human convenience, we often use a textual
   string, termed the OBJECT DESCRIPTOR, to also refer to objects.

   Objects also have a syntax that defines the abstract data structure
   corresponding to that object type.  The ASN.1 language [6] provides
   the primitives used for this purpose.  The SMI [1] purposely

   restricts the ASN.1 constructs which may be used for simplicity and
   ease of implementation.  The encoding of an object type simply
   describes how to represent an object using ASN.1 encoding rules [7],
   for purposes of dealing with the SNMP protocol.

2.1.  Format of Definitions

   Section 4 contains the specification of all object types defined in
   this MIB module.  The object types are defined using the conventions
   defined in the SMI, as amended by the extensions specified in
   "Towards Concise MIB Definitions" [4].

3.  Overview

3.1.  Informal Overview

   This section describes how the objects defined below relate with
   other MIBs.  This section is only informational to help understand
   how the pieces fit together.

   The objects defined below are used in conjunction with MIB-II and
   other MIBs such as the LAPB MIB [9].  A system with a complete X.25
   stack running over a synchronous line will have at least two
   interfaces in the ifTable defined in MIB-II.  There will be an
   interface for LAPB and another interface for the packet layer of
   X.25. There will also be objects defined in the RS-232-like MIB for
   the physical sync line.

   Each software interface identifies the layer below it used to send
   and receive packets. The X.25 MIB object, defined below,
   x25OperDataLinkId, specifies an instance of lapbAdmnIndex for the
   LAPB interface under that X.25. The LAPB object, lapbOperPortId,
   identifies an instance of the rs232PortIndex for the the Sync line
   used by LAPB.

   For X.25 running over LAPB over Ethernet, the lapbOperPortId would
   identify the instance of ifIndex for the Ethernet interface.

   Each X.25 subnetwork will have separate entries in the ifTable.  Thus
   a system with two X.25 lines would have two ifTable entries for the
   two X.25 packet layers and two other entries for the two LAPB
   interfaces. Each X.25 Packet Layer MIB would identify the instance of
   the LAPB MIB for the interface below it. Each LAPB MIB would identify
   the Sync line below it. The system would also have two entries in the
   rs232PortTable and rs232SyncPortTable for the two physical lines.

   Since the ifTable as defined in MIB-II is device independent, it
   doesn't have anything specific for any type of interface.  The

   objects below define the X.25 packet layer specific information for
   an interface of type X.25. Different X.25 interfaces can also be
   differentiated by matching the values of ifIndex with x25AdmnIndex.

3.2.  Textual Conventions

   This MIB introduces a new data type as a textual convention for use
   with X.25.  This textual convention enhances the readability of the
   specification and can ease comparison with other specifications if
   appropriate.  It should be noted that the introduction of such
   textual conventions has no effect on either the syntax nor the
   semantics of any managed objects.  These conventions are merely an
   artifact of the explanatory method used.  Objects defined in terms of
   one of these methods are always encoded by means of the rules that
   define the primitive type.  Hence, no changes to the SMI or the SNMP
   are necessary to accommodate these textual conventions which are
   adopted merely for the convenience of readers and writers in pursuit
   of the elusive goal of clear, concise, and unambiguous MIB documents.

   This MIB introduces the data type of:

                       X121Address

3.3.  Structure of MIB

   Instances of the objects defined below represent attributes of an
   X.25 Packet Layer interface.  At present these interfaces are
   identified by an ifType object in the Internet-standard MIB-II [5]
   of:

                 ddn-x25(4), and
                 rfc887-x25(5).

   For these interfaces, the value of the ifSpecific variable in the
   MIB-II [5] has the OBJECT IDENTIFIER value:

                 x25    OBJECT IDENTIFIER ::= { transmission 5 }

   The objects defined below are similar to those defined in a draft ISO
   document for X.25 management [11]. Some object definitions also
   reference the ISO specification for X.25 [10] to specify  the section
   that will give the reader additional information about the object.
   Access to those documents maybe useful (but isn't essential) to
   understand the names and semantics of some objects.  The similarity
   of these objects with the ISO objects minimizes the instrumentation
   required by those systems that support both OSI and TCP/IP management
   protocols.

   Since the objects defined here are extensions to the Internet
   Standard MIB [2] and thus also an extension of the second version,
   MIB-II [5], the objects defined here explicitly do not duplicate
   objects defined in existing standards.  In some instances
   clarification of how to apply those objects has been given.

   The relationship between an X.25 Packet Layer interface and an
   interface in the context of the Internet-standard MIB [5] is one-to-
   one. As such, the value of an ifIndex object instance can be directly
   used to identify corresponding instances of the objects defined
   below.

3.4.  Tables

   The objects below form several tables.  These tables are:

                               x25AdmnTable
                               x25OperTable
                               x25StatTable
                               x25ChannelTable
                               x25CircuitTable
                               x25ClearedCircuitTable
                               x25CallParmTable

   The x25AdmnTable defines objects for the parameters of an X.25
   interface which the administrator can read and set.  These objects
   are used at interface initialization time to start the interface.
   Once the interface has started, changes to the objects in the
   Administration table may not take affect until the interface is re-
   initialized.

   The x25OperTable defines objects that report the current parameters
   used by a running interface.  These objects are read-only.

   The x25StatTable defines objects that report operational statistics
   for an X.25 interface.  These are read-only counters of events that
   occurred at the interface.

   The x25ChannelTable defines objects to allow the administrator to
   manage the division of channel numbers.

   The x25CircuitTable defines objects that return information about
   existing X.25 circuits.  These entries result from calls placed or
   answered by the PLE or from PVCs.

   The x25ClearedCircuitTable contains objects for recording the
   termination information from circuits that cleared abnormally.

   The x25CallParmTable defines the call parameters used to call other
   systems.  This table contains call parameter entries which are
   referenced by other tables.  For example, the x25AdmnTable has one
   object that identifies the entry in the table for the default PLE
   parameters.  The x25CircuitTable has one object that identifies the
   entry in the x25CallParmTable for the parameters in use by that
   circuit.  Other MIBs may also reference entries to identify call
   parameters to use to make X.25 calls.

3.5.  Table Usage

   Different tables provide different functions.  The administrator sets
   the starting X.25 parameters in the x25AdmnTable for the X.25 PLE;
   these objects include a reference to the x25CallParmTable entry to
   identify the default call parameters for the PLE.  Once all the
   parameters are set, the administrator initializes the interface.  As
   part of initializing the interface, the operating parameters are
   copied into the interface from the x25AdmnTable; these parameters are
   viewable by getting the objects in the x25OperTable.  (The interface
   maybe started by setting the value of ifAdminStatus to up.)  If any
   PVCs are configured, their parameters can be set in the the
   x25CircuitTable before initializing the interface; this should be
   done in conjunction with configuring higher layer entities to use the
   PVCs via the MIBs for those entities.

   Once the PLE completes initialization, it makes additional entries in
   the x25circuitTable for calls placed or answered.  When a circuit is
   cleared, the status of the entry for the circuit is set to closed
   and, if the clear is abnormal, an entry will also be made in the
   x25ClearedCircuitTable.  An entry in the x25CircuitTable with a
   status of closed maybe deleted by the agent at its convenience.  A
   closed entry will always be reused at the time the PLE re-allocates
   the channel number of the entry for another call.  The call
   parameters used for a circuit can be found by looking in the
   x25CircuitTable and following the x25CircuitCallParamId pointer to
   the entry in the x25CallParmTable that contains the parameters.

   There are no mechanisms in the X.25 MIB for telling the PLE to place
   an X.25 call. Such mechanisms belong in the MIBs for the higher layer
   entities that use the X.25 circuits.

3.6.  Conformance

   All the objects defined here are mandatory. To claim conformance with
   this MIB an implementation must support all objects.  However some
   objects pertain to features that are optional.  There are values
   defined for those objects that indicate the implementation does not
   support the optional feature.  The agent for such an implementation

   must support reading the object and return the value that indicates
   the optional feature isn't supported and reject set requests to
   change the object.

   Some optional features have more than one object that pertain to it
   (window rotation has a timer, a count, and a counter for timer
   runouts).  In such case, any object which indicates the optional
   feature isn't supported is sufficient to indicate the feature isn't
   supported and the values of the other objects relative to that
   feature are undefined.