rfc2216.txt

RFC 的详细文档！

     This function is described further below and in [RFC 2210].

     - Least Common Request function. This function computes an
     invocation request sufficient to provide service at least
     equivalent to any one of the original requests passed to the
     function. This function differs from the RSVP-merge function in
     that it simply computes an upper bound. It does not need to compute
     new invocation parameters to be passed upstream by RSVP and cannot
     utilize the second option discussed in "Notes on RSVP Merging"
     below.

 oo Notes on Ordering

   Typically the ordering relation will be described separately for the
   service's TSpec and RSpec.  An invocation request is ordered with
   respect to another if and only if both its TSpec and its RSpec are
   similarly ordered with respect to each other.

   For TSpecs, the basic ordering relation is well defined.  TSpec A is
   substitutable for TSpec B if and only any flow that is compliant with
   TSpec B is also compliant with TSpec A. The service specification
   must explain how to compare two TSpecs to determine whether this is
   true.



Shenker & Wroclawski         Informational                     [Page 17]

RFC 2216            Network Element Service Template      September 1997


   For RSpecs, the ordering relation is dependent on the service. RSpec
   A is substitutable for RSpec B if the quality of service invoked by
   RSpec A is at least as good as the quality of service invoked by
   RSpec B.  Since there is no precise mathematical description of
   "goodness" of quality of service, these ordering relations must be
   spelled out explicitly in the service description.

 oo Notes on RSVP Merging

   The purpose of the RSVP merging function is to compute an invocation
   request which will provide service to the merged flow at least
   equivalent to that which any of the original requests would obtain
   for its corresponding unmerged flow. This equivalence may be obtained
   in two ways

     1) The merged request may be computed as an upper bound on the set
     of original (unmerged) invocation requests. In this case, the
     service offered by the merged request to any particular traffic
     flow is identical to that offered by the largest unmerged request,
     by definition.

     2) The merged request may be computed as a value smaller than the
     upper bound on the set of original requests, but the results passed
     upstream may restrict the traffic sources to behavior which makes
     the merged and unmerged requests behave identically.

   Note that the merging rules for a particular service may apply either
   option 1 or option 2 to the different components of a TSpec, as
   appropriate.  The decision is typically made as follows:

     When a downstream service module instance can tolerate a flow which
     exceeds the parameter, the upper bound should be used. For example,
     if the service supports policing to protect itself against excess
     traffic, the traffic rate supported by a merged reservation might
     be an upper bound across the traffic rates supported by each
     unmerged reservation. The effect of this will be to install the
     merged reservation at the local node and to inform each traffic
     source of the largest traffic rate protected by reservation along
     any *one* distribution path from the source to a receiver.

     When a downstream service module instance will not function
     properly if the parameter is exceeded, the merged function should
     select the least agressive value of the parameter to install and
     pass upstream. In this case, the traffic sources will be informed
     of a parameter value which is appropriate for *all* distribution
     paths traversed by the traffic flow. For example, services which
     can handle packets of only limited size can incorporate packet size
     in the TSpec, and treat the parmeter as described in option 2. The



Shenker & Wroclawski         Informational                     [Page 18]

RFC 2216            Network Element Service Template      September 1997


     effect of this will be to limit packet sizes in the flow to those
     which can be handled by every instance of the service along the
     flow's path.

   This merging calculation must be performed by the service module
   because it is specific to a particular service.

 oo Notes on Calculating Upper Bounds

   Both the RSVP-Merge function and the Least Common Request function
   may make use of calculated upper bounds on TSpec and RSpec
   parameters.

   The calculated upper bound need not be a least upper bound, nor do
   the various network elements along the path need to all use the same
   choice of upper bound.  Any selection of invocation parameters Iu is
   compliant as long as it substitutable for each of the parameters
   I1...In from which it is calculated.  Intuitively, one set of
   parameters is substitutable for another if the resulting quality of
   service is at least as desirable to all applications. A precise
   definition of this "substitutable for" function; the ordering
   relation, must be specified in the service definition. (It may be
   specified as the empty set, in which case merging of dissimilar
   requests will not be allowed). If the ordering function specified in
   this section gives a partial order (if it is possible for two RSpecs
   or TSpecs to be unordered), then a separate upper bound computation
   for the parmeter must be given as well.

 oo Notes on Service Substitution

   This portion of the service description may also note any
   relationships with other services which are strictly ordered with
   respect to the service being defined. Two services A and B are
   strictly ordered if it is always possible to substitute service B for
   the service A given a set of invocation parameters for service A.
   This ordering information may be used to allow network elements which
   provide service B to respond to requests for service A, even if the
   element does not provide service A directly. If the service
   specification describes such an inter-service ordering, it MUST also
   include a description of the invocation parameter mapping function
   for that ordering.

   Substitution of of one service for another in cases where they are
   not strictly ordered is currently not supported. A future version of
   this document may augment the service specification format to support
   this capability.





Shenker & Wroclawski         Informational                     [Page 19]

RFC 2216            Network Element Service Template      September 1997


 o Guidelines for Implementors

   Many services may be defined in a manner which allows the range of
   behavior of a compliant network element to be rather broad.  This
   section should provide some guidance as to what range of behaviors
   the author of the service specification expects the community to
   desire in their implementations.  Because these guidelines depend on
   such imprecise and undefinable notions at "typical loads", these
   guidelines cannot be incorporated as part of a strict compliance
   test. Instead, they are for informational purposes only.

 o Evaluation Criteria

   Specific functional behaviors required of an implementation for
   conformance to a service specification is detailed in the previous
   sections.  However, the service specifications are intended to allow
   a wide range of implementations, and these implementations will
   differ in performance. This section describes tests that can be used
   to evaluate a network element's implementation of a given service.

   Implementors of service modules face a number of tradeoffs, and it is
   unlikely that a single implementation would be considered "best"
   under all circumstances. For instance, given the same service
   specification, an implementation appropriate for a low-speed link
   might target extremely high link utilization, while a different
   implementation might attempt to reduce non-loaded packet forwarding
   delay to the minimum at the expense of somewhat lower utilization of
   the link. The intention of the tests specified in this section should
   be to probe the tradeoffs made by the implementation designer, and to
   provide metrics useful to guide the customer's choice of an
   appropriate implementation for her needs.

   The tests specified in this section should be designed to operate on
   a single network element in isolation. This enables their use in a
   comparative rating system for QoS-aware network elements. In
   production networks, users will be more concerned with the end-to-end
   behavior obtained, which will depend not just on the particular
   network elements selected, but also on other factors such as the
   setup protocol and the bandwidth of the links. Some user-relevant
   performance factors are the rate of admission control rejections, the
   range of services offered, and the packet delay and drop rates in the
   various service classes.  The form of any standardized end-to-end
   metrics and measurement tools for integrated service internetworks is
   not specified by this document or by service specification document
   which follow the format given here.

   This section is for informational purposes only.




Shenker & Wroclawski         Informational                     [Page 20]

RFC 2216            Network Element Service Template      September 1997


 o Examples of Implementation

   This section describes example instantiations of the service.  Often
   these will just be references to the literature, or brief sketches of
   how the service could be implemented.  The purposes of the section
   are to to provide a more concrete sense of the service being
   specified and to provide pointers and hints to aid the implementor.
   However, the descriptions in this section are specifically not
   intended to exclude other implementation strategies.

   This section is for informational purposes only.

 o Examples of Use

   In order to provide more a more concrete sense of how this service
   might be used, this section describes some example uses of the
   service, for informational purposes only.  The examples here are not
   meant to be exhaustive, and do not exclude in any way other uses of
   the service.

   This section is for informational purposes only.

Security Considerations

   Security considerations are not discussed in this memo.

References

   [PARTRIDGE] C. Partridge, Gigabit Networking, Addison Wesley
   Publishers (1994).

   [RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215,
   September 1997.

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

   [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
   of 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 1819] Delgrossi, L.,  and L. Berger, Editors, "Internet Stream
   Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC
   1819, August 1995.



Shenker & Wroclawski         Informational                     [Page 21]

RFC 2216            Network Element Service Template      September 1997


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

Authors' Address:

   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]
   Fax:   [phone]
   EMail: [e-mail]




























Shenker & Wroclawski         Informational                     [Page 22]