rfc2815.txt

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

   provide policing (function three), policing for IEEE networks is
   generally implemented at the edge of the network by a layer-3 device.
   When this policing is performed only at the edges of the network it
   is of necessity approximate. This issue is discussed further in
   [IS802FRAME].

3.1.  Context of admission control and delay bounds

   As described above, it is the combination of priority-based
   scheduling and admission control that creates quantified delay
   bounds. Thus, any attempt to quantify the delay bounds expected by a
   given traffic class has to made in the context of the admission
   control elements. Section 6 of the framework [IS802FRAME] provides
   for two different models of admission control - centralized or
   distributed Bandwidth Allocators.



Seaman, et al.              Standards Track                     [Page 6]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   It is important to note that in this approach it is the admission
   control algorithm that determines which of the Int-Serv services is
   being offered. Given a set of priority classes with delay targets, a
   relatively simple admission control algorithm can place flows into
   classes so that the bandwidth and delay behavior experienced by each
   flow corresponds to the requirements of the Controlled-Load service,
   but cannot offer the higher assurance of the Guaranteed service. To
   offer the Guaranteed service, the admission control algorithm must be
   much more stringent in its allocation of resources, and must also
   compute the C and D error terms required of this service.

   A delay bound can only be realized at the admission control element
   itself so any delay numbers attached to a traffic class represent the
   delay that a single element can allow for.  That element may
   represent a whole L2 domain or just a single L2 segment.

   With either admission control model, the delay bound has no scope
   outside of a L2 domain. The only requirement is that it be understood
   by all Bandwidth Allocators in the L2 domain and, for example, be
   exported as C and D terms to L3 devices implementing the Guaranteed
   Service.  Thus, the end-to-end delay experienced by a flow can only
   be characterized by summing along the path using the usual RSVP
   mechanisms.

3.2.  Default service mappings

   Table 1 presents the default mapping from delay targets to IEEE 802.1
   user_priority classes. However, these mappings must be viewed as
   defaults, and must be changeable.

   In order to simplify the task of changing mappings, this mapping
   table is held by *switches* (and routers if desired) but generally
   not by end-station hosts.  It is a read-write table. The values
   proposed below are defaults and can be overridden by management
   control so long as all switches agree to some extent (the required
   level of agreement requires further analysis).

   In future networks this mapping table might be adjusted dynamically
   and without human intervention. It is possible that some form of
   network-wide lookup service could be implemented that serviced
   requests from clients e.g., traffic_class = getQoSbyName("H.323
   video") and notified switches of what traffic categories they were
   likely to encounter and how to allocate those requests into traffic
   classes.  Alternatively, the network's admission control mechanisms
   might directly adjust the mapping table to maximize the utilization
   of network resources. Such mechanisms are for further study.





Seaman, et al.              Standards Track                     [Page 7]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   The delay bounds numbers proposed in Table 1 are for per-Bandwidth
   Allocator element delay targets and are derived from a subjective
   analysis of the needs of typical delay-sensitive applications e.g.,
   voice, video. See Annex H of [802.1D] for further discussion of the
   selection of these values. Although these values appear to address
   the needs of current video and voice technology, it should be noted
   that there is no requirement to adhere to these values and no
   dependence of IEEE 802.1 on these values.

            user_priority  Service

                 0         Default, assumed to be Best Effort
                 1         reserved, "less than" Best Effort
                 2         reserved
                 3         reserved
                 4         Delay Sensitive, no bound
                 5         Delay Sensitive, 100ms bound
                 6         Delay Sensitive, 10ms bound
                 7         Network Control

             Table 1 - Example user_priority to service mappings

      Note: These mappings are believed to be useful defaults but
      further implementation and usage experience is required. The
      mappings may be refined in future editions of this document.

   With this example set of mappings, delay-sensitive, admission
   controlled traffic flows are mapped to user_priority values in
   ascending order of their delay bound requirement. Note that the
   bounds are targets only - see [IS802FRAME] for a discussion of the
   effects of other non-conformant flows on delay bounds of other flows.
   Only by applying admission control to higher-priority classes can any
   promises be made to lower-priority classes.

   This set of mappings also leaves several classes as reserved for
   future definition.

      Note: this mapping does not dictate what mechanisms or algorithms
      a network element (e.g., an Ethernet switch) must perform to
      implement these mappings: this is an implementation choice and
      does not matter so long as the requirements for the particular
      service model are met.

      Note: these mappings apply primarily to networks constructed from
      devices that implement the priority-scheduling behavior defined as
      the default in 802.1D. Some devices may implement more complex
      scheduling behaviors not based only on priority. In that
      circumstance these mappings might still be used, but other, more



Seaman, et al.              Standards Track                     [Page 8]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


      specialized mappings may be more appropriate.

3.3.  Discussion

   The recommendation of classes 4, 5 and 6 for Delay Sensitive,
   Admission Controlled flows is somewhat arbitrary; any classes with
   priorities greater than that assigned to Best Effort can be used.
   Those proposed here have the advantage that, for transit through
   802.1D switches with only two-level strict priority queuing, all
   delay-sensitive traffic gets "high priority" treatment (the 802.1D
   default split is 0-3 and 4-7 for a device with 2 queues).

   The choice of the delay bound targets is tuned to an average expected
   application mix, and might be retuned by a network manager facing a
   widely different mix of user needs. The choice is potentially very
   significant: wise choice can lead to a much more efficient allocation
   of resources as well as greater (though still not very good)
   isolation between flows.

   Placing Network Control traffic at class 7 is necessary to protect
   important traffic such as route updates and network management.
   Unfortunately, placing this traffic higher in the user_priority
   ordering causes it to have a direct effect on the ability of devices
   to provide assurances to QoS controlled application traffic.
   Therefore, an estimate of the amount of Network Control traffic must
   be made by any device that is performing admission control (e.g.,
   SBMs). This would be in terms of the parameters that are normally
   taken into account by the admission control algorithm. This estimate
   should be used in the admission control decisions for the lower
   classes (the estimate is likely to be a configuration parameter of
   SBMs).

   A traffic class such as class 1 for "less than best effort" might be
   useful for devices that wish to dynamically "penalty tag" all of the
   data of flows that are presently exceeding their allocation or Tspec.
   This provides a way to isolate flows that are exceeding their service
   limits from flows that are not, to avoid reducing the QoS delivered
   to flows that are within their contract. Data from such tagged flows
   might also be preferentially discarded by an overloaded downstream
   device.

   A somewhat simpler approach would be to tag only the portion of a
   flow's packets that actually exceed the Tspec at any given instant as
   low priority. However, it is often considered to be a bad idea to
   treat flows in this way as it will likely cause significant re-
   ordering of the flow's packets, which is not desirable. Note that the
   default 802.1D treatment of user_priorities 1 and 2 is "less than"
   the default class 0.



Seaman, et al.              Standards Track                     [Page 9]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


4.  Computation of integrated services characterization parameters by
    IEEE 802 devices

   The integrated service model requires that each network element that
   supports integrated services compute and make available certain
   "characterization parameters" describing the element's behavior.
   These parameters may be either generally applicable or specific to a
   particular QoS control service.  These parameters may be computed by
   calculation, measurement, or estimation. When a network element
   cannot compute its own parameters (for example, a simple link), we
   assume that the device sending onto or receiving data from the link
   will compute the link's parameters as well as it's own.  The accuracy
   of calculation of these parameters may not be very critical; in some
   cases loose estimates are all that is required to provide a useful
   service. This is important in the IEEE 802 case, where it will be
   virtually impossible to compute parameters accurately for certain
   topologies and switch technologies.  Indeed, it is an assumption of
   the use of this model by relatively simple switches (see [IS802FRAME]
   for a discussion of the different types of switch functionality that
   might be expected) that they merely provide values to describe the
   device and admit flows conservatively.  The discussion below presents
   a general outline for the computation of these parameters, and points
   out some cases where the parameters must be computed accurately.
   Further specification of how to export these parameters is for
   further study.

4.1.  General characterization parameters

   There are some general parameters [GENCHAR] that a device will need
   to use and/or supply for all service types:

   *  Ingress link

   *  Egress links and their MTUs, framing overheads and minimum packet
      sizes (see media-specific information presented above).

   *  Available path bandwidth: updated hop-by-hop by any device along
      the path of the flow.

   *  Minimum latency

   Of these parameters, the MTU and minimum packet size information must
   be reported accurately. Also, the "break bits" must be set correctly,
   both the overall bit that indicates the existence of QoS control
   support and the individual bits that specify support for a particular
   scheduling service. The available bandwidth should be reported as
   accurately as possible, but very loose estimates are acceptable. The
   minimum latency parameter should be determined and reported as



Seaman, et al.              Standards Track                    [Page 10]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   accurately as possible if the element offers Guaranteed service, but
   may be loosely estimated or reported as zero if the element offers
   only Controlled-Load service.

4.2.  Parameters to implement Guaranteed Service

   A network element supporting the Guaranteed Service [GS] must be able
   to determine the following parameters:

   *  Constant delay bound through this device (in addition to any value
      provided by "minimum latency" above) and up to the receiver at the
      next network element for the packets of this flow if it were to be
      admitted.  This includes any access latency bound to the outgoing
      link as well as propagation delay across that link. This value is
      advertised as the 'C' parameter of the Guaranteed Service.

   *  Rate-proportional delay bound through this device and up to the
      receiver at the next network element for the packets of this flow
      if it were to be admitted.  This value is advertised as the 'D'
      parameter of the Guaranteed Service.

   *  Receive resources that would need to be associated with this flow
      (e.g., buffering, bandwidth) if it were to be admitted and not
      suffer packet loss if it kept within its supplied Tspec/Rspec.
      These values are used by the admission control algorithm to decide
      whether a new flow can be accepted by the device.

   *  Transmit resources that would need to be associated with this flow
      (e.g., buffering, bandwidth, constant- and rate-proportional delay
      bounds) if it were to be admitted. These values are used by the
      admission control algorithm to decide whether a new flow can be
      accepted by the device.

   The exported characterization parameters for this service should be
   reported as accurately as possible. If estimations or approximations
   are used, they should err in whatever direction causes the user to
   receive better performance than requested. For example, the C and D
   error terms should overestimate delay, rather than underestimate it.

4.3.  Parameters to implement Controlled Load

   A network element implementing the Controlled Load service [CL] must
   be able to determine the following:

   *  Receive resources that would need to be associated with this flow
      (e.g., buffering) if it were to be admitted. These values are used
      by the admission control algorithm to decide whether a new flow
      can be accepted by the device.



Seaman, et al.              Standards Track                    [Page 11]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   *  Transmit resources that would need to be associated with this flow
      (e.g., buffering) if it were to be admitted. These values are used
      by the admission control algorithm to decide whether a new flow
      can be accepted by the device.

   The Controlled Load service does not export any service-specific
   characterization parameters. Internal resource allocation estimates
   should ensure that the service quality remains high when considering
   the statistical aggregation of Controlled Load flows into 802 traffic
   classes.

4.4.  Parameters to implement Best Effort

   For a network element that implements only best effort service there
   are no explicit parameters that need to be characterized. Note that
   an integrated services aware network element that implements only