rfc3086.txt

RFC 的详细文档！

   suffice.  A PDB's definition does not have to hold for arbitrary
   topologies of networks, but the limits on the range of applicability
   for a specific PDB must be clearly specified.

   In general, a PDB operates between N ingress points and M egress
   points at the DS domain boundary.  Even in the degenerate case where
   N=M=1, PDB attributes are more complex than the definition of PHB
   attributes since the concatenation of the behavior of intermediate
   nodes affects the former.  A complex case with N and M both greater
   than one involves splits and merges in the traffic path and is non-
   trivial to analyze.  Analytic, simulation, and experimental work will
   all be necessary to understand even the simplest PDBs.

4.2 Constructing PDBs

   A DS domain is configured to meet the network operator's traffic
   engineering goals for the domain independently of the performance
   goals for a particular flow of a traffic aggregate.  Once the



Nichols & Carpenter          Informational                     [Page 10]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   interior routers are configured for the number of distinct traffic
   aggregates that the network will handle, each PDB's allocation at the
   edge comes from meeting the desired performance goals for the PDB's
   traffic aggregate subject to that configuration of packet schedulers
   and bandwidth capacity.  The configuration of traffic conditioners at
   the edge may be altered by provisioning or admission control but the
   decision about which PDB to use and how to apply classification and
   traffic conditioning comes from matching performance to goals.

   For example, consider the DS domain of figure 3.  A PDB with an
   explicit bound on loss must apply traffic conditioning at the
   boundary to ensure that on the average no more packets are admitted
   than can emerge.  Though, queueing internal to the network may result
   in a difference between input and output traffic over some
   timescales, the averaging timescale should not exceed what might be
   expected for reasonably sized buffering inside the network.  Thus if
   bursts are allowed to arrive into the interior of the network, there
   must be enough capacity to ensure that losses don't exceed the bound.
   Note that explicit bounds on the loss level can be particularly
   difficult as the exact way in which packets merge inside the network
   affects the burstiness of the PDB's traffic aggregate and hence,
   loss.

   PHBs give explicit expressions of the treatment a traffic aggregate
   can expect at each hop.  For a PDB, this behavior must apply to
   merging and diverging traffic aggregates, thus characterizing a PDB
   requires understanding what happens to a PHB under aggregation.  That
   is, PHBs recursively applied must result in a known behavior.  As an
   example, since maximum burst sizes grow with the number of microflows
   or traffic aggregate streams merged, a PDB specification must address
   this.  A clear advantage of constructing behaviors that aggregate is
   the ease of concatenating PDBs so that the associated traffic
   aggregate has known attributes that span interior DS domains and,
   eventually, farther.  For example, in figure 1 assume that we have
   configured the foo PDB on the interior DS domains of AS2.  Then
   traffic aggregates associated with the foo PDB in each interior DS
   domain of AS2 can be merged at the shaded interior boundary routers.
   If the same (or fewer) traffic conditioners as applied at the
   entrance to AS2 are applied at these interior boundaries, the
   attributes of the foo PDB should continue to be used to quantify the
   expected behavior.  Explicit expressions of what happens to the
   behavior under aggregation, possibly parameterized by node in-degrees
   or network diameters, are necessary to determine what to do at the
   internal aggregation points.  One approach might be to completely
   reapply the traffic conditioning at these points; another might
   employ some limited rate-based remarking only.





Nichols & Carpenter          Informational                     [Page 11]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   Multiple PDBs may use the same PHB.  The specification of a PDB can
   contain a list of PHBs and their required configuration, all of which
   would result in the same PDB.  In operation, it is expected that a
   single domain will use a single PHB to implement a particular PDB,
   though different domains may select different PHBs.  Recall that in
   the diffserv definition [RFC2474], a single PHB might be selected
   within a domain by a list of DSCPs.  Multiple PDBs might use the same
   PHB in which case the transit performance of traffic aggregates of
   these PDBs will, of necessity, be the same.  Yet, the particular
   characteristics that the PDB designer wishes to claim as attributes
   may vary, so two PDBs that use the same PHB might not be specified
   with the same list of attributes.

   The specification of the transit expectations of PDBs across domains
   both assists in the deployment of QoS within a DS domain and helps
   enable the composition of end-to-end, cross-domain services to
   proceed by making it possible to hide details of a domain's internals
   while exposing characteristics necessary for QoS.

4.3 PDBs using PHB Groups

   The use of PHB groups to construct PDBs can be done in several ways.
   A single PHB member of a PHB group might be used to construct a
   single PDB.  For example, a PDB could be defined using just one of
   the Class Selector Compliant PHBs [RFC2474].  The traffic
   conditioning for that PDB and the required configuration of the
   particular PHB would be defined in such a way that there was no
   dependence or relationship with the manner in which other PHBs of the
   group are used or, indeed, whether they are used in that DS domain.
   In this case, the reasonable approach would be to specify this PDB
   alone in a document which expressly called out the conditions and
   configuration of the Class Selector PHB required.

   A single PDB can be constructed using more than one PHB from the same
   PHB group.  For example, the traffic conditioner described in RFC
   2698 might be used to mark a particular entering traffic aggregate
   for one of the three AF1x PHBs [RFC2597] while the transit
   performance of the resultant PDB is specified, statistically, across
   all the packets marked with one of those PHBs.

   A set of related PDBs might be defined using a PHB group.  In this
   case, the related PDBs should be defined in the same document.  This
   is appropriate when the traffic conditioners that create the traffic
   aggregates associated with each PDB have some relationships and
   interdependencies such that the traffic aggregates for these PDBs
   should be described and characterized together.  The transit
   attributes will depend on the PHB associated with the PDB and will
   not be the same for all PHBs in the group, though there may be some



Nichols & Carpenter          Informational                     [Page 12]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   parameterized interrelationship between the attributes of each of
   these PDBs.  In this case, each PDB should have a clearly separate
   description of its transit attributes (delineated in a separate
   subsection) within the document.  For example, the traffic
   conditioner described in RFC 2698 might be used to mark arriving
   packets for three different AF1x PHBs, each of which is to be treated
   as a separate traffic aggregate in terms of transit properties.  Then
   a single document could be used to define and quantify the
   relationship between the arriving packets and the emerging traffic
   aggregates as they relate to one another.  The transit
   characteristics of packets of each separate AF1x traffic aggregate
   should be described separately within the document.

   Another way in which a PHB group might be used to create one PDB per
   PHB might have decoupled traffic conditioners, but some relationship
   between the PHBs of the group.  For example, a set of PDBs might be
   defined using Class Selector Compliant PHBs [RFC2474] in such a way
   that the traffic conditioners that create the traffic aggregates are
   not related, but the transit performance of each traffic aggregate
   has some parametric relationship to the other.  If it makes sense to
   specify them in the same document, then the author(s) should do so.

4.4 Forwarding path vs. control plane

   A PDB's associated PHB, classifiers, and traffic conditioners are all
   in the packet forwarding path and operate at line rates.  PHBs,
   classifiers, and traffic conditioners are configured in response to
   control plane activity which takes place across a range of time
   scales, but, even at the shortest time scale, control plane actions
   are not expected to happen per-packet.  Classifiers and traffic
   conditioners at the DS domain boundary are used to enforce who gets
   to use the PDB and how the PDB should behave temporally.
   Reconfiguration of PHBs might occur monthly, quarterly, or only when
   the network is upgraded.  Classifiers and traffic conditioners might
   be reconfigured at a few regular intervals during the day or might
   happen in response to signalling decisions thousands of times a day.
   Much of the control plane work is still evolving and is outside the
   charter of the Diffserv WG.  We note that this is quite appropriate
   since the manner in which the configuration is done and the time
   scale at which it is done should not affect the PDB attributes.

5 Format for Specification of Diffserv Per-Domain Behaviors

   PDBs arise from a particular relationship between edge and interior
   (which may be parameterized).  The quantifiable characteristics of a
   PDB must be independent of whether the network edge is configured
   statically or dynamically.  The particular configuration of traffic




Nichols & Carpenter          Informational                     [Page 13]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   conditioners at the DS domain edge is critical to how a PDB performs,
   but the act(s) of configuring the edge is a control plane action
   which can be separated from the specification of the PDB.

   The following sections must be present in any specification of a
   Differentiated Services PDB.  Of necessity, their length and content
   will vary greatly.

5.1 Applicability Statement

   All PDB specs must have an applicability statement that outlines the
   intended use of this PDB and the limits to its use.

5.2 Technical specification

   This section specifies the rules or guidelines to create this PDB,
   each distinguished with "may", "must" and "should." The technical
   specification must list the classification and traffic conditioning
   required (if any) and the PHB (or PHBs) to be used with any
   additional requirements on their configuration beyond that contained
   in RFCs.  Classification can reflect the results of an admission
   control process.  Traffic conditioning may include marking, traffic
   shaping, and policing.  A Service Provisioning Policy might be used
   to describe the technical specification of a particular PDB.

5.3 Attributes

   A PDB's attributes tell how it behaves under ideal conditions if
   configured in a specified manner (where the specification may be
   parameterized).  These might include drop rate, throughput, delay
   bounds measured over some time period.  They may be bounds,
   statistical bounds, or percentiles (e.g., "90% of all packets
   measured over intervals of at least 5 minutes will cross the DS
   domain in less than 5 milliseconds").  A wide variety of
   characteristics may be used but they must be explicit, quantifiable,
   and defensible.  Where particular statistics are used, the document
   must be precise about how they are to be measured and about how the
   characteristics were derived.

   Advice to a network operator would be to use these as guidelines in
   creating a service specification rather than use them directly.  For
   example, a "loss-free" PDB would probably not be sold as such, but
   rather as a service with a very small packet loss probability.








Nichols & Carpenter          Informational                     [Page 14]

RFC 3086             Diffserv per Domain Behaviors            April 2001


5.4 Parameters

   The definition and characteristics of a PDB may be parameterized by
   network-specific features; for example, maximum number of hops,
   minimum bandwidth, total number of entry/exit points of the PDB
   to/from the diffserv network, maximum transit delay of network
   elements, minimum buffer size available for the PDB at a network
   node, etc.

5.5 Assumptions

   In most cases, PDBs will be specified assuming lossless links, no
   link failures, and relatively stable routing.  This is reasonable
   since otherwise it would be very difficult to quantify behavior and
   this is the operating conditions for which most operators strive.
   However, these assumptions must be clearly stated.  Since PDBs with
   specific bandwidth parameters require that bandwidth to be available,
   the assumptions to be stated may include standby capacity.  Some PDBs
   may be specifically targeted for cases where these assumptions do not
   hold, e.g., for high loss rate links, and such targeting must also be