rfc2211.txt

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

   errors, are not bounded by this service.

5. Invocation Information

   The controlled-load service is invoked by specifying the data flow's
   desired traffic parameters (TSpec) to the network element. Requests
   placed for a new flow will be accepted if the network element has the
   capacity to forward the flow's packets as described above. Requests
   to change the TSpec for an existing flow should be treated as a new
   invocation, in the sense that admission control must be reapplied to
   the flow. Requests that reduce the TSpec for an existing flow (in the



Wroclawski                 Standards Track                      [Page 5]

RFC 2211                Controlled-Load Network           September 1997


   sense that the new TSpec is strictly smaller than the old TSpec
   according to the ordering rules given below) should never be denied
   service.

   The Controlled-Load service uses the TOKEN_BUCKET_TSPEC defined in
   Reference [5] to describe a data flow's traffic parameters. This
   TSpec takes the form of a token bucket specification plus a peak rate
   (p), a minimum policed unit (m) and a maximum packet size (M).

   The token bucket specification includes a bucket rate r and a bucket
   depth, b.  Both r and b must be positive.  The rate, r, is measured
   in bytes of IP datagrams per second. Values of this parameter may
   range from 1 byte per second to 40 terabytes per second. Network
   elements MUST return an error for requests containing values outside
   this range. Network elements MUST return an error for any request
   containing a value within this range which cannot be supported by the
   element. In practice, only the first few digits of the r parameter
   are significant, so the use of floating point representations,
   accurate to at least 0.1% is encouraged.

   The bucket depth, b, is measured in bytes. Values of this parameter
   may range from 1 byte to 250 gigabytes. Network elements MUST return
   an error for requests containing values outside this range. Network
   elements MUST return an error for any request containing a value
   within this range which cannot be supported by the element. In
   practice, only the first few digits of the b parameter are
   significant, so the use of floating point representations, accurate
   to at least 0.1% is encouraged.

   The range of values allowed for these parameters is intentionally
   large to allow for future network technologies. Any given network
   element is not expected to support the full range of values.

   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 parameter exists in this version of the specification
   primarily for TSpec compatability with other QoS control services and
   the shared TOKEN_BUCKET_TSPEC parameter. While some admission control
   and buffer allocation algorithms may find the peak rate value useful,
   the field may always be ignored by a Controlled-Load service
   conforming to this version of the specification. That is, the service
   module at a network element may always assume that the peak data rate
   arriving at that element is the line rate of the incoming interface,
   and the service's evaluation criteria do not require a network
   element to consider the peak rate value. More explicit use of the
   peak-rate parameter by a Controlled-Load service module may be added
   to the specification in the future.




Wroclawski                 Standards Track                      [Page 6]

RFC 2211                Controlled-Load Network           September 1997


   The minimum policed unit, m, is an integer measured in bytes.  All IP
   datagrams less than size m will be counted against the token bucket
   as being of size m. The maximum packet size, M, is the biggest packet
   that will conform to the traffic specification; it is also measured
   in bytes.  Network elements MUST reject a service request if the
   requested maximum packet size is larger than the MTU of the link.
   Both m and M must be positive, and m must be less then or equal to M.

   The preferred concrete representation for the TSpec is three floating
   point numbers in single-precision IEEE floating point format followed
   by two 32-bit integers in network byte order.  The first value is the
   rate (r), the second value is the bucket size (b), the third is the
   peak rate (p), the fourth is the minimum policed unit (m), and the
   fifth is the maximum packet size (M). For the parameters (r) and (b),
   only bit-patterns which represent valid non-negative floating point
   numbers are allowed. Negative numbers (including "negative zero),
   infinities, and NAN's are not allowed.  For the parameter (p) only
   bit-patterns which represent valid non-negative floating point
   numbers or positive infinity are allowed. Positive infinity is
   represented with an exponent of all ones (255) and a sign bit and
   mantissa of all zeroes. Negative numbers (including "negative zero"),
   negative infinity, and NAN's are not allowed.

      NOTE: An implementation which utilizes general-purpose hardware or
      software IEEE floating-point support may wish to verify that
      arriving parameters meet this requirement before using the
      parameters in floating-point computations, in order to avoid
      unexpected exceptions or traps.

   The controlled-load service is assigned service_name 5.

   The TOKEN_BUCKET_TSPEC parameter used by the Controlled-Load service
   is general parameter number 127, as indicated in [5].

6. Exported Information

   The controlled-load service has no required characterization
   parameters. Individual implementations may export appropriate
   implementation-specific measurement and monitoring information.

7. Policing

   The controlled-load service is provided to a flow on the basis that
   the flow's traffic conforms to a TSpec given at flow setup time. This
   section defines the meaning of conformance to the controlled-load
   TSpec, describes the circumstances under which a controlled-load
   flow's traffic might *not* conform to the TSpec, and specifies the
   network element's action in those circumstances.



Wroclawski                 Standards Track                      [Page 7]

RFC 2211                Controlled-Load Network           September 1997


   Controlled-load service modules provide QoS control for traffic
   conforming to the TSpec given at setup time.  The TSpec's token
   bucket parameters require that traffic must obey the rule that over
   all time periods, the amount of data sent does not exceed rT+b, where
   r and b are the token bucket parameters and T is the length of the
   time period.  For the purposes of this accounting, links must count
   packets that are smaller than the minimal policing unit m to be of
   size m.  Packets that arrive at an element and cause a violation of
   the the rT+b bound are considered nonconformant.

   Additionally, packets bigger than the outgoing link MTU are
   considered nonconformant.  It is expected that this situation will
   not arise with any frequency, because flow setup mechanisms are
   expected to notify the sending application of the appropriate path
   MTU.

   In the presence of nonconformant packets arriving for one or more
   controlled-load flows, each network element must ensure locally that
   the following requirements are met:

     1) The network element MUST continue to provide the contracted
     quality of service to those controlled-load flows not experiencing
     excess traffic.

     2) The network element SHOULD prevent excess controlled-load
     traffic from unfairly impacting the handling of arriving best-
     effort traffic.  This requirement is discussed further in Section 9
     of this document (Guidelines for Implementors).

     3) Consistent with points 1 and 2, the network element MUST attempt
     to forward the excess traffic on a best-effort basis if sufficient
     resources are available.

   Network elements must not assume that that arrival of nonconformant
   traffic for a specific controlled-load flow will be unusual, or
   indicative of error.  In certain circumstances (particularly, routers
   acting as the "split points" of a multicast distribution tree
   supporting a shared reservation) large numbers of packets will fail
   the conformance test *as a matter of normal operation*.

   Network elements must not assume that data sources or upstream
   elements have taken action to "police" controlled-load flows by
   limiting their traffic to conform to the flow's TSpec.  Each network
   element providing controlled-load service MUST independently ensure
   that the requirements given above are met in the presence of
   nonconformant arriving traffic for one or more controlled-load flows.





Wroclawski                 Standards Track                      [Page 8]

RFC 2211                Controlled-Load Network           September 1997


   Network elements may use any appropriate implementation mechanism to
   meet the requirements given above.  Examples of such mechanisms
   include token-bucket policing filters and per-flow scheduling
   algorithms.  However, it is insufficient to simply place all
   controlled-load flows into the same shared resource pool, without
   first ensuring that non-conformant flows are prevented from starving
   conformant flows of the necessary processing resources.

   Further discussion of this issue may be found in Section 11 of this
   note.

   Beyond requirements 2 and 3 above, the controlled-load service does
   not define the QoS behavior delivered to flows with non-conformant
   arriving traffic.  Specifically, it is permissible either to degrade
   the service delivered to all of the flow's packets equally, or to
   sort the flow's packets into a conformant set and a nonconformant set
   and deliver different levels of service to the two sets. This point
   is discussed further in Section 9 of this note.

   When resources are available, network elements at points within the
   interior of the network SHOULD be prepared to accommodate packet
   bursts somewhat larger than the actual TSpec. This requirement
   derives from the traffic distortion effect described in Section 4. As
   described there, it may be met either through explicit means or
   statistical multiplexing of shared buffering resources.

   When handling such traffic, it is permissible to allow some delaying
   of a packet if that delay would allow it to pass the policing
   function.  (In other words, to reshape the traffic).  However, the
   overall requirement for limiting the duration of any such traffic
   distortion must be considered. The challenge is to define a viable
   reshaping function.

   Intuitively, a plausible approach is to allow a delay of (roughly) up
   to the maximum queueing delay experienced by completely conforming
   packets before declaring that a packet has failed to pass the
   policing function. The merit of this approach, and the precise
   wording of the specification that describes it, require further
   study.

8. Ordering and Merging

   The controlled-load service TSpec is ordered according to the
   following rule: TSpec A is a substitute for ("as good or better than"
   or "greater than or equal to") TSpec B if and only if:






Wroclawski                 Standards Track                      [Page 9]

RFC 2211                Controlled-Load Network           September 1997


     (1) the token bucket rate r for TSpec A is greater than or equal to
     that of TSpec B,

     (2) the token bucket depth b for TSpec A is greater than or equal
     to that of TSpec B,

     (3) the peak rate p for TSpec A is greater than or equal to that of
     TSpec B,

     (4) the minimum policed unit m for TSpec A is less than or equal to
     that of TSpec B,

     (5) the maximum packet size M of TSpec A is greater than or equal
     to that of TSpec B.

   Note that not all TSpecs can be ordered with respect to each other.
   If two TSpecs differ but not all five of the points above are true,
   then the TSpecs are unordered.

   A merged TSpec is the TSpec used by the RSVP protocol when merging a
   set of TSpecs to create a "merged" reservation. TSpec merging is
   described further in [4] and [3]. The TSpec merge operation addresses
   two requirements: