rfc1381.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,613 行 · 第 1/5 页

Network Working Group                                          D. Throop
Request for Comments: 1381                      Data General Corporation
                                                                F. Baker
                                        Advanced Computer Communications
                                                           November 1992


                    SNMP MIB Extension for X.25 LAPB

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 Link Layer of
   X.25, LAPB.  The objects defined here, along with the objects in the
   "SNMP MIB Extension for the Packet Layer of X.25" [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 Formal overview .......................................    4
   3.4 Tables ................................................    5
   3.5 Traps .................................................    6
   4. Object Definitions .....................................    6
   5. Appendix: Revision History .............................   27
      July 30, 1992 ..........................................   27
      June 12, 1992 ..........................................   27
      May 18, 1992 ...........................................   28
      April 8, 1992 ..........................................   28
      February 1992 ..........................................   28
      October 1991 ...........................................   29
      June 1991 ..............................................   30
      April 1991 .............................................   30



Throop & Baker                                                  [Page 1]

RFC 1381                     X.25 LAPB MIB                 November 1992


   6. Acknowledgements .......................................   30
   7. References .............................................   31
   8. Security Considerations ................................   33
   9. Authors' Addresses .....................................   33

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 the
   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



Throop & Baker                                                  [Page 2]

RFC 1381                     X.25 LAPB MIB                 November 1992


   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 definitions use the conventions given in
   the SMI [1] as amended by the 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 to be used in conjunction with MIB-II
   and other MIBs such as the X.25 packet level 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, x25InfoDataLinkId,
   specifies an instance of lapbAdmnIndex for the LAPB interface under
   that X.25. The LAPB object, lapbOperPortId, defined below, identifies
   an instance of the rs232PortIndex for the the Sync line used by LAPB.

   For X.25 running over LAPB over Ethernet, the lapbAdmnPortId 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 below it. Each LAPB MIB would identify the Sync line
   below it. The system would also have two entries for 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 LAPB specific information for an interface



Throop & Baker                                                  [Page 3]

RFC 1381                     X.25 LAPB MIB                 November 1992


   of type LAPB. Different LAPB interfaces can also be differentiated by
   matching the values of ifIndex with lapbAdmnIndex.

3.2.  Textual Conventions

   Two new data types are introduced as a textual conventions in this
   MIB document.  These textual conventions enhance the readability of
   the specification and can ease comparison with other specifications
   if appropriate.  It should be noted that the introduction of these
   textual conventions has no effect on either the syntax nor the
   semantics of any managed objects.  The use of these is 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 types of:

                    PositiveInteger
                    ifIndexType

3.3.  Formal overview

   Instances of the objects defined below represent attributes of a LAPB
   interface.  LAPB interfaces are identified by an ifType object in the
   Internet-standard MIB [5] of

                lapb(16).

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

                lapb    OBJECT IDENTIFIER ::= { transmission 16 }

   The relationship between a LAPB 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.

   The objects defined below are defined in the context of ISO 7776 [10]
   and ISO 8885 [11]. Access to those documents maybe useful (but isn't
   essential) to understand the names and semantics of some objects.
   Where possible the object descriptions use the terminology of ISO
   7776; for example, one commonly used term refers to the peer LAPB as
   the DCE/remote DTE.  This terminology does not restrict the
   instrumented LAPB to function only as a DTE.  This MIB maybe applied



Throop & Baker                                                  [Page 4]

RFC 1381                     X.25 LAPB MIB                 November 1992


   to a LAPB configured as either a DCE or a DTE.

   To the extent that some attributes defined in the Internet standard
   MIB [5] are applicable to LAPB, those objects have not been
   duplicated here.  In some instances some clarification of how to
   apply those objects to LAPB has been given.

   Some objects defined below include a DEFVAL clause. This clause
   provides reasonable (but not mandatory) default values to use when
   creating these objects.  This does not imply this MIB defines any
   mechanism for creating or deleting LAPB interfaces.  The creation and
   deletion of the objects of this MIB depend on the implementation
   method for creating and deleting LAPB interfaces.  The DEFVAL clause
   provides reasonable defaults to allow further extension of the MIB to
   define methods for creating and deleting LAPB interfaces without
   having to deprecate these objects for the lack of a DEFVAL clause.

3.4.  Tables

   This extension adds four tables to the MIB.  These tables are:

                       lapbAdmnTable,
                       lapbOperTable,
                       lapbFlowTable, and
                       lapbXidTable.

   The lapbAdmnTable provides objects for common parameters used by LAPB
   such as the T1 retransmission timer or the N2 retransmission counter.
   Changes to objects in this table need not affect a running interface
   but provides access to the values used to initialize an interface.
   These values are read-write.

   The lapbOperTable provides objects to determine the parameters
   actually in use by an interface.  These objects are read only.  The
   values currently in use maybe different from the lapbAdmnTable values
   if the lapbAdmnTable was changed after interface initialization or if
   XID negotiation selected different values.

   The lapbFlowTable provides objects that report how the LAPB interface
   performs.  These are read-only objects used to monitor operation.

   The lapbXidTable is not required for systems that do not transmit XID
   frames. For systems that do transmit XID frames, this table provides
   the values for the fields of the XID frame that are not already
   present in the lapbAdmnTable.  The objects in this table are read-
   write.





Throop & Baker                                                  [Page 5]

RFC 1381                     X.25 LAPB MIB                 November 1992


3.5.  Traps

   Since all LAPB interfaces have entries in the ifTable, significant
   changes in the state of the interface should send a linkUp or
   linkDown trap. Thus an interface that receives or sends a Frame
   Reject frame should send a linkDown trap.  If the interface later
   comes back up, it should then send a linkUP trap.

4.  Object Definitions


          RFC1381-MIB DEFINITIONS ::= BEGIN

          IMPORTS
                  Counter
                          FROM RFC1155-SMI
                  transmission
                          FROM RFC1213-MIB
                  OBJECT-TYPE
                          FROM RFC-1212;


                          --  LAPB MIB

          lapb    OBJECT IDENTIFIER ::= { transmission 16 }

          PositiveInteger ::= INTEGER (0..2147483647)

          IfIndexType     ::= INTEGER (1..2147483647)
          -- IfIndexType specifies an index object for a table
          -- with entries that match entries in the MIB-II ifTable.
          -- The value of the index for the table will match the
          -- ifIndex entry for same interface in the ifTable.
          -- The values of this object range from 1 to ifNumber
          -- inclusive.