RFC relevance of condition

As per Relevance of the word condition, we have this rfc below:

Network Working Group K.
Request for Comments: 3086 Packet
Category: Informational B.

April 2001

Definition of Differentiated Services Per Domain
and Rules for their

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

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

The differentiated services framework enables quality-of-
provisioning within a network domain by applying rules at the
to create traffic aggregates and coupling each of these with
specific forwarding path treatment in the domain through use of
codepoint in the IP header. The diffserv WG has defined the
architecture for differentiated services and has focused on
forwarding path behavior required in routers, known as "per-
forwarding behaviors" (or PHBs). The WG has also
functionality required at diffserv (DS) domain edges to
(classifiers) and condition (e.g., policing and shaping)
according to the rules. Short-term changes in the QoS goals for a
domain are implemented by changing only the configuration of
edge behaviors without necessarily reconfiguring the behavior
interior network nodes

The next step is to formulate examples of how forwarding
components (PHBs, classifiers, and traffic conditioners) can be
to compose traffic aggregates whose packets experience
forwarding characteristics as they transit a differentiated
domain. The WG has decided to use the term per-domain behavior,
PDB, to describe the behavior experienced by a particular set
packets as they cross a DS domain. A PDB is characterized
specific metrics that quantify the treatment a set of packets with
particular DSCP (or set of DSCPs) will receive as it crosses a
domain. A PDB specifies a forwarding path treatment for a
aggregate and, due to the role that particular choices of edge

Nichols & Carpenter Informational [Page 1]

RFC 3086 Diffserv per Domain Behaviors April 2001

PHB configuration play in its resulting attributes, it is where
forwarding path and the control plane interact. The
parameters of a PDB should be suitable for use in Service
Specifications at the network edge

This document defines and discusses Per-Domain Behaviors in
and lays out the format and required content for contributions to
Diffserv WG on PDBs and the procedure that will be applied
individual PDB specifications to advance as WG products. This
is specified to expedite working group review of PDB submissions

Table of

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

Differentiated Services allows an approach to IP Quality of
that is modular, incrementally deployable, and scalable
introducing minimal per-node complexity [RFC2475]. From the
user's point of view, QoS should be supported end-to-end between
pair of hosts. However, this goal is not immediately attainable.
will require interdomain QoS support, and many untaken steps
on the road to achieving this. One essential step, the evolution
the business models for interdomain QoS, will necessarily
outside of the IETF. A goal of the diffserv WG is to provide
firm technical foundation that allows these business models
develop. The first major step will be to support edge-to-edge
intradomain QoS between the ingress and egress of a single network
i.e., a DS Domain in the terminology of RFC 2474. The intention
that this edge-to-edge QoS should be composable, in a
technical sense, to a quantifiable QoS across a DS Region composed
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
behaviors required in the forwarding path of all network nodes,
per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474,
2597 and 2598 give a rich toolbox for differential packet handling
individual boxes. The general architectural model for diffserv
been documented in RFC 2475. An informal router model [MODEL
describes a model of traffic conditioning and other
behaviors. However, technical issues remain in moving "beyond
box" to intradomain QoS models

The ultimate goal of creating scalable end-to-end QoS in the
requires that we can identify and quantify behavior for a group
packets that is preserved when they are aggregated with other
as they traverse the Internet. The step of specifying
path attributes on a per-domain basis for a set of
distinguished only by the mark in the DS field of individual
is critical in the evolution of Diffserv QoS and should provide
technical input that will aid in the construction of business models
This document defines and specifies the term "Per-Domain Behavior"
PDB to describe QoS attributes across a DS domain

Diffserv classification and traffic conditioning are applied
packets arriving at the boundary of a DS domain to
restrictions on the composition of the resultant traffic aggregates
as distinguished by the DSCP marking , inside the domain.
classifiers and traffic conditioners are set to reflect the
and traffic goals for that domain and may be specified in a
(Traffic Conditioning Agreement). Once packets have crossed the
boundary, adherence to diffserv principles makes it possible to
packets solely according to the behavior they receive at each hop (
selected by the DSCP). This approach has well-known
advantages, both in the forwarding path and in the control plane
Less well recognized is that these scaling properties only result
the per-hop behavior definition gives rise to a particular type
invariance under aggregation. Since the per-hop behavior must
equivalent for every node in the domain, while the set of
marked for that PHB may be different at every node, PHBs should
defined such that their characteristics do not depend on the
volume of the associated BA on a router's ingress link nor on
particular path through the DS domain taken by the packets
Specifically, different streams of traffic that belong to the
traffic aggregate merge and split as they traverse the network.
the properties of a PDB using a particular PHB hold regardless of
the temporal characteristics of the marked traffic aggregate
as it traverses the domain, then that PDB scales. (Clearly
assumes that numerical parameters such as bandwidth allocated to
particular PDB may be different at different points in the network
and may be adjusted dynamically as traffic volume varies.) If

Nichols & Carpenter Informational [Page 3]

RFC 3086 Diffserv per Domain Behaviors April 2001

are limits to where the properties hold, that translates to a
on the size or topology of a DS domain that can use that PDB
Although useful single-link DS domains might exist, PDBs that
invariant with network size or that have simple relationships
network size and whose properties can be recovered by
rules (that is, forming another diffserv boundary or edge to re
enforce the rules for the traffic aggregate) are needed for
scalable end-to-end quality of service

There is a clear distinction between the definition of a Per-
Behavior in a DS domain and a service that might be specified in
Service Level Agreement. The PDB definition is a technical
block that permits the coupling of classifiers, traffic conditioners
specific PHBs, and particular configurations with a resulting set
specific observable attributes which may be characterized in
variety of ways. These definitions are intended to be useful
in configuring DS domains, but the PDB (or PDBs) used by a
is not expected to be visible to customers any more than the
PHBs employed in the provider's network would be. Network
are expected to select their own measures to make customer-visible
contracts and these may be stated quite differently from
technical attributes specified in a PDB definition, though
configuration of a PDB might be taken from a Service
Specification (SLS). Similarly, specific PDBs are intended as
for ISPs to construct differentiated services offerings; each
choose different sets of tools, or even develop their own, in
to achieve particular externally observable metrics. Nevertheless
the measurable parameters of a PDB are expected to be among
parameters cited directly or indirectly in the Service
Specification component of a corresponding SLA

This document defines Differentiated Services Per-Domain
and specifies the format that must be used for submissions
particular PDBs to the Diffserv WG

2

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

" Behavior Aggregate: a collection of packets with the same
crossing a link in a particular direction

" Differentiated Services Domain: a contiguous portion of
Internet over which a consistent set of differentiated
policies are administered in a coordinated fashion.
differentiated services domain can represent

Nichols & Carpenter Informational [Page 4]

RFC 3086 Diffserv per Domain Behaviors April 2001

administrative domains or autonomous systems, different
regions, different network technologies (e.g., cell/frame),
and routers, etc. Also DS domain

" Differentiated Services Boundary: the edge of a DS domain,
classifiers and traffic conditioners are likely to be deployed.
differentiated services boundary can be further sub-divided
ingress and egress nodes, where the ingress/egress nodes are
downstream/upstream nodes of a boundary link in a given
direction. A differentiated services boundary typically is
at the ingress to the first-hop differentiated services-
router (or network node) that a host's packets traverse, or at
egress of the last-hop differentiated services-compliant router
network node that packets traverse before arriving at a host.
is sometimes referred to as the boundary at a leaf router.
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
maps to the same PHB, usually in a DS domain or some subset of a
domain. A traffic aggregate marked for the foo PHB is referred
as the "foo traffic aggregate" or "foo aggregate" interchangeably
This generalizes the concept of Behavior Aggregate from a link to
network

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

" A Service Level Specification (SLS) is a set of parameters
their values which together define the service offered to a
stream by a DS domain. It is expected to include specific
or bounds for PDB parameters

3 The Value of Defining Edge-to-Edge

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

Nichols & Carpenter Informational [Page 5]

RFC 3086 Diffserv per Domain Behaviors April 2001

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

Today's Internet is composed of multiple independently
domains or Autonomous Systems (ASs), represented by the "clouds"
figure 1. To deploy ubiquitous end-to-end quality of service in
Internet, business models must evolve that include issues of
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
the IETF can address the technical issues in creating an
QoS within a Differentiated Services framework. In fact,
approach is quite amenable to incremental deployment strategies

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

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

Figure 1: Interconnection of ASs and DS

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

Nichols & Carpenter Informational [Page 6]

RFC 3086 Diffserv per Domain Behaviors April 2001

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

The incentive structure for differentiated services is based
upstream domains ensuring their traffic conforms to the
Conditioning Agreements (TCAs) with downstream domains and
domains enforcing that TCA, thus metrics associated with PDBs can
sensibly computed. The letters "X" and "Y" in figure 1 represent
DS boundary routers containing traffic conditioners that ensure
enforce conformance (e.g., shapers and policers). Although
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)
or may not condition traffic. Technical guidelines for the
and configuration of DS boundaries should derive from the
of a particular PDB under aggregation and multiple hops

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

4 Understanding

4.1 Defining

RFCs 2474 and 2475 define a Differentiated Services
Aggregate as "a collection of packets with the same DS
crossing a link in a particular direction" and further state
packets with the same DSCP get the same per-hop forwarding
(or PHB) everywhere inside a single DS domain. Note that even
multiple DSCPs map to the same PHB, this must hold for each
individually. In section 2 of this document, we introduced a
general definition of a traffic aggregate in the diffserv sense
that we might easily refer to the packets which are mapped to
same PHB everywhere within a DS domain. Section 2 also presented
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
target group of packets will receive from "edge to edge" of a
domain. A particular PHB (or, if applicable, list of PHBs)
traffic conditioning requirements are associated with each PDB

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

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

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

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

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
target

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

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

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

4.1.2 Crossing the DS domain: transit

The second component of PDB performance is the metrics
characterize the transit of a packet of the PDB's traffic
between any two edges of the DS domain boundary shown in figure 3.
Note that the DS domain boundary runs through the DS boundary
since the traffic aggregate is generally formed in the
router before the packets are queued and scheduled for output. (
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
traffic conditioning being applied. If it is necessary to
the kind of traffic conditioning that could result in remarking
there should be a DS domain boundary at that point, though such
"interior" boundary can have "lighter weight" rules in its TCA
Thus, when measuring attributes between locations as indicated
figure 3, the DSCP at the egress side can be assumed to have
throughout the domain

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

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

Though a DS domain may be as small as a single node, more
topologies are expected to be the norm, thus the PDB definition
hold as its traffic aggregate is split and merged on the
links of a DS domain. Packet flow in a network is not part of
PDB definition; the application of traffic conditioning as
enter the DS domain and the consistent PHB through the DS domain
suffice. A PDB's definition does not have to hold for
topologies of networks, but the limits on the range of
for a specific PDB must be clearly specified

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

4.2 Constructing

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

Nichols & Carpenter Informational [Page 10]

RFC 3086 Diffserv per Domain Behaviors April 2001

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

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

PHBs give explicit expressions of the treatment a traffic
can expect at each hop. For a PDB, this behavior must apply
merging and diverging traffic aggregates, thus characterizing a
requires understanding what happens to a PHB under aggregation.
is, PHBs recursively applied must result in a known behavior. As
example, since maximum burst sizes grow with the number of
or traffic aggregate streams merged, a PDB specification must
this. A clear advantage of constructing behaviors that aggregate
the ease of concatenating PDBs so that the associated
aggregate has known attributes that span interior DS domains and
eventually, farther. For example, in figure 1 assume that we
configured the foo PDB on the interior DS domains of AS2.
traffic aggregates associated with the foo PDB in each interior
domain of AS2 can be merged at the shaded interior boundary routers
If the same (or fewer) traffic conditioners as applied at
entrance to AS2 are applied at these interior boundaries,
attributes of the foo PDB should continue to be used to quantify
expected behavior. Explicit expressions of what happens to
behavior under aggregation, possibly parameterized by node in-
or network diameters, are necessary to determine what to do at
internal aggregation points. One approach might be to
reapply the traffic conditioning at these points; another
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
contain a list of PHBs and their required configuration, all of
would result in the same PDB. In operation, it is expected that
single domain will use a single PHB to implement a particular PDB
though different domains may select different PHBs. Recall that
the diffserv definition [RFC2474], a single PHB might be
within a domain by a list of DSCPs. Multiple PDBs might use the
PHB in which case the transit performance of traffic aggregates
these PDBs will, of necessity, be the same. Yet, the
characteristics that the PDB designer wishes to claim as
may vary, so two PDBs that use the same PHB might not be
with the same list of attributes

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

4.3 PDBs using PHB

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
single PDB. For example, a PDB could be defined using just one
the Class Selector Compliant PHBs [RFC2474]. The
conditioning for that PDB and the required configuration of
particular PHB would be defined in such a way that there was
dependence or relationship with the manner in which other PHBs of
group are used or, indeed, whether they are used in that DS domain
In this case, the reasonable approach would be to specify this
alone in a document which expressly called out the conditions
configuration of the Class Selector PHB required

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

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

Nichols & Carpenter Informational [Page 12]

RFC 3086 Diffserv per Domain Behaviors April 2001

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

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

4.4 Forwarding path vs. control

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

5 Format for Specification of Diffserv Per-Domain

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

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
which can be separated from the specification of the PDB

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

5.1 Applicability

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

5.2 Technical

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

5.3

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

Advice to a network operator would be to use these as guidelines
creating a service specification rather than use them directly.
example, a "loss-free" PDB would probably not be sold as such,
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

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

5.5

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

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

5.6 Example

A PDB specification must give example uses to motivate
understanding of ways in which a diffserv network could make use
the PDB although these are not expected to be detailed. For example
"A bulk handling PDB may be used for all packets which should
take any resources from the network unless they would otherwise
unused. This might be useful for Netnews traffic or for
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 (
a commonly defined one) is being used nor is it necessary for
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
above. Detail the assumptions made there and what constraints
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

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

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

6 On PDB

As discussed in section 4, measurable, quantifiable
associated with each PDB can be used to describe what will happen
packets using that PDB as they cross the domain. In its role as
building block for the construction of interdomain quality-of
service, a PDB specification should provide the answer to
question: Under what conditions can we join the output of this
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
multi-domain services limits the realistic scenarios. A PDB'
attributes with a clear statement of the conditions under which
attributes hold is critical to the composition of multi-
services

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

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

Nichols & Carpenter Informational [Page 16]

RFC 3086 Diffserv per Domain Behaviors April 2001

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

6.1 Considerations in specifying long-term or average PDB

To characterize the average or long-term behavior for the foo PDB
must explore a number of questions, for instance: Can the DS
handle the average foo traffic flow? Is that answer
dependent or are there some specific assumptions on routing
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
dramatically increase

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

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

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

Nichols & Carpenter Informational [Page 17]

RFC 3086 Diffserv per Domain Behaviors April 2001

6.2 Considerations in specifying short-term or bursty PDB

Next, consider the short-time behavior of the traffic
associated with a PDB, specifically whether permitting the
bursts to add in the same manner as the average rates will lead
properties that aggregate or under what conditions this will lead
properties that aggregate. In our example, if domain D allows
of the uplinks to burst p packets into the foo traffic aggregate,
bursts could accumulate as they transit the ring. Packets headed
link L can come from both directions of the ring and back-to-
packets from foo's traffic aggregate can arrive at the same time.
the bandwidth of link L is the same as the links of the ring,
probably does not present a buffering problem. If there are
input links that can send packets to queue for L, at worst,
packets can arrive simultaneously for L. If the bandwidth of link
equals or exceeds twice B, the packets won't accumulate. Further,
p is limited to one, and the bandwidth of L exceeds the rate
arrival (over the longer term) of foo packets (required for
the loss) then the queue of foo packets for link L will empty
new packets arrive. If the bandwidth of L is equal to B, one
packet must queue while the other is transmitted. This would
in N x p back-to- back packets of this traffic aggregate
over L during the same time scale as the bursts of p were
on the uplinks. Thus, configuring the PDB so that link L can
the sum of the rates that ingress to the foo PDB doesn't
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
Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting
than the full bandwidth L, this number is larger. For
bounds, a smaller buffer might do if the probability of exceeding
can be bounded

More generally, for router indegree of d, bursts of foo packets
arrive on each input. Then, in the absence of any additional
conditioning, it is possible that dxpx(# of uplinks) back-to-back
packets can be sent across link L to domain E. Thus the DS domain
must permit these much larger bursts into the foo PDB than domain
permits on the N uplinks or else the foo traffic aggregate must
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
in order to ensure PDBs can be concatenated, as across the
DS domains of figure 1? Traffic conditioning for constructing a
that has certain attributes across a DS domain should
independently of the origin of the packets. With reference to

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
entering link L into domain E should not depend on the number
uplinks into domain D

6.3

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

7 A Reference Per-Domain

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

7.1 Best Effort

7.1.1

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

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

Nichols & Carpenter Informational [Page 19]

RFC 3086 Diffserv per Domain Behaviors April 2001

7.1.2 TCS and PHB

There are no restrictions governing rate and bursts of packets
the limits imposed by the ingress link. The network edge
that packets using the PDB are marked for the Default PHB (as
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

"As much as possible as soon as possible".

Packets of this PDB will not be completely starved and when
are available (i.e., not required by packets from any other
aggregate), network elements should be configured to permit
of this PDB to consume them

Network operators may bound the delay and loss rate for
constructed from this PDB given knowledge about their network,
such attributes are not part of the definition

7.1.4

None

7.1.5

A properly functioning network, i.e., packets may be delivered
any ingress to any egress

7.1.6 Example

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

7.1.7 Environmental

There are no environmental concerns specific to this PDB

7.1.8 Security Considerations for BE

There are no specific security exposures for this PDB. See
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

G1. Following the format given in this document, write a draft
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
a separate document, provide details of deployment experience
measured results on a network of non-trivial size carrying
traffic and/or convincing simulation results (simulation of a
of modern traffic patterns and network topologies as applicable).
The document should be brought to the attention of the diffserv
mailing list, if active

G2. Initial discussion should focus primarily on the merits of
PDB, though comments and questions on the claimed attributes
reasonable. This is in line with the Differentiated Services goal
put relevance before academic interest in the specification of PDBs
Academically interesting PDBs are encouraged, but would be
appropriate for technical publications and conferences, not
submission to the IETF. (An "academically interesting" PDB
become a PDB of interest for deployment over time.)

The implementation of the following guidelines varies, depending
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
is a useful PDB and that the characteristics "appear" to be
(i.e., not egregiously wrong) that version of the draft goes to
review panel the WG co-chairs set up to audit and report on
characteristics. The review panel will be given a deadline for
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
other constraints (IETF meetings, major holidays) but is expected
be in the 4-8 week range. During that time, the panel may
with the authors directly (cc'ing the WG co-chairs) to
clarifications. This process should result in a revised draft and/
a report to the WG from the panel that either endorses or
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
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
Informational RFC in our "PDB series".

If no active Diffserv Working Group exists

G3. Following discussion on relevant mailing lists, the
should revise the Internet Draft and contact the IESG for "
Review" as defined in section 2 of RFC 2434 [RFC2434].

G4. Subsequent to the review, the IESG may recommend publication
the Draft as an RFC, request revisions, or decline to publish as
Informational RFC in the "PDB series".

9 Security

The general security considerations of [RFC2474] and [RFC2475]
to all PDBs. Individual PDB definitions may require
security considerations

10

The ideas in this document have been heavily influenced by
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
be acknowledged for their useful input but not be held
for our mangling of it. Grenville Armitage coined "per
behavior (PDB)" though some have suggested similar terms prior
that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John
reviewed the document and commented so as to improve its form

[RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, "
of the Differentiated Services Field (DS Field) in the IPv
and IPv6 Headers", RFC 2474, December 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
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
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
Marker", RFC 2698, June 1999.

[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "
Informal Management Model for Diffserv Routers", Work
Progress

[MIB] Baker, F., Chan, K. and A. Smith, "Management
Base for the Differentiated Services Architecture", Work
Progress

[VW] Jacobson, V., Nichols, K. and K. Poduri, "The '
Wire' Per-Domain Behavior", Work in Progress

[WCG] Worldcom, "Internet Service Level Guarantee",
http://www.worldcom.com/terms/service_level_guarantee
t_sla_terms.

[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
Considerations", BCP 26, RFC 2434, October 1998.

Authors'

Kathleen
Packet Design,
2465 Latham Street, Third
Mountain View, CA 94040

EMail: nichols@packetdesign.

Brian

c/o
Suite 150
1890 Maple
Evanston, IL 60201

EMail: brian@icair.

Nichols & Carpenter Informational [Page 23]

RFC 3086 Diffserv per Domain Behaviors April 2001

Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Nichols & Carpenter Informational [Page 24]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX