rfc3289.txt

RFC 的详细文档！

   and a "specific" pointer, to identify the parameters in question.
   This structure is a bow to SNMP's limitations; it would be better to
   have a structure with N rates and N+1 "next" pointers, with a single
   algorithm specified.  In this case, multiple meter entries connected
   by the "fail" link are understood to contain the parameters for a
   specified algorithm, and traffic conforming to a given rate follows
   their "succeed" paths.  Within this MIB, only Token Bucket parameters
   are specified; other varieties of meters may be designed in other MIB
   modules.

   When the MIB is used for configuration, diffServMeterNextFree always
   contains a legal value for diffServMeterId that is not currently used
   in the system's configuration.

3.3.2.  diffServTBParamTable - The Token Bucket Parameters Table

   The Token Bucket Parameters Table is a set of parameters that define
   a Token Bucket Meter.  As a parameter, a token bucket may be
   specified once and applied to many interfaces, using
   diffServMeterSpecific.  Specifically, several modes of [srTCM] and
   [trTCM] are addressed.  Other varieties of meters may be specified in
   other MIB modules.

   In general, if a Token Bucket has N rates, it has N+1 potential
   outcomes - the traffic stream is slower than and therefore conforms
   to all of the rates, it fails the first few but is slower than and
   therefore conforms to the higher rates, or it fails all of them.  As
   such, multi-rate meters should specify those rates in monotonically
   increasing order, passing through the diffServMeterFailNext from more
   committed to more excess rates, and finally falling through
   diffServMeterFailNext to the set of actions that apply to traffic
   which conforms to none of the specified rates.  diffServTBParamType
   in the first entry indicates the algorithm being used.  At each rate,
   diffServTBParamRate is derivable from diffServTBParamBurstSize and
   diffServTBParamInterval; a superior implementation will allow the






Baker, et. al.              Standards Track                    [Page 11]

RFC 3289              Differentiated Services MIB               May 2002


   configuration of any two of diffServTBParamRate,
   diffServTBParamBurstSize, and diffServTBParamInterval, and respond
   with the appropriate error code if all three are specified but are
   not mathematically related.

   When the MIB is used for configuration, diffServTBParamNextFree
   always contains a legal value for diffServTBParamId that is not
   currently used in the system's configuration.

3.4.  Actions applied to packets

   "Actions" are the things a differentiated services interface PHB may
   do to a packet in transit.  At a minimum, such a policy might
   calculate statistics on traffic in various configured classes, mark
   it with a DSCP, drop it, or enqueue it before passing it on for other
   processing.

   Actions are composed of a structural element, the
   diffServActionTable, and various component action entries that may be
   applied.  In the case of the Algorithmic Dropper, an additional
   parameter table may be specified to control Active Queue Management,
   as defined in [RED93] and other AQM specifications.

3.4.1.  diffServActionTable - The Action Table

   The action table identifies sequences of actions to be applied to a
   packet.  Successive actions are chained through diffServActionNext,
   ultimately resulting in zeroDotZero (indicating that the policy is
   complete), a pointer to a queue, or a pointer to some other
   functional data path element.

   When the MIB is used for configuration, diffServActionNextFree always
   contains a legal value for diffServActionId that is not currently
   used in the system's configuration.

3.4.2.  diffServCountActTable - The Count Action Table

   The count action accumulates statistics pertaining to traffic passing
   through a given path through the policy.  It is intended to be useful
   for usage-based billing, for statistical studies, or for analysis of
   the behavior of a policy in a given network.  The objects in the
   Count Action are various counters and a discontinuity time.  The
   counters display the number of packets and bytes encountered on the
   path since the discontinuity time.  They share the same discontinuity
   time, which is the discontinuity time of the interface or agent.






Baker, et. al.              Standards Track                    [Page 12]

RFC 3289              Differentiated Services MIB               May 2002


   The designers of this MIB expect that every path through a policy
   should have a corresponding counter.  In early versions, it was
   impossible to configure an action without implementing a counter,
   although the current design makes them in effect the network
   manager's option, as a result of making actions consistent in
   structure and extensibility.  The assurance of proper debugging and
   accounting is therefore left with the policy designer.

   When the MIB is used for configuration, diffServCountActNextFree
   always contains a legal value for diffServCountActId that is not
   currently used in the system's configuration.

3.4.3.  diffServDscpMarkActTable - The Mark Action Table

   The Mark Action table is an unusual table, both in SNMP and in this
   MIB.  It might be viewed not so much as an array of single-object
   entries as an array of OBJECT-IDENTIFIER conventions, as the OID for
   a diffServDscpMarkActDscp instance conveys all of the necessary
   information: packets are to be marked with the requisite DSCP.

   As such, contrary to common practice, the index for the table is
   read- only, and is both the Entry's index and its only value.

3.4.4.  diffServAlgDropTable - The Algorithmic Drop Table

   The Algorithmic Drop Table identifies a dropping algorithm, drops
   packets, and counts the drops.  Classified as an action, it is in
   effect a method which applies a packet to a queue, and may modify
   either.  When the algorithm is "always drop", this is simple; when
   the algorithm calls for head-drop, tail-drop, or a variety of Active
   Queue Management, the queue is inspected, and in the case of Active
   Queue Management, additional parameters are REQUIRED.

   What may not be clear from the name is that an Algorithmic Drop
   action often does not drop traffic.  Algorithms other than "always
   drop" normally drop a few percent of packets at most.  The action
   inspects the diffServQEntry that diffServAlgDropQMeasure points to in
   order to determine whether the packet should be dropped.

   When the MIB is used for configuration, diffServAlgDropNextFree
   always contains a legal value for diffServAlgDropId that is not
   currently used in the system's configuration.









Baker, et. al.              Standards Track                    [Page 13]

RFC 3289              Differentiated Services MIB               May 2002


3.4.5.  diffServRandomDropTable - The Random Drop Parameters Table

   The Random Drop Table is an extension of the Algorithmic Drop Table
   intended for use on queues whose depth is actively managed.  Active
   Queue Management algorithms are typified by [RED93], but the
   parameters they use vary.  It was deemed for the purposes of this MIB
   that the proper values to represent include:

      o  Target case mean queue depth, expressed in bytes or packets

      o  Worst case mean queue depth, expressed in bytes or packets

      o  Maximum drop rate expressed as drops per thousand

      o  Coefficient of an exponentially weighted moving average,
         expressed as the numerator of a fraction whose denominator is
         65536.

      o  Sampling rate

   An example of the representation chosen in this MIB for this element
   is shown in Figure 1.

   Random droppers often have their drop probability function described
   as a plot of drop probability (P) against averaged queue length (Q).
   (Qmin,Pmin) then defines the start of the characteristic plot.
   Normally Pmin=0, meaning with average queue length below Qmin, there
   will be no drops.  (Qmax,Pmax) defines a "knee" on the plot, after
   which point the drop probability becomes more progressive (greater
   slope).  (Qclip,1) defines the queue length at which all packets will
   be dropped.  Notice this is different from Tail Drop because this
   uses an averaged queue length, although it is possible for Qclip to
   equal Qmax.

   In the MIB module, diffServRandomDropMinThreshBytes and
   diffServRandomDropMinThreshPkts represent Qmin.
   diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPkts
   represent Qmax.  diffServAlgDropQThreshold represents Qclip.
   diffServRandomDropInvProbMax represents Pmax (inverse).  This MIB
   does not represent Pmin (assumed to be zero unless otherwise
   represented).  In addition, since message memory is finite, queues
   generally have some upper bound above which they are incapable of
   storing additional traffic.  Normally this number is equal to Qclip,
   specified by diffServAlgDropQThreshold.







Baker, et. al.              Standards Track                    [Page 14]

RFC 3289              Differentiated Services MIB               May 2002


          AlgDrop                                   Queue
          +-----------------+                       +-------+
      --->| Next   ---------+--+------------------->| Next -+--> ...
          | QMeasure -------+--+                    | ...   |
          | QThreshold      |     RandomDrop        +-------+
          | Type=randomDrop |     +----------------+
          | Specific -------+---->| MinThreshBytes |
          +-----------------+     | MaxThreshBytes |
                                  | ProbMax        |
                                  | Weight         |
                                  | SamplingRate   |
                                  +----------------+

    Figure 1: Example Use of the RandomDropTable for Random Droppers

   Each random dropper specification is associated with a queue.  This
   allows multiple drop processes (of same or different types) to be
   associated with the same queue, as different PHB implementations may
   require.  This also allows for sequences of multiple droppers if
   necessary.

   The calculation of a smoothed queue length may also have an important
   bearing on the behavior of the dropper: parameters may include the
   sampling interval or rate, and the weight of each sample.  The
   performance may be very sensitive to the values of these parameters
   and a wide range of possible values may be required due to a wide
   range of link speeds.  Most algorithms include a sample weight,
   represented here by diffServRandomDropWeight.  The availability of
   diffServRandomDropSamplingRate as readable is important, the
   information provided by Sampling Rate is essential to the
   configuration of diffServRandomDropWeight.  Having Sampling Rate be
   configurable is also helpful, as line speed increases, the ability to
   have queue sampling be less frequent than packet arrival is needed.
   Note, however, that there is ongoing research on this topic, see e.g.
   [ACTQMGMT] and [AQMROUTER].

   Additional parameters may be added in an enterprise MIB module, e.g.
   by using AUGMENTS on this table, to handle aspects of random drop
   algorithms that are not standardized here.

   When the MIB is used for configuration, diffServRandomDropNextFree
   always contains a legal value for diffServRandomDropId that is not
   currently used in the system's configuration.








Baker, et. al.              Standards Track                    [Page 15]

RFC 3289              Differentiated Services MIB               May 2002


3.5.  Queuing and Scheduling of Packets

   These include Queues and Schedulers, which are inter-related in their
   use of queuing techniques.  By doing so, it is possible to build
   multi-level schedulers, such as those which treat a set of queues as
   having priority among them, and at a specific priority find a
   secondary WFQ scheduler with some number of queues.

3.5.1.  diffServQTable - The Class or Queue Table

   The Queue Table models simple FIFO queues.  The Scheduler Table
   allows flexibility in constructing both simple and somewhat more
   complex queuing hierarchies from those queues.

   Queue Table entries are pointed at by the "next" attributes of the
   upstream elements, such as diffServMeterSucceedNext or
   diffServActionNext.  Note that multiple upstream elements may direct
   their traffic to the same Queue Table entry.  For example, the