rfc2233.txt

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

   (2)  ifOperStatus may have the value 'up' or 'dormant' if one or
        more interfaces below it in the stack are 'dormant', and all
        others below it are either 'down', 'dormant', 'notPresent',
        'lowerLayerDown', 'unknown' or 'testing'.

   (3)  ifOperStatus has the value 'lowerLayerDown' while all
        interfaces below it in the stack are either 'down',
        'notPresent', 'lowerLayerDown', or 'testing'.

3.1.15.  Traps

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






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


   Operational experience indicates that management stations are most
   concerned with an interface being in the down state and the fact that
   this state may indicate a failure.  Thus, it is most useful to
   instrument transitions into/out of either the up state or the down
   state.

   Instrumenting transitions into or out of the up state was rejected
   since it would have the drawback that a 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 demand interface, then a transition to dormant would entail
   generation of a linkDown 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 (to/from all other states except notPresent) has the
   advantages:

   (1)  A transition into the down state (from a state other than
        notPresent) 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 (to a state other than the
        notPresent 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 generating traps on transitions into
   or out of the down state (except to/from the notPresent state) is
   generally consistent with current usage and interpretation of these
   traps by manager stations.

   Transitions to/from the notPresent state are concerned with the
   insertion and removal of hardware, and are outside the scope of these
   traps.

   Therefore, this memo defines that LinkUp and linkDown traps are
   generated on just after ifOperStatus leaves, or just before it
   enters, the down state, respectively; except that LinkUp and linkDown
   traps never generated on transitions to/from the notPresent state.

   Note that this definition allows a node with only one interface to
   transmit a linkDown trap before that interface goes down.  (Of
   course, when the interface is going down because of a failure
   condition, the linkDown trap probably cannot be successfully
   transmitted anyway.)




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


   Some interfaces perform a link "training" function when trying to
   bring the interface up.  In the event that such an interface were
   defective, then the training function would fail and the interface
   would remain down, and the training function might be repeated at
   appropriate intervals.  If the interface, while performing this
   training function, were considered to the in the testing state, then
   linkUp and linkDown traps would be generated for each start and end
   of the training function.  This is not the intent of the linkUp and
   linkDown traps, and therefore, while performing such a training
   function, the interface's state should be represented as down.

   An exception to the above generation of linkUp/linkDown traps on
   changes in ifOperStatus, occurs when an interface is "flapping",
   i.e., when it is rapidly oscillating between the up and down states.
   If traps were generated for each such oscillation, the network and
   the network management system would be flooded with unnecessary
   traps.  In such a situation, the agent should rate- limit its
   generation of traps.

3.1.16.  ifSpecific

   The original definition of the OBJECT IDENTIFIER value of ifSpecific
   was not sufficiently clear.  As a result, different implementors used
   it differently, and confusion resulted.  Some implementations set the
   value of ifSpecific to the OBJECT IDENTIFIER that defines the media-
   specific MIB, i.e., the "foo" of:

              foo OBJECT IDENTIFIER ::= { transmission xxx }

   while others set it to be OBJECT IDENTIFIER of the specific table or
   entry in the appropriate media-specific MIB (i.e., fooTable or
   fooEntry), while still others set it be the OBJECT IDENTIFIER of the
   index object of the table's row, including instance identifier,
   (i.e., fooIfIndex.ifIndex).  A definition based on the latter would
   not be sufficient unless it also allowed for media- specific MIBs
   which include several tables, where each table has its own
   (different) indexing.

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







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


3.1.17.  Creation/Deletion of Interfaces

   While some interfaces, for example, most physical interfaces, cannot
   be created via network management, other interfaces such as logical
   interfaces sometimes can be.  The ifTable contains only generic
   information about an interface.  Almost all 'create-able' interfaces
   have other, media-specific, information through which configuration
   parameters may be supplied prior to creating such an interface.
   Thus, the ifTable does not itself support the creation or deletion of
   an interface (specifically, it has no RowStatus [2] column).  Rather,
   if a particular interface type supports the dynamic creation and/or
   deletion of an interface of that type, then that media-specific MIB
   should include an appropriate RowStatus object (see the ATM LAN-
   Emulation Client MIB [8] for an example of a MIB which does this).
   Typically, when such a RowStatus object is created/deleted, then the
   conceptual row in the ifTable appears/disappears as a by-product, and
   an ifIndex value (chosen by the agent) is stored in an appropriate
   object in the media-specific MIB.

3.1.18.  All Values Must be Known

   There are a number of situations where an agent does not know the
   value of one or more objects for a particular interface.  In all such
   circumstances, an agent MUST NOT instantiate an object with an
   incorrect value; rather, it MUST respond with the appropriate
   error/exception condition (e.g., noSuchInstance for SNMPv2).

   One example is where an agent is unable to count the occurrences
   defined by one (or more) of the ifTable counters.  In this
   circumstance, the agent MUST NOT instantiate the particular counter
   with a value of, say, zero.  To do so would be to provide mis-
   information to a network management application reading the zero
   value, and thereby assuming that there have been no occurrences of
   the event (e.g., no input errors because ifInErrors is always zero).

   Sometimes the lack of knowledge of an object's value is temporary.
   For example, when the MTU of an interface is a configured value and a
   device dynamically learns the configured value through (after)
   exchanging messages over the interface (e.g., ATM LAN- Emulation
   [8]).  In such a case, the value is not known until after the ifTable
   entry has already been created.  In such a case, the ifTable entry
   should be created without an instance of the object whose value is
   unknown; later, when the value becomes known, the missing object can
   then be instantiated (e.g., the instance of ifMtu is only
   instantiated once the interface's MTU becomes known).






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


   As a result of this "known values" rule, management applications MUST
   be able to cope with the responses to retrieving the object instances
   within a conceptual row of the ifTable revealing that some of the
   row's columnar objects are missing/not available.

4.  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 preserves 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, as must the ifStackTable's
        portrayal of the relationship(s) between the sub-layers.

   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.

   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.







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


5.  Overview

   This MIB consists of 4 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, or
        replacements for objects of the original (MIB-II) ifTable that
        were deprecated because the semantics of said objects have
        significantly changed.  This table also contains objects that
        were previously in the ifExtnsTable.

   ifStackTable
        This table contains objects that define the relationships among
        the sub-layers of an interface.

   ifRcvAddressTable
        This table contains objects that are used to define the media-
        level addresses which this interface will receive.  This table
        is a generic table.  The designers of media- specific MIBs must
        define exactly how this table applies to their specific MIB.

6.  Interfaces Group Definitions

   IF-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64,
       Integer32, TimeTicks, mib-2,
       NOTIFICATION-TYPE                        FROM SNMPv2-SMI
       TEXTUAL-CONVENTION, DisplayString,
       PhysAddress, TruthValue, RowStatus,