rfc2863.txt

RFC 的详细文档！

   identify the "superior" and "subordinate" sub-layers through INTEGER
   "pointers" to the appropriate conceptual rows in the ifTable.  This
   solution supports both upward and downward multiplexing, allows the
   IANAifType to Media-Specific MIB mapping to identify the media-
   specific MIB module for that sub-layer, such that the new table need
   only be referenced to obtain information about layering, and it only
   requires enumerated values of ifType for each sub-layer, not for
   combinations of them.  However, it does require that the descriptions
   of some objects in the ifTable (specifically, ifType, ifPhysAddress,
   ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to
   any sub-layer (rather than only to a sub-layer immediately beneath



McCloghrie & Kastenholz     Standards Track                     [Page 5]

RFC 2863                The Interfaces Group MIB               June 2000


   the network layer as previously), plus some (specifically, ifSpeed)
   which need to have appropriate values identified for use when a
   generalized definition does not apply to a particular sub-layer.

   In addition, this adopted solution makes no requirement that a
   device, in which a sub-layer is instrumented by a conceptual row of
   the ifTable, be aware of whether an internetwork protocol runs on top
   of (i.e., at some layer above) that sub-layer.  In fact, the counters
   of packets received on an interface are defined as counting the
   number "delivered to a higher-layer protocol".  This meaning of
   "higher-layer" includes:

   (1)   Delivery to a forwarding module which accepts
         packets/frames/octets and forwards them on at the same protocol
         layer.  For example, for the purposes of this definition, the
         forwarding module of a MAC-layer bridge is considered as a
         "higher-layer" to the MAC-layer of each port on the bridge.

   (2)   Delivery to a higher sub-layer within a interface stack.  For
         example, for the purposes of this definition, if a PPP module
         operated directly over a serial interface, the PPP module would
         be considered the higher sub-layer to the serial interface.

   (3)   Delivery to a higher protocol layer which does not do packet
         forwarding for sub-layers that are "at the top of" the
         interface stack.  For example, for the purposes of this
         definition, the local IP module would be considered the higher
         layer to a SLIP serial interface.

   Similarly, for output, the counters of packets transmitted out an
   interface are defined as counting the number "that higher-level
   protocols requested to be transmitted".  This meaning of "higher-
   layer" includes:

   (1)   A forwarding module, at the same protocol layer, which
         transmits packets/frames/octets that were received on an
         different interface.  For example, for the purposes of this
         definition, the forwarding module of a MAC-layer bridge is
         considered as a "higher-layer" to the MAC-layer of each port on
         the bridge.

   (2)   The next higher sub-layer within an interface stack.  For
         example, for the purposes of this definition, if a PPP module
         operated directly over a serial interface, the PPP module would
         be a "higher layer" to the serial interface.






McCloghrie & Kastenholz     Standards Track                     [Page 6]

RFC 2863                The Interfaces Group MIB               June 2000


   (3)   For sub-layers that are "at the top of" the interface stack, a
         higher element in the network protocol stack.  For example, for
         the purposes of this definition, the local IP module would be
         considered the higher layer to an Ethernet interface.

3.1.2.  Guidance on Defining Sub-layers

   The designer of a media-specific MIB must decide whether to divide
   the interface into sub-layers or not, and if so, how to make the
   divisions.  The following guidance is offered to assist the media-
   specific MIB designer in these decisions.

   In general, the number of entries in the ifTable should be kept to
   the minimum required for network management.  In particular, a group
   of related interfaces should be treated as a single interface with
   one entry in the ifTable providing that:

   (1)   None of the group of interfaces performs multiplexing for any
         other interface in the agent,

   (2)   There is a meaningful and useful way for all of the ifTable's
         information (e.g., the counters, and the status variables), and
         all of the ifTable's capabilities (e.g., write access to
         ifAdminStatus), to apply to the group of interfaces as a whole.

   Under these circumstances, there should be one entry in the ifTable
   for such a group of interfaces, and any internal structure which
   needs to be represented to network management should be captured in a
   MIB module specific to the particular type of interface.

   Note that application of bullet 2 above to the ifTable's ifType
   object requires that there is a meaningful media-specific MIB and a
   meaningful ifType value which apply to the group of interfaces as a
   whole.  For example, it is not appropriate to treat an HDLC sub-layer
   and an RS-232 sub-layer as a single ifTable entry when the media-
   specific MIBs and the ifType values for HDLC and RS-232 are separate
   (rather than combined).

   Subject to the above, it is appropriate to assign an ifIndex value to
   any interface that can occur in an interface stack (in the
   ifStackTable) where the bottom of the stack is a physical interface
   (ifConnectorPresent has the value 'true') and there is a layer-3 or
   other application that "points down" to the top of this stack.  An
   example of an application that points down to the top of the stack is
   the Character MIB [21].






McCloghrie & Kastenholz     Standards Track                     [Page 7]

RFC 2863                The Interfaces Group MIB               June 2000


   Note that the sub-layers of an interface on one device will sometimes
   be different from the sub-layers of the interconnected interface of
   another device; for example, for a frame-relay DTE interface
   connected a frameRelayService interface, the inter-connected DTE and
   DCE interfaces have different ifType values and media-specific MIBs.

   These guidelines are just that, guidelines.  The designer of a
   media-specific MIB is free to lay out the MIB in whatever SMI
   conformant manner is desired.  However, in doing so, the media-
   specific MIB MUST completely specify the sub-layering model used for
   the MIB, and provide the assumptions, reasoning, and rationale used
   to develop that model.

3.1.3.  Virtual Circuits

   Several of the sub-layers for which media-specific MIB modules have
   been defined are connection oriented (e.g., Frame Relay, X.25).
   Experience has shown that each effort to define such a MIB module
   revisits the question of whether separate conceptual rows in the
   ifTable are needed for each virtual circuit.  Most, if not all, of
   these efforts to date have decided to have all virtual circuits
   reference a single conceptual row in the ifTable.

   This memo strongly recommends that connection-oriented sub-layers do
   not have a conceptual row in the ifTable for each virtual circuit.
   This avoids the proliferation of conceptual rows, especially those
   which have considerable redundant information.  (Note, as a
   comparison, that connection-less sub-layers do not have conceptual
   rows for each remote address.)  There may, however, be circumstances
   under which it is appropriate for a virtual circuit of a connection-
   oriented sub-layer to have its own conceptual row in the ifTable; an
   example of this might be PPP over an X.25 virtual circuit.  The MIB
   in section 6 of this memo supports such circumstances.

   If a media-specific MIB wishes to assign an entry in the ifTable to
   each virtual circuit, the MIB designer must present the rationale for
   this decision in the media-specific MIB's specification.

3.1.4.  Bit, Character, and Fixed-Length Interfaces

   RS-232 is an example of a character-oriented sub-layer over which
   (e.g., through use of PPP) IP datagrams can be sent.  Due to the
   packet-based nature of many of the objects in the ifTable, experience
   has shown that it is not appropriate to have a character-oriented
   sub-layer represented by a whole conceptual row in the ifTable.






McCloghrie & Kastenholz     Standards Track                     [Page 8]

RFC 2863                The Interfaces Group MIB               June 2000


   Experience has also shown that it is sometimes desirable to have some
   management information for bit-oriented interfaces, which are
   similarly difficult to represent by a whole conceptual row in the
   ifTable.  For example, to manage the channels of a DS1 circuit, where
   only some of the channels are carrying packet-based data.

   A further complication is that some subnetwork technologies transmit
   data in fixed length transmission units.  One example of such a
   technology is cell relay, and in particular Asynchronous Transfer
   Mode (ATM), which transmits data in fixed-length cells.  Representing
   such a interface as a packet-based interface produces redundant
   objects if the relationship between the number of packets and the
   number of octets in either direction is fixed by the size of the
   transmission unit (e.g., the size of a cell).

   About half the objects in the ifTable are applicable to every type of
   interface: packet-oriented, character-oriented, and bit-oriented.  Of
   the other half, two are applicable to both character-oriented and
   packet-oriented interfaces, and the rest are applicable only to
   packet-oriented interfaces.  Thus, while it is desirable for
   consistency to be able to represent any/all types of interfaces in
   the ifTable, it is not possible to implement the full ifTable for
   bit- and character-oriented sub-layers.

   A rejected solution to this problem would be to split the ifTable
   into two (or more) new MIB tables, one of which would contain objects
   that are relevant only to packet-oriented interfaces (e.g., PPP), and
   another that may be used by all interfaces.  This is highly
   undesirable since it would require changes in every agent
   implementing the ifTable (i.e., just about every existing SNMP
   agent).

   The solution adopted in this memo builds upon the fact that
   compliance statements in SMIv2 (in contrast to SMIv1) refer to object
   groups, where object groups are explicitly defined by listing the
   objects they contain.  Thus, with SMIv2, multiple compliance
   statements can be specified, one for all interfaces and additional
   ones for specific types of interfaces.  The separate compliance
   statements can be based on separate object groups, where the object
   group for all interfaces can contain only those objects from the
   ifTable which are appropriate for every type of interfaces.  Using
   this solution, every sub-layer can have its own conceptual row in the
   ifTable.

   Thus, section 6 of this memo contains definitions of the objects of
   the existing 'interfaces' group of MIB-II, in a manner which is both
   SNMPv2-compliant and semantically-equivalent to the existing MIB-II
   definitions.  With equivalent semantics, and with the BER ("on the



McCloghrie & Kastenholz     Standards Track                     [Page 9]

RFC 2863                The Interfaces Group MIB               June 2000


   wire") encodings unchanged, these definitions retain the same OBJECT
   IDENTIFIER values as assigned by MIB-II.  Thus, in general, no
   rewrite of existing agents which conform to MIB-II and the
   ifExtensions MIB is required.

   In addition, this memo defines several object groups for the purposes
   of defining which objects apply to which types of interface:

   (1)   the ifGeneralInformationGroup.  This group contains those
         objects applicable to all types of network interfaces,
         including bit-oriented interfaces.

   (2)   the ifPacketGroup.  This group contains those objects
         applicable to packet-oriented network interfaces.

   (3)   the ifFixedLengthGroup.  This group contains the objects
         applicable not only to character-oriented interfaces, such as
         RS-232, but also to those subnetwork technologies, such as
         cell-relay/ATM, which transmit data in fixed length
         transmission units.  As well as the octet counters, there are
         also a few other counters (e.g., the error counters) which are
         useful for this type of interface, but are currently defined as
         being packet-oriented.  To accommodate this, the definitions of
         these counters are generalized to apply to character-oriented