rfc3086.txt

RFC 的详细文档！

   made explicit.  If additional restrictions, especially specific
   traffic engineering measures, are required, these must be stated.

   Further, if any assumptions are made about the allocation of
   resources within a diffserv network in the creation of the PDB, these
   must be made explicit.

5.6 Example Uses

   A PDB specification must give example uses to motivate the
   understanding of ways in which a diffserv network could make use of
   the PDB although these are not expected to be detailed.  For example,
   "A bulk handling PDB may be used for all packets which should not
   take any resources from the network unless they would otherwise go
   unused.  This might be useful for Netnews traffic or for traffic
   rejected from some other PDB by traffic policers."

5.7 Environmental Concerns (media, topology, etc.)

   Note that it is not necessary for a provider to expose which PDB (if
   a commonly defined one) is being used nor is it necessary for a
   provider to specify a service by the PDB's attributes.  For example,
   a service provider might use a PDB with a "no queueing loss"
   characteristic in order to specify a "very low loss" service.

   This section is to inject realism into the characteristics described
   above.  Detail the assumptions made there and what constraints that
   puts on topology or type of physical media or allocation.



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


5.8 Security Considerations for each PDB

   This section should include any security considerations that are
   specific to the PDB.  Is it subject to any unusual theft-of-service
   or denial-of-service attacks?  Are any unusual security precautions
   needed?

   It is not necessary to repeat the general security discussions in
   [RFC2474] and [RFC2475], but a reference should be included.  Also
   refer to any special security considerations for the PHB or PHBs
   used.

6 On PDB Attributes

   As discussed in section 4, measurable, quantifiable attributes
   associated with each PDB can be used to describe what will happen to
   packets using that PDB as they cross the domain.  In its role as a
   building block for the construction of interdomain quality-of-
   service, a PDB specification should provide the answer to the
   question: Under what conditions can we join the output of this domain
   to another under the same traffic conditioning and expectations?
   Although there are many ways in which traffic might be distributed,
   creating quantifiable, realizable PDBs that can be concatenated into
   multi-domain services limits the realistic scenarios.  A PDB's
   attributes with a clear statement of the conditions under which the
   attributes hold is critical to the composition of multi-domain
   services.

   There is a clear correlation between the strictness of the traffic
   conditioning and the quality of the PDB's attributes.  As indicated
   earlier, numerical bounds are likely to be statistical or expressed
   as a percentile.  Parameters expressed as strict bounds will require
   very precise mathematical analysis, while those expressed
   statistically can to some extent rely on experiment.  Section 7 gives
   the example of a PDB without strict traffic conditioning and
   concurrent work on a PDB with strict traffic conditioning and
   attributes is also in front of the WG [VW].  This section gives some
   general considerations for characterizing PDB attributes.

   There are two ways to characterize PDBs with respect to time.  First
   are properties over "long" time periods, or average behaviors.  A PDB
   specification should report these as the rates or throughput seen
   over some specified time period.  In addition, there are properties
   of "short" time behavior, usually expressed as the allowable
   burstiness in a traffic aggregate.  The short time behavior is
   important in understanding buffering requirements (and associated
   loss characteristics) and for metering and conditioning
   considerations at DS boundaries.  For short-time behavior, we are



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


   interested primarily in two things: 1) how many back-to-back packets
   of the PDB's traffic aggregate will we see at any point (this would
   be metered as a burst) and 2) how large a burst of packets of this
   PDB's traffic aggregate can appear in a queue at once (gives queue
   overflow and loss).  If other PDBs are using the same PHB within the
   domain, that must be taken into account.

6.1 Considerations in specifying long-term or average PDB attributes

   To characterize the average or long-term behavior for the foo PDB we
   must explore a number of questions, for instance: Can the DS domain
   handle the average foo traffic flow?  Is that answer topology
   dependent or are there some specific assumptions on routing which
   must hold for the foo PDB to preserve its "adequately provisioned"
   capability?  In other words, if the topology of D changes suddenly,
   will the foo PDB's attributes change?  Will its loss rate
   dramatically increase?

   Let domain D in figure 4 be an ISP ringing the U.S. with links of
   bandwidth B and with N tails to various metropolitan areas.  Inside
   D, if the link between the node connected to A and the node connected
   to Z goes down, all the foo traffic aggregate between the two nodes
   must transit the entire ring: Would the bounded behavior of the foo
   PDB change?  If this outage results in some node of the ring now
   having a larger arrival rate to one of its links than the capacity of
   the link for foo's traffic aggregate, clearly the loss rate would
   change dramatically.  In this case, topological assumptions were made
   about the path of the traffic from A to Z that affected the
   characteristics of the foo PDB.  If these topological assumptions no
   longer hold, the loss rate of packets of the foo traffic aggregate
   transiting the domain could change; for example, a characteristic
   such as "loss rate no greater than 1% over any interval larger than
   10 minutes." A PDB specification should spell out the assumptions
   made on preserving the attributes.

                  ____X________X_________X___________          /
                 /                                   \    L   |
         A<---->X                                     X<----->|  E
                |                                     |       |
                |               D                     |        \
         Z<---->X                                     |
                |                                     |
                 \___________________________________/
                         X                 X

        Figure 4: ISP and DS domain D connected in a ring and
                  connected to DS domain E




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


6.2 Considerations in specifying short-term or bursty PDB attributes

   Next, consider the short-time behavior of the traffic aggregate
   associated with a PDB, specifically whether permitting the maximum
   bursts to add in the same manner as the average rates will lead to
   properties that aggregate or under what conditions this will lead to
   properties that aggregate.  In our example, if domain D allows each
   of the uplinks to burst p packets into the foo traffic aggregate, the
   bursts could accumulate as they transit the ring.  Packets headed for
   link L can come from both directions of the ring and back-to-back
   packets from foo's traffic aggregate can arrive at the same time.  If
   the bandwidth of link L is the same as the links of the ring, this
   probably does not present a buffering problem.  If there are two
   input links that can send packets to queue for L, at worst, two
   packets can arrive simultaneously for L.  If the bandwidth of link L
   equals or exceeds twice B, the packets won't accumulate.  Further, if
   p is limited to one, and the bandwidth of L exceeds the rate of
   arrival (over the longer term) of foo packets (required for bounding
   the loss) then the queue of foo packets for link L will empty before
   new packets arrive.  If the bandwidth of L is equal to B, one foo
   packet must queue while the other is transmitted.  This would result
   in N x p back-to- back packets of this traffic aggregate arriving
   over L during the same time scale as the bursts of p were permitted
   on the uplinks.  Thus, configuring the PDB so that link L can handle
   the sum of the rates that ingress to the foo PDB doesn't guarantee
   that L can handle the sum of the N bursts into the foo PDB.

   If the bandwidth of L is less than B, then the link must buffer
   Nxpx(B-L)/B foo packets to avoid loss.  If the PDB is getting less
   than the full bandwidth L, this number is larger.  For probabilistic
   bounds, a smaller buffer might do if the probability of exceeding it
   can be bounded.

   More generally, for router indegree of d, bursts of foo packets might
   arrive on each input.  Then, in the absence of any additional traffic
   conditioning, it is possible that dxpx(# of uplinks) back-to-back foo
   packets can be sent across link L to domain E.  Thus the DS domain E
   must permit these much larger bursts into the foo PDB than domain D
   permits on the N uplinks or else the foo traffic aggregate must be
   made to conform to the TCA for entering E (e.g., by shaping).

   What conditions should be imposed on a PDB and on the associated PHB
   in order to ensure PDBs can be concatenated, as across the interior
   DS domains of figure 1?  Traffic conditioning for constructing a PDB
   that has certain attributes across a DS domain should apply
   independently of the origin of the packets.  With reference to the





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


   example we've been exploring, the TCA for the PDB's traffic aggregate
   entering link L into domain E should not depend on the number of
   uplinks into domain D.

6.3 Remarks

   This section has been provided as motivational food for thought for
   PDB specifiers.  It is by no means an exhaustive catalog of possible
   PDB attributes or what kind of analysis must be done.  We expect this
   to be an interesting and evolutionary part of the work of
   understanding and deploying differentiated services in the Internet.
   There is a potential for much interesting research work.  However, in
   submitting a PDB specification to the Diffserv WG, a PDB must also
   meet the test of being useful and relevant by a deployment
   experience, described in section 8.

7 A Reference Per-Domain Behavior

   The intent of this section is to define as a reference a Best Effort
   PDB, a PDB that has little in the way of rules or expectations.

7.1 Best Effort PDB

7.1.1 Applicability

   A Best Effort (BE) PDB is for sending "normal internet traffic"
   across a diffserv network.  That is, the definition and use of this
   PDB is to preserve, to a reasonable extent, the pre-diffserv delivery
   expectation for packets in a diffserv network that do not require any
   special differentiation.  Although the PDB itself does not include
   bounds on availability, latency, and packet loss, this does not
   preclude Service Providers from engineering their networks so as to
   result in commercially viable bounds on services that utilize the BE
   PDB.  This would be analogous to the Service Level Guarantees that
   are provided in today's single-service Internet.

   In the present single-service commercial Internet, Service Level
   Guarantees for availability, latency, and packet delivery can be
   found on the web sites of ISPs [WCG, PSI, UU].  For example, a
   typical North American round-trip latency bound is 85 milliseconds,
   with each service provider's site information specifying the method
   of measurement of the bounds and the terms associated with these
   bounds contractually.








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


7.1.2 TCS and PHB configurations

   There are no restrictions governing rate and bursts of packets beyond
   the limits imposed by the ingress link.  The network edge ensures
   that packets using the PDB are marked for the Default PHB (as defined
   in [RFC2474]), but no other traffic conditioning is required.
   Interior network nodes apply the Default PHB on these packets.

7.1.3 Attributes of this PDB