Internet Draft
Internet Engineering Task Force			K. Nichols
Differentiated Services Working Group		Packet Design
Internet Draft					B. Carpenter
Expires in December, 2000			IBM
draft-ietf-diffserv-pdb-def-00.txt		June, 2000

	Definition of Differentiated Services Per Domain 
	   Behaviors and Rules for their Specification

	<draft-ietf-diffserv-pdb-def-00>

Status of this Memo

This document is an Internet-Draft and is in full conformance 
with all provisions of Section 10 of RFC2026. Internet-Drafts are 
working documents of the Internet Engineering Task Force 
(IETF), its areas, and its working groups. Note that other groups 
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six 
months and may be updated, replaced, or obsoleted by other doc-
uments at any time. It is inappropriate to use Internet-Drafts as 
reference material or to cite them other than as "work in 
progress."

This document is a product of the Diffserv working group. Com-
ments on this draft should be directed to the Diffserv mailing list  
. The list of current Internet-Drafts can be 
accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of 
Internet-Draft Shadow Directories can be accessed at http://
www.ietf.org/shadow.html. Distribution of this memo is unlim-
ited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

The diffserv WG has defined the general architecture for differen-
tiated services (RFC 2475) and has been focused on the definition 
and standardization of the forwarding path behavior required in 
routers, known as "per-hop forwarding behaviors" (or PHBs) 
(RFCs 2474, 2597, and 2598). The differentiated services frame-
work creates services within a network by applying rules at the 
network edges to create traffic aggregates and coupling these with 
a specific forwarding path treatment for the aggregate. The WG 
has also discussed the behavior required at diffserv network edges 
or boundaries for conditioning packet aggregates, such elements 
as policers and shapers [MODEL, MIB]. A major feature of the 
diffserv architecture is that only the components applying the 
rules at the edge need to be changed in response to short-term 
changes in QoS goals in the network, rather than reconfiguring 
the interior behaviors.

The next step for the WG is to formulate examples of how the for-
 
Nichols and Carpenter       Expires: December, 2000        [page  1 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


warding path components (PHBs, classifiers, and traffic condi-
tioners) can be used within the architectural framework 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 behav-
ior, or PDB, to describe the behavior experienced by packets of a 
particular traffic aggregate as they cross a DS domain. PDBs can 
be used to characterize, by specific metrics, the treatment individ-
ual packets with a particular DSCP (or set of DSCPs) will receive 
as it crosses a DS domain. However, no microflow information 
should be required as packets transit a differentiated services net-
work. A PDB is an expression of a fowarding path treatment, but 
due to the role that particular choices of edge and PHB configura-
tion play in its resulting attributes, it is where the forwarding path
and the control plane interact.

This document defines and discusses Per Domain Behaviors in 
detail and lays out the format and required content for contribu-
tions to the Diffserv WG on PDBs and the rules 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.

A pdf version of this document is available at: ftp://www.packet-
design.com/outgoing/ietf/pdb_def.pdf.

Table of Contents

1. Introduction ........................................  2

2. Definitions .........................................  3

3. The Value of Defining Edge-to-Edge Behavior .........  4

4. Understanding Diffserv PDBs .........................  5

5. Format for Specification of Diffserv PDBs ...........  8

6. PDB Attributes .....................................  10

7. Reference Per-Domain Behaviors .....................  13

8. Procedure for Submitting PDBs to Diffserv WG .......  14

9. Acknowledgements ...................................  15


1.0  Introduction

Differentiated Services allows an approach to IP QoS that is mod-
ular, high performance, incrementally deployable, and scalable 
[RFC2475]. Although an ultimate goal is interdomain quality of 
service, there remain many untaken steps on the road to achieving 
 
Nichols and Carpenter       Expires: December, 2000        [page  2 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


this goal. 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 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. A diffserv Conceptual Model [MODEL] 
describes a model of traffic conditioning and other forwarding 
behaviors. 

Although business models will have to evolve over time, there 
also remain technical issues in moving "beyond the box" to QoS 
models that apply within a single network domain. Providing 
QoS on a per-domain basis is useful in itself and will provide use-
ful deployment experience for further IETF work as well as for 
the evolution of business models. The step of specifying forward-
ing path attributes on a per-domain basis for a traffic aggregate 
distinguished only by the mark in the DS field of individual pack-
ets is critical in the evolution of Diffserv QoS and should provide 
the technical input that will aid in the construction of business 
models. The ultimate goal of creating end to end QoS in the Inter-
net imposes the requirement that we can create and quantify a 
behavior for a group of packets that is preserved when they are 
aggregated with other packets. This document defines and speci-
fies the term "Per-Domain Behavior" or PDB to describe QoS 
attributes across a DS domain.

In diffserv, rules are imposed on packets arriving at the boundary 
of a DS domain through use of classification and traffic condi-
tioning which are set to reflect the policy and traffic goals for
that domain. 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. 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, a PHB should be defined such that its defining char-
acteristics don't depend on the volume of the associated BA on a 
router's ingress link nor on a particular path through the DS 
domain taken by the packets marked for it. If the properties of a 
PDB using a particular PHB hold regardless of how the marked 
aggregate mutates as it traverses the domain, then that PDB 
scales. If there 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 sim-
ple relationships with network size and whose properties can be 
 
Nichols and Carpenter       Expires: December, 2000        [page  3 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


recovered by reapplying rules (that is, forming another diffserv 
boundary or edge to re-enforce the rules for the 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 couples rules, specific PHBs, and 
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 are 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 cus-
tomer-visible in contracts and these may be stated quite differ-
ently from the technical attributes specified in a PDB definition. 
Similarly, specific PDBs are intended as tools for ISPs to con-
struct differentiated services offerings; each may choose different 
sets of tools, or even develop their own, in order to achieve
particular externally observable metrics. 

This document defines Differentiated Services Per-Domain 
Behaviors and specifies the format that must be used for submis-
sions of particular PDBs to the Diffserv WG. 

2.0  Definitions

The following definitions are stated in RFCs 2474 and 2475 and 
are repeated here for easy reference:

o Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction. The terms "aggregate" and
"behavior aggregate" are used interchangeably in this document.

o 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 administrative domains or autono-
mous systems, different trust regions, different network technologies 
(e.g., cell/frame), hosts and routers, etc. Also DS domain.

o 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 down-
stream/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
 
Nichols and Carpenter       Expires: December, 2000        [page  4 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


be co-located with a host, subject to local policy. Also DS boundary.

To these we add:

o 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 a the foo PHB is referred to 
as the "foo traffic aggregate" or the "foo aggregate" interchangeably.

o 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.

3.0  The Value of Defining Edge-to-Edge 
Behavior

Networks of DS domains can be connected to create end-to-end 
services, but where DS domains are independently administered, 
the evolution of the necessary business agreements and future sig-
naling arrangements will take some time. Early deployments will 
be within a single administrative domain. Specification of the 
transit expectations of packets matching a target for a particular 
diffserv behavior across a DS domain both assists in the deploy-
ment of single-domain QoS and will help enable the composition 
of end-to-end, cross domain services to proceed. Putting aside the 
business issues, the same technical issues that arise in intercon-
necting DS domains with homogeneous administration will arise 
in interconnecting the autonomous systems (ASs) of the Internet.

Today's Internet is composed of multiple independently adminis-
tered domains or Autonomous Systems (ASs), represented by the 
circles in figure 1. To deploy ubiquitous end-to-end quality of ser-
vice 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. 

Figure 1: Interconnection of ASs and DS Domains

A single AS (for example, AS2 in figure 1) may be composed of 
subnetworks and, as the definition allows, these can be separate 
DS domains. For a number of reasons, it might be useful to have 
multiple DS domains in an AS, most notable being to follow 
topological and/or technological boundaries and to separate the 
allocation of resources. If we confine ourselves to the DS bound-
aries 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. 
 
Nichols and Carpenter       Expires: December, 2000        [page  5 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000



The incentive structure for differentiated services is based on 
upstream domains ensuring their traffic conforms to agreed upon 
rules and downstream domains enforcing that conformance, thus 
metrics associated with PDBs can be sensibly computed. The 
rectangular boxes in figure 1 represent the DS boundary routers 
and thus would contain the traffic conditioners that ensure and 
enforce conformance (e.g., shapers and  policers). Although we 
expect that policers and shapers will be required at the DS bound-
aries of ASs (dark rectangles), they might appear anywhere, or 
nowhere, inside the AS. Thus, the boxes at the DS boundaries 
internal to the AS (shaded rectangles) may or may not condition 
traffic. Understanding a particular PDB's characteristics under 
aggregation and multiple hops will result in guidelines for the 
placement and configuration of DS boundaries. 

This approach continues the separation of forwarding path and 
control plane decribed in RFC 2474. The forwarding path charac-
teristics are addressed by considering what happens at every hop 
of a packet's path and what behaviors can be characterized under 
the merging and branching through multiple hops. The control 
plane only needs to be employed 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 qual-
ity-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.0  	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:

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. 

Measurable, quantifiable, attributes are associated with each PDB 
and these can be used to describe what will happen to packets of 
that PDB as they cross the DS domain. These derive from the 
 
Nichols and Carpenter       Expires: December, 2000        [page  6 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


rules that are enforced during the entry of packets into the DS 
domain and the forwarding treatment (PHB) the packets get 
inside the domain. PDB attributes may be absolute or statistical 
and they may be parameterized by network properties. For exam-
ple,  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 
deliverd 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.

Identification of the target group of packets is carried out using 
classification. The Per-Domain Behavior applied to that group of 
packet is characterized in two parts: 1) the relationship between 
this target group of packets to the marked traffic aggregate which 
results  from the application of rules (through the use of traffic 
conditioning) to the identified (classified) packets to create a traf-
fic aggregate marked for the associated  PHB (see figure 2) and 2) 
the attributes which result from the treatment experienced by 
packets from the same traffic aggregate transiting the interior of a 
DS domain, between and inside of DS boundaries. 

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

The first part is more straightforward than the second, but might 
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. This would be formulated as the 
rate of the emerging foo traffic aggregate being less than or equal 
to the smaller of R and the arrival rate of the target group of pack-
ets and additional temporal characteristics of the packets (e.g., 
burst) would be specified as desired.  Thus, there is a "loss rate" 
that results to the original target group from sending too much 
traffic or the traffic with the wrong temporal characteristics that 
should be entirely preventable (or controllable) by the upstream 
sender conforming to the traffic conditioning associated with the 
PDB specification. A PDB might also apply traffic conditioning 
at egress at a DS boundary.   This 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 pre-
sented in this document.) In section 4.3, we will revisit this dis-
cussion for PHB groups.

This aspect of "who is in control" of the loss (or demotion) rate 
helps to clearly delineate the first part of characterizing packet 
performance of a PDB from the second part. Further, the relation-
ship of the traffic aggregate to the arriving target packet group can 
usually be expressed more simply that the traffic aggregate's tran-
sit attributes and depends on different elements. The second part 
 
Nichols and Carpenter       Expires: December, 2000        [page  7 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


is illustrated in figure 3 as the quantifiable metrics that can be 
used to characterize the transit of any packet of a particular traffic
aggregate between any two edges of the DS domain boundary 
shown in figure 3, including those indicated with arrows. Note 
that the DS domain boundary runs through the DS boundary rout-
ers 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.)  

Figure 3: Range of applicability of attributes of a traffic aggregate 
associated with a PDB

The traffic aggregate associated with a PDB is formed by the 
application of rules, through classification and traffic condition-
ing, to packets arriving at the DS boundary. Packets that conform 
to the rules are marked with a DSCP that maps to a particular 
PHB within a domain. DSCPs should not mutate in the interior of 
a DS domain as there are no rules being applied. If it is necessary 
to reapply the kind of rules that could result in remarking, there 
should probably be a DS domain boundary at that point; an inte-
rior one that can have "lighter weight" rules. Thus, if measuring 
attributes between locations as indicated in figure 3, the DSCP at 
the egress side can be assumed to have held throughout the 
domain.

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 rules 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, though, a PDB operates between N ingress points and 
M egress points at the DS domain boundary. Even in the degener-
ate 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 under-
stand 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 perfor-
mance goals for a particular flow of a traffic aggregate. Once the 
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 
 
Nichols and Carpenter       Expires: December, 2000        [page  8 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


the PDB's traffic aggretae subject to that configuration of link 
schedulers and bandwidth. The rules at the edge may be altered 
by provisioning or admission control but the decision about 
which PDB to use and how to apply the rules comes from match-
ing performance to goals.

For example, consider the diffserv domain of figure 3. A PDB 
with an attribute of an explicit bound on loss must have rules at 
the edge to ensure that on the average no more packets are admit-
ted 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 net-
work. 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 pack-
ets 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 aggre-
gate can expect at each hop. For a PDB, this behavior must apply 
to merging and diverging traffic aggregates, thus characterizing a 
PDB requires exploring what happens to a PHB under aggrega-
tion. Rules must be recursively applied to result in a known 
behavior. As an example, since maximum burst sizes grow with 
the number of microflows or aggregate flows 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 traffi aggregate has known attributes that span inte-
rior 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. Using the same (or fewer) rules 
as were applied to create the traffic aggregates at the entrance to 
AS2, there should be confidence that the attributes of the foo 
PDB can continue to be used to quantify by the expected behav-
ior.   Explicit expressions of what happens to the behavior under 
aggregation, possibly parameterized by node in-degrees or net-
work diameters are necessary to determine what to do at the inter-
nal aggregation points. One approach might be to completely 
reapply the edge rules at these points. Another might employ 
some limited rate-based remarking only.

Multiple PDBs might use the same PHB. In the specification of a 
PDB, there might be a list of PHBs and their required configura-
tion, all of which would result in the same characteristics. In 
operation, though, it is expected that a single domain will use a 
single PHB to implement a particular PDB. A single PHB might 
beselected 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. 
 
Nichols and Carpenter       Expires: December, 2000        [page  9 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


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 behavior aggre-
gates 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. 

4.3  PDBs using PHB Groups

When a set of related PDBs are defined using a PHB group, they 
should be defined in the same document. This would be particu-
larly appropriate if the application of the edge rules that create the
traffic aggregates associated with each PDB had some relation-
ships and interdependencies, as one would expect for the AF PHB 
group [RFC2597]. Characterizing the traffic conditioning effects 
should then be described for these PDBs 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, thus each should 
have a clearly separate treatment, though there may be some 
parameterized interrelationship between the attributes of each of 
these PDBs.

For example, if the traffic conditioner described in RFC 2698 is 
used to mark arriving packets for three different AF1x PHBs, then 
the most reasonable approach is to define and quantify the rela-
tionship between the arriving packets and the emerging traffic 
aggregates as they relate to one another. The transit characteris-
tics of packets of each separate AF1x traffic aggregate should be 
described separately.

A set of PDBs might be defined using Class Selector Compliant 
PHBs [RFC2474] in such a way that the edge rules that create the 
traffic aggregates are not related, but the transit performance of 
each traffic aggregate has some parametric relationship to the 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 and edge traffic conditioners are in the 
packet forwarding path and operate at line rates while the config-
uration of the DS domain edge to enforce rules on who gets to use 
the PDB and how the PDB should behave temporally is done by 
the control plane on a very different time scale. For example, con-
figuration of PHBs might only occur monthly or quarterly. The 
edge rules might be reconfigured at a few regular intervals during 
the day or might happen in response to signalling decisions thou-
sands of times a day. Even at the shortest time scale, control plane 
actions are not expected to happen per-packet. Much of the con-
trol plane work is still evolving and is outside the charter of the 
Diffserv WG. We note that this is quite appropriate since the 
 
Nichols and Carpenter       Expires: December, 2000        [page  10 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


manner in which the configuration is done and the time scale at 
which it is done should not affect the PDB attributes.

5.0  Format for Specification of Diffserv Per-Domain Behaviors

PDBs arise from a particular relationship between edge and inte-
rior (which may be parameterized). The quantifiable characteris-
tics of a PDB must be independent of whether the network edge is 
configured statically or dynamically. The particular configuration 
of traffic 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 con-
tent 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  Rules

This section describes the rules to be followed in the creation of 
this PDB. Rules should be distinguished with "may", "must" and 
"should." The rules specify the edge behavior and configuration 
and the PHB (or PHBs) to be used and any additional require-
ments on their configuration beyond that contained in RFCs.

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 absolute 
bounds or statistical bounds (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 characteris-
tics 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 proba-
bility. 

5.4  Parameters

 
Nichols and Carpenter       Expires: December, 2000        [page  11 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


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. 
However, these assumptions must be clearly stated. Some PDBs 
may be developed without these assumptions, e.g., for high loss 
rate links, and these must also be made explicit. If additional 
restrictions, e.g., route pinning, 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 behavior aggregate 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 due to 
violation of that PDB's rules."

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 exam-
ple, 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.

6.0  PDB Attributes

Attributes are associated with each PDB: measurable, quantifi-
able, characteristics which can be used to describe what will hap-
pen to packets using that PDB as they cross the domain. These 
expectations result directly from the application of edge rules 
enforced during the creation of the PDB's traffic aggregate and/or 
its entry into the domain and the forwarding treatment (PHB) 
packets of that traffic aggregate get inside the domain. There are 
 
Nichols and Carpenter       Expires: December, 2000        [page  12 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


many ways in which traffic might be distributed, but creating a 
quantifiable, realizable service across the DS domain will limit 
the scenarios which can occur. There is a clear correlation 
between the strictness of the rules and the quality of the charac-
terization of the PDB.

There are two ways to characterize PDBs with respect to time.
First are its properties over "long" time periods, or average 
behaviors. In a PDB spec, these would be the rates or throughput 
seen over some specified time period. In addition, there are prop-
erties of "short" time behavior, usually expressed as the allowable 
burstiness in an aggregate. The short time behavior is important is 
understanding the buffering (and associated loss characteristics) 
and in quantifying how packets using the PDB aggregate, either 
within a DS domain or at the boundaries. For short-time behavior, 
we are 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.

Put simply, 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 rules and expectations?

6.1  Considerations in specifying long-term or average PDB attributes 

To make this more concrete, consider the DS domain of figure 4 
for which we will define the foo PDB. To characterize the average 
or long-term behavior that must be specified 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? 

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

Let figure 4 be an ISP ringing the U.S. with links of bandwidth B 
and with N tails to various metropolitan areas. 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 hav-
ing 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 that case, there were topological assumptions 
made about the path of the traffic from A to Z that affected the 
characteristics of the foo PDB. Once these no longer hold, any 
 
Nichols and Carpenter       Expires: December, 2000        [page  13 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


assumptions on the loss rate of packets of the foo traffic aggregate 
transiting the domain would change; for example, a characteristic 
such as "loss rate no greater than 1% over any interval larger than 
10 minutes" would no longer hold. A PDB specification should 
spell out the assumptions made on preserving the attributes.

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 maxi-
mum bursts to add in the same manner as the average rates will 
lead to properties that aggregate or under what rules 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 aggre-
gate, 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 band-
width 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 trans-
mitted. 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 
rules, 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 rules for entering E 
(e.g., by shaping).

What conditions should be imposed on a PDB and on the associ-
ated PHB in order to ensure PDBs can be concatenated, as across 
the interior DS domains of figure 1? Edge rules for constructing a 
PDB that has certain attributes across a DS domain should apply 
 
Nichols and Carpenter       Expires: December, 2000        [page  14 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


independently of the origin of the packets. With reference to the 
example we've been exploring, the rules 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  Example

In this example, we will make the above more concrete. We 
assume that only the foo PDB is using its associated traffic aggre-
gate and we use "foo agggregate" interchangeably with "the traf-
fic aggregate associated with the PDB foo." We also use "foo 
packets" interchangeably with "the packets marked for the PHB 
associated with PDB foo."

Assume the topology of figure 4 and that all the uplinks have the 
same bandwidth B and link L has bandwidth L which is less than 
or equal to B. The foo traffic aggregates from the N uplinks each 
have average rate R and are destined to cross L. If only a fraction 
a of link L is allocated to foo, then R =axL/N fits the average rate 
constraint. If each of the N flows can have a burst of p packets 
and half the flows transit the ring in each direction, then 2xp 
packets can arrive at the foo queue for link L in the time it took to 
transmit p packets on the ring, p/B. Although the link scheduler 
for link L might allow the burst of packets to be transmitted at the 
line rate L, after the burst allotment has been exceeded, the queue 
should be expected to clear at only rate axL. Then consider the 
packets that can accumulate. It takes 2xp/(axL) to clear the queue 
of the foo packets. In that time, bursts of p packets from the other 
uplinks can arrive from the ring, so the packets do not even have 
to be back-to-back.  Even if the packets do not arrive back-to-
back, but are spaced by less time than it takes to clear the queue 
of foo packets, either the required buffer size can become large or 
the burst size of foo packets entering E across L becomes large 
and is a function of N, the number of uplinks of domain D. 

Let L = 1.5 Mbps, B = 45 Mbps, a = 1/3, N=10, p = 3. Suppose 
that the bursts from two streams of foo packets arrive at the queue 
for link L very close together. Even if 3 of the packets are cleared 
at the line rate of 1.5 Mbps, there will be 3 packets remaining to 
be serviced at a 500 kbps rate. In the time allocated to send one of 
these, 9 packets can arrive on each of the inputs from the ring. If 
any non-zero number of these 18 packets are foo packets, the 
queue size will not reduce. If two more bursts (6 of the 18 pack-
ets) arrive, the queue increases to 8 packets. Thus, it's possible to 
build up quite a large queue, one likely to exceed the buffer allo-
cated for foo. The rate bound means that each of the uplinks will 
be idle for the time to send three packets at 50 kbps, possibly by 
policing at the ring egress, and thus the queue would eventually 
decrease and clear, however, the queue at link L can still be very 
large. PDBs where the intention is to permit loss should be con-
structed so as to provide a probabilistic bound for the queue size 
to exceed a reasonable buffer size of one or two bandwidth-delay 
products. Alternatively or additionally, rules can be used that 
 
Nichols and Carpenter       Expires: December, 2000        [page  15 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


bound the amount of foo packets that queue by limiting the burst 
size at the ingress uplinks to one packet, resulting in a maximum 
queue of N or 10 or to impose additional rules on the PDB. One 
approach is to limit the domain over which the PDB applies so 
that interior boundaries are placed at merge points (or between 
every M merge points)  so that a shaping edge conditioner can be 
reapplied.  Another approach is to use a PHB defined such that it 
strictly limits the burstiness.

6.4  Remarks

This section has been provided to provide some 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 ser-
vices 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. 

7.0  Reference Per-Domain Behaviors

The intent of this section is to define one or a few "reference" 
PDBss; certainly a Best Effort PDB and perhaps others. This sec-
tion is very preliminary at this time and meant to be the starting 
point for discussion rather than its end. These are PDBs that have 
little in the way of rules or expectations.

7.1  Best Effort Behavior 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 deliv-
ery expectation for packets in a diffserv network that do not 
require any special differentiation.

7.1.2  Rules

There are no rules 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]). Interior network nodes use 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 
 
Nichols and Carpenter       Expires: December, 2000        [page  16 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


other traffic aggregate), network elements should be configured 
to permit packets of this PDB to consume them.

Although some network operators may bound the delay and loss 
rate for this aggregate given knowledge about their network, these 
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.2  Bulk Handling Behavior PDB

7.2.1  Applicability

A Bulk Handling (BH) PDB is for sending extremely non-critical 
traffic across a diffserv network. There should be an expectation 
that these packets may be delayed or dropped when other traffic is 
present.

7.2.2  Rules

There are no rules governing rate and bursts of packets beyond 
the limits imposed by the ingress link. The network edge ensures 
that packets using this PDB are marked for either a CS or an AF 
PHB. Interior network nodes must have this PHB configured so 
that its packets may be starved when other traffic is present. For 
example, using the PHB for Class Selector 1 (DSCP=001000), all 
routers in the domain could be configured to queue such traffic 
behind all other traffic, subject to tail drop.

7.2.3  Attributes of the BH PHB 

Packets are forwarded when there are idle resources.

7.2.4  Parameters

None.

7.2.5  Assumptions 
 
Nichols and Carpenter       Expires: December, 2000        [page  17 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000



A properly functioning network.

7.2.6  Example uses

1. For Netnews and other "bulk mail" of the Internet.

2. For "downgraded" traffic from some other PDB.

8.0  Procedure for submitting PDB 
specifications to Diffserv WG

1. Following the guidelines of this document, write a draft and 
submit it as an Internet Draft and bring it to the attention of the 
WG mailing list.

2. Initial discussion on the WG should focus primarily on the 
merits of the a PDB, though comments and questions on the 
claimed attributes are reasonable. This is in line with our desire to 
put relevance before academic interest in spending WG time on 
PDBs. Academically interesting PDBs are encouraged, but not 
for submission to the diffserv WG.

3. 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. 

4. If/when endorsed by the panel, that draft goes to WG last call. 
If not endorsed, the author(s) can give a itemized response to the 
panel's report and ask for a WG Last Call.

5. If/when passes Last Call, goes to ADs for publication as a WG 
Informational RFC in our "PDB series".

9.0  Acknowledgements

The ideas in this document have been heavily influenced by the 
Diffserv WG and, in particular, by discussions with Van Jacob-
son, 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 sug-
 
Nichols and Carpenter       Expires: December, 2000        [page  18 ]

INTERNET DRAFT       draft-ietf-diffserv-pdb-def-00.txt   June, 2000


gested similar terms prior to that.

References

[RFC2474] RFC 2474, "Definition of the Differentiated Services 
Field (DS Field) in the IPv4 and IPv6 Headers", 
K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/
rfc/rfc2474.txt

[RFC2475] RFC 2475, "An Architecture for Differentiated Ser-
vices",  S. Blake, D. Black, M.Carl-
son,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/
rfc2475.txt

[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. 
Baker, J. Heinanen, W. Weiss, J. Wroclawski, 
www.ietf.org/rfc/rfc2597.txt

[RFC2598] RFC 2598, "An Expedited Forwarding PHB", 
V.Jacobson, K.Nichols, K.Poduri, www.ietf.org/rfc/
rfc2598.txt

[RFC2698] RFC 2698, "A Two Rate Three Color Marker", J. 
Heinanen, R. Guerin. www.ietf.org/rfc/rfc2698.txt

[MODEL]	"A Conceptual Model for Diffserv Routers", draft-ietf-
diffserv-model-02.txt, Bernet et. al.

[MIB] "Management Information Base for the Differentiated 
Services Architecture", draft-ietf-diffserv-mib-01.txt, 
Baker et. al.

[VW] "The 'Virtual Wire' Behavior Aggregate", draft-ietf-diff-
serv-ba-vw-00.txt, V. Jacobson, K. Nichols, and K. 
Poduri (being modified to reflect new terminology).

Authors' Addresses

Kathleen Nichols		Brian E. Carpenter
Packet Design, Inc.		IBM
66 Willow Place			c/o iCAIR
Menlo Park, CA 94025		Suite 150
				1890 Maple Avenue
				Evanston, IL 60201
				USA
email: 
nichols@packetdesign.com	brian@icair.org