rfc1229.txt

RFC 的详细文档！

Network Working Group                              K. McCloghrie, Editor
Request for Comments: 1229                      Hughes LAN Systems, Inc.
                                                                May 1991


                Extensions to the Generic-Interface MIB

Status of this Memo

   This RFC contains definitions of managed objects used as experimental
   extensions to the generic interfaces structure of MIB-II.  This memo
   is a product of the SNMP Working Group of the Internet Engineering
   Task Force (IETF).  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.

Table of Contents

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    1
   3. Objects ...............................................    2
   4. Overview ..............................................    3
   4.1 Generic Interface Extension Table ....................    3
   4.2 Generic Interface Test Table .........................    3
   4.3 Generic Receive Address Table ........................    4
   5. Definitions ...........................................    5
   6. Acknowledgements ......................................   14
   7. References ............................................   15
   8. Security Considerations................................   15
   9. Author's Address.......................................   16

1.  Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.  In particular, it defines managed object
   types as experimental extensions to the generic interfaces structure
   of MIB-II.

2.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      RFC 1155 which defines the SMI, the mechanisms used for describing
      and naming objects for the purpose of management.  RFC 1212



SNMP Working Group                                              [Page 1]

RFC 1229                Interface MIB Extensions                May 1991


      defines a more concise description mechanism, which is wholly
      consistent with the SMI.

      RFC 1156 which defines MIB-I, the core set of managed objects for
      the Internet suite of protocols.  RFC 1213, defines MIB-II, an
      evolution of MIB-I based on implementation experience and new
      operational requirements.

      RFC 1157 which defines the SNMP, the protocol used for network
      access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

3.  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) [7]
   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 [3] 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 [8],
   subject to the additional requirements imposed by the SNMP.

   Section 5 contains the specification of all object types in this
   section of the MIB.  The object types are defined using the
   conventions specified in the SMI, as amended by the extensions
   specified in [9].






SNMP Working Group                                              [Page 2]

RFC 1229                Interface MIB Extensions                May 1991


4.  Overview

   The Internet Standard MIB [4,6] contains a group of management
   objects pertaining to a network device's generic network
   interface(s).  These objects are generic in the sense that they apply
   to all network interfaces, irrespective of the type of communication
   media and protocols used on such interfaces.  This has proved to be
   necessary but not sufficient; there are efforts underway to define
   additional MIB objects which are specific to particular media and
   lower-level (subnetwork-layer and below) protocol stacks.

   However, some of these efforts have identified objects which are
   required (or at least useful), but are not specific to the
   interface-type on which the effort is focusing.  In order to avoid
   redundancy, it is better that such objects be defined as extensions
   to the generic interface group, rather than defined in multiple
   specific-interface-type MIBs.

   This memo defines the resultant extensions to the generic interface
   group.  These extensions are spread over three tables: the generic
   Interface Extension table, the generic Interface Test table, and the
   generic Receive Address table.

4.1.  Generic Interface Extension Table

   This table consists of new objects applicable to all types of
   subnetwork interface.

4.2.  Generic Interface Test Table

   This section defines objects which allow a network manager to
   instruct an agent to test an interface for various faults.  A few
   common types of tests are defined in this document but most will be
   defined elsewhere, dependent on the particular type of interface.
   After testing, the object ifExtnsTestResult can be read to determine
   the outcome.  If an agent cannot perform the test, ifExtnsTestResult
   is set to so indicate.  The object ifExtnsTestCode can be used to
   provide further test-specific or interface-specific (or even
   enterprise-specific) information concerning the outcome of the test.
   Only one test can be in progress on each interface at any one time.
   If one test is in progress when another test is invoked, the second
   test is rejected.  Some agents may reject a test when a prior test is
   active on another interface.

   When a test is invoked, the identity of the originator of the request
   and the request-id are saved by the agent in the objects
   ifExtnsTestRequestId and ifExtnsTestCommunity.  These values remain
   set until the next test is invoked.  In the (rare) event that the



SNMP Working Group                                              [Page 3]

RFC 1229                Interface MIB Extensions                May 1991


   invocation of tests by two network managers were to overlap, then
   there would be a possibility that the first test's results might be
   overwritten by the second test's results prior to the first results
   being read.  This unlikely circumstance can be detected by a network
   manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId at
   the same time as the test results are retrieved, and ensuring that
   the results are for the desired request.

   In general, a Management station must not retransmit a request to
   invoke a test for which it does not receive a response; instead, it
   properly inspects an agent's MIB to determine if the invocation was
   successful.  The invocation request is retransmitted only if the
   invocation was unsuccessful.

   Some tests may require the interface to be taken off-line or may even
   require the agent to be rebooted after completion of the test.  In
   these circumstances, communication with the management station
   invoking the test may be lost until after completion of the test.
   The agent should make every effort to transmit a response to the
   request that invoked the test prior to losing communication.  When
   the agent is restored to normal service, the results of the test are
   properly made available in the appropriate objects.  Note that this
   requires that the ifIndex value assigned to an interface must be
   unchanged even if the test causes a reboot.  An agent must reject any
   test for which it cannot, perhaps due to resource constraints, make
   available at least the minimum amount of information after that test
   completes.

4.3.  Generic Receive Address Table

   This table contains objects relating to an interface's support for
   receiving packets/frames at more than one address on the same
   interface.


















SNMP Working Group                                              [Page 4]

RFC 1229                Interface MIB Extensions                May 1991


5.  Definitions


          RFC1229-MIB DEFINITIONS ::= BEGIN


          --        Extensions to MIB-II's Generic Interface Table

          IMPORTS
                  experimental, Counter         FROM RFC1155-SMI
                  DisplayString, PhysAddress    FROM RFC1213-MIB
                  OBJECT-TYPE                   FROM RFC-1212;



          ifExtensions  OBJECT IDENTIFIER ::= { experimental 6 }


          --   Generic Interface Extension Table
          --
          --  This group of objects is mandatory for all types of
          --  subnetwork interface.

          ifExtnsTable  OBJECT-TYPE
                  SYNTAX SEQUENCE OF IfExtnsEntry
                  ACCESS not-accessible
                  STATUS mandatory
                  DESCRIPTION
                         "A list of interfaces extension entries.
                          The number of entries is given by the value
                          of ifNumber, defined in [4,6]."
                  ::= { ifExtensions 1 }

          ifExtnsEntry  OBJECT-TYPE
                  SYNTAX IfExtnsEntry
                  ACCESS not-accessible
                  STATUS mandatory
                  DESCRIPTION
                         "An extension to the interfaces entry,
                          defined in [4,6], containing additional
                          objects at the subnetwork layer and below
                          for a particular interface."
                  INDEX  { ifExtnsIfIndex }
                  ::= { ifExtnsTable 1 }

          IfExtnsEntry ::=
                  SEQUENCE {
                      ifExtnsIfIndex



SNMP Working Group                                              [Page 5]

RFC 1229                Interface MIB Extensions                May 1991


                          INTEGER,
                      ifExtnsChipSet
                          OBJECT IDENTIFIER,
                      ifExtnsRevWare
                          DisplayString,
                      ifExtnsMulticastsTransmittedOks
                          Counter,
                      ifExtnsBroadcastsTransmittedOks
                          Counter,
                      ifExtnsMulticastsReceivedOks
                          Counter,
                      ifExtnsBroadcastsReceivedOks
                          Counter,
                      ifExtnsPromiscuous