rfc2233.txt

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

   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.







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


   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.

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








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


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/Down 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/Down 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.

   The default setting should limit the number of traps generated to one
   per interface per linkUp/Down 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.








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


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

   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.






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


   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
   that ifOperStatus's transition will not occur immediately, but rather
   after a small time lag to complete certain operations before going
   "down"; for example, it might need to finish transmitting a packet.
   If a manager station finds that ifAdminStatus is down and
   ifOperStatus is not down for a particular interface, the manager
   station should wait a short while and check again.  If the condition
   still exists, only then should it raise an error indication.
   Naturally, it should also ensure that ifLastChange has not changed
   during this interval.

   Whenever an interface table entry is created (usually as a result of
   system initialization), the relevant instance of ifAdminStatus is set
   to down, and presumably ifOperStatus will be down or notPresent.

   An interface may be enabled in two ways: either as a result of
   explicit management action (e.g. setting ifAdminStatus to up) or as a
   result of the managed system's initialization process.  When
   ifAdminStatus changes to the up state, the related ifOperStatus
   should do one of the following:

   (1)  Change to the up state if and only if the interface is able
        to send and receive packets.

   (2)  Change to the lowerLayerDown state if and only if the
        interface is prevented from entering the up state because of the
        state of one or more of the interfaces beneath it in the
        interface stack.




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


   (3)  Change to the dormant state if and only if the interface is
        found to be operable, but the interface is waiting for other,
        external, events to occur before it can transmit or receive
        packets.  Presumably when the expected events occur, the
        interface will then change to the up state.

   (4)  Remain in the down state if an error or other fault condition
        is detected on the interface.

   (5)  Change to the unknown state if, for some reason, the state of
        the interface can not be ascertained.

   (6)  Change to the testing state if some test(s) must be performed
        on the interface. Presumably after completion of the test, the
        interface's state will change to up, dormant, or down, as
        appropriate.

   (7)  Remain in the notPresent state if interface components are
        missing.

3.1.14.  IfOperStatus in an Interface Stack

   When an interface is a part of an interface-stack, but is not the
   lowest interface in the stack, then:

   (1)  ifOperStatus has the value 'up' if it is able to pass packets
        due to one or more interfaces below it in the stack being 'up',
        irrespective of whether other interfaces below it are 'down', 
        'dormant', 'notPresent', 'lowerLayerDown', 'unknown' or
        'testing'.