draft-ietf-diffserv-model-06.txt   rfc3290.txt 
Internet Engineering Task Force Y. Bernet Network Working Group Y. Bernet
Diffserv Working Group Microsoft Request for Comments: 3290 Microsoft
INTERNET-DRAFT S. Blake Category: Informational S. Blake
Expires August 2001 Ericsson Ericsson
draft-ietf-diffserv-model-06.txt D. Grossman D. Grossman
Motorola Motorola
A. Smith A. Smith
Allegro Networks Harbour Networks
February 2001 May 2002
An Informal Management Model for Diffserv Routers An Informal Management Model for Diffserv Routers
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo provides information for the Internet community. It does
provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, and memo is unlimited.
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This document is a product of the IETF's Differentiated Services working Copyright Notice
group. Comments should be addressed to WG's mailing list at
diffserv@ietf.org. The charter for Differentiated Services may be found
at http://www.ietf.org/html.charters/diffserv-charter.html
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Distribution of this memo is unlimited.
Abstract Abstract
This document proposes an informal management model of Differentiated This document proposes an informal management model of Differentiated
Services (Diffserv) routers for use in their management and Services (Diffserv) routers for use in their management and
configuration. This model defines functional datapath elements (e.g. configuration. This model defines functional datapath elements
classifiers, meters, actions (e.g. marking, absolute dropping, counting, (e.g., classifiers, meters, actions, marking, absolute dropping,
multiplexing), algorithmic droppers, queues and schedulers. It describes counting, multiplexing), algorithmic droppers, queues and schedulers.
possible configuration parameters for these elements and how they might It describes possible configuration parameters for these elements and
be interconnected to realize the range of traffic conditioning and per- how they might be interconnected to realize the range of traffic
hop behavior (PHB) functionalities described in the Diffserv conditioning and per-hop behavior (PHB) functionalities described in
Architecture [DSARCH]. the Diffserv Architecture.
The model is intended to be abstract and capable of representing the Table of Contents
configuration parameters important to Diffserv functionality for a
variety of specific router implementations. It is not intended as a 1 Introduction ................................................. 3
guide to system implementation nor as a formal modelling description. 2 Glossary ..................................................... 4
This model serves as the rationale for the design of an SNMP MIB [DSMIB] 3 Conceptual Model ............................................. 7
and for other configuration interfaces (e.g. other policy-management 3.1 Components of a Diffserv Router ............................ 7
protocols) and, possibly, more detailed formal models (e.g. 3.1.1 Datapath ................................................. 7
[QOSDEVMOD]): these should all be consistent with this model. 3.1.2 Configuration and Management Interface ................... 9
3.1.3 Optional QoS Agent Module ................................ 10
3.2 Diffserv Functions at Ingress and Egress ................... 10
3.3 Shaping and Policing ....................................... 12
3.4 Hierarchical View of the Model ............................. 12
4 Classifiers .................................................. 13
4.1 Definition ................................................. 13
4.1.1 Filters .................................................. 15
4.1.2 Overlapping Filters ...................................... 15
4.2 Examples ................................................... 16
4.2.1 Behavior Aggregate (BA) Classifier ....................... 16
4.2.2 Multi-Field (MF) Classifier .............................. 17
4.2.3 Free-form Classifier ..................................... 17
4.2.4 Other Possible Classifiers ............................... 18
5 Meters ....................................................... 19
5.1 Examples ................................................... 20
5.1.1 Average Rate Meter ....................................... 20
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ......... 21
5.1.3 Two-Parameter Token Bucket Meter ......................... 21
5.1.4 Multi-Stage Token Bucket Meter ........................... 22
5.1.5 Null Meter ............................................... 23
6 Action Elements .............................................. 23
6.1 DSCP Marker ................................................ 24
6.2 Absolute Dropper ........................................... 24
6.3 Multiplexor ................................................ 25
6.4 Counter .................................................... 25
6.5 Null Action ................................................ 25
7 Queuing Elements ............................................. 25
7.1 Queuing Model .............................................. 26
7.1.1 FIFO Queue ............................................... 27
7.1.2 Scheduler ................................................ 28
7.1.3 Algorithmic Dropper ...................................... 30
7.2 Sharing load among traffic streams using queuing ........... 33
7.2.1 Load Sharing ............................................. 34
7.2.2 Traffic Priority ......................................... 35
8 Traffic Conditioning Blocks (TCBs) ........................... 35
8.1 TCB ........................................................ 36
8.1.1 Building blocks for Queuing .............................. 37
8.2 An Example TCB ............................................. 37
8.3 An Example TCB to Support Multiple Customers ............... 42
8.4 TCBs Supporting Microflow-based Services ................... 44
8.5 Cascaded TCBs .............................................. 47
9 Security Considerations ...................................... 47
10 Acknowledgments ............................................. 47
11 References .................................................. 47
Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 50
Authors' Addresses ............................................. 55
Full Copyright Statement........................................ 56
1. Introduction 1. Introduction
Differentiated Services (Diffserv) [DSARCH] is a set of technologies Differentiated Services (Diffserv) [DSARCH] is a set of technologies
which allow network service providers to offer services with different which allow network service providers to offer services with
kinds of network quality-of-service (QoS) objectives to different different kinds of network quality-of-service (QoS) objectives to
customers and their traffic streams. This document uses terminology different customers and their traffic streams. This document uses
defined in [DSARCH] and other work-in-progress from the IETF's Diffserv terminology defined in [DSARCH] and [NEWTERMS] (some of these
working group (some of these definitions are included here in Section 2 definitions are included here in Section 2 for completeness).
for completeness).
The premise of Diffserv networks is that routers within the core of the The premise of Diffserv networks is that routers within the core of
network handle packets in different traffic streams by forwarding them the network handle packets in different traffic streams by forwarding
using different per-hop behaviors (PHBs). The PHB to be applied is them using different per-hop behaviors (PHBs). The PHB to be applied
indicated by a Diffserv codepoint (DSCP) in the IP header of each packet is indicated by a Diffserv codepoint (DSCP) in the IP header of each
[DSFIELD]. The DSCP markings are applied either by a trusted upstream packet [DSFIELD]. The DSCP markings are applied either by a trusted
node, e.g. a customer, or by the edge routers on entry to the Diffserv upstream node, e.g., a customer, or by the edge routers on entry to
network. the Diffserv network.
The advantage of such a scheme is that many traffic streams can be The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behavior aggregates (BA) which aggregated to one of a small number of behavior aggregates (BA),
are each forwarded using the same PHB at the router, thereby simplifying which are each forwarded using the same PHB at the router, thereby
the processing and associated storage. In addition, there is no simplifying the processing and associated storage. In addition,
signaling, other than what is carried in the DSCP of each packet, and no there is no signaling other than what is carried in the DSCP of each
other related processing that is required in the core of the Diffserv packet, and no other related processing that is required in the core
network since QoS is invoked on a packet-by-packet basis. of the Diffserv network since QoS is invoked on a packet-by-packet
basis.
The Diffserv architecture enables a variety of possible services which The Diffserv architecture enables a variety of possible services
could be deployed in a network. These services are reflected to which could be deployed in a network. These services are reflected
customers at the edges of the Diffserv network in the form of a Service to customers at the edges of the Diffserv network in the form of a
Level Specification (SLS - see section 2). Whilst further discussion of Service Level Specification (SLS - see [NEWTERMS]). Whilst further
such services is outside the scope of this document (see [PDBDEF]), the discussion of such services is outside the scope of this document
ability to provide these services depends on the availability of (see [PDBDEF]), the ability to provide these services depends on the
cohesive management and configuration tools that can be used to availability of cohesive management and configuration tools that can
provision and monitor a set of Diffserv routers in a coordinated manner. be used to provision and monitor a set of Diffserv routers in a
To facilitate the development of such configuration and management tools coordinated manner. To facilitate the development of such
it is helpful to define a conceptual model of a Diffserv router that configuration and management tools it is helpful to define a
abstracts away implementation details of particular Diffserv routers conceptual model of a Diffserv router that abstracts away
from the parameters of interest for configuration and management. The implementation details of particular Diffserv routers from the
purpose of this document is to define such a model. parameters of interest for configuration and management. The purpose
of this document is to define such a model.
The basic forwarding functionality of a Diffserv router is defined in The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB]. other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
This document is not intended in any way to constrain or to dictate the This document is not intended in any way to constrain or to dictate
implementation alternatives of Diffserv routers. It is expected that the implementation alternatives of Diffserv routers. It is expected
router implementers will demonstrate a great deal of variability in that router implementers will demonstrate a great deal of variability
their implementations. To the extent that implementers are able to model in their implementations. To the extent that implementers are able
their implementations using the abstractions described in this document, to model their implementations using the abstractions described in
configuration and management tools will more readily be able to this document, configuration and management tools will more readily
configure and manage networks incorporating Diffserv routers of assorted be able to configure and manage networks incorporating Diffserv
origins. routers of assorted origins.
o Section 3 starts by describing the basic high-level blocks of a This model is intended to be abstract and capable of representing the
Diffserv router. It explains the concepts used in the model, configuration parameters important to Diffserv functionality for a
including the hierarchical management model for these blocks which variety of specific router implementations. It is not intended as a
uses low-level functional datapath elements such as Classifiers, guide to system implementation nor as a formal modeling description.
Actions, Queues. This model serves as the rationale for the design of an SNMP MIB
[DSMIB] and for other configuration interfaces (e.g., other policy-
management protocols) and, possibly, more detailed formal models
(e.g., [QOSDEVMOD]): these should all be consistent with this model.
o Section 4 describes Classifier elements. o Section 3 starts by describing the basic high-level blocks of a
Diffserv router. It explains the concepts used in the model,
including the hierarchical management model for these blocks which
uses low-level functional datapath elements such as Classifiers,
Actions, Queues.
o Section 5 discusses Meter elements. o Section 4 describes Classifier elements.
o Section 6 discusses Action elements. o Section 5 discusses Meter elements.
o Section 7 discusses the basic queueing elements of Algorithmic o Section 6 discusses Action elements.
Droppers, Queues and Schedulers and their functional behaviors
(e.g. traffic shaping).
o Section 8 shows how the low-level elements can be combined to build o Section 7 discusses the basic queuing elements of Algorithmic
modules called Traffic Conditioning Blocks (TCBs) which are useful Droppers, Queues, and Schedulers and their functional behaviors
for management purposes. (e.g., traffic shaping).
o Section 9 discusses security concerns. o Section 8 shows how the low-level elements can be combined to
build modules called Traffic Conditioning Blocks (TCBs) which are
useful for management purposes.
o Appendix A contains a brief discussion of the token bucket and o Section 9 discusses security concerns.
leaky bucket algorithms used in this model and some of the
practical effects of the use of token buckets within the Diffserv o Appendix A contains a brief discussion of the token bucket and
architecture. leaky bucket algorithms used in this model and some of the
practical effects of the use of token buckets within the Diffserv
architecture.
2. Glossary 2. Glossary
This document uses terminology which is defined in [DSARCH]. There is This document uses terminology which is defined in [DSARCH]. There
also current work-in-progress on this terminology in the IETF and some is also current work-in-progress on this terminology in the IETF and
of the definitions provided here are taken from that work. Some of the some of the definitions provided here are taken from that work. Some
terms from these other references are defined again here in order to of the terms from these other references are defined again here in
provide additional detail, along with some new terms specific to this order to provide additional detail, along with some new terms
document. specific to this document.
Absolute A functional datapath element which simply discards all Absolute A functional datapath element which simply discards all
Dropper packets arriving at its input. Dropper packets arriving at its input.
Algorithmic A functional datapath element which selectively discards Algorithmic A functional datapath element which selectively
Dropper packets that arrive at its input, based on a discarding Dropper discards packets that arrive at its input, based on a
algorithm. It has one data input and one output. discarding algorithm. It has one data input and one
output.
Classifier A functional datapath element which consists of filters Classifier A functional datapath element which consists of filters
that select matching and non-matching packets. Based that select matching and non-matching packets. Based
on this selection, packets are forwarded along the on this selection, packets are forwarded along the
appropriate datapath within the router. A classifier, appropriate datapath within the router. A classifier,
therefore, splits a single incoming traffic stream into therefore, splits a single incoming traffic stream into
multiple outgoing streams. multiple outgoing streams.
Counter A functional datapath element which updates a packet Counter A functional datapath element which updates a packet
counter and also an octet counter for every counter and also an octet counter for every
packet that passes through it. packet that passes through it.
Datapath A conceptual path taken by packets with particular Datapath A conceptual path taken by packets with particular
characteristics through a Diffserv router. Decisions characteristics through a Diffserv router. Decisions
as to the path taken by a packet are made by functional as to the path taken by a packet are made by functional
datapath elements such as Classifiers and Meters. datapath elements such as Classifiers and Meters.
Filter A set of wildcard, prefix, masked, range and/or exact Filter A set of wildcard, prefix, masked, range and/or exact
match conditions on the content of a packet's match conditions on the content of a packet's
headers or other data, and/or on implicit or derived headers or other data, and/or on implicit or derived
attributes associated with the packet. A filter is attributes associated with the packet. A filter is
said to match only if each condition is satisfied. said to match only if each condition is satisfied.
Functional A basic building block of the conceptual router. Functional A basic building block of the conceptual router.
Datapath Typical elements are Classifiers, Meters, Actions, Datapath Typical elements are Classifiers, Meters, Actions,
Element Algorithmic Droppers, Queues and Schedulers. Element Algorithmic Droppers, Queues and Schedulers.
Multiplexer A multiplexor. Multiplexer A multiplexor.
(Mux) (Mux)
Multiplexor A functional datapath element that merges multiple Multiplexor A functional datapath element that merges multiple
(Mux) traffic streams (datapaths) into a single traffic (Mux) traffic streams (datapaths) into a single traffic
stream (datapath). stream (datapath).
Non-work- A property of a scheduling algorithm such that it Non-work- A property of a scheduling algorithm such that it
conserving services packets no sooner than a scheduled departure conserving services packets no sooner than a scheduled departure
time, even if this means leaving packets queued time, even if this means leaving packets queued
while the output (e.g. a network link or connection while the output (e.g., a network link or connection
to the next element) is idle. to the next element) is idle.
Policing The process of comparing the arrival of data packets Policing The process of comparing the arrival of data packets
against a temporal profile and forwarding, delaying against a temporal profile and forwarding, delaying
or dropping them so as to make the output stream or dropping them so as to make the output stream
conformant to the profile. conformant to the profile.
Queueing A combination of functional datapath elements Queuing A combination of functional datapath elements
Block that modulates the transmission of packets belonging Block that modulates the transmission of packets belonging
to a traffic streams and determines their to a traffic streams and determines their
ordering, possibly storing them temporarily or ordering, possibly storing them temporarily or
discarding them. discarding them.
Scheduling An algorithm which determines which queue of a set Scheduling An algorithm which determines which queue of a set
algorithm of queues to service next. This may be based on the algorithm of queues to service next. This may be based on the
relative priority of the queues, on a weighted fair relative priority of the queues, on a weighted fair
bandwidth sharing policy or some other policy. Such bandwidth sharing policy or some other policy. Such
an algorithm may be either work-conserving or non- an algorithm may be either work-conserving or non-
work-conserving. work-conserving.
Service-Level A set of parameters and their values which together Service-Level A set of parameters and their values which together
Specification define the treatment offered to a traffic stream by a Specification define the treatment offered to a traffic stream by a
(SLS) Diffserv domain. (SLS) Diffserv domain.
Shaping The process of delaying packets within a traffic stream Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined temporal profile. to cause it to conform to some defined temporal
Shaping can be implemented using a queue serviced by a profile. Shaping can be implemented using a queue
non-work-conserving scheduling algorithm. serviced by a non-work-conserving scheduling algorithm.
Traffic A logical datapath entity consisting of a number of Traffic A logical datapath entity consisting of a number of
Conditioning functional datapath elements interconnected in Conditioning functional datapath elements interconnected in
Block (TCB) such a way as to perform a specific set of traffic Block (TCB) such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream. conditioning functions on an incoming traffic stream.
A TCB can be thought of as an entity with one A TCB can be thought of as an entity with one
input and one or more outputs and a set of control input and one or more outputs and a set of control
parameters. parameters.
Traffic A set of parameters and their values which together Traffic A set of parameters and their values which together
Conditioning specify a set of classfier rules and a traffic profile. Conditioning specify a set of classifier rules and a traffic
Specification A TCS is an integral element of a SLS. Specification profile. A TCS is an integral element of a SLS.
(TCS) (TCS)
Work- A property of a scheduling algorithm such that it Work- A property of a scheduling algorithm such that it
conserving services a packet, if one is available, at every conserving services a packet, if one is available, at every
transmission opportunity. transmission opportunity.
3. Conceptual Model 3. Conceptual Model
This section introduces a block diagram of a Diffserv router and This section introduces a block diagram of a Diffserv router and
describes the various components illustrated in Figure 1. Note that a describes the various components illustrated in Figure 1. Note that
Diffserv core router is likely to require only a subset of these a Diffserv core router is likely to require only a subset of these
components: the model presented here is intended to cover the case of components: the model presented here is intended to cover the case of
both Diffserv edge and core routers. both Diffserv edge and core routers.
3.1. Components of a Diffserv Router 3.1. Components of a Diffserv Router
The conceptual model includes abstract definitions for the following: The conceptual model includes abstract definitions for the following:
o Traffic Classification elements. o Traffic Classification elements.
o Metering functions. o Metering functions.
o Actions of Marking, Absolute Dropping, Counting and o Actions of Marking, Absolute Dropping, Counting, and
Multiplexing. Multiplexing.
o Queueing elements, including capabilities of algorithmic o Queuing elements, including capabilities of algorithmic
dropping and scheduling. dropping and scheduling.
o Certain combinations of the above functional datapath elements o Certain combinations of the above functional datapath elements
into higher-level blocks known as Traffic Conditioning Blocks into higher-level blocks known as Traffic Conditioning Blocks
(TCBs). (TCBs).
The components and combinations of components described in this document The components and combinations of components described in this
form building blocks that need to be manageable by Diffserv document form building blocks that need to be manageable by Diffserv
configuration and management tools. One of the goals of this document is configuration and management tools. One of the goals of this
to show how a model of a Diffserv device can be built using these document is to show how a model of a Diffserv device can be built
component blocks. This model is in the form of a connected directed using these component blocks. This model is in the form of a
acyclic graph (DAG) of functional datapath elements that describes the connected directed acyclic graph (DAG) of functional datapath
traffic conditioning and queueing behaviors that any particular packet elements that describes the traffic conditioning and queuing
will experience when forwarded to the Diffserv router. Figure 1 behaviors that any particular packet will experience when forwarded
illustrates the major functional blocks of a Diffserv router. to the Diffserv router. Figure 1 illustrates the major functional
blocks of a Diffserv router.
3.1.1. Datapath 3.1.1. Datapath
An ingress interface, routing core and egress interface are illustrated An ingress interface, routing core, and egress interface are
at the center of the diagram. In actual router implementations, there illustrated at the center of the diagram. In actual router
may be an arbitrary number of ingress and egress interfaces implementations, there may be an arbitrary number of ingress and
interconnected by the routing core. The routing core element serves as egress interfaces interconnected by the routing core. The routing
core element serves as an abstraction of a router's normal routing
and switching functionality. The routing core moves packets between
interfaces according to policies outside the scope of Diffserv (note:
it is possible that such policies for output-interface selection
might involve use of packet fields such as the DSCP but this is
outside the scope of this model). The actual queuing delay and
packet loss behavior of a specific router's switching
fabric/backplane is not modeled by the routing core; these should be
modeled using the functional datapath elements described later. The
routing core of this model can be thought of as an infinite
bandwidth, zero-delay interconnect between interfaces - properties
like the behavior of the core when overloaded need to be reflected
back into the queuing elements that are modeled around it (e.g., when
too much traffic is directed across the core at an egress interface),
the excess must either be dropped or queued somewhere: the elements
performing these functions must be modeled on one of the interfaces
involved.
The components of interest at the ingress to and egress from
interfaces are the functional datapath elements (e.g., Classifiers,
Queuing elements) that support Diffserv traffic conditioning and
per-hop behaviors [DSARCH]. These are the fundamental components
comprising a Diffserv router and are the focal point of this model.
+---------------+ +---------------+
| Diffserv | | Diffserv |
Mgmt | configuration | Mgmt | configuration |
<----+-->| & management |------------------+ <----+-->| & management |------------------+
SNMP,| | interface | | SNMP,| | interface | |
COPS | +---------------+ | COPS | +---------------+ |
etc. | | | etc. | | |
| | | | | |
| v v | v v
| +-------------+ +-------------+ | +-------------+ +-------------+
| | ingress i/f | +---------+ | egress i/f | | | ingress i/f | +---------+ | egress i/f |
--------->| classify, |-->| routing |-->| classify, |----> -------->| classify, |-->| routing |-->| classify, |---->
data | | meter, | | core | | meter |data out data | | meter, | | core | | meter |data out
in | | action, | +---------+ | action, | in | | action, | +---------+ | action, |
| | queueing | | queueing | | | queuing | | queuing |
| +-------------+ +-------------+ | +-------------+ +-------------+
| ^ ^ | ^ ^
| | | | | |
| | | | | |
| +------------+ | | +------------+ |
+-->| QOS agent | | +-->| QOS agent | |
-------->| (optional) |---------------------+ -------->| (optional) |---------------------+
QOS | (e.g. RSVP)| QOS |(e.g., RSVP)|
cntl +------------+ cntl +------------+
msgs msgs
Figure 1: Diffserv Router Major Functional Blocks
an abstraction of a router's normal routing and switching functionality.
The routing core moves packets between interfaces according to policies
outside the scope of Diffserv (note: it is possible that such policies
for output-interface selection might involve use of packet fields such
as the DSCP but this is outside the scope of this model). The actual
queueing delay and packet loss behavior of a specific router's switching
fabric/backplane is not modeled by the routing core; these should be
modeled using the functional datapath elements described later. The
routing core of this model can be thought of as an infinite bandwidth,
zero-delay backplane connecting interfaces - properties like the
behaviour of the core when overloaded need to be reflected back into the
queueing elements that are modelled around it e.g. when too much traffic
is directed across the core at an egress interface, the excess must
either be dropped or queued somewhere: the elements performing these
functions must be modelled on one of the interfaces involved.
The components of interest at the ingress to and egress from interfaces Figure 1: Diffserv Router Major Functional Blocks
are the functional datapath elements (e.g. Classifiers, Queueing
elements) that support Diffserv traffic conditioning and per-hop
behaviors [DSARCH]. These are the fundamental components comprising a
Diffserv router and are the focal point of this model.
3.1.2. Configuration and Management Interface 3.1.2. Configuration and Management Interface
Diffserv operating parameters are monitored and provisioned through this Diffserv operating parameters are monitored and provisioned through
interface. Monitored parameters include statistics regarding traffic this interface. Monitored parameters include statistics regarding
carried at various Diffserv service levels. These statistics may be traffic carried at various Diffserv service levels. These statistics
important for accounting purposes and/or for tracking compliance to may be important for accounting purposes and/or for tracking
Traffic Conditioning Specifications (TCSs) negotiated with customers. compliance to Traffic Conditioning Specifications (TCSs) negotiated
Provisioned parameters are primarily the TCS parameters for Classifiers with customers. Provisioned parameters are primarily the TCS
and Meters and the associated PHB configuration parameters for Actions parameters for Classifiers and Meters and the associated PHB
and Queueing elements. The network administrator interacts with the configuration parameters for Actions and Queuing elements. The
Diffserv configuration and management interface via one or more network administrator interacts with the Diffserv configuration and
management protocols, such as SNMP or COPS, or through other router management interface via one or more management protocols, such as
configuration tools such as serial terminal or telnet consoles. SNMP or COPS, or through other router configuration tools such as
serial terminal or telnet consoles.
Specific policy rules and goals governing the Diffserv behaviour of a Specific policy rules and goals governing the Diffserv behavior of a
router are presumed to be installed by policy management mechanisms. router are presumed to be installed by policy management mechanisms.
However, Diffserv routers are always subject to implementation limits However, Diffserv routers are always subject to implementation limits
which scope the kinds of policies which can be successfully implemented which scope the kinds of policies which can be successfully
by the router. External reporting of such implementation capabilities is implemented by the router. External reporting of such implementation
considered out of scope for this document. capabilities is considered out of scope for this document.
3.1.3. Optional QoS Agent Module 3.1.3. Optional QoS Agent Module
Diffserv routers may snoop or participate in either per-microflow or Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the per-flow-aggregate signaling of QoS requirements [E2E] (e.g., using
RSVP protocol. Snooping of RSVP messages may be used, for example, to the RSVP protocol). Snooping of RSVP messages may be used, for
learn how to classify traffic without actually participating as a RSVP example, to learn how to classify traffic without actually
protocol peer. Diffserv routers may reject or admit RSVP reservation participating as a RSVP protocol peer. Diffserv routers may reject
requests to provide a means of admission control to Diffserv-based or admit RSVP reservation requests to provide a means of admission
services or they may use these requests to trigger provisioning changes control to Diffserv-based services or they may use these requests to
for a flow-aggregation in the Diffserv network. A flow-aggregation in trigger provisioning changes for a flow-aggregation in the Diffserv
this context might be equivalent to a Diffserv BA or it may be more network. A flow-aggregation in this context might be equivalent to a
fine-grained, relying on a multi-field (MF) classifier [DSARCH]. Note Diffserv BA or it may be more fine-grained, relying on a multi-field
that the conceptual model of such a router implements the Integrated (MF) classifier [DSARCH]. Note that the conceptual model of such a
Services Model as described in [INTSERV], applying the control plane router implements the Integrated Services Model as described in
controls to the data classified and conditioned in the data plane, as [INTSERV], applying the control plane controls to the data classified
desribed in [E2E]. and conditioned in the data plane, as described in [E2E].
Note that a QoS Agent component of a Diffserv router, if present, might Note that a QoS Agent component of a Diffserv router, if present,
be active only in the control plane and not in the data plane. In this might be active only in the control plane and not in the data plane.
scenario, RSVP could be used merely to signal reservation state without In this scenario, RSVP could be used merely to signal reservation
installing any actual reservations in the data plane of the Diffserv state without installing any actual reservations in the data plane of
router: the data plane could still act purely on Diffserv DSCPs and the Diffserv router: the data plane could still act purely on
provide PHBs for handling data traffic without the normal per-microflow Diffserv DSCPs and provide PHBs for handling data traffic without the
handling expected to support some Intserv services. normal per-microflow handling expected to support some Intserv
services.
3.2. Diffserv Functions at Ingress and Egress 3.2. Diffserv Functions at Ingress and Egress
This document focuses on the Diffserv-specific components of the router. This document focuses on the Diffserv-specific components of the
Figure 2 shows a high-level view of ingress and egress interfaces of a router. Figure 2 shows a high-level view of ingress and egress
router. The diagram illustrates two Diffserv router interfaces, each interfaces of a router. The diagram illustrates two Diffserv router
having a set of ingress and a set of egress elements. It shows interfaces, each having a set of ingress and a set of egress
classification, metering, action and queueing functions which might be elements. It shows classification, metering, action and queuing
instantiated at each interface's ingress and egress. functions which might be instantiated at each interface's ingress and
egress.
The simple diagram of Figure 2 assumes that the set of Diffserv
functions to be carried out on traffic on a given interface are
independent of those functions on all other interfaces. There are some
architectures where Diffserv functions may be shared amongst multiple
interfaces e.g. processor and buffering resources that handle multiple
interfaces on the same line card before forwarding across a routing
core. The model presented in this document may be easily extended to
handle such cases; however, this topic is not treated further here as it
leads to excessive complexity in the explanation of the concepts.
In principle, if one were to construct a network entirely out of two- The simple diagram of Figure 2 assumes that the set of Diffserv
port routers (connected by LANs or similar media), then it might be functions to be carried out on traffic on a given interface are
necessary for each router to perform four QoS control functions in the independent of those functions on all other interfaces. There are
datapath on traffic in each direction: some architectures where Diffserv functions may be shared amongst
multiple interfaces (e.g., processor and buffering resources that
handle multiple interfaces on the same line card before forwarding
across a routing core). The model presented in this document may be
easily extended to handle such cases; however, this topic is not
treated further here as it leads to excessive complexity in the
explanation of the concepts.
Interface A Interface B Interface A Interface B
+-------------+ +---------+ +-------------+ +-------------+ +---------+ +-------------+
| ingress: | | | | egress: | | ingress: | | | | egress: |
| classify, | | | | classify, | | classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |---> --->| meter, |---->| |---->| meter, |--->
| action, | | | | action, | | action, | | | | action, |
| queueing | | routing | | queueing | | queuing | | routing | | queuing |
+-------------+ | core | +-------------+ +-------------+ | core | +-------------+
| egress: | | | | ingress: | | egress: | | | | ingress: |
| classify, | | | | classify, | | classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<--- <---| meter, |<----| |<----| meter, |<---
| action, | | | | action, | | action, | | | | action, |
| queueing | +---------+ | queueing | | queuing | +---------+ | queuing |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 2. Traffic Conditioning and Queueing Elements Figure 2. Traffic Conditioning and Queuing Elements
- Classify each message according to some set of rules, possibly just In principle, if one were to construct a network entirely out of
a "match everything" rule. two-port routers (connected by LANs or similar media), then it might
be necessary for each router to perform four QoS control functions in
the datapath on traffic in each direction:
- If necessary, determine whether the data stream the message is part - Classify each message according to some set of rules, possibly
of is within or outside its rate by metering the stream. just a "match everything" rule.
- Perform a set of resulting actions, including applying a drop - If necessary, determine whether the data stream the message is
policy appropriate to the classification and queue in question and part of is within or outside its rate by metering the stream.
perhaps additionally marking the traffic with a Differentiated
Services Code Point (DSCP) [DSFIELD].
- Enqueue the traffic for output in the appropriate queue. The - Perform a set of resulting actions, including applying a drop
scheduling of output from this queue may lead to shaping of the policy appropriate to the classification and queue in question and
traffic or may simply cause it to be forwarded with some minimum perhaps additionally marking the traffic with a Differentiated
rate or maximum latency assurance. Services Code Point (DSCP) [DSFIELD].
If the network is now built out of N-port routers, the expected behavior - Enqueue the traffic for output in the appropriate queue. The
of the network should be identical. Therefore, this model must provide scheduling of output from this queue may lead to shaping of the
for essentially the same set of functions at the ingress as on the traffic or may simply cause it to be forwarded with some minimum
egress of a router's interfaces. The one point of difference in the rate or maximum latency assurance.
model between ingress and the egress is that all traffic at the egress
of an interface is queued, while traffic at the ingress to an interface
is likely to be queued only for shaping purposes, if at all. Therefore,
equivalent functional datapath elements may be modelled at both the
ingress to and egress from an interface.
Note that it is not mandatory that each of these functional datapath If the network is now built out of N-port routers, the expected
elements be implemented at both ingress and egress; equally, the model behavior of the network should be identical. Therefore, this model
allows that multiple sets of these elements may be placed in series must provide for essentially the same set of functions at the ingress
and/or in parallel at ingress or at egress. The arrangement of elements as on the egress of a router's interfaces. The one point of
is dependent on the service requirements on a particular interface on a difference in the model between ingress and the egress is that all
particular router. By modelling these elements at both ingress and traffic at the egress of an interface is queued, while traffic at the
egress, it is not implied that they must be implemented in this way in a ingress to an interface is likely to be queued only for shaping
specific router. For example, a router may implement all shaping and PHB purposes, if at all. Therefore, equivalent functional datapath
queueing at the interface egress or may instead implement it only at the elements may be modeled at both the ingress to and egress from an
ingress. Furthermore, the classification needed to map a packet to an interface.
egress queue (if present) need not be implemented at the egress but
instead might be implemented at the ingress, with the packet passed
through the routing core with in-band control information to allow for
egress queue selection.
Specifically, some interfaces will be at the outer "edge" and some will Note that it is not mandatory that each of these functional datapath
be towards the "core" of the Diffserv domain. It is to be expected (from elements be implemented at both ingress and egress; equally, the
the general principles guiding the motivation of Diffserv) that "edge" model allows that multiple sets of these elements may be placed in
interfaces, or at least the routers that contain them, will implement series and/or in parallel at ingress or at egress. The arrangement
more complexity and require more configuration than those in the core of elements is dependent on the service requirements on a particular
although this is obviously not a requirement. interface on a particular router. By modeling these elements at both
ingress and egress, it is not implied that they must be implemented
in this way in a specific router. For example, a router may
implement all shaping and PHB queuing at the interface egress or may
instead implement it only at the ingress. Furthermore, the
classification needed to map a packet to an egress queue (if present)
need not be implemented at the egress but instead might be
implemented at the ingress, with the packet passed through the
routing core with in-band control information to allow for egress
queue selection.
Specifically, some interfaces will be at the outer "edge" and some
will be towards the "core" of the Diffserv domain. It is to be
expected (from the general principles guiding the motivation of
Diffserv) that "edge" interfaces, or at least the routers that
contain them, will implement more complexity and require more
configuration than those in the core although this is obviously not a
requirement.
3.3. Shaping and Policing 3.3. Shaping and Policing
Diffserv nodes may apply shaping, policing and/or marking to traffic Diffserv nodes may apply shaping, policing and/or marking to traffic
streams that exceed the bounds of their TCS in order to prevent one streams that exceed the bounds of their TCS in order to prevent one
traffic stream from seizing more than its share of resources from a traffic stream from seizing more than its share of resources from a
Diffserv network. In this model, Shaping, sometimes considered as a TC Diffserv network. In this model, Shaping, sometimes considered as a
action, is treated as a function of queueing elements - see section 7. TC action, is treated as a function of queuing elements - see section
Algorithmic Dropping techniques (e.g. RED) are similarly treated since 7. Algorithmic Dropping techniques (e.g., RED) are similarly treated
these often are closely associated with queues. Policing is modelled as since they are often closely associated with queues. Policing is
either a concatenation of a Meter with an Absolute Dropper or as a modeled as either a concatenation of a Meter with an Absolute Dropper
concatenation of an Algorithmic Dropper with a Scheduler. These elements or as a concatenation of an Algorithmic Dropper with a Scheduler.
will discard packets which exceed the TCS. These elements will discard packets which exceed the TCS.
3.4. Hierarchical View of the Model 3.4. Hierarchical View of the Model
>From a device-level configuration management perspective, the following From a device-level configuration management perspective, the
hierarchy exists: following hierarchy exists:
At the lowest level considered here, are individual functional At the lowest level considered here, there are individual
datapath elements, each with their own configuration parameters and functional datapath elements, each with their own configuration
management counters and flags. parameters and management counters and flags.
At the next level, the network administrator manages groupings of At the next level, the network administrator manages groupings of
these functional datapath elements interconnected in a DAG. These these functional datapath elements interconnected in a DAG. These
functional datapath elements are organized in self-contained TCBs functional datapath elements are organized in self-contained TCBs
which are used to implement some desired network policy (see which are used to implement some desired network policy (see
Section 8). One or more TCBs may be instantiated at each Section 8). One or more TCBs may be instantiated at each
interface's ingress or egress; they may be connected in series interface's ingress or egress; they may be connected in series
and/or in parallel configurations on the multiple outputs of a and/or in parallel configurations on the multiple outputs of a
preceding TCB. A TCB can be thought of as a "black box" with one preceding TCB. A TCB can be thought of as a "black box" with one
input and one or more outputs (in the data path). Each interface input and one or more outputs (in the data path). Each interface
may have a different TCB configuration and each direction (ingress may have a different TCB configuration and each direction (ingress
or egress) may too. or egress) may too.
At the topmost level considered here, the network administrator At the topmost level considered here, the network administrator
manages interfaces. Each interface has ingress and egress manages interfaces. Each interface has ingress and egress
functionality, with each of these expressed as one or more TCBs. functionality, with each of these expressed as one or more TCBs.
This level of the hierarchy is what was illustrated in Figure 2. This level of the hierarchy is what was illustrated in Figure 2.
Further levels may be built on top of this hierarchy, in particular ones Further levels may be built on top of this hierarchy, in particular
for aiding in the repetitive configuration tasks likely for routers with ones for aiding in the repetitive configuration tasks likely for
many interfaces: some such "template" tools for Diffserv routers are routers with many interfaces: some such "template" tools for Diffserv
outside the scope of this model but are under study by other working routers are outside the scope of this model but are under study by
groups within IETF. other working groups within IETF.
4. Classifiers 4. Classifiers
4.1. Definition 4.1. Definition
Classification is performed by a classifier element. Classifiers are 1:N Classification is performed by a classifier element. Classifiers are
(fan-out) devices: they take a single traffic stream as input and 1:N (fan-out) devices: they take a single traffic stream as input and
generate N logically separate traffic streams as output. Classifiers are generate N logically separate traffic streams as output. Classifiers
parameterized by filters and output streams. Packets from the input are parameterized by filters and output streams. Packets from the
stream are sorted into various output streams by filters which match the input stream are sorted into various output streams by filters which
contents of the packet or possibly match other attributes associated match the contents of the packet or possibly match other attributes
with the packet. Various types of classifiers using different filters associated with the packet. Various types of classifiers using
are described in the following sections. Figure 3 illustrates a different filters are described in the following sections. Figure 3
classifier, where the outputs connect to succeeding functional datapath illustrates a classifier, where the outputs connect to succeeding
elements. functional datapath elements.
The simplest possible Classifier element is one that matches all packets The simplest possible Classifier element is one that matches all
that are applied at its input. In this case, the Classifier element is packets that are applied at its input. In this case, the Classifier
just a no-op and may be omitted. element is just a no-op and may be omitted.
Note that we allow a Multiplexor (see Section 6.5) before the Classifier Note that we allow a Multiplexor (see Section 6.5) before the
to allow input from multiple traffic streams. For example, if traffic Classifier to allow input from multiple traffic streams. For
streams originating from multiple ingress interfaces feed through a example, if traffic streams originating from multiple ingress
single Classifier then the interface number could be one of the packet interfaces feed through a single Classifier then the interface number
classification keys used by the Classifier. This optimization may be could be one of the packet classification keys used by the
important for scalability in the management plane. Classifiers may also Classifier. This optimization may be important for scalability in
be cascaded in sequence to perform more complex lookup operations whilst the management plane. Classifiers may also be cascaded in sequence
still maintaining such scalability. to perform more complex lookup operations whilst still maintaining
such scalability.
Another example of a packet attribute could be an integer representing Another example of a packet attribute could be an integer
the BGP community string associated with the packet's best-matching representing the BGP community string associated with the packet's
route. Other contextual information may also be used by a Classifier best-matching route. Other contextual information may also be used
e.g. knowledge that a particular interface faces a Diffserv domain or a by a Classifier (e.g., knowledge that a particular interface faces a
legacy IP TOS domain [DSARCH] could be used when determining whether a Diffserv domain or a legacy IP TOS domain [DSARCH] could be used when
determining whether a DSCP is present or not).
unclassified classified unclassified classified
traffic traffic traffic traffic
+------------+ +------------+
| |--> match Filter1 --> OutputA | |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB ------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC | |--> no match --> OutputC
+------------+ +------------+
Figure 3. An Example Classifier Figure 3. An Example Classifier
DSCP is present or not. The following BA classifier separates traffic into one of three
output streams based on matching filters:
The following BA classifier separates traffic into one of three output
streams based on matching filters:
Filter Matched Output Stream Filter Matched Output Stream
-------------- --------------- -------------- ---------------
Filter1 A Filter1 A
Filter2 B Filter2 B
no match C no match C
Where the filters are defined to be the following BA filters ([DSARCH], Where the filters are defined to be the following BA filters
Section 4.2.1 ): ([DSARCH], Section 4.2.1):
Filter DSCP Filter DSCP
------ ------ ------ ------
Filter1 101010 Filter1 101010
Filter2 111111 Filter2 111111
Filter3 ****** (wildcard) Filter3 ****** (wildcard)
4.1.1. Filters 4.1.1. Filters
A filter consists of a set of conditions on the component values of a A filter consists of a set of conditions on the component values of a
packet's classification key (the header values, contents, and attributes packet's classification key (the header values, contents, and
relevant for classification). In the BA classifier example above, the attributes relevant for classification). In the BA classifier
classification key consists of one packet header field, the DSCP, and example above, the classification key consists of one packet header
both Filter1 and Filter2 specify exact-match conditions on the value of field, the DSCP, and both Filter1 and Filter2 specify exact-match
the DSCP. Filter3 is a wildcard default filter which matches every conditions on the value of the DSCP. Filter3 is a wildcard default
packet, but which is only selected in the event that no other more filter which matches every packet, but which is only selected in the
specific filter matches. event that no other more specific filter matches.
In general there are a set of possible component conditions including In general there are a set of possible component conditions including
exact, prefix, range, masked and wildcard matches. Note that ranges can exact, prefix, range, masked and wildcard matches. Note that ranges
be represented (with less efficiency) as a set of prefixes and that can be represented (with less efficiency) as a set of prefixes and
prefix matches are just a special case of both masked and range matches. that prefix matches are just a special case of both masked and range
matches.
In the case of a MF classifier, the classification key consists of a In the case of a MF classifier, the classification key consists of a
number of packet header fields. The filter may specify a different number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example below condition for each key component, as illustrated in the example below
for a IPv4/TCP classifier: for a IPv4/TCP classifier:
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------ ------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003 Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address and In this example, the fourth octet of the destination IPv4 address and
the source TCP port are wildcard or "don't care". the source TCP port are wildcard or "don't care".
MF classification of IP-fragmented packets is impossible if the filter MF classification of IP-fragmented packets is impossible if the
uses transport-layer port numbers e.g. TCP port numbers. MTU-discovery filter uses transport-layer port numbers (e.g., TCP port numbers).
is therefore a prerequisite for proper operation of a Diffserv network MTU-discovery is therefore a prerequisite for proper operation of a
that uses such classifiers. Diffserv network that uses such classifiers.
4.1.2. Overlapping Filters 4.1.2. Overlapping Filters
Note that it is easy to define sets of overlapping filters in a Note that it is easy to define sets of overlapping filters in a
classifier. For example: classifier. For example:
Filter IPv4 Src Addr IPv4 Dest Addr Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- -------------- ------ ------------- --------------
Filter5 172.31.8.X/24 X/0 Filter5 172.31.8.X/24 X/0
Filter6 X/0 172.30.10.1/32 Filter6 X/0 172.30.10.1/32
A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr 172.30.10.1} A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr
cannot be uniquely classified by this pair of filters and so a 172.30.10.1} cannot be uniquely classified by this pair of filters
precedence must be established between Filter5 and Filter6 in order to and so a precedence must be established between Filter5 and Filter6
break the tie. This precedence must be established either (a) by a in order to break the tie. This precedence must be established
manager which knows that the router can accomplish this particular either (a) by a manager which knows that the router can accomplish
ordering e.g. by means of reported capabilities, or (b) by the router this particular ordering (e.g., by means of reported capabilities),
along with a mechanism to report to a manager which precedence is being or (b) by the router along with a mechanism to report to a manager
used. Such precedence mechanisms must be supported in any translation of which precedence is being used. Such precedence mechanisms must be
this model into specific syntax for configuration and management supported in any translation of this model into specific syntax for
protocols. configuration and management protocols.
As another example, one might want first to disallow certain As another example, one might want first to disallow certain
applications from using the network at all, or to classify some applications from using the network at all, or to classify some
individual traffic streams that are not Diffserv-marked. Traffic that is individual traffic streams that are not Diffserv-marked. Traffic
not classified by those tests might then be inspected for a DSCP. The that is not classified by those tests might then be inspected for a
word "then" implies sequence and this must be specified by means of DSCP. The word "then" implies sequence and this must be specified by
precedence. means of precedence.
An unambiguous classifier requires that every possible classification An unambiguous classifier requires that every possible classification
key match at least one filter (possibly the wildcard default) and that key match at least one filter (possibly the wildcard default) and
any ambiguity between overlapping filters be resolved by precedence. that any ambiguity between overlapping filters be resolved by
Therefore, the classifiers on any given interface must be "complete" and precedence. Therefore, the classifiers on any given interface must
will often include an "everything else" filter as the lowest precedence be "complete" and will often include an "everything else" filter as
element in order for the result of classification to be deterministic. the lowest precedence element in order for the result of
Note that this completeness is only required of the first classifier classification to be deterministic. Note that this completeness is
that incoming traffic will meet as it enters an interface - subsequent only required of the first classifier that incoming traffic will meet
classifiers on an interface only need to handle the traffic that it is as it enters an interface - subsequent classifiers on an interface
known that they will receive. only need to handle the traffic that it is known that they will
receive.
This model of classifier operation makes the assumption that all filters This model of classifier operation makes the assumption that all
of the same precedence be applied simultaneously. Whilst convenient from filters of the same precedence be applied simultaneously. Whilst
a modelling point-of-view, this may or may not be how the classifier is convenient from a modeling point-of-view, this may or may not be how
actually implemented - this assumption is not intended to dictate how the classifier is actually implemented - this assumption is not
the implementation actually handles this, merely to clearly define the intended to dictate how the implementation actually handles this,
required end result. merely to clearly define the required end result.
4.2. Examples 4.2. Examples
4.2.1. Behaviour Aggregate (BA) Classifier 4.2.1. Behavior Aggregate (BA) Classifier
The simplest Diffserv classifier is a behavior aggregate (BA) classifier The simplest Diffserv classifier is a behavior aggregate (BA)
[DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a classifier [DSARCH]. A BA classifier uses only the Diffserv
packet's IP header to determine the logical output stream to which the codepoint (DSCP) in a packet's IP header to determine the logical
packet should be directed. We allow only an exact-match condition on output stream to which the packet should be directed. We allow only
this field because the assigned DSCP values have no structure, and an exact-match condition on this field because the assigned DSCP
therefore no subset of DSCP bits are significant. values have no structure, and therefore no subset of DSCP bits are
significant.
The following defines a possible BA filter: The following defines a possible BA filter:
Filter8: Filter8:
Type: BA Type: BA
Value: 111000 Value: 111000
4.2.2. Multi-Field (MF) Classifier 4.2.2. Multi-Field (MF) Classifier
Another type of classifier is a multi-field (MF) classifier [DSARCH]. Another type of classifier is a multi-field (MF) classifier [DSARCH].
This classifies packets based on one or more fields in the packet This classifies packets based on one or more fields in the packet
(possibly including the DSCP). A common type of MF classifier is a 6- (possibly including the DSCP). A common type of MF classifier is a
tuple classifier that classifies based on six fields from the IP and TCP 6-tuple classifier that classifies based on six fields from the IP
or UDP headers (destination address, source address, IP protocol, source and TCP or UDP headers (destination address, source address, IP
port, destination port, and DSCP). MF classifiers may classify on other protocol, source port, destination port, and DSCP). MF classifiers
fields such as MAC addresses, VLAN tags, link-layer traffic class fields may classify on other fields such as MAC addresses, VLAN tags, link-
or other higher-layer protocol fields. layer traffic class fields, or other higher-layer protocol fields.
The following defines a possible MF filter: The following defines a possible MF filter:
Filter9: Filter9:
Type: IPv4-6-tuple Type: IPv4-6-tuple
IPv4DestAddrValue: 0.0.0.0 IPv4DestAddrValue: 0.0.0.0
IPv4DestAddrMask: 0.0.0.0 IPv4DestAddrMask: 0.0.0.0
IPv4SrcAddrValue: 172.31.8.0 IPv4SrcAddrValue: 172.31.8.0
IPv4SrcAddrMask: 255.255.255.0 IPv4SrcAddrMask: 255.255.255.0
IPv4DSCP: 28 IPv4DSCP: 28
IPv4Protocol: 6 IPv4Protocol: 6
IPv4DestL4PortMin: 0 IPv4DestL4PortMin: 0
IPv4DestL4PortMax: 65535 IPv4DestL4PortMax: 65535
IPv4SrcL4PortMin: 20 IPv4SrcL4PortMin: 20
IPv4SrcL4PortMax: 20 IPv4SrcL4PortMax: 20
A similar type of classifier can be defined for IPv6. A similar type of classifier can be defined for IPv6.
4.2.3. Free-form Classifier 4.2.3. Free-form Classifier
A Free-form classifier is made up of a set of user definable arbitrary A Free-form classifier is made up of a set of user definable
filters each made up of {bit-field size, offset (from head of packet), arbitrary filters each made up of {bit-field size, offset (from head
mask}: of packet), mask}:
Classifier2: Classifier2:
Filter12: OutputA Filter12: OutputA
Filter13: OutputB Filter13: OutputB
Default: OutputC Default: OutputC
Filter12: Filter12:
Type: FreeForm Type: FreeForm
SizeBits: 3 (bits) SizeBits: 3 (bits)
Offset: 16 (bytes) Offset: 16 (bytes)
Value: 100 (binary) Value: 100 (binary)
Mask: 101 (binary) Mask: 101 (binary)
Filter13: Filter13:
Type: FreeForm Type: FreeForm
SizeBits: 12 (bits) SizeBits: 12 (bits)
skipping to change at page 16, line 32 skipping to change at page 18, line 18
Value: 100 (binary) Value: 100 (binary)
Mask: 101 (binary) Mask: 101 (binary)
Filter13: Filter13:
Type: FreeForm Type: FreeForm
SizeBits: 12 (bits) SizeBits: 12 (bits)
Offset: 16 (bytes) Offset: 16 (bytes)
Value: 100100000000 (binary) Value: 100100000000 (binary)
Mask: 111111111111 (binary) Mask: 111111111111 (binary)
Free-form filters can be combined into filter groups to form very Free-form filters can be combined into filter groups to form very
powerful filters. powerful filters.
4.2.4. Other Possible Classifiers 4.2.4. Other Possible Classifiers
Classification may also be performed based on information at the Classification may also be performed based on information at the
datalink layer below IP (e.g. VLAN or datalink-layer priority) or datalink layer below IP (e.g., VLAN or datalink-layer priority) or
perhaps on the ingress or egress IP, logical or physical interface perhaps on the ingress or egress IP, logical or physical interface
identifier. (e.g. the incoming channel number on a channelized identifier (e.g., the incoming channel number on a channelized
interface). A classifier that filters based on IEEE 802.1p Priority and interface). A classifier that filters based on IEEE 802.1p Priority
on 802.1Q VLAN-ID might be represented as: and on 802.1Q VLAN-ID might be represented as:
Classifier3: Classifier3:
Filter14 AND Filter15: OutputA Filter14 AND Filter15: OutputA
Default: OutputB Default: OutputB
Filter14: -- priority 4 or 5 Filter14: -- priority 4 or 5
Type: Ieee8021pPriority Type: Ieee8021pPriority
Value: 100 (binary) Value: 100 (binary)
Mask: 110 (binary) Mask: 110 (binary)
Filter15: -- VLAN 2304 Filter15: -- VLAN 2304
Type: Ieee8021QVlan Type: Ieee8021QVlan
Value: 100100000000 (binary) Value: 100100000000 (binary)
Mask: 111111111111 (binary) Mask: 111111111111 (binary)
Such classifiers may be the subject of other standards or may be Such classifiers may be the subject of other standards or may be
proprietary to a router vendor but they are not discussed further here. proprietary to a router vendor but they are not discussed further
here.
5. Meters 5. Meters
Metering is defined in [DSARCH]. Diffserv network providers may choose Metering is defined in [DSARCH]. Diffserv network providers may
to offer services to customers based on a temporal (i.e., rate) profile choose to offer services to customers based on a temporal (i.e.,
within which the customer submits traffic for the service. In this rate) profile within which the customer submits traffic for the
event, a meter might be used to trigger real-time traffic conditioning service. In this event, a meter might be used to trigger real-time
actions (e.g., marking) by routing a non-conforming packet through an traffic conditioning actions (e.g., marking) by routing a non-
appropriate next-stage action element. Alternatively, by counting conforming packet through an appropriate next-stage action element.
conforming and/or non-conforming traffic using a Counter element Alternatively, by counting conforming and/or non-conforming traffic
downstream of the Meter, it might also be used to help in collecting using a Counter element downstream of the Meter, it might also be
data for out-of-band management functions such as billing applications. used to help in collecting data for out-of-band management functions
such as billing applications.
Meters are logically 1:N (fan-out) devices (although a multiplexor can Meters are logically 1:N (fan-out) devices (although a multiplexor
be used in front of a meter). Meters are parameterized by a temporal can be used in front of a meter). Meters are parameterized by a
profile and by conformance levels, each of which is associated with a temporal profile and by conformance levels, each of which is
meter's output. Each output can be connected to another functional associated with a meter's output. Each output can be connected to
element. another functional element.
Note that this model of a meter differs slightly from that described in Note that this model of a meter differs slightly from that described
[DSARCH]. In that description the meter is not a datapath element but is in [DSARCH]. In that description the meter is not a datapath element
instead used to monitor the traffic stream and send control signals to but is instead used to monitor the traffic stream and send control
action elements to dynamically modulate their behavior based on the signals to action elements to dynamically modulate their behavior
conformance of the packet. This difference in the description does not based on the conformance of the packet. This difference in the
change the function of a meter. Figure 4 illustrates a meter with 3 description does not change the function of a meter. Figure 4
levels of conformance. illustrates a meter with 3 levels of conformance.
In some Diffserv examples e.g. [AF-PHB], three levels of conformance are In some Diffserv examples (e.g., [AF-PHB]), three levels of
discussed in terms of colors, with green representing conforming, yellow conformance are discussed in terms of colors, with green representing
representing partially conforming and red representing non-conforming. conforming, yellow representing partially conforming and red
These different conformance levels may be used to trigger different representing non-conforming. These different conformance levels may
queueing, marking or dropping treatment later on in the processing. be used to trigger different queuing, marking or dropping treatment
Other example meters use a binary notion of conformance; in the general later on in the processing. Other example meters use a binary notion
case N levels of conformance can be supported. In general there is no of conformance; in the general case N levels of conformance can be
constraint on the type of functional datapath element following a meter supported. In general there is no constraint on the type of
output, but care must be taken not to inadvertently configure a datapath functional datapath element following a meter output, but care must
that results in packet reordering that is not consistent with the be taken not to inadvertently configure a datapath that results in
requirements of the relevant PHB specification. packet reordering that is not consistent with the requirements of the
relevant PHB specification.
unmetered metered unmetered metered
traffic traffic traffic traffic
+---------+ +---------+
| |--------> conformance A | |--------> conformance A
--------->| meter |--------> conformance B --------->| meter |--------> conformance B
| |--------> conformance C | |--------> conformance C
+---------+ +---------+
Figure 4. A Generic Meter Figure 4. A Generic Meter
A meter, according to this model, measures the rate at which packets A meter, according to this model, measures the rate at which packets
making up a stream of traffic pass it, compares the rate to some set of making up a stream of traffic pass it, compares the rate to some set
thresholds and produces some number of potential results (two or more): of thresholds, and produces some number of potential results (two or
a given packet is said to be "conformant" to a level of the meter if, at more): a given packet is said to be "conformant" to a level of the
the time that the packet is being examined, the stream appears to be meter if, at the time that the packet is being examined, the stream
within the rate limit for the profile associated with that level. A appears to be within the rate limit for the profile associated with
fuller discussion of conformance to meter profiles (and the associated that level. A fuller discussion of conformance to meter profiles
requirements that this places on the schedulers upstream) is provided in (and the associated requirements that this places on the schedulers
Appendix A. upstream) is provided in Appendix A.
5.1. Examples 5.1. Examples
The following are some examples of possible meters. The following are some examples of possible meters.
5.1.1. Average Rate Meter 5.1.1. Average Rate Meter
An example of a very simple meter is an average rate meter. This type of An example of a very simple meter is an average rate meter. This
meter measures the average rate at which packets are submitted to it type of meter measures the average rate at which packets are
over a specified averaging time. submitted to it over a specified averaging time.
An average rate profile may take the following form: An average rate profile may take the following form:
Meter1: Meter1:
Type: AverageRate Type: AverageRate
Profile: Profile1 Profile: Profile1
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: Counter1 NonConformingOutput: Counter1
Profile1: Profile1:
Type: AverageRate Type: AverageRate
AverageRate: 120 kbps AverageRate: 120 kbps
Delta: 100 msec Delta: 100 msec
A Meter measuring against this profile would continually maintain a A Meter measuring against this profile would continually maintain a
count that indicates the total number and/or cumulative byte-count of count that indicates the total number and/or cumulative byte-count of
packets arriving between time T (now) and time T - 100 msecs. So long as packets arriving between time T (now) and time T - 100 msecs. So
an arriving packet does not push the count over 12 kbits in the last 100 long as an arriving packet does not push the count over 12 kbits in
msec then the packet would be deemed conforming. Any packet that pushes the last 100 msec, the packet would be deemed conforming. Any packet
the count over 12 kbits would be deemed non-conforming. Thus, this Meter that pushes the count over 12 kbits would be deemed non-conforming.
deems packets to correspond to one of two conformance levels: conforming Thus, this Meter deems packets to correspond to one of two
or non-conforming and sends them on for the appropriate subsequent conformance levels: conforming or non-conforming, and sends them on
treatment. for the appropriate subsequent treatment.
5.1.2. Exponential Weighted Moving Average (EWMA) Meter 5.1.2. Exponential Weighted Moving Average (EWMA) Meter
The EWMA form of Meter is easy to implement in hardware and can be The EWMA form of Meter is easy to implement in hardware and can be
parameterized as follows: parameterized as follows:
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t) avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta t = t' + Delta
For a packet arriving at time t: For a packet arriving at time t:
if (avg_rate(t) > AverageRate) if (avg_rate(t) > AverageRate)
non-conforming non-conforming
else else
conforming conforming
"Gain" controls the time constant (e.g. frequency response) of what is "Gain" controls the time constant (e.g., frequency response) of what
essentially a simple IIR low-pass filter. "rate(t)" measures the number is essentially a simple IIR low-pass filter. "Rate(t)" measures the
of incoming bytes in a small fixed sampling interval, Delta. Any packet number of incoming bytes in a small fixed sampling interval, Delta.
that arrives and pushes the average rate over a predefined rate Any packet that arrives and pushes the average rate over a predefined
AverageRate is deemed non-conforming. An EWMA Meter profile might look rate AverageRate is deemed non-conforming. An EWMA Meter profile
something like the following: might look something like the following:
Meter2: Meter2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
Profile: Profile2 Profile: Profile2
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile2: Profile2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
AverageRate: 25 kbps AverageRate: 25 kbps
Delta: 10 usec Delta: 10 usec
Gain: 1/16 Gain: 1/16
5.1.3. Two-Parameter Token Bucket Meter 5.1.3. Two-Parameter Token Bucket Meter
A more sophisticated Meter might measure conformance to a token bucket A more sophisticated Meter might measure conformance to a token
(TB) profile. A TB profile generally has two parameters, an average bucket (TB) profile. A TB profile generally has two parameters, an
token rate, R, and a burst size, B. TB Meters compare the arrival rate average token rate, R, and a burst size, B. TB Meters compare the
of packets to the average rate specified by the TB profile. Logically, arrival rate of packets to the average rate specified by the TB
tokens accumulate in a bucket at the average rate, R, up to a maximum profile. Logically, tokens accumulate in a bucket at the average
credit which is the burst size, B. When a packet of length L arrives, a rate, R, up to a maximum credit which is the burst size, B. When a
conformance test is applied. There are at least two such tests in packet of length L arrives, a conformance test is applied. There are
widespread use: at least two such tests in widespread use:
Strict conformance Strict conformance
Packets of length L bytes are considered conforming only if there Packets of length L bytes are considered conforming only if there
are sufficient tokens available in the bucket at the time of packet are sufficient tokens available in the bucket at the time of
arrival for the complete packet i.e. the current depth is greater packet arrival for the complete packet (i.e., the current depth is
than or equal to L: no tokens may be borrowed from future token greater than or equal to L): no tokens may be borrowed from future
allocations. For examples of this approach, see [SRTCM] and token allocations. For examples of this approach, see [SRTCM] and
[TRTCM]. [TRTCM].
Loose conformance Loose conformance
Packets of length L bytes are considered conforming if any tokens Packets of length L bytes are considered conforming if any tokens
are available in the bucket at the time of packet arrival: up to L are available in the bucket at the time of packet arrival: up to L
bytes may then be borrowed from future token allocations. bytes may then be borrowed from future token allocations.
Packets are allowed to exceed the average rate in bursts up to the burst Packets are allowed to exceed the average rate in bursts up to the
size. For further discussion of loose and strict conformance to token burst size. For further discussion of loose and strict conformance
bucket profiles, as well as system and implementation issues, see to token bucket profiles, as well as system and implementation
Appendix A. issues, see Appendix A.
A two-parameter TB meter has exactly two possible conformance levels A two-parameter TB meter has exactly two possible conformance levels
(conforming, non-conforming). Such a meter might appear as follows: (conforming, non-conforming). Such a meter might appear as follows:
Meter3: Meter3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
Profile: Profile3 Profile: Profile3
ConformanceType: loose ConformanceType: loose
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile3: Profile3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 200 kbps AverageRate: 200 kbps
BurstSize: 100 kbytes BurstSize: 100 kbytes
5.1.4. Multi-Stage Token Bucket Meter 5.1.4. Multi-Stage Token Bucket Meter
More complicated TB meters might define multiple burst sizes and more More complicated TB meters might define multiple burst sizes and more
conformance levels. Packets found to exceed the larger burst size are conformance levels. Packets found to exceed the larger burst size
deemed non-conforming. Packets found to exceed the smaller burst size are deemed non-conforming. Packets found to exceed the smaller burst
are deemed partially-conforming. Packets exceeding neither are deemed size are deemed partially-conforming. Packets exceeding neither are
conforming. Some token bucket meters designed for Diffserv networks are deemed conforming. Some token bucket meters designed for Diffserv
described in more detail in [SRTCM, TRTCM]; in some of these references, networks are described in more detail in [SRTCM, TRTCM]; in some of
three levels of conformance are discussed in terms of colors with green these references, three levels of conformance are discussed in terms
representing conforming, yellow representing partially conforming and of colors with green representing conforming, yellow representing
red representing non-conforming. Note that these multiple-conformance- partially conforming, and red representing non-conforming. Note that
level meters can sometimes be implemented using an appropriate sequence these multiple-conformance-level meters can sometimes be implemented
of multiple two-parameter TB meters. using an appropriate sequence of multiple two-parameter TB meters.
A profile for a multi-stage TB meter with three levels of conformance A profile for a multi-stage TB meter with three levels of conformance
might look as follows: might look as follows:
Meter4: Meter4:
Type: TwoRateTokenBucket Type: TwoRateTokenBucket
ProfileA: Profile4 ProfileA: Profile4
ConformanceTypeA: strict ConformanceTypeA: strict
ConformingOutputA: Queue1 ConformingOutputA: Queue1
ProfileB: Profile5 ProfileB: Profile5
ConformanceTypeB: strict ConformanceTypeB: strict
ConformingOutputB: Marker1 ConformingOutputB: Marker1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile4: Profile4:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 20 kbytes BurstSize: 20 kbytes
skipping to change at page 21, line 35 skipping to change at page 23, line 33
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 20 kbytes BurstSize: 20 kbytes
Profile5: Profile5:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 100 kbytes BurstSize: 100 kbytes
5.1.5. Null Meter 5.1.5. Null Meter
A null meter has only one output: always conforming, and no associated A null meter has only one output: always conforming, and no
temporal profile. Such a meter is useful to define in the event that the associated temporal profile. Such a meter is useful to define in the
configuration or management interface does not have the flexibility to event that the configuration or management interface does not have
omit a meter in a datapath segment. the flexibility to omit a meter in a datapath segment.
Meter5: Meter5:
Type: NullMeter Type: NullMeter
Output: Queue1 Output: Queue1
6. Action Elements 6. Action Elements
The classifiers and meters described up to this point are fan-out The classifiers and meters described up to this point are fan-out
elements which are generally used to determine the appropriate action to elements which are generally used to determine the appropriate action
apply to a packet. The set of possible actions that can then be applied to apply to a packet. The set of possible actions that can then be
include: applied include:
- Marking
- Absolute Dropping - Marking
- Multiplexing - Absolute Dropping
- Multiplexing
- Counting - Counting
- Null action - do nothing - Null action - do nothing
The corresponding action elements are described in the following The corresponding action elements are described in the following
sections. sections.
6.1. DSCP Marker 6.1. DSCP Marker
DSCP Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an DSCP Markers are 1:1 elements which set a codepoint (e.g., the DSCP
IP header). DSCP Markers may also act on unmarked packets (e.g. those in an IP header). DSCP Markers may also act on unmarked packets
submitted with DSCP of zero) or may re-mark previously marked packets. (e.g., those submitted with DSCP of zero) or may re-mark previously
In particular, the model supports the application of marking based on a marked packets. In particular, the model supports the application of
preceding classifier match. The mark set in a packet will determine its marking based on a preceding classifier match. The mark set in a
subsequent PHB treatment in downstream nodes of a network and possibly packet will determine its subsequent PHB treatment in downstream
also in subsequent processing stages within this router. nodes of a network and possibly also in subsequent processing stages
within this router.
DSCP Markers for Diffserv are normally parameterized by a single DSCP Markers for Diffserv are normally parameterized by a single
parameter: the 6-bit DSCP to be marked in the packet header. parameter: the 6-bit DSCP to be marked in the packet header.
Marker1: Marker1:
Type: DSCPMarker Type: DSCPMarker
Mark: 010010 Mark: 010010
6.2. Absolute Dropper 6.2. Absolute Dropper
Absolute Droppers simply discard packets. There are no parameters for Absolute Droppers simply discard packets. There are no parameters
these droppers. Because this Absolute Dropper is a terminating point of for these droppers. Because this Absolute Dropper is a terminating
the datapath and has no outputs it is probably desirable to forward the point of the datapath and has no outputs, it is probably desirable to
packet through a Counter Action first for instrumentation purposes. forward the packet through a Counter Action first for instrumentation
purposes.
AbsoluteDropper1: AbsoluteDropper1:
Type: AbsoluteDropper Type: AbsoluteDropper
Absolute Droppers are not the only elements than can cause a packet to Absolute Droppers are not the only elements than can cause a packet
be discarded: another element is an Algorithmic Dropper element (see to be discarded: another element is an Algorithmic Dropper element
Section 7.1.3). However, since this element's behavior is closely tied (see Section 7.1.3). However, since this element's behavior is
the state of one or more queues, we choose to distinguish it as a closely tied the state of one or more queues, we choose to
separate functional datapath element. distinguish it as a separate functional datapath element.
6.3. Multiplexor 6.3. Multiplexor
It is occasionally necessary to multiplex traffic streams into a It is occasionally necessary to multiplex traffic streams into a
functional datapath element with a single input. A M:1 (fan-in) functional datapath element with a single input. A M:1 (fan-in)
multiplexor is a simple logical device for merging traffic streams. It multiplexor is a simple logical device for merging traffic streams.
is parameterized by its number of incoming ports. It is parameterized by its number of incoming ports.
Mux1: Mux1:
Type: Multiplexor Type: Multiplexor
Output: Queue2 Output: Queue2
6.4. Counter 6.4. Counter
One passive action is to account for the fact that a data packet was One passive action is to account for the fact that a data packet was
processed. The statistics that result might be used later for customer processed. The statistics that result might be used later for
billing, service verification or network engineering purposes. Counters customer billing, service verification or network engineering
are 1:1 functional datapath elements which update a counter by L and a purposes. Counters are 1:1 functional datapath elements which update
packet counter by 1 every time a L-byte sized packet passes through a counter by L and a packet counter by 1 every time a L-byte sized
them. Counters can be used to count packets about to be dropped by an packet passes through them. Counters can be used to count packets
Absolute Dropper or to count packets arriving at or departing from some about to be dropped by an Absolute Dropper or to count packets
other functional element. arriving at or departing from some other functional element.
Counter1: Counter1:
Type: Counter Type: Counter
Output: Queue1 Output: Queue1
6.5. Null Action 6.5. Null Action
A null action has one input and one output. The element performs no A null action has one input and one output. The element performs no
action on the packet. Such an element is useful to define in the event action on the packet. Such an element is useful to define in the
that the configuration or management interface does not have the event that the configuration or management interface does not have
flexibility to omit an action element in a datapath segment. the flexibility to omit an action element in a datapath segment.
Null1: Null1:
Type: Null Type: Null
Output: Queue1 Output: Queue1
7. Queueing Elements 7. Queuing Elements
Queueing elements modulate the transmission of packets belonging to the Queuing elements modulate the transmission of packets belonging to
different traffic streams and determine their ordering, possibly storing the different traffic streams and determine their ordering, possibly
them temporarily or discarding them. Packets are usually stored either storing them temporarily or discarding them. Packets are usually
because there is a resource constraint (e.g., available bandwidth) which stored either because there is a resource constraint (e.g., available
prevents immediate forwarding, or because the queueing block is being bandwidth) which prevents immediate forwarding, or because the
used to alter the temporal properties of a traffic stream (i.e. queuing block is being used to alter the temporal properties of a
shaping). Packets are discarded for one of the following reasons: traffic stream (i.e., shaping). Packets are discarded for one of the
following reasons:
- because of buffering limitations. - because of buffering limitations.
- because a buffer threshold is exceeded (including when shaping - because a buffer threshold is exceeded (including when shaping
is performed). is performed).
- as a feedback control signal to reactive control protocols such - as a feedback control signal to reactive control protocols such
as TCP. as TCP.
- because a meter exceeds a configured profile (i.e. policing). - because a meter exceeds a configured profile (i.e., policing).
The queueing elements in this model represent a logical abstraction of a The queuing elements in this model represent a logical abstraction of
queueing system, which is used to configure PHB-related parameters. The a queuing system which is used to configure PHB-related parameters.
model can be used to represent a broad variety of possible The model can be used to represent a broad variety of possible
implementations. However, it need not necessarily map one-to-one with implementations. However, it need not necessarily map one-to-one
physical queueing systems in a specific router implementation. with physical queuing systems in a specific router implementation.
Implementors should map the configurable parameters of the Implementors should map the configurable parameters of the
implementation's queueing systems to these queueing element parameters implementation's queuing systems to these queuing element parameters
as appropriate to achieve equivalent behaviors. as appropriate to achieve equivalent behaviors.
7.1. Queueing Model 7.1. Queuing Model
Queueing is a function which lends itself to innovation. It must be Queuing is a function which lends itself to innovation. It must be
modelled to allow a broad range of possible implementations to be modeled to allow a broad range of possible implementations to be
represented using common structures and parameters. This model uses represented using common structures and parameters. This model uses
functional decomposition as a tool to permit the needed lattitude. functional decomposition as a tool to permit the needed latitude.
Queueing systems perform three distinct, but related, functions: they Queuing systems perform three distinct, but related, functions: they
store packets, they modulate the departure of packets belonging to store packets, they modulate the departure of packets belonging to
various traffic streams and they selectively discard packets. This model various traffic streams and they selectively discard packets. This
decomposes queueing into the component elements that perform each of model decomposes queuing into the component elements that perform
these functions: Queues, Schedulers and Algorithmic Droppers, each of these functions: Queues, Schedulers, and Algorithmic
respectively. These elements may be connected together as part of a Droppers, respectively. These elements may be connected together as
TCB, as described in section 8. part of a TCB, as described in section 8.
The remainder of this section discusses FIFO Queues: typically, the The remainder of this section discusses FIFO Queues: typically, the
Queue element of this model will be implemented as a FIFO data Queue element of this model will be implemented as a FIFO data
structure. However, this does not preclude implementations which are not structure. However, this does not preclude implementations which are
strictly FIFO, in that they also support operations that remove or not strictly FIFO, in that they also support operations that remove
examine packets (e.g., for use by discarders) other than at the head or or examine packets (e.g., for use by discarders) other than at the
tail. However, such operations must not have the effect of reordering head or tail. However, such operations must not have the effect of
packets belonging to the same microflow. reordering packets belonging to the same microflow.
Note that the term FIFO has multiple different common usages: it is Note that the term FIFO has multiple different common usages: it is
sometimes taken to mean, among other things, a data structure that sometimes taken to mean, among other things, a data structure that
permits items to be removed only in the order in which they were permits items to be removed only in the order in which they were
inserted or a service discipline which is non-reordering. inserted or a service discipline which is non-reordering.
7.1.1. FIFO Queue 7.1.1. FIFO Queue
In this model, a FIFO Queue element is a data structure which at any In this model, a FIFO Queue element is a data structure which at any
time may contain zero or more packets. It may have one or more time may contain zero or more packets. It may have one or more
thresholds associated with it. A FIFO has one or more inputs and exactly thresholds associated with it. A FIFO has one or more inputs and
one output. It must support an enqueue operation to add a packet to the exactly one output. It must support an enqueue operation to add a
tail of the queue and a dequeue operation to remove a packet from the packet to the tail of the queue and a dequeue operation to remove a
head of the queue. Packets must be dequeued in the order in which they packet from the head of the queue. Packets must be dequeued in the
were enqueued. A FIFO has a current depth, which indicates the number of order in which they were enqueued. A FIFO has a current depth, which
packets and/or bytes that it contains at a particular time. FIFOs in indicates the number of packets and/or bytes that it contains at a
this model are modelled without inherent limits on their depth - particular time. FIFOs in this model are modeled without inherent
obviously this does not reflect the reality of implementations: FIFO limits on their depth - obviously this does not reflect the reality
size limits are modelled here by an algorithmic dropper associated with of implementations: FIFO size limits are modeled here by an
the FIFO, typically at its input. It is quite likely that every FIFO algorithmic dropper associated with the FIFO, typically at its input.
will be preceded by an algorithmic dropper. One exception might be the It is quite likely that every FIFO will be preceded by an algorithmic
case where the packet stream has already been policed to a profile that dropper. One exception might be the case where the packet stream has
can never exceed the scheduler bandwidth available at the FIFO's output already been policed to a profile that can never exceed the scheduler
- this would not need an algorithmic dropper at the input to the FIFO. bandwidth available at the FIFO's output - this would not need an
algorithmic dropper at the input to the FIFO.
This representation of a FIFO allows for one common type of depth limit, This representation of a FIFO allows for one common type of depth
one that results from a FIFO supplied from a limited pool of buffers, limit, one that results from a FIFO supplied from a limited pool of
shared between multiple FIFOs. buffers, shared between multiple FIFOs.
In an implementation, packets are presumably stored in one or more In an implementation, packets are presumably stored in one or more
buffers. Buffers are allocated from one or more free buffer pools. If buffers. Buffers are allocated from one or more free buffer pools.
there are multiple instances of a FIFO, their packet buffers may or may If there are multiple instances of a FIFO, their packet buffers may
not be allocated out of the same free buffer pool. Free buffer pools may or may not be allocated out of the same free buffer pool. Free
also have one or more thresholds associated with them, which may affect buffer pools may also have one or more thresholds associated with
discarding and/or scheduling. Other than this, buffering mechanisms are them, which may affect discarding and/or scheduling. Other than
implementation specific and not part of this model. this, buffering mechanisms are implementation specific and not part
of this model.
A FIFO might be represented using the following parameters: A FIFO might be represented using the following parameters:
Queue1: Queue1:
Type: FIFO Type: FIFO
Output: Scheduler1 Output: Scheduler1
Note that a FIFO must provide triggers and/or current state information Note that a FIFO must provide triggers and/or current state
to other elements upstream and downstream from it: in particular, it is information to other elements upstream and downstream from it: in
likely that the current depth will need to be used by Algorithmic particular, it is likely that the current depth will need to be used
Dropper elements placed before or after the FIFO. It will also likely by Algorithmic Dropper elements placed before or after the FIFO. It
need to provide an implicit "I have packets for you" signal to will also likely need to provide an implicit "I have packets for you"
downstream Scheduler elements. signal to downstream Scheduler elements.
7.1.2. Scheduler 7.1.2. Scheduler
A scheduler is an element which gates the departure of each packet that A scheduler is an element which gates the departure of each packet
arrives at one of its inputs, based on a service discipline. It has one that arrives at one of its inputs, based on a service discipline. It
or more inputs and exactly one output. Each input has an upstream has one or more inputs and exactly one output. Each input has an
element to which it is connected, and a set of parameters that affects upstream element to which it is connected, and a set of parameters
the scheduling of packets received at that input. that affects the scheduling of packets received at that input.
The service discipline (also known as a scheduling algorithm) is an The service discipline (also known as a scheduling algorithm) is an
algorithm which might take any of the following as its input(s): algorithm which might take any of the following as its input(s):
a) static parameters such as relative priority associated with each of a) static parameters such as relative priority associated with each
the scheduler's inputs. of the scheduler's inputs.
b) absolute token bucket parameters for maximum or minimum rates b) absolute token bucket parameters for maximum or minimum rates
associated with each of the scheduler's inputs. associated with each of the scheduler's inputs.
c) parameters, such as packet length or DSCP, associated with the c) parameters, such as packet length or DSCP, associated with the
packet currently present at its input. packet currently present at its input.
d) absolute time and/or local state. d) absolute time and/or local state.
Possible service disciplines fall into a number of categories, including Possible service disciplines fall into a number of categories,
(but not limited to) first come, first served (FCFS), strict priority, including (but not limited to) first come, first served (FCFS),
weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority strict priority, weighted fair bandwidth sharing (e.g., WFQ), rate-
and rate-based. Service disciplines can be further distinguished by limited strict priority, and rate-based. Service disciplines can be
whether they are work-conserving or non-work-conserving (see Glossary). further distinguished by whether they are work-conserving or non-
Non-work-conserving schedulers can be used to shape traffic streams to work-conserving (see Glossary). Non-work-conserving schedulers can
match some profile by delaying packets that might be deemed non- be used to shape traffic streams to match some profile by delaying
conforming by some downstream node: a packet is delayed until such time packets that might be deemed non-conforming by some downstream node:
as it would conform to a downstream meter using the same profile. a packet is delayed until such time as it would conform to a
downstream meter using the same profile.
[DSARCH] defines PHBs without specifying required scheduling algorithms. [DSARCH] defines PHBs without specifying required scheduling
However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF algorithms. However, PHBs such as the class selectors [DSFIELD], EF
[AF-PHB] have descriptions or configuration parameters which strongly [EF-PHB] and AF [AF-PHB] have descriptions or configuration
suggest the sort of scheduling discipline needed to implement them. This parameters which strongly suggest the sort of scheduling discipline
document discusses a minimal set of queue parameters to enable needed to implement them. This document discusses a minimal set of
realization of these PHBs. It does not attempt to specify an all- queue parameters to enable realization of these PHBs. It does not
embracing set of parameters to cover all possible implementation models. attempt to specify an all-embracing set of parameters to cover all
A mimimal set includes: possible implementation models. A minimal set includes:
a) a minimum service rate profile which allows rate guarantees for a) a minimum service rate profile which allows rate guarantees for
each traffic stream as required by EF and AF without specifying the each traffic stream as required by EF and AF without specifying
details of how excess bandwidth between these traffic streams is the details of how excess bandwidth between these traffic streams
shared. Additional parameters to control this behavior should be is shared. Additional parameters to control this behavior should
made available, but are dependent on the particular scheduling be made available, but are dependent on the particular scheduling
algorithm implemented. algorithm implemented.
b) a service priority, used only after the minimum rate profiles of b) a service priority, used only after the minimum rate profiles of
all inputs have been satisfied, to decide how to allocate any all inputs have been satisfied, to decide how to allocate any
remaining bandwidth. remaining bandwidth.
c) a maximum service rate profile, for use only with a non-work- c) a maximum service rate profile, for use only with a non-work-
conserving service discipline. conserving service discipline.
Any one of these profiles is composed, for the purposes of this model, Any one of these profiles is composed, for the purposes of this
of both a rate (in suitable units of bits, bytes or larger chunks in model, of both a rate (in suitable units of bits, bytes or larger
some unit of time) and a burst size, as discussed further in Appendix A. chunks in some unit of time) and a burst size, as discussed further
in Appendix A.
By way of example, for an implementation of the EF PHB using a strict By way of example, for an implementation of the EF PHB using a strict
priority scheduling algorithm that assumes that the aggregate EF rate priority scheduling algorithm that assumes that the aggregate EF rate
has been appropriately bounded by upstream policing to avoid starvation has been appropriately bounded by upstream policing to avoid
of other BAs, the service rate profiles are not used: the minimum starvation of other BAs, the service rate profiles are not used: the
service rate profile would be defaulted to zero and the maximum service minimum service rate profile would be defaulted to zero and the
rate profile would effectively be the "line rate". Such an maximum service rate profile would effectively be the "line rate".
implementation, with multiple priority classes, could also be used for Such an implementation, with multiple priority classes, could also be
the Diffserv class selectors [DSFIELD]. used for the Diffserv class selectors [DSFIELD].
Alternatively, setting the service priority values for each input to the Alternatively, setting the service priority values for each input to
scheduler to the same value enables the scheduler to satisfy the minimum the scheduler to the same value enables the scheduler to satisfy the
service rates for each input, so long as the sum of all minimum service minimum service rates for each input, so long as the sum of all
rates is less than or equal to the line rate. minimum service rates is less than or equal to the line rate.
For example, a non-work-conserving scheduler, allocating spare bandwidth For example, a non-work-conserving scheduler, allocating spare
equally between all its inputs, might be represented using the following bandwidth equally between all its inputs, might be represented using
parameters: the following parameters:
Scheduler1: Scheduler1:
Type: Scheduler2Input Type: Scheduler2Input
Input1: Input1:
MaxRateProfile: Profile1 MaxRateProfile: Profile1
MinRateProfile: Profile2 MinRateProfile: Profile2
Priority: none Priority: none
Input2: Input2:
MaxRateProfile: Profile3 MaxRateProfile: Profile3
MinRateProfile: Profile4 MinRateProfile: Profile4
Priority: none Priority: none
A work-conserving scheduler might be represented using the following A work-conserving scheduler might be represented using the following
parameters: parameters:
Scheduler2: Scheduler2:
Type: Scheduler3Input Type: Scheduler3Input
Input1: Input1:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: Profile5 MinRateProfile: Profile5
Priority: 1 Priority: 1
Input2: Input2:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: Profile6 MinRateProfile: Profile6
Priority: 2 Priority: 2
Input3: Input3:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: none MinRateProfile: none
Priority: 3 Priority: 3
7.1.3. Algorithmic Dropper 7.1.3. Algorithmic Dropper
An Algorithmic Dropper is an element which selectively discards packets An Algorithmic Dropper is an element which selectively discards
that arrive at its input, based on a discarding algorithm. It has one packets that arrive at its input, based on a discarding algorithm.
data input and one output. In this model (but not necessarily in a real It has one data input and one output. In this model (but not
implementation), a packet enters the dropper at its input and either its necessarily in a real implementation), a packet enters the dropper at
buffer is returned to a free buffer pool or the packet exits the dropper its input and either its buffer is returned to a free buffer pool or
at the output. the packet exits the dropper at the output.
Alternatively, an Algorithmic Dropper can be thought of as invoking Alternatively, an Algorithmic Dropper can be thought of as invoking
operations on a FIFO Queue which selectively remove a packet and return operations on a FIFO Queue which selectively remove a packet and
its buffer to the free buffer pool based on a discarding algorithm. In return its buffer to the free buffer pool based on a discarding
this case, the operation could be modelled as being a side-effect on the algorithm. In this case, the operation could be modeled as being a
FIFO upon which it operated, rather than as having a discrete input and side-effect on the FIFO upon which it operated, rather than as having
output. This treatment is equivalent and we choose the one described in a discrete input and output. This treatment is equivalent and we
the previous paragraph for this model. choose the one described in the previous paragraph for this model.
One of the primary characteristics of an Algorithmic Dropper is the One of the primary characteristics of an Algorithmic Dropper is the
choice of which packet is to be dropped, if any: for the purposes of choice of which packet (if any) is to be dropped: for the purposes of
this model, we restrict the packet selection choices to one of the this model, we restrict the packet selection choices to one of the
following and we indicate the choice by the relative positions of following and we indicate the choice by the relative positions of
Algorithmic Dropper and FIFO Queue elements in the model: Algorithmic Dropper and FIFO Queue elements in the model:
a) selection of a packet that is about to be added to the tail of a a) selection of a packet that is about to be added to the tail of a
queue (a "Tail Dropper"): the output of the Algorithmic Dropper queue (a "Tail Dropper"): the output of the Algorithmic Dropper
element is connected to the input of the relevant FIFO Queue element is connected to the input of the relevant FIFO Queue
element. element.
b) a packet that is currently at the head of a queue (a "Head b) a packet that is currently at the head of a queue (a "Head
Dropper"): the output of the FIFO Queue element is connected to the Dropper"): the output of the FIFO Queue element is connected to
input of the Algorithmic Dropper element. the input of the Algorithmic Dropper element.
Other packet selection methods could be added to this model in the form Other packet selection methods could be added to this model in the
of a different type of datapath element. form of a different type of datapath element.
The Algorithmic Dropper is modelled as having a single input. It is The Algorithmic Dropper is modeled as having a single input. It is
possible that packets which were classified differently by a Classifier possible that packets which were classified differently by a
in this TCB will end up passing through the same dropper. The dropper's Classifier in this TCB will end up passing through the same dropper.
algorithm may need to apply different calculations based on The dropper's algorithm may need to apply different calculations
characteristics of the incoming packet e.g. its DSCP. So there is a based on characteristics of the incoming packet (e.g., its DSCP). So
need, in implementations of this model, to be able to relate information there is a need, in implementations of this model, to be able to
about which classifier element was matched by a packet from a Classifier relate information about which classifier element was matched by a
to an Algorithmic Dropper. In the rare cases where this is required, packet from a Classifier to an Algorithmic Dropper. In the rare
the chosen model is to insert another Classifier element at this point cases where this is required, the chosen model is to insert another
in the flow and for it to feed into multiple Algorithmic Dropper Classifier element at this point in the flow and for it to feed into
elements, each one implementing a drop calculation that is independent multiple Algorithmic Dropper elements, each one implementing a drop
of any classification keys of the packet: this will likely require the calculation that is independent of any classification keys of the
creation of a new TCB to contain the Classifier and the Algorithmic packet: this will likely require the creation of a new TCB to contain
Dropper elements. the Classifier and the Algorithmic Dropper elements.
NOTE: There are many other formulations of a model that could NOTE: There are many other formulations of a model that could
represent this linkage that are different to the one described represent this linkage that are different from the one described
above: one formulation would have been to have a pointer from one above: one formulation would have been to have a pointer from one
of the drop probability calculation algorithms inside the dropper of the drop probability calculation algorithms inside the dropper
to the original Classifier element that selects this algorithm. to the original Classifier element that selects this algorithm.
Another way would have been to have multiple "inputs" to the Another way would have been to have multiple "inputs" to the
Algorithmic Dropper element fed from the preceding elements, Algorithmic Dropper element fed from the preceding elements,
leading eventually back to the Classifier elements that matched the leading eventually back to the Classifier elements that matched
packet. Yet another formulation might have been for the Classifier the packet. Yet another formulation might have been for the
to (logically) include some sort of "classification identifier" Classifier to (logically) include some sort of "classification
along with the packet along its path, for use by any subsequent identifier" along with the packet along its path, for use by any
element. And yet another could have been to include a classifier subsequent element. And yet another could have been to include a
inside the dropper, in order for it to pick out the drop algorithm classifier inside the dropper, in order for it to pick out the
to be applied. These other approaches could be used by drop algorithm to be applied. These other approaches could be
implementations but were deemed to be less clear than the approach used by implementations but were deemed to be less clear than the
taken here. approach taken here.
An Algorithmic Dropper, an example of which illustrated in Figure 5, has An Algorithmic Dropper, an example of which is illustrated in Figure
one or more triggers that cause it to make a decision whether or not to 5, has one or more triggers that cause it to make a decision whether
drop one (or possibly more than one) packet. A trigger may be internal or not to drop one (or possibly more than one) packet. A trigger may
(the arrival of a packet at the input to the dropper) or it may be be internal (the arrival of a packet at the input to the dropper) or
external (resulting from one or more state changes at another element, it may be external (resulting from one or more state changes at
such as a FIFO Queue depth crossing a threshold or a scheduling event). another element, such as a FIFO Queue depth crossing a threshold or a
It is likely that an instantaneous FIFO depth will need to be smoothed scheduling event). It is likely that an instantaneous FIFO depth
over some averaging interval before being used as a useful trigger. Some will need to be smoothed over some averaging interval before being
dropping algorithms may require several trigger inputs feeding back from used as a useful trigger. Some dropping algorithms may require
events elsewhere in the system e.g. depth-smoothing functions that several trigger inputs feeding back from events elsewhere in the
calculate averages over more than one time interval. system (e.g., depth-smoothing functions that calculate averages over
more than one time interval).
+------------------+ +-----------+ +------------------+ +-----------+
| +-------+ | n |smoothing | | +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)| | |trigger|<----------/---|function(s)|
| |calc. | | |(optional) | | |calc. | | |(optional) |
| +-------+ | +-----------+ | +-------+ | +-----------+
| | | ^ | | | ^
| v | |Depth | v | |Depth
Input | +-------+ no | ------------+ to Scheduler Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|-------> ---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+ | | ? | | ------------+
| +-------+ | FIFO | +-------+ | FIFO
| |yes | | |yes |
| | | | | | | | | |
| | v | count + | | | v | count + |
| +---+ bit-bucket| | +---+ bit-bucket|
+------------------+ +------------------+
Algorithmic Algorithmic
Dropper Dropper
Figure 5. Example of Algorithmic Dropper from Tail of a Queue Figure 5. Example of Algorithmic Dropper from Tail of a Queue
A trigger may be a boolean combination of events e.g. a FIFO depth A trigger may be a boolean combination of events (e.g., a FIFO depth
exceeding a threshold OR a buffer pool depth falling below a threshold. exceeding a threshold OR a buffer pool depth falling below a
It takes as its input some set of dynamic parameters e.g. smoothed or threshold). It takes as its input some set of dynamic parameters
instantaneous FIFO depth and some set of static parameters e.g. (e.g., smoothed or instantaneous FIFO depth), and some set of static
thresholds, and possibly other parameters associated with the packet. It parameters (e.g., thresholds), and possibly other parameters
may also have internal state e.g. history of its past actions. Note associated with the packet. It may also have internal state (e.g.,
that, although an Algorithmic Dropper may require knowledge of data history of its past actions). Note that, although an Algorithmic
fields in a packet, as discovered by a Classifier in the same TCB, it Dropper may require knowledge of data fields in a packet, as
may not modify the packet (i.e. it is not a marker). discovered by a Classifier in the same TCB, it may not modify the
packet (i.e., it is not a marker).
The result of the trigger calculation is that the dropping algorithm The result of the trigger calculation is that the dropping algorithm
makes a decision on whether to forward or to discard a packet. The makes a decision on whether to forward or to discard a packet. The
discarding function is likely to keep counters regarding the discarded discarding function is likely to keep counters regarding the
packets (there is no appropriate place here to include a Counter Action discarded packets (there is no appropriate place here to include a
element). Counter Action element).
The example in Figure 5 also shows a FIFO Queue element from whose tail The example in Figure 5 also shows a FIFO Queue element from whose
the dropping is to take place and whose depth characteristics are used tail the dropping is to take place and whose depth characteristics
by this Algorithmic Dropper. It also shows where a depth-smoothing are used by this Algorithmic Dropper. It also shows where a depth-
function might be included: smoothing functions are outside the scope of smoothing function might be included: smoothing functions are outside
this document and are not modelled explicitly here, we merely indicate the scope of this document and are not modeled explicitly here, we
where they might be added. merely indicate where they might be added.
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of
dropping algorithms. Tail-dropping and head-dropping are effected by the dropping algorithms. Tail-dropping and head-dropping are effected by
location of the Algorithmic Dropper element relative to the FIFO Queue the location of the Algorithmic Dropper element relative to the FIFO
element. As an example, a dropper using a RIO algorithm might be Queue element. As an example, a dropper using a RIO algorithm might
represented using 2 Algorithmic Droppers with the following parameters: be represented using 2 Algorithmic Droppers with the following
parameters:
AlgorithmicDropper1: (for in-profile traffic) AlgorithmicDropper1: (for in-profile traffic)
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED Discipline: RED
Trigger: Internal Trigger: Internal
Output: Fifo1 Output: Fifo1
MinThresh: Fifo1.Depth > 20 kbyte MinThresh: Fifo1.Depth > 20 kbyte
MaxThresh: Fifo1.Depth > 30 kbyte MaxThresh: Fifo1.Depth > 30 kbyte
SampleWeight .002 SampleWeight .002
MaxDropProb 1% MaxDropProb 1%
skipping to change at page 31, line 31 skipping to change at page 33, line 28
AlgorithmicDropper2: (for out-of-profile traffic) AlgorithmicDropper2: (for out-of-profile traffic)
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED Discipline: RED
Trigger: Internal Trigger: Internal
Output: Fifo1 Output: Fifo1
MinThresh: Fifo1.Depth > 10 kbyte MinThresh: Fifo1.Depth > 10 kbyte
MaxThresh: Fifo1.Depth > 20 kbyte MaxThresh: Fifo1.Depth > 20 kbyte
SampleWeight .002 SampleWeight .002
MaxDropProb 2% MaxDropProb 2%
Another form of Algorithmic Dropper, a threshold-dropper, might be Another form of Algorithmic Dropper, a threshold-dropper, might be
represented using the following parameters: represented using the following parameters:
AlgorithmicDropper3: AlgorithmicDropper3:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Fifo2.Depth > 20 kbyte Trigger: Fifo2.Depth > 20 kbyte
Output: Fifo1 Output: Fifo1
7.2. Sharing load among traffic streams using queueing 7.2. Sharing load among traffic streams using queuing
Queues are used, in Differentiated Services, for a number of purposes. Queues are used, in Differentiated Services, for a number of
In essence, they are simply places to store traffic until it is purposes. In essence, they are simply places to store traffic until
transmitted. However, when several queues are used together in a it is transmitted. However, when several queues are used together in
queueing system, they can also achieve effects beyond that for given a queuing system, they can also achieve effects beyond that for given
traffic streams. They can be used to limit variation in delay or impose traffic streams. They can be used to limit variation in delay or
a maximum rate (shaping), to permit several streams to share a link in a impose a maximum rate (shaping), to permit several streams to share a
semi-predictable fashion (load sharing), or to move variation in delay link in a semi-predictable fashion (load sharing), or to move
from some streams to other streams. variation in delay from some streams to other streams.
Traffic shaping is often used to condition traffic such that packets Traffic shaping is often used to condition traffic, such that packets
arriving in a burst will be "smoothed" and deemed conforming by arriving in a burst will be "smoothed" and deemed conforming by
subsequent downstream meters in this or other nodes. In [DSARCH] a subsequent downstream meters in this or other nodes. In [DSARCH] a
shaper is described as a queueing element controlled by a meter which shaper is described as a queuing element controlled by a meter which
defines its temporal profile. However, this representation of a shaper defines its temporal profile. However, this representation of a
differs substantially from typical shaper implementations. shaper differs substantially from typical shaper implementations.
In the model described here, a shaper is realized by using a non-work- In the model described here, a shaper is realized by using a non-
conserving Scheduler. Some implementations may elect to have queues work-conserving Scheduler. Some implementations may elect to have
whose sole purpose is shaping, while others may integrate the shaping queues whose sole purpose is shaping, while others may integrate the
function with other buffering, discarding and scheduling associated with shaping function with other buffering, discarding, and scheduling
access to a resource. Shapers operate by delaying the departure of associated with access to a resource. Shapers operate by delaying
packets that would be deemed non-conforming by a meter configured to the the departure of packets that would be deemed non-conforming by a
shaper's maximum service rate profile. The packet is scheduled to depart meter configured to the shaper's maximum service rate profile. The
no sooner than such time that it would become conforming. packet is scheduled to depart no sooner than such time that it would
become conforming.
7.2.1. Load Sharing 7.2.1. Load Sharing
Load sharing is the traditional use of queues and was theoretically Load sharing is the traditional use of queues and was theoretically
explored by Floyd & Jacobson [FJ95] although it has been in use in explored by Floyd & Jacobson [FJ95], although it has been in use in
communications systems since the 1970's. communications systems since the 1970's.
[DSARCH] discusses load sharing as dividing an interface among traffic [DSARCH] discusses load sharing as dividing an interface among
classes predictably or applying a minimum rate to each of a set of traffic classes predictably, or applying a minimum rate to each of a
traffic classes, which might be measured as an absolute lower bound on set of traffic classes, which might be measured as an absolute lower
the rate a traffic stream achieves or a fraction of the rate an bound on the rate a traffic stream achieves or a fraction of the rate
interface offers. It is generally implemented as some form of weighted an interface offers. It is generally implemented as some form of
queueing algorithm among a set of FIFO queues i.e. a WFQ scheme. This weighted queuing algorithm among a set of FIFO queues i.e., a WFQ
has interesting side-effects. scheme. This has interesting side-effects.
A key effect sought is to ensure that the mean rate the traffic in a A key effect sought is to ensure that the mean rate the traffic in a
stream experiences is never lower than some threshold when there is at stream experiences is never lower than some threshold when there is
least that much traffic to send. When there is less traffic than this, at least that much traffic to send. When there is less traffic than
the queue tends to be starved of traffic, meaning that the queuing this, the queue tends to be starved of traffic, meaning that the
system will not delay its traffic by very much. When there is queuing system will not delay its traffic by very much. When there
significantly more traffic and the queue starts filling, packets in this is significantly more traffic and the queue starts filling, packets
class will be delayed significantly more than traffic in other classes in this class will be delayed significantly more than traffic in
that are under-using their available capacity. This form of queuing other classes that are under-using their available capacity. This
system therefore tends to move delay and variation in delay from under- form of queuing system therefore tends to move delay and variation in
used classes of traffic to heavier users, as well as managing the rates delay from under-used classes of traffic to heavier users, as well as
of the traffic streams. managing the rates of the traffic streams.
A side-effect of a WRR or WFQ implementation is that between any two A side-effect of a WRR or WFQ implementation is that between any two
packets in a given traffic class, the scheduler may emit one or more packets in a given traffic class, the scheduler may emit one or more
packets from each of the other classes in the queuing system. In cases packets from each of the other classes in the queuing system. In
where average behavior is in view, this is perfectly acceptable. In cases where average behavior is in view, this is perfectly
cases where traffic is very intolerant of jitter and there are a number acceptable. In cases where traffic is very intolerant of jitter and
of competing classes, this may have undesirable consequences. there are a number of competing classes, this may have undesirable
consequences.
7.2.2. Traffic Priority 7.2.2. Traffic Priority
Traffic Prioritization is a special case of load sharing, wherein a Traffic Prioritization is a special case of load sharing, wherein a
certain traffic class is deemed so jitter-intolerant that if it has certain traffic class is deemed so jitter-intolerant that if it has
traffic present, that traffic must be sent at the earliest possible traffic present, that traffic must be sent at the earliest possible
time. By extension, several priorities might be defined, such that time. By extension, several priorities might be defined, such that
traffic in each of several classes is given preferential service over traffic in each of several classes is given preferential service over
any traffic of a lower class. It is the obvious implementation of IP any traffic of a lower class. It is the obvious implementation of IP
Precedence as described in [RFC 791], of 802.1p traffic classes [802.1D] Precedence as described in [RFC 791], of 802.1p traffic classes
and other similar technologies. [802.1D], and other similar technologies.
Priority is often abused in real networks; people tend to think that Priority is often abused in real networks; people tend to think that
traffic which has a high business priority deserves this treatment and traffic which has a high business priority deserves this treatment
talk more about the business imperatives than the actual application and talk more about the business imperatives than the actual
requirements. This can have severe consequences; networks have been application requirements. This can have severe consequences;
configured which placed business-critical traffic at a higher priority networks have been configured which placed business-critical traffic
than routing-protocol traffic, resulting in collapse of the network's at a higher priority than routing-protocol traffic, resulting in
management or control systems. However, it may have a legitimate use for collapse of the network's management or control systems. However, it
services based on an Expedited Forwarding (EF) PHB, where it is may have a legitimate use for services based on an Expedited
absolutely sure, thanks to policing at all possible traffic entry Forwarding (EF) PHB, where it is absolutely sure, thanks to policing
points, that a traffic stream does not abuse its rate and that the at all possible traffic entry points, that a traffic stream does not
application is indeed jitter-intolerant enough to merit this type of abuse its rate and that the application is indeed jitter-intolerant
handling. Note that, even in cases with well-policed ingress points, enough to merit this type of handling. Note that, even in cases with
there is still the possibility of unexpected traffic loops within an un- well-policed ingress points, there is still the possibility of
policed core part of the network causing such collapse. unexpected traffic loops within an un-policed core part of the
network causing such collapse.
8. Traffic Conditioning Blocks (TCBs) 8. Traffic Conditioning Blocks (TCBs)
The Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler The Classifier, Meter, Action, Algorithmic Dropper, Queue and
functional datapath elements described above can be combined into Scheduler functional datapath elements described above can be
Traffic Conditioning Blocks (TCBs). A TCB is an abstraction of a set of combined into Traffic Conditioning Blocks (TCBs). A TCB is an
functional datapath elements that may be used to facilitate the abstraction of a set of functional datapath elements that may be used
definition of specific traffic conditioning functionality e.g. it might to facilitate the definition of specific traffic conditioning
be likened to a template which can be replicated multiple times for functionality (e.g., it might be likened to a template which can be
different traffic streams or different customers. It has no likely replicated multiple times for different traffic streams or different
physical representation in the implementation of the data path: it is customers). It has no likely physical representation in the
invented purely as an abstraction for use by management tools. implementation of the data path: it is invented purely as an
abstraction for use by management tools.
This model describes the configuration and management of a Diffserv This model describes the configuration and management of a Diffserv
interface in terms of a TCB that contains, by definition, zero or more interface in terms of a TCB that contains, by definition, zero or
Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler more Classifier, Meter, Action, Algorithmic Dropper, Queue and
elements. These elements are arranged arbitrarily according to the Scheduler elements. These elements are arranged arbitrarily
policy being expressed, but always in the order here. Traffic may be according to the policy being expressed, but always in the order
classified; classified traffic may be metered; each stream of traffic here. Traffic may be classified; classified traffic may be metered;
identified by a combination of classifiers and meters may have some set each stream of traffic identified by a combination of classifiers and
of actions performed on it, followed by drop algorithms; packets of the meters may have some set of actions performed on it, followed by drop
traffic stream may ultimately be stored into a queue and then be algorithms; packets of the traffic stream may ultimately be stored
scheduled out to the next TCB or physical interface. It is permissible into a queue and then be scheduled out to the next TCB or physical
to omit elements or include null elements of any type, or to concatenate interface. It is permissible to omit elements or include null
multiple functional datapath elements of the same type. elements of any type, or to concatenate multiple functional datapath
elements of the same type.
When the Diffserv treatment for a given packet needs to have such When the Diffserv treatment for a given packet needs to have such
building blocks repeated, this is performed by cascading multiple TCBs: building blocks repeated, this is performed by cascading multiple
an output of one TCB may drive the input of a succeeding one. For TCBs: an output of one TCB may drive the input of a succeeding one.
example, consider the case where traffic of a set of classes is shaped For example, consider the case where traffic of a set of classes is
to a set of rates, but the total output rate of the group of classes shaped to a set of rates, but the total output rate of the group of
must also be limited to a rate. One might imagine a set of network news classes must also be limited to a rate. One might imagine a set of
feeds, each with a certain maximum rate, and a policy that their network news feeds, each with a certain maximum rate, and a policy
aggregate may not exceed some figure. This may be simply accomplished by that their aggregate may not exceed some figure. This may be simply
cascading two TCBs. The first classifies the traffic into its separate accomplished by cascading two TCBs. The first classifies the traffic
feeds and queues each feed separately. The feeds (or a subset of them) into its separate feeds and queues each feed separately. The feeds
are now fed into a second TCB, which places all input (these news feeds) (or a subset of them) are now fed into a second TCB, which places all
into a single queue with a certain maximum rate. In implementation, one input (these news feeds) into a single queue with a certain maximum
could imagine this as the several literal queues, a CBQ or WFQ system rate. In implementation, one could imagine this as the several
with an appropriate (and complex) weighting scheme, or a number of other literal queues, a CBQ or WFQ system with an appropriate (and complex)
approaches. But they would have the same externally measurable effect on weighting scheme, or a number of other approaches. But they would
the traffic as if they had been literally implemented with separate have the same externally measurable effect on the traffic as if they
TCBs. had been literally implemented with separate TCBs.
8.1. TCB 8.1. TCB
A generalised TCB might consist of the following stages: A generalized TCB might consist of the following stages:
- Classification stage
- Metering stage
- Action stage (involving Markers, Absolute Droppers,
Counters and Multiplexors)
- Queueing stage (involving Algorithmic Droppers, Queues
and Schedulers)
where each stage may consist of a set of parallel datapaths consisting - Classification stage
of pipelined elements.
A Classifier or a Meter is typically a 1:N element, an Action, - Metering stage
Algorithmic Dropper or Queue is typically a 1:1 element and a Scheduler
is a N:1 element. A complete TCB should, however, result in a 1:1 or 1:N
abstract element. Note that the fan-in or fan-out of an element is not
an important defining characteristic of this taxonomy.
8.1.1. Building blocks for Queueing - Action stage (involving Markers, Absolute Droppers, Counters,
and Multiplexors)
Some particular rules are applied to the ordering of elements within a - Queuing stage (involving Algorithmic Droppers, Queues, and
Queueing stage within a TCB: elements of the same type may appear more Schedulers)
than once, either in parallel or in series. Typically, a queueing stage
will have relatively many elements in parallel and few in series.
Iteration and recursion are not supported constructs (the elements are
arranged in an acyclic graph). The following inter-connections of
elements are allowed:
1) The input of a Queue may be the input of the queueing block or it where each stage may consist of a set of parallel datapaths
may be connected to the output of an Algorithmic Dropper or to an consisting of pipelined elements.
output of a Scheduler.
2) Each input of a Scheduler may be connected to the output of a A Classifier or a Meter is typically a 1:N element, an Action,
Queue, to the output of an Algorithmic Dropper or to the output of Algorithmic Dropper, or Queue is typically a 1:1 element and a
another Scheduler. Scheduler is a N:1 element. A complete TCB should, however, result
in a 1:1 or 1:N abstract element. Note that the fan-in or fan-out of
an element is not an important defining characteristic of this
taxonomy.
3) The input of an Algorithmic Dropper may be the first element of the 8.1.1. Building blocks for Queuing
queueing stage, the output of another Algorithmic Dropper or it may
be connected to the output of a Queue (to indicate head-dropping).
4) The output of the queueing block may be the output of a Queue, an Some particular rules are applied to the ordering of elements within
Algorithmic Dropper or a Scheduler. a Queuing stage within a TCB: elements of the same type may appear
more than once, either in parallel or in series. Typically, a
queuing stage will have relatively many elements in parallel and few
in series. Iteration and recursion are not supported constructs (the
elements are arranged in an acyclic graph). The following inter-
connections of elements are allowed:
Note, in particular, that Schedulers may operate in series such that a - The input of a Queue may be the input of the queuing block, or
packet at the head of a Queue feeding the concatenated Schedulers is it may be connected to the output of an Algorithmic Dropper, or
serviced only after all of the scheduling criteria are met. For example, to an output of a Scheduler.
a Queue which carries EF traffic streams may be served first by a non-
work-conserving Scheduler to shape the stream to a maximum rate, then by
a work-conserving Scheduler to mix EF traffic streams with other traffic
streams. Alternatively, there might be a Queue and/or a dropper between
the two Schedulers.
Note also that some non-sensical scenarios e.g. a Queue preceding an - Each input of a Scheduler may be connected to the output of a
Algorithmic Dropper, directly feeding into another Queue, are Queue, to the output of an Algorithmic Dropper, or to the
prohibited. output of another Scheduler.
- The input of an Algorithmic Dropper may be the first element of
the queuing stage, the output of another Algorithmic Dropper,
or it may be connected to the output of a Queue (to indicate
head-dropping).
- The output of the queuing block may be the output of a Queue,
an Algorithmic Dropper, or a Scheduler.
Note, in particular, that Schedulers may operate in series such so
that a packet at the head of a Queue feeding the concatenated
Schedulers is serviced only after all of the scheduling criteria are
met. For example, a Queue which carries EF traffic streams may be
served first by a non-work-conserving Scheduler to shape the stream
to a maximum rate, then by a work-conserving Scheduler to mix EF
traffic streams with other traffic streams. Alternatively, there
might be a Queue and/or a dropper between the two Schedulers.
Note also that some non-sensical scenarios (e.g., a Queue preceding
an Algorithmic Dropper, directly feeding into another Queue), are
prohibited.
8.2. An Example TCB 8.2. An Example TCB
A SLS is presumed to have been negotiated between the customer and the A SLS is presumed to have been negotiated between the customer and
provider which specifies the handling of the customer's traffic, as the provider which specifies the handling of the customer's traffic,
defined by a TCS) by the provider's network. The agreement might be of as defined by a TCS) by the provider's network. The agreement might
the following form: be of the following form:
DSCP PHB Profile Treatment DSCP PHB Profile Treatment
---- --- ------- ---------------------- ---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming. 001001 EF Profile4 Discard non-conforming.
001100 AF11 Profile5 Shape to profile, tail-drop when full. 001100 AF11 Profile5 Shape to profile, tail-drop when full.
001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000, 001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
tail-drop when full. tail-drop when full.
other BE none Apply RED-like dropping. other BE none Apply RED-like dropping.
This SLS specifies that the customer may submit packets marked for DSCP This SLS specifies that the customer may submit packets marked for
001001 which will get EF treatment so long as they remain conforming to DSCP 001001 which will get EF treatment so long as they remain
Profile4 and will be discarded if they exceed this profile. The conforming to Profile4, which will be discarded if they exceed this
discarded packets are counted in this example, perhaps for use by the profile. The discarded packets are counted in this example, perhaps
provider's sales department in convincing the customer to buy a larger for use by the provider's sales department in convincing the customer
SLS. Packets marked for DSCP 001100 will be shaped to Profile5 before to buy a larger SLS. Packets marked for DSCP 001100 will be shaped
forwarding. Packets marked for DSCP 001101 will be metered to Profile3 to Profile5 before forwarding. Packets marked for DSCP 001101 will
with non-conforming packets "downgraded" by being re-marked with a DSCP be metered to Profile3 with non-conforming packets "downgraded" by
of 001000. It is implicit in this agreement that conforming packets are being re-marked with a DSCP of 001000. It is implicit in this
given the PHB originally indicated by the packets' DSCP field. agreement that conforming packets are given the PHB originally
indicated by the packets' DSCP field.
Figures 6 and 7 illustrates a TCB that might be used to handle this SLS Figures 6 and 7 illustrates a TCB that might be used to handle this
at an ingress interface at the customer/provider boundary. SLS at an ingress interface at the customer/provider boundary.
The Classification stage of this example consists of a single BA The Classification stage of this example consists of a single BA
classifier. The BA classifier is used to separate traffic based on the classifier. The BA classifier is used to separate traffic based on
Diffserv service level requested by the customer (as indicated by the the Diffserv service level requested by the customer (as indicated by
DSCP in each submitted packet's IP header). We illustrate three DSCP the DSCP in each submitted packet's IP header). We illustrate three
filter values: A, B and C. The 'X' in the BA classifier is a wildcard DSCP filter values: A, B, and C. The 'X' in the BA classifier is a
filter that matches every packet not otherwise matched. wildcard filter that matches every packet not otherwise matched.
The path for DSCP 001100 proceeds directly to Dropper1 whilst the paths The path for DSCP 001100 proceeds directly to Dropper1 whilst the
for DSCP 001001 and 001101 include a metering stage. All other traffic paths for DSCP 001001 and 001101 include a metering stage. All other
is passed directly on to Dropper3. There is a separate meter for each traffic is passed directly on to Dropper3. There is a separate meter
set of packets corresponding to classifier outputs A and C. Each meter for each set of packets corresponding to classifier outputs A and C.
uses a specific profile, as specified in the TCS, for the corresponding Each meter uses a specific profile, as specified in the TCS, for the
Diffserv service level. The meters in this example each indicate one of corresponding Diffserv service level. The meters in this example
two conformance levels: conforming or non-conforming. each indicate one of two conformance levels: conforming or non-
conforming.
Following the Metering stage is an Action stage in some of the branches. Following the Metering stage is an Action stage in some of the
Packets submitted for DSCP 001001 (Classifier output A) that are deemed branches. Packets submitted for DSCP 001001 (Classifier output A)
non-conforming by Meter1 are counted and discarded while packets that that are deemed non-conforming by Meter1 are counted and discarded
are conforming are passed on to Queue1. Packets submitted for DSCP while packets that are conforming are passed on to Queue1. Packets
001101 (Classifier output C) that are deemed non-conforming by Meter2 submitted for DSCP 001101 (Classifier output C) that are deemed non-
are re-marked and then both conforming and non-conforming packets are conforming by Meter2 are re-marked and then both conforming and non-
multiplexed together before being passed on to Dropper2/Queue3. conforming packets are multiplexed together before being passed on to
Dropper2/Queue3.
The Algorithmic Dropping, Queueing and Scheduling stages are realised as The Algorithmic Dropping, Queuing and Scheduling stages are realized
follows, illustrated in figure 7. Note that the figure does not show any as follows, illustrated in figure 7. Note that the figure does not
of the implicit control linkages between elements that allow e.g. an show any of the implicit control linkages between elements that allow
Algorithmic Dropper to sense the current state of a succeeding Queue. e.g., an Algorithmic Dropper to sense the current state of a
succeeding Queue.
+-----+ +-----+
| A|---------------------------> to Queue1 | A|---------------------------> to Queue1
+->| | +->| |
| | B|--+ +-----+ +-----+ | | B|--+ +-----+ +-----+
| +-----+ | | | | | | +-----+ | | | | |
| Meter1 +->| |--->| | | Meter1 +->| |--->| |
| | | | | | | | | |
| +-----+ +-----+ | +-----+ +-----+
| Counter1 Absolute | Counter1 Absolute
submitted +-----+ | Dropper1 submitted +-----+ | Dropper1
traffic | A|-----+ traffic | A|-----+
--------->| B|--------------------------------------> to AlgDropper1 --------->| B|--------------------------------------> to AlgDropper1
| C|-----+ | C|-----+
| X|--+ | | X|--+ |
+-----+ | | +-----+ +-----+ +-----+ | | +-----+ +-----+
Classifier1| | | A|--------------->|A | Classifier1| | | A|--------------->|A |
(BA) | +->| | | |--> to AlgDrop2 (BA) | +->| | | |--> to AlgDrop2
| | B|--+ +-----+ +->|B | | | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+ | +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1 | Meter2 +->| |-+ Mux1
| | | | | |
| +-----+ | +-----+
| Marker1 | Marker1
+-----------------------------------> to AlgDropper3 +-----------------------------------> to AlgDropper3
Figure 6: An Example Traffic Conditioning Block (Part 1) Figure 6: An Example Traffic Conditioning Block (Part 1)
Conforming DSCP 001001 packets from Meter1 are passed directly to Conforming DSCP 001001 packets from Meter1 are passed directly to
Queue1: there is no way, with configuration of the following Scheduler Queue1: there is no way, with configuration of the following
to match the metering, for these packets to overflow the depth of Queue1 Scheduler to match the metering, for these packets to overflow the
so there is no requirement for dropping at this point. Packets marked depth of Queue1, so there is no requirement for dropping at this
for DSCP 001100 must be passed through a tail-dropper, AlgDropper1, point. Packets marked for DSCP 001100 must be passed through a
which serves to limit the depth of the following queue, Queue2: packets tail-dropper, AlgDropper1, which serves to limit the depth of the
that arrive to a full queue will be discarded. This is likely to be an following queue, Queue2: packets that arrive to a full queue will be
error case: the customer is obviously not sticking to its agreed discarded. This is likely to be an error case: the customer is
profile. Similarly, all packets from the original DSCP 001101 stream obviously not sticking to its agreed profile. Similarly, all packets
(some may have been re-marked by this stage) are passed to AlgDropper2 from the original DSCP 001101 stream (some may have been re-marked by
and Queue3. Packets marked for all other DSCPs are passed to this stage) are passed to AlgDropper2 and Queue3. Packets marked for
AlgDropper3 which is a RED-like Algorithmic Dropper: based on feedback all other DSCPs are passed to AlgDropper3 which is a RED-like
of the current depth of Queue4, this dropper is supposed to discard Algorithmic Dropper: based on feedback of the current depth of
enough packets from its input stream to keep the queue depth under Queue4, this dropper is supposed to discard enough packets from its
control. input stream to keep the queue depth under control.
These four Queue elements are then serviced by a Scheduler element These four Queue elements are then serviced by a Scheduler element
Scheduler1: this must be configured to give each of its inputs an Scheduler1: this must be configured to give each of its inputs an
appropriate priority and/or bandwidth share. Inputs A and C are given appropriate priority and/or bandwidth share. Inputs A and C are
guarantees of bandwidth, as appropriate for the contracted profiles. given guarantees of bandwidth, as appropriate for the contracted
Input B is given a limit on the bandwidth it can use i.e. a non-work- profiles. Input B is given a limit on the bandwidth it can use
conserving discipline in order to achieve the desired shaping of this (i.e., a non-work-conserving discipline) in order to achieve the
stream. Input D is given no limits or guarantees but a lower priority desired shaping of this stream. Input D is given no limits or
than the other queues, appropriate for its best-effort status. Traffic guarantees but a lower priority than the other queues, appropriate
then exits the Scheduler in a single orderly stream. for its best-effort status. Traffic then exits the Scheduler in a
single orderly stream.
The interconnections of the TCB elements illustrated in Figures 6 and 7 The interconnections of the TCB elements illustrated in Figures 6 and
can be represented textually as follows: 7 can be represented textually as follows:
TCB1: TCB1:
Classifier1: Classifier1:
FilterA: Meter1 FilterA: Meter1
FilterB: Dropper1 FilterB: Dropper1
FilterC: Meter2 FilterC: Meter2
Default: Dropper3 Default: Dropper3
from Meter1 +-----+ from Meter1 +-----+
------------------------------->| |----+ ------------------------------->| |----+
| | | | | |
+-----+ | +-----+ |
Queue1 | Queue1 |
| +-----+ | +-----+
from Classifier1 +-----+ +-----+ +->|A | from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |-------> ---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting | | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic +-----+ +-----+ | +->|D | traffic
AlgDropper1 Queue2 | | +-----+ AlgDropper1 Queue2 | | +-----+
| | Scheduler1 | | Scheduler1
from Mux1 +-----+ +-----+ | | from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ | ---------------->| |------->| |--+ |
| | | | | | | | | |
+-----+ +-----+ | +-----+ +-----+ |
AlgDropper2 Queue3 | AlgDropper2 Queue3 |
| |
from Classifier1 +-----+ +-----+ | from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+ ---------------->| |------->| |----+
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
AlgDropper3 Queue4 AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2) Figure 7: An Example Traffic Conditioning Block (Part 2)
Meter1: Meter1:
Type: AverageRate Type: AverageRate
Profile: Profile4 Profile: Profile4
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: Counter1 NonConformingOutput: Counter1
Counter1: Counter1:
Output: AbsoluteDropper1 Output: AbsoluteDropper1
Meter2: Meter2:
Type: AverageRate Type: AverageRate
Profile: Profile3 Profile: Profile3
ConformingOutput: Mux1.InputA ConformingOutput: Mux1.InputA
NonConformingOutput: Marker1 NonConformingOutput: Marker1
Marker1: Marker1:
Type: DSCPMarker Type: DSCPMarker
Mark: 001000 Mark: 001000
Output: Mux1.InputB Output: Mux1.InputB
Mux1: Mux1:
Output: Dropper2 Output: Dropper2
AlgDropper1: AlgDropper1:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Queue2.Depth > 10kbyte Trigger: Queue2.Depth > 10kbyte
Output: Queue2 Output: Queue2
AlgDropper2: AlgDropper2:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Queue3.Depth > 20kbyte Trigger: Queue3.Depth > 20kbyte
Output: Queue3 Output: Queue3
AlgDropper3: AlgDropper3:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED93 Discipline: RED93
Trigger: Internal Trigger: Internal
Output: Queue3 Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too> <other RED parms too>
Queue1: Queue1:
Type: FIFO Type: FIFO
Output: Scheduler1.InputA Output: Scheduler1.InputA
Queue2:
Type: FIFO
Output: Scheduler1.InputB
Queue3: Queue2:
Type: FIFO Type: FIFO
Output: Scheduler1.InputC Output: Scheduler1.InputB
Queue4: Queue3:
Type: FIFO Type: FIFO
Output: Scheduler1.InputD Output: Scheduler1.InputC
Scheduler1: Queue4:
Type: Scheduler4Input Type: FIFO
InputA: Output: Scheduler1.InputD
MaxRateProfile: none
MinRateProfile: Profile4 Scheduler1:
Priority: 20 Type: Scheduler4Input
InputB: InputA:
MaxRateProfile: Profile5 MaxRateProfile: none
MinRateProfile: none MinRateProfile: Profile4
Priority: 40 Priority: 20
InputC: InputB:
MaxRateProfile: none MaxRateProfile: Profile5
MinRateProfile: Profile3 MinRateProfile: none
Priority: 20 Priority: 40
InputD: InputC:
MaxRateProfile: none MaxRateProfile: none
MinRateProfile: none MinRateProfile: Profile3
Priority: 10 Priority: 20
InputD:
MaxRateProfile: none
MinRateProfile: none
Priority: 10
8.3. An Example TCB to Support Multiple Customers 8.3. An Example TCB to Support Multiple Customers
The TCB described above can be installed on an ingress interface to The TCB described above can be installed on an ingress interface to
implement a provider/customer TCS if the interface is dedicated to the implement a provider/customer TCS if the interface is dedicated to
customer. However, if a single interface is shared between multiple the customer. However, if a single interface is shared between
customers, then the TCB above will not suffice, since it does not multiple customers, then the TCB above will not suffice, since it
differentiate among traffic from different customers. Its classification does not differentiate among traffic from different customers. Its
stage uses only BA classifiers. classification stage uses only BA classifiers.
The configuration is readily modified to support the case of multiple The configuration is readily modified to support the case of multiple
customers per interface, as follows. First, a TCB is defined for each customers per interface, as follows. First, a TCB is defined for
customer to reflect the TCS with that customer: TCB1, defined above is each customer to reflect the TCS with that customer: TCB1, defined
the TCB for customer 1. Similar elements are created for TCB2 and for above is the TCB for customer 1. Similar elements are created for
TCB3 which reflect the agreements with customers 2 and 3 respectively. TCB2 and for TCB3 which reflect the agreements with customers 2 and 3
These 3 TCBs may or may not contain similar elements and parameters. respectively. These 3 TCBs may or may not contain similar elements
and parameters.
Finally, a classifier is added to the front end to separate the traffic Finally, a classifier is added to the front end to separate the
from the three different customers. This forms a new TCB, TCB4, which is traffic from the three different customers. This forms a new TCB,
illustrated in Figure 8. TCB4, which is illustrated in Figure 8.
A representation of this multi-customer TCB might be: A representation of this multi-customer TCB might be:
TCB4: TCB4:
Classifier4: Classifier4:
Filter1: to TCB1 Filter1: to TCB1
Filter2: to TCB2 Filter2: to TCB2
Filter3: to TCB3 Filter3: to TCB3
No Match: AbsoluteDropper4 No Match: AbsoluteDropper4
AbsoluteDropper4: AbsoluteDropper4:
skipping to change at page 41, line 33 skipping to change at page 43, line 36
(as defined above) (as defined above)
TCB2: TCB2:
(similar to TCB1, perhaps with different (similar to TCB1, perhaps with different
elements or numeric parameters) elements or numeric parameters)
TCB3: TCB3:
(similar to TCB1, perhaps with different (similar to TCB1, perhaps with different
elements or numeric parameters) elements or numeric parameters)
and the filters, based on each customer's source MAC address, could be and the filters, based on each customer's source MAC address, could
defined as follows: be defined as follows:
Filter1: Filter1:
submitted +-----+ submitted +-----+
traffic | A|--------> TCB1 traffic | A|--------> TCB1
--------->| B|--------> TCB2 --------->| B|--------> TCB2
| C|--------> TCB3 | C|--------> TCB3
| X|------+ +-----+ | X|------+ +-----+
+-----+ +-->| | +-----+ +-->| |
Classifier4 +-----+ Classifier4 +-----+
skipping to change at page 42, line 12 skipping to change at page 44, line 12
Figure 8: An Example of a Multi-Customer TCB Figure 8: An Example of a Multi-Customer TCB
Type: MacAddress Type: MacAddress
SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1)
SrcMask: FF-FF-FF-FF-FF-FF SrcMask: FF-FF-FF-FF-FF-FF
DestValue: 00-00-00-00-00-00 DestValue: 00-00-00-00-00-00
DestMask: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00
Filter2: Filter2:
(similar to Filter1 but with customer 2's source MAC address as (similar to Filter1 but with customer 2's source MAC address as
SrcValue) SrcValue)
Filter3: Filter3:
(similar to Filter1 but with customer 3's source MAC address as (similar to Filter1 but with customer 3's source MAC address as
SrcValue) SrcValue)
In this example, Classifier4 separates traffic submitted from different In this example, Classifier4 separates traffic submitted from
customers based on the source MAC address in submitted packets. Those different customers based on the source MAC address in submitted
packets with recognized source MAC addresses are passed to the TCB packets. Those packets with recognized source MAC addresses are
implementing the TCS with the corresponding customer. Those packets with passed to the TCB implementing the TCS with the corresponding
unrecognized source MAC addresses are passed to a dropper. customer. Those packets with unrecognized source MAC addresses are
passed to a dropper.
TCB4 has a Classifier stage and an Action element stage performing TCB4 has a Classifier stage and an Action element stage performing
dropping of all unmatched traffic. dropping of all unmatched traffic.
8.4. TCBs Supporting Microflow-based Services 8.4. TCBs Supporting Microflow-based Services
The TCB illustrated above describes a configuration that might be The TCB illustrated above describes a configuration that might be
suitable for enforcing a SLS at a router's ingress. It assumes that the suitable for enforcing a SLS at a router's ingress. It assumes that
customer marks its own traffic for the appropriate service level. It the customer marks its own traffic for the appropriate service level.
then limits the rate of aggregate traffic submitted at each service It then limits the rate of aggregate traffic submitted at each
level, thereby protecting the resources of the Diffserv network. It does service level, thereby protecting the resources of the Diffserv
not provide any isolation between the customer's individual microflows. network. It does not provide any isolation between the customer's
individual microflows.
A more complex example might be a TCB configuration that offers A more complex example might be a TCB configuration that offers
additional functionality to the customer. It recognizes individual additional functionality to the customer. It recognizes individual
customer microflows and marks each one independently. It also isolates customer microflows and marks each one independently. It also
the customer's individual microflows from each other in order to prevent isolates the customer's individual microflows from each other in
a single microflow from seizing an unfair share of the resources order to prevent a single microflow from seizing an unfair share of
available to the customer at a certain service level. This is the resources available to the customer at a certain service level.
illustrated in Figure 9. This is illustrated in Figure 9.
Suppose that the customer has an SLS which specifies 2 service
levels, to be identified to the provider by DSCP A and DSCP B.
Traffic is first directed to a MF classifier which classifies traffic
based on miscellaneous classification criteria, to a granularity
sufficient to identify individual customer microflows. Each
microflow can then be marked for a specific DSCP The metering
elements limit the contribution of each of the customer's microflows
to the service level for which it was marked. Packets exceeding the
allowable limit for the microflow are dropped.
Suppose that the customer has an SLS which specifices 2 service levels,
to be identifed to the provider by DSCP A and DSCP B. Traffic is first
directed to a MF classifier which classifies traffic based on
miscellaneous classification criteria, to a granularity sufficient to
identify individual customer microflows. Each microflow can then be
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
+-----+ +-----+ +-----+ +-----+
Classifier1 | | | |---------------+ Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ | (MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | | +-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ | | A|------ +-----+ +-----+ +-----+ |
--->| B|-----+ Marker1 Meter1 Absolute | -->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+ | C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A | | X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |---> +-----+ | | | | | | |------------------>|B |--->
| | +->| |-->| | +-----+ +-->|C | to TCB2 | | +->| |-->| | +-----+ +-->|C | to TCB2
| | | | | |---->| | | +-----+ | | | | | |---->| | | +-----+
| | +-----+ +-----+ +-----+ | Mux1 | | +-----+ +-----+ +-----+ | Mux1
| | Marker2 Meter2 Absolute | | | Marker2 Meter2 Absolute |
| | Dropper2 | | | Dropper2 |
| | +-----+ +-----+ | | | +-----+ +-----+ |
| | | | | |---------------+ | | | | | |---------------+
| |--->| |-->| | +-----+ | |--->| |-->| | +-----+
| | | | |---->| | | | | | |---->| |
| +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute | Marker3 Meter3 Absolute
| Dropper3 | Dropper3
V etc. V etc.
Figure 9: An Example of a Marking and Traffic Isolation TCB Figure 9: An Example of a Marking and Traffic Isolation TCB
was marked. Packets exceeding the allowable limit for the microflow are This TCB could be formally specified as follows:
dropped.
This TCB could be formally specified as follows:
TCB1: TCB1:
Classifier1: (MF) Classifier1: (MF)
FilterA: Marker1 FilterA: Marker1
FilterB: Marker2 FilterB: Marker2
FilterC: Marker3 FilterC: Marker3
etc. etc.
Marker1: Marker1:
Output: Meter1 Output: Meter1
skipping to change at page 44, line 21 skipping to change at page 46, line 21
Meter3: Meter3:
ConformingOutput: Mux1.InputC ConformingOutput: Mux1.InputC
NonConformingOutput: AbsoluteDropper3 NonConformingOutput: AbsoluteDropper3
etc. etc.
Mux1: Mux1:
Output: to TCB2 Output: to TCB2
Note that the detailed traffic element declarations are not shown here. Note that the detailed traffic element declarations are not shown
Traffic is either dropped by TCB1 or emerges marked for one of two here. Traffic is either dropped by TCB1 or emerges marked for one of
DSCPs. This traffic is then passed to TCB2 which is illustrated in two DSCPs. This traffic is then passed to TCB2 which is illustrated
Figure 10. in Figure 10.
TCB2 could then be specified as follows: TCB2 could then be specified as follows:
Classifier2: (BA) Classifier2: (BA)
FilterA: Meter5 FilterA: Meter5
FilterB: Meter6 FilterB: Meter6
+-----+ +-----+
| |---------------> to Queue1 | |---------------> to Queue1
+->| | +-----+ +->| | +-----+
+-----+ | | |---->| | +-----+ | | |---->| |
| A|---+ +-----+ +-----+ | A|---+ +-----+ +-----+
skipping to change at page 45, line 4 skipping to change at page 46, line 46
| A|---+ +-----+ +-----+ | A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4 ->| | Meter5 AbsoluteDropper4
| B|---+ +-----+ | B|---+ +-----+
+-----+ | | |---------------> to Queue2 +-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+ Classifier2 +->| | +-----+
(BA) | |---->| | (BA) | |---->| |
+-----+ +-----+ +-----+ +-----+
Meter6 AbsoluteDropper5 Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2 Figure 10: Additional Example: TCB2
Meter5: Meter5:
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper4 NonConformingOutput: AbsoluteDropper4
Meter6: Meter6:
ConformingOutput: Queue2 ConformingOutput: Queue2
NonConformingOutput: AbsoluteDropper5 NonConformingOutput: AbsoluteDropper5
8.5. Cascaded TCBs 8.5. Cascaded TCBs
Nothing in this model prevents more complex scenarios in which one Nothing in this model prevents more complex scenarios in which one
microflow TCB precedes another (e.g. for TCBs implementing separate TCSs microflow TCB precedes another (e.g., for TCBs implementing separate
for the source and for a set of destinations). TCSs for the source and for a set of destinations).
9. Security Considerations 9. Security Considerations
Security vulnerabilities of Diffserv network operation are discussed in Security vulnerabilities of Diffserv network operation are discussed
[DSARCH]. This document describes an abstract functional model of in [DSARCH]. This document describes an abstract functional model of
Diffserv router elements. Certain denial-of-service attacks such as Diffserv router elements. Certain denial-of-service attacks such as
those resulting from resource starvation may be mitigated by appropriate those resulting from resource starvation may be mitigated by
configuration of these router elements; for example, by rate limiting appropriate configuration of these router elements; for example, by
certain traffic streams or by authenticating traffic marked for higher rate limiting certain traffic streams or by authenticating traffic
quality-of-service. marked for higher quality-of-service.
One particular theft- or denial-of-service issue may arise where a There may be theft-of-service scenarios where a malicious host can
token-bucket meter, with an absolute dropper for non-conforming traffic, exploit a loose token bucket policer to obtain slightly better QoS
is used in a TCB to police a stream to a given TCS: suppose that the than that committed in the TCS.
leaky-bucket scheduler that sent the packet was being conservative in
that it only transmitted the packet if the whole packet fitted within
the profile; suppose further that the token-bucket meter is using a
"loose" conformance test, as described in section 5, and indicates that
it should accept this packet even though not all of the bits would have
been within the profile: this difference may be exploited by a malicious
scheduler either to obtain QoS treatment for more octets than allowed in
the TCS or to disrupt (perhaps only slightly) the QoS guarantees
promised to other traffic streams.
10. Acknowledgments 10. Acknowledgments
Concepts, terminology, and text have been borrowed liberally from Concepts, terminology, and text have been borrowed liberally from
[POLTERM], as well as from other IETF work on MIBs and policy- [POLTERM], as well as from other IETF work on MIBs and policy-
management. We wish to thank the authors of some of those documents: management. We wish to thank the authors of some of those documents:
Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan,
Scott Hahn and Andrea Westerinen for their contributions. Scott Hahn, and Andrea Westerinen for their contributions.
This document has benefitted from the comments and suggestions of This document has benefited from the comments and suggestions of
several participants of the Diffserv working group, particularly Shahram several participants of the Diffserv working group, particularly
Davari, John Strassner and Walter Weiss. This document could never have Shahram Davari, John Strassner, and Walter Weiss. This document
reached this level of rough consensus without the relentless pressure of could never have reached this level of rough consensus without the
the co-chairs Brian Carpenter and Kathie Nichols, for which the authors relentless pressure of the co-chairs Brian Carpenter and Kathie
are grateful. Nichols, for which the authors are grateful.
11. References 11. References
[AF-PHB] [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured "Assured Forwarding PHB Group", RFC 2597, June 1999.
Forwarding PHB Group", RFC 2597, June 1999.
[DSARCH] [DSARCH] Carlson, M., Weiss, W., Blake, S., Wang, Z., Black, D.
M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, and E. Davies, "An Architecture for Differentiated
"An Architecture for Differentiated Services", RFC 2475, December Services", RFC 2475, December 1998.
1998
[DSFIELD] [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the "Definition of the Differentiated Services Field (DS
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Field) in the IPv4 and IPv6 Headers", RFC 2474, December
Headers", RFC 2474, December 1998. 1998.
[DSMIB] [DSMIB] Baker, F., Smith, A., and K. Chan, "Management
F. Baker, A. Smith, K. Chan, "Differentiated Services MIB", Information Base for the Differentiated Services
Internet Draft <http://www.ietf.org/internet-drafts/draft-ietf- Architecture", RFC 3289, May 2002.
diffserv-mib-06.txt>, January 2001.
[E2E] [E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K. Speer, M., Nichols, K., Braden, R., Davie, B.,
Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A Wroclawski, J. and E. Felstaine, "A Framework for
Framework for Integrated Services Operation over Diffserv Integrated Services Operation over Diffserv Networks",
Networks", RFC 2998, November 2000. RFC 2998, November 2000.
[EF-PHB] [EF-PHB] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le
V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D.
PHB", RFC 2598, June 1999. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[FJ95] [FJ95] Floyd, S. and V. Jacobson, "Link Sharing and Resource
S. Floyd and V. Jacobson, "Link Sharing and Resource Management Management Models for Packet Networks", IEEE/ACM
Models for Packet Networks", IEEE/ACM Transactions on Networking, Transactions on Networking, Vol. 3 No. 4, August 1995l.
Vol. 3 No. 4, August 1995
[INTSERV] [INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated
R. Braden, D. Clark and S. Shenker, "Integrated Services in the Services in the Internet Architecture: an Overview", RFC
Internet Architecture: an Overview", RFC 1633, June 1994. 1633, June 1994.
[PDBDEF] [NEWTERMS] Grossman, D., "New Terminology and Clarifications for
K. Nichols and B. Carpenter, "Definition of Differentiated Services Diffserv", RFC 3260, April, 2002
Per Domain Behaviors and Rules for Their Specification", Internet
Draft <http://www.ietf.org/internet-drafts/draft-heinanen-diffserv-
pdb-def-03.txt>
[POLTERM] [PDBDEF] K. Nichols and B. Carpenter, "Definition of
A. Westerinen et al., "Policy Terminology", Internet Draft Differentiated Services Per Domain Behaviors and Rules
<http://www.ietf.org/internet-drafts/draft-ietf-policy- for Their Specification", RFC 3086, April 2001.
terminology-01.txt>, November 2000.
[QOSDEVMOD] [POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
J. Strassner, A. Westerinen, B. Moore, "Information Model for M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
Describing Network Device QoS Mechanisms", Internet Draft J. and S. Waldbusser, "Policy Terminology", RFC 3198,
<http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device- November 2001.
info-model-02.txt>, November 2000
[QUEUEMGMT] [QOSDEVMOD] Strassner, J., Westerinen, A. and B. Moore, "Information
B. Braden et al., "Recommendations on Queue Management and Model for Describing Network Device QoS Mechanisms", Work
Congestion Avoidance in the Internet", RFC 2309, April 1998. in Progress.
[SRTCM] [QUEUEMGMT] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering,
J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC S., Estrin, D., Floyd, S., Jacobson, V., Minshall, C.,
2697, September 1999. Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J. and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[TRTCM] [SRTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color
J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698, Marker", RFC 2697, September 1999.
September 1999.
[VIC] [TRTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color
McCanne, S. and Jacobson, V., "vic: A Flexible Framework for Packet Marker", RFC 2698, September 1999.
Video", ACM Multimedia '95, November 1995, San Francisco, CA, pp.
511-522. <ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[802.1D] [VIC] McCanne, S. and Jacobson, V., "vic: A Flexible Framework
"Information technology - Telecommunications and information for Packet Video", ACM Multimedia '95, November 1995, San
exchange between systems - Local and metropolitan area networks - Francisco, CA, pp. 511-522.
Common specifications - Part 3: Media Access Control (MAC) Bridges: <ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.",
ISO/IEC 15802-3: 1998.
12. Appendix A. Discussion of Token Buckets and Leaky Buckets [802.1D] "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Media Access Control (MAC) Bridges: Revision. This
is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and
802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e.", ISO/IEC 15802-3: 1998.
The concept used for rate-control in several architectures, including Appendix A. Discussion of Token Buckets and Leaky Buckets
ATM, Frame Relay, Integrated Services and Differentiated Services,
consists of "leaky buckets" and/or "token buckets". Both of these are,
by definition, theoretical relationships between some defined burst
size, B, a rate, R, and a time interval, t:
R = B/t "Leaky bucket" and/or "Token Bucket" models are used to describe rate
control in several architectures, including Frame Relay, ATM,
Integrated Services and Differentiated Services. Both of these
models are, by definition, theoretical relationships between some
defined burst size, B, a rate, R, and a time interval, t:
Thus, a token bucket or leaky bucket might specify an information rate R = B/t
of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token
rate is 1,200,000 bits per second, the token burst is 12,000 bits and Thus, a token bucket or leaky bucket might specify an information
the token interval is 10 milliseconds. The specification says that rate of 1.2 Mbps with a burst size of 1500 bytes. In this case, the
conforming traffic will, in the worst case, come in 100 bursts per token rate is 1,200,000 bits per second, the token burst is 12,000
second of 1500 bytes each and at an average rate not exceeding 1.2 Mbps. bits and the token interval is 10 milliseconds. The specification
says that conforming traffic will, in the worst case, come in 100
bursts per second of 1500 bytes each and at an average rate not
exceeding 1.2 Mbps.
A.1 Leaky Buckets A.1 Leaky Buckets
A leaky bucket algorithm is primarily used for shaping traffic as it A leaky bucket algorithm is primarily used for shaping traffic as it
leaves an interface onto the network (handled under Queues and leaves an interface onto the network (handled under Queues and
Schedulers in this model). Traffic theoretically departs from an Schedulers in this model). Traffic theoretically departs from an
interface at a rate of one bit every so many time units (in the example, interface at a rate of one bit every so many time units (in the
one bit every 0.83 microseconds) but, in fact, departs in multi-bit example, one bit every 0.83 microseconds) but, in fact, departs in
units (packets) at a rate approximating the theoretical, as measured multi-bit units (packets) at a rate approximating the theoretical, as
over a longer interval. In the example, it might send one 1500 byte measured over a longer interval. In the example, it might send one
packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is 1500 byte packet every 10 ms or perhaps one 500 byte packet every 3.3
also possible to build multi-rate leaky buckets in which traffic departs ms. It is also possible to build multi-rate leaky buckets in which
from the interface at varying rates depending on recent activity or traffic departs from the interface at varying rates depending on
inactivity. recent activity or inactivity.
Implementations generally seek as constant a transmission rate as Implementations generally seek as constant a transmission rate as
achievable. In theory, a 10 Mbps shaped transmission stream from an achievable. In theory, a 10 Mbps shaped transmission stream from an
algorithmic implementation and a stream which is running at 10 Mbps algorithmic implementation and a stream which is running at 10 Mbps
because its bottleneck link has been a 10 Mbps Ethernet link should be because its bottleneck link has been a 10 Mbps Ethernet link should
indistinguishable. Depending on configuration, the approximation to be indistinguishable. Depending on configuration, the approximation
theoretical smoothness may vary by moving as much as an MTU from one to theoretical smoothness may vary by moving as much as an MTU from
token interval to another. Traffic may also be jostled by other traffic one token interval to another. Traffic may also be jostled by other
competing for the same transmission resources. traffic competing for the same transmission resources.
A.2 Token Buckets A.2 Token Buckets
A token bucket, on the other hand, measures the arrival rate of traffic A token bucket, on the other hand, measures the arrival rate of
from another device. This traffic may originally have been shaped using traffic from another device. This traffic may originally have been
a leaky bucket shaper or its equivalent. The token bucket determines shaped using a leaky bucket shaper or its equivalent. The token
whether the traffic (still) conforms to the specification. Multi-rate bucket determines whether the traffic (still) conforms to the
token buckets (e.g. token buckets with both a peak rate and a mean rate, specification. Multi-rate token buckets (e.g., token buckets with
and sometimes more) are commonly used, such as those described in both a peak rate and a mean rate, and sometimes more) are commonly
[SRTCM] and [TRTCM]. In this case, absolute smoothness is not expected, used, such as those described in [SRTCM] and [TRTCM]. In this case,
but conformance to one or more of the specified rates is. absolute smoothness is not expected, but conformance to one or more
of the specified rates is.
Simplistically, a data stream is said to conform to a simple token Simplistically, a data stream is said to conform to a simple token
bucket parameterised by a {R, B} if the system receives in any time bucket parameterized by a {R, B} if the system receives in any time
interval, t, at most, an amount of data not exceeding (R * t) + B. interval, t, at most, an amount of data not exceeding (R * t) + B.
For a multi-rate token bucket case, the data stream is said to conform For a multi-rate token bucket case, the data stream is said to
if, for each of the rates, the stream conforms to the token-bucket conform if, for each of the rates, the stream conforms to the token-
profile appropriate for traffic of that class. For example, received bucket profile appropriate for traffic of that class. For example,
traffic that arrives pre-classified as one of the "excess" rates (e.g. received traffic that arrives pre-classified as one of the "excess"
AF12 or AF13 traffic for a device implementing the AF1x PHB) is only rates (e.g., AF12 or AF13 traffic for a device implementing the AF1x
compared to the relevant "excess" token bucket profile. PHB) is only compared to the relevant "excess" token bucket profile.
A.3 Some Consequences A.3 Some Consequences
The fact that Internet Protocol data is organized into variable length
packets introduces some uncertainty in the conformance decision made by
any downstream Meter that is attempting to determine conformance to a
traffic profile that is theoretically designed for fixed-length units of
data.
When used as a leaky bucket shaper, the above definition interacts with The fact that Internet Protocol data is organized into variable
clock granularity in ways one might not expect. A leaky bucket releases length packets introduces some uncertainty in the conformance
a packet only when all of its bits would have been allowed: it does not decision made by any downstream Meter that is attempting to determine
borrow from future capacity. If the clock is very fine grain, on the conformance to a traffic profile that is theoretically designed for
order of the bit rate or faster, this is not an issue. But if the clock fixed-length units of data.
is relatively slow (and millisecond or multi-millisecond clocks are not
unusual in networking equipment), this can introduce jitter to the
shaped stream.
This leaves an implementor of a token bucket Meter with a dilemma. When When used as a leaky bucket shaper, the above definition interacts
the number of bandwidth tokens, b, left in the token bucket is positive with clock granularity in ways one might not expect. A leaky bucket
but less than the size of the packet being operated on, L, one of three releases a packet only when all of its bits would have been allowed:
actions can be performed: it does not borrow from future capacity. If the clock is very fine
grain, on the order of the bit rate or faster, this is not an issue.
But if the clock is relatively slow (and millisecond or multi-
millisecond clocks are not unusual in networking equipment), this can
introduce jitter to the shaped stream.
(1) The whole size of the packet can be substracted from the bucket, This leaves an implementor of a token bucket Meter with a dilemma.
leaving it negative, remembering that, when new tokens are next When the number of bandwidth tokens, b, left in the token bucket is
added to the bucket, the new token allocation, B, must be added positive but less than the size of the packet being operated on, L,
to b rather than simply setting the bucket to "full". This option one of three actions can be performed:
potentially puts more than the desired burst size of data into
this token bucket interval and correspondingly less into the
next. It does, however, keep the average amount accepted per
token bucket interval equal to the token burst. This approach
accepts traffic if any one bit in the packet would have been
accepted and borrows up to one MTU of capacity from one or more
subsequent intervals when necessary. Such a token bucket meter
implementation is said to offer "loose" conformance to the token
bucket.
(2) Alternatively, the packet can be rejected and the amount of (1) The whole size of the packet can be subtracted from the
tokens in the bucket left unchanged (and maybe an attempt could bucket, leaving it negative, remembering that, when new
be made to accept the packet under another threshold in another tokens are next added to the bucket, the new token
bucket), remembering that, when new tokens are next added to the allocation, B, must be added to b rather than simply setting
bucket, the new token allocation, B, must be added to b rather the bucket to "full". This option potentially puts more
than simply setting the bucket to "full". This potentially puts than the desired burst size of data into this token bucket
less than the permissible burst size of data into this token interval and correspondingly less into the next. It does,
bucket interval and correspondingly more into the next. Like the however, keep the average amount accepted per token bucket
first option, it keeps the average amount accepted per token interval equal to the token burst. This approach accepts
bucket interval equal to the token burst. This approach accepts traffic if any one bit in the packet would have been
traffic only if every bit in the packet would have been accepted accepted and borrows up to one MTU of capacity from one or
and borrows up to one MTU of capacity from one or more previous more subsequent intervals when necessary. Such a token
intervals when necessary. Such a token bucket meter bucket meter implementation is said to offer "loose"
implementation is said to offer "strict" (or perhaps "stricter") conformance to the token bucket.
conformance to the token bucket. This option is consistent with
[SRTCM] and [TRTCM] and is often used in ATM and frame-relay
implementations.
(3) The TB variable can be set to zero to account for the first part (2) Alternatively, the packet can be rejected and the amount of
of the packet and the remainder of the packet size can be taken tokens in the bucket left unchanged (and maybe an attempt
out of the next-colored bucket. This, of course, has another bug: could be made to accept the packet under another threshold
the same packet cannot have both conforming and nonconforming in another bucket), remembering that, when new tokens are
components in the Diffserv architecture and so is not really next added to the bucket, the new token allocation, B, must
appropriate here and we do not discuss this option further here. be added to b rather than simply setting the bucket to
"full". This potentially puts less than the permissible
burst size of data into this token bucket interval and
correspondingly more into the next. Like the first option,
it keeps the average amount accepted per token bucket
interval equal to the token burst. This approach accepts
traffic only if every bit in the packet would have been
accepted and borrows up to one MTU of capacity from one or
more previous intervals when necessary. Such a token bucket
meter implementation is said to offer "strict" (or perhaps
"stricter") conformance to the token bucket. This option is
consistent with [SRTCM] and [TRTCM] and is often used in ATM
and frame-relay implementations.
Unfortunately, the thing that cannot be done is exactly to fit the token (3) The TB variable can be set to zero to account for the first
burst specification with random sized packets: therefore token buckets part of the packet and the remainder of the packet size can
in a variable length packet environment always have a some variance from be taken out of the next-colored bucket. This, of course,
theoretical reality. This has also been observed in the ATM Guaranteed has another bug: the same packet cannot have both
Frame Rate (GFR) service category specification and Frame Relay. A conforming and non-conforming components in the Diffserv
number of observations may be made: architecture and so is not really appropriate here and we do
not discuss this option further here.
o Operationally, a token bucket meter is reasonable for traffic which Unfortunately, the thing that cannot be done is exactly to
has been shaped by a leaky bucket shaper or a serial line. However, fit the token burst specification with random sized packets:
traffic in the Internet is rarely shaped in that way: TCP applies therefore token buckets in a variable length packet
no shaping to its traffic, but rather depends on longer-range ACK- environment always have a some variance from theoretical
clocking behavior to help it approximate a certain rate and reality. This has also been observed in the ATM Guaranteed
explicitly sends traffic bursts during slow start, retransmission Frame Rate (GFR) service category specification and Frame
and fast recovery. Video-on-IP implementations such as [VIC] may Relay. A number of observations may be made:
have a leaky bucket shaper available to them, but often do not, and
simply enqueue the output of their codec for transmission on the
appropriate interface. As a result, in each of these cases, a token
bucket meter may reject traffic in the short term (over a single
token interval) which it would have accepted if it had a longer
time in view and which it needs to accept for the application to
work properly. To work around this, the token interval, B/R, must
approximate or exceed the RTT of the session(s) in question and the
burst size, B, must accommodate the largest burst that the
originator might send.
o The behavior of a loose token bucket is significantly different o Operationally, a token bucket meter is reasonable for traffic
from the token bucket description for ATM and for Frame Relay. which has been shaped by a leaky bucket shaper or a serial line.
However, traffic in the Internet is rarely shaped in that way: TCP
applies no shaping to its traffic, but rather depends on longer-
range ACK-clocking behavior to help it approximate a certain rate
and explicitly sends traffic bursts during slow start,
retransmission, and fast recovery. Video-on-IP implementations
such as [VIC] may have a leaky bucket shaper available to them,
but often do not, and simply enqueue the output of their codec for
transmission on the appropriate interface. As a result, in each
of these cases, a token bucket meter may reject traffic in the
short term (over a single token interval) which it would have
accepted if it had a longer time in view and which it needs to
accept for the application to work properly. To work around this,
the token interval, B/R, must approximate or exceed the RTT of the
session(s) in question and the burst size, B, must accommodate the
largest burst that the originator might send.
o A loose token bucket does not accept packets while the token count o The behavior of a loose token bucket is significantly different
is negative. This means that, when a large packet has just borrowed from the token bucket description for ATM and for Frame Relay.
tokens from the future, even a small incoming packet e.g. a 40-byte
TCP ACK/SYN will not be accepted. Therefore, if such a loose token
bucket is configured with a burst size close to the MTU, some
discrimination against smaller packets can take place: use of a
larger burst size avoids this problem.
o The converse of the above is that a strict token bucket sometimes o A loose token bucket does not accept packets while the token count
does not accept large packets when a loose one would do so. is negative. This means that, when a large packet has just
Therefore, if such a strict token bucket is configured with a burst borrowed tokens from the future, even a small incoming packet
size close to the MTU, some discrimination against larger packets (e.g., a 40-byte TCP ACK/SYN) will not be accepted. Therefore, if
can take place: use of a larger burst size avoids this problem. such a loose token bucket is configured with a burst size close to
the MTU, some discrimination against smaller packets can take
place: use of a larger burst size avoids this problem.
o In real-world deployments, MTUs are often larger than the burst o The converse of the above is that a strict token bucket sometimes
size offered by a link-layer network service provider. If so then does not accept large packets when a loose one would do so.
it is possible that a strict token bucket meter would find that Therefore, if such a strict token bucket is configured with a
traffic never matches the specified profile: this may be avoided by burst size close to the MTU, some discrimination against larger
not allowing such a specification to be used. This situation cannot packets can take place: use of a larger burst size avoids this
arise with a loose token bucket since the smallest burst size that problem.
can be configured is 1 bit, by definition limiting a loose token
bucket to having a burst size of greater than one MTU.
o Both strict token bucket specifications, as specified in [SRTCM] o In real-world deployments, MTUs are often larger than the burst
and [TRTCM], and loose ones, are subject to a persistent under-run. size offered by a link-layer network service provider. If so then
These accumulate burst capacity over time, up to the maximum burst it is possible that a strict token bucket meter would find that
size. Suppose that the maximum burst size is exactly the size of traffic never matches the specified profile: this may be avoided
the packets being sent - which one might call the "strictest" token by not allowing such a specification to be used. This situation
bucket implementation. In such a case, when one packet has been cannot arise with a loose token bucket since the smallest burst
accepted, the token depth becomes zero and starts to accumulate size that can be configured is 1 bit, by definition limiting a
again. If the next packet is received any time earlier than a loose token bucket to having a burst size of greater than one MTU.
token interval later, it will not be accepted. If the next packet
arrives exactly on time, it will be accepted and the token depth o Both strict token bucket specifications, as specified in [SRTCM]
again set to zero. If it arrives later, however, accumulation of and [TRTCM], and loose ones, are subject to a persistent under-
tokens will have stopped because it is capped by the maximum burst run. These accumulate burst capacity over time, up to the maximum
size: during the interval between the bucket becoming full and the burst size. Suppose that the maximum burst size is exactly the
actual arrival of the packet, no new tokens are added. As a result, size of the packets being sent - which one might call the
jitter that accumulates across multiple hops in the network "strictest" token bucket implementation. In such a case, when one
conspires against the algorithm to reduce the actual acceptance packet has been accepted, the token depth becomes zero and starts
rate. Thus it usually makes sense to set the maximum token bucket to accumulate again. If the next packet is received any time
size somewhat greater than the MTU in order to absorb some of the earlier than a token interval later, it will not be accepted. If
jitter and allow a practical acceptance rate more in line with the the next packet arrives exactly on time, it will be accepted and
desired theoretical rate. the token depth again set to zero. If it arrives later, however,
accumulation of tokens will have stopped because it is capped by
the maximum burst size: during the interval between the bucket
becoming full and the actual arrival of the packet, no new tokens
are added. As a result, jitter that accumulates across multiple
hops in the network conspires against the algorithm to reduce the
actual acceptance rate. Thus it usually makes sense to set the
maximum token bucket size somewhat greater than the MTU in order
to absorb some of the jitter and allow a practical acceptance rate
more in line with the desired theoretical rate.
A.4 Mathematical Definition of Strict Token Bucket Conformance A.4 Mathematical Definition of Strict Token Bucket Conformance
The strict token bucket conformance behavior defined in [SRTCM] and The strict token bucket conformance behavior defined in [SRTCM] and
[TRTCM] is not mandatory for compliance with any current Diffserv [TRTCM] is not mandatory for compliance with any current Diffserv
standards, but we give here a mathematical definition of two-parameter standards, but we give here a mathematical definition of two-
token bucket operation which is consistent with those documents and parameter token bucket operation which is consistent with those
which can also be used to define a shaping profile. documents and which can also be used to define a shaping profile.
Define a token bucket with bucket size B, token accumulation rate R and Define a token bucket with bucket size B, token accumulation rate R
instantaneous token occupancy b(t). Assume that b(0) = B. Then after an and instantaneous token occupancy b(t). Assume that b(0) = B. Then
arbitrary interval with no packet arrivals, b(t) will not change since after an arbitrary interval with no packet arrivals, b(t) will not
the bucket is already full of tokens. change since the bucket is already full of tokens.
Assume a packet of size L bytes arrives at time t'. The bucket occupancy Assume a packet of size L bytes arrives at time t'. The bucket
is still B. Then, as long as L <= B, the packet conforms to the meter, occupancy is still B. Then, as long as L <= B, the packet conforms
and afterwards to the meter, and afterwards
b(t') = B - L. b(t') = B - L.
Assume now an interval delta_t = t - t' elapses before the next packet Assume now an interval delta_t = t - t' elapses before the next
arrives, of size L' <= B. Just before this, at time t-, the bucket has packet arrives, of size L' <= B. Just before this, at time t-, the
accumulated delta_t*R tokens over the interval, up to a maximum of B bucket has accumulated delta_t*R tokens over the interval, up to a
tokens so that: maximum of B tokens so that:
b(t-) = min{ B, b(t') + delta_t*R } b(t-) = min{ B, b(t') + delta_t*R }
For a strict token bucket, the conformance test is as follows: For a strict token bucket, the conformance test is as follows:
if (b(t-) - L' >= 0) { if (b(t-) - L' >= 0) {
/* the packet conforms */ /* the packet conforms */
b(t) = b(t-) - L'; b(t) = b(t-) - L';
} }
else { else {
/* the packet does not conform */ /* the packet does not conform */
b(t) = b(t-); b(t) = b(t-);
} }
This function can also be used to define a shaping profile. If a packet This function can also be used to define a shaping profile. If a
of size L arrives at time t, it will be eligible for transmission at packet of size L arrives at time t, it will be eligible for
time te given as follows (we still assume L <= B): transmission at time te given as follows (we still assume L <= B):
te = max{ t, t" } te = max{ t, t" }
where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L credits where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L
have accumulated in the bucket, and when the packet would conform if the credits have accumulated in the bucket, and when the packet would
token bucket were a meter. te != t" only if t > t". conform if the token bucket were a meter. te != t" only if t > t".
A mathematical definition along these lines for loose token bucket A mathematical definition along these lines for loose token bucket
conformance is left as an exercise for the reader. conformance is left as an exercise for the reader.
13. Authors' Addresses Authors' Addresses
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 936 9568 Phone: +1 425 936 9568
E-mail: yoramb@microsoft.com EMail: ybernet@msn.com
Steven Blake Steven Blake
Ericsson Ericsson
920 Main Campus Drive, Suite 500 920 Main Campus Drive, Suite 500
Raleigh, NC 27606 Raleigh, NC 27606
Phone: +1 919 472 9913 Phone: +1 919 472 9913
E-mail: steven.blake@ericsson.com EMail: steven.blake@ericsson.com
Daniel Grossman Daniel Grossman
Motorola Inc. Motorola Inc.
20 Cabot Blvd. 20 Cabot Blvd.
Mansfield, MA 02048 Mansfield, MA 02048
Phone: +1 508 261 5312 Phone: +1 508 261 5312
E-mail: dan@dma.isg.mot.com EMail: dan@dma.isg.mot.com
Andrew Smith (editor) Andrew Smith (editor)
Allegro Networks Harbour Networks
6399 San Ignacio Ave. Jiuling Building
San Jose, CA 95119 21 North Xisanhuan Ave.
FAX: +1 415 345 1827 Beijing, 100089
E-mail: andrew@allegronetworks.com PRC
Table of Contents Fax: +1 415 345 1827
EMail: ah_smith@acm.org
1 Introduction .................................................... 2 Full Copyright Statement
2 Glossary ........................................................ 4
3 Conceptual Model ................................................ 6
3.1 Components of a Diffserv Router ............................... 6
3.1.1 Datapath .................................................... 6
3.1.2 Configuration and Management Interface ...................... 8
3.1.3 Optional QoS Agent Module ................................... 8
3.2 Diffserv Functions at Ingress and Egress ...................... 9
3.3 Shaping and Policing .......................................... 11
3.4 Hierarchical View of the Model ................................ 11
4 Classifiers ..................................................... 12
4.1 Definition .................................................... 12
4.1.1 Filters ..................................................... 13
4.1.2 Overlapping Filters ......................................... 14
4.2 Examples ...................................................... 15
4.2.1 Behaviour Aggregate (BA) Classifier ......................... 15
4.2.2 Multi-Field (MF) Classifier ................................. 15
4.2.3 Free-form Classifier ........................................ 16
4.2.4 Other Possible Classifiers .................................. 16
5 Meters .......................................................... 17
5.1 Examples ...................................................... 18
5.1.1 Average Rate Meter .......................................... 18
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............ 19
5.1.3 Two-Parameter Token Bucket Meter ............................ 19
5.1.4 Multi-Stage Token Bucket Meter .............................. 20
5.1.5 Null Meter .................................................. 21
6 Action Elements ................................................. 21
6.1 DSCP Marker ................................................... 22
6.2 Absolute Dropper .............................................. 22
6.3 Multiplexor ................................................... 23
6.4 Counter ....................................................... 23
6.5 Null Action ................................................... 23
7 Queueing Elements ............................................... 23
7.1 Queueing Model ................................................ 24
7.1.1 FIFO Queue .................................................. 25
7.1.2 Scheduler ................................................... 26
7.1.3 Algorithmic Dropper ......................................... 28
7.2 Sharing load among traffic streams using queueing ............. 31
7.2.1 Load Sharing ................................................ 32
7.2.2 Traffic Priority ............................................ 33
8 Traffic Conditioning Blocks (TCBs) .............................. 33
8.1 TCB ........................................................... 34
8.1.1 Building blocks for Queueing ................................ 35
8.2 An Example TCB ................................................ 35
8.3 An Example TCB to Support Multiple Customers .................. 40
8.4 TCBs Supporting Microflow-based Services ...................... 42
8.5 Cascaded TCBs ................................................. 45
9 Security Considerations ......................................... 46
10 Acknowledgments ................................................ 46
11 References ..................................................... 46
12 Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 48
13 Authors' Addresses ............................................. 53
14. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 321 change blocks. 
1644 lines changed or deleted 1682 lines changed or added

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