draft-ietf-diffserv-pdb-def-03.txt   rfc3086.txt 
Internet Engineering Task Force K. Nichols
Differentiated Services Working Group Packet Design
Internet Draft B. Carpenter
Expires in July, 2001 IBM
draft-ietf-diffserv-pdb-def-03 January, 2001
Definition of Differentiated Services Per Domain Behaviors Network Working Group K. Nichols
and Rules for their Specification Request for Comments: 3086 Packet Design
Category: Informational B. Carpenter
IBM
April 2001
<draft-ietf-diffserv-pdb-def-03> Definition of Differentiated Services Per Domain Behaviors
and Rules for their Specification
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, memo is unlimited.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
This document is a product of the Diffserv working group. Comments
on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>. The list of current Internet-Drafts can be accessed
at www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Shadow Directories can be accessed at www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The differentiated services framework enables quality-of-service The differentiated services framework enables quality-of-service
provisioning within a network domain by applying rules at the edges provisioning within a network domain by applying rules at the edges
to create traffic aggregates and coupling each of these with a to create traffic aggregates and coupling each of these with a
specific forwarding path treatment in the domain through use of specific forwarding path treatment in the domain through use of a
a codepoint in the IP header [RFC2474]. The diffserv WG has defined codepoint in the IP header. The diffserv WG has defined the general
the general architecture for differentiated services [RFC2475] architecture for differentiated services and has focused on the
and has focused on the forwarding path behavior required in routers, forwarding path behavior required in routers, known as "per-hop
known as "per-hop forwarding behaviors" (or PHBs) [RFC2474, RFC2597, forwarding behaviors" (or PHBs). The WG has also discussed
and RFC2598]. The WG has also discussed functionality required functionality required at diffserv (DS) domain edges to select
at diffserv (DS) domain edges to select (classifiers) and condition (classifiers) and condition (e.g., policing and shaping) traffic
(e.g., policing and shaping) traffic according to the rules [RFC2475, according to the rules. Short-term changes in the QoS goals for a DS
MODEL, MIB]. Short-term changes in the QoS goals for a DS domain domain are implemented by changing only the configuration of these
are implemented by changing only the configuration of these edge edge behaviors without necessarily reconfiguring the behavior of
behaviors without necessarily reconfiguring the behavior of interior interior network nodes.
network nodes.
The next step is to formulate examples of how forwarding path components The next step is to formulate examples of how forwarding path
(PHBs, classifiers, and traffic conditioners) can be used to compose components (PHBs, classifiers, and traffic conditioners) can be used
traffic aggregates whose packets experience specific forwarding to compose traffic aggregates whose packets experience specific
characteristics as they transit a differentiated services domain. forwarding characteristics as they transit a differentiated services
The WG has decided to use the term per-domain behavior, or PDB, domain. The WG has decided to use the term per-domain behavior, or
to describe the behavior experienced by a particular set of packets PDB, to describe the behavior experienced by a particular set of
as they cross a DS domain. A PDB is characterized by specific metrics packets as they cross a DS domain. A PDB is characterized by
that quantify the treatment a set of packets with a particular specific metrics that quantify the treatment a set of packets with a
DSCP (or set of DSCPs) will receive as it crosses a DS domain. particular DSCP (or set of DSCPs) will receive as it crosses a DS
A PDB specifies a fowarding path treatment for a traffic aggregate domain. A PDB specifies a forwarding path treatment for a traffic
and, due to the role that particular choices of edge and PHB aggregate and, due to the role that particular choices of edge and
configuration play in its resulting attributes, it is where the PHB configuration play in its resulting attributes, it is where the
forwarding path and the control plane interact. The measurable forwarding path and the control plane interact. The measurable
parameters of a PDB should be suitable for use in Service Level parameters of a PDB should be suitable for use in Service Level
Specifications at the network edge. Specifications at the network edge.
This document defines and discusses Per-Domain Behaviors in detail This document defines and discusses Per-Domain Behaviors in detail
and lays out the format and required content for contributions and lays out the format and required content for contributions to the
to the Diffserv WG on PDBs and the procedure that will be applied Diffserv WG on PDBs and the procedure that will be applied for
for individual PDB specifications to advance as WG products. This individual PDB specifications to advance as WG products. This format
format is specified to expedite working group review of PDB submissions. is specified to expedite working group review of PDB submissions.
A pdf version of this document is available at: Table of Contents
www.packetdesign.com/ietf/diffserv/pdb_def.pdf.
Contents 1. Introduction ................................................ 2
1. Introduction ................................................2 2. Definitions ................................................. 4
2. Definitions .................................................3 3. The Value of Defining Edge-to-Edge Behavior ................. 5
3. The Value of Defining Edge-to-Edge Behavior .................4 4. Understanding PDBs .......................................... 7
4. Understanding PDBs ..........................................5 5. Format for Specification of Diffserv Per-Domain Behaviors ...13
5. Format for Specification of Diffserv Per-Domain Behaviors ..10 6. On PDB Attributes ...........................................16
6. On PDB Attributes ..........................................11 7. A Reference Per-Domain Behavior .............................19
7. A Reference Per-Domain Behavior ............................13 8. Guidelines for Advancing PDB Specifications .................21
8. Guidelines for Advancing PDB Specifications ................15 9. Security Considerations .....................................22
9. Security Considerations ....................................15 10. Acknowledgements ............................................22
10. Acknowledgements ...........................................15 References ..................................................22
Authors' Addresses ..........................................23
Full Copyright Statement ....................................24
1 Introduction 1 Introduction
Differentiated Services allows an approach to IP Quality of Service Differentiated Services allows an approach to IP Quality of Service
that is modular, incrementally deployable, and scalable while that is modular, incrementally deployable, and scalable while
introducing minimal per-node complexity [RFC2475]. From the end user's introducing minimal per-node complexity [RFC2475]. From the end
point of view, QoS should be supported end-to-end between any pair of user's point of view, QoS should be supported end-to-end between any
hosts. However, this goal is not immediately attainable. It will pair of hosts. However, this goal is not immediately attainable. It
require interdomain QoS support, and many untaken steps remain will require interdomain QoS support, and many untaken steps remain
on the road to achieving this. One essential step, the evolution on the road to achieving this. One essential step, the evolution of
of the business models for interdomain QoS, will necessarily develop the business models for interdomain QoS, will necessarily develop
outside of the IETF. A goal of the diffserv WG is to provide the outside of the IETF. A goal of the diffserv WG is to provide the
firm technical foundation that allows these business models to firm technical foundation that allows these business models to
develop. The first major step will be to support edge-to-edge or develop. The first major step will be to support edge-to-edge or
intradomain QoS between the ingress and egress of a single network, intradomain QoS between the ingress and egress of a single network,
i.e. a DS Domain in the terminology of RFC 2474. The intention i.e., a DS Domain in the terminology of RFC 2474. The intention is
is that this edge-to-edge QoS should be composable, in a purely that this edge-to-edge QoS should be composable, in a purely
technical sense, to a quantifiable QoS across a DS Region composed technical sense, to a quantifiable QoS across a DS Region composed of
of multiple DS domains. multiple DS domains.
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 RFCs per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474,
2474, 2597 and 2598 give a rich toolbox for differential packet 2597 and 2598 give a rich toolbox for differential packet handling by
handling by individual boxes. The general architectural model for individual boxes. The general architectural model for diffserv has
diffserv has been documented in RFC 2475. An informal router model been documented in RFC 2475. An informal router model [MODEL]
[MODEL] describes a model of traffic conditioning and other forwarding describes a model of traffic conditioning and other forwarding
behaviors. However, technical issues remain in moving "beyond the behaviors. However, technical issues remain in moving "beyond the
box" to intradomain QoS models. box" to intradomain QoS models.
The ultimate goal of creating scalable end-to-end QoS in the Internet The ultimate goal of creating scalable end-to-end QoS in the Internet
requires that we can identify and quantify behavior for a group requires that we can identify and quantify behavior for a group of
of packets that is preserved when they are aggregated with other packets that is preserved when they are aggregated with other packets
packets as they traverse the Internet. The step of specifying forwarding as they traverse the Internet. The step of specifying forwarding
path attributes on a per-domain basis for a set of packets distinguished path attributes on a per-domain basis for a set of packets
only by the mark in the DS field of individual packets is critical distinguished only by the mark in the DS field of individual packets
in the evolution of Diffserv QoS and should provide the technical is critical in the evolution of Diffserv QoS and should provide the
input that will aid in the construction of business models. This technical input that will aid in the construction of business models.
document defines and specifies the term "Per-Domain Behavior" or This document defines and specifies the term "Per-Domain Behavior" or
PDB to describe QoS attributes across a DS domain. PDB to describe QoS attributes across a DS domain.
Diffserv classification and traffic conditioning are applied to Diffserv classification and traffic conditioning are applied to
packets arriving at the boundary of a DS domain to impose restrictions packets arriving at the boundary of a DS domain to impose
on the composition of the resultant traffic aggregates, as distinguished restrictions on the composition of the resultant traffic aggregates,
by the DSCP marking , inside the domain. The classifiers and traffic as distinguished by the DSCP marking , inside the domain. The
conditioners are set to reflect the policy and traffic goals for classifiers and traffic conditioners are set to reflect the policy
that domain and may be specified in a TCA (Traffic Conditioning and traffic goals for that domain and may be specified in a TCA
Agreement). Once packets have crossed the DS boundary, adherence (Traffic Conditioning Agreement). Once packets have crossed the DS
to diffserv principles makes it possible to group packets solely boundary, adherence to diffserv principles makes it possible to group
according to the behavior they receive at each hop (as selected packets solely according to the behavior they receive at each hop (as
by the DSCP). This approach has well-known scaling advantages, selected by the DSCP). This approach has well-known scaling
both in the forwarding path and in the control plane. Less well advantages, both in the forwarding path and in the control plane.
recognized is that these scaling properties only result if the Less well recognized is that these scaling properties only result if
per-hop behavior definition gives rise to a particular type of the per-hop behavior definition gives rise to a particular type of
invariance under aggregation. Since the per-hop behavior must be invariance under aggregation. Since the per-hop behavior must be
equivalent for every node in the domain, while the set of packets equivalent for every node in the domain, while the set of packets
marked for that PHB may be different at every node, PHBs should marked for that PHB may be different at every node, PHBs should be
be defined such that their characteristics do not depend on the defined such that their characteristics do not depend on the traffic
traffic volume of the associated BA on a router's ingress link volume of the associated BA on a router's ingress link nor on a
nor on a particular path through the DS domain taken by the packets. particular path through the DS domain taken by the packets.
Specifically, different streams of traffic that belong to the same Specifically, different streams of traffic that belong to the same
traffic aggregate merge and split as they traverse the network. traffic aggregate merge and split as they traverse the network. If
If the properties of a PDB using a particular PHB hold regardless the properties of a PDB using a particular PHB hold regardless of how
of how the temporal characteristics of the marked traffic aggregate the temporal characteristics of the marked traffic aggregate change
change as it traverses the domain, then that PDB scales. (Clearly as it traverses the domain, then that PDB scales. (Clearly this
this assumes that numerical parameters such as bandwidth allocated assumes that numerical parameters such as bandwidth allocated to the
to the particular PDB may be different at different points in the particular PDB may be different at different points in the network,
network, and may be adjusted dynamically as traffic volume varies.) and may be adjusted dynamically as traffic volume varies.) If there
If there are limits to where the properties hold, that translates are limits to where the properties hold, that translates to a limit
to a limit on the size or topology of a DS domain that can use on the size or topology of a DS domain that can use that PDB.
that PDB. Although useful single-link DS domains might exist, PDBs Although useful single-link DS domains might exist, PDBs that are
that are invariant with network size or that have simple relationships invariant with network size or that have simple relationships with
with network size and whose properties can be recovered by reapplying network size and whose properties can be recovered by reapplying
rules (that is, forming another diffserv boundary or edge to re-enforce rules (that is, forming another diffserv boundary or edge to re-
the rules for the traffic aggregate) are needed for building scalable enforce the rules for the traffic aggregate) are needed for building
end-to-end quality of service. scalable end-to-end quality of service.
There is a clear distinction between the definition of a Per-Domain There is a clear distinction between the definition of a Per-Domain
Behavior in a DS domain and a service that might be specified in Behavior in a DS domain and a service that might be specified in a
a Service Level Agreement. The PDB definition is a technical building Service Level Agreement. The PDB definition is a technical building
block that permits the coupling of classifiers, traffic conditioners, block that permits the coupling of classifiers, traffic conditioners,
specific PHBs, and particular configurations with a resulting set specific PHBs, and particular configurations with a resulting set of
of specific observable attributes which may be characterized in specific observable attributes which may be characterized in a
a variety of ways. These definitions are intended to be useful variety of ways. These definitions are intended to be useful tools
tools in configuring DS domains, but the PDB (or PDBs) used by in configuring DS domains, but the PDB (or PDBs) used by a provider
a provider is not expected to be visible to customers any more is not expected to be visible to customers any more than the specific
than the specific PHBs employed in the provider's network would PHBs employed in the provider's network would be. Network providers
be. Network providers are expected to select their own measures are expected to select their own measures to make customer-visible in
to make customer-visible in contracts and these may be stated quite contracts and these may be stated quite differently from the
differently from the technical attributes specified in a PDB definition, technical attributes specified in a PDB definition, though the
though the configuration of a PDB might be taken from a Service configuration of a PDB might be taken from a Service Level
Level Specification (SLS). Similarly, specific PDBs are intended Specification (SLS). Similarly, specific PDBs are intended as tools
as tools for ISPs to construct differentiated services offerings; for ISPs to construct differentiated services offerings; each may
each may choose different sets of tools, or even develop their choose different sets of tools, or even develop their own, in order
own, in order to achieve particular externally observable metrics. to achieve particular externally observable metrics. Nevertheless,
Nevertheless, the measurable parameters of a PDB are expected to the measurable parameters of a PDB are expected to be among the
be among the parameters cited directly or indirectly in the Service parameters cited directly or indirectly in the Service Level
Level Specification component of a corresponding SLA. Specification component of a corresponding SLA.
This document defines Differentiated Services Per-Domain Behaviors This document defines Differentiated Services Per-Domain Behaviors
and specifies the format that must be used for submissions of particular and specifies the format that must be used for submissions of
PDBs to the Diffserv WG. particular PDBs to the Diffserv WG.
2 Definitions 2 Definitions
The following definitions are stated in RFCs 2474 and 2475 and are The following definitions are stated in RFCs 2474 and 2475 and are
repeated here for easy reference: repeated here for easy reference:
" 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. crossing a link in a particular direction.
" Differentiated Services Domain: a contiguous portion of the Internet " Differentiated Services Domain: a contiguous portion of the
over which a consistent set of differentiated services policies Internet over which a consistent set of differentiated services
are administered in a coordinated fashion. A differentiated services policies are administered in a coordinated fashion. A
domain can represent different administrative domains or autonomous differentiated services domain can represent different
systems, different trust regions, different network technologies administrative domains or autonomous systems, different trust
(e.g., cell/frame), hosts and routers, etc. Also DS domain. regions, different network technologies (e.g., cell/frame), hosts
and routers, etc. Also DS domain.
" Differentiated Services Boundary: the edge of a DS domain, where " Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed. classifiers and traffic conditioners are likely to be deployed. A
A differentiated services boundary can be further sub-divided into differentiated services boundary can be further sub-divided into
ingress and egress nodes, where the ingress/egress nodes are the ingress and egress nodes, where the ingress/egress nodes are the
downstream/upstream nodes of a boundary link in a given traffic downstream/upstream nodes of a boundary link in a given traffic
direction. A differentiated services boundary typically is found direction. A differentiated services boundary typically is found
at the ingress to the first-hop differentiated services-compliant at the ingress to the first-hop differentiated services-compliant
router (or network node) that a host's packets traverse, or at router (or network node) that a host's packets traverse, or at the
the egress of the last-hop differentiated services-compliant router egress of the last-hop differentiated services-compliant router or
or network node that packets traverse before arriving at a host. network node that packets traverse before arriving at a host. This
This is sometimes referred to as the boundary at a leaf router. is sometimes referred to as the boundary at a leaf router. A
A differentiated services boundary may be co-located with a host, differentiated services boundary may be co-located with a host,
subject to local policy. Also DS boundary. subject to local policy. Also DS boundary.
To these we add: To these we add:
" 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 maps to the same PHB, usually in a DS domain or some subset of a DS
a DS domain. A traffic aggregate marked for the foo PHB is referred domain. A traffic aggregate marked for the foo PHB is referred to
to as the "foo traffic aggregate" or "foo aggregate" interchangeably. as the "foo traffic aggregate" or "foo aggregate" interchangeably.
This generalizes the concept of Behavior Aggregate from a link This generalizes the concept of Behavior Aggregate from a link to a
to a network. network.
" Per-Domain Behavior: the expected treatment that an identifiable " Per-Domain Behavior: the expected treatment that an identifiable or
or target group of packets will receive from "edge-to-edge" of target group of packets will receive from "edge-to-edge" of a DS
a DS domain. (Also PDB.) A particular PHB (or, if applicable, list domain. (Also PDB.) A particular PHB (or, if applicable, list of
of PHBs) and traffic conditioning requirements are associated with PHBs) and traffic conditioning requirements are associated with
each PDB. each PDB.
" A Service Level Specfication (SLS) is a set of parameters and " A Service Level Specification (SLS) is a set of parameters and
their values which together define the service offered to a traffic their values which together define the service offered to a traffic
stream by a DS domain. It is expected to include specific values stream by a DS domain. It is expected to include specific values
or bounds for PDB parameters. or bounds for PDB parameters.
3 The Value of Defining Edge-to-Edge Behavior 3 The Value of Defining Edge-to-Edge Behavior
As defined in section 2, a PDB describes the edge-to-edge behavior As defined in section 2, a PDB describes the edge-to-edge behavior
across a DS domain's "cloud." Specification of the transit expectations across a DS domain's "cloud." Specification of the transit
of packets matching a target for a particular diffserv behavior expectations of packets matching a target for a particular diffserv
across a DS domain will both assist in the deployment of single-domain behavior across a DS domain will both assist in the deployment of
QoS and will help enable the composition of end-to-end, cross-domain single-domain QoS and will help enable the composition of end-to-end,
services. Networks of DS domains can be connected to create end-to-end cross-domain services. Networks of DS domains can be connected to
services by building on the PDB characteristics without regard create end-to-end services by building on the PDB characteristics
to the particular PHBs used. This level of abstraction makes it without regard to the particular PHBs used. This level of
easier to compose cross-domain services as well as making it possible abstraction makes it easier to compose cross-domain services as well
to hide details of a network's internals while exposing information as making it possible to hide details of a network's internals while
sufficient to enable QoS. exposing information sufficient to enable QoS.
Today's Internet is composed of multiple independently administered Today's Internet is composed of multiple independently administered
domains or Autonomous Systems (ASs), represented by the "clouds" domains or Autonomous Systems (ASs), represented by the "clouds" in
in figure 1. To deploy ubiquitous end-to-end quality of service figure 1. To deploy ubiquitous end-to-end quality of service in the
in the Internet, business models must evolve that include issues Internet, business models must evolve that include issues of charging
of charging and reporting that are not in scope for the IETF. In and reporting that are not in scope for the IETF. In the meantime,
the meantime, there are many possible uses of quality of service there are many possible uses of quality of service within an AS and
within an AS and the IETF can address the technical issues in creating the IETF can address the technical issues in creating an intradomain
an intradomain QoS within a Differentiated Services framework. QoS within a Differentiated Services framework. In fact, this
In fact, this approach is quite amenable to incremental deployment approach is quite amenable to incremental deployment strategies.
strategies.
Where DS domains are independently administered, the evolution of Where DS domains are independently administered, the evolution of the
the necessary business agreements and future signaling arrangements necessary business agreements and future signaling arrangements will
will take some time, thus, early deployments will be within a single take some time, thus, early deployments will be within a single
administrative domain. Putting aside the business issues, the same administrative domain. Putting aside the business issues, the same
technical issues that arise in interconnecting DS domains with technical issues that arise in interconnecting DS domains with
homogeneous administration will arise in interconnecting the autonomous homogeneous administration will arise in interconnecting the
systems (ASs) of the Internet. autonomous systems (ASs) of the Internet.
---------------------------------------- ----------------------------------------
| AS2 | | AS2 |
| | | |
------- | ------------ ------------ | ------- | ------------ ------------ |
| AS1 |------|-----X | | | | | AS1 |------|-----X | | | |
------- | | | Y | | ------- ------- | | | Y | | -------
| | | /| X----|--------| AS3 | | | | /| X----|--------| AS3 |
| | | / | | | ------- | | | / | | | -------
| | | / ------------ | | | | / ------------ |
| | Y | | | | Y | |
| | | \ ------------ | | | | \ ------------ |
------- | | | \ | | | ------- | | | \ | | |
| AS4 |------|-----X | \| | | | AS4 |------|-----X | \| | |
------- | | | Y X----|------ ------- | | | Y X----|------
| | | | | | | | | | | |
| ------------ ------------ | | ------------ ------------ |
| | | |
| | | |
---------------------------------------- ----------------------------------------
Figure 1: Interconnection of ASs and DS Domains Figure 1: Interconnection of ASs and DS Domains
A single AS (e.g., AS2 in figure 1) may be composed of subnetworks 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. and, as the definition allows, these can be separate DS domains. An
An AS might have multiple DS domains for a number of reasons, most AS might have multiple DS domains for a number of reasons, most
notable being to follow topological and/or technological boundaries notable being to follow topological and/or technological boundaries
and to separate the allocation of resources. If we confine ourselves and to separate the allocation of resources. If we confine ourselves
to the DS boundaries between these "interior" DS domains, we avoid to the DS boundaries between these "interior" DS domains, we avoid
the non-technical problems of setting up a service and can address the non-technical problems of setting up a service and can address
the issues of creating characterizable PDBs. the issues of creating characterizable PDBs.
The incentive structure for differentiated services is based on The incentive structure for differentiated services is based on
upstream domains ensuring their traffic conforms to the Traffic upstream domains ensuring their traffic conforms to the Traffic
Conditioning Agreements (TCAs) with downstream domains and downstream Conditioning Agreements (TCAs) with downstream domains and downstream
domains enforcing that TCA, thus metrics associated with PDBs can domains enforcing that TCA, thus metrics associated with PDBs can be
be sensibly computed. The rectangular boxes in figure 1 represent sensibly computed. The letters "X" and "Y" in figure 1 represent the
the DS boundary routers containing traffic conditioners that ensure DS boundary routers containing traffic conditioners that ensure and
and enforce conformance (e.g., shapers and policers). Although enforce conformance (e.g., shapers and policers). Although policers
policers and shapers are expected at the DS boundaries of ASs (dark and shapers are expected at the DS boundaries of ASs (the "X" boxes),
rectangles), they might appear anywhere, or nowhere, inside the they might appear anywhere, or nowhere, inside the AS. Specifically,
AS. Specifically, the boxes at the DS boundaries internal to the the boxes at the DS boundaries internal to the AS (the "Y" boxes) may
AS (shaded rectangles) may or may not condition traffic. Technical or may not condition traffic. Technical guidelines for the placement
guidelines for the placement and configuration of DS boundaries and configuration of DS boundaries should derive from the attributes
should derive from the attributes of a particular PDB under aggregation of a particular PDB under aggregation and multiple hops.
and multiple hops.
This definition of PDB continues the separation of forwarding path This definition of PDB continues the separation of forwarding path
and control plane decribed in RFC 2474. The forwarding path and control plane described in RFC 2474. The forwarding path
characteristics are addressed by considering how the behavior at every characteristics are addressed by considering how the behavior at
hop of a packet's path is affected by the merging and branching of every hop of a packet's path is affected by the merging and branching
traffic aggregates through multiple hops. Per-hop behaviors in nodes are of traffic aggregates through multiple hops. Per-hop behaviors in
configured infrequently, representing a change in network nodes are configured infrequently, representing a change in network
infrastructure. More frequent quality-of-service changes come from infrastructure. More frequent quality-of-service changes come from
employing control plane functions in the configuration of the DS employing control plane functions in the configuration of the DS
boundaries. A PDB provides a link between the DS domain level at which boundaries. A PDB provides a link between the DS domain level at
control is exercised to form traffic aggregates with quality-of-service which control is exercised to form traffic aggregates with quality-
goals across the domain and the per-hop and per-link treatments packets of-service goals across the domain and the per-hop and per-link
receive that results in meeting the quality-of-service goals. treatments packets receive that results in meeting the quality-of-
service goals.
4 Understanding PDBs 4 Understanding PDBs
4.1 Defining PDBs 4.1 Defining PDBs
RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate RFCs 2474 and 2475 define a Differentiated Services Behavior
as "a collection of packets with the same DS codepoint crossing Aggregate as "a collection of packets with the same DS codepoint
a link in a particular direction" and further state that packets crossing a link in a particular direction" and further state that
with the same DSCP get the same per-hop forwarding treatment (or packets with the same DSCP get the same per-hop forwarding treatment
PHB) everywhere inside a single DS domain. Note that even if multiple (or PHB) everywhere inside a single DS domain. Note that even if
DSCPs map to the same PHB, this must hold for each DSCP individually. multiple DSCPs map to the same PHB, this must hold for each DSCP
In section 2 of this document, we introduced a more general definition individually. In section 2 of this document, we introduced a more
of a traffic aggregate in the diffserv sense so that we might easily general definition of a traffic aggregate in the diffserv sense so
refer to the packets which are mapped to the same PHB everywhere that we might easily refer to the packets which are mapped to the
within a DS domain. Section 2 also presented a short definition same PHB everywhere within a DS domain. Section 2 also presented a
of PDBs which we expand upon in this section: short definition of PDBs which we expand upon in this section:
Per-Domain Behavior: the expected treatment that an identifiable Per-Domain Behavior: the expected treatment that an identifiable or
or target group of packets will receive from "edge to edge" of target group of packets will receive from "edge to edge" of a DS
a DS domain. A particular PHB (or, if applicable, list of PHBs) domain. A particular PHB (or, if applicable, list of PHBs) and
and traffic conditioning requirements are associated with each traffic conditioning requirements are associated with each PDB.
PDB.
Each PDB has measurable, quantifiable, attributes that can be used Each PDB has measurable, quantifiable, attributes that can be used to
to describe what happens to its packets as they enter and cross describe what happens to its packets as they enter and cross the DS
the DS domain. These derive from the characteristics of the traffic domain. These derive from the characteristics of the traffic
aggregate that results from application of classification and traffic aggregate that results from application of classification and traffic
conditioning during the entry of packets into the DS domain and conditioning during the entry of packets into the DS domain and the
the forwarding treatment (PHB) the packets get inside the domain, forwarding treatment (PHB) the packets get inside the domain, but can
but can also depend on the entering traffic loads and the domain's also depend on the entering traffic loads and the domain's topology.
topology. PDB attributes may be absolute or statistical and they PDB attributes may be absolute or statistical and they may be
may be parameterized by network properties. For example, a loss parameterized by network properties. For example, a loss attribute
attribute might be expressed as "no more than 0.1% of packets will might be expressed as "no more than 0.1% of packets will be dropped
be dropped when measured over any time period larger than T", a when measured over any time period larger than T", a delay attribute
delay attribute might be expressed as "50% of delivered packets might be expressed as "50% of delivered packets will see less than a
will see less than a delay of d milliseconds, 30% will see a delay delay of d milliseconds, 30% will see a delay less than 2d ms, 20%
less than 2d ms, 20% will see a delay of less than 3d ms." A wide will see a delay of less than 3d ms." A wide range of metrics is
range of metrics is possible. In general they will be expressed possible. In general they will be expressed as bounds or percentiles
as bounds or percentiles rather than as absolute values. rather than as absolute values.
A PDB is applied to a target group of packets arriving at the edge A PDB is applied to a target group of packets arriving at the edge of
of the DS domain. The target group is distinguished from all arriving the DS domain. The target group is distinguished from all arriving
packets by use of packet classifiers [RFC2475] (where the classifier packets by use of packet classifiers [RFC2475] (where the classifier
may be "null"). The action of the PDB on the target group has two may be "null"). The action of the PDB on the target group has two
parts. The first part is the the use of traffic conditioning to parts. The first part is the the use of traffic conditioning to
create a traffic aggregate. During traffic conditioning, conformant create a traffic aggregate. During traffic conditioning, conformant
packets are marked with a DSCP for the PHB associated with the packets are marked with a DSCP for the PHB associated with the PDB
PDB (see figure 2). The second part is the treatment experienced (see figure 2). The second part is the treatment experienced by
by packets from the same traffic aggregate transiting the interior packets from the same traffic aggregate transiting the interior of a
of a DS domain, between and inside of DS domain boundaries. The DS domain, between and inside of DS domain boundaries. The following
following subsections further discuss these two effects on the subsections further discuss these two effects on the target group
target group that arrives at the DS domain boundary. that arrives at the DS domain boundary.
----------- ------------ -------------------- foo ----------- ------------ -------------------- foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets | | |of packets | |& marking (for foo) | aggregate packets | | |of packets | |& marking (for foo) | aggregate
----------- ------------ -------------------- ----------- ------------ --------------------
Figure 2: Relationship of the traffic aggregate associated with Figure 2: Relationship of the traffic aggregate associated
a PDB to arriving packets with a PDB to arriving packets
4.1.1 Crossing the DS edge: the effects of traffic conditioning on the 4.1.1 Crossing the DS edge: the effects of traffic conditioning on the
target group target group
This effect is quantified by the relationship of the emerging traffic This effect is quantified by the relationship of the emerging traffic
aggregate to the entering target group. That relationship can depend aggregate to the entering target group. That relationship can depend
on the arriving traffic pattern as well as the configuration of on the arriving traffic pattern as well as the configuration of the
the traffic conditioners. For example, if the EF PHB [RFC2598] traffic conditioners. For example, if the EF PHB [RFC2598] and a
and a strict policer of rate R are associated with the foo PDB, strict policer of rate R are associated with the foo PDB, then the
then the first part of characterizing the foo PDB is to write the first part of characterizing the foo PDB is to write the relationship
relationship between the arriving target packets and the departing between the arriving target packets and the departing foo traffic
foo traffic aggregate. In this case, "the rate of the emerging aggregate. In this case, "the rate of the emerging foo traffic
foo traffic aggregate is less than or equal to the smaller of R aggregate is less than or equal to the smaller of R and the arrival
and the arrival rate of the target group of packets" and additional rate of the target group of packets" and additional temporal
temporal characteristics of the packets (e.g., burst) may be specified characteristics of the packets (e.g., burst) may be specified as
as desired. Thus, there is a "loss rate" on the arriving target desired. Thus, there is a "loss rate" on the arriving target group
group that results from sending too much traffic or the traffic that results from sending too much traffic or the traffic with the
with the wrong temporal characteristics. This loss rate should wrong temporal characteristics. This loss rate should be entirely
be entirely preventable (or controllable) by the upstream sender preventable (or controllable) by the upstream sender conforming to
conforming to the traffic conditioning associated with the PDB the traffic conditioning associated with the PDB specification.
specification.
The issue of "who is in control" of the loss (or demotion) rate The issue of "who is in control" of the loss (or demotion) rate helps
helps to clearly delineate this component of PDB performance from to clearly delineate this component of PDB performance from that
that associated with transiting the domain. The latter is completely associated with transiting the domain. The latter is completely
under control of the operator of the DS domain and the former is under control of the operator of the DS domain and the former is used
used to ensure that the entering traffic aggregate conforms to to ensure that the entering traffic aggregate conforms to the traffic
the traffic profile to which the operator has provisioned the network. profile to which the operator has provisioned the network. Further,
Further, the effects of traffic conditioning on the target group the effects of traffic conditioning on the target group can usually
can usually be expressed more simply than the effects of transitting be expressed more simply than the effects of transiting the DS domain
the DS domain on the traffic aggregate's traffic profile. on the traffic aggregate's traffic profile.
A PDB may also apply traffic conditioning at DS domain egress. The A PDB may also apply traffic conditioning at DS domain egress. The
effect of this conditioning on the overall PDB attributes would effect of this conditioning on the overall PDB attributes would be
be treated similarly to the ingress characteristics (the authors treated similarly to the ingress characteristics (the authors may
may develop more text on this in the future, but it does not materially develop more text on this in the future, but it does not materially
affect the ideas presented in this document.) affect the ideas presented in this document.)
4.1.2 Crossing the DS domain: transit effects 4.1.2 Crossing the DS domain: transit effects
The second component of PDB performance is the metrics that characterize The second component of PDB performance is the metrics that
the transit of a packet of the PDB's traffic aggregate between characterize the transit of a packet of the PDB's traffic aggregate
any two edges of the DS domain boundary shown in figure 3. Note between any two edges of the DS domain boundary shown in figure 3.
that the DS domain boundary runs through the DS boundary routers Note that the DS domain boundary runs through the DS boundary routers
since the traffic aggregate is generally formed in the boundary since the traffic aggregate is generally formed in the boundary
router before the packets are queued and scheduled for output. router before the packets are queued and scheduled for output. (In
(In most cases, this distinction is expected to be important.) most cases, this distinction is expected to be important.)
DSCPs should not change in the interior of a DS domain as there is no
DSCPs should not change in the interior of a DS domain as there traffic conditioning being applied. If it is necessary to reapply
is no traffic conditioning being applied. If it is necessary to the kind of traffic conditioning that could result in remarking,
reapply the kind of traffic conditioning that could result in remarking, there should be a DS domain boundary at that point, though such an
there should be a DS domain boundary at that point, though such "interior" boundary can have "lighter weight" rules in its TCA.
an "interior" boundary can have "lighter weight" rules in its TCA. Thus, when measuring attributes between locations as indicated in
Thus, when measuring attributes between locations as indicated figure 3, the DSCP at the egress side can be assumed to have held
in figure 3, the DSCP at the egress side can be assumed to have throughout the domain.
held throughout the domain.
------------- -------------
| | | |
-----X | -----X |
| | | |
| DS | | DS |
| domain X---- | domain X----
| | | |
-----X | -----X |
| | | |
------------- -------------
Figure 3: Range of applicability of attributes of a traffic Figure 3: Range of applicability of attributes of a traffic
aggregate associated with a PDB (is between the points aggregate associated with a PDB (is between the
marked "X") points marked "X")
Though a DS domain may be as small as a single node, more complex 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 topologies are expected to be the norm, thus the PDB definition must
must hold as its traffic aggregate is split and merged on the interior 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 links of a DS domain. Packet flow in a network is not part of the
PDB definition; the application of traffic conditioning as packets PDB definition; the application of traffic conditioning as packets
enter the DS domain and the consistent PHB through the DS domain enter the DS domain and the consistent PHB through the DS domain must
must suffice. A PDB's definition does not have to hold for arbitrary suffice. A PDB's definition does not have to hold for arbitrary
topologies of networks, but the limits on the range of applicability topologies of networks, but the limits on the range of applicability
for a specific PDB must be clearly specified. for a specific PDB must be clearly specified.
In general, a PDB operates between N ingress points and M egress In general, a PDB operates between N ingress points and M egress
points at the DS domain boundary. Even in the degenerate case where points at the DS domain boundary. Even in the degenerate case where
N=M=1, PDB attributes are more complex than the definition of PHB N=M=1, PDB attributes are more complex than the definition of PHB
attributes since the concatenation of the behavior of intermediate attributes since the concatenation of the behavior of intermediate
nodes affects the former. A complex case with N and M both greater nodes affects the former. A complex case with N and M both greater
than one involves splits and merges in the traffic path and is than one involves splits and merges in the traffic path and is non-
non-trivial to analyze. Analytic, simulation, and experimental trivial to analyze. Analytic, simulation, and experimental work will
work will all be necessary to understand even the simplest PDBs. all be necessary to understand even the simplest PDBs.
4.2 Constructing PDBs 4.2 Constructing PDBs
A DS domain is configured to meet the network operator's traffic A DS domain is configured to meet the network operator's traffic
engineering goals for the domain independently of the performance engineering goals for the domain independently of the performance
goals for a particular flow of a traffic aggregate. Once the interior goals for a particular flow of a traffic aggregate. Once the
routers are configured for the number of distinct traffic aggregates interior routers are configured for the number of distinct traffic
that the network will handle, each PDB's allocation at the edge aggregates that the network will handle, each PDB's allocation at the
comes from meeting the desired performance goals for the PDB's edge comes from meeting the desired performance goals for the PDB's
traffic aggregate subject to that configuration of packet schedulers traffic aggregate subject to that configuration of packet schedulers
and bandwidth capacity. The configuration of traffic conditioners and bandwidth capacity. The configuration of traffic conditioners at
at the edge may be altered by provisioning or admission control the edge may be altered by provisioning or admission control but the
but the decision about which PDB to use and how to apply classification decision about which PDB to use and how to apply classification and
and traffic conditioning comes from matching performance to goals. traffic conditioning comes from matching performance to goals.
For example, consider the DS domain of figure 3. A PDB with an explicit For example, consider the DS domain of figure 3. A PDB with an
bound on loss must apply traffic conditioning at the boundary to explicit bound on loss must apply traffic conditioning at the
ensure that on the average no more packets are admitted than can boundary to ensure that on the average no more packets are admitted
emerge. Though, queueing internal to the network may result in than can emerge. Though, queueing internal to the network may result
a difference between input and output traffic over some timescales, in a difference between input and output traffic over some
the averaging timescale should not exceed what might be expected timescales, the averaging timescale should not exceed what might be
for reasonably sized buffering inside the network. Thus if bursts expected for reasonably sized buffering inside the network. Thus if
are allowed to arrive into the interior of the network, there must bursts are allowed to arrive into the interior of the network, there
be enough capacity to ensure that losses don't exceed the bound. must be enough capacity to ensure that losses don't exceed the bound.
Note that explicit bounds on the loss level can be particularly Note that explicit bounds on the loss level can be particularly
difficult as the exact way in which packets merge inside the network difficult as the exact way in which packets merge inside the network
affects the burstiness of the PDB's traffic aggregate and hence, affects the burstiness of the PDB's traffic aggregate and hence,
loss. loss.
PHBs give explicit expressions of the treatment a traffic aggregate PHBs give explicit expressions of the treatment a traffic aggregate
can expect at each hop. For a PDB, this behavior must apply to can expect at each hop. For a PDB, this behavior must apply to
merging and diverging traffic aggregates, thus characterizing a merging and diverging traffic aggregates, thus characterizing a PDB
PDB requires understanding what happens to a PHB under aggregation. requires understanding what happens to a PHB under aggregation. That
That is, PHBs recursively applied must result in a known behavior. is, PHBs recursively applied must result in a known behavior. As an
As an example, since maximum burst sizes grow with the number of example, since maximum burst sizes grow with the number of microflows
microflows or traffic aggregate streams merged, a PDB specification or traffic aggregate streams merged, a PDB specification must address
must address this. A clear advantage of constructing behaviors this. A clear advantage of constructing behaviors that aggregate is
that aggregate is the ease of concatenating PDBs so that the associated the ease of concatenating PDBs so that the associated traffic
traffic aggregate has known attributes that span interior DS domains aggregate has known attributes that span interior DS domains and,
and, eventually, farther. For example, in figure 1 assume that eventually, farther. For example, in figure 1 assume that we have
we have configured the foo PDB on the interior DS domains of AS2. configured the foo PDB on the interior DS domains of AS2. Then
Then traffic aggregates associated with the foo PDB in each interior traffic aggregates associated with the foo PDB in each interior DS
DS domain of AS2 can be merged at the shaded interior boundary domain of AS2 can be merged at the shaded interior boundary routers.
routers. If the same (or fewer) traffic conditioners as applied If the same (or fewer) traffic conditioners as applied at the
at the entrance to AS2 are applied at these interior boundaries, entrance to AS2 are applied at these interior boundaries, the
the attributes of the foo PDB should continue to be used to quantify attributes of the foo PDB should continue to be used to quantify the
the expected behavior. Explicit expressions of what happens to expected behavior. Explicit expressions of what happens to the
the behavior under aggregation, possibly parameterized by node behavior under aggregation, possibly parameterized by node in-degrees
in-degrees or network diameters, are necessary to determine what or network diameters, are necessary to determine what to do at the
to do at the internal aggregation points. One approach might be internal aggregation points. One approach might be to completely
to completely reapply the traffic conditioning at these points; reapply the traffic conditioning at these points; another might
another might employ some limited rate-based remarking only. employ some limited rate-based remarking only.
Multiple PDBs may use the same PHB. The specification of a PDB can Multiple PDBs may use the same PHB. The specification of a PDB can
contain a list of PHBs and their required configuration, all of contain a list of PHBs and their required configuration, all of which
which would result in the same PDB. In operation, it is expected would result in the same PDB. In operation, it is expected that a
that a single domain will use a single PHB to implement a particular single domain will use a single PHB to implement a particular PDB,
PDB, though different domains may select different PHBs. Recall though different domains may select different PHBs. Recall that in
that in the diffserv definition [RFC2474], a single PHB might be the diffserv definition [RFC2474], a single PHB might be selected
selected within a domain by a list of DSCPs. Multiple PDBs might within a domain by a list of DSCPs. Multiple PDBs might use the same
use the same PHB in which case the transit performance of traffic PHB in which case the transit performance of traffic aggregates of
aggregates of these PDBs will, of necessity, be the same. Yet, these PDBs will, of necessity, be the same. Yet, the particular
the particular characteristics that the PDB designer wishes to characteristics that the PDB designer wishes to claim as attributes
claim as attributes may vary, so two PDBs that use the same PHB may vary, so two PDBs that use the same PHB might not be specified
might not be specified with the same list of attributes. with the same list of attributes.
The specification of the transit expectations of PDBs across domains The specification of the transit expectations of PDBs across domains
both assists in the deployment of QoS within a DS domain and helps both assists in the deployment of QoS within a DS domain and helps
enable the composition of end-to-end, cross-domain services to enable the composition of end-to-end, cross-domain services to
proceed by making it possible to hide details of a domain's internals proceed by making it possible to hide details of a domain's internals
while exposing characteristics necessary for QoS. while exposing characteristics necessary for QoS.
4.3 PDBs using PHB Groups 4.3 PDBs using PHB Groups
The use of PHB groups to construct PDBs can be done in several ways. The use of PHB groups to construct PDBs can be done in several ways.
A single PHB member of a PHB group might be used to construct a A single PHB member of a PHB group might be used to construct a
single PDB. For example, a PDB could be defined using just one single PDB. For example, a PDB could be defined using just one of
of the Class Selector Compliant PHBs [RFC2474]. The traffic conditioning the Class Selector Compliant PHBs [RFC2474]. The traffic
for that PDB and the required configuration of the particular PHB conditioning for that PDB and the required configuration of the
would be defined in such a way that there was no dependence or particular PHB would be defined in such a way that there was no
relationship with the manner in which other PHBs of the group are dependence or relationship with the manner in which other PHBs of the
used or, indeed, whether they are used in that DS domain. In this group are used or, indeed, whether they are used in that DS domain.
case, the reasonable approach would be to specify this PDB alone in In this case, the reasonable approach would be to specify this PDB
a document which expressly called out the conditions and configuration alone in a document which expressly called out the conditions and
of the Class Selector PHB required. configuration of the Class Selector PHB required.
A single PDB can be constructed using more than one PHB from the A single PDB can be constructed using more than one PHB from the same
same PHB group. For example, the traffic conditioner described PHB group. For example, the traffic conditioner described in RFC
in RFC 2698 might be used to mark a particular entering traffic 2698 might be used to mark a particular entering traffic aggregate
aggregate for one of the three AF1x PHBs [RFC2597] while the transit for one of the three AF1x PHBs [RFC2597] while the transit
performance of the resultant PDB is specified, statistically, across performance of the resultant PDB is specified, statistically, across
all the packets marked with one of those PHBs. all the packets marked with one of those PHBs.
A set of related PDBs might be defined using a PHB group. In this 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. case, the related PDBs should be defined in the same document. This
This is appropriate when the traffic conditioners that create the is appropriate when the traffic conditioners that create the traffic
traffic aggregates associated with each PDB have some relationships aggregates associated with each PDB have some relationships and
and interdependencies such that the traffic aggregates for these interdependencies such that the traffic aggregates for these PDBs
PDBs should be described and characterized together. The transit should be described and characterized together. The transit
attributes will depend on the PHB associated with the PDB and will 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 not be the same for all PHBs in the group, though there may be some
some parameterized interrelationship between the attributes of parameterized interrelationship between the attributes of each of
each of these PDBs. In this case, each PDB should have a clearly these PDBs. In this case, each PDB should have a clearly separate
separate description of its transit attributes (delineated in a description of its transit attributes (delineated in a separate
separate subsection) within the document. For example, the traffic subsection) within the document. For example, the traffic
conditioner described in RFC 2698 might be used to mark arriving conditioner described in RFC 2698 might be used to mark arriving
packets for three different AF1x PHBs, each of which is to be treated packets for three different AF1x PHBs, each of which is to be treated
as a separate traffic aggregate in terms of transit properties. as a separate traffic aggregate in terms of transit properties. Then
Then a single document could be used to define and quantify the a single document could be used to define and quantify the
relationship between the arriving packets and the emerging traffic relationship between the arriving packets and the emerging traffic
aggregates as they relate to one another. The transit characteristics aggregates as they relate to one another. The transit
of packets of each separate AF1x traffic aggregate should be described characteristics of packets of each separate AF1x traffic aggregate
separately within the document. should be described separately within the document.
Another way in which a PHB group might be used to create one PDB Another way in which a PHB group might be used to create one PDB per
per PHB might have decoupled traffic conditioners, but some relationship PHB might have decoupled traffic conditioners, but some relationship
between the PHBs of the group. For example, a set of PDBs might between the PHBs of the group. For example, a set of PDBs might be
be defined using Class Selector Compliant PHBs [RFC2474] in such defined using Class Selector Compliant PHBs [RFC2474] in such a way
a way that the traffic conditioners that create the traffic aggregates that the traffic conditioners that create the traffic aggregates are
are not related, but the transit performance of each traffic aggregate not related, but the transit performance of each traffic aggregate
has some parametric relationship to the other. If it makes sense has some parametric relationship to the other. If it makes sense to
to specify them in the same document, then the author(s) should specify them in the same document, then the author(s) should do so.
do so.
4.4 Forwarding path vs. control plane 4.4 Forwarding path vs. control plane
A PDB's associated PHB, classifiers, and traffic conditioners are A PDB's associated PHB, classifiers, and traffic conditioners are all
all in the packet forwarding path and operate at line rates. PHBs, in the packet forwarding path and operate at line rates. PHBs,
classifiers, and traffic conditioners are configured in response classifiers, and traffic conditioners are configured in response to
to control plane activity which takes place across a range of time control plane activity which takes place across a range of time
scales, but, even at the shortest time scale, control plane actions scales, but, even at the shortest time scale, control plane actions
are not expected to happen per-packet. Classifiers and traffic are not expected to happen per-packet. Classifiers and traffic
conditioners at the DS domain boundary are used to enforce who conditioners at the DS domain boundary are used to enforce who gets
gets to use the PDB and how the PDB should behave temporally. to use the PDB and how the PDB should behave temporally.
Reconfiguration of PHBs might occur monthly, quarterly, or only when Reconfiguration of PHBs might occur monthly, quarterly, or only when
the network is upgraded. Classifiers and traffic conditioners might be the network is upgraded. Classifiers and traffic conditioners might
reconfigured at a few regular intervals during the day or might happen be reconfigured at a few regular intervals during the day or might
in response to signalling decisions thousands of times a day. Much of happen in response to signalling decisions thousands of times a day.
the control plane work is still evolving and is outside the charter of Much of the control plane work is still evolving and is outside the
the Diffserv WG. We note that this is quite appropriate since the charter of the Diffserv WG. We note that this is quite appropriate
manner in which the configuration is done and the time scale at which since the manner in which the configuration is done and the time
it is done should not affect the PDB attributes. scale at which it is done should not affect the PDB attributes.
5 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 interior PDBs arise from a particular relationship between edge and interior
(which may be parameterized). The quantifiable characteristics (which may be parameterized). The quantifiable characteristics of a
of a PDB must be independent of whether the network edge is configured PDB must be independent of whether the network edge is configured
statically or dynamically. The particular configuration of traffic statically or dynamically. The particular configuration of traffic
conditioners at the DS domain edge is critical to how a PDB performs, conditioners at the DS domain edge is critical to how a PDB performs,
but the act(s) of configuring the edge is a control plane action but the act(s) of configuring the edge is a control plane action
which can be separated from the specification of the PDB. which can be separated from the specification of the 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 content Differentiated Services PDB. Of necessity, their length and content
will vary greatly. will 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 Technical specification 5.2 Technical specification
This section specifies the rules or guidelines to create this PDB, This section specifies the rules or guidelines to create this PDB,
each distinguished with "may", "must" and "should." The technical each distinguished with "may", "must" and "should." The technical
specification must list the classification and traffic conditioning specification must list the classification and traffic conditioning
required (if any) and the PHB (or PHBs) to be used with any additional required (if any) and the PHB (or PHBs) to be used with any
requirements on their configuration beyond that contained in RFCs. additional requirements on their configuration beyond that contained
Classification can reflect the results of an admission control in RFCs. Classification can reflect the results of an admission
process. Traffic conditioning may include marking, traffic shaping, control process. Traffic conditioning may include marking, traffic
and policing. A Service Provisioning Policy might be used to describe shaping, and policing. A Service Provisioning Policy might be used
the technical specification of a particular PDB. to describe the technical specification of a particular PDB.
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 measured over some time period. They may be bounds, statistical bounds measured over some time period. They may be bounds,
bounds, or percentiles (e.g., "90% of all packets measured over statistical bounds, or percentiles (e.g., "90% of all packets
intervals of at least 5 minutes will cross the DS domain in less measured over intervals of at least 5 minutes will cross the DS
than 5 milliseconds"). A wide variety of characteristics may be domain in less than 5 milliseconds"). A wide variety of
used but they must be explicit, quantifiable, and defensible. Where characteristics may be used but they must be explicit, quantifiable,
particular statistics are used, the document must be precise about and defensible. Where particular statistics are used, the document
how they are to be measured and about how the characteristics were must be precise about how they are to be measured and about how the
derived. characteristics 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 such, example, a "loss-free" PDB would probably not be sold as such, but
but rather as a service with a very small packet loss probability. rather as a service with a very small packet loss probability.
5.4 Parameters 5.4 Parameters
The definition and characteristics of a PDB may be parameterized The definition and characteristics of a PDB may be parameterized by
by network-specific features; for example, maximum number of hops, network-specific features; for example, maximum number of hops,
minimum bandwidth, total number of entry/exit points of the PDB minimum bandwidth, total number of entry/exit points of the PDB
to/from the diffserv network, maximum transit delay of network to/from the diffserv network, maximum transit delay of network
elements, minimum buffer size available for the PDB at a network elements, minimum buffer size available for the PDB at a network
node, etc. 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 failures, and relatively stable routing. This is reasonable link failures, and relatively stable routing. This is reasonable
since otherwise it would be very difficult to quantify behavior since otherwise it would be very difficult to quantify behavior and
and this is the operating conditions for which most operators strive. this is the operating conditions for which most operators strive.
However, these assumptions must be clearly stated. Since PDBs with However, these assumptions must be clearly stated. Since PDBs with
specific bandwidth parameters require that bandwidth to be available, specific bandwidth parameters require that bandwidth to be available,
the assumptions to be stated may include standby capacity. Some the assumptions to be stated may include standby capacity. Some PDBs
PDBs may be specifically targeted for cases where these assumptions may be specifically targeted for cases where these assumptions do not
do not hold, e.g., for high loss rate links, and such targeting hold, e.g., for high loss rate links, and such targeting must also be
must also be made explicit. If additional restrictions, especially made explicit. If additional restrictions, especially specific
specific traffic engineering measures, are required, these must traffic engineering measures, are required, these must be stated.
be stated.
Further, if any assumptions are made about the allocation of resources Further, if any assumptions are made about the allocation of
within a diffserv network in the creation of the PDB, these must resources within a diffserv network in the creation of the PDB, these
be made explicit. must be made explicit.
5.6 Example Uses 5.6 Example Uses
A PDB specification must give example uses to motivate the understanding A PDB specification must give example uses to motivate the
of ways in which a diffserv network could make use of the PDB although understanding of ways in which a diffserv network could make use of
these are not expected to be detailed. For example, "A bulk handling the PDB although these are not expected to be detailed. For example,
PDB may be used for all packets which should not take any resources "A bulk handling PDB may be used for all packets which should not
from the network unless they would otherwise go unused. This might take any resources from the network unless they would otherwise go
be useful for Netnews traffic or for traffic rejected from some unused. This might be useful for Netnews traffic or for traffic
other PDB by traffic policers." rejected from some other PDB by traffic policers."
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 commonly defined one) is being used nor is it necessary for a
a provider to specify a service by the PDB's attributes. For example, provider to specify a service by the PDB's attributes. For example,
a service provider might use a PDB with a "no queueing loss" a service provider might use a PDB with a "no queueing loss"
characteristic in order to specify a "very low loss" service. characteristic 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 that above. Detail the assumptions made there and what constraints that
puts on topology or type of physical media or allocation. puts on topology or type of physical media or allocation.
5.8 Security Considerations for each PDB 5.8 Security Considerations for each PDB
This section should include any security considerations that are This section should include any security considerations that are
specific to the PDB. Is it subject to any unusual theft-of-service specific to the PDB. Is it subject to any unusual theft-of-service
or denial-of-service attacks? Are any unusual security precautions or denial-of-service attacks? Are any unusual security precautions
needed? needed?
It is not necessary to repeat the general security discussions in It is not necessary to repeat the general security discussions in
[RFC2474] and [RFC2475], but a reference should be included. Also [RFC2474] and [RFC2475], but a reference should be included. Also
refer to any special security considerations for the PHB or PHBs refer to any special security considerations for the PHB or PHBs
used. used.
6 On PDB Attributes 6 On PDB Attributes
As discussed in section 4, measurable, quantifiable attributes As discussed in section 4, measurable, quantifiable attributes
associated with each PDB can be used to describe what will happen to associated with each PDB can be used to describe what will happen to
packets using that PDB as they cross the domain. In its role as a build- packets using that PDB as they cross the domain. In its role as a
ing block for the construction of interdomain quality-of-service, a building block for the construction of interdomain quality-of-
PDB specification should provide the answer to the question: Under service, a PDB specification should provide the answer to the
what conditions can we join the output of this domain to another question: Under what conditions can we join the output of this domain
under the same traffic conditioning and expectations? Although to another under the same traffic conditioning and expectations?
there are many ways in which traffic might be distributed, creating Although there are many ways in which traffic might be distributed,
quantifiable, realizable PDBs that can be concatenated into multi-domain creating quantifiable, realizable PDBs that can be concatenated into
services limits the realistic scenarios. A PDB's attributes with multi-domain services limits the realistic scenarios. A PDB's
a clear statement of the conditions under which the attributes attributes with a clear statement of the conditions under which the
hold is critical to the composition of multi-domain services. attributes hold is critical to the composition of multi-domain
services.
There is a clear correlation between the strictness of the traffic There is a clear correlation between the strictness of the traffic
conditioning and the quality of the PDB's attributes. As indicated conditioning and the quality of the PDB's attributes. As indicated
earlier, numerical bounds are likely to be statistical or expressed earlier, numerical bounds are likely to be statistical or expressed
as a percentile. Parameters expressed as strict bounds will require as a percentile. Parameters expressed as strict bounds will require
very precise mathematical analysis, while those expressed statistically very precise mathematical analysis, while those expressed
can to some extent rely on experiment. Section 7 gives the example statistically can to some extent rely on experiment. Section 7 gives
of a PDB without strict traffic conditioning and concurrent work the example of a PDB without strict traffic conditioning and
on a PDB with strict traffic conditioning and attributes is also concurrent work on a PDB with strict traffic conditioning and
in front of the WG [VW]. This section gives some general considerations attributes is also in front of the WG [VW]. This section gives some
for characterizing PDB attributes. general considerations for characterizing PDB attributes.
There are two ways to characterize PDBs with respect to time. First There are two ways to characterize PDBs with respect to time. First
are properties over "long" time periods, or average behaviors. are properties over "long" time periods, or average behaviors. A PDB
A PDB specification should report these as the rates or throughput specification should report these as the rates or throughput seen
seen over some specified time period. In addition, there are properties over some specified time period. In addition, there are properties
of "short" time behavior, usually expressed as the allowable burstiness of "short" time behavior, usually expressed as the allowable
in a traffic aggregate. The short time behavior is important in burstiness in a traffic aggregate. The short time behavior is
understanding buffering requirements (and associated loss character- important in understanding buffering requirements (and associated
istics) and for metering and conditioning considerations at DS loss characteristics) and for metering and conditioning
boundaries. For short-time behavior, we are interested primarily in considerations at DS boundaries. For short-time behavior, we are
two things: 1) how many back-to-back packets of the PDB's traffic interested primarily in two things: 1) how many back-to-back packets
aggregate will we see at any point (this would be metered as a burst) of the PDB's traffic aggregate will we see at any point (this would
and 2) how large a burst of packets of this PDB's traffic aggregate be metered as a burst) and 2) how large a burst of packets of this
can appear in a queue at once (gives queue overflow and loss). PDB's traffic aggregate can appear in a queue at once (gives queue
If other PDBs are using the same PHB within the domain, that must overflow and loss). If other PDBs are using the same PHB within the
be taken into account. 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 characterize the average or long-term behavior for the foo PDB To characterize the average or long-term behavior for the foo PDB we
we must explore a number of questions, for instance: Can the DS must explore a number of questions, for instance: Can the DS domain
domain handle the average foo traffic flow? Is that answer topology de- handle the average foo traffic flow? Is that answer topology
pendent or are there some specific assumptions on routing which must dependent or are there some specific assumptions on routing which
hold for the foo PDB to preserve its "adequately provisioned" must hold for the foo PDB to preserve its "adequately provisioned"
capability? In other words, if the topology of D changes suddenly, capability? In other words, if the topology of D changes suddenly,
will the foo PDB's attributes change? Will its loss rate dramatically will the foo PDB's attributes change? Will its loss rate
increase? dramatically increase?
Let domain D in figure 4 be an ISP ringing the U.S. with links of Let domain D in figure 4 be an ISP ringing the U.S. with links of
bandwidth B and with N tails to various metropolitan areas. Inside bandwidth B and with N tails to various metropolitan areas. Inside
D, if the link between the node connected to A and the node connected D, if the link between the node connected to A and the node connected
to Z goes down, all the foo traffic aggregate between the two nodes to Z goes down, all the foo traffic aggregate between the two nodes
must transit the entire ring: Would the bounded behavior of the must transit the entire ring: Would the bounded behavior of the foo
foo PDB change? If this outage results in some node of the ring PDB change? If this outage results in some node of the ring now
now having a larger arrival rate to one of its links than the capacity having a larger arrival rate to one of its links than the capacity of
of the link for foo's traffic aggregate, clearly the loss rate the link for foo's traffic aggregate, clearly the loss rate would
would change dramatically. In this case, topological assumptions change dramatically. In this case, topological assumptions were made
were made about the path of the traffic from A to Z that affected about the path of the traffic from A to Z that affected the
the characteristics of the foo PDB. If these topological assumptions characteristics of the foo PDB. If these topological assumptions no
no longer hold, the loss rate of packets of the foo traffic aggregate longer hold, the loss rate of packets of the foo traffic aggregate
transiting the domain could change; for example, a characteristic transiting the domain could change; for example, a characteristic
such as "loss rate no greater than 1% over any interval larger such as "loss rate no greater than 1% over any interval larger than
than 10 minutes." A PDB specification should spell out the assumptions 10 minutes." A PDB specification should spell out the assumptions
made on preserving the attributes. made on preserving the attributes.
____X________X_________X___________ / ____X________X_________X___________ /
/ \ L | / \ L |
A<---->X X<----->| E A<---->X X<----->| E
| | | | | |
| D | \ | D | \
Z<---->X | Z<---->X |
| | | |
\___________________________________/ \___________________________________/
X 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
to DS domain E connected to DS domain E
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 maximum associated with a PDB, specifically whether permitting the maximum
bursts to add in the same manner as the average rates will lead bursts to add in the same manner as the average rates will lead to
to properties that aggregate or under what conditions this will properties that aggregate or under what conditions this will lead to
lead to properties that aggregate. In our example, if domain D properties that aggregate. In our example, if domain D allows each
allows each of the uplinks to burst p packets into the foo traffic of the uplinks to burst p packets into the foo traffic aggregate, the
aggregate, the bursts could accumulate as they transit the ring. bursts could accumulate as they transit the ring. Packets headed for
Packets headed for link L can come from both directions of the link L can come from both directions of the ring and back-to-back
ring and back-to-back packets from foo's traffic aggregate can packets from foo's traffic aggregate can arrive at the same time. If
arrive at the same time. If the bandwidth of link L is the same the bandwidth of link L is the same as the links of the ring, this
as the links of the ring, this probably does not present a buffering probably does not present a buffering problem. If there are two
problem. If there are two input links that can send packets to input links that can send packets to queue for L, at worst, two
queue for L, at worst, two packets can arrive simultaneously for packets can arrive simultaneously for L. If the bandwidth of link L
L. If the bandwidth of link L equals or exceeds twice B, the packets equals or exceeds twice B, the packets won't accumulate. Further, if
won't accumulate. Further, if p is limited to one, and the bandwidth p is limited to one, and the bandwidth of L exceeds the rate of
of L exceeds the rate of arrival (over the longer term) of foo arrival (over the longer term) of foo packets (required for bounding
packets (required for bounding the loss) then the queue of foo the loss) then the queue of foo packets for link L will empty before
packets for link L will empty before new packets arrive. If the new packets arrive. If the bandwidth of L is equal to B, one foo
bandwidth of L is equal to B, one foo packet must queue while the packet must queue while the other is transmitted. This would result
other is transmitted. This would result in N x p back-to- back in N x p back-to- back packets of this traffic aggregate arriving
packets of this traffic aggregate arriving over L during the same over L during the same time scale as the bursts of p were permitted
time scale as the bursts of p were permitted on the uplinks. Thus, on the uplinks. Thus, configuring the PDB so that link L can handle
configuring the PDB so that link L can handle the sum of the rates the sum of the rates that ingress to the foo PDB doesn't guarantee
that ingress to the foo PDB doesn't guarantee that L can handle that L can handle the sum of the N bursts into the foo PDB.
the sum of the N 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 the full bandwidth L, this number is larger. For probabilistic than the full bandwidth L, this number is larger. For probabilistic
bounds, a smaller buffer might do if the probability of exceeding bounds, a smaller buffer might do if the probability of exceeding it
it can be bounded. can be bounded.
More generally, for router indegree of d, bursts of foo packets More generally, for router indegree of d, bursts of foo packets might
might arrive on each input. Then, in the absence of any additional arrive on each input. Then, in the absence of any additional traffic
traffic conditioning, it is possible that dxpx(# of uplinks) back-to conditioning, it is possible that dxpx(# of uplinks) back-to-back foo
-back foo packets can be sent across link L to domain E. Thus the DS packets can be sent across link L to domain E. Thus the DS domain E
domain E must permit these much larger bursts into the foo PDB must permit these much larger bursts into the foo PDB than domain D
than domain D permits on the N uplinks or else the foo traffic permits on the N uplinks or else the foo traffic aggregate must be
aggregate must be made to conform to the TCA for entering E (e.g., made to conform to the TCA for entering E (e.g., by shaping).
by shaping).
What conditions should be imposed on a PDB and on the associated What conditions should be imposed on a PDB and on the associated PHB
PHB in order to ensure PDBs can be concatenated, as across the in order to ensure PDBs can be concatenated, as across the interior
interior DS domains of figure 1? Traffic conditioning for constructing DS domains of figure 1? Traffic conditioning for constructing a PDB
a PDB that has certain attributes across a DS domain should apply that has certain attributes across a DS domain should apply
independently of the origin of the packets. With reference to the independently of the origin of the packets. With reference to the
example we've been exploring, the TCA for the PDB's traffic aggregate example we've been exploring, the TCA for the PDB's traffic aggregate
entering link L into domain E should not depend on the number of entering link L into domain E should not depend on the number of
uplinks into domain D. uplinks into domain D.
6.3 Remarks 6.3 Remarks
This section has been provided as motivational food for thought This section has been provided as motivational food for thought for
for PDB specifiers. It is by no means an exhaustive catalog of PDB specifiers. It is by no means an exhaustive catalog of possible
possible PDB attributes or what kind of analysis must be done. PDB attributes or what kind of analysis must be done. We expect this
We expect this to be an interesting and evolutionary part of the to be an interesting and evolutionary part of the work of
work of understanding and deploying differentiated services in understanding and deploying differentiated services in the Internet.
the Internet. There is a potential for much interesting research There is a potential for much interesting research work. However, in
work. However, in submitting a PDB specification to the Diffserv submitting a PDB specification to the Diffserv WG, a PDB must also
WG, a PDB must also meet the test of being useful and relevant meet the test of being useful and relevant by a deployment
by a deployment experience, described in section 8. experience, described in section 8.
7 A Reference Per-Domain Behavior 7 A Reference Per-Domain Behavior
The intent of this section is to define as a reference a Best Effort The intent of this section is to define as a reference a Best Effort
PDB, a PDB that has little in the way of rules or expectations. PDB, a PDB that has little in the way of rules or expectations.
7.1 Best Effort PDB 7.1 Best Effort 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 a diffserv network. That is, the definition and use of this across a diffserv network. That is, the definition and use of this
PDB is to preserve, to a reasonable extent, the pre-diffserv delivery PDB is to preserve, to a reasonable extent, the pre-diffserv delivery
expectation for packets in a diffserv network that do not require expectation for packets in a diffserv network that do not require any
any special differentiation. Although the PDB itself does not include special differentiation. Although the PDB itself does not include
bounds on availability, latency, and packet loss, this does not bounds on availability, latency, and packet loss, this does not
preclude Service Providers from engineering their networks so as preclude Service Providers from engineering their networks so as to
to result in commercially viable bounds on services that utilize result in commercially viable bounds on services that utilize the BE
the BE PDB. This would be analogous to the Service Level Guarantees PDB. This would be analogous to the Service Level Guarantees that
that are provided in today's single-service Internet. are provided in today's single-service Internet.
In the present single-service commercial Internet, Service Level In the present single-service commercial Internet, Service Level
Guarantees for availability, latency, and packet delivery can be Guarantees for availability, latency, and packet delivery can be
found on the web sites of ISPs [WCG, PSI, UU]. For example, a typical found on the web sites of ISPs [WCG, PSI, UU]. For example, a
North American round-trip latency bound is 85 milliseconds, with typical North American round-trip latency bound is 85 milliseconds,
each service provider's site information specifying the method with each service provider's site information specifying the method
of measurement of the bounds and the terms associated with these of measurement of the bounds and the terms associated with these
bounds contractually. bounds contractually.
7.1.2 TCS and PHB configurations 7.1.2 TCS and PHB configurations
There are no restrictions governing rate and bursts of packets beyond There are no restrictions governing rate and bursts of packets beyond
the limits imposed by the ingress link. The network edge ensures the limits imposed by the ingress link. The network edge ensures
that packets using the PDB are marked for the Default PHB (as defined that packets using the PDB are marked for the Default PHB (as defined
in [RFC2474]), but no other traffic conditioning is required. Interior in [RFC2474]), but no other traffic conditioning is required.
network nodes apply the Default PHB on these packets. Interior network nodes apply 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 resources Packets of this PDB will not be completely starved and when resources
are available (i.e., not required by packets from any other traffic are available (i.e., not required by packets from any other traffic
aggregate), network elements should be configured to permit packets aggregate), network elements should be configured to permit packets
of this PDB to consume them. of this PDB to consume them.
Network operators may bound the delay and loss rate for services Network operators may bound the delay and loss rate for services
constructed from this PDB given knowledge about their network, constructed from this PDB given knowledge about their network, but
but such attributes are not part of the definition. such attributes are 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 from A properly functioning network, i.e., packets may be delivered 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.1.7 Environmental Concerns 7.1.7 Environmental Concerns
There are no environmental concerns specific to this PDB. There are no environmental concerns specific to this PDB.
7.1.8 Securty Considerations for BE PDB 7.1.8 Security Considerations for BE PDB
There are no specific security exposures for this PDB. See the There are no specific security exposures for this PDB. See the
general security considerations in [RFC2474] and [RFC2475]. general security considerations in [RFC2474] and [RFC2475].
8 Guidelines for writing PDB specifications 8 Guidelines for writing PDB specifications
G1. Following the format given in this document, write a draft and G1. Following the format given in this document, write a draft and
submit it as an Internet Draft. The document should have "diffserv" submit it as an Internet Draft. The document should have "diffserv"
as some part of the name. Either as an appendix to the draft, or as some part of the name. Either as an appendix to the draft, or in
in a separate document, provide details of deployment experience a separate document, provide details of deployment experience with
with measured results on a network of non-trivial size carrying measured results on a network of non-trivial size carrying realistic
realistic traffic and/or convincing simulation results (simulation traffic and/or convincing simulation results (simulation of a range
of a range of modern traffic patterns and network topologies as of modern traffic patterns and network topologies as applicable).
applicable). The document should be brought to the attention of The document should be brought to the attention of the diffserv WG
the diffserv WG mailing list, if active. mailing list, if active.
G2. Initial discussion should focus primarily on the merits of the G2. Initial discussion should focus primarily on the merits of the
PDB, though comments and questions on the claimed attributes are PDB, though comments and questions on the claimed attributes are
reasonable. This is in line with the Differentiated Services goal reasonable. This is in line with the Differentiated Services goal to
to put relevance before academic interest in the specification put relevance before academic interest in the specification of PDBs.
of PDBs. Academically interesting PDBs are encouraged, but would Academically interesting PDBs are encouraged, but would be more
be more appropriate for technical publications and conferences, appropriate for technical publications and conferences, not for
not for submission to the IETF. (An "academically interesting" submission to the IETF. (An "academically interesting" PDB might
PDB might become a PDB of interest for deployment over time.) become a PDB of interest for deployment over time.)
The implementation of the following guidelines varies, depending The implementation of the following guidelines varies, depending on
on whether there is an active diffserv working group or not. whether there is an active diffserv working group or not.
Active Diffserv Working Group path: Active Diffserv Working Group path:
G3. Once consensus has been reached on a version of a draft that G3. Once consensus has been reached on a version of a draft that it
it is a useful PDB and that the characteristics "appear" to be is a useful PDB and that the characteristics "appear" to be correct
correct (i.e., not egregiously wrong) that version of the draft (i.e., not egregiously wrong) that version of the draft goes to a
goes to a review panel the WG co-chairs set up to audit and report review panel the WG co-chairs set up to audit and report on the
on the characteristics. The review panel will be given a deadline characteristics. The review panel will be given a deadline for the
for the review. The exact timing of the deadline will be set on review. The exact timing of the deadline will be set on a case-by-
a case-by-case basis by the co-chairs to reflect the complexity case basis by the co-chairs to reflect the complexity of the task and
of the task and other constraints (IETF meetings, major holidays) other constraints (IETF meetings, major holidays) but is expected to
but is expected to be in the 4-8 week range. During that time, be in the 4-8 week range. During that time, the panel may correspond
the panel may correspond with the authors directly (cc'ing the with the authors directly (cc'ing the WG co-chairs) to get
WG co-chairs) to get clarifications. This process should result clarifications. This process should result in a revised draft and/or
in a revised draft and/or a report to the WG from the panel that a report to the WG from the panel that either endorses or disputes
either endorses or disputes the claimed characteristics. the claimed characteristics.
G4. If/when endorsed by the panel, that draft goes to WG last call. G4. If/when endorsed by the panel, that draft goes to WG last call.
If not endorsed, the author(s) can give an itemized response to If not endorsed, the author(s) can give an itemized response to the
the panel's report and ask for a WG Last Call. panel's report and ask for a WG Last Call.
G5. If/when passes Last Call, goes to ADs for publication as a WG G5. 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".
If no active Diffserv Working Group exists: If no active Diffserv Working Group exists:
G3. Following discussion on relevant mailing lists, the authors G3. Following discussion on relevant mailing lists, the authors
should revise the Internet Draft and contact the IESG for "Expert should revise the Internet Draft and contact the IESG for "Expert
Review" as defined in section 2 of RFC 2434 [RFC2434]. Review" as defined in section 2 of RFC 2434 [RFC2434].
G4. Subsequent to the review, the IESG may recommend publication G4. Subsequent to the review, the IESG may recommend publication of
of the Draft as an RFC, request revisions, or decline to publish the Draft as an RFC, request revisions, or decline to publish as an
as an Informational RFC in the "PDB series". Informational RFC in the "PDB series".
9 Security Considerations 9 Security Considerations
The general security considerations of [RFC2474] and [RFC2475] apply The general security considerations of [RFC2474] and [RFC2475] apply
to all PDBs. Individual PDB definitions may require additional to all PDBs. Individual PDB definitions may require additional
security considerations. security considerations.
10 Acknowledgements 10 Acknowledgements
The ideas in this document have been heavily influenced by the Diffserv The ideas in this document have been heavily influenced by the
WG and, in particular, by discussions with Van Jacobson, Dave Clark, Diffserv WG and, in particular, by discussions with Van Jacobson,
Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush,
Aaron Falk, and a host of other people who should be acknowledged Frank Kastenholz, Aaron Falk, and a host of other people who should
for their useful input but not be held accountable for our mangling be acknowledged for their useful input but not be held accountable
of it. Grenville Armitage coined "per domain behavior (PDB)" though for our mangling of it. Grenville Armitage coined "per domain
some have suggested similar terms prior to that. Dan Grossman, behavior (PDB)" though some have suggested similar terms prior to
Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert
and commented so as to improve its form. reviewed the document and commented so as to improve its form.
References References
[RFC2474] RFC 2474, "Definition of the Differentiated Services Field [RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, "Definition
(DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, F. of the Differentiated Services Field (DS Field) in the IPv4
Baker, D. Black, www.ietf.org/rfc/rfc2474.txt and IPv6 Headers", RFC 2474, December 1998.
[RFC2475] RFC 2475, "An Architecture for Differentiated Services", [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
S. Blake, D. Black, M.Carlson, E.Davies, Z.Wang, W.Weiss, W. Weiss, "An Architecture for Differentiated Services",
www.ietf.org/rfc/rfc2475.txt December 1998.
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2598] RFC 2598, "An Expedited Forwarding PHB", V.Jacobson, [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
K.Nichols, K.Poduri, www.ietf.org/ rfc/rfc2598.txt Forwarding PHB", RFC 2598, June 1999.
[RFC2698] RFC 2698, "A Two Rate Three Color Marker", J. Heinanen, R. [RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color
Guerin. www.ietf.org/rfc/ rfc2698.txt Marker", RFC 2698, June 1999.
[MODEL] "An Informal Management Model for Diffserv Routers", [MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
draft-ietf-diffserv-model-05.txt, Y. Bernet, S. Blake, D. Grossman, Informal Management Model for Diffserv Routers", Work in
A. Smith Progress.
[MIB] "Management Information Base for the Differentiated Services [MIB] Baker, F., Chan, K. and A. Smith, "Management Information
Architecture", draft-ietf-diffserv- mib-06.txt, F. Baker, K. Chan, Base for the Differentiated Services Architecture", Work in
A. Smith Progress.
[VW] "The 'Virtual Wire' Per-Domain Behavior", [VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual
draft-ietf-diffserv-pdb-vw-00.txt, V. Jacobson, K. Nichols, and Wire' Per-Domain Behavior", Work in Progress.
K. Poduri
[WCG] Worldcom, "Internet Service Level Guarantee", [WCG] Worldcom, "Internet Service Level Guarantee",
http://www.worldcom.com/terms/service_level_guarantee/t_sla_terms.phtml http://www.worldcom.com/terms/service_level_guarantee/
t_sla_terms.phtml
[PSI] PSINet, "Service Level Agreements", http://www.psinet.com/sla/ [PSI] PSINet, "Service Level Agreements",
http://www.psinet.com/sla/
[UU] UUNET USA Web site, "Service Level Agreements", [UU] UUNET USA Web site, "Service Level Agreements",
http://www.us.uu.net/support/sla/ http://www.us.uu.net/support/sla/
[RFC234] RFC 2434, "Guidelines for IANA Considerations", T. Narten, [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA
H. Alverstrand. www.ietf.org/rfc/ rfc2434.txt Considerations", BCP 26, RFC 2434, October 1998.
Authors' Addresses Authors' Addresses
Kathleen Nichols Brian Carpenter Kathleen Nichols
Packet Design, Inc. IBM Packet Design, LLC
66 Willow Place c/o iCAIR 2465 Latham Street, Third Floor
Menlo Park, CA 94025 Suite 150 Mountain View, CA 94040
USA 1890 Maple Avenue USA
Evanston, IL 60201
USA EMail: nichols@packetdesign.com
email: nichols@packetdesign.com email: brian@icair.org
Brian Carpenter
IBM
c/o iCAIR
Suite 150
1890 Maple Avenue
Evanston, IL 60201
USA
EMail: brian@icair.org
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 123 change blocks. 
874 lines changed or deleted 854 lines changed or added

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