rfc1573.txt

RFC 的详细文档！

           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



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


   from the values of the others.

   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.  To
   align the definitions better, the old counters are deprecated and
   replaced by new definitions.  Counters with 64 bits of range are also
   needed, as explained above.

3.2.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
   conditions that cause these state changes that are 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.2.10.  Addition of New ifType values

   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, which can be re-specified (with additional
   values) without issuing 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.  Thus, this document defines two MIB
   modules: one to define the MIB for the 'interfaces' group, and a
   second to define the first version of the IANAifType textual
   convention.  The latter will be periodically re-issued by the IANA.

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



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


   of ifIndex.

3.2.12.  IfAdminStatus and IfOperStatus

   A new state has been added to ifOperStatus: dormant.  This state
   indicates that the relevant interface is not actually in a condition
   to pass packets (i.e., 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 down state 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, 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 also be down.

   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:



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


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

      (2)  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 transition to the up state.

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

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

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

3.2.13.  Traps

   The exact definition of when linkUp and linkDown traps are generated,
   has been changed to reflect the changes to ifAdminStatus and
   ifOperStatus.

   LinkUp and linkDown traps are generated just after ifOperStatus
   leaves, or just before it enters, the down state, respectively.  The
   wording of the conditions under which a linkDown trap is generated
   was explicitly chosen to allow a node with only one interface to
   transmit the linkDown trap before that interface goes down.

   Operational experience seems to indicate that manager stations are
   most concerned with an interface being in the down state and the fact
   that this state may indicate a failure.  It seemed most useful to
   instrument either transitions into/out of the up state or the down
   state.

   Instrumenting transitions into or out of the up state has the
   drawback that an on-demand interface might have many transitions
   between up and dormant, leading to many linkUp traps and no linkDown
   traps.  Furthermore, if a node's only interface is the on-demand
   interface, then a transition to dormant will entail generation of a
   trap, necessitating bringing the link to the up state (and a linkUp
   trap)!!

   On the other hand, instrumenting transitions into or out of the down
   state has the advantages:



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


      (1)  A transition into the down state will occur when an error is
           detected on an interface.  Error conditions are presumably of
           great interest to network managers.

      (2)  Departing the down state generally indicates that the
           interface is going to either up or dormant, both of which are
           considered "healthy" states.

   Furthermore, it is believed that generarating traps on transitions
   into or out of the down state is generally consistent with current
   usage and interpretation of these traps by manager stations.

   Therefore, this memo defines that it is the transitions into/out of
   the down state which generate traps.

   Obviously, if a failure condition is present on a node with a single
   interface, the linkDown trap will probably not be succesfully
   transmitted since the interface through which it must be transmitted
   has failed.

3.2.14.  ifSpecific

   The current definition of ifSpecific is not explicit enough.  The
   only definition that can both be made explicit and can cover all the
   useful situations (see section 3.1.9) is to have ifSpecific be the
   most general value for the media-specific MIB module (the first
   example given section in 3.1.9).  This effectively makes it redundant
   because it contains no more information than is provided by ifType.
   For this reason, ifSpecific has been deprecated.

3.3.  Media-Specific MIB Applicability

   The exact use and semantics of many objects in this MIB are open to
   some interpretation.  This is a result of the generic nature of this
   MIB.  It is not always possible to come up with specific,
   unambiguous, text that covers all cases and yet preserve the generic
   nature of the MIB.

   Therefore, it is incumbent upon a media-specific MIB designer to,
   wherever necessary, clarify the use of the objects in this MIB with
   respect to the media-specific MIB.

   Specific areas of clarification include:

   Layering Model
        The media-specific MIB designer MUST completely and
        unambiguously specify the layering model used.  Each
        individual sub-layer must be identified.



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


   Virtual Circuits
        The media-specific MIB designer MUST specify whether virtual
        circuits are assigned entries in the ifTable or not.  If they
        are, compelling rationale must be presented.

   ifTestTable
        The media-specific MIB designer MUST specify the
        applicability of the ifTestTable.

   ifRcvAddressTable
        The media-specific MIB designer MUST specify the
        applicability of the ifRcvAddressTable.

   ifType
        For each of the ifType values to which the media-specific MIB
        applies, it must specify the mapping of ifType values to
        media-specific MIB module(s) and instances of MIB objects
        within those modules.

   However, wherever this interface MIB is specific in the semantics,
   DESCRIPTION, or applicability of objects, the media-specific MIB
   designer MUST NOT change said semantics, DESCRIPTION, or
   applicability.

4.  Overview

   This MIB consists of 5 tables:

   ifTable
        This table is the ifTable from MIB-II.

   ifXTable
        This table contains objects that have been added to the
        Interface MIB as a result of the Interface Evolution effort,