Internet Draft

Internet Engineering Task Force K. Nichols
Differentiated Services Working Group Cisco Systems
Internet Draft Brian Carpenter
Expires in August, 2000 IBM
draft-ietf-diffserv-ba-def-01.txt February, 2000

Definition of Differentiated Services Behavior Aggregates and
Rules for their Specification

<draft-ietf-diffserv-ba-def-01.txt>

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

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 "per-hop forwarding behaviors" (or
PHBs) required in routers (RFCs 2474, 2597, and 2598). The dif-
ferentiated services framework creates services within a network
by applying rules at the edges in the creation of traffic aggregates
(known as Behavior Aggregates) coupled with the forwarding
path behavior. The WG has also discussed the behavior required
at diffserv network edges or boundaries for conditioning the
aggregates, elements such as policers and shapers [MODEL,
MIB]. A major feature of diffserv 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.

Nichols and Carpenter Expires: August, 2000 [page 1 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

The next step for the WG is to lay out how the forwarding path
components (PHBs, classifiers, and traffic conditioners) can be
used within the architectural framework to compose specific
Behavior Aggregates. These BAs should have properties such that
the transit of individual packets of a BA through a differentiated
services network can be characterized by specific metrics. How-
ever, no microflow information should be required as packets
transit a differentiated services network.

This document defines and discusses Behavior Aggregates in
detail and lays out the format and required content for contribu-
tions to the Diffserv WG on BAs and the rules that will be applied
for individual BA specifications to advance as WG products. This
format is specified to expedite working group review of BA sub-
missions.

A pdf version of this document is available at: ftp://ftp-
eng.cisco.com/ftp/kmn-group/docs/BA_def.pdf.

Table of Contents

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

2. Some Definitions from RFC 2474.............................. 3

3. The Value of Defining Edge-to-Edge BAs...................... 3

4. Understanding Diffserv Behavior Aggregates.................. 4

5. Format for Specification of Diffserv Behavior Aggregates.... 6

6. Structuring BAs to Meet Expectations........................ 7

7. Reference Behavior Aggregates............................... 10

8. Sketchy Examples of Creating and Using BAs.................. 11

9. Procedure for submitting BAs to Diffserv WG................. 12

10 Acknowledgements............................................ 13

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

Nichols and Carpenter Expires: August, 2000 [page 2 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

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. Although business models will have to evolve
over time, there are technical issues in moving "beyond the box"
that lead to QoS models within a single network, i.e., not crossing
administrative domain boundaries. Providing QoS within a single
network is useful in itself and will provide useful deployment
experience for further IETF work as well as for the evolution of
business models. This step is critical in the evolution of Diffserv
QoS and should ultimately provide the technical input that will
aid in the construction of business models. The ultimate goal of
creating end to end QoS in the Internet 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.

Once packets have crossed the DS boundary, adherence to the
diffserv framework 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 the same 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 treatment of
packets of a behavior aggregate doesn't change when other pack-
ets join or leave the BA. If the properties of a BA using a particu-
lar PHB hold regardless of how the aggregate mutates as it
traverses the domain, then that BA 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 BA. Although useful
single-link BAs might exist, BAs that are invariant with network
size or that have simple relationships with network size and
whose properties can recovered by reapplying rules (that is, form-
ing 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 Behavior
Aggregate in a DS domain and a service that might be specified in
a Service Level Agreement. The BA definition is a technical
building block that couples rules, specific PHBs, and configura-
tions with specific observable characteristics. These definitions
are intended to be useful tools in configuring DS domains, but the
BA (or BAs) used by a provider are not expected to be visible to
customers any more than the specific PHBs employed in the pro-
vider's network would be. QoS providers are expected to select
their own measures to make customer-visible in contracts and
these may be stated quite differently from the characteristics in a
BA definition. Similarly, specific BAs are intended as tools for

Nichols and Carpenter Expires: August, 2000 [page 3 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

ISPs to construct differentiated services offerings; each may
choose different sets of tools, or even develop their own, in order
to achieve particular externally observable metrics.

This document defines Differentiated Services Behavior Aggre-
gates more precisely than past documents and specifies the format
that must be used for submissions of particular Behavior Aggre-
gates to the Diffserv WG.

2.0 Some Definitions from RFC 2474

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

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

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.

Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed. A diff-
erentiated services boundary can be further sub-divided into ingress
and egress nodes, where the ingress/egress nodes are the downstream/
upstream nodes of a boundary link in a given traffic direction.
A differentiated services boundary typically is found at the ingress to
the first-hop differentiated services-compliant router (or network
node) that a host's packets traverse, or at the egress of the last-hop
differentiated services-compliant router or network node that packets
traverse before arriving at a host. This is sometimes referred to as theboundary at a leaf router. A differentiated services boundary may be
co-located with a host, subject to local policy. Also DS boundary.

3.0 The Value of Defining Edge-to-Edge BAs

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. The specification of the
transit expectations of behavior aggregates across DS domains
both assists in the deployment of that 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 interconnecting DS domains with homoge-
neous administration will arise in interconnecting the autono-
mous systems (ASs) of the Internet.

Today's Internet is composed of multiple independently adminis-

Nichols and Carpenter Expires: August, 2000 [page 4 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

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, a 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, B 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 behavior aggregates.

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 so
that characteristics of behavior aggregates might sensibly be com-
puted. The filled in boxes in figure 1 represent the conformance
ensurers (e.g., shapers) and conformance enforcers (e.g., polic-
ers). Although we expect that policers and shapers will be
required at the boundaries of ASs, they might appear anywhere,
or nowhere, inside the AS. Thus, the boxes at the DS boundaries
internal to the AS may or may not condition traffic. Understand-
ing behavior under aggregation will result in guidelines for the
placement of DS boundaries.

4.0 Understanding Diffserv Behavior Aggregates

4.1 Defining BAs

In this section we expand on the definition of Behavior Aggre-
gates given in RFCs 2474 and 2475. Those RFCs define a Differ-
entiated Services Behavior Aggregate as "a collection of packets
with the same DS codepoint crossing a link in a particular direc-
tion" 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.

Within a DS domain, BAs are formed by the application of rules
to packets arriving at the DS boundary, through classification and
traffic conditioning. Packets that conform to the rules are marked
with the same DSCP (or a known set of DSCPs) within a domain.
In the interior of a DS domain, where DSCPs should not be

Nichols and Carpenter Expires: August, 2000 [page 5 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

remarked, as there are no rules being applied. Though a DS
domain may be as small as a single node, more complex topolo-
gies are expected to be the norm, thus the BA's definition must
hold as it is split and merged on the interior links of a DS domain.
Packet flow in a network is not part of the BA definition; the
application of rules as packets enter the DS domain and the con-
sistent PHB through the DS domain must suffice. (Though limits
can be put on the applicability of a specific BA.)

Associated with each BA are measurable, quantifiable, character-
istics which can be used to describe what will happen to packets
of that BA as they cross the DS domain. These expectations
derive from the rules that are enforced during the entry of packets
into the DS domain (the creation of the BA) and the forwarding
treatment (PHB) the BA gets inside the cloud. They may be abso-
lute or statistical bounds and they may be parameterized by net-
work properties.

4.2 Constructing BAs

Generally, the forwarding path of a DS domain is configured to
meet the network operator's traffic engineering goals for the
domain, independently of the performance goals for a particular
flow of a BA. Once the interior is configured, the rules on allocat-
ing BAs come from meeting the desired performance goals sub-
ject 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 to use and how to apply the
rules comes from matching performance to goals.

For example, consider the diffserv domain of figure 1. A BA
which specifies explicit bounds on loss must have rules at the
edge to ensure that, on the average, no more packets are admitted
than can emerge. As the network can contain queues, input traffic
may not equal the output traffic over all timescales. However the
averaging timescale should not exceed what might be expected
for reasonably sized buffering inside the network. Thus if we
allow bursts to arrive into the interior of the network, we must
know there is enough capacity to ensure that losses don't exceed
the BA's bound. Note that explicit bounds on the loss level can be
particularly difficult as the exact way in which packets of a partic-
ular BA merge inside the network affect the aggregate burstiness
and hence, loss.

PHBs give explicit expressions of what treatment a BA can
expect from each hop. This behavior must continue to apply
under aggregation of merging BA flows. Explicit expressions of
what happens to this behavior under aggregation, possibly param-
eterized by node in-degrees or network diameters are required.
This allows us to determine what to do at internal aggregation
points. For example, do we reapply edge rules?

Characterizing a BA requires exploring what happens to a PHB

Nichols and Carpenter Expires: August, 2000 [page 6 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

under aggregation. 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 BA flows merged, a BA speci-
fication must address this. A clear advantage of constructing
behaviors that aggregate is the ease of building up BAs that span
interior DS domains and eventually farther. For example, a BA
with known properties that crosses an interior DS domain of AS
B in figure 1, can be merged with the same type of BA at the inte-
rior shaded routers. Using the same (or fewer) rules as were
applied to create the BA at the entrance to AS B, there should be
confidence that the BA can continue to be quantified by the
expected behavior.

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 Forwarding path vs. control plane for BAs

The PHB and the edge rules that form and condition BAs are in
the forwarding path and take place at line rates while the configu-
ration of the DS domain edge to enforce rules on who goes into a
BA and how the BA should behave temporally is done by the con-
trol plane on a very different time scale. For example, configura-
tion 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 since how the configuration is done and at what
time scale it is done should not affect the characteristics of the
BA.

5.0 Format for Specification of Diffserv Behavior Aggregates

Behavior Aggregates arise from a particular relationship between
edge and interior (which may be parameterized). The quantifiable
characteristics of a BA MUST be independent of whether the net-
work edge is configured statically or dynamically. The particular
configuration of traffic conditioners at the DS domain edge is
critical to how a BA performs, but the act(s) of configuring the
edge is a control plane action which can be separated from the
specification of the BA.

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

5.1 Applicability Statement

All BAs must have an applicability statement that outlines the

Nichols and Carpenter Expires: August, 2000 [page 7 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

intended use of this BA and the limits to its use.

5.2 Rules

This section describes the rules to be followed in the creation of
this BA. 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 Characteristics

The characteristics of a BA tell how it behaves under ideal condi-
tions if configured in a specified manner (where the specification
may be parameterized). Characteristics of a BA might be 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, quantifi-
able, and defensible. Where particular statistics are used, the doc-
ument must be precise about how they are to be measured and
about how the characteristics were derived.

Advice to a network operator would be to use these characteris-
tics as guidelines in creating a service specification rather than
use them directly. For example, a "loss-free" BA would probably
not be sold as such, but rather as a service with a very small
packet loss probability.

5.4 Parameters

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

5.5 Assumptions

In most cases, BAs will be characterized 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. If additional
restrictions, e.g., route pinning, are required, these must be stated.
Some BAs may be developed without these assumptions, e.g., for
high loss rate links, and these must also be made explicit.

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

Nichols and Carpenter Expires: August, 2000 [page 8 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

5.6 Example Uses

A BA specification must give example uses to motivate the under-
standing of ways in which a diffserv network could make use of
the BA although these are not expected to be detailed. For exam-
ple, "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 BA due to
violation of that BA's rules."

5.7 Environmental Concerns (media, topology, etc.)

Note that it is not necessary for a provider to expose what Behav-
ior Aggregate (if a commonly defined one) is being used nor is it
necessary for a provider to specify the service by the BA's charac-
teristics. For example, a service provider might use a BA 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 Structuring BAs to Meet Expectations

Associated with each BA is an expectation: measurable, quantifi-
able, characteristics which can be used to describe what will hap-
pen to packets of that BA as they cross the domain. These
expectations result directly from the application of rules enforced
during the creation of the BA and/or its entry into the domain and
the forwarding treatment (PHB) packets of the BA get inside the
domain. There are many ways in which traffic might be distrib-
uted, 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 characterization of the BA.

There are two kinds of BA properties to consider. First are the
properties over "long" time periods, or average behaviors. In a
description of a BA, these would be the rates or throughput seen
over some specified time period. The second set of properties has
to do with the "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 the BA aggregates, 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 this BA will we see at any point (this would be
metered as a burst) and 2) how large a burst of packets of this BA
can appear in a queue at once (gives queue overflow and loss).

Put simply, a BA specification should provide the answer to the

Nichols and Carpenter Expires: August, 2000 [page 9 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

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 BA
characteristics

To make this more concrete, consider the DS domain of figure 2.
First consider the average or long-term behavior that must be
specified for a target BA which we designate as BAx. Can the DS
domain handle the average traffic flow? Is that answer topology-
dependent or are there some specific assumptions on routing
which must hold for BAx to preserve its "adequately provi-
sioned" capability? In other words, if the topology of D changes
suddenly, will the properties of BAx change? Will the loss rate of
BAx dramatically increase?

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

Let figure 2 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 were to go
down, causing all the BAx traffic between the two to transit the
entire ring, would the bounded behavior of BAx change? If some
node of the ring now has a larger arrival rate to one of its links
than the capacity of the link for BAx, clearly the loss rate would
change dramatically. In that case, there were topological assump-
tions made about the path of the traffic from A to Z that affected
the characteristics of BAx. Once these no longer hold, any
assumptions on the loss rate of packets of BAx crossing 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 BA specification should spell out the
assumptions made on preserving the characteristics.

6.2 Considerations in specifying short-term or bursty BA
characteristics

Next, consider the short-time behavior of a BA, specifically
whether permitting the maximum bursts to add in the same man-
ner 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 of p
packets into BAx, they could accumulate as they transit the ring.
For packets headed for link L, back-to-back BAx packets can
come from both directions and arrive at the same time. If the
bandwidth of link L is the same as the links of the ring, this prob-
ably does not present a buffering problem. If there are two input
links that can send packets to queue for L, at worst, two packets
can arrive simultaneously for L. If the bandwidth of link L equals
or exceeds twice B, the packets won't accumulate. Further, if p is
limited to one, and the bandwidth of L exceeds the rate of arrival
(over the longer term) of BAx packets (required for bounding the

Nichols and Carpenter Expires: August, 2000 [page 10 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

loss) then the queue of BAx packets for link L will empty before
new packets arrive. If the bandwidth of L is equal to B, one packet
of BAx must queue while the other is transmitted. This would
result in N x p back-to-back packets of BAx arriving over L dur-
ing the same time scale as the bursts of p were permitted on the
uplinks. Link L should be configured to handle the sum of the
rates that ingress to BAx, but that doesn't guarantee that it can
handle the sum of the N bursts into BAx.

If the bandwidth of L is less than B, then the link must buffer
Nxpx(B-L)/B BAx packets to avoid loss. If BAx 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 BAx packets
might arrive on each input. Then, in the absence of any additional
rules, it is possible that dxpx(# of uplinks) back-to-back BAx
packets can be sent across link L to domain E. Thus the DS
domain E must permit these much larger bursts into BAx than
domain D permits on the N uplinks or else the flow of BAx pack-
ets must be made to conform to the rules for entering E (e.g., by
shaping).

What conditions should be imposed on a BA and on the PHBs
which carry it in order to ensure BAs that can be interconnected
as across the interior DS domains of figure 1? Edge rules for con-
structing a BA that has certain characteristics across a DS domain
should apply independently of the origin of the packets. With ref-
erence to the example we've been exploring, the rules for a BA
entering link L into domain E should not depend on the number
of uplinks into domain D.

6.3 Example

Consider where all the uplinks have the same bandwidth B and
link L has bandwidth L which is less than or equal to B. Flows of
BAx packets 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
BAx, 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 BAx
queue for link L in 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 allot-
ment 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 BAx 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 BAx packets, either the required
buffer size can become large or the burst size of BAx entering E

Nichols and Carpenter Expires: August, 2000 [page 11 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

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 BAx 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 of BAx, the queue
size will not reduce. If two more bursts (6 of the 18 packets)
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 BAx. 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. There may be BAs where the intention is to permit loss, but
in that case, it should be constructed so as to provide a probabilis-
tic bound for the queue size to exceed a reasonable buffer size of
one or two bandwidth-delay products. Alternatively or addition-
ally, rules can be used that bound the amount of BAx that queues
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 creation of the aggregate, such as intermediate shap-
ing.

7.0 Reference Behavior Aggregates

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

7.1 Best Effort Behavior Aggregate

7.1.1 Applicability

A Best Effort (BE) BA is for sending "normal internet traffic"
across a diffserv network. That is, the definition and use of this
BA is to preserve, to a reasonable extent, the pre-diffserv delivery
expectation for packets in a diffserv network that do not require
any special differentiation.

7.1.2 Rules

There are no rules governing rate and bursts of packets beyond
the limits imposed by the ingress link. At each network node in
the interior of the network, packets marked for this BA are given
the Default PHB (as defined in [RFC2474]).

7.1.3 Characteristics of this BA

Nichols and Carpenter Expires: August, 2000 [page 12 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

"As much as possible as soon as possible".

Packets of this BA will not be completely starved and when
resources are available, this BA should be configured to consume
them.

Although some network operators may bound the delay and loss
rate for this aggregate given knowledge about their network, such
characteristics are not required.

7.1.4 Parameters

None.

7.1.5 Assumptions

A properly functioning network.

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.

7.2 Bulk Handling Behavior Aggregate

7.2.1 Applicability

A Bulk Handling (BH) BA 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

7.2.3 Characteristics of this BA

Packets are forwarded when there are idle resources.

7.2.4 Parameters

None.

7.2.5 Assumptions

A properly functioning network.

Nichols and Carpenter Expires: August, 2000 [page 13 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

7.2.6 Example uses

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

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

8.0 Sketchy Examples of Creating and Using BAs

There is a clear interaction between the number and strictness of
the rules and the number and strictness of quantifiable character-
istics for a BA. Examples of more strictly defined BAs will be
necessary to make this document's definitions clearer. This is
being addressed in two ways. One, a companion document is in
preparation defining a BA that uses the EF PHB and is related to
the VLL described in [RFC2598]. In addition, this section
includes two "sketchy" examples to motivate thinking and discus-
sion on BAs. The following examples are illustrative rather than
exhaustive or even complete.

The following should be looked at as "mythical" BAs that may
never see the light of day and will likely not appear in future revi-
sions of this document.

8.1 Loss Tolerant Provisioned

A loss-tolerant provisioned BA is useful for statistically provi-
sioning a BA whose packets should have low delay, but are loss-
tolerant. Rules for this aggregate are that entering composite BAs
must not exceed a peak rate of Rp and may not burst more than
two MTU packet-times at Rp. The BA uses CS3, selected by
DSCP03 and configured so that its minimum share of all internal
links is Smin (in bps), running active queue management with a
low threshold (defined in time rather than packets) and a small
maximum queue size (also in time). Characteristics of this BA:

Some 90th percentile bound on loss and delay.

Parameterized by Smin and Rp. The sum of all the Rp should be on
the order of some over provisioning factor (larger than 1).

Assumptions on these characteristics are that the network is oper-
ating under ideal conditions.

8.2 Preferred

A Preferred BA is for provisioning traffic so as to give low-load
performance across a DS domain. The rules governing it are that
the packets of this BA arriving over any ingress to the domain are
average rate-limited to Ra with a maximum burst size of Bmax.
The BA uses CS4, selected by DSCP04 and configured so that its
minimum share of all internal links is Smin (in bps) and the sum
of all Ra < Smin. Characteristics of this BA:

Nichols and Carpenter Expires: August, 2000 [page 14 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

Probabilistic bounds based on the sum of all allocated rates and
the burst size.

Throughput measured over 5 minute intervals will be at least Ra.

Assumptions on these characteristics are that the network is oper-
ating under ideal conditions.

Example uses:

1. A voice service where customer is guaranteed a conformant
packet loss rate of less than 0.5% and a latency bound of 20 ms,
99th percentile jitter less than 2 packet-times, median jitter of less
than a packet-time across the domain.

2. A "leased line replacement" where the customer is guaranteed
to receive throughput performance indistinguishable from a
leased line at Rp with a per-packet delay of less than 20 msec
through the cloud.

9.0 Procedure for submitting BAs 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 such a BA, though comments and questions on the
claimed characteristics are reasonable.

3. Once consensus has been reached on a version of a draft that it
is a useful BA 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 "BA series".

Nichols and Carpenter Expires: August, 2000 [page 15 ]

INTERNET DRAFT draft-ietf-diffserv-ba-def-01.txt February, 2000

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

11.0 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, ftp://
ftp.isi.edu/in-notes/rfc2597.txt

[RFC2598] RFC 2598, "An Expedited Forwarding PHB",
V.Jacobson, K.Nichols, K.Poduri, ftp://ftp.isi.edu/in-
notes/rfc2598.txt

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

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

Authors' Addresses

Kathleen Nichols Brian E. Carpenter
Cisco Systems IBM
170 West Tasman Drive c/o iCAIR
San Jose, CA 95134-1706 Suite 150
1890 Maple Avenue
email: kmn@cisco.com Evanston, IL 60201
USA
EMail: brian@icair.org