draft-ietf-diffserv-pdb-def-00.txt   draft-ietf-diffserv-pdb-def-01.txt 
Internet Engineering Task Force K. Nichols Internet Engineering Task Force K. Nichols
Differentiated Services Working Group Packet Design Differentiated Services Working Group Packet Design
Internet Draft B. Carpenter Internet Draft B. Carpenter
Expires in December, 2000 IBM Expires in April, 2001 IBM
Definition of Differentiated Services Per Domain
Behaviors and Rules for their Specification
<draft-ietf-diffserv-pdb-def-00> Definition of Differentiated Services Per Domain Behaviors and Rules
for their Specification
<draft-ietf-diffserv-pdb-def-01>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
with all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are working
working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its areas,
(IETF), its areas, and its working groups. Note that other groups and its working groups. Note that other groups may also distribute
may also distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other doc- and may be updated, replaced, or obsoleted by other documents at any
uments at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference material
reference material or to cite them other than as "work in or to cite them other than as "work in progress."
progress."
This document is a product of the Diffserv working group. Com- This document is a product of the Diffserv working group. Comments
ments on this draft should be directed to the Diffserv mailing list on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>. The list of current Internet-Drafts can be <diffserv@ietf.org>. The list of current Internet-Drafts can be accessed
accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of at www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Internet-Draft Shadow Directories can be accessed at http:// Shadow Directories can be accessed at www.ietf.org/shadow.html.
www.ietf.org/shadow.html. Distribution of this memo is unlim- Distribution of this memo is unlimited.
ited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
The diffserv WG has defined the general architecture for differen- The differentiated services framework enables quality-of-service
tiated services (RFC 2475) and has been focused on the definition provisioning within a network domain by applying rules at the edges to
and standardization of the forwarding path behavior required in create traffic aggregates and coupling each of these with a specific
routers, known as "per-hop forwarding behaviors" (or PHBs) forwarding path treatment in the domain through use of a codepoint in
(RFCs 2474, 2597, and 2598). The differentiated services frame- the IP header [RFC2474]. The diffserv WG has defined the general
work creates services within a network by applying rules at the architecture for differentiated services [RFC2475] and has focused on
network edges to create traffic aggregates and coupling these with the forwarding path behavior required in routers, known as "per-hop
a specific forwarding path treatment for the aggregate. The WG forwarding behaviors" (or PHBs) [RFC2474, RFC2597, and RFC2598]. The WG
has also discussed the behavior required at diffserv network edges has also discussed functionality required at diffserv (DS) domain edges
or boundaries for conditioning packet aggregates, such elements to select (classifiers) and condition (e.g., policing and shaping)
as policers and shapers [MODEL, MIB]. A major feature of the traffic according to the rules [RFC2475, MODEL, MIB]. Short-term changes
diffserv architecture is that only the components applying the in the QoS goals for a DS domain are implemented by changing only the
rules at the edge need to be changed in response to short-term configuration of these edge behaviors rather than reconfiguring the
changes in QoS goals in the network, rather than reconfiguring behavior of interior network nodes.
the interior behaviors.
The next step for the WG is to formulate examples of how the for-
Nichols and Carpenter Expires: December, 2000 [page 1 ]
warding path components (PHBs, classifiers, and traffic condi-
tioners) can be used within the architectural framework to
compose traffic aggregates whose packets experience specific
forwarding characteristics as they transit a differentiated services
domain. The WG has decided to use the term per-domain behav-
ior, or PDB, to describe the behavior experienced by packets of a
particular traffic aggregate as they cross a DS domain. PDBs can
be used to characterize, by specific metrics, the treatment individ-
ual packets with a particular DSCP (or set of DSCPs) will receive
as it crosses a DS domain. However, no microflow information
should be required as packets transit a differentiated services net-
work. A PDB is an expression of a fowarding path treatment, but
due to the role that particular choices of edge and PHB configura-
tion play in its resulting attributes, it is where the forwarding path
and the control plane interact.
This document defines and discusses Per Domain Behaviors in The next step is to formulate examples of how forwarding path components
detail and lays out the format and required content for contribu- (PHBs, classifiers, and traffic conditioners) can be used to compose
tions to the Diffserv WG on PDBs and the rules that will be traffic aggregates whose packets experience specific forwarding
applied for individual PDB specifications to advance as WG characteristics as they transit a differentiated services domain. The WG
products. This format is specified to expedite working group has decided to use the term per-domain behavior, or PDB, to describe the
review of PDB submissions. behavior experienced by a particular set of packets as they cross a DS
domain. A PDB is characterized by specific metrics that quantify the
treatment a set of packets with a particular DSCP (or set of DSCPs) will
receive as it crosses a DS domain. A PDB specifies a fowarding path
treatment for a traffic aggregate and, due to the role that particular
choices of edge and PHB configuration play in its resulting attributes,
it is where the forwarding path and the control plane interact. The
measurable parameters of a PDB should be suitable for use in Service
Level Specifications at the network edge.
A pdf version of this document is available at: ftp://www.packet- This document defines and discusses Per Domain Behaviors in detail
design.com/outgoing/ietf/pdb_def.pdf. and lays out the format and required content for contributions to
the Diffserv WG on PDBs and the rules that will be applied for
individual PDB specifications to advance as WG products. This format is
specified to expedite working group review of PDB submissions.
Table of Contents A pdf version of this document is available at:
www.packetdesign.com/ietf/diffserv/pdb_def.pdf.
1. Introduction ........................................ 2 Change log for -01 version
2. Definitions ......................................... 3 -Noted that PDB parameters may form part of SLS (1.0).
3. The Value of Defining Edge-to-Edge Behavior ......... 4 -Clarified that parameters are not absolute values (4.1, 5.3).
4. Understanding Diffserv PDBs ......................... 5 -Rewrote the PDB from PHB group section (4.3).
5. Format for Specification of Diffserv PDBs ........... 8 -Added traffic conditioning needs to PDB rules (5.2).
6. PDB Attributes ..................................... 10 -Replaced reference to route pinning by general reference to traffic
engineering, added reference to assumption of standby capacity (5.5).
7. Reference Per-Domain Behaviors ..................... 13 -Removed Example from Section 6 (6.3).
8. Procedure for Submitting PDBs to Diffserv WG ....... 14 -Deleted Bulk Handling PDB (7.2).
9. Acknowledgements ................................... 15 -Add requirement for PDB deployment experience (section 8).
1.0 Introduction -General syntax cleanups etc. Shortened and tweaked the Abstract.
Tweaked the Introduction.
Differentiated Services allows an approach to IP QoS that is mod- -Eliminated solo usage of "aggregate" since it seems to confuse people.
ular, high performance, incrementally deployable, and scalable Using "aggregate" as an abbreviation for sometimes BA and sometimes
[RFC2475]. Although an ultimate goal is interdomain quality of TA is definitely confusing. Removed the following from the definitions:
service, there remain many untaken steps on the road to achieving The terms "aggregate" and "behavior aggregate" are used interchangeably
in this document.
Nichols and Carpenter Expires: December, 2000 [page 2 ] 1 Introduction
this goal. One essential step, the evolution of the business models Differentiated Services allows an approach to IP Quality of Service
for interdomain QoS, will necessarily develop outside of the that is modular, incrementally deployable, and scalable while
introducing minimal per-node complexity [RFC2475]. From the end user's
point of view, QoS should be supported end-to-end between any pair of
hosts. However, this goal is not immediately attainable. It will require
interdomain QoS support, and many untaken steps remain on the road
to achieving this. One essential step, the evolution of the business
models for interdomain QoS, will necessarily develop outside of the
IETF. A goal of the diffserv WG is to provide the firm technical IETF. A goal of the diffserv WG is to provide the firm technical
foundation that allows these business models to develop. foundation that allows these business models to develop. The first
major step will be to support edge-to-edge or intradomain QoS between
the ingress and egress of a single network, i.e. a DS Domain in the
terminology of RFC 2474. The intention is that this edge-to-edge QoS
should be composable, in a purely technical sense, to a quantifiable
multi-domain QoS.
The Diffserv WG has finished the first phase of standardizing the The Diffserv WG has finished the first phase of standardizing the
behaviors required in the forwarding path of all network nodes, behaviors required in the forwarding path of all network nodes, the
the per-hop forwarding behaviors or PHBs. The PHBs defined in per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474,
RFCs 2474, 2597 and 2598 give a rich toolbox for differential 2597 and 2598 give a rich toolbox for differential packet handling by
packet handling. A diffserv Conceptual Model [MODEL] individual boxes. The general architectural model for diffserv has been
describes a model of traffic conditioning and other forwarding documented in RFC 2475. An informal router model [MODEL] describes a
behaviors. model of traffic conditioning and other forwarding behaviors. However,
technical issues remain in moving "beyond the box" to intradomain QoS
Although business models will have to evolve over time, there models.
also remain technical issues in moving "beyond the box" to QoS
models that apply within a single network domain. Providing
QoS on a per-domain basis is useful in itself and will provide use-
ful deployment experience for further IETF work as well as for
the evolution of business models. The step of specifying forward-
ing path attributes on a per-domain basis for a traffic aggregate
distinguished only by the mark in the DS field of individual pack-
ets is critical in the evolution of Diffserv QoS and should provide
the technical input that will aid in the construction of business
models. The ultimate goal of creating end to end QoS in the Inter-
net imposes the requirement that we can create and quantify a
behavior for a group of packets that is preserved when they are
aggregated with other packets. This document defines and speci-
fies the term "Per-Domain Behavior" or PDB to describe QoS
attributes across a DS domain.
In diffserv, rules are imposed on packets arriving at the boundary
of a DS domain through use of classification and traffic condi-
tioning which are set to reflect the policy and traffic goals for
that domain. Once packets have crossed the DS boundary, adherence
to diffserv principles makes it possible to group packets solely
according to the behavior they receive at each hop. This approach
has well-known scaling advantages, both in the forwarding path
and in the control plane. Less well recognized is that these scaling
properties only result if the per-hop behavior definition gives rise
to a particular type of invariance under aggregation. Since the
per-hop behavior must be equivalent for every node in the domain
while the set of packets marked for that PHB may be different at
every node, a PHB should be defined such that its defining char-
acteristics don't depend on the volume of the associated BA on a
router's ingress link nor on a particular path through the DS
domain taken by the packets marked for it. If the properties of a
PDB using a particular PHB hold regardless of how the marked
aggregate mutates as it traverses the domain, then that PDB
scales. If there are limits to where the properties hold, that
translates to a limit on the size or topology of a DS domain that
can use that PDB. Although useful single-link DS domains might
exist, PDBs that are invariant with network size or that have sim-
ple relationships with network size and whose properties can be
Nichols and Carpenter Expires: December, 2000 [page 3 ] The ultimate goal of creating scalable end to end QoS in the Internet
requires that we can identify and quantify behavior for a group of
packets that is preserved when they are aggregated with other packets
as they traverse the Internet. The step of specifying forwarding path
attributes on a per-domain basis for a set of packets distinguished
only by the mark in the DS field of individual packets is critical
in the evolution of Diffserv QoS and should provide the technical
input that will aid in the construction of business models. This
document defines and specifies the term "Per-Domain Behavior" or PDB
to describe QoS attributes across a DS domain.
recovered by reapplying rules (that is, forming another diffserv In diffserv, rules are imposed on certain packets arriving at the
boundary or edge to re-enforce the rules for the aggregate) are boundary of a DS domain through use of classification and traffic
needed for building scalable end-to-end quality of service. conditioning which are set to reflect the policy and traffic goals for
that domain. Once packets have crossed the DS boundary, adherence to
diffserv principles makes it possible to group packets solely according
to the behavior they receive at each hop. This approach has well-known
scaling advantages, both in the forwarding path and in the control
plane. Less well recognized is that these scaling properties only
result if the per-hop behavior definition gives rise to a particular
type of invariance under aggregation. Since the per-hop behavior must be
equivalent for every node in the domain, while the set of packets marked
for that PHB may be different at every node, PHBs should be defined such
that their characteristics do not depend on the traffic volume of the
associated BA on a router's ingress link nor on a particular path
through the DS domain taken by the packets. Specifically, different
streams of traffic that belong to the same traffic aggregate merge and
split as they traverse the network. If the properties of a PDB using a
particular PHB hold regardless of how the marked traffic aggregate
mutates as it traverses the domain, then that PDB scales. (Clearly this
assumes that numerical parameters such as bandwidth allocated to the
particular PDB may be different at different points in the network, and
may be adjusted dynamically as traffic volume varies.) If there are
limits to where the properties hold, that translates to a limit on the
size or topology of a DS domain that can use that PDB. Although useful
single-link DS domains might exist, PDBs that are invariant with network
size or that have simple relationships with network size and whose
properties can be recovered by reapplying rules (that is, forming
another diffserv boundary or edge to re-enforce the rules for the
traffic aggregate) are needed for building scalable end-to-end quality
of service.
There is a clear distinction between the definition of a Per- There is a clear distinction between the definition of a Per-Domain
Domain Behavior in a DS domain and a service that might be Behavior in a DS domain and a service that might be specified in a
specified in a Service Level Agreement. The PDB definition is a Service Level Agreement. The PDB definition is a technical building
technical building block that couples rules, specific PHBs, and block that couples rules, specific PHBs, and configurations with a
configurations with a resulting set of specific observable resulting set of specific observable attributes which may be
attributes which may be characterized in a variety of ways. These characterized in a variety of ways. These definitions are intended to be
definitions are intended to be useful tools in configuring DS useful tools in configuring DS domains, but the PDB (or PDBs) used by a
domains, but the PDB (or PDBs) used by a provider are not provider are not expected to be visible to customers any more than the
expected to be visible to customers any more than the specific specific PHBs employed in the provider's network would be. Network
PHBs employed in the provider's network would be. Network providers are expected to select their own measures to make customer-
providers are expected to select their own measures to make cus- visible in contracts and these may be stated quite differently from the
tomer-visible in contracts and these may be stated quite differ- technical attributes specified in a PDB definition. Similarly, specific
ently from the technical attributes specified in a PDB definition. PDBs are intended as tools for ISPs to construct differentiated services
Similarly, specific PDBs are intended as tools for ISPs to con- offerings; each may choose different sets of tools, or even develop
struct differentiated services offerings; each may choose different their own, in order to achieve particular externally observable metrics.
sets of tools, or even develop their own, in order to achieve Nevertheless, the measurable parameters of a PDB are expected to be
particular externally observable metrics. among the parameters cited directly or indirectly in the Service Level
Specification component of a corresponding SLA.
This document defines Differentiated Services Per-Domain This document defines Differentiated Services Per-Domain Behaviors
Behaviors and specifies the format that must be used for submis- and specifies the format that must be used for submissions of particular
sions of particular PDBs to the Diffserv WG. PDBs to the Diffserv WG.
2.0 Definitions 2 Definitions
The following definitions are stated in RFCs 2474 and 2475 and The following definitions are stated in RFCs 2474 and 2475 and are
are repeated here for easy reference: repeated here for easy reference:
o Behavior Aggregate: a collection of packets with the same codepoint " Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction. The terms "aggregate" and crossing a link in a particular direction.
"behavior aggregate" are used interchangeably in this document.
o Differentiated Services Domain: a contiguous portion of the Internet " Differentiated Services Domain: a contiguous portion of the Internet
over which a consistent set of differentiated services policies are over which a consistent set of differentiated services policies are
administered in a coordinated fashion. A differentiated services administered in a coordinated fashion. A differentiated services domain
domain can represent different administrative domains or autono- can represent different administrative domains or autonomous systems,
mous systems, different trust regions, different network technologies different trust regions, different network technologies (e.g.,
(e.g., cell/frame), hosts and routers, etc. Also DS domain. cell/frame), hosts and routers, etc. Also DS domain.
o Differentiated Services Boundary: the edge of a DS domain, where " Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed. A classifiers and traffic conditioners are likely to be deployed. A
differentiated services boundary can be further sub-divided into differentiated services boundary can be further sub-divided into ingress
ingress and egress nodes, where the ingress/egress nodes are the down- and egress nodes, where the ingress/egress nodes are the
stream/upstream nodes of a boundary link in a given traffic direction. downstream/upstream nodes of a boundary link in a given traffic
A differentiated services boundary typically is found at the ingress direction. A differentiated services boundary typically is found at the
to the first-hop differentiated services-compliant router (or network ingress to the first-hop differentiated services-compliant router (or
node) that a host's packets traverse, or at the egress of the last-hop network node) that a host's packets traverse, or at the egress of the
differentiated services-compliant router or network node that packets last-hop differentiated services-compliant router or network node that
traverse before arriving at a host. This is sometimes referred to as packets traverse before arriving at a host. This is sometimes referred
the boundary at a leaf router. A differentiated services boundary may to as the boundary at a leaf router. A differentiated services boundary
may be co-located with a host, subject to local policy. Also DS
Nichols and Carpenter Expires: December, 2000 [page 4 ] boundary.
be co-located with a host, subject to local policy. Also DS boundary.
To these we add: To these we add:
o Traffic Aggregate: a collection of packets with a codepoint that " Traffic Aggregate: a collection of packets with a codepoint that
maps to the same PHB, usually in a DS domain or some subset of a DS maps to the same PHB, usually in a DS domain or some subset of a DS
domain. A traffic aggregate marked for a the foo PHB is referred to domain. A traffic aggregate marked for the foo PHB is referred to
as the "foo traffic aggregate" or the "foo aggregate" interchangeably. as the "foo traffic aggregate" or the "foo aggregate" interchangeably.
This generalizes the concept of Behavior Aggregate from a link to
a network.
o Per-Domain Behavior: the expected treatment that an identifiable or " Per-Domain Behavior: the expected treatment that an identifiable
target group of packets will receive from "edge to edge" of a DS or target group of packets will receive from "edge to edge" of a DS
domain. (Also PDB.) A particular PHB (or, if applicable, list of domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs)
PHBs) and traffic conditioning requirements are associated with and traffic conditioning requirements are associated with each PDB.
each PDB.
3.0 The Value of Defining Edge-to-Edge " A Service Level Specfication (SLS) is a set of parameters and their
Behavior values which together define the service offered to a traffic stream
by a DS domain. It is expected to include specific values or bounds
for PDB parameters.
Networks of DS domains can be connected to create end-to-end 3 The Value of Defining Edge-to-Edge Behavior
services, but where DS domains are independently administered,
the evolution of the necessary business agreements and future sig-
naling arrangements will take some time. Early deployments will
be within a single administrative domain. Specification of the
transit expectations of packets matching a target for a particular
diffserv behavior across a DS domain both assists in the deploy-
ment of single-domain QoS and will help enable the composition
of end-to-end, cross domain services to proceed. Putting aside the
business issues, the same technical issues that arise in intercon-
necting DS domains with homogeneous administration will arise
in interconnecting the autonomous systems (ASs) of the Internet.
Today's Internet is composed of multiple independently adminis- As defined in section 2, a PDB describes the edge-to-edge behavior
tered domains or Autonomous Systems (ASs), represented by the across a DS domain's "cloud." Specification of the transit expectations
circles in figure 1. To deploy ubiquitous end-to-end quality of ser- of packets matching a target for a particular diffserv behavior across
vice in the Internet, business models must evolve that include a DS domain will both assist in the deployment of single-domain QoS
issues of charging and reporting that are not in scope for the and will help enable the composition of end-to-end, cross domain
IETF. In the meantime, there are many possible uses of quality of services. Networks of DS domains can be connected to create end-to-end
service within an AS and the IETF can address the technical services by building on the PDB characteristics without regard to the
issues in creating an intradomain QoS within a Differentiated particular PHBs used. This level of abstraction makes it easier to
Services framework. In fact, this approach is quite amenable to compose cross-domain services as well as making it possible to hide
incremental deployment strategies. details of a network's internals while exposing information sufficient
to enable QoS.
Figure 1: Interconnection of ASs and DS Domains Today's Internet is composed of multiple independently administered
domains or Autonomous Systems (ASs), represented by the "clouds" in
figure 1. To deploy ubiquitous end-to-end quality of service in the
Internet, business models must evolve that include issues of charging
and reporting that are not in scope for the IETF. In the meantime,
there are many possible uses of quality of service within an AS and
the IETF can address the technical issues in creating an intradomain
QoS within a Differentiated Services framework. In fact, this approach
is quite amenable to incremental deployment strategies.
A single AS (for example, AS2 in figure 1) may be composed of Where DS domains are independently administered, the evolution of the
subnetworks and, as the definition allows, these can be separate necessary business agreements and future signaling arrangements will
DS domains. For a number of reasons, it might be useful to have take some time, thus, early deployments will be within a single
multiple DS domains in an AS, most notable being to follow administrative domain. Putting aside the business issues, the same
topological and/or technological boundaries and to separate the technical issues that arise in interconnecting DS domains with
allocation of resources. If we confine ourselves to the DS bound- homogeneous administration will arise in interconnecting the autonomous
aries between these "interior" DS domains, we avoid the non- systems (ASs) of the Internet.
technical problems of setting up a service and can address the
issues of creating characterizable PDBs.
Nichols and Carpenter Expires: December, 2000 [page 5 ] A single AS (e.g., AS2 in figure 1) may be composed of subnetworks
and, as the definition allows, these can be separate DS domains. An
AS might have multiple DS domains for a number of reasons, most notable
being to follow topological and/or technological boundaries and to
separate the allocation of resources. If we confine ourselves to the
DS boundaries between these "interior" DS domains, we avoid the non-
technical problems of setting up a service and can address the issues
of creating characterizable PDBs.
The incentive structure for differentiated services is based on ----------------------------------------
upstream domains ensuring their traffic conforms to agreed upon | AS2 |
rules and downstream domains enforcing that conformance, thus | |
metrics associated with PDBs can be sensibly computed. The ------- | ------------ ------------ |
rectangular boxes in figure 1 represent the DS boundary routers | AS1 |------|-----X | | | |
and thus would contain the traffic conditioners that ensure and ------- | | | Y | | -------
enforce conformance (e.g., shapers and policers). Although we | | | /| X----|--------| AS3 |
expect that policers and shapers will be required at the DS bound- | | | / | | | -------
aries of ASs (dark rectangles), they might appear anywhere, or | | | / ------------ |
nowhere, inside the AS. Thus, the boxes at the DS boundaries | | Y | |
internal to the AS (shaded rectangles) may or may not condition | | | \ ------------ |
traffic. Understanding a particular PDB's characteristics under ------- | | | \ | | |
aggregation and multiple hops will result in guidelines for the | AS4 |------|-----X | \| | |
placement and configuration of DS boundaries. ------- | | | Y X----|------
| | | | | |
| ------------ ------------ |
| |
| |
----------------------------------------
This approach continues the separation of forwarding path and Figure 1: Interconnection of ASs and DS Domains
control plane decribed in RFC 2474. The forwarding path charac-
teristics are addressed by considering what happens at every hop
of a packet's path and what behaviors can be characterized under
the merging and branching through multiple hops. The control
plane only needs to be employed in the configuration of the DS
boundaries. A PDB provides a link between the DS domain level
at which control is exercised to form traffic aggregates with qual-
ity-of-service goals across the domain and the per-hop and per-
link treatments packets receive that results in meeting the quality-
of-service goals.
4.0 Understanding PDBs The incentive structure for differentiated services is based on upstream
domains ensuring their traffic conforms to agreed upon rules and
downstream domains enforcing that conformance, thus metrics associated
with PDBs can be sensibly computed. The "X's" in figure 1 represent the
DS boundary routers containing traffic conditioners that ensure and
enforce conformance (e.g., shapers and policers). Although
policers and shapers are expected at the DS boundaries of ASs, they
might appear anywhere, or nowhere, inside the AS. Specifically, the
X's at the DS boundaries internal to the AS may or may not condition
traffic. Technical guidelines for the placement and configuration of DS
boundaries should derive from the attributes of a particular PDB under
aggregation and multiple hops.
4.1 Defining PDBs This definition of PDB continues the separation of forwarding path
and control plane decribed in RFC 2474. The forwarding path
characteristics are addressed by considering how the behavior at every
hop of a packet's path is affected by the merging and branching of
traffic aggregates through multiple hops. Per-hop behaviors in nodes are
configured infrequently, representing a change in network
infrastructure. More frequent quality-of-service changes come from
employing control plane functions in the configuration of the DS
boundaries. A PDB provides a link between the DS domain level at which
control is exercised to form traffic aggregates with quality-of-service
goals across the domain and the per-hop and per-link
treatments packets receive that results in meeting the
quality-of-service goals.
RFCs 2474 and 2475 define a Differentiated Services Behavior 4 Understanding PDBs
Aggregate as "a collection of packets with the same DS codepoint
crossing a link in a particular direction" and further state that
packets with the same DSCP get the same per-hop forwarding
treatment (or PHB) everywhere inside a single DS domain. Note
that even if multiple DSCPs map to the same PHB, this must hold
for each DSCP individually. In section 2 of this document, we
introduced a more general definition of a traffic aggregate in the
diffserv sense so that we might easily refer to the packets which
are mapped to the same PHB everywhere within a DS domain.
Section 2 also presented a short definition of PDBs which we
expand upon in this section:
Per-Domain Behavior: the expected treatment that an identifiable or 4.1 Defining PDBs
target group of packets will receive from "edge to edge" of a DS
domain. A particular PHB (or, if applicable, list of PHBs) and traffic
conditioning requirements are associated with each PDB.
Measurable, quantifiable, attributes are associated with each PDB RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate
and these can be used to describe what will happen to packets of as "a collection of packets with the same DS codepoint crossing a
that PDB as they cross the DS domain. These derive from the link in a particular direction" and further state that packets with
the same DSCP get the same per-hop forwarding treatment (or PHB)
everywhere inside a single DS domain. Note that even if multiple DSCPs
map to the same PHB, this must hold for each DSCP individually. In
section 2 of this document, we introduced a more general definition of a
traffic aggregate in the diffserv sense so that we might easily refer to
the packets which are mapped to the same PHB everywhere within a DS
domain. Section 2 also presented a short definition of PDBs which we
expand upon in this section:
Nichols and Carpenter Expires: December, 2000 [page 6 ] Per-Domain Behavior: the expected treatment that an identifiable
or target group of packets will receive from "edge to edge" of a
DS domain. A particular PHB (or, if applicable, list of PHBs) and
traffic conditioning requirements are associated with each PDB.
rules that are enforced during the entry of packets into the DS Each PDB has measurable, quantifiable, attributes that can be used
domain and the forwarding treatment (PHB) the packets get to describe what happens to its packets as they enter and cross the
inside the domain. PDB attributes may be absolute or statistical DS domain. These derive from the rules that are enforced during the
and they may be parameterized by network properties. For exam- entry of packets into the DS domain and the forwarding treatment (PHB)
ple, a loss attribute might be expressed as "no more than 0.1% of the packets get inside the domain, but can also depend on the entering
packets will be dropped when measured over any time period traffic loads and the domain's topology. PDB attributes may be absolute
or statistical and they may be parameterized by network properties.
For example, a loss attribute might be expressed as "no more than
0.1% of packets will be dropped when measured over any time period
larger than T", a delay attribute might be expressed as "50% of larger than T", a delay attribute might be expressed as "50% of
deliverd packets will see less than a delay of d milliseconds, 30% delivered packets will see less than a delay of d milliseconds, 30% will
will see a delay less than 2d ms, 20% will see a delay of less than see a delay less than 2d ms, 20% will see a delay of less than 3d ms."
3d ms." A wide range of metrics is possible. A wide range of metrics is possible. In general they will be expressed
as bounds or percentiles rather than as absolute values.
Identification of the target group of packets is carried out using A PDB is applied to a target group of packets arriving at the edge
classification. The Per-Domain Behavior applied to that group of of the DS domain. The target group is distinguished from all arriving
packet is characterized in two parts: 1) the relationship between packets by use of packet classifiers [RFC2475] (where the classifier
this target group of packets to the marked traffic aggregate which may be "null"). The action of the PDB on the target group has two
results from the application of rules (through the use of traffic parts. The first part is the enforcement of rules (through the use
conditioning) to the identified (classified) packets to create a traf- of traffic conditioning) to create a traffic aggregate. Packets that
fic aggregate marked for the associated PHB (see figure 2) and 2) conform to the rules are marked with a DSCP for the PHB associated with
the attributes which result from the treatment experienced by the PDB (see figure 2). The second part is the treatment experienced
packets from the same traffic aggregate transiting the interior of a by packets from the same traffic aggregate transiting the interior
DS domain, between and inside of DS boundaries. of a DS domain, between and inside of DS domain boundaries. The
following subsections further discuss these two effects on the target
group that arrives at the DS domain boundary.
Figure 2: Relationship of the traffic aggregate associated with a ----------- ------------ -------------------- foo
PDB to arriving packets arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets | | |of packets | |& marking (for foo) | aggregate
----------- ------------ --------------------
The first part is more straightforward than the second, but might Figure 2: Relationship of the traffic aggregate associated with
depend on the arriving traffic pattern as well as the configuration a PDB to arriving packets
of the traffic conditioners. For example, if the EF PHB
[RFC2598] and a strict policer of rate R are associated with the
foo PDB, then the first part of characterizing the foo PDB is to
write the relationship between the arriving target packets and the
departing foo traffic aggregate. This would be formulated as the
rate of the emerging foo traffic aggregate being less than or equal
to the smaller of R and the arrival rate of the target group of pack-
ets and additional temporal characteristics of the packets (e.g.,
burst) would be specified as desired. Thus, there is a "loss rate"
that results to the original target group from sending too much
traffic or the traffic with the wrong temporal characteristics that
should be entirely preventable (or controllable) by the upstream
sender conforming to the traffic conditioning associated with the
PDB specification. A PDB might also apply traffic conditioning
at egress at a DS boundary. This would be treated similarly to
the ingress characteristics (the authors may develop more text on
this in the future, but it does not materially affect the ideas pre-
sented in this document.) In section 4.3, we will revisit this dis-
cussion for PHB groups.
This aspect of "who is in control" of the loss (or demotion) rate 4.1.1 Crossing the DS edge: the effects of rules on the target group
helps to clearly delineate the first part of characterizing packet
performance of a PDB from the second part. Further, the relation-
ship of the traffic aggregate to the arriving target packet group can
usually be expressed more simply that the traffic aggregate's tran-
sit attributes and depends on different elements. The second part
Nichols and Carpenter Expires: December, 2000 [page 7 ] This effect is quantified by the relationship of the emerging traffic
aggregate to the entering target group. That relationship can depend
on the arriving traffic pattern as well as the configuration of the
traffic conditioners. For example, if the EF PHB [RFC2598] and a strict
policer of rate R are associated with the foo PDB, then the first
part of characterizing the foo PDB is to write the relationship between
the arriving target packets and the departing foo traffic aggregate.
In this case, "the rate of the emerging foo traffic aggregate is less
than or equal to the smaller of R and the arrival rate of the target
group of packets" and additional temporal characteristics of the packets
(e.g., burst) may be specified as desired. Thus, there is a "loss
rate" on the arriving target group that results from sending too much
traffic or the traffic with the wrong temporal characteristics. This
loss rate should be entirely preventable (or controllable) by the
upstream sender conforming to the traffic conditioning associated
with the PDB specification.
is illustrated in figure 3 as the quantifiable metrics that can be The issue of "who is in control" of the loss (or demotion) rate helps
used to characterize the transit of any packet of a particular traffic to clearly delineate this component of PDB performance from that
aggregate between any two edges of the DS domain boundary associated with transiting the domain. The latter is completely under
shown in figure 3, including those indicated with arrows. Note control of the operator of the DS domain and the former is used to
that the DS domain boundary runs through the DS boundary rout- ensure that the entering traffic aggregate is following the rules to
ers since the traffic aggregate is generally formed in the boundary which the operator has provisioned the network. Further, the effects of
router before the packets are queued and scheduled for output. (In the enforcement of edge rules on the target group can usually be
most cases, this distinction is expected to be important.) expressed more simply than the traffic aggregate's transit attributes.
Figure 3: Range of applicability of attributes of a traffic aggregate A PDB may also apply traffic conditioning at DS domain egress. The
associated with a PDB effect of this conditioning on the overall PDB attributes would be
treated similarly to the ingress characteristics (the authors may
develop more text on this in the future, but it does not materially
affect the ideas presented in this document.)
The traffic aggregate associated with a PDB is formed by the 4.1.2 Crossing the DS domain: transit effects
application of rules, through classification and traffic condition-
ing, to packets arriving at the DS boundary. Packets that conform
to the rules are marked with a DSCP that maps to a particular
PHB within a domain. DSCPs should not mutate in the interior of
a DS domain as there are no rules being applied. If it is necessary
to reapply the kind of rules that could result in remarking, there
should probably be a DS domain boundary at that point; an inte-
rior one that can have "lighter weight" rules. Thus, if measuring
attributes between locations as indicated in figure 3, the DSCP at
the egress side can be assumed to have held throughout the
domain.
Though a DS domain may be as small as a single node, more The second component of PDB performance is the metrics that characterize
complex topologies are expected to be the norm, thus the PDB the transit of a packet of the PDB's traffic aggregate between any
definition must hold as its traffic aggregate is split and merged on two edges of the DS domain boundary shown in figure 3. Note that the
the interior links of a DS domain. Packet flow in a network is not DS domain boundary runs through the DS boundary routers since the
part of the PDB definition; the application of rules as packets traffic aggregate is generally formed in the boundary router before
enter the DS domain and the consistent PHB through the DS the packets are queued and scheduled for output. (In most cases, this
domain must suffice. A PDB's definition does not have to hold distinction is expected to be important.)
for arbitrary topologies of networks, but the limits on the range of
applicability for a specific PDB must be clearly specified.
In general, though, a PDB operates between N ingress points and -------------
M egress points at the DS domain boundary. Even in the degener- | |
ate case where N=M=1, PDB attributes are more complex than -----X |
the definition of PHB attributes since the concatenation of the | |
behavior of intermediate nodes affects the former. A complex | DS |
case with N and M both greater than one involves splits and | domain X----
merges in the traffic path and is non-trivial to analyze. Analytic, | |
simulation, and experimental work will all be necessary to under- -----X |
stand even the simplest PDBs. | |
-------------
4.2 Constructing PDBs Figure 3: Range of applicability of attributes of a traffic
aggregate associated with a PDB (is between the points
marked "X")
A DS domain is configured to meet the network operator's traffic DSCPs should not mutate in the interior of a DS domain as there are
engineering goals for the domain independently of the perfor- no "rules" being applied to the traffic. If it is necessary to reapply
mance goals for a particular flow of a traffic aggregate. Once the the kind of rules that could result in remarking, there should be
interior routers are configured for the number of distinct traffic a DS domain boundary at that point, though such an "interior" boundary
aggregates that the network will handle, each PDB's allocation at can have "lighter weight" rules. Thus, when measuring attributes between
the edge comes from meeting the desired performance goals for locations as indicated in figure 3, the DSCP at the egress side can
be assumed to have held throughout the domain.
Nichols and Carpenter Expires: December, 2000 [page 8 ] Though a DS domain may be as small as a single node, more complex
topologies are expected to be the norm, thus the PDB definition must
hold as its traffic aggregate is split and merged on the interior links
of a DS domain. Packet flow in a network is not part of the PDB
definition; the application of rules as packets enter the DS domain and
the consistent PHB through the DS domain must suffice. A PDB's
definition does not have to hold for arbitrary topologies of networks,
but the limits on the range of applicability for a specific PDB must be
clearly specified.
the PDB's traffic aggretae subject to that configuration of link In general, a PDB operates between N ingress points and M egress points
schedulers and bandwidth. The rules at the edge may be altered at the DS domain boundary. Even in the degenerate case where N=M=1,
by provisioning or admission control but the decision about PDB attributes are more complex than the definition of PHB attributes
which PDB to use and how to apply the rules comes from match- since the concatenation of the behavior of intermediate nodes affects
ing performance to goals. the former. A complex case with N and M both greater than one involves
splits and merges in the traffic path and is non-trivial to analyze.
Analytic, simulation, and experimental work will all be necessary
to understand even the simplest PDBs.
For example, consider the diffserv domain of figure 3. A PDB 4.2 Constructing PDBs
with an attribute of an explicit bound on loss must have rules at
the edge to ensure that on the average no more packets are admit-
ted than can emerge. Though, queueing internal to the network
may result in a difference between input and output traffic over
some timescales, the averaging timescale should not exceed what
might be expected for reasonably sized buffering inside the net-
work. Thus if bursts are allowed to arrive into the interior of the
network, there must be enough capacity to ensure that losses
don't exceed the bound. Note that explicit bounds on the loss
level can be particularly difficult as the exact way in which pack-
ets merge inside the network affects the burstiness of the PDB's
traffic aggregate and hence, loss.
PHBs give explicit expressions of the treatment a traffic aggre- A DS domain is configured to meet the network operator's traffic
gate can expect at each hop. For a PDB, this behavior must apply engineering goals for the domain independently of the performance goals
to merging and diverging traffic aggregates, thus characterizing a for a particular flow of a traffic aggregate. Once the interior routers
PDB requires exploring what happens to a PHB under aggrega- are configured for the number of distinct traffic aggregates that
tion. Rules must be recursively applied to result in a known the network will handle, each PDB's allocation at the edge comes from
behavior. As an example, since maximum burst sizes grow with meeting the desired performance goals for the PDB's traffic aggregate
the number of microflows or aggregate flows merged, a PDB subject to that configuration of packet schedulers and bandwidth
specification must address this. A clear advantage of constructing capacity. The rules at the edge may be altered by provisioning or
behaviors that aggregate is the ease of concatenating PDBs so that admission control but the decision about which PDB to use and how to
the associated traffi aggregate has known attributes that span inte- apply the rules comes from matching performance to goals.
rior DS domains and, eventually, farther. For example, in figure 1
assume that we have configured the foo PDB on the interior DS
domains of AS2. Then traffic aggregates associated with the foo
PDB in each interior DS domain of AS2 can be merged at the
shaded interior boundary routers. Using the same (or fewer) rules
as were applied to create the traffic aggregates at the entrance to
AS2, there should be confidence that the attributes of the foo
PDB can continue to be used to quantify by the expected behav-
ior. Explicit expressions of what happens to the behavior under
aggregation, possibly parameterized by node in-degrees or net-
work diameters are necessary to determine what to do at the inter-
nal aggregation points. One approach might be to completely
reapply the edge rules at these points. Another might employ
some limited rate-based remarking only.
Multiple PDBs might use the same PHB. In the specification of a For example, consider the DS domain of figure 3. A PDB with an explicit
PDB, there might be a list of PHBs and their required configura- bound on loss must have rules at the edge to ensure that on the average
tion, all of which would result in the same characteristics. In no more packets are admitted than can emerge. Though, queueing internal
operation, though, it is expected that a single domain will use a to the network may result in a difference between input and output
single PHB to implement a particular PDB. A single PHB might traffic over some timescales, the averaging timescale should not exceed
beselected within a domain by a list of DSCPs. Multiple PDBs what might be expected for reasonably sized buffering inside the
might use the same PHB in which case the transit performance of network. Thus if bursts are allowed to arrive into the interior of the
traffic aggregates of these PDBs will, of necessity, be the same. network, there must be enough capacity to ensure that losses don't
exceed the bound. Note that explicit bounds on the loss level can be
particularly difficult as the exact way in which packets merge inside
the network affects the burstiness of the PDB's traffic aggregate and
hence, loss.
Nichols and Carpenter Expires: December, 2000 [page 9 ] PHBs give explicit expressions of the treatment a traffic aggregate
can expect at each hop. For a PDB, this behavior must apply to merging
and diverging traffic aggregates, thus characterizing a PDB requires
understanding what happens to a PHB under aggregation. 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 traffic
aggregate streams merged, a PDB specification must address this. A
clear advantage of constructing behaviors that aggregate is the ease
of concatenating PDBs so that the associated traffic aggregate has
known attributes that span interior DS domains and, eventually, farther.
For example, in figure 1 assume that we have configured the foo PDB
on the interior DS domains of AS2. Then traffic aggregates associated
with the foo PDB in each interior DS domain of AS2 can be merged at
the shaded interior boundary routers. Using the same (or fewer) rules
as were applied to create the traffic aggregates at the entrance to
AS2, there should be confidence that the attributes of the foo PDB
can continue to be used to quantify by the expected behavior. Explicit
expressions of what happens to the behavior under aggregation, possibly
parameterized by node in-degrees or network diameters are necessary
to determine what to do at the internal aggregation points. One approach
might be to completely reapply the edge rules at these points; another
might employ some limited rate-based remarking only.
Yet, the particular characteristics that the PDB designer wishes to Multiple PDBs may use the same PHB. The specification of a PDB can
claim as attributes may vary, so two PDBs that use the same PHB contain a list of PHBs and their required configuration, all of which
might not be specified with the same list of attributes. would result in the same PDB. In operation, it is expected that a
single domain will use a single PHB to implement a particular PDB,
though different domains may select different PHBs. Recall that in
the diffserv definition [RFC2474], a single PHB might be selected
within a domain by a list of DSCPs. Multiple PDBs might use the same
PHB in which case the transit performance of traffic aggregates of
these PDBs will, of necessity, be the same. Yet, the particular
characteristics that the PDB designer wishes to claim as attributes may
vary, so two PDBs that use the same PHB might not be specified with the
same list of attributes.
The specification of the transit expectations of behavior aggre- The specification of the transit expectations of PDBs across domains
gates across domains both assists in the deployment of QoS both assists in the deployment of QoS within a DS domain and helps
within a DS domain and helps enable the composition of end-to- enable the composition of end-to-end, cross-domain services to proceed
end, cross-domain services to proceed. by making it possible to hide details of a domain's internals while
exposing characteristics necessary for QoS.
4.3 PDBs using PHB Groups 4.3 PDBs using PHB Groups
When a set of related PDBs are defined using a PHB group, they The use of PHB groups to construct PDBs can be done in several ways.
should be defined in the same document. This would be particu- A single PHB member of a PHB group might be used to construct a single
larly appropriate if the application of the edge rules that create the PDB. For example, a PDB could be defined using just one of the Class
traffic aggregates associated with each PDB had some relation- Selector Compliant PHBs [RFC2474]. The edge rules for that PDB and
ships and interdependencies, as one would expect for the AF PHB the required configuration of the particular PHB would be defined
group [RFC2597]. Characterizing the traffic conditioning effects in such a way that there was no dependence or relationship with the
should then be described for these PDBs together. The transit manner in which other PHBs of the group are used or, indeed, whether
attributes will depend on the PHB associated with the PDB and they are used in that DS domain. In this case, the reasonable approach
will not be the same for all PHBs in the group, thus each should would be to specify this PDB alone in a document which expressly called
have a clearly separate treatment, though there may be some out the conditions and configuration of the Class Selector PHB required.
parameterized interrelationship between the attributes of each of
these PDBs.
For example, if the traffic conditioner described in RFC 2698 is
used to mark arriving packets for three different AF1x PHBs, then
the most reasonable approach is to define and quantify the rela-
tionship between the arriving packets and the emerging traffic
aggregates as they relate to one another. The transit characteris-
tics of packets of each separate AF1x traffic aggregate should be
described separately.
A set of PDBs might be defined using Class Selector Compliant A single PDB can be constructed using more than one PHB from the same
PHBs [RFC2474] in such a way that the edge rules that create the PHB group. For example, the traffic conditioner described in RFC 2698
traffic aggregates are not related, but the transit performance of might be used to mark a particular entering traffic aggregate for
each traffic aggregate has some parametric relationship to the the one of the three AF1x PHBs [RFC2597] while the transit performance
other. If it makes sense to specify them in the same document, of the resultant PDB is specified, statistically, across all the packets
then the author(s) should do so. marked with one of those PHBs.
4.4 Forwarding path vs. control plane A set of related PDBs might be defined using a PHB group. In this case,
the related PDBs should be defined in the same document. This is
appropriate when the application of the edge rules that create the
traffic aggregates associated with each PDB have some relationships and
interdependencies such that the traffic conditioning effects for these
PDBs should be described and characterized together. The transit
attributes will depend on the PHB associated with the PDB and will not
be the same for all PHBs in the group, though there may be some
parameterized interrelationship between the attributes of each of these
PDBs. In this case, each PDB should have a clearly separate description
of its transit attributes (delineated in a separate subsection) within
the document. For example, the traffic conditioner described in RFC
2698 might be used to mark arriving packets for three different AF1x
PHBs, each of which is to be treated as a separate traffic aggregate
in terms of transit properties. Then a single document could be used
to define and quantify the relationship between the arriving packets
and the emerging traffic aggregates as they relate to one another.
The transit characteristics of packets of each separate AF1x traffic
aggregate should be described separately within the document.
A PDB's associated PHB and edge traffic conditioners are in the Another way in which a PHB group might be used to create one PDB per
packet forwarding path and operate at line rates while the config- PHB might have decoupled edge rules, but some relationship between
uration of the DS domain edge to enforce rules on who gets to use the PHBs of the group. For example, a set of PDBs might be defined
the PDB and how the PDB should behave temporally is done by using Class Selector Compliant PHBs [RFC2474] in such a way that the
the control plane on a very different time scale. For example, con- edge rules that create the traffic aggregates are not related, but
figuration of PHBs might only occur monthly or quarterly. The the transit performance of each traffic aggregate has some parametric
edge rules might be reconfigured at a few regular intervals during relationship to the the other. If it makes sense to specify them in
the day or might happen in response to signalling decisions thou- the same document, then the author(s) should do so.
sands of times a day. Even at the shortest time scale, control plane
actions are not expected to happen per-packet. Much of the con-
trol plane work is still evolving and is outside the charter of the
Diffserv WG. We note that this is quite appropriate since the
Nichols and Carpenter Expires: December, 2000 [page 10 ] 4.4 Forwarding path vs. control plane
manner in which the configuration is done and the time scale at A PDB's associated PHB and edge traffic conditioners are in the packet
which it is done should not affect the PDB attributes. forwarding path and operate at line rates while the configuration
of the DS domain edge to enforce rules on who gets to use the PDB
and how the PDB should behave temporally is done by the control plane
on a very different time scale. For example, reconfiguration of PHBs
might occur monthly, quarterly, or only when the network is upgraded.
The edge rules might be reconfigured at a few regular intervals during
the day or might happen in response to signalling decisions thousands
of times a day. Even at the shortest time scale, control plane actions
are not expected to happen per-packet. Much of the control plane work
is still evolving and is outside the charter of the Diffserv WG. We
note that this is quite appropriate since the manner in which the
configuration is done and the time scale at which it is done should
not affect the PDB attributes.
5.0 Format for Specification of Diffserv Per-Domain Behaviors 5 Format for Specification of Diffserv Per-Domain Behaviors
PDBs arise from a particular relationship between edge and inte- PDBs arise from a particular relationship between edge and interior
rior (which may be parameterized). The quantifiable characteris- (which may be parameterized). The quantifiable characteristics of
tics of a PDB must be independent of whether the network edge is a PDB must be independent of whether the network edge is configured
configured statically or dynamically. The particular configuration statically or dynamically. The particular configuration of traffic
of traffic conditioners at the DS domain edge is critical to how a conditioners at the DS domain edge is critical to how a PDB performs,
PDB performs, but the act(s) of configuring the edge is a control but the act(s) of configuring the edge is a control plane action which
plane action which can be separated from the specification of the can be separated from the specification of the PDB.
PDB.
The following sections must be present in any specification of a The following sections must be present in any specification of a
Differentiated Services PDB. Of necessity, their length and con- Differentiated Services PDB. Of necessity, their length and content will
tent will vary greatly. vary greatly.
5.1 Applicability Statement 5.1 Applicability Statement
All PDB specs must have an applicability statement that outlines All PDB specs must have an applicability statement that outlines the
the intended use of this PDB and the limits to its use. intended use of this PDB and the limits to its use.
5.2 Rules 5.2 Rules
This section describes the rules to be followed in the creation of This section describes the rules to be followed in the creation of
this PDB. Rules should be distinguished with "may", "must" and this PDB. Rules should be distinguished with "may", "must" and "should."
"should." The rules specify the edge behavior and configuration The rules specify the edge behavior and configuration, including
and the PHB (or PHBs) to be used and any additional require- whatever traffic conditioning is required, and the PHB (or PHBs) to be
ments on their configuration beyond that contained in RFCs. used and any additional requirements on their configuration beyond that
contained in RFCs. Note that traffic conditioning may include
classification, admission control, marking, traffic shaping, and
policing.
5.3 Attributes 5.3 Attributes
A PDB's attributes tell how it behaves under ideal conditions if A PDB's attributes tell how it behaves under ideal conditions if
configured in a specified manner (where the specification may be configured in a specified manner (where the specification may be
parameterized). These might include drop rate, throughput, delay parameterized). These might include drop rate, throughput, delay bounds
bounds measured over some time period. They may be absolute measured over some time period. They may be bounds, statistical bounds,
bounds or statistical bounds (e.g., "90% of all packets measured or percentiles (e.g., "90% of all packets measured over intervals of at
over intervals of at least 5 minutes will cross the DS domain in least 5 minutes will cross the DS domain in less than 5 milliseconds").
less than 5 milliseconds"). A wide variety of characteristics may A wide variety of characteristics may be used but they must be explicit,
be used but they must be explicit, quantifiable, and defensible. quantifiable, and defensible. Where particular statistics are used, the
Where particular statistics are used, the document must be precise document must be precise about how they are to be measured and about how
about how they are to be measured and about how the characteris- the characteristics were derived.
tics were derived.
Advice to a network operator would be to use these as guidelines Advice to a network operator would be to use these as guidelines in
in creating a service specification rather than use them directly. creating a service specification rather than use them directly. For
For example, a "loss-free" PDB would probably not be sold as example, a "loss-free" PDB would probably not be sold as such, but
such, but rather as a service with a very small packet loss proba- rather as a service with a very small packet loss probability.
bility.
5.4 Parameters 5.4 Parameters
Nichols and Carpenter Expires: December, 2000 [page 11 ] The definition and characteristics of a PDB may be parameterized by
network-specific features; for example, maximum number of hops, minimum
The definition and characteristics of a PDB may be parameterized bandwidth, total number of entry/exit points of the PDB to/from the
by network-specific features; for example, maximum number of diffserv network, maximum transit delay of network elements, minimum
hops, minimum bandwidth, total number of entry/exit points of buffer size available for the PDB at a network node, etc.
the PDB to/from the diffserv network, maximum transit delay of
network elements, minimum buffer size available for the PDB at
a network node, etc.
5.5 Assumptions 5.5 Assumptions
In most cases, PDBs will be specified assuming lossless links, no In most cases, PDBs will be specified assuming lossless links, no link
link failures, and relatively stable routing. This is reasonable failures, and relatively stable routing. This is reasonable since
since otherwise it would be very difficult to quantify behavior. otherwise it would be very difficult to quantify behavior and this
However, these assumptions must be clearly stated. Some PDBs is the operating conditions for which most operators strive. However,
may be developed without these assumptions, e.g., for high loss these assumptions must be clearly stated. Since PDBs with specific
rate links, and these must also be made explicit. If additional bandwidth parameters require that bandwidth to be available, the
restrictions, e.g., route pinning, are required, these must be stated. assumptions to be stated may include standby capacity. Some PDBs may be
specifically targeted for cases where these assumptions do not hold,
e.g., for high loss rate links, and such targeting must also be made
explicit. If additional restrictions, especially specific traffic
engineering measures, are required, these must be stated.
Further, if any assumptions are made about the allocation of Further, if any assumptions are made about the allocation of resources
resources within a diffserv network in the creation of the PDB, within a diffserv network in the creation of the PDB, these must be
these must be made explicit. made explicit.
5.6 Example Uses 5.6 Example Uses
A PDB specification must give example uses to motivate the A PDB specification must give example uses to motivate the understanding
understanding of ways in which a diffserv network could make of ways in which a diffserv network could make use of the PDB although
use of the PDB although these are not expected to be detailed. For these are not expected to be detailed. For example, "A bulk handling
example, "A bulk handling behavior aggregate may be used for PDB may be used for all packets which should not take any resources
all packets which should not take any resources from the network from the network unless they would otherwise go unused. This might
unless they would otherwise go unused. This might be useful for be useful for Netnews traffic or for traffic rejected from some other
Netnews traffic or for traffic rejected from some other PDB due to PDB due to violation of that PDB's rules."
violation of that PDB's rules."
5.7 Environmental Concerns (media, topology, etc.) 5.7 Environmental Concerns (media, topology, etc.)
Note that it is not necessary for a provider to expose which PDB Note that it is not necessary for a provider to expose which PDB (if
(if a commonly defined one) is being used nor is it necessary for a a commonly defined one) is being used nor is it necessary for a provider
provider to specify a service by the PDB's attributes. For exam- to specify a service by the PDB's attributes. For example, a service
ple, a service provider might use a PDB with a "no queueing loss" provider might use a PDB with a "no queueing loss" characteristic
characteristic in order to specify a "very low loss" service. in order to specify a "very low loss" service.
This section is to inject realism into the characteristics described This section is to inject realism into the characteristics described
above. Detail the assumptions made there and what constraints above. Detail the assumptions made there and what constraints that
that puts on topology or type of physical media or allocation. puts on topology or type of physical media or allocation.
6.0 PDB Attributes
Attributes are associated with each PDB: measurable, quantifi-
able, characteristics which can be used to describe what will hap-
pen to packets using that PDB as they cross the domain. These
expectations result directly from the application of edge rules
enforced during the creation of the PDB's traffic aggregate and/or
its entry into the domain and the forwarding treatment (PHB)
packets of that traffic aggregate get inside the domain. There are
Nichols and Carpenter Expires: December, 2000 [page 12 ] 6 On PDB Attributes
many ways in which traffic might be distributed, but creating a As discussed in section 4, measurable, quantifiable attributes
quantifiable, realizable service across the DS domain will limit associated with each PDB can be used to describe what will happen to
the scenarios which can occur. There is a clear correlation packets using that PDB as they cross the domain. In itrole as a building
between the strictness of the rules and the quality of the charac- block for the construction of interdomain quality-of-service, a PDB
terization of the PDB. specification should provide the answer to the question: Under what
conditions can we join the output of this domain to another under the
same rules and expectations? Although there are many ways in which
traffic might be distributed, creating quantifiable, realizable PDBs
that can be concatenated into multi-domain services limits the realistic
scenarios. A PDB's attributes with a clear statement of the conditions
under which the attributes hold is critical to the composition of multi-
domain services.
There are two ways to characterize PDBs with respect to time. There is a clear correlation between the strictness of the rules and the
First are its properties over "long" time periods, or average quality of the PDB's attributes. As indicated earlier, numerical bounds
behaviors. In a PDB spec, these would be the rates or throughput are likely to be statistical or expressed as a percentile. Parameters
seen over some specified time period. In addition, there are prop- expressed as strict bounds will require very precise mathematical
erties of "short" time behavior, usually expressed as the allowable analysis, whereas those expressed statistically can to some extent
burstiness in an aggregate. The short time behavior is important is rely on experiment. Section 7 gives the example of a PDB without strict
understanding the buffering (and associated loss characteristics) rules and concurrent work on a PDB with strict rules and attributes
and in quantifying how packets using the PDB aggregate, either is also in front of the WG [VW]. This section gives some general
within a DS domain or at the boundaries. For short-time behavior, considerations for characterizing PDB attributes.
we are interested primarily in two things: 1) how many back-to-
back packets of the PDB's traffic aggregate will we see at any
point (this would be metered as a burst) and 2) how large a burst
of packets of this PDB's traffic aggregate can appear in a queue at
once (gives queue overflow and loss). If other PDBs are using the
same PHB within the domain, that must be taken into account.
Put simply, a PDB specification should provide the answer to the There are two ways to characterize PDBs with respect to time. First
question: Under what conditions can we join the output of this are properties over "long" time periods, or average behaviors. A PDB
domain to another under the same rules and expectations? specification should report these as the rates or throughput seen
over some specified time period. In addition, there are properties
of "short" time behavior, usually expressed as the allowable burstiness
in a traffic aggregate. The short time behavior is important in under-
standing buffering requirements (and associated loss characteristics)
and for metering and conditioning considerations at DS boundaries. For
short-time behavior, we are interested primarily in two things: 1) how
many back-to-back packets of the PDB's traffic aggregate will we see at
any point (this would be metered as a burst) and 2) how large a burst of
packets of this PDB's traffic aggregate can appear in a queue at once
(gives queue overflow and loss). If other PDBs are using the same PHB
within the domain, that must be taken into account.
6.1 Considerations in specifying long-term or average PDB attributes 6.1 Considerations in specifying long-term or average PDB attributes
To make this more concrete, consider the DS domain of figure 4 To characterize the average or long-term behavior for the foo PDB we
for which we will define the foo PDB. To characterize the average must explore a number of questions, for instance: Can the DS domain
or long-term behavior that must be specified we must explore a handle the average foo traffic flow? Is that answer topology-dependent
number of questions, for instance: Can the DS domain handle the or are there some specific assumptions on routing which must hold
average foo traffic flow? Is that answer topology-dependent or are for the foo PDB to preserve its "adequately provisioned" capability?
there some specific assumptions on routing which must hold for In other words, if the topology of D changes suddenly, will the foo
the foo PDB to preserve its "adequately provisioned" capability? PDB's attributes change? Will its loss rate dramatically increase?
In other words, if the topology of D changes suddenly, will the
foo PDB's attributes change? Will its loss rate dramatically ____X________X_________X___________ /
increase? / \ L |
A<---->X X<----->| E
| | |
| D | \
Z<---->X |
| |
\___________________________________/
X X
Figure 4: ISP and DS domain D connected in a ring and connected Figure 4: ISP and DS domain D connected in a ring and connected
to DS domain E to DS domain E
Let figure 4 be an ISP ringing the U.S. with links of bandwidth B Let domain D in figure 4 be an ISP ringing the U.S. with links of
and with N tails to various metropolitan areas. If the link between bandwidth B and with N tails to various metropolitan areas. Inside D, if
the node connected to A and the node connected to Z goes down, the link between the node connected to A and the node connected to Z
all the foo traffic aggregate between the two nodes must transit goes down, all the foo traffic aggregate between the two nodes must
the entire ring: Would the bounded behavior of the foo PDB transit the entire ring: Would the bounded behavior of the foo PDB
change? If this outage results in some node of the ring now hav- change? If this outage results in some node of the ring now having a
ing a larger arrival rate to one of its links than the capacity of the larger arrival rate to one of its links than the capacity of the link
link for foo's traffic aggregate, clearly the loss rate would change for foo's traffic aggregate, clearly the loss rate would change
dramatically. In that case, there were topological assumptions dramatically. In this case, topological assumptions were made about the
made about the path of the traffic from A to Z that affected the path of the traffic from A to Z that affected the characteristics of the
characteristics of the foo PDB. Once these no longer hold, any foo PDB. If these topological assumptions no longer hold, the loss rate
of packets of the foo traffic aggregate transiting the domain could
Nichols and Carpenter Expires: December, 2000 [page 13 ] change; for example, a characteristic such as "loss rate no greater
than 1% over any interval larger than 10 minutes." A PDB specification
assumptions on the loss rate of packets of the foo traffic aggregate should spell out the assumptions made on preserving the attributes.
transiting the domain would change; for example, a characteristic
such as "loss rate no greater than 1% over any interval larger than
10 minutes" would no longer hold. A PDB specification should
spell out the assumptions made on preserving the attributes.
6.2 Considerations in specifying short-term or bursty PDB attributes 6.2 Considerations in specifying short-term or bursty PDB attributes
Next, consider the short-time behavior of the traffic aggregate Next, consider the short-time behavior of the traffic aggregate
associated with a PDB, specifically whether permitting the maxi- associated with a PDB, specifically whether permitting the maximum
mum bursts to add in the same manner as the average rates will bursts to add in the same manner as the average rates will lead to
lead to properties that aggregate or under what rules this will lead properties that aggregate or under what rules this will lead to
to properties that aggregate. In our example, if domain D allows properties that aggregate. In our example, if domain D allows each of
each of the uplinks to burst p packets into the foo traffic aggre- the uplinks to burst p packets into the foo traffic aggregate, the
gate, the bursts could accumulate as they transit the ring. Packets bursts could accumulate as they transit the ring. Packets headed for
headed for link L can come from both directions of the ring and link L can come from both directions of the ring and back-to-back
back-to-back packets from foo's traffic aggregate can arrive at the packets from foo's traffic aggregate can arrive at the same time. If the
same time. If the bandwidth of link L is the same as the links of bandwidth of link L is the same as the links of the ring, this probably
the ring, this probably does not present a buffering problem. If does not present a buffering problem. If there are two input links that
there are two input links that can send packets to queue for L, at can send packets to queue for L, at worst, two packets can arrive
worst, two packets can arrive simultaneously for L. If the band- simultaneously for L. If the bandwidth of link L equals or exceeds
width of link L equals or exceeds twice B, the packets won't twice B, the packets won't accumulate. Further, if p is limited to
accumulate. Further, if p is limited to one, and the bandwidth of L one, and the bandwidth of L exceeds the rate of arrival (over the
exceeds the rate of arrival (over the longer term) of foo packets longer term) of foo packets (required for bounding the loss) then
(required for bounding the loss) then the queue of foo packets for the queue of foo packets for link L will empty before new packets
link L will empty before new packets arrive. If the bandwidth of L arrive. If the bandwidth of L is equal to B, one foo packet must queue
is equal to B, one foo packet must queue while the other is trans- while the other is transmitted. This would result in N x p back-to-
mitted. This would result in N x p back-to-back packets of this back packets of this traffic aggregate arriving over L during the
traffic aggregate arriving over L during the same time scale as the same time scale as the bursts of p were permitted on the uplinks.
bursts of p were permitted on the uplinks. Thus, configuring the Thus, configuring the PDB so that link L can handle the sum of the
PDB so that link L can handle the sum of the rates that ingress to rates that ingress to the foo PDB doesn't guarantee that L can handle
the foo PDB doesn't guarantee that L can handle the sum of the N the sum of the N bursts into the foo PDB.
bursts into the foo PDB.
If the bandwidth of L is less than B, then the link must buffer If the bandwidth of L is less than B, then the link must buffer
Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less than
than the full bandwidth L, this number is larger. For probabilistic the full bandwidth L, this number is larger. For probabilistic bounds, a
bounds, a smaller buffer might do if the probability of exceeding smaller buffer might do if the probability of exceeding it can be
it can be bounded. bounded.
More generally, for router indegree of d, bursts of foo packets
might arrive on each input. Then, in the absence of any additional
rules, it is possible that dxpx(# of uplinks) back-to-back foo
packets can be sent across link L to domain E. Thus the DS
domain E must permit these much larger bursts into the foo PDB
than domain D permits on the N uplinks or else the foo traffic
aggregate must be made to conform to the rules for entering E
(e.g., by shaping).
What conditions should be imposed on a PDB and on the associ-
ated PHB in order to ensure PDBs can be concatenated, as across
the interior DS domains of figure 1? Edge rules for constructing a
PDB that has certain attributes across a DS domain should apply
Nichols and Carpenter Expires: December, 2000 [page 14 ]
independently of the origin of the packets. With reference to the
example we've been exploring, the rules for the PDB's traffic
aggregate entering link L into domain E should not depend on the
number of uplinks into domain D.
6.3 Example
In this example, we will make the above more concrete. We
assume that only the foo PDB is using its associated traffic aggre-
gate and we use "foo agggregate" interchangeably with "the traf-
fic aggregate associated with the PDB foo." We also use "foo
packets" interchangeably with "the packets marked for the PHB
associated with PDB foo."
Assume the topology of figure 4 and that all the uplinks have the
same bandwidth B and link L has bandwidth L which is less than
or equal to B. The foo traffic aggregates from the N uplinks each
have average rate R and are destined to cross L. If only a fraction
a of link L is allocated to foo, then R =axL/N fits the average rate
constraint. If each of the N flows can have a burst of p packets
and half the flows transit the ring in each direction, then 2xp
packets can arrive at the foo queue for link L in the time it took to
transmit p packets on the ring, p/B. Although the link scheduler
for link L might allow the burst of packets to be transmitted at the
line rate L, after the burst allotment has been exceeded, the queue
should be expected to clear at only rate axL. Then consider the
packets that can accumulate. It takes 2xp/(axL) to clear the queue
of the foo packets. In that time, bursts of p packets from the other
uplinks can arrive from the ring, so the packets do not even have
to be back-to-back. Even if the packets do not arrive back-to-
back, but are spaced by less time than it takes to clear the queue
of foo packets, either the required buffer size can become large or
the burst size of foo packets entering E across L becomes large
and is a function of N, the number of uplinks of domain D.
Let L = 1.5 Mbps, B = 45 Mbps, a = 1/3, N=10, p = 3. Suppose
that the bursts from two streams of foo packets arrive at the queue
for link L very close together. Even if 3 of the packets are cleared
at the line rate of 1.5 Mbps, there will be 3 packets remaining to
be serviced at a 500 kbps rate. In the time allocated to send one of
these, 9 packets can arrive on each of the inputs from the ring. If
any non-zero number of these 18 packets are foo packets, the
queue size will not reduce. If two more bursts (6 of the 18 pack-
ets) arrive, the queue increases to 8 packets. Thus, it's possible to
build up quite a large queue, one likely to exceed the buffer allo-
cated for foo. The rate bound means that each of the uplinks will
be idle for the time to send three packets at 50 kbps, possibly by
policing at the ring egress, and thus the queue would eventually
decrease and clear, however, the queue at link L can still be very
large. PDBs where the intention is to permit loss should be con-
structed so as to provide a probabilistic bound for the queue size
to exceed a reasonable buffer size of one or two bandwidth-delay
products. Alternatively or additionally, rules can be used that
Nichols and Carpenter Expires: December, 2000 [page 15 ] More generally, for router indegree of d, bursts of foo packets might
arrive on each input. Then, in the absence of any additional rules,
it is possible that dxpx(# of uplinks) back-to-back foo packets can
be sent across link L to domain E. Thus the DS domain E must permit
these much larger bursts into the foo PDB than domain D permits on
the N uplinks or else the foo traffic aggregate must be made to conform
to the rules for entering E (e.g., by shaping).
bound the amount of foo packets that queue by limiting the burst What conditions should be imposed on a PDB and on the associated PHB
size at the ingress uplinks to one packet, resulting in a maximum in order to ensure PDBs can be concatenated, as across the interior
queue of N or 10 or to impose additional rules on the PDB. One DS domains of figure 1? Edge rules for constructing a PDB that has
approach is to limit the domain over which the PDB applies so certain attributes across a DS domain should apply independently of
that interior boundaries are placed at merge points (or between the origin of the packets. With reference to the example we've been
every M merge points) so that a shaping edge conditioner can be exploring, the rules for the PDB's traffic aggregate entering link
reapplied. Another approach is to use a PHB defined such that it L into domain E should not depend on the number of uplinks into domain
strictly limits the burstiness. D.
6.4 Remarks 6.3 Remarks
This section has been provided to provide some motivational food This section has been provided to provide some motivational food for
for thought for PDB specifiers. It is by no means an exhaustive thought for PDB specifiers. It is by no means an exhaustive catalog
catalog of possible PDB attributes or what kind of analysis must of possible PDB attributes or what kind of analysis must be done.
be done. We expect this to be an interesting and evolutionary part We expect this to be an interesting and evolutionary part of the work
of the work of understanding and deploying differentiated ser- of understanding and deploying differentiated services in the Internet.
vices in the Internet. There is a potential for much interesting There is a potential for much interesting research work. However,
research work. However, in submitting a PDB specification to the in submitting a PDB specification to the Diffserv WG, a PDB must also
Diffserv WG, a PDB must also meet the test of being useful and meet the test of being useful and relevant by a deployment experience,
relevant. described in section 8.
7.0 Reference Per-Domain Behaviors 7 A Reference Per-Domain Behavior
The intent of this section is to define one or a few "reference" The intent of this section is to define as a reference a Best Effort
PDBss; certainly a Best Effort PDB and perhaps others. This sec- PDB, a PDB that has little in the way of rules or expectations.
tion is very preliminary at this time and meant to be the starting
point for discussion rather than its end. These are PDBs that have
little in the way of rules or expectations.
7.1 Best Effort Behavior PDB 7.1 Best Effort Behavior PDB
7.1.1 Applicability 7.1.1 Applicability
A Best Effort (BE) PDB is for sending "normal internet traffic" A Best Effort (BE) PDB is for sending "normal internet traffic" across
across a diffserv network. That is, the definition and use of this a diffserv network. That is, the definition and use of this PDB is
PDB is to preserve, to a reasonable extent, the pre-diffserv deliv- to preserve, to a reasonable extent, the pre-diffserv delivery
ery expectation for packets in a diffserv network that do not expectation for packets in a diffserv network that do not require any
require any special differentiation. special differentiation.
7.1.2 Rules 7.1.2 Rules
There are no rules governing rate and bursts of packets beyond There are no rules governing rate and bursts of packets beyond the
the limits imposed by the ingress link. The network edge ensures limits imposed by the ingress link. The network edge ensures that
that packets using the PDB are marked for the Default PHB (as packets using the PDB are marked for the Default PHB (as defined in
defined in [RFC2474]). Interior network nodes use the Default [RFC2474]), but no other traffic conditioning is required. Interior
PHB on these packets. network nodes use the Default PHB on these packets.
7.1.3 Attributes of this PDB 7.1.3 Attributes of this PDB
"As much as possible as soon as possible". "As much as possible as soon as possible".
Packets of this PDB will not be completely starved and when Packets of this PDB will not be completely starved and when resources
resources are available (i.e., not required by packets from any are available (i.e., not required by packets from any other traffic
aggregate), network elements should be configured to permit packets
Nichols and Carpenter Expires: December, 2000 [page 16 ] of this PDB to consume them.
other traffic aggregate), network elements should be configured
to permit packets of this PDB to consume them.
Although some network operators may bound the delay and loss Although some network operators may bound the delay and loss rate for
rate for this aggregate given knowledge about their network, these this PDB given knowledge about their network, these attributes are
attributes are not part of the definition. not part of the definition.
7.1.4 Parameters 7.1.4 Parameters
None. None.
7.1.5 Assumptions 7.1.5 Assumptions
.A properly functioning network, i.e. packets may be delivered A properly functioning network, i.e. packets may be delivered from
from any ingress to any egress. any ingress to any egress.
7.1.6 Example uses 7.1.6 Example uses
1. For the normal Internet traffic connection of an organization. 1. For the normal Internet traffic connection of an organization.
2. For the "non-critical" Internet traffic of an organization. 2. For the "non-critical" Internet traffic of an organization.
3. For standard domestic consumer connections 3. For standard domestic consumer connections
7.2 Bulk Handling Behavior PDB 8 Procedure for submitting PDB specifications to Diffserv WG
7.2.1 Applicability
A Bulk Handling (BH) PDB is for sending extremely non-critical
traffic across a diffserv network. There should be an expectation
that these packets may be delayed or dropped when other traffic is
present.
7.2.2 Rules
There are no rules governing rate and bursts of packets beyond
the limits imposed by the ingress link. The network edge ensures
that packets using this PDB are marked for either a CS or an AF
PHB. Interior network nodes must have this PHB configured so
that its packets may be starved when other traffic is present. For
example, using the PHB for Class Selector 1 (DSCP=001000), all
routers in the domain could be configured to queue such traffic
behind all other traffic, subject to tail drop.
7.2.3 Attributes of the BH PHB
Packets are forwarded when there are idle resources.
7.2.4 Parameters
None.
7.2.5 Assumptions
Nichols and Carpenter Expires: December, 2000 [page 17 ]
A properly functioning network.
7.2.6 Example uses
1. For Netnews and other "bulk mail" of the Internet.
2. For "downgraded" traffic from some other PDB.
8.0 Procedure for submitting PDB
specifications to Diffserv WG
1. Following the guidelines of this document, write a draft and 1. Following the guidelines of this document, write a draft and submit
submit it as an Internet Draft and bring it to the attention of the it as an Internet Draft and bring it to the attention of the WG mailing
WG mailing list. list. Either as an appendix to the draft, or in a separate document,
provide details of deployment experience with measured results on
a network of non-trivial size carrying realistic traffic.
2. Initial discussion on the WG should focus primarily on the 2. Initial discussion on the WG should focus primarily on the merits
merits of the a PDB, though comments and questions on the of the a PDB, though comments and questions on the claimed attributes
claimed attributes are reasonable. This is in line with our desire to are reasonable. This is in line with our desire to put relevance before
put relevance before academic interest in spending WG time on academic interest in spending WG time on PDBs. Academically interesting
PDBs. Academically interesting PDBs are encouraged, but not PDBs are encouraged, but not for submission to the diffserv WG.
for submission to the diffserv WG.
3. Once consensus has been reached on a version of a draft that it 3. Once consensus has been reached on a version of a draft that it
is a useful PDB and that the characteristics "appear" to be correct is a useful PDB and that the characteristics "appear" to be correct
(i.e., not egregiously wrong) that version of the draft goes to a (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 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 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- review. The exact timing of the deadline will be set on a case-by-case
case basis by the co-chairs to reflect the complexity of the task basis by the co-chairs to reflect the complexity of the task and other
and other constraints (IETF meetings, major holidays) but is constraints (IETF meetings, major holidays) but is expected to be in the
expected to be in the 4-8 week range. During that time, the panel 4-8 week range. During that time, the panel may correspond with the
may correspond with the authors directly (cc'ing the WG co- authors directly (cc'ing the WG co-chairs) to get clarifications. This
chairs) to get clarifications. This process should result in a revised process should result in a revised draft and/or a report to the WG from
draft and/or a report to the WG from the panel that either the panel that either endorses or disputes the claimed characteristics.
endorses or disputes the claimed characteristics.
4. If/when endorsed by the panel, that draft goes to WG last call. 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 If not endorsed, the author(s) can give a itemized response to the
panel's report and ask for a WG Last Call. panel's report and ask for a WG Last Call.
5. If/when passes Last Call, goes to ADs for publication as a WG 5. If/when passes Last Call, goes to ADs for publication as a WG
Informational RFC in our "PDB series". Informational RFC in our "PDB series".
9.0 Acknowledgements 9 Acknowledgements
The ideas in this document have been heavily influenced by the
Diffserv WG and, in particular, by discussions with Van Jacob-
son, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner,
Randy Bush, Frank Kastenholz, Aaron Falk, and a host of other
people who should be acknowledged for their useful input but not
be held accountable for our mangling of it. Grenville Armitage
coined "per domain behavior (PDB)" though some have sug-
Nichols and Carpenter Expires: December, 2000 [page 18 ]
gested similar terms prior to that. The ideas in this document have been heavily influenced by the Diffserv
WG and, in particular, by discussions with Van Jacobson, Dave Clark,
Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz,
Aaron Falk, and a host of other people who should be acknowledged
for their useful input but not be held accountable for our mangling
of it. Grenville Armitage coined "per domain behavior (PDB)" though
some have suggested similar terms prior to that.
References References
[RFC2474] RFC 2474, "Definition of the Differentiated Services [RFC2474] RFC 2474, "Definition of the Differentiated Services Field
Field (DS Field) in the IPv4 and IPv6 Headers", (DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, F.
K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/ Baker, D. Black, www.ietf.org/rfc/rfc2474.txt
rfc/rfc2474.txt
[RFC2475] RFC 2475, "An Architecture for Differentiated Ser- [RFC2475] RFC 2475, "An Architecture for Differentiated Services",
vices", S. Blake, D. Black, M.Carl- S. Blake, D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss,
son,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/ www.ietf.org/rfc/rfc2475.txt
rfc2475.txt
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J.
Baker, J. Heinanen, W. Weiss, J. Wroclawski, Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt
www.ietf.org/rfc/rfc2597.txt
[RFC2598] RFC 2598, "An Expedited Forwarding PHB", [RFC2598] RFC 2598, "An Expedited Forwarding PHB", V.Jacobson,
V.Jacobson, K.Nichols, K.Poduri, www.ietf.org/rfc/ K.Nichols, K.Poduri, www.ietf.org/ rfc/rfc2598.txt
rfc2598.txt
[RFC2698] RFC 2698, "A Two Rate Three Color Marker", J. [RFC2698] RFC 2698, "A Two Rate Three Color Marker", J. Heinanen, R.
Heinanen, R. Guerin. www.ietf.org/rfc/rfc2698.txt Guerin. www.ietf.org/rfc/ rfc2698.txt
[MODEL] "A Conceptual Model for Diffserv Routers", draft-ietf- [MODEL] "An Informal Management Model for Diffserv Routers",
diffserv-model-02.txt, Bernet et. al. draft-ietf-diffserv-model-04.txt, Y. Bernet, S. Blake, D. Grossman,
A. Smith
[MIB] "Management Information Base for the Differentiated [MIB] "Management Information Base for the Differentiated Services
Services Architecture", draft-ietf-diffserv-mib-01.txt, Architecture", draft-ietf-diffserv- mib-01.txt, F. Baker, K. Chan,
Baker et. al. A. Smith
[VW] "The 'Virtual Wire' Behavior Aggregate", draft-ietf-diff- [VW] "The 'Virtual Wire' Per-Domain Behavior",
serv-ba-vw-00.txt, V. Jacobson, K. Nichols, and K. draft-ietf-diffserv-pdb-vw-00.txt, V. Jacobson, K. Nichols, and
Poduri (being modified to reflect new terminology). K. Poduri.
Authors' Addresses Authors' Addresses
Kathleen Nichols Brian E. Carpenter Kathleen Nichols Brian Carpenter
Packet Design, Inc. IBM Packet Design, Inc. IBM
66 Willow Place c/o iCAIR 66 Willow Place c/o iCAIR
Menlo Park, CA 94025 Suite 150 Menlo Park, CA 94025 Suite 150
1890 Maple Avenue USA 1890 Maple Avenue
Evanston, IL 60201 Evanston, IL 60201
USA USA
email: email: nichols@packetdesign.com email: brian@icair.org
nichols@packetdesign.com brian@icair.org
 End of changes. 130 change blocks. 
834 lines changed or deleted 769 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/