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

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