rfc1213.txt

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

   Two new objects are added to the IP group:

      ipNetToMediaTable
      ipRoutingDiscards

   the first is the address translation table for the IP group
   (providing identical functionality to the now deprecated atTable in
   the address translation group), and the latter provides information
   when routes are lost due to a lack of buffer space.

3.8.  The ICMP Group

   There are no changes to this group.

3.9.  The TCP Group

   Two new variables are added:

      tcpInErrs
      tcpOutRsts

   which keep track of the number of incoming TCP segments in error and
   the number of resets generated by a TCP.

3.10.  The UDP Group

   A new table:

      udpTable

   is added.

3.11.  The EGP Group

   Experience has indicated a need for additional objects that are
   useful in EGP monitoring.  In addition to making several additions to
   the egpNeighborTable object, i.e.,

      egpNeighAs
      egpNeighInMsgs
      egpNeighInErrs
      egpNeighOutMsgs
      egpNeighOutErrs
      egpNeighInErrMsgs
      egpNeighOutErrMsgs



SNMP Working Group                                              [Page 7]

RFC 1213                         MIB-II                       March 1991


      egpNeighStateUps
      egpNeighStateDowns
      egpNeighIntervalHello
      egpNeighIntervalPoll
      egpNeighMode
      egpNeighEventTrigger

   a new variable is added:

      egpAs

   which gives the autonomous system associated with this EGP entity.

3.12.  The Transmission Group

   MIB-I was lacking in that it did not distinguish between different
   types of transmission media.  A new group, the Transmission group, is
   allocated for this purpose:

      transmission OBJECT IDENTIFIER ::= { mib-2 10 }

   When Internet-standard definitions for managing transmission media
   are defined, the transmission group is used to provide a prefix for
   the names of those objects.

   Typically, such definitions reside in the experimental portion of the
   MIB until they are "proven", then as a part of the Internet
   standardization process, the definitions are accordingly elevated and
   a new object identifier, under the transmission group is defined.  By
   convention, the name assigned is:

      type OBJECT IDENTIFIER ::= { transmission number }

   where "type" is the symbolic value used for the media in the ifType
   column of the ifTable object, and "number" is the actual integer
   value corresponding to the symbol.

3.13.  The SNMP Group

   The application-oriented working groups of the IETF have been tasked
   to be receptive towards defining MIB variables specific to their
   respective applications.

   For the SNMP, it is useful to have statistical information.  A new
   group, the SNMP group, is allocated for this purpose:

      snmp   OBJECT IDENTIFIER ::= { mib-2 11 }




SNMP Working Group                                              [Page 8]

RFC 1213                         MIB-II                       March 1991


3.14.  Changes from RFC 1158

   Features of this MIB include:

   (1)  The managed objects in this document have been defined
        using the conventions defined in the Internet-standard
        SMI, as amended by the extensions specified in [14].  It
        must be emphasized that definitions made using these
        extensions are semantically identically to those in RFC
        1158.

   (2)  The PhysAddress textual convention has been introduced to
        represent media addresses.

   (3)  The ACCESS clause of sysLocation is now read-write.

   (4)  The definition of sysServices has been clarified.

   (5)  New ifType values (29-32) have been defined.  In
        addition, the textual-descriptor for the DS1 and E1
        interface types has been corrected.

   (6)  The definition of ipForwarding has been clarified.

   (7)  The definition of ipRouteType has been clarified.

   (8)  The ipRouteMetric5 and ipRouteInfo objects have been
        defined.

   (9)  The ACCESS clause of tcpConnState is now read-write, to
        support deletion of the TCB associated with a TCP
        connection.  The definition of this object has been
        clarified to explain this usage.

   (10) The definition of egpNeighEventTrigger has been
        clarified.

   (11) The definition of several of the variables in the new
        snmp group have been clarified.  In addition, the
        snmpInBadTypes and snmpOutReadOnlys objects are no longer
        present.  (However, the object identifiers associated
        with those objects are reserved to prevent future use.)

   (12) The definition of snmpInReadOnlys has been clarified.

   (13) The textual descriptor of the snmpEnableAuthTraps has
        been changed to snmpEnableAuthenTraps, and the definition
        has been clarified.



SNMP Working Group                                              [Page 9]

RFC 1213                         MIB-II                       March 1991


   (14) The ipRoutingDiscards object was added.

   (15) The optional use of an implementation-dependent, small
        positive integer was disallowed when identifying
        instances of the IP address and routing tables.

4.  Objects

   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) [8]
   defined in the SMI.  In particular, each object has a name, a syntax,
   and an encoding.  The name is an object identifier, an
   administratively assigned name, which specifies an object type.  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 OBJECT
   DESCRIPTOR, to also refer to the object type.

   The syntax of an object type defines the abstract data structure
   corresponding to that object type.  The ASN.1 language is used for
   this purpose.  However, the SMI [12] purposely restricts the ASN.1
   constructs which may be used.  These restrictions are explicitly made
   for simplicity.

   The encoding of an object type is simply how that object type is
   represented using the object type's syntax.  Implicitly tied to the
   notion of an object type's syntax and encoding is how the object type
   is represented when being transmitted on the network.

   The SMI specifies the use of the basic encoding rules of ASN.1 [9],
   subject to the additional requirements imposed by the SNMP.

4.1.  Format of Definitions

   Section 6 contains contains the specification of all object types
   contained in this MIB module.  The object types are defined using the
   conventions defined in the SMI, as amended by the extensions
   specified in [14].

5.  Overview

   Consistent with the IAB directive to produce simple, workable systems
   in the short-term, the list of managed objects defined here, has been
   derived by taking only those elements which are considered essential.

   This approach of taking only the essential objects is NOT
   restrictive, since the SMI defined in the companion memo provides



SNMP Working Group                                             [Page 10]

RFC 1213                         MIB-II                       March 1991


   three extensibility mechanisms: one, the addition of new standard
   objects through the definitions of new versions of the MIB; two, the
   addition of widely-available but non-standard objects through the
   experimental subtree; and three, the addition of private objects
   through the enterprises subtree.  Such additional objects can not
   only be used for vendor-specific elements, but also for
   experimentation as required to further the knowledge of which other
   objects are essential.

   The design of MIB-II is heavily influenced by the first extensibility
   mechanism.  Several new variables have been added based on
   operational experience and need.  Based on this, the criteria for
   including an object in MIB-II are remarkably similar to the MIB-I
   criteria:

   (1)  An object needed to be essential for either fault or
        configuration management.

   (2)  Only weak control objects were permitted (by weak, it is
        meant that tampering with them can do only limited
        damage).  This criterion reflects the fact that the
        current management protocols are not sufficiently secure
        to do more powerful control operations.

   (3)  Evidence of current use and utility was required.

   (4)  In MIB-I, an attempt was made to limit the number of
        objects to about 100 to make it easier for vendors to
        fully instrument their software.  In MIB-II, this limit
        was raised given the wide technological base now
        implementing MIB-I.

   (5)  To avoid redundant variables, it was required that no
        object be included that can be derived from others in the
        MIB.

   (6)  Implementation specific objects (e.g., for BSD UNIX) were
        excluded.

   (7)  It was agreed to avoid heavily instrumenting critical
        sections of code.  The general guideline was one counter
        per critical section per layer.

   MIB-II, like its predecessor, the Internet-standard MIB, contains
   only essential elements.  There is no need to allow individual
   objects to be optional.  Rather, the objects are arranged into the
   following groups:




SNMP Working Group                                             [Page 11]

RFC 1213                         MIB-II                       March 1991


      - System
      - Interfaces
      - Address Translation (deprecated)
      - IP
      - ICMP
      - TCP
      - UDP
      - EGP
      - Transmission
      - SNMP

   These groups are the basic unit of conformance: This method is as
   follows: if the semantics of a group is applicable to an
   implementation, then it must implement all objects in that group.
   For example, an implementation must implement the EGP group if and
   only if it implements the EGP.

   There are two reasons for defining these groups: to provide a means
   of assigning object identifiers; and, to provide a method for
   implementations of managed agents to know which objects they must
   implement.

6.  Definitions

          RFC1213-MIB DEFINITIONS ::= BEGIN

          IMPORTS
                  mgmt, NetworkAddress, IpAddress, Counter, Gauge,
                          TimeTicks
                      FROM RFC1155-SMI
                  OBJECT-TYPE
                          FROM RFC-1212;

          --  This MIB module uses the extended OBJECT-TYPE macro as
          --  defined in [14];


          --  MIB-II (same prefix as MIB-I)

          mib-2      OBJECT IDENTIFIER ::= { mgmt 1 }

          -- textual conventions

          DisplayString ::=
              OCTET STRING
          -- This data type is used to model textual information taken
          -- from the NVT ASCII character set.  By convention, objects
          -- with this syntax are declared as having



SNMP Working Group                                             [Page 12]

RFC 1213                         MIB-II                       March 1991


          --
          --      SIZE (0..255)

          PhysAddress ::=
              OCTET STRING
          -- This data type is used to model media addresses.  For many
          -- types of media, this will be in a binary representation.
          -- For example, an ethernet address would be represented as
          -- a string of 6 octets.