rfc2211.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,068 行 · 第 1/4 页

   The third variable should be specifically evaluated using the
   following procedure.

     With no controlled-load flows in place, overload the network
     element with best-effort traffic (as indicated by substantial
     packet loss and queueing delay).

     Execute requests for controlled-load service giving TSpecs with
     increasingly large rate and burst parameters. If the request is
     accepted, verify that traffic matching the TSpec is in fact handled
     with characteristics closely approximating the unloaded
     measurements taken above.

     Repeat these experiments to determine the range of traffic
     parameter (rate, burst size) values successfully handled by the
     network element. The useful range of each parameter must be
     determined for several settings of the other parameter, to map out
     a two-dimensional "region" of successfully handled TSpecs. When
     compared with network elements providing similar capabilities, this
     region indicates the relative ability of the elements to provide
     controlled-load service under high load. A larger region indicates
     a higher evaluation rating.

11. Examples of Implementation

   One possible implementation of controlled-load service is to provide
   a queueing mechanism with two priority levels; a high priority one
   for controlled-load and a lower priority one for best effort service.
   An admission control algorithm is used to limit the amount of traffic
   placed into the high-priority queue. This algorithm may be based
   either on the specified characteristics of the high-priority flows
   (using information provided by the TSpecs), or on the measured
   characteristics of the existing high-priority flows and the TSpec of
   the new request.

   Another possible implementation of controlled-load service is based
   on the existing capabilities of network elements which support



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


   "traffic classes" based on mechanisms such as weighted fair queueing
   or class-based queueing [6]. In this case, it is sufficient to map
   data flows accepted for controlled-load service into an existing
   traffic class with adequate capacity to avoid overload. This

   requirement is enforced by an admission control algorithm which
   considers the characteristics of the traffic class, the
   characteristics of the traffic already admitted to the class, and the
   TSpec of the new flow requesting service. Again, the admission
   control algorithm may be based either on the TSpec-specified or the
   measured characteristics of the existing traffic.

   A specific case of the above approach is to employ a scheduler which
   implements weighted fair queueing or similar load-management scheme,
   allocating a separate scheduling queue with correctly chosen weight
   to each individual controlled-load flow.  In this circumstance, the
   traffic scheduler also plays the role of the policing function, by
   ensuring that nonconformant traffic arriving for one controlled-load
   flow does not affect either other controlled-load flows or the best-
   effort traffic. This elimination of mechanism is balanced by the
   drawback that the approach does not benefit from any performance or
   resource usage gain arising from statistical aggregation of several
   flows into a single queueing class.

   Admission control algorithms based on specified characteristics are
   likely be appropriate when the number of flows in the high-priority
   class is small, or the traffic characteristics of the flows appear
   highly variable. In these situations the measured behavior of the
   aggregate controlled-load traffic stream may not serve as an
   effective predictor of future traffic, leading a measurement-based
   admission control algorithm to produce incorrect results. Conversely,
   in situations where the past behavior of the aggregate controlled-
   load traffic *is* a good predictor of future behavior, a measurement-
   based admission control algorithm may allow more traffic to be
   admitted to the controlled-load service class with no degradation in
   performance. An implementation may choose to switch between these two
   approaches depending on the nature of the traffic stream at a given
   time.

   A variety of techniques may be used to provide the desired isolation
   between excess (nonconformant) controlled-load traffic and other
   best-effort traffic. Use of a low priority queue for nonconformant
   controlled-load traffic is simple, but other approaches may provide
   superior service or fit better into existing architectures.  Variants
   of fair queueing or weighted fair queueing may be used to allocate a
   percentage of the available resources to different best-effort
   traffic classes. One approach would be to allocate each controlled-
   load flow a a 1/N "fair share" percentage of the available best-



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


   effort bandwidth for its excess traffic. An alternate approach would
   be to provide a single WFQ resource class for all excess controlled-
   load traffic.  Finally, alternate mechanisms such as RED [xxx] may be
   used to provide the same overall function.

12. Examples of Use

   The controlled-load service may be used by any application which can
   make use of best-effort service, but is best suited to those
   applications which can usefully characterize their traffic
   requirements.  Applications based on the transport of "continuous
   media" data, such as digitized audio or video, are an important
   example of this class.

   The controlled-load service is not isochronous and does not provide
   any explicit information about transmission delay. For this reason,
   applications with end-to-end timing requirements, including the
   continuous-media class mentioned above, provide an application-
   specific timing recovery mechanism, similar or identical to the
   mechanisms required when these applications use best-effort service.
   A protocol useful to applications requiring this capability is the
   IETF Real-Time Transport Protocol [2].

   Load-sensitive applications may choose to request controlled-load
   service whenever they are run. Alternatively, these applications may
   monitor their own performance and request controlled-load service
   from the network only when best-effort service is not providing
   acceptable performance. The first strategy provides higher assurance
   that the level of quality delivered to the user will not change over
   the lifetime of an application session. The second strategy provides
   greated flexibility and offers cost savings in environments where
   levels of service above best-effort incur a charge.

13. Security Considerations

   A network element implementing the service described here is
   intentionally and explicitly expected to give preferential treatment
   to selected packet traffic. This memo does not describe the mechanism
   used to indicate which traffic is to receive the preferential
   treatment - rather, the controlled-load service described here may be
   invoked by a number of mechanisms, including RSVP, SNMP network
   management software, or proprietary control software. However, any
   mechanism used to invoke the controlled load service must provide
   security sufficient to guard against use of this preferential
   treatment capability by undesired or unauthorized traffic.  A correct
   implementation of the controlled-load service is *not* susceptable to
   a denial-of-service attack based on maliciously requesting a very
   small resource allocation for the attacked traffic flow. This is



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


   because the service specification requires that traffic in excess of
   the requested level be carried on a best-effort basis, rather than
   being dropped. This requirement is discussed further in Section 7 of
   this memo.

   Of necessity, giving preferential service to certain traffic flows
   implies giving less service to other traffic flows.  Thus, it is
   possible to conduct a denial of service attack by maliciously
   reconfiguring the controlled-load "admission control algorithm" to
   allow overallocation of available bandwidth or other forwarding
   resources, starving non-controlled-load flows. In general, this is
   unlikely to increase the network's vulnerability to attack, because
   many other reconfigurations of a router or host can cause denial of
   service. It is reasonable to assume that whatever means is used to
   protect against other reconfiguration attacks will be adequate to
   protect against this one as well.

Appendix 1: Use of the Controlled-Load service with RSVP

   The use of Controlled-Load service in conjunction with the RSVP
   resource reservation setup protocol is specified in reference [4].
   This document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and
   ADSPEC objects needed to support applications desiring Controlled-
   Load service and gives information about how RSVP processes those
   objects. The RSVP protocol itself is specified in Reference [3].

References

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

   [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
   "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
   January 1996.

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

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

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







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


   [6] S. Floyd, and V. Jacobson.  "Link-sharing and Resource Management
   Models for Packet Networks," IEEE/ACM Transactions on Networking,
   Vol. 3 No. 4, pp. 365-386, August 1995.

   [7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to
   Flow Control in Integrated Service Networks". MIT Laboratory for
   Information and Decision Systems, Report LIDS-TH-2089, February 1992

Author's Address

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

   Phone: [phone]
   Fax:   [phone] (FAX)
   EMail: [e-mail]

































Wroclawski                 Standards Track                     [Page 19]