rfc2233.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,442 行 · 第 1/5 页

        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.

   (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.



McCloghrie & Kastenholz     Standards Track                     [Page 6]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   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 [9].

   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.



McCloghrie & Kastenholz     Standards Track                     [Page 7]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


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.

   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




McCloghrie & Kastenholz     Standards Track                     [Page 8]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   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 SNMPv2 (in contrast to SNMPv1) refer to
   object groups, where object groups are explicitly defined by
   listing the objects they contain.  Thus, in SNMPv2, 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 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:






McCloghrie & Kastenholz     Standards Track                     [Page 9]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   (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 interfaces and fixed-length-transmission
        interfaces.

   It should be noted that the octet counters in the ifTable
   aggregate octet counts for unicast and non-unicast packets into a
   single octet counter per direction (received/transmitted).  Thus,
   with the above definition of fixed-length-transmission interfaces,
   where such interfaces which support non-unicast packets, separate
   counts of unicast and multicast/broadcast transmissions can only
   be maintained in a media-specific MIB module.

3.1.5.  Interface Numbering

   MIB-II defines an object, ifNumber, whose value represents:

        "The number of network interfaces (regardless of their
        current state) present on this system."

   Each interface is identified by a unique value of the ifIndex
   object, and the description of ifIndex constrains its value as
   follows:

        "Its value ranges between 1 and the value of ifNumber.  The
        value for each interface must remain constant at least from
        one re-initialization of the entity's network management
        system to the next re-initialization."

   This constancy requirement on the value of ifIndex for a
   particular interface is vital for efficient management.  However,
   an increasing number of devices allow for the dynamic
   addition/removal of network interfaces.  One example of this is a
   dynamic ability to configure the use of SLIP/PPP over a



McCloghrie & Kastenholz     Standards Track                    [Page 10]

RFC 2233            Interfaces Group MIB using SMIv2       November 1997


   character-oriented port.  For such dynamic additions/removals, the
   combination of the constancy requirement and the restriction that
   the value of ifIndex is less than ifNumber is problematic.

   Redefining ifNumber to be the largest value of ifIndex was
   rejected since it would not help.  Such a re-definition would
   require ifNumber to be deprecated and the utility of the redefined
   object would be questionable.  Alternatively, ifNumber could be
   deprecated and not replaced.  However, the deprecation of ifNumber
   would require a change to that portion of ifIndex's definition
   which refers to ifNumber.  So, since the definition of ifIndex
   must be changed anyway in order to solve the problem, changes to