rfc2475.txt

中、英文RFC文档大全打包下载完全版 .

   forwarded unchanged while triggering some accounting procedure.
   Out-of-profile packets may be mapped to one or more behavior
   aggregates that are "inferior" in some dimension of forwarding
   performance to the BA into which in-profile packets are mapped.

   Note that a traffic profile is an optional component of a TCA and its
   use is dependent on the specifics of the service offering and the
   domain's service provisioning policy.

2.3.3  Traffic Conditioners

   A traffic conditioner may contain the following elements: meter,
   marker, shaper, and dropper.  A traffic stream is selected by a
   classifier, which steers the packets to a logical instance of a
   traffic conditioner.  A meter is used (where appropriate) to measure
   the traffic stream against a traffic profile.  The state of the meter



Blake, et. al.               Informational                     [Page 15]

RFC 2475        Architecture for Differentiated Services   December 1998


   with respect to a particular packet (e.g., whether it is in- or out-
   of-profile) may be used to affect a marking, dropping, or shaping
   action.

   When packets exit the traffic conditioner of a DS boundary node the
   DS codepoint of each packet must be set to an appropriate value.

   Fig. 1 shows the block diagram of a classifier and traffic
   conditioner.  Note that a traffic conditioner may not necessarily
   contain all four elements.  For example, in the case where no traffic
   profile is in effect, packets may only pass through a classifier and
   a marker.

                               +-------+
                               |       |-------------------+
                        +----->| Meter |                   |
                        |      |       |--+                |
                        |      +-------+  |                |
                        |                 V                V
                  +------------+      +--------+      +---------+
                  |            |      |        |      | Shaper/ |
    packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
                  |            |      |        |      |         |
                  +------------+      +--------+      +---------+


   Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner

2.3.3.1  Meters

   Traffic meters measure the temporal properties of the stream of
   packets selected by a classifier against a traffic profile specified
   in a TCA.  A meter passes state information to other conditioning
   functions to trigger a particular action for each packet which is
   either in- or out-of-profile (to some extent).

2.3.3.2  Markers

   Packet markers set the DS field of a packet to a particular
   codepoint, adding the marked packet to a particular DS behavior
   aggregate.  The marker may be configured to mark all packets which
   are steered to it to a single codepoint, or may be configured to mark
   a packet to one of a set of codepoints used to select a PHB in a PHB
   group, according to the state of a meter.  When the marker changes
   the codepoint in a packet it is said to have "re-marked" the packet.






Blake, et. al.               Informational                     [Page 16]

RFC 2475        Architecture for Differentiated Services   December 1998


2.3.3.3  Shapers

   Shapers delay some or all of the packets in a traffic stream in order
   to bring the stream into compliance with a traffic profile.  A shaper
   usually has a finite-size buffer, and packets may be discarded if
   there is not sufficient buffer space to hold the delayed packets.

2.3.3.4  Droppers

   Droppers discard some or all of the packets in a traffic stream in
   order to bring the stream into compliance with a traffic profile.
   This process is know as "policing" the stream.  Note that a dropper
   can be implemented as a special case of a shaper by setting the
   shaper buffer size to zero (or a few) packets.

2.3.4  Location of Traffic Conditioners and MF Classifiers

   Traffic conditioners are usually located within DS ingress and egress
   boundary nodes, but may also be located in nodes within the interior
   of a DS domain, or within a non-DS-capable domain.

2.3.4.1  Within the Source Domain

   We define the source domain as the domain containing the node(s)
   which originate the traffic receiving a particular service.  Traffic
   sources and intermediate nodes within a source domain may perform
   traffic classification and conditioning functions.  The traffic
   originating from the source domain across a boundary may be marked by
   the traffic sources directly or by intermediate nodes before leaving
   the source domain.  This is referred to as initial marking or "pre-
   marking".

   Consider the example of a company that has the policy that its CEO's
   packets should have higher priority.  The CEO's host may mark the DS
   field of all outgoing packets with a DS codepoint that indicates
   "higher priority".  Alternatively, the first-hop router directly
   connected to the CEO's host may classify the traffic and mark the
   CEO's packets with the correct DS codepoint.  Such high priority
   traffic may also be conditioned near the source so that there is a
   limit on the amount of high priority traffic forwarded from a
   particular source.

   There are some advantages to marking packets close to the traffic
   source.  First, a traffic source can more easily take an
   application's preferences into account when deciding which packets
   should receive better forwarding treatment.  Also, classification of





Blake, et. al.               Informational                     [Page 17]

RFC 2475        Architecture for Differentiated Services   December 1998


   packets is much simpler before the traffic has been aggregated with
   packets from other sources, since the number of classification rules
   which need to be applied within a single node is reduced.

   Since packet marking may be distributed across multiple nodes, the
   source DS domain is responsible for ensuring that the aggregated
   traffic towards its provider DS domain conforms to the appropriate
   TCA.  Additional allocation mechanisms such as bandwidth brokers or
   RSVP may be used to dynamically allocate resources for a particular
   DS behavior aggregate within the provider's network [2BIT, Bernet].
   The boundary node of the source domain should also monitor
   conformance to the TCA, and may police, shape, or re-mark packets as
   necessary.

2.3.4.2  At the Boundary of a DS Domain

   Traffic streams may be classified, marked, and otherwise conditioned
   on either end of a boundary link (the DS egress node of the upstream
   domain or the DS ingress node of the downstream domain).  The SLA
   between the domains should specify which domain has responsibility
   for mapping traffic streams to DS behavior aggregates and
   conditioning those aggregates in conformance with the appropriate
   TCA.  However, a DS ingress node must assume that the incoming
   traffic may not conform to the TCA and must be prepared to enforce
   the TCA in accordance with local policy.

   When packets are pre-marked and conditioned in the upstream domain,
   potentially fewer classification and traffic conditioning rules need
   to be supported in the downstream DS domain.  In this circumstance
   the downstream DS domain may only need to re-mark or police the
   incoming behavior aggregates to enforce the TCA.  However, more
   sophisticated services which are path- or source-dependent may
   require MF classification in the downstream DS domain's ingress
   nodes.

   If a DS ingress node is connected to an upstream non-DS-capable
   domain, the DS ingress node must be able to perform all necessary
   traffic conditioning functions on the incoming traffic.

2.3.4.3  In non-DS-Capable Domains

   Traffic sources or intermediate nodes in a non-DS-capable domain may
   employ traffic conditioners to pre-mark traffic before it reaches the
   ingress of a downstream DS domain.  In this way the local policies
   for classification and marking may be concealed.






Blake, et. al.               Informational                     [Page 18]

RFC 2475        Architecture for Differentiated Services   December 1998


2.3.4.4  In Interior DS Nodes

   Although the basic architecture assumes that complex classification
   and traffic conditioning functions are located only in a network's
   ingress and egress boundary nodes, deployment of these functions in
   the interior of the network is not precluded.  For example, more
   restrictive access policies may be enforced on a transoceanic link,
   requiring MF classification and traffic conditioning functionality in
   the upstream node on the link.  This approach may have scaling
   limits, due to the potentially large number of classification and
   conditioning rules that might need to be maintained.

2.4  Per-Hop Behaviors

   A per-hop behavior (PHB) is a description of the externally
   observable forwarding behavior of a DS node applied to a particular
   DS behavior aggregate.  "Forwarding behavior" is a general concept in
   this context.  For example, in the event that only one behavior
   aggregate occupies a link, the observable forwarding behavior (i.e.,
   loss, delay, jitter) will often depend only on the relative loading
   of the link (i.e., in the event that the behavior assumes a work-
   conserving scheduling discipline).  Useful behavioral distinctions
   are mainly observed when multiple behavior aggregates compete for
   buffer and bandwidth resources on a node.  The PHB is the means by
   which a node allocates resources to behavior aggregates, and it is on
   top of this basic hop-by-hop resource allocation mechanism that
   useful differentiated services may be constructed.

   The most simple example of a PHB is one which guarantees a minimal
   bandwidth allocation of X% of a link (over some reasonable time
   interval) to a behavior aggregate.  This PHB can be fairly easily
   measured under a variety of competing traffic conditions.  A slightly
   more complex PHB would guarantee a minimal bandwidth allocation of X%
   of a link, with proportional fair sharing of any excess link
   capacity.  In general, the observable behavior of a PHB may depend on
   certain constraints on the traffic characteristics of the associated
   behavior aggregate, or the characteristics of other behavior
   aggregates.

   PHBs may be specified in terms of their resource (e.g., buffer,
   bandwidth) priority relative to other PHBs, or in terms of their
   relative observable traffic characteristics (e.g., delay, loss).
   These PHBs may be used as building blocks to allocate resources and
   should be specified as a group (PHB group) for consistency.  PHB
   groups will usually share a common constraint applying to each PHB
   within the group, such as a packet scheduling or buffer management
   policy.  The relationship between PHBs in a group may be in terms of
   absolute or relative priority (e.g., discard priority by means of



Blake, et. al.               Informational                     [Page 19]

RFC 2475        Architecture for Differentiated Services   December 1998


   deterministic or stochastic thresholds), but this is not required
   (e.g., N equal link shares).  A single PHB defined in isolation is a
   special case of a PHB group.

   PHBs are implemented in nodes by means of some buffer management and
   packet scheduling mechanisms.  PHBs are defined in terms of behavior
   characteristics relevant to service provisioning policies, and not in
   terms of particular implementation mechanisms.  In general, a variety
   of implementation mechanisms may be suitable for implementing a
   particular PHB group.  Furthermore, it is likely that more than one
   PHB group may be implemented on a node and utilized within a domain.
   PHB groups should be defined such that the proper resource allocation
   between groups can be inferred, and integrated mechanisms can be
   implemented which can simultaneously support two or more groups.  A
   PHB group definition should indicate possible conflicts with
   previously documented PHB groups which might prevent simultaneous
   operation.

   As described in [DSFIELD], a PHB is selected at a node by a mapping
   of the DS codepoint in a received packet.  Standardized PHBs have a
   recommended codepoint.  However, the total space of codepoints is
   larger than the space available for recommended codepoints for
   standardized PHBs, and [DSFIELD] leaves provisions for locally
   configurable mappings.  A codepoint->PHB mapping table may contain
   both 1->1 and N->1 mappings.  All codepoints must be mapped to some
   PHB; in the absence of some local policy, codepoints which are not