rfc2215.txt

RFC 的详细文档！

   reported as indeterminate. This is described below.

   Note that while the granularity of measurement is microseconds, a
   conforming element is free to actually measure delays more loosely.
   The minimum requirement is that the element estimate its delay
   accurately to the nearest 100 microsecond granularity. Elements that
   can measure more accurately are, of course, encouraged to do so.

      NOTE: Measuring in milliseconds is not acceptable, because if the
      minimum delay value is a millisecond, a path with several hops
      will lead to a composed delay of at least several milliseconds,
      which is likely to be misleading.





Shenker & Wroclawski        Standards Track                    [Page 11]

RFC 2215          General Characterization Parameters     September 1997


   The XDR description of this parameter is:

                    unsigned int MINIMUM_PATH_LATENCY;

   The distinguished value (2**32)-1 is taken to mean "indeterminate
   latency". A network element which cannot accurately predict the
   latency of packets it is processing should set its local parameter to
   this value. Because the composition function limits the composed sum
   to this value, receipt of this value at a network element or
   application indicates that the true path latency is not known. This
   may happen because one or more network elements could not supply a
   value, or because the range of the composition calculation was
   exceeded.

 3.5. PATH_MTU

   This parameter computes the maximum transmission unit (MTU) for
   packets following a data path.  This value is required to invoke QoS
   control services which require that IP packet size be strictly
   limited to a specific MTU. Existing MTU discovery mechanisms cannot
   be used because they provide information only to the sender and they
   do not directly allow for QoS control services to specify MTU's
   smaller than the physical MTU.

   The local characterization parameter is the IP MTU, where the MTU of
   a network element is defined to be the maximum transmission unit the
   network element can accommodate without fragmentation, including IP
   and upper-layer protocol headers but not including link level
   headers.  The composition rule is to take the minimum of the network
   element's MTU and the previously composed value.  This quantity, when
   composed end-to-end, informs the endpoint of the maximum transmission
   unit that can traverse the path from sender to receiver without
   fragmentation.  The parameter_number for the MTU of the network
   element's link is 9.  The parameter_number for the composed MTU along
   the path is 10.

   A correct and valid value of this parameter must be provided by all
   IS-aware network elements.

   A specific service module may specify an MTU smaller than that of the
   overall network element by overriding this parameter with one giving
   the service's MTU value. A service module may not specify an MTU
   value larger than that given by the global parameter.

   Values of this parameter are measured in bytes.  The representation
   must be able to express values ranging from 1 byte to 2**32-1 bytes.





Shenker & Wroclawski        Standards Track                    [Page 12]

RFC 2215          General Characterization Parameters     September 1997


   The XDR description of this parameter is:

                          unsigned int PATH_MTU;

 3.6. TOKEN_BUCKET_TSPEC

   This parameter is used to describe data traffic parameters using a
   simple token bucket filter. This parameter is used by data senders to
   describe the traffic parameters of traffic it expects to generate,
   and by QoS control services to describe the parameters of traffic for
   which the reservation should apply. It is defined as a general rather
   than service-specific parameter because the same traffic description
   may be used by several QoS control services in some situations.

      NOTE: All previous definitions in this note have described
      "characterization parameters", with local values set by network
      elements to characterize their behavior and composition rules to
      give the resulting end-to-end behavior. The TOKEN_BUCKET_TSPEC is
      not a characterization parameter, because intermediate nodes
      within the network do not export local values for
      TOKEN_BUCKET_TSPECs. The TOKEN_BUCKET_TSPEC is simply a data
      structure definition given here because it is common to more than
      one QoS control service.

   The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127.

   The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification
   plus a peak rate [p], minimum policed unit [m], and a maximum packet
   size [M].

   The token bucket specification includes an average or token rate [r]
   and a bucket depth [b].  Both [r] and [b] must be positive.

   The token 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. In practice, only the first few digits of the
   [r] and [p] parameters 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. 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 peak traffic rate [p] 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. In practice, only the first few digits of



Shenker & Wroclawski        Standards Track                    [Page 13]

RFC 2215          General Characterization Parameters     September 1997


   the [r] and [p] parameters are significant, so the use of floating
   point representations, accurate to at least 0.1% is encouraged. The
   peak rate value may be set to positive infinity, indicating that it
   is unknown or unspecified.

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

   The minimum policed unit, [m], is an integer measured in bytes.  This
   size includes the application data and all protocol headers at or
   above the IP level (IP, TCP, UDP, RTP, etc.). It does not include the
   link-level header size, because these headers will change in size as
   the packet crosses different portions of the internetwork.

   All IP datagrams less than size [m] are treated as being of size m
   for purposes of resource allocation and policing. The purpose of this
   parameter is to allow reasonable estimation of the per-packet
   resources needed to process a flow's packets (maximum packet rate can
   be computed from the [b] and [m] terms) and to reasonably bound the
   bandwidth overhead consumed by the flow's link-level packet headers.
   The maximum bandwidth overhead consumed by link-level headers when
   carrying a flow's packets is bounded by the ratio of the link-level
   header size to [m]. Without the [m] term, it would be necessary to
   compute this bandwidth overhead assuming that every flow was always
   sending minimum-sized packets, which is unacceptable.

   The maximum packet size, [M], is the biggest packet that will conform
   to the traffic specification; it is also measured in bytes.  Any
   packets of larger size sent into the network may not receive QoS-
   controlled service, since they are considered to not meet the traffic
   specification.

   Both [m] and [M] must be positive, and [m] must be less then or equal
   to [M].

   The XDR description of this parameter is:

         struct {
           float r;
           float b;
           float p;
           unsigned m;
           unsigned M;
         } TOKEN_BUCKET_TSPEC;






Shenker & Wroclawski        Standards Track                    [Page 14]

RFC 2215          General Characterization Parameters     September 1997


   For the fields [r] and [b] only valid non-negative floating point
   numbers are allowed. Negative numbers (including "negative zero),
   infinities, and NAN's are not allowed.

   For the field [p], only valid non-negative floating point numbers or
   positive infinity are allowed. Negative numbers (including "negative
   zero), negative infinities, 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 parameter values meet these requirements before using the
      values in floating-point computations, in order to avoid
      unexpected exceptions or traps.

4. Security Considerations

   Implementation of the characterization parameters described in this
   memo creates no known new avenues for malicious attack on the network
   infrastructure.  Implementation of these characterization parameters
   does, of necessity, reveal some additional information about a
   network's performance, which in extremely rare circumstances could be
   viewed as a security matter by the network provider.

5. References

   [RFC 2005] Braden, R., Ed., et. al., "Resource Reservation Protocol
   (RSVP) - Version 1 Functional Specification", RFC 2205, September
   1997.

   [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
   Services", RFC 2210, September 1997.

   [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS
   Control Service Specification Template", RFC 2216, September 1997.

   [RFC 2212] Shenker, S., Partridge, C., and R. Guerin "Specification
   of the Guaranteed Quality of Service", RFC 2212, September 1997.

   [RFC 2211] Wroclawski, J., "Specification of the Controlled Load
   Quality of Service", RFC 2211, September 1997.

   [RFC 1832] Srinivansan, R., "XDR: External Data Representation
   Standard", RFC 1832, August 1995.








Shenker & Wroclawski        Standards Track                    [Page 15]

RFC 2215          General Characterization Parameters     September 1997


Authors' Addresses

   Scott Shenker
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304-1314

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

   Phone: [phone]
   Ffax:  617-253-2673 (FAX)
   EMail: [e-mail]































Shenker & Wroclawski        Standards Track                    [Page 16]