rfc3086.txt

RFC 的详细文档！

   As defined in section 2, a PDB describes the edge-to-edge behavior
   across a DS domain's "cloud." Specification of the transit
   expectations of packets matching a target for a particular diffserv
   behavior across a DS domain will both assist in the deployment of
   single-domain QoS and will help enable the composition of end-to-end,
   cross-domain services.  Networks of DS domains can be connected to
   create end-to-end services by building on the PDB characteristics
   without regard to the particular PHBs used.  This level of



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


   abstraction makes it easier to compose cross-domain services as well
   as making it possible to hide details of a network's internals while
   exposing information sufficient to enable QoS.

   Today's Internet is composed of multiple independently administered
   domains or Autonomous Systems (ASs), represented by the "clouds" in
   figure 1.  To deploy ubiquitous end-to-end quality of service in the
   Internet, business models must evolve that include issues of charging
   and reporting that are not in scope for the IETF.  In the meantime,
   there are many possible uses of quality of service within an AS and
   the IETF can address the technical issues in creating an intradomain
   QoS within a Differentiated Services framework.  In fact, this
   approach is quite amenable to incremental deployment strategies.

   Where DS domains are independently administered, the evolution of the
   necessary business agreements and future signaling arrangements will
   take some time, thus, early deployments will be within a single
   administrative domain.  Putting aside the business issues, the same
   technical issues that arise in interconnecting DS domains with
   homogeneous administration will arise in interconnecting the
   autonomous systems (ASs) of the Internet.

                 ----------------------------------------
                 |                AS2                   |
                 |                                      |
    -------      |     ------------     ------------    |
    | AS1 |------|-----X           |    |          |    |
    -------      |     |           |    Y          |    |        -------
                 |     |           |   /|          X----|--------| AS3 |
                 |     |           |  / |          |    |        -------
                 |     |           | /  ------------    |
                 |     |           Y      |             |
                 |     |           | \  ------------    |
    -------      |     |           |  \ |          |    |
    | AS4 |------|-----X           |   \|          |    |
    -------      |     |           |    Y          X----|------
                 |     |           |    |          |    |
                 |     ------------     ------------    |
                 |                                      |
                 |                                      |
                 ----------------------------------------

         Figure 1: Interconnection of ASs and DS Domains

   A single AS (e.g., AS2 in figure 1) may be composed of subnetworks
   and, as the definition allows, these can be separate DS domains.  An
   AS might have multiple DS domains for a number of reasons, most
   notable being to follow topological and/or technological boundaries



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


   and to separate the allocation of resources.  If we confine ourselves
   to the DS boundaries between these "interior" DS domains, we avoid
   the non-technical problems of setting up a service and can address
   the issues of creating characterizable PDBs.

   The incentive structure for differentiated services is based on
   upstream domains ensuring their traffic conforms to the Traffic
   Conditioning Agreements (TCAs) with downstream domains and downstream
   domains enforcing that TCA, thus metrics associated with PDBs can be
   sensibly computed.  The letters "X" and "Y" in figure 1 represent the
   DS boundary routers containing traffic conditioners that ensure and
   enforce conformance (e.g., shapers and policers).  Although policers
   and shapers are expected at the DS boundaries of ASs (the "X" boxes),
   they might appear anywhere, or nowhere, inside the AS.  Specifically,
   the boxes at the DS boundaries internal to the AS (the "Y" boxes) may
   or may not condition traffic.  Technical guidelines for the placement
   and configuration of DS boundaries should derive from the attributes
   of a particular PDB under aggregation and multiple hops.

   This definition of PDB continues the separation of forwarding path
   and control plane described in RFC 2474.  The forwarding path
   characteristics are addressed by considering how the behavior at
   every hop of a packet's path is affected by the merging and branching
   of traffic aggregates through multiple hops.  Per-hop behaviors in
   nodes are configured infrequently, representing a change in network
   infrastructure.  More frequent quality-of-service changes come from
   employing control plane functions in the configuration of the DS
   boundaries.  A PDB provides a link between the DS domain level at
   which control is exercised to form traffic aggregates with quality-
   of-service goals across the domain and the per-hop and per-link
   treatments packets receive that results in meeting the quality-of-
   service goals.

4 Understanding PDBs

4.1 Defining PDBs

   RFCs 2474 and 2475 define a Differentiated Services Behavior
   Aggregate as "a collection of packets with the same DS codepoint
   crossing a link in a particular direction" and further state that
   packets with the same DSCP get the same per-hop forwarding treatment
   (or PHB) everywhere inside a single DS domain.  Note that even if
   multiple DSCPs map to the same PHB, this must hold for each DSCP
   individually.  In section 2 of this document, we introduced a more
   general definition of a traffic aggregate in the diffserv sense so
   that we might easily refer to the packets which are mapped to the
   same PHB everywhere within a DS domain.  Section 2 also presented a
   short definition of PDBs which we expand upon in this section:



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


   Per-Domain Behavior: the expected treatment that an identifiable or
     target group of packets will receive from "edge to edge" of a DS
     domain.  A particular PHB (or, if applicable, list of PHBs) and
     traffic conditioning requirements are associated with each PDB.

   Each PDB has measurable, quantifiable, attributes that can be used to
   describe what happens to its packets as they enter and cross the DS
   domain.  These derive from the characteristics of the traffic
   aggregate that results from application of classification and traffic
   conditioning during the entry of packets into the DS domain and the
   forwarding treatment (PHB) the packets get inside the domain, but can
   also depend on the entering traffic loads and the domain's topology.
   PDB attributes may be absolute or statistical and they may be
   parameterized by network properties.  For example, a loss attribute
   might be expressed as "no more than 0.1% of packets will be dropped
   when measured over any time period larger than T", a delay attribute
   might be expressed as "50% of delivered packets will see less than a
   delay of d milliseconds, 30% will see a delay less than 2d ms, 20%
   will see a delay of less than 3d ms." A wide range of metrics is
   possible.  In general they will be expressed as bounds or percentiles
   rather than as absolute values.

   A PDB is applied to a target group of packets arriving at the edge of
   the DS domain.  The target group is distinguished from all arriving
   packets by use of packet classifiers [RFC2475] (where the classifier
   may be "null").  The action of the PDB on the target group has two
   parts.  The first part is the the use of traffic conditioning to
   create a traffic aggregate.  During traffic conditioning, conformant
   packets are marked with a DSCP for the PHB associated with the PDB
   (see figure 2).  The second part is the treatment experienced by
   packets from the same traffic aggregate transiting the interior of a
   DS domain, between and inside of DS domain boundaries.  The following
   subsections further discuss these two effects on the target group
   that arrives at the DS domain boundary.

           -----------   ------------   --------------------   foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets   |           | |of packets  | |& marking (for foo) |  aggregate
           -----------   ------------   --------------------

         Figure 2: Relationship of the traffic aggregate associated
                    with a PDB to arriving packets









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


4.1.1 Crossing the DS edge: the effects of traffic conditioning on the
      target group

   This effect is quantified by the relationship of the emerging traffic
   aggregate to the entering target group.  That relationship can depend
   on the arriving traffic pattern as well as the configuration of the
   traffic conditioners.  For example, if the EF PHB [RFC2598] and a
   strict policer of rate R are associated with the foo PDB, then the
   first part of characterizing the foo PDB is to write the relationship
   between the arriving target packets and the departing foo traffic
   aggregate.  In this case, "the rate of the emerging foo traffic
   aggregate is less than or equal to the smaller of R and the arrival
   rate of the target group of packets" and additional temporal
   characteristics of the packets (e.g., burst) may be specified as
   desired.  Thus, there is a "loss rate" on the arriving target group
   that results from sending too much traffic or the traffic with the
   wrong temporal characteristics.  This loss rate should be entirely
   preventable (or controllable) by the upstream sender conforming to
   the traffic conditioning associated with the PDB specification.

   The issue of "who is in control" of the loss (or demotion) rate helps
   to clearly delineate this component of PDB performance from that
   associated with transiting the domain.  The latter is completely
   under control of the operator of the DS domain and the former is used
   to ensure that the entering traffic aggregate conforms to the traffic
   profile to which the operator has provisioned the network.  Further,
   the effects of traffic conditioning on the target group can usually
   be expressed more simply than the effects of transiting the DS domain
   on the traffic aggregate's traffic profile.

   A PDB may also apply traffic conditioning at DS domain egress.  The
   effect of this conditioning on the overall PDB attributes would be
   treated similarly to the ingress characteristics (the authors may
   develop more text on this in the future, but it does not materially
   affect the ideas presented in this document.)

4.1.2 Crossing the DS domain: transit effects

   The second component of PDB performance is the metrics that
   characterize the transit of a packet of the PDB's traffic aggregate
   between any two edges of the DS domain boundary shown in figure 3.
   Note that the DS domain boundary runs through the DS boundary routers
   since the traffic aggregate is generally formed in the boundary
   router before the packets are queued and scheduled for output.  (In
   most cases, this distinction is expected to be important.)






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


   DSCPs should not change in the interior of a DS domain as there is no
   traffic conditioning being applied.  If it is necessary to reapply
   the kind of traffic conditioning that could result in remarking,
   there should be a DS domain boundary at that point, though such an
   "interior" boundary can have "lighter weight" rules in its TCA.
   Thus, when measuring attributes between locations as indicated in
   figure 3, the DSCP at the egress side can be assumed to have held
   throughout the domain.

                               -------------
                               |           |
                          -----X           |
                               |           |
                               |   DS      |
                               |   domain  X----
                               |           |
                          -----X           |
                               |           |
                               -------------

          Figure 3: Range of applicability of attributes of a traffic
                    aggregate associated with a PDB (is between the
                    points marked "X")

   Though a DS domain may be as small as a single node, more complex
   topologies are expected to be the norm, thus the PDB definition must
   hold as its traffic aggregate is split and merged on the interior
   links of a DS domain.  Packet flow in a network is not part of the
   PDB definition; the application of traffic conditioning as packets
   enter the DS domain and the consistent PHB through the DS domain must