rfc2233.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,442 行 · 第 1/5 页

   ifNumber do not benefit the solution.

   The solution adopted in this memo is just 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.
   This is a minor change in the semantics of ifIndex; however, all
   existing agent implementations conform to this new definition, and
   in the interests of not requiring changes to existing agent
   implementations and to the many existing media-specific MIBs, this
   memo assumes that this change does not require ifIndex to be
   deprecated.  Experience indicates that this assumption does
   "break" a few management applications, but this is considered
   preferable to breaking all agent implementations.

   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 requirement for constancy (between re-initializations) of an
   interface's ifIndex value 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 assignment (in advance) of ifIndex values
   for all possible interfaces that might be added dynamically.  The
   exact meaning of a "different" interface is hard to define, and
   there will be gray areas.  Any firm definition in this document
   would likely to turn out to be inadequate.  Instead, implementors
   must choose what it means in their particular situation, subject
   to the following rules:





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


   (1)  a previously-unused value of ifIndex must be assigned to a
        dynamically added interface if an agent has no knowledge of
        whether the interface is the "same" or "different" to a
        previously incarnated interface.

   (2)  a management station, not noticing that an interface has gone
        away and another has come into existence, must not be
        confused when calculating the difference between the counter
        values retrieved on successive polls for a particular ifIndex
        value.

   When the new interface is the same as an old interface, but a
   discontinuity in the value of the interface's counters cannot be
   avoided, the ifTable has (until now) required that a new ifIndex
   value be assigned to the returning interface.  That is, either all
   counter values have had to be retained during the absence of an
   interface in order to use the same ifIndex value on that
   interface's return, or else a new ifIndex value has had to be
   assigned to the returning interface.  Both alternatives have
   proved to be burdensome to some implementations:

   (1)  maintaining the counter values may not be possible (e.g., if
        they are maintained on removable hardware),

   (2)  using a new ifIndex value presents extra work for management
        applications.  While the potential need for such extra work
        is unavoidable on agent re-initializations, it is desirable
        to avoid it between re-initializations.

   To address this, a new object, ifCounterDiscontinuityTime, has
   been defined to record the time of the last discontinuity in an
   interface's counters.  By monitoring the value of this new object,
   a management application can now detect counter discontinuities
   without the ifIndex value of the interface being changed.  Thus,
   an agent which implements this new object should, when a new
   interface is the same as an old interface, retain that interface's
   ifIndex value and update if necessary the interface's value of
   ifCounterDiscontinuityTime.  With this new object, a management
   application must, when calculating differences between counter
   values retrieved on successive polls, discard any calculated
   difference for which the value of ifCounterDiscontinuityTime is
   different for the two polls.  (Note that this test must be
   performed in addition to the normal checking of sysUpTime to
   detect an agent re-initialization.)  Since such discards are a
   waste of network management processing and bandwidth, an agent
   should not update the value of ifCounterDiscontinuityTime unless
   absolutely necessary.




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


   While defining this new object is a change in the semantics of the
   ifTable counter objects, it is impractical to deprecate and
   redefine all these counters because of their wide deployment and
   importance.  Also, a survey of implementations indicates that many
   agents and management applications do not correctly implement this
   aspect of the current semantics (because of the burdensome issues
   mentioned above), such that the practical implications of such a
   change is small.  Thus, this breach of the SMI's rules is
   considered to be acceptable.

   Note, however, that the addition of ifCounterDiscontinuityTime
   does not change the fact that:

        It is necessary at certain times for the assignment of ifIndex
        values to change on a reinitialization of the agent (such as a
        reboot).

   The possibility of ifIndex value re-assignment must be
   accommodated by a management application whenever the value of
   sysUpTime is reset to zero.

   Note also that some agents support multiple "naming scopes", e.g.,
   for an SNMPv1 agent, multiple values of the SNMPv1 community
   string.  For such an agent (e.g., a CNM agent which supports a
   different subset of interfaces for different customers), there is
   no required relationship between the ifIndex values which identify
   interfaces in one naming scope and those which identify interfaces
   in another naming scope.  It is the agent's choice as to whether
   the same or different ifIndex values identify the same or
   different interfaces in different naming scopes.

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






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


   A new problem is introduced by representing each sub-layer as an
   ifTable entry.  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 having
   an ifTable entry for each interface sub-layer, 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 local name (e.g., the name used
   at the device's local console) for the interface of which the
   relevant entry in the ifTable is a component.  For example,
   consider a router having an interface composed of PPP running over
   an RS-232 port.  If the router uses the name "wan1" for the
   (combined) interface, then the ifName objects for the
   corresponding PPP and RS-232 entries in the ifTable would both
   have the value "wan1".  On the other hand, if the router uses the
   name "wan1.1" for the PPP interface and "wan1.2" for the RS-232
   port, then the ifName objects for the corresponding PPP and RS-232
   entries in the ifTable would have the values "wan1.1" and
   "wan1.2", respectively.  As an another example, consider an agent
   which responds to SNMP queries concerning an interface on some
   other (proxied) device: if such a proxied device associates a
   particular identifier with an interface, then it is appropriate to
   use this identifier as the value of the interface's ifName, since
   the local console in this case is that of the proxied device.

   In contrast, the existing ifDescr object is intended to contain a
   description of an interface, whereas another new object, ifAlias,
   provides a location in which a network management application can
   store a non-volatile interface-naming value of its own choice.
   The ifAlias object allows a network manager to give one or more
   interfaces their own unique names, irrespective of any interface-
   stack relationship.  Further, the ifAlias name is non-volatile,
   and thus an interface must retain its assigned ifAlias value
   across reboots, even if an agent chooses a new ifIndex value for
   the interface.

3.1.6.  Counter Size

   As the speed of network media increase, the minimum time in which
   a 32 bit counter will wrap decreases.  For example, a 10Mbs stream
   of back-to-back, full-size packets causes ifInOctets to wrap in
   just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
   minutes, and at 1Gbs, the minimum is 34 seconds.  Requiring that
   interfaces be polled frequently enough not to miss a counter wrap
   is increasingly problematic.





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


   A rejected solution to this problem was to scale the counters; for
   example, ifInOctets could be changed to count received octets in,
   say, 1024 byte blocks.  While it would provide acceptable
   functionality at high rates of the counted-events, at low rates it
   suffers.  If there is little traffic on an interface, there might
   be a significant interval before enough of the counted-events
   occur to cause the scaled counter to be incremented.  Traffic
   would then appear to be very bursty, leading to incorrect
   conclusions of the network's performance.

   Instead, this memo adopts expanded, 64 bit, counters.  These
   counters are provided in new "high capacity" groups.  The old,
   32-bit, counters have not been deprecated.  The 64-bit counters
   are to be used only when the 32-bit counters do not provide enough
   capacity; that is, when the 32 bit counters could wrap too fast.

   For interfaces that operate at 20,000,000 (20 million) bits per
   second or less, 32-bit byte and packet counters MUST be used.  For
   interfaces that operate faster than 20,000,000 bits/second, and
   slower than 650,000,000 bits/second, 32-bit packet counters MUST
   be used and 64-bit octet counters MUST be used.  For interfaces
   that operate at 650,000,000 bits/second or faster, 64-bit packet
   counters AND 64-bit octet counters MUST be used.

   These speed thresholds were chosen as reasonable compromises based
   on the following:

   (1)  The cost of maintaining 64-bit counters is relatively high,
        so minimizing the number of agents which must support them is
        desirable.  Common interfaces (such as 10Mbs Ethernet) should
        not require them.

   (2)  64-bit counters are a new feature, introduced in SNMPv2.  It
        is reasonable to expect that support for them will be spotty
        for the immediate future.  Thus, we wish to limit them to as
        few systems as possible.  This, in effect, means that 64-bit
        counters should be limited to higher speed interfaces.
        Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
        fairly wide-spread so it seems reasonable to not require 64-
        bit counters for these interfaces.

   (3)  The 32-bit octet counters will wrap in the following times,
        for the following interfaces (when transmitting maximum-sized
        packets back-to-back):

        -   10Mbs Ethernet: 57 minutes,

        -   16Mbs Token Ring: 36 minutes,



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


        -   a US T3 line (45 megabits): 12 minutes,

        -   FDDI: 5.7 minutes

   (4)  The 32-bit packet counters wrap in about 57 minutes when 64-
        byte packets are transmitted back-to-back on a 650,000,000
        bit/second link.

   As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit
   octet counter to wrap in just under 5 years.  Conversely, an
   81,000,000 terabit/second link is required to cause a 64-bit counter
   to wrap in 30 minutes.  We believe that, while technology rapidly
   marches forward, this link speed will not be achieved for at least
   several years, leaving sufficient time to evaluate the introduction
   of 96 bit counters.

   When 64-bit counters are in use, the 32-bit counters MUST still be
   available.  They will report the low 32-bits of the associated 64-bit
   count (e.g., ifInOctets will report the least significant 32 bits of
   ifHCInOctets).  This enhances inter-operability with existing
   implementations at a very minimal cost to agents.