rfc1573.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

   Note that the sub-layers of an interface on one device will sometimes
   be different to the sub-layers of the interconnected interface of
   another device.  A simple example of this is a frame-relay DTE
   interface which connects to a frameRelayService interface, where the
   DTE interface has a different ifType value and media-specific MIB to
   the DCE interface.

   Also note that a media-specific MIB may mandate that a particular



McCloghrie & Kastenholz                                        [Page 11]

RFC 1573               Interfaces Group Evolution           January 1994


   ifTable counter does not apply and that its value must always be 0,
   signifying that the applicable event can not and does not occur for
   that type of interface; for example, ifInMulticastPkts and
   ifOutMulticastPkts on an interface type which has no multicast
   capability.  In other circumstances, an agent must not always return
   0 for any counter just because its implementation is incapable of
   detecting occurrences of the particular event; instead, it must
   return a noSuchName/noSuchObject error/exception when queried for the
   counter, even if this prevents the implementation from complying with
   the relevant MODULE-COMPLIANCE macro.

   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 so doing, 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.2.4.  Virtual Circuits

   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.2.5.  Bit, Character, and Fixed-Length Interfaces

   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.

   One possible but not recommended solution to this problem would be to
   split the ifTable into two (or more) new MIB tables, one of which



McCloghrie & Kastenholz                                        [Page 12]

RFC 1573               Interfaces Group Evolution           January 1994


   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:

      (1)  the ifGeneralGroup.  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.



McCloghrie & Kastenholz                                        [Page 13]

RFC 1573               Interfaces Group Evolution           January 1994


   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.2.6.  Counter Size

   Two approaches to addressing the shrinking minimum counter-wrap time
   problem were evaluated.  Counters could be scaled, for example,
   ifInOctets could be changed to count received octets in, e.g., 1024
   byte blocks.  Alternatively, the size of the counter could be
   increased.

   Scaling the counters was rejected.  While it provides acceptable
   performance at high count rates, at low rates it suffers.  If there
   is little traffic on an interface, there might be a significant
   interval before enough counts occur to cause a counter to be
   incremented.  Traffic would then appear to be very bursty, leading to
   incorrect conclusions of the network's performance.

   The alternative, which this memo adopts, is to provide expanded, 64
   bit, counters.  These counters are provided in new "high capacity"
   groups,

   The old, 32-bit, counters have not been deprecated.  The 64-bit
   counters are to be used only when the 32-bit counters do not provide
   enough capacity; that is, the 32 bit counters could wrap too fast.

   For interfaces that operate at 20,000,000 (20 million) bits per
   second or less, 32-bit byte and packet counters MUST be used.  For
   interfaces that operate faster than 20,000,000 bits/second, and
   slower than 650,000,000 bits/second, 32-bit packet counters MUST be
   used and 64-bit octet counters MUST be used.  For interfaces that
   operate at 650,000,000 bits/second or faster, both 64-bit packet
   counters AND 64-bit octet counters MUST be used.

   These speed steps were chosen as reasonable compromises based on the
   following:

      (1)  The cost of maintaining 64-bit counters is relatively high,
           so minimizing the number of agents which must support them is
           desirable.  Common interfaces (such as Ethernet) should not
           require them.





McCloghrie & Kastenholz                                        [Page 14]

RFC 1573               Interfaces Group Evolution           January 1994


      (2)  64-bit counters are a new feature, introduced in SNMPv2.  It
           is reasonable to expect that support for them will be spotty
           for the immediate future.  Thus, we wish to limit them to as
           few systems as possible.  This, in effect, means that 64-bit
           counters should be limited to higher speed interfaces.
           Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
           fairly wide-spread so it seems reasonable to not require 64-
           bit counters for these interfaces.

      (3)  The 32-bit octet counters will wrap in the following times,
           for the following interfaces (when transmitting maximum-sized
           packets back-to-back):

           -   Ethernet: 57 minutes,

           -   16 megabit Token Ring: 36 minutes,

           -   A US T3 line (45 megabits): 12 minutes,

           -   FDDI: 5.7 minutes

      (4)  The 32-bit packet counters wraps in about 57 minutes when
           64-byte packets are transmitted back-to-back on a 650,000,000
           bit/second link.

           As an aside, a 1-terabit (1,000 gigabits) link will cause a
           64 bit octet counter to wrap in just under 5 years.
           Conversely, an 81,000,000 terabit/second link is required to
           cause a 64-bit counter to wrap in 30 minutes.  We believe
           that, while technology rapidly marches forward, this link
           speed will not be achieved for at least several years,
           leaving sufficient time to evaluate the introduction of 96
           bit counters.

   When 64-bit counters are in use, the 32-bit counters MUST still be
   available.  They will report the low 32-bits of the associated 64-bit
   count (e.g., ifInOctets will report the least significant 32 bits of
   ifHCInOctets).  This enhances inter-operability with existing
   implementations at a very minimal cost to agents.

   The new "high capacity" groups are:

      (1)  the ifHCFixedLengthGroup for character-oriented/fixed-length
           interfaces, and the ifHCPacketGroup for packet-based
           interfaces; both of these groups include 64 bit counters for
           octets, and





McCloghrie & Kastenholz                                        [Page 15]

RFC 1573               Interfaces Group Evolution           January 1994


      (2)  the ifVHCPacketGroup for packet-based interfaces; this group
           includes 64 bit counters for octets and packets.

3.2.7.  Interface Speed

   In order to deal with increasing interface speeds, we have added an
   ifHighSpeed object.

   This object reports the speed of the interface in 1,000,000 (1
   million) bits/second units.  Thus, the true speed of the interface
   will be the value reported by this object, plus or minus 500,000
   bits/second.

   Other alternatives considered were:

      (1)  Making the interface speed a 64-bit gauge.  This was rejected
           since the current SMI does not allow such a syntax.

           Furthermore, even if 64-bit gauges were available, their use
           would require additional complexity in agents due to an
           increased requirement for 64-bit operations.

      (2)  We also considered making "high-32 bit" and "low-32-bit"
           objects which, when combined, would be a 64-bit value.  This
           simply seemed overly complex for what we are trying to do.

           Furthermore, a full 64-bits of precision does not seem
           necessary.  The value of ifHighSpeed will be the only report
           of interface speed for interfaces that are faster than
           4,294,967,295 bits per second.  At this speed, the
           granularity of ifHighSpeed will be 1,000,000 bits per second,
           thus the error will be 1/4294, or about 0.02%.  This seems
           reasonable.

      (3)  Adding a "scale" object, which would define the units which
           ifSpeed's value is.

           This would require two additional objects; one for the
           scaling object, and one to replace the current ifSpeed.  This
           later object is required since the semantics of ifSpeed would
           be significantly altered, and manager stations which do not
           understand the new semantics would be confused.

3.2.8.  Multicast/Broadcast Counters

   To avoid the redundancy of counting all non-unicast packets as well
   as having individual multicast and broadcast packet counters, we
   deprecate the use of the non-unicast counters, which can be derived