rfc2212.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Shenker, et. al.            Standards Track                     [Page 5]

RFC 2212             Guaranteed Quality of Service        September 1997


   The TSpec takes the form of a token bucket plus a peak rate (p), a
   minimum policed unit (m), and a maximum datagram size (M).

   The token bucket has a bucket depth, b, and a bucket rate, r.  Both b
   and r MUST be positive.  The rate, r, is measured in bytes of IP
   datagrams per second, and can range from 1 byte per second to as
   large as 40 terabytes per second (or close to what is believed to be
   the maximum theoretical bandwidth of a single strand of fiber).
   Clearly, particularly for large bandwidths, only the first few digits
   are significant and so the use of floating point representations,
   accurate to at least 0.1% is encouraged.

   The bucket depth, b, is also measured in bytes and can range from 1
   byte to 250 gigabytes.  Again, floating point representations
   accurate to at least 0.1% are encouraged.

   The range of values is intentionally large to allow for the future
   bandwidths.  The range is not intended to imply that a network
   element has to support the entire range.

   The peak rate, p, is measured in bytes of IP datagrams per second and
   has the same range and suggested representation as the bucket rate.
   The peak rate is the maximum rate at which the source and any
   reshaping points (reshaping points are defined below) may inject
   bursts of traffic into the network.  More precisely, it is a
   requirement that for all time periods the amount of data sent cannot
   exceed M+pT where M is the maximum datagram size and T is the length
   of the time period.  Furthermore, p MUST be greater than or equal to
   the token bucket rate, r.  If the peak rate is unknown or
   unspecified, then p MUST be set to infinity.

   The minimum policed unit, m, is an integer measured in bytes.  All IP
   datagrams less than size m will be counted, when policed and tested
   for conformance to the TSpec, as being of size m.  The maximum
   datagram size, M, is the biggest datagram that will conform to the
   traffic specification; it is also measured in bytes.  The flow MUST
   be rejected if the requested maximum datagram size is larger than the
   MTU of the link.  Both m and M MUST be positive, and m MUST be less
   than or equal to M.

      The guaranteed service uses the general TOKEN_BUCKET_TSPEC
      parameter defined in Reference [8] to describe a data flow's
      traffic characteristics. The description above is of that
      parameter.  The TOKEN_BUCKET_TSPEC is general parameter number
      127. Use of this parameter for the guaranteed service TSpec
      simplifies the use of guaranteed Service in a multi-service
      environment.




Shenker, et. al.            Standards Track                     [Page 6]

RFC 2212             Guaranteed Quality of Service        September 1997


   The RSpec is a rate R and a slack term S, where R MUST be greater
   than or equal to r and S MUST be nonnegative.  The rate R is again
   measured in bytes of IP datagrams per second and has the same range
   and suggested representation as the bucket and the peak rates.  The
   slack term S is in microseconds.  The RSpec rate can be bigger than
   the TSpec rate because higher rates will reduce queueing delay.  The
   slack term signifies the difference between the desired delay and the
   delay obtained by using a reservation level R.  This slack term can
   be utilized by the network element to reduce its resource reservation
   for this flow. When a network element chooses to utilize some of the
   slack in the RSpec, it MUST follow specific rules in updating the R
   and S fields of the RSpec; these rules are specified in the Ordering
   and Merging section.  If at the time of service invocation no slack
   is specified, the slack term, S, is set to zero.  No buffer
   specification is included in the RSpec because the network element is
   expected to derive the required buffer space to ensure no queueing
   loss from the token bucket and peak rate in the TSpec, the reserved
   rate and slack in the RSpec, the exported information received at the
   network element, i.e., Ctot and Dtot or Csum and Dsum, combined with
   internal information about how the element manages its traffic.

   The TSpec can be represented by three floating point numbers in
   single-precision IEEE floating point format followed by two 32-bit
   integers in network byte order.  The first floating point value is
   the rate (r), the second floating point value is the bucket size (b),
   the third floating point is the peak rate (p), the first integer is
   the minimum policed unit (m), and the second integer is the maximum
   datagram size (M).

   The RSpec rate term, R, can also be represented using single-
   precision IEEE floating point.

   The Slack term, S, can be represented as a 32-bit integer.  Its value
   can range from 0 to (2**32)-1 microseconds.

   When r, b, p, and R terms are represented as IEEE floating point
   values, the sign bit MUST be zero (all values MUST be non-negative).
   Exponents less than 127 (i.e., 0) are prohibited.  Exponents greater
   than 162 (i.e., positive 35) are discouraged, except for specifying a
   peak rate of infinity.  Infinity is represented with an exponent of
   all ones (255) and a sign bit and mantissa of all zeroes.

Exported Information

   Each guaranteed service module MUST export at least the following
   information.  All of the parameters described below are
   characterization parameters.




Shenker, et. al.            Standards Track                     [Page 7]

RFC 2212             Guaranteed Quality of Service        September 1997


   A network element's implementation of guaranteed service is
   characterized by two error terms, C and D, which represent how the
   element's implementation of the guaranteed service deviates from the
   fluid model.  These two parameters have an additive composition rule.

   The error term C is the rate-dependent error term.  It represents the
   delay a datagram in the flow might experience due to the rate
   parameters of the flow.  An example of such an error term is the need
   to account for the time taken serializing a datagram broken up into
   ATM cells, with the cells sent at a frequency of 1/r.

      NOTE: It is important to observe that when computing the delay
      bound, parameter C is divided by the reservation rate R.  This
      division is done because, as with the example of serializing the
      datagram, the effect of the C term is a function of the
      transmission rate.  Implementors should take care to confirm that
      their C values, when divided by various rates, give appropriate
      results.  Delay values that are not dependent on the rate SHOULD
      be incorporated into the value for the D parameter.

   The error term D is the rate-independent, per-element error term and
   represents the worst case non-rate-based transit time variation
   through the service element.  It is generally determined or set at
   boot or configuration time.  An example of D is a slotted network, in
   which guaranteed flows are assigned particular slots in a cycle of
   slots.  Some part of the per-flow delay may be determined by which
   slots in the cycle are allocated to the flow.  In this case, D would
   measure the maximum amount of time a flow's data, once ready to be
   sent, might have to wait for a slot.  (Observe that this value can be
   computed before slots are assigned and thus can be advertised.  For
   instance, imagine there are 100 slots.  In the worst case, a flow
   might get all of its N slots clustered together, such that if a
   packet was made ready to send just after the cluster ended, the
   packet might have to wait 100-N slot times before transmitting.  In
   this case one can easily approximate this delay by setting D to 100
   slot times).

   If the composition function is applied along the entire path to
   compute the end-to-end sums of C and D (Ctot and Dtot) and the
   resulting values are then provided to the end nodes (by presumably
   the setup protocol), the end nodes can compute the maximal datagram
   queueing delays.  Moreover, if the partial sums (Csum and Dsum) from
   the most recent reshaping point (reshaping points are defined below)
   downstream towards receivers are handed to each network element then
   these network elements can compute the buffer allocations necessary






Shenker, et. al.            Standards Track                     [Page 8]

RFC 2212             Guaranteed Quality of Service        September 1997


   to achieve no datagram loss, as detailed in the section Guidelines
   for Implementors.  The proper use and provision of this service
   requires that the quantities Ctot and Dtot, and the quantities Csum
   and Dsum be computed.  Therefore, we assume that usage of guaranteed
   service will be primarily in contexts where these quantities are made
   available to end nodes and network elements.

   The error term C is measured in units of bytes.  An individual
   element can advertise a C value between 1 and 2**28 (a little over
   250 megabytes) and the total added over all elements can range as
   high as (2**32)-1.  Should the sum of the different elements delay
   exceed (2**32)-1, the end-to-end error term MUST be set to (2**32)-1.

   The error term D is measured in units of one microsecond.  An
   individual element can advertise a delay value between 1 and 2**28
   (somewhat over two minutes) and the total delay added over all
   elements can range as high as (2**32)-1.  Should the sum of the
   different elements delay exceed (2**32)-1, the end-to-end delay MUST
   be set to (2**32)-1.

   The guaranteed service is service_name 2.

   The RSpec parameter is numbered 130.

   Error characterization parameters C and D are numbered 131 and 132.
   The end-to-end composed values for C and D (Ctot and Dtot) are
   numbered 133 and 134.  The since-last-reshaping point composed values
   for C and D (Csum and Dsum) are numbered 135 and 136.

Policing

   There are two forms of policing in guaranteed service.  One form is
   simple policing (hereafter just called policing to be consistent with
   other documents), in which arriving traffic is compared against a
   TSpec.  The other form is reshaping, where an attempt is made to
   restore (possibly distorted) traffic's shape to conform to the TSpec,
   and the fact that traffic is in violation of the TSpec is discovered
   because the reshaping fails (the reshaping buffer overflows).

   Policing is done at the edge of the network.  Reshaping is done at
   all heterogeneous source branch points and at all source merge
   points.  A heterogeneous source branch point is a spot where the
   multicast distribution tree from a source branches to multiple
   distinct paths, and the TSpec's of the reservations on the various
   outgoing links are not all the same.  Reshaping need only be done if
   the TSpec on the outgoing link is "less than" (in the sense described
   in the Ordering section) the TSpec reserved on the immediately
   upstream link.  A source merge point is where the distribution paths



Shenker, et. al.            Standards Track                     [Page 9]

RFC 2212             Guaranteed Quality of Service        September 1997


   or trees from two different sources (sharing the same reservation)
   merge.  It is the responsibility of the invoker of the service (a
   setup protocol, local configuration tool, or similar mechanism) to
   identify points where policing is required.  Reshaping may be done at
   other points as well as those described above.  Policing MUST not be
   done except at the edge of the network.

   The token bucket and peak rate parameters require that traffic MUST
   obey the rule that over all time periods, the amount of data sent
   cannot exceed M+min[pT, rT+b-M], where r and b are the token bucket
   parameters, M is the maximum datagram size, and T is the length of
   the time period (note that when p is infinite this reduces to the
   standard token bucket requirement).  For the purposes of this
   accounting, links MUST count datagrams which are smaller than the
   minimum policing unit to be of size m.  Datagrams which arrive at an
   element and cause a violation of the the M+min[pT, rT+b-M] bound are
   considered non-conformant.

   At the edge of the network, traffic is policed to ensure it conforms
   to the token bucket.  Non-conforming datagrams SHOULD be treated as
   best-effort datagrams.  [If and when a marking ability becomes
   available, these non-conformant datagrams SHOULD be ''marked'' as
   being non-compliant and then treated as best effort datagrams at all
   subsequent routers.]

   Best effort service is defined as the default service a network
   element would give to a datagram that is not part of a flow and was
   sent between the flow's source and destination.  Among other
   implications, this definition means that if a flow's datagram is
   changed to a best effort datagram, all flow control (e.g., RED [2])
   that is normally applied to best effort datagrams is applied to that
   datagram too.

      NOTE: There may be situations outside the scope of this document,
      such as when a service module's implementation of guaranteed
      service is being used to implement traffic sharing rather than a
      quality of service, where the desired action is to discard non-
      conforming datagrams.  To allow for such uses, implementors SHOULD
      ensure that the action to be taken for non-conforming datagrams is
      configurable.

   Inside the network, policing does not produce the desired results,
   because queueing effects will occasionally cause a flow's traffic
   that entered the network as conformant to be no longer conformant at
   some downstream network element.  Therefore, inside the network,
   network elements that wish to police traffic MUST do so by reshaping
   traffic to the token bucket.  Reshaping entails delaying datagrams
   until they are within conformance of the TSpec.



Shenker, et. al.            Standards Track                    [Page 10]