diff options
Diffstat (limited to 'doc/rfc/rfc3086.txt')
| -rw-r--r-- | doc/rfc/rfc3086.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc3086.txt b/doc/rfc/rfc3086.txt new file mode 100644 index 0000000..af25f8b --- /dev/null +++ b/doc/rfc/rfc3086.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group K. Nichols +Request for Comments: 3086 Packet Design +Category: Informational B. Carpenter + IBM + April 2001 + + + Definition of Differentiated Services Per Domain Behaviors + and Rules for their Specification + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The differentiated services framework enables quality-of-service + provisioning within a network domain by applying rules at the edges + to create traffic aggregates and coupling each of these with a + specific forwarding path treatment in the domain through use of a + codepoint in the IP header. The diffserv WG has defined the general + architecture for differentiated services and has focused on the + forwarding path behavior required in routers, known as "per-hop + forwarding behaviors" (or PHBs). The WG has also discussed + functionality required at diffserv (DS) domain edges to select + (classifiers) and condition (e.g., policing and shaping) traffic + according to the rules. Short-term changes in the QoS goals for a DS + domain are implemented by changing only the configuration of these + edge behaviors without necessarily reconfiguring the behavior of + interior network nodes. + + The next step is to formulate examples of how forwarding path + components (PHBs, classifiers, and traffic conditioners) can be used + to compose traffic aggregates whose packets experience specific + forwarding characteristics as they transit a differentiated services + domain. The WG has decided to use the term per-domain behavior, or + PDB, to describe the behavior experienced by a particular set of + packets as they cross a DS domain. A PDB is characterized by + specific metrics that quantify the treatment a set of packets with a + particular DSCP (or set of DSCPs) will receive as it crosses a DS + domain. A PDB specifies a forwarding path treatment for a traffic + aggregate and, due to the role that particular choices of edge and + + + +Nichols & Carpenter Informational [Page 1] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + PHB configuration play in its resulting attributes, it is where the + forwarding path and the control plane interact. The measurable + parameters of a PDB should be suitable for use in Service Level + Specifications at the network edge. + + This document defines and discusses Per-Domain Behaviors in detail + and lays out the format and required content for contributions to the + Diffserv WG on PDBs and the procedure that will be applied for + individual PDB specifications to advance as WG products. This format + is specified to expedite working group review of PDB submissions. + +Table of Contents + + 1. Introduction ................................................ 2 + 2. Definitions ................................................. 4 + 3. The Value of Defining Edge-to-Edge Behavior ................. 5 + 4. Understanding PDBs .......................................... 7 + 5. Format for Specification of Diffserv Per-Domain Behaviors ...13 + 6. On PDB Attributes ...........................................16 + 7. A Reference Per-Domain Behavior .............................19 + 8. Guidelines for Advancing PDB Specifications .................21 + 9. Security Considerations .....................................22 + 10. Acknowledgements ............................................22 + References ..................................................22 + Authors' Addresses ..........................................23 + Full Copyright Statement ....................................24 + +1 Introduction + + Differentiated Services allows an approach to IP Quality of Service + that is modular, incrementally deployable, and scalable while + introducing minimal per-node complexity [RFC2475]. From the end + user's point of view, QoS should be supported end-to-end between any + pair of hosts. However, this goal is not immediately attainable. It + will require interdomain QoS support, and many untaken steps remain + on the road to achieving this. One essential step, the evolution of + the business models for interdomain QoS, will necessarily develop + outside of the IETF. A goal of the diffserv WG is to provide the + firm technical foundation that allows these business models to + develop. The first major step will be to support edge-to-edge or + intradomain QoS between the ingress and egress of a single network, + i.e., a DS Domain in the terminology of RFC 2474. The intention is + that this edge-to-edge QoS should be composable, in a purely + technical sense, to a quantifiable QoS across a DS Region composed of + multiple DS domains. + + + + + + +Nichols & Carpenter Informational [Page 2] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + The Diffserv WG has finished the first phase of standardizing the + behaviors required in the forwarding path of all network nodes, the + per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474, + 2597 and 2598 give a rich toolbox for differential packet handling by + individual boxes. The general architectural model for diffserv has + been documented in RFC 2475. An informal router model [MODEL] + describes a model of traffic conditioning and other forwarding + behaviors. However, technical issues remain in moving "beyond the + box" to intradomain QoS models. + + The ultimate goal of creating scalable end-to-end QoS in the Internet + requires that we can identify and quantify behavior for a group of + packets that is preserved when they are aggregated with other packets + as they traverse the Internet. The step of specifying forwarding + path attributes on a per-domain basis for a set of packets + distinguished only by the mark in the DS field of individual packets + is critical in the evolution of Diffserv QoS and should provide the + technical input that will aid in the construction of business models. + This document defines and specifies the term "Per-Domain Behavior" or + PDB to describe QoS attributes across a DS domain. + + Diffserv classification and traffic conditioning are applied to + packets arriving at the boundary of a DS domain to impose + restrictions on the composition of the resultant traffic aggregates, + as distinguished by the DSCP marking , inside the domain. The + classifiers and traffic conditioners are set to reflect the policy + and traffic goals for that domain and may be specified in a TCA + (Traffic Conditioning Agreement). Once packets have crossed the DS + boundary, adherence to diffserv principles makes it possible to group + packets solely according to the behavior they receive at each hop (as + selected by the DSCP). This approach has well-known scaling + advantages, both in the forwarding path and in the control plane. + Less well recognized is that these scaling properties only result if + the per-hop behavior definition gives rise to a particular type of + invariance under aggregation. Since the per-hop behavior must be + equivalent for every node in the domain, while the set of packets + marked for that PHB may be different at every node, PHBs should be + defined such that their characteristics do not depend on the traffic + volume of the associated BA on a router's ingress link nor on a + particular path through the DS domain taken by the packets. + Specifically, different streams of traffic that belong to the same + traffic aggregate merge and split as they traverse the network. If + the properties of a PDB using a particular PHB hold regardless of how + the temporal characteristics of the marked traffic aggregate change + as it traverses the domain, then that PDB scales. (Clearly this + assumes that numerical parameters such as bandwidth allocated to the + particular PDB may be different at different points in the network, + and may be adjusted dynamically as traffic volume varies.) If there + + + +Nichols & Carpenter Informational [Page 3] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + are limits to where the properties hold, that translates to a limit + on the size or topology of a DS domain that can use that PDB. + Although useful single-link DS domains might exist, PDBs that are + invariant with network size or that have simple relationships with + network size and whose properties can be recovered by reapplying + rules (that is, forming another diffserv boundary or edge to re- + enforce the rules for the traffic aggregate) are needed for building + scalable end-to-end quality of service. + + There is a clear distinction between the definition of a Per-Domain + Behavior in a DS domain and a service that might be specified in a + Service Level Agreement. The PDB definition is a technical building + block that permits the coupling of classifiers, traffic conditioners, + specific PHBs, and particular configurations with a resulting set of + specific observable attributes which may be characterized in a + variety of ways. These definitions are intended to be useful tools + in configuring DS domains, but the PDB (or PDBs) used by a provider + is not expected to be visible to customers any more than the specific + PHBs employed in the provider's network would be. Network providers + are expected to select their own measures to make customer-visible in + contracts and these may be stated quite differently from the + technical attributes specified in a PDB definition, though the + configuration of a PDB might be taken from a Service Level + Specification (SLS). Similarly, specific PDBs are intended as tools + for ISPs to construct differentiated services offerings; each may + choose different sets of tools, or even develop their own, in order + to achieve particular externally observable metrics. Nevertheless, + the measurable parameters of a PDB are expected to be among the + parameters cited directly or indirectly in the Service Level + Specification component of a corresponding SLA. + + This document defines Differentiated Services Per-Domain Behaviors + and specifies the format that must be used for submissions of + particular PDBs to the Diffserv WG. + +2 Definitions + + The following definitions are stated in RFCs 2474 and 2475 and are + repeated here for easy reference: + + " Behavior Aggregate: a collection of packets with the same codepoint + crossing a link in a particular direction. + + " Differentiated Services Domain: a contiguous portion of the + Internet over which a consistent set of differentiated services + policies are administered in a coordinated fashion. A + differentiated services domain can represent different + + + + +Nichols & Carpenter Informational [Page 4] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + administrative domains or autonomous systems, different trust + regions, different network technologies (e.g., cell/frame), hosts + and routers, etc. Also DS domain. + + " Differentiated Services Boundary: the edge of a DS domain, where + classifiers and traffic conditioners are likely to be deployed. A + differentiated services boundary can be further sub-divided into + ingress and egress nodes, where the ingress/egress nodes are the + downstream/upstream nodes of a boundary link in a given traffic + direction. A differentiated services boundary typically is found + at the ingress to the first-hop differentiated services-compliant + router (or network node) that a host's packets traverse, or at the + egress of the last-hop differentiated services-compliant router or + network node that packets traverse before arriving at a host. This + is sometimes referred to as the boundary at a leaf router. A + differentiated services boundary may be co-located with a host, + subject to local policy. Also DS boundary. + + To these we add: + + " Traffic Aggregate: a collection of packets with a codepoint that + maps to the same PHB, usually in a DS domain or some subset of a DS + domain. A traffic aggregate marked for the foo PHB is referred to + as the "foo traffic aggregate" or "foo aggregate" interchangeably. + This generalizes the concept of Behavior Aggregate from a link to a + network. + + " Per-Domain Behavior: the expected treatment that an identifiable or + target group of packets will receive from "edge-to-edge" of a DS + domain. (Also PDB.) A particular PHB (or, if applicable, list of + PHBs) and traffic conditioning requirements are associated with + each PDB. + + " A Service Level Specification (SLS) is a set of parameters and + their values which together define the service offered to a traffic + stream by a DS domain. It is expected to include specific values + or bounds for PDB parameters. + +3 The Value of Defining Edge-to-Edge Behavior + + 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 + 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 + 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 + + "As much as possible as soon as possible". + + Packets of this PDB will not be completely starved and when resources + are available (i.e., not required by packets from any other traffic + aggregate), network elements should be configured to permit packets + of this PDB to consume them. + + Network operators may bound the delay and loss rate for services + constructed from this PDB given knowledge about their network, but + such attributes are not part of the definition. + +7.1.4 Parameters + + None. + +7.1.5 Assumptions + + A properly functioning network, i.e., packets may be delivered from + any ingress to any egress. + +7.1.6 Example uses + + 1. For the normal Internet traffic connection of an organization. + + 2. For the "non-critical" Internet traffic of an organization. + + 3. For standard domestic consumer connections + +7.1.7 Environmental Concerns + + There are no environmental concerns specific to this PDB. + +7.1.8 Security Considerations for BE PDB + + There are no specific security exposures for this PDB. See the + general security considerations in [RFC2474] and [RFC2475]. + + + + + +Nichols & Carpenter Informational [Page 20] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + +8 Guidelines for writing PDB specifications + + G1. Following the format given in this document, write a draft and + submit it as an Internet Draft. The document should have "diffserv" + as some part of the name. Either as an appendix to the draft, or in + a separate document, provide details of deployment experience with + measured results on a network of non-trivial size carrying realistic + traffic and/or convincing simulation results (simulation of a range + of modern traffic patterns and network topologies as applicable). + The document should be brought to the attention of the diffserv WG + mailing list, if active. + + G2. Initial discussion should focus primarily on the merits of the + PDB, though comments and questions on the claimed attributes are + reasonable. This is in line with the Differentiated Services goal to + put relevance before academic interest in the specification of PDBs. + Academically interesting PDBs are encouraged, but would be more + appropriate for technical publications and conferences, not for + submission to the IETF. (An "academically interesting" PDB might + become a PDB of interest for deployment over time.) + + The implementation of the following guidelines varies, depending on + whether there is an active diffserv working group or not. + + Active Diffserv Working Group path: + + G3. Once consensus has been reached on a version of a draft that it + is a useful PDB and that the characteristics "appear" to be correct + (i.e., not egregiously wrong) that version of the draft goes to a + review panel the WG co-chairs set up to audit and report on the + characteristics. The review panel will be given a deadline for the + review. The exact timing of the deadline will be set on a case-by- + case basis by the co-chairs to reflect the complexity of the task and + other constraints (IETF meetings, major holidays) but is expected to + be in the 4-8 week range. During that time, the panel may correspond + with the authors directly (cc'ing the WG co-chairs) to get + clarifications. This process should result in a revised draft and/or + a report to the WG from the panel that either endorses or disputes + the claimed characteristics. + + G4. If/when endorsed by the panel, that draft goes to WG last call. + If not endorsed, the author(s) can give an itemized response to the + panel's report and ask for a WG Last Call. + + + + + + + + +Nichols & Carpenter Informational [Page 21] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + G5. If/when passes Last Call, goes to ADs for publication as a WG + Informational RFC in our "PDB series". + + If no active Diffserv Working Group exists: + + G3. Following discussion on relevant mailing lists, the authors + should revise the Internet Draft and contact the IESG for "Expert + Review" as defined in section 2 of RFC 2434 [RFC2434]. + + G4. Subsequent to the review, the IESG may recommend publication of + the Draft as an RFC, request revisions, or decline to publish as an + Informational RFC in the "PDB series". + +9 Security Considerations + + The general security considerations of [RFC2474] and [RFC2475] apply + to all PDBs. Individual PDB definitions may require additional + security considerations. + +10 Acknowledgements + + The ideas in this document have been heavily influenced by the + Diffserv WG and, in particular, by discussions with Van Jacobson, + Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, + Frank Kastenholz, Aaron Falk, and a host of other people who should + be acknowledged for their useful input but not be held accountable + for our mangling of it. Grenville Armitage coined "per domain + behavior (PDB)" though some have suggested similar terms prior to + that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert + reviewed the document and commented so as to improve its form. + +References + + [RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, "Definition + of the Differentiated Services Field (DS Field) in the IPv4 + and IPv6 Headers", RFC 2474, December 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and + W. Weiss, "An Architecture for Differentiated Services", + December 1998. + + [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, June 1999. + + [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited + Forwarding PHB", RFC 2598, June 1999. + + + + + +Nichols & Carpenter Informational [Page 22] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + + [RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color + Marker", RFC 2698, June 1999. + + [MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An + Informal Management Model for Diffserv Routers", Work in + Progress. + + [MIB] Baker, F., Chan, K. and A. Smith, "Management Information + Base for the Differentiated Services Architecture", Work in + Progress. + + [VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual + Wire' Per-Domain Behavior", Work in Progress. + + [WCG] Worldcom, "Internet Service Level Guarantee", + http://www.worldcom.com/terms/service_level_guarantee/ + t_sla_terms.phtml + + [PSI] PSINet, "Service Level Agreements", + http://www.psinet.com/sla/ + + [UU] UUNET USA Web site, "Service Level Agreements", + http://www.us.uu.net/support/sla/ + + [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA + Considerations", BCP 26, RFC 2434, October 1998. + +Authors' Addresses + + Kathleen Nichols + Packet Design, LLC + 2465 Latham Street, Third Floor + Mountain View, CA 94040 + USA + + EMail: nichols@packetdesign.com + + + Brian Carpenter + IBM + c/o iCAIR + Suite 150 + 1890 Maple Avenue + Evanston, IL 60201 + USA + + EMail: brian@icair.org + + + + +Nichols & Carpenter Informational [Page 23] + +RFC 3086 Diffserv per Domain Behaviors April 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Nichols & Carpenter Informational [Page 24] + |