rfc1573.txt

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

   years.

3.1.7.  Multicast/Broadcast Counters

   The counters in the ifTable for packets addressed to a multicast or
   the broadcast address, are combined as counters of non-unicast
   packets.  In contrast, the ifExtensions MIB [7] defines one set of
   counters for multicast, and a separate set for broadcast packets.
   With the separate counters, the original combined counters become
   redundant.

3.1.8.  Addition of New ifType values

   Over time new ifType enumerated values have been needed for new
   interface types.  With the syntax of ifType being defined in a MIB,
   this requires the new MIB to be re-issued in order to define the new
   values.  In the past, re-issuing of the MIB has occurred only after
   several years.

3.1.9.  ifSpecific

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

          foo OBJECT IDENTIFIER ::= { transmission xxx }

   while others have it be the OBJECT IDENTIFIER of the table or entry
   in the appropriate media-specific MIB (e.g. fooTable or fooEntry),
   while still others have it be the OBJECT IDENTIFIER of the index
   object of the table's row, including instance identifier (e.g.,
   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,



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


   indexing.

3.2.  Clarifications/Revisions

   The following clarifications and/or revisions are proposed.

3.2.1.  Interface Numbering

   One solution to the interface numbering problem would be to redefine
   ifNumber to be the largest value of ifIndex, but the utility of such
   an object is questionable, and such a re-definition would require
   ifNumber to be deprecated.  Thus, an improvement would be to
   deprecate ifNumber and not replace it.  However, the deprecation of
   ifNumber would require a change to that portion of ifIndex's
   definition which refers to ifNumber.  So, since the definition of
   ifIndex must be changed anyway in order to solve the problem, changes
   to ifNumber do not benefit the solution.

   The solution adopted in this memo is to delete the requirement that
   the value of ifIndex must be less than the value of ifNumber, and to
   retain ifNumber with its current definition.  It could be argued that
   this is a change in the semantics of ifIndex; however, all existing
   implementations conform to this new definition, and in the interests
   of not requiring changes in existing implementations and in the many
   existing media-specific MIBs, it is proposed that this change does
   not require ifIndex to be deprecated.

   This solution also results in the possibility of "holes" in the
   ifTable (i.e., the ifIndex values of conceptual rows in the ifTable
   are not necessarily contiguous), but SNMP's GetNext (and SNMPv2's
   GetBulk) operation easily deals with such holes.  The value of
   ifNumber still represents the number of conceptual rows, which
   increases/decreases as new interfaces are dynamically added/removed.
   The vital constancy requirement is met by requiring that after an
   interface is dynamically removed, its ifIndex value is not re-used
   (by a different dynamically added interface) until after the
   following re-initialization of the network management system.  This
   avoids the need for a priori assignment of ifIndex values for all
   possible interfaces which might be added dynamically.

   The exact meaning of a "different" interface is hard to define, and
   there will be gray areas.  One important criterion is that a
   management station, not noticing that an interface has gone away and
   another come into existence, should not be confused when it
   calculates the difference between the counter values retrieved on
   successive polls for a particular ifIndex value.  However, any firm
   definition in this document would likely to turn out to be
   inadequate.  Instead, the following guidelines are offered to allow



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


   implementors to choose what "different" means in their particular
   situation.

   A previously-unused value of ifIndex should be assigned to a
   dynamically added interface if:

      (1)  the assignment of a previously-used ifIndex value to the
           interface could result in a discontinuity in the values of
           ifTable counters for that value of ifIndex; or,

      (2)  an agent has no knowledge of whether the interface is the
           "same" or "different" from a previous interface incarnation.

   Because of the restriction of the value of ifIndex to be less than
   ifNumber, interfaces have been numbered with small integer values.
   This has led to the ability by humans to use the ifIndex values as
   (somewhat) user-friendly names for network interfaces (e.g.,
   "interface number 3").  With the relaxation of the restriction on the
   value of ifIndex, there is now the possibility that ifIndex values
   could be assigned as very large numbers (e.g., memory addresses).
   Such numbers would be much less user-friendly.

   Therefore, this memo recommends that ifIndex values still be assigned
   as (relatively) small integer values starting at 1, even though the
   values in use at any one time are not necessarily contiguous.  (Note
   that this makes remembering which values have been assigned easy for
   agents which dynamically add new interfaces.)

   This proposed change introduces a new problem of its own.
   Previously, there usually was a simple, direct, mapping of interfaces
   to the physical ports on systems.  This mapping would be based on the
   ifIndex value.  However, by removing the previous restrictions on the
   values allowed for ifIndex, along with the interface sub-layer
   concept (see the following section), mapping from interfaces to
   physical ports becomes increasingly problematic.

   To address this issue, a new object, ifName, is added to the MIB.
   This object contains the device's name for the interface of which the
   relevant entry in the ifTable is a component.  For example, if a
   router has an interface named wan1, which is composed of PPP running
   over an RS-232 port, the ifName objects for the corresponding PPP and
   RS-232 entries in the ifTable will contain the string "wan1".

3.2.2.  Interface Sub-Layers

   One possible but not recommended solution to the problem of
   representing multiple sub-layers would be to retain the concept of
   one conceptual row for all the sub-layers of an interface and have



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


   each media-specific MIB module identify its "superior" and
   "subordinate" sub-layers through OBJECT IDENTIFIER "pointers".  The
   drawbacks of this scheme are: 1) the superior/subordinate pointers
   are contained in the media-specific MIB modules, and thus, a manager
   could not learn the structure of an interface, without inspecting
   multiple pointers in different MIB modules; this is overly complex
   and only possible if the manager has knowledge of all the relevant
   media-specific MIB modules; 2) current MIB modules would all need to
   be retrofitted with these new "pointers"; 3) this scheme does not
   adequately address the problem of upward and downward multiplexing;
   and 4) enumerated values of ifType are needed for each combination of
   sub-layers.

   Another possible but not recommended scheme would be to retain the
   concept of one conceptual row for all the sub-layers of an interface
   and have a new separate MIB table to identify the "superior" and
   "subordinate" sub-layers which contain OBJECT IDENTIFIER "pointers"
   to media-specific MIB module(s) for each sub-layer.  Effectively, one
   conceptual row in the ifTable would represent each combination of
   sub-layers between the internetwork-layer and the wire.  While this
   scheme has fewer drawbacks, it does not support downward
   multiplexing, such as PPP over MLP; since MLP makes two (or more)
   serial lines appear to the layers above as a single physical
   interface, PPP over MLP should appear to the internetwork-layer as a
   single interface.  However, this scheme would result in two (or more)
   conceptual rows in the ifTable and the internetwork-layer would run
   over both of them.  This scheme also requires enumerated values of
   ifType for each combination of sub-layers.

   The solution adopted in this memo is to have an individual conceptual
   row in the ifTable to represent each sub-layer and have a new
   separate MIB table (the ifStackTable, see section 5 of this memo) to
   identify the "superior" and "subordinate" sub-layers through INTEGER
   "pointers" to the appropriate conceptual rows in the ifTable.  This
   solution supports both upward and downward multiplexing.  It also
   allows the IANAIfType to Media-Specific MIB mapping to identify the
   media-specific MIB module for each sub- layer.  The new table
   (ifStackTable) need be referenced only to obtain information about
   layering.  Enumerated values for ifType are required for each sub-
   layer only, not for combinations of them.

   However, this solution does require that the descriptions of some
   objects in the ifTable (specifically, ifType, ifPhysAddress,
   ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to
   any sub-layer (rather than only to a sub-layer immediately beneath
   the network layer, as at present).  It also requires that some
   objects (specifically, ifSpeed) need to have appropriate values
   identified for use when a generalized definition does not apply to a



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


   particular sub-layer.

   In addition, this adopted solution makes no requirement that a
   device, in which a sub-layer is instrumented by a conceptual row of
   the ifTable, be aware of whether an internetwork protocol runs on top
   of (i.e., at some layer above) that sub-layer.  In fact, the counters
   of packets received on an interface are defined as counting the
   number "delivered to a higher-layer protocol".  This meaning of
   "higher-layer" includes:

      (1)  Delivery to a forwarding module which accepts
           packets/frames/octets and forwards them on at the same
           protocol layer.  For example, for the purposes of this
           definition, the forwarding module of a MAC-layer bridge is
           considered as a "higher-layer" to the MAC-layer of each port
           on the bridge.

      (2)  Delivery to a higher sub-layer within a interface stack.  For
           example, for the purposes of this definition, if a PPP module
           operated directly over a serial interface, the PPP module
           would be considered the higher sub-layer to the serial
           interface.

      (3)  Delivery to a higher protocol layer which does not do packet
           forwarding for sub-layers that are "at the top of" the
           interface stack.  For example, for the purposes of this
           definition, the local IP module would be considered the
           higher layer to a SLIP serial interface.

   Similarly, for output, the counters of packets transmitted out an
   interface are defined as counting the number "that higher-level
   protocols requested to be transmitted".  This meaning of "higher-
   layer" includes:

      (1)  A forwarding module, at the same protocol layer, which
           transmits packets/frames/octets that were received on an
           different interface.  For example, for the purposes of this
           definition, the forwarding module of a MAC-layer bridge is
           considered as a "higher-layer" to the MAC-layer of each port
           on the bridge.

      (2)  The next higher sub-layer within an interface stack.  For
           example, for the purposes of this definition, if a PPP module
           operated directly over a serial interface, the PPP module
           would be a "higher layer" to the serial interface.






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


      (3)  For sub-layers that are "at the top of" the interface stack,
           a higher element in the network protocol stack.  For example,
           for the purposes of this definition, the local IP module
           would be considered the higher layer to an Ethernet
           interface.

3.2.3.  Guidance on Defining Sub-layers

   The designer of a media-specific MIB must decide whether to divide
   the interface into sub-layers, and if so, how to make the divisions.
   The following guidance is offered to assist the media-specific MIB
   designer in these decisions.

   In general, the number of entries in the ifTable should be kept to
   the minimum required for network management.  In particular, a group
   of related interfaces should be treated as a single interface with
   one entry in the ifTable providing that:

      (1)  None of the group of interfaces performs multiplexing for any
           other interface in the agent,

      (2)  There is a meaningful and useful way for all of the ifTable's
           information (e.g., the counters, and the status variables),
           and all of the ifTable's capabilities (e.g., write access to
           ifAdminStatus), to apply to the group of interfaces as a
           whole.

   Under these circumstances, there should be one entry in the ifTable
   for such a group of interfaces, and any internal structure which
   needs to be represented to network management should be captured in a