rfc2863.txt

RFC 的详细文档！

   interfaces that operate at 650,000,000 bits/second or faster, 64-bit
   packet counters AND 64-bit octet counters MUST be supported.

   These speed thresholds 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 10Mbs Ethernet) should
         not require them.

   (2)   64-bit counters are a new feature, introduced in the SMIv2.  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):

         -   10Mbs Ethernet: 57 minutes,

         -   16Mbs Token Ring: 36 minutes,

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

         -   FDDI: 5.7 minutes

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





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


   As an aside, a 1-terabit/second (1,000 Gbs) 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

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

3.1.7.  Interface Speed

   Network speeds are increasing.  The range of ifSpeed is limited to
   reporting a maximum speed of (2**31)-1 bits/second, or approximately
   2.2Gbs.  SONET defines an OC-48 interface, which is defined at
   operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
   Thus, ifSpeed is insufficient for the future, and this memo defines
   an additional object: ifHighSpeed.

   The ifHighSpeed 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 (but rejected) 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.





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


   (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.1.8.  Multicast/Broadcast Counters

   In MIB-II, the ifTable counters for multicast and broadcast packets
   are combined as counters of non-unicast packets.  In contrast, the
   ifExtensions MIB [19] defined one set of counters for multicast, and
   a separate set for broadcast packets.  With the separate counters,
   the original combined counters become redundant.  To avoid this
   redundancy, the non-unicast counters are deprecated.

   For the output broadcast and multicast counters defined in RFC 1229,
   their definitions varied slightly from the packet counters in the
   ifTable, in that they did not count errors/discarded packets.  Thus,
   this memo defines new objects with better aligned definitions.
   Counters with 64 bits of range are also needed, as explained above.

3.1.9.  Trap Enable

   In the multi-layer interface model, each sub-layer for which there is
   an entry in the ifTable can generate linkUp/linkDown Traps.  Since
   interface state changes would tend to propagate through the interface
   (from top to bottom, or bottom to top), it is likely that several
   traps would be generated for each linkUp/linkDown occurrence.

   It is desirable to provide a mechanism for manager stations to
   control the generation of these traps.  To this end, the
   ifLinkUpDownTrapEnable object has been added.  This object allows
   managers to limit generation of traps to just the sub-layers of
   interest.



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


   The default setting should limit the number of traps generated to one
   per interface per linkUp/linkDown event.  Furthermore, it seems that
   the state changes of most interest to network managers occur at the
   lowest level of an interface stack.  Therefore we specify that by
   default, only the lowest sub-layer of the interface generate traps.

3.1.10.  Addition of New ifType values

   Over time, there is the need to add new ifType enumerated values for
   new interface types.  If the syntax of ifType were defined in the MIB
   in section 6, then a new version of this MIB would have to be re-
   issued in order to define new values.  In the past, re-issuing of a
   MIB has occurred only after several years.

   Therefore, the syntax of ifType is changed to be a textual
   convention, such that the enumerated integer values are now defined
   in the textual convention, IANAifType, defined in a different
   document.  This allows additional values to be documented without
   having to re-issue a new version of this document.  The Internet
   Assigned Number Authority (IANA) is responsible for the assignment of
   all Internet numbers, including various SNMP-related numbers, and
   specifically, new ifType values.

3.1.11.  InterfaceIndex Textual Convention

   A new textual convention, InterfaceIndex, has been defined.  This
   textual convention "contains" all of the semantics of the ifIndex
   object.  This allows other MIB modules to easily import the semantics
   of ifIndex.

3.1.12.  New states for IfOperStatus

   Three new states have been added to ifOperStatus: 'dormant',
   'notPresent', and 'lowerLayerDown'.

   The dormant state indicates that the relevant interface is not
   actually in a condition to pass packets (i.e., it is not 'up') but is
   in a "pending" state, waiting for some external event.  For "on-
   demand" interfaces, this new state identifies the situation where the
   interface is waiting for events to place it in the up state.
   Examples of such events might be:

   (1)   having packets to transmit before establishing a connection to
         a remote system;

   (2)   having a remote system establish a connection to the interface
         (e.g. dialing up to a slip-server).




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


   The notPresent state is a refinement on the down state which
   indicates that the relevant interface is down specifically because
   some component (typically, a hardware component) is not present in
   the managed system.  Examples of use of the notPresent state are:

   (1)   to allow an interface's conceptual row including its counter
         values to be retained across a "hot swap" of a card/module,
         and/or

   (2)   to allow an interface's conceptual row to be created, and
         thereby enable interfaces to be pre-configured prior to
         installation of the hardware needed to make the interface
         operational.

   Agents are not required to support interfaces in the notPresent
   state.  However, from a conceptual viewpoint, when a row in the
   ifTable is created, it first enters the notPresent state and then
   subsequently transitions into the down state; similarly, when a row
   in the ifTable is deleted, it first enters the notPresent state and
   then subsequently the object instances are deleted.  For an agent
   with no support for notPresent, both of these transitions (from the
   notPresent state to the down state, and from the notPresent state to
   the instances being removed) are immediate, i.e., the transition does
   not last long enough to be recorded by ifOperStatus.  Even for those
   agents which do support interfaces in the notPresent state, the
   length of time and conditions under which an interface stays in the
   notPresent state is implementation-specific.

   The lowerLayerDown state is also a refinement on the down state.
   This new state indicates that this interface runs "on top of" one or
   more other interfaces (see ifStackTable) and that this interface is
   down specifically because one or more of these lower-layer interfaces
   are down.

3.1.13.  IfAdminStatus and IfOperStatus

   The down state of ifOperStatus now has two meanings, depending on the
   value of ifAdminStatus.

   (1)   if ifAdminStatus is not down and ifOperStatus is down then a
         fault condition is presumed to exist on the interface.

   (2)   if ifAdminStatus is down, then ifOperStatus will normally also
         be down (or notPresent) i.e., there is not (necessarily) a
         fault condition on the interface.

   Note that when ifAdminStatus transitions to down, ifOperStatus will
   normally also transition to down.  In this situation, it is possible



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