rfc2863.txt

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

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




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


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

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





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


   (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 just after ifOperStatus leaves, or just before it enters,
   the down state, respectively; except that LinkUp and linkDown traps
   are never generated on transitions to/from the notPresent state.  For
   the purpose of deciding when these traps occur, the lowerLayerDown
   state and the down state are considered to be equivalent, i.e., there
   is no trap on transition from lowerLayerDown into down, and there is
   a trap on transition from any other state except down (and
   notPresent) into lowerLayerDown.

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

   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 limit the rate at which
   it generates traps.



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


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.

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 [6] 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 [20] 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.








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


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

   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
   [20]).  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).

   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.








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


   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.

   ifXxxOctets
      The definitions of ifInOctets and ifOutOctets (and similarly,
      ifHCInOctets and ifHCOutOctets) specify that their values include
      framing charact