draft-ietf-diffserv-model-02.txt   draft-ietf-diffserv-model-03.txt 
Internet Engineering Task Force Y. Bernet Internet Engineering Task Force Y. Bernet
Diffserv Working Group Microsoft Diffserv Working Group Microsoft
INTERNET-DRAFT A. Smith INTERNET-DRAFT A. Smith
Expires: September 2000 Extreme Networks Expires November 2000 Extreme Networks
S. Blake draft-ietf-diffserv-model-03.txt S. Blake
Ericsson Ericsson
D. Grossman D. Grossman
Motorola Motorola
A Conceptual Model for Diffserv Routers A Conceptual Model for Diffserv Routers
draft-ietf-diffserv-model-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with all
all provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
Internet-Drafts are working documents of the Internet Engineering its working groups. Note that other groups may also distribute working
Task Force (IETF), its areas, and its working groups. Note that documents as Internet-Drafts.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. 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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of the Diffserv working group. Comments This document is a product of the IETF's Differentiated Services Working
on this draft should be directed to the Diffserv mailing list Group. Comments should be addressed to WG's mailing list at
<diffserv@ietf.org>. 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 (2000). All Rights Reserved.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
DISCLAIMER - for reasons outside our control this version has been
rushed out with formatting errors and not checked by all authors.
This draft proposes a conceptual model of Differentiated Services This draft proposes a conceptual model of Differentiated Services
(Diffserv) routers for use in their management and configuration. (Diffserv) routers for use in their management and configuration. This
This model defines the general functional datapath elements model defines the general functional datapath elements (classifiers,
(classifiers, meters, markers, droppers, monitors, replicators, muxes, meters, markers, droppers, monitors, multiplexors, queues), their
queues), their possible configuration parameters, and how they might possible configuration parameters, and how they might be interconnected
be interconnected to realize the range of classification, traffic to realize the range of classification, traffic conditioning, and per-
conditioning, and per-hop behavior (PHB) functionalities described in hop behavior (PHB) functionalities described in [DSARCH]. The model is
Bernet, et. al. Expires: September 2000 [page 1]
[DSARCH]. The model is intended to be abstract and capable of
representing the configuration parameters important to Diffserv
functionality for a variety of specific router implementations. It
is not intended as a guide to hardware implementation.
This model should serve as a rationale for the design of a Diffserv
MIB [DSMIB], as well for various configuration interfaces (such as
[PIB]). Since these documents are all evolving simultaneously there
are discrepancies between their current revisions; this should be
resolved in a future revision of this draft.
Table of Contents
1. Introduction ................................................. 3 intended to be abstract and capable of representing the configuration
2. Glossary .................................................... 4 parameters important to Diffserv functionality for a variety of specific
3. Conceptual Model ............................................. 6 router implementations. It is not intended as a guide to hardware
3.1 Elements of a Diffserv Router ............................. 6 implementation.
3.1.1 Datapath .............................................. 7
3.1.2 Configuration and Management Interface ................ 8
3.1.3 Optional RSVP Module .................................. 8
3.2 Hierarchical Model of Diffserv Components ................. 8
4. Classifiers .................................................. 10
4.1 Definition ................................................ 10
4.1.1 Filters ............................................... 11
4.1.2 Overlapping Filters ................................... 12
4.1.3 Filter Groups ......................................... 12
4.2 Examples .................................................. 12
4.2.1 Behavior Aggregate (BA) Classifier .................... 12
4.2.2 Multi-Field (MF) Classifier ........................... 13
4.2.3 IEEE802 MAC Address Classifier ........................ 13
4.2.4 Free-form Classifier .................................. 14
4.2.5 Other Possible Classifiers ............................ 14
4.3 MPLS ...................................................... 15
5. Meters ....................................................... 15
5.1 Definition ................................................ 15
5.2 Examples .................................................. 16
5.2.1 Average Rate Meter .................................... 16
5.2.2 Exponentially Weighted Moving Average (EWMA) Meter .... 17
5.2.3 Two-Parameter Token Bucket Meter ...................... 17
5.2.4 Multi-Stage Token Bucket Meter ........................ 18
5.2.5 Null Meter ............................................ 19
6. Action Elements .............................................. 19*
6.1 Marker .................................................... 19*
6.2 Dropper ................................................... 20*
6.3 Shaper .................................................... 20*
6.4 Replicating Element ....................................... 20*
6.5 Multiplexor ............................................... 20*
6.6 Monitor ................................................... 21*
6.7 Null Action ............................................... 21*
7. Queues ....................................................... 21
7.1 Queue Sets and Scheduling ................................. 21
7.2 Shaping ................................................... 23
Bernet, et. al. Expires: July 2000 [page 2] This model serves as the rationale for the design of an SNMP MIB [DSMIB]
8. Traffic Conditioning Blocks (TCBs) ........................... 23 and for other configuration interfaces (e.g. [DSPIB]) and more detailed
8.1 An Example TCB ............................................ 24 models (e.g. [QOSDEVMOD]): these should all be based upon and consistent
8.2 An Example TCB to Support Multiple Customers .............. 27 with this model.
8.3 TCBs Supporting Microflow-based Services .................. 28
8.4 Cascaded TCBs ............................................. 31
9. Open Issues .................................................. 31
10. Security Considerations ...................................... 31
11. Acknowledgments .............................................. 31
12. References ................................................... 32
Appendix A. Simple Token Bucket Definition ....................... 33
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 differing levels of which allow network service providers to offer different kinds of
network quality-of-service (QoS) to different customers and their network quality-of-service (QoS) to different customers and their
traffic streams. The premise of Diffserv networks is that routers traffic streams. The premise of Diffserv networks is that routers within
within the core of the network handle packets in different traffic the core of the network handle packets in different traffic streams by
streams by forwarding them using different per-hop behaviors (PHBs). forwarding them using different per-hop behaviors (PHBs). The PHB to be
The PHB to be applied is indicated by a Diffserv codepoint (DSCP) in applied is indicated by a Diffserv codepoint (DSCP) in the IP header of
the IP header of each packet [DSFIELD]. Note that this document each packet [DSFIELD]. Note that this document uses the terminology
uses the terminology defined in [DSARCH, DSTERMS] and in Sec. 2. defined in [DSARCH, DSTERMS] and in Section 2.
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) aggregated to one of a small number of behavior aggregates (BA) which
which are each forwarded using the same PHB at the router, thereby are each forwarded using the same PHB at the router, thereby simplifying
simplifying the processing and associated storage. In addition, the processing and associated storage. In addition, there is no
there is no signaling, other than what is carried in the DSCP of signaling, other than what is carried in the DSCP of each packet, and no
each packet, and no other related processing that is required in the other related processing that is required in the core of the Diffserv
core of the Diffserv network since QoS is invoked on a packet-by- network since QoS is invoked on a packet-by- packet basis.
packet basis.
The Diffserv architecture enables a variety of possible services The Diffserv architecture enables a variety of possible services which
which could be deployed in a network. These services are reflected could be deployed in a network. These services are reflected to
to customers at the edges of the Diffserv network in the form of a customers at the edges of the Diffserv network in the form of a Service
Service Level Specification (SLS) [DSTERMS]. The ability to provide Level Specification (SLS) [DSTERMS]. The ability to provide these
these services depends on the availability of cohesive management and services depends on the availability of cohesive management and
configuration tools that can be used to provision and monitor a set configuration tools that can be used to provision and monitor a set of
of Diffserv routers in a coordinated manner. To facilitate the Diffserv routers in a coordinated manner. To facilitate the development
development of such configuration and management tools it is helpful of such configuration and management tools it is helpful to define a
to define a conceptual model of a Diffserv router that abstracts conceptual model of a Diffserv router that abstracts away implementation
away implementation details of particular Diffserv routers from the details of particular Diffserv routers from the parameters of interest
parameters of interest for configuration and management. The purpose for configuration and management. The purpose of this draft is to define
of this draft is to define such a model. 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 This document is not intended in any way to constrain or to dictate the
the implementation alternatives of Diffserv routers. We expect that implementation alternatives of Diffserv routers. It is expected that
router vendors will demonstrate a great deal of variability in their router implementers will demonstrate a great deal of variability in
implementations. To the extent that vendors are able to model their their implementations. To the extent that implementers are able to model
their implementations using the abstractions described in this draft,
Bernet, et. al. Expires: September 2000 [page 3]
implementations using the abstractions described in this draft,
configuration and management tools will more readily be able to configuration and management tools will more readily be able to
configure and manage networks incorporating Diffserv routers of configure and manage networks incorporating Diffserv routers of assorted
various implementations. origins.
In Sec. 3 we start by describing the basic high-level functional
o Section 3 starts by describing the basic high-level functional
elements of a Diffserv router and then describe the various elements of a Diffserv router and then describe the various
components. We then focus on the Diffserv-specific components of components, then focussing on the Diffserv-specific components of
the router and describe a hierarchical management model for these. the router and a hierarchical management model for these
components.
In Sec. 4 we describe classification elements and in Sec. 5, we o Section 4 describes classification elements.
discuss the meter elements.
In Sec. 6 we discuss action elements. In Sec. 7 we discuss the o Section 5 discusses meter elements.
basic queueing elements and their functional behaviors (e.g.,
shaping).
In Sec. 8, we show how the basic classification, meter, action, and o Section 6 discusses action elements.
o Section 7 discusses the basic queueing elements and their
functional behaviors (e.g. shaping).
o Section 8 shows how the basic classification, meter, action and
queueing elements can be combined to build modules called Traffic queueing elements can be combined to build modules called Traffic
Conditioning Blocks (TCBs). Conditioning Blocks (TCBs).
In Sec. 9 we discuss open issues with this document and in Sec. 10 we o Section 9 discusses open issues with this document
discuss security concerns.
Appendix A discusses token bucket implementation details. o Section 10 discusses security concerns.
2. Glossary 2. Glossary
Some of the terms used in this draft are defined in [DSARCH] and in This memo uses terminology which is defined in [DSARCH] and in
[DSTERMS]. We define a few of them here again only to provide [DSTERMS]. Some of the terms defined there are defined again here in
additional detail. order to provide additional detail, along with some new terms specific
to this document.
Buffer An algorithm used to determine whether an arriving
management packet should be stored in a queue, or discarded. This
algorithm decision is usually a function of the instantaneous or
average queue occupancy, but also may be a function of
the aggregate queue occupancy in a queue set, or of
other parameters.
Classifier A functional datapath element which consists of filters Classifier A functional datapath element which consists of filters
which select packets based on the content of packet which select packets based on the content of packet
headers or other packet data, and/or on implicit or headers or other packet data, and/or on implicit or
derived attributes associated with the packet, and derived attributes associated with the packet, and
forwards the packet along a particular datapath within forwards the packet along a particular datapath within
the router. A classifier splits a single incoming the router. A classifier splits a single incoming
traffic stream into multiple outgoing ones. traffic stream into multiple outgoing ones.
Enqueueing The process of executing a buffer management algorithm Counter A functional datapath element which updates a packet
to determine whether an arriving packet should be counter and also an octet counter for every
stored in a queue. packet that passes through it. Used for collecting
statistics.
Filter A set of (wildcard/prefix/masked/range/exact)
conditions on the components of a packet's
Bernet, et. al. Expires: September 2000 [page 4] Filter A set of wildcard, prefix, masked, range and/or exact
match conditions on the components of a packet's
classification key. A filter is said to match only if classification key. A filter is said to match only if
each condition is satisfied. each condition is satisfied.
Replicating A functional datapath element which makes one or more
element copies of a packet and forwards them on distinct
datapaths; for example to a monitoring port.
Monitor A functional datapath element which updates an octet
and a packet counter for every packet which passes
through it. Used for collecting statistics.
Multiplexer A functional datapath element that merges multiple Multiplexer 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 does Non-work- A property of a scheduling algorithm such that it
conserving not necessarily service a packet if available at every conserving services packets no sooner than a scheduled departure
transmission opportunity. time, even if this means leaving packets in a FIFO
while the link is idle.
Queue A storage location for packets awaiting transmission or
processing by the next functional element in the data-
path. The queues represented in this model are
abstract elements that may be implemented by multiple
physical queues in series and/or in parallel in a
specific implementation. Note that we assume that a
queue is serviced such as to preserve the required
ordering constraint for each Ordering Aggregate (OA)
it queues [DSTERMS]. This can be achieved by a FIFO
(first in, first out) service policy or by other means
(e.g., multiple FIFOs exclusively servicing particular
OAs).
Queue set A set of queues which are serviced by a scheduling Queueing A combination of functional datapath elements
algorithm and which may share a buffer management Block that modulates the transmission of packets belonging
algorithm. to a traffic streams and determines their
ordering, possibly storing them temporarily or
discarding them.
Scheduling An algorithm which determines which queue of a queue Scheduling An algorithm which determines which queue of a set
algorithm set to service next. This may be based on the relative algorithm of qyeyes to service next. This may be based on the
priority of the queues, or on a weighted fair bandwidth relative priority of the queues, on a weighted fair
sharing policy, or some other policy. A scheduling bandwidth sharing policy or some other policy. Such
algorithm may be either work-conserving or non-work- an algorithm may be either work-conserving or non-
conserving. work-conserving.
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 traffic profile. to cause it to conform to some defined traffic profile.
Shaping can be implemented using a queue serviced by a Shaping can be implemented using a queue serviced by a
non-work conserving scheduling algorithm. 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 other functional datapath entities interconnected in Conditioning other functional datapath entities 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
input and one output and a set of control parameters.
Bernet, et. al. Expires: September 2000 [page 5] Work- A property of a scheduling algorithm such that it
A TCB can be thought of as an entity with at least one conserving servicess a packet, if one is available, at every
input and output and a set of control parameters. transmission opportunity."
Work A property of a scheduling algorithm such that it
conserving services a packet if available at every transmission
opportunity.
3. Conceptual Model 3. Conceptual Model
In this section we introduce a block diagram of a Diffserv router and This section introduces a block diagram of a Diffserv router and
describe the various components illustrated. Note that a Diffserv describes the various components illustrated. Note that a Diffserv core
core router is assumed to include only a subset of these components: router is assumed to include only a subset of these components: the
the model we present here is intended to cover the case of both model presented here is intended to cover the case of both Diffserv edge
Diffserv edge and core routers. and core routers.
3.1 Elements of a Diffserv Router 3.1. Elements of a Diffserv Router
The conceptual model we define includes abstract definitions for the The conceptual model includes abstract definitions for the following:
following:
o The basic traffic classification components. o Traffic Classification elements.
o The basic traffic conditioning components. o Metering functions.
o Certain combinations of traffic classification and conditioning o Traffic Conditioning (TC) actions of Marking, Absolute Dropping,
components. Counting and Multiplexing.
o Queueing components. o Queueing elements, including capabilities of algorithmic
dropping.
The components and combinations of components described in this o Certain combinations of traffic classification, traffic
document form building blocks that need to be manageable by Diffserv conditioning and queueing elements.
configuration and management tools. One of the goals of this
document is to show how a model of a Diffserv device can be built The components and combinations of components described in this document
using these component blocks. This model is in the form of a form building blocks that need to be manageable by Diffserv
connected directed acyclic graph (DAG) of functional datapath configuration and management tools. One of the goals of this document is
elements that describes the traffic conditioning and queueing to show how a model of a Diffserv device can be built using these
behaviors that any particular packet will experience when forwarded component blocks. This model is in the form of a connected directed
to the Diffserv router. acyclic graph (DAG) of functional datapath elements that describes the
traffic conditioning and queueing behaviors that any particular packet
will experience when forwarded to the Diffserv router.
The following diagram illustrates the major functional blocks of a The following diagram illustrates the major functional blocks of a
Diffserv router: Diffserv router:
Bernet, et. al. Expires: September 2000 [page 6] 3.1.1. Datapath
An ingress interface, routing core and egress interface are illustrated
at the center of the diagram. In actual router implementations, there
may be an arbitrary number of ingress and 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. The actual queueing delay and packet loss
+---------------+ +---------------+
| Diffserv | | Diffserv |
Mgmt | configuration | Mgmt | configuration |
<----+-->| & management |------------------+ <----+-->| & management |------------------+
SNMP,| | interface | | SNMP,| | interface | |
COPS | +---------------+ | COPS | +---------------+ |
etc. | | | etc. | | |
| | | | | |
| v v | v v
| +-------------+ +---------+ +-------------+ | +-------------+ +-------------+
data | | ingress i/f | | | | egress i/f | | | ingress i/f | +---------+ | egress i/f |
-------->| class., |-->| routing |-->| class., |----> --------->| classify, |-->| routing |-->| classify, |---->
| | TC, | | core | | TC, | data | | meter, | | core | | meter |data out
| | queueing | | | | queueing | in | | action, | +---------+ | action, |
| +-------------+ +---------+ +-------------+ | | queueing | | queueing |
| +-------------+ +-------------+
| ^ ^ | ^ ^
| | | | | |
| | | | | |
| +------------+ | | +------------+ |
+-->| 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 Figure 1: Diffserv Router Major Functional Blocks
3.1.1 Datapath behavior of a specific router's switching fabric/backplane is not
modeled by the routing core; these should be modeled using the
An ingress interface, routing core, and egress interface are functional elements described later. The routing core should be thought
illustrated at the center of the diagram. In actual router of as an infinite bandwidth, zero- delay backplane connecting ingress
implementations, there may be an arbitrary number of ingress and and egress interfaces.
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. 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 elements described later. The
routing core should be thought of as an infinite bandwidth, zero-
delay backplane connecting ingress and egress interfaces.
The components of interest on the ingress/egress interfaces are the The components of interest on the ingress/egress interfaces are the
traffic classifiers, traffic conditioning (TC) components, and the traffic classifiers, traffic conditioning (TC) components, and the
queueing components that support Diffserv traffic conditioning and queueing components that support Diffserv traffic conditioning and per-
per-hop behaviors [DSARCH]. These are the fundamental components hop behaviors [DSARCH]. These are the fundamental components comprising
comprising a Diffserv router and will be the focal point of our a Diffserv router and will be the focal point of our conceptual model.
conceptual model.
Bernet, et. al. Expires: September 2000 [page 7] 3.1.2. Configuration and Management Interface
3.1.2 Configuration and Management Interface Diffserv operating parameters are monitored and provisioned through this
interface. Monitored parameters include statistics regarding traffic
carried at various Diffserv service levels. These statistics may be
important for accounting purposes and/or for tracking compliance to
Traffic Conditioning Specifications (TCSs) [DSTERMS] negotiated with
Diffserv operating parameters are monitored and provisioned through customers. Provisioned parameters are primarily classification rules, TC
this interface. Monitored parameters include statistics regarding and PHB configuration parameters. The network administrator interacts
traffic carried at various Diffserv service levels. These statistics with the Diffserv configuration and management interface via one or more
may be important for accounting purposes and/or for tracking management protocols, such as SNMP or COPS, or through other router
compliance to traffic conditioning specifications (TCSs) [DSTERMS] configuration tools such as serial terminal or telnet consoles.
negotiated with customers. Provisioned parameters are primarily
classification rules, TC and PHB configuration parameters. The
network administrator interacts with the Diffserv configuration and
management interface via one or more management protocols, such as
SNMP or COPS, or through other router configuration tools such as
serial terminal or telnet consoles.
Specific policy objectives are presumed to be installed by or Specific policy objectives are presumed to be installed by or retrieved
retrieved from policy management mechanisms. However, diffserv from policy management mechanisms. However, diffserv routers are subject
routers are subject to implementation decisions which form a meta- to implementation decisions which form a meta- policy that scopes the
policy that scopes the kinds of policies which can be created. kinds of policies which can be created.
3.1.3 Optional RSVP 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]. The example per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the
discussed here uses the RSVP protocol. Snooping of RSVP messages may RSVP protocol. Snooping of RSVP messages may be used, for example, to
be used, for example, to learn how to classify traffic without learn how to classify traffic without actually participating as a RSVP
actually participating as a RSVP protocol peer. Diffserv routers may protocol peer. Diffserv routers may reject or admit RSVP reservation
reject or admit RSVP reservation requests to provide a means of requests to provide a means of admission control to Diffserv-based
admission control to Diffserv-based services or they may use these services or they may use these requests to trigger provisioning changes
requests to trigger provisioning changes for a flow-aggregation in for a flow-aggregation in the Diffserv network. A flow-aggregation in
the Diffserv network. A flow-aggregation in this context might be this context might be equivalent to a Diffserv BA or it may be more
equivalent to a Diffserv BA or it may be more fine-grained, relying fine-grained, relying on a MF classifier [DSARCH]. Note that the
on a MF classifier [DSARCH]. Note that the conceptual model of such conceptual model of such a router implements the Integrated Services
a router starts to look the same as a Integrated Services (intserv) Model as described in [INTSERV], applying the control plane controls to
router in its component makeup [E2E]. the data classified and conditioned in the data plane, as desribed in
[E2E].
Note that a RSVP component of a Diffserv router, if present, might Note that a QoS Agent component of a Diffserv router, if present, might
be active only in the control plane and not in the data plane. In be active only in the control plane and not in the data plane. In this
this scenario, RSVP is used strictly as a signaling protocol. The scenario, RSVP could be used merely to signal reservation state without
data plane of such a Diffserv router can still act purely on Diffserv installing any actual reservations in the data plane of the Diffserv
DSCPs and PHBs in handling data traffic. router: the data plane could still act purely on Diffserv DSCPs and
provide PHBs for handling data traffic without the normal per-microflow
handling expected to support some Intserv services.
3.2 Hierarchical Model of Diffserv Components 3.2. Hierarchical Model of Diffserv Components
We focus on the Diffserv specific functional components of the This document focuses on the Diffserv-specific components of the router:
router: the classification, traffic conditioning, and queueing classification, traffic conditioning and queueing functions. Figure 2
functionality. The diagram below is based on the larger block shows a high-level view of ingress and egress interfaces of a router.
diagram shown above: The diagram illustrates two Diffserv router interfaces, each having an
ingress and an egress component. It shows classification, meter, action
and queueing elements which might be instantiated on each interface's
ingress and egress component. The TC functionality is implemented by a
combination of classification, action, meter and queueing elements.
In principle, if one were to construct a network entirely out of two-
port routers (in appropriate places connected by LANs or similar media),
then it would be necessary for each router to perform four QoS control
functions in the datapath on traffic in each direction:
- Classify each message according to some set of rules.
- If necessary, determine whether the data stream the message is part
of is within or outside its rate by metering the stream.
- Perform a set of resulting actions, including applying a drop
policy appropriate to the classification and queue in question and
perhaps additionally marking the traffic with a Differentiated
Services Code Point (DSCP) as defined in [DSCP].
- Enqueue the traffic for output in the appropriate queue, which may
either shape the traffic or simply forward it with some minimum
rate or maximum latency.
If the network is now built out of N-port routers, the expected behavior
of the network should be identical. Therefore, this model must provide
for essentially the same set of functions on the ingress as on the
egress port of the router. Some interfaces will be "edge" interfaces and
some will be "interior" to the Differentiated Services domain. The one
point of difference between an ingress and an egress interface is that
Bernet, et. al. Expires: September 2000 [page 8]
Interface A Interface B Interface A Interface B
+-------------+ +---------+ +-------------+ +-------------+ +---------+ +-------------+
| ingress i/f | | | | egress i/f | | ingress i/f | | | | egress i/f |
| class., | | | | class., | | classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |---> --->| meter, |---->| |---->| meter, |--->
| action, | | | | action, | | action, | | | | action, |
| queueing | | | | queueing | | queueing | | | | queueing |
+-------------+ | routing | +-------------+ +-------------+ | routing | +-------------+
| core | | core |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| egress i/f | | | | ingress i/f | | egress i/f | | | | ingress i/f |
| class., | | | | class., | | classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<--- <---| meter, |<----| |<----| meter, |<---
| action, | | | | action, | | action, | | | | action, |
| queueing | +---------+ | queueing | | queueing | +---------+ | queueing |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 2. Traffic Conditioning and Queueing Elements Figure 2. Traffic Conditioning and Queueing Elements
This diagram illustrates two Diffserv router interfaces, each having all traffic on an egress interface is queued, while traffic on an
an ingress and an egress component. It shows classification, meter, ingress interface will typically be queued only for shaping purposes, if
action, and queueing elements which might be instantiated on each at all. Therefore, equivalent functional elements are modelled on both
interface's ingress and egress component. The TC functionality is the ingress and egress components of an interface.
implemented by a combination of classification, action, meter, and
queueing elements. We show equivalent functional elements on both
the ingress and egress components of an interface because we expect
an N-port router to display the same Diffserv capabilities as a
network of 2-port routers interconnected by LAN media [DSMIB]. Note
that it is not mandatory that each of these functional elements be
implemented on both ingress and egress components; it is dependent on
the service requirements on a particular interface on a particular
router. Further, we wish to point out that by showing these elements
on both ingress and egress components we do not mean to imply that
they must be implemented in this way in a specific router. For
example, a router may implement all shaping and PHB queueing on the
interface egress component, or may instead implement it only on the
ingress component. Further, the classification needed to map a
packet to an egress component queue (if present) need not be
implemented on the egress component but instead may be implemented on
the ingress component, with the packet passed through the routing
core with in-band control information to allow for egress queue
selection.
From a configuration and management perspective, the following Note that it is not mandatory that each of these functional elements be
implemented on both ingress and egress components; equally, the model
allows that multiple sets of these elements may be placed in series
and/or in parallel at ingress or at egress. The arrangement of elements
is dependent on the service requirements on a particular interface on a
particular router. By modelling these elements on both ingress and
egress components, 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 queueing on the interface egress component or may
instead implement it only on the ingress component. Furthermore, the
classification needed to map a packet to an egress component queue (if
present) need not be implemented on the egress component but instead may
be implemented on the ingress component, with the packet passed through
the routing core with in-band control information to allow for egress
queue selection.
>From a device-configuration and management perspective, the following
hierarchy exists: hierarchy exists:
At the top level, the network administrator manages interfaces. Each At the top level, the network administrator manages interfaces.
interface consists of an ingress component and an egress component. Each interface consists of an ingress component and an egress
Each component may contain classifier, action, meter, and queueing component. Each component may contain classifier, action, meter
elements. and queueing elements.
Bernet, et. al. Expires: September 2000 [page 9]
At the next level, the network administrator manages groups of At the next level, the network administrator manages groups of
functional elements interconnected in a DAG. These elements are functional elements interconnected in a DAG. These elements are
organized in self-contained Traffic Conditioning Blocks (TCBs) which organized in self-contained Traffic Conditioning Blocks (TCBs)
are used to implement some desired network policy (see Sec. 8). One which are used to implement some desired network policy (see
or more TCBs may be instantiated on each ingress or egress component, Section 8). One or more TCBs may be instantiated on each ingress or
may be connected in series, and/or may be connected in a egress component; they may be connected in series and/or in
parallel configuration on the multiple outputs of a classifier. parallel configurations on the multiple outputs of a classifier.
We define the TCB to optionally include classification and queueing The TCB is defined optionally to include classification and
elements so as to allow for rich functionality. A TCB can be thought queueing elements so as to allow for flexible functionality. A TCB
of as a "black box" with a single input and a single output (on the can be thought of as a "black box" with one input and one output in
main data path). TCBs can be constructed out of a DAG of other TCBs, the data path. Each interface (ingress or egress) may have
recursively. We do not assume the same TCB configuration on every different TCB configurations.
interface (ingress or egress).
At the lowest level are individual functional elements, each with At the lowest level are individual functional elements, each with
their own configuration parameters and management counters and flags. their own configuration parameters and management counters and
flags.
4. Classifiers 4. Classifiers
4.1 Definition 4.1. Definition
Classification is performed by a classifier element. Classifiers are Classification is performed by a classifier element. Classifiers are 1:N
1:N (fan-out) devices: they take a single traffic stream as input and (fan-out) devices: they take a single traffic stream as input and
generate N logically separate traffic streams as output. Classifiers generate N logically separate traffic streams as output. Classifiers are
are parameterized by filters and output streams. Packets from the parameterized by filters and output streams. Packets from the input
input stream are sorted into various output streams by filters which stream are sorted into various output streams by filters which match the
match the contents of the packet or possibly match other attributes contents of the packet or possibly match other attributes associated
associated with the packet. Various types of classifiers are with the packet. Various types of classifiers are described in the
described in the following sections. following sections.
We use the following diagram to illustrate a classifier, where the We use the following diagram to illustrate a classifier, where the
outputs connect to succeeding functional elements: outputs connect to succeeding functional elements:
unclassified classified unclassified classified
traffic traffic traffic traffic
+------------+ +------------+
| |--> match Filter1 --> output A | |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> output B ------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> output C | |--> no match --> OutputC
+------------+ +------------+
Figure 3. An Example Classifier Figure 3. An Example Classifier
Note that we allow a mux (see Sec. 6.5) before the classifier to Note that we allow a multiplexor (see Section 6.5) before the classifier
allow input from multiple traffic streams. For example, if multiple to allow input from multiple traffic streams. For example, if multiple
ingress sub-interfaces feed through a single classifier then the ingress sub-interfaces feed through a single classifier then the
interface number can be considered by the classifier as a packet interface number can be considered by the classifier as a packet
attribute and be included in the packet's classification key. This attribute and be included in the packet's classification key. This
optimization may be important for scalability in the management optimization may be important for scalability in the management plane.
plane. Another possible packet attribute could be an integer Another example of a packet attribute could be an integer representing
representing the BGP community string associated with the packet's the BGP community string associated with the packet's best-matching
best-matching route. route.
The following classifier separates traffic into one of three output The following classifier separates traffic into one of three output
streams based on three filters: streams based on three filters:
Filter Matched Output Stream Filter Matched Output Stream
-------------- --------------- -------------- ---------------
Filter1 A Filter1 A
Filter2 B Filter2 B
Filter3 (no match) C Filter3 (no match) C
Where Filters1 and Filter2 are defined to be the following BA filters Where Filters1 and Filter2 are defined to be the following BA filters
([DSARCH], see Sec. 4.2.1 ): ([DSARCH], Section 4.2.1 ):
Filter DSCP Filter DSCP
------ ------ ------ ------
1 101010 1 101010
2 111111 2 111111
3 ****** (wildcard) 3 ****** (wildcard)
4.1.1 Filters 4.1.1. Filters
A filter consists of a set of conditions on the component values of A filter consists of a set of conditions on the component values of a
a packet's classification key (the header values, contents, and packet's classification key (the header values, contents, and attributes
attributes relevant for classification). In the BA classifier relevant for classification). In the BA classifier example above, the
example above, the classification key consists of one packet header classification key consists of one packet header field, the DSCP, and
field, the DSCP, and both Filter1 and Filter2 specify exact-match both Filter1 and Filter2 specify exact-match conditions on the value of
conditions on the value of the DSCP. Filter3 is a wildcard default the DSCP. Filter3 is a wildcard default filter which matches every
filter which matches every packet, but which is only selected in the packet, but which is only selected in the event that no other more
event that no other more specific filter matches. 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 exact, prefix, range, masked, and wildcard matches. Note that ranges can
can be represented (with less efficiency) as a set of prefixes and be represented (with less efficiency) as a set of prefixes and that
that prefix matches are just a special case of both masked and range prefix matches are just a special case of both masked and range matches.
matches.
In the case of a MF classifier [DSARCH], the classification key In the case of a MF classifier [DSARCH], the classification key consists
consists of a number of packet header fields. The filter may of a number of packet header fields. The filter may specify a different
specify a different condition for each key component, as illustrated condition for each key component, as illustrated in the example below
in the example below for a IPv4/TCP classifier: for a IPv4/TCP classifier:
Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort Filter IP Src Addr IP 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 In this example, the fourth octet of the destination IPv4 address and
and the source TCP port are wildcard or "don't cares". the source TCP port are wildcard or "don't cares".
MF filtering of fragmented packets is impossible. MTU size discovery MF classification of fragmented packets is impossible if the filter uses
is therefore prerequisite for proper operation of a diffserv network. transport-layer port numbers e.g. TCP port numbers. MTU-discovery is
therefore a prerequisite for proper operation of a 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:
Filter5: Filter6: Filter5:
Type: Masked-DSCP Type: Masked-DSCP Type: Masked-DSCP
Value: 111000 Value: 000111 (binary) Value: 111000
Mask: 111000 Mask: 000111 (binary) Mask: 111000
A packet containing DSCP = 111111 cannot be uniquely classified by
this pair of filters and so a precedence must be established between
Filter5 and Filter6 in order to break the tie. This precedence must
be established either (a) by a manager which knows that the router
can accomplish this particular ordering; e.g., by means of reported
capabilities or (b) by the router along with a mechanism to report
to a manager which precedence is being used. These ordering
mechanisms must be supported by the configuration and management
protocols although further discussion of this is outside the scope of
this document.
An unambiguous classifier requires that every possible classification
key match at least one filter (including the wildcard default), and
that any ambiguity between overlapping filters be resolved by
precedence.
4.1.3 Filter Groups
Filters may be logically combined. For example, consider the Filter6:
following DestMacAddress filter: Type: Masked-DSCP
Value: 000111 (binary)
Mask: 000111 (binary)
Filter7: A packet containing DSCP = 111111 cannot be uniquely classified by this
Type: DestMacAddress pair of filters and so a precedence must be established between Filter5
Value: 01-02-03-04-05-06 and Filter6 in order to break the tie. This precedence must be
Mask: FF-FF-FF-FF-FF-FF established either (a) by a manager which knows that the router can
accomplish this particular ordering e.g. by means of reported
capabilities, or (b) by the router along with a mechanism to report to a
manager which precedence is being used. These ordering mechanisms must
be supported by the configuration and management protocols although
further discussion of this is outside the scope of this document.
Classifier0 could then be declared as: As another example, one might want first to disallow certain
applications from using the network at all, or to classify some
individual traffic streams that are not Diffserv-marked. Traffic that is
not classified by those tests might then be inspected for a DSCP. The
word "then" implies sequence and this must be specified by means of
precedence.
Classifier0: An unambiguous classifier requires that every possible classification
Filter1 and Filter7: output A key match at least one filter (possibly the wildcard default) and that
Filter2 and Filter7: output B any ambiguity between overlapping filters be resolved by precedence.
Default (wildcard) filter: output C Therefore, the classifiers on any given interface must be "complete" and
will often include an "everything else" filter as the lowest precedence
element in order for the result of classification to be deterministic.
Note that this completeness is only required of the first classifier
that incoming traffic will meet as it enters an interface - subsequent
classifiers on an interface only need to handle the traffic that it is
known that they will receive.
4.2 Examples 4.2. Examples
4.2.1 Behaviour Aggregate (BA) Classifier 4.2.1. Behaviour Aggregate (BA) Classifier
The simplest Diffserv classifier is a behavior aggregate (BA) The simplest Diffserv classifier is a behavior aggregate (BA) classifier
classifier [DSARCH]. A BA classifier uses only the Diffserv [DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a
codepoint (DSCP) in a packet's IP header to determine the logical packet's IP header to determine the logical output stream to which the
output stream to which the packet should be directed. We allow only packet should be directed. We allow only an exact-match condition on
an exact-match condition on this field because the assigned DSCP this field because the assigned DSCP values have no structure, and
values have no structure, and therefore no subset of DSCP bits are therefore no subset of DSCP bits are significant.
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
header (including the DSCP). A common type of MF classifier is a 6- (possibly including the DSCP). A common type of MF classifier is a 6-
tuple classifier that classifies based on six IP header fields tuple classifier that classifies based on six fields from the IP and TCP
(destination address, source address, IP protocol, source port, or UDP headers (destination address, source address, IP protocol, source
destination port, and DSCP). MF classifiers may classify on other port, destination port, and DSCP). MF classifiers may classify on other
fields such as MAC addresses, VLAN tags, link-layer traffic class fields such as MAC addresses, VLAN tags, link-layer traffic class fields
fields or other higher-layer protocol 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 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 IEEE802 MAC Address Classifier 4.2.3. Free-form Classifier
A MacAddress filter is parameterized by a 6-byte {value, mask} pair
for either source or destination MAC address. For example, the
following classifier sends packets matching either DA =
01-02-03-04-05-06 or SA = 00-E0-2B-XX-XX-XX to output A:
Classifier1:
Filter10: output A
Filter11: output A
Default: output B
Filter10:
Type: DestMacAddress
Value: 01-02-03-04-05-06 (hex)
Mask: FF-FF-FF-FF-FF-FF (hex)
Filter11:
Type: SrcMacAddress
DestValue: 00-E0-2B-00-00-00 (hex)
DestMask: FF-FF-FF-00-00-00 (hex)
4.2.4 Free-form Classifier
A Free-form classifier is made up of a set of user definable A Free-form classifier is made up of a set of user definable arbitrary
arbitrary filters each made up of {bit-field size, offset (from head filters each made up of {bit-field size, offset (from head of packet),
of packet), mask}: mask}:
Classifier2: Classifier2:
Filter12: output A Filter12: OutputA
Filter13: output B Filter13: OutputB
Default: output C 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)
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.5 Other Possible Classifiers 4.2.4. Other Possible Classifiers
Classification may also be performed based on information at the
datalink layer below IP (e.g. VLAN or datalink-layer priority) or
perhaps on the ingress or egress IP, logical or physical interface
identifier. (e.g. the incoming channel number on a channelized
interface). A classifier that filters based on IEEE 802.1p Priority and
on 802.1Q VLAN-ID might be represented as:
Classifier3: Classifier3:
Filter14: output A Filter14 AND Filter15: OutputA
Filter15: output B Default: OutputB
Default: output C
Filter14: Filter14: -- priority 4 or 5
Type: IEEEPriority Type: Ieee8021pPriority
Value: 100 (binary) Value: 100 (binary)
Mask: 101 (binary) Mask: 110 (binary)
Filter15:
Type: IEEEVLAN Filter15: -- VLAN 2304
Type: Ieee8021QVlan
Value: 100100000000 (binary) Value: 100100000000 (binary)
Mask: 111111111111 (binary) Mask: 111111111111 (binary)
Classification may be performed based on implicit information Such classifiers may be subject of other standards or may be enterprise-
associated with a packet (e.g. the incoming channel number on a specific but are not discussed further here.
channelized interface) or on information derived from a different
non-Diffserv classification operation (e.g. the outgoing interface
determined by the route lookup operation). Other vendor-specific
filter formats are possible. We do not discuss these further here.
4.3 MPLS
It is possible for an MPLS label-switched router (LSR) to function as
a Diffserv router [MPLSDS]. The interaction between MPLS and Diffserv
is not discussed further in this document.
5. Meters 5. Meters
5.1 Definition Metering is is defined in [DSARCH]. Diffserv network providers may
choose to offer services to customers based on a temporal (i.e., rate)
profile within which the customer submits traffic for the service. In
Metering is the function of monitoring the arrival times of packets this event, a meter might be used to trigger real-time traffic
of a traffic stream and determining the level of conformance of each conditioning actions (e.g., marking) by routing a non-conforming packet
packet to a pre-established traffic profile. Diffserv network through an appropriate next-stage action element. Alternatively, it
providers may choose to offer services to customers based on a might also be used for out-of-band management functions like statistics
temporal (i.e., rate) profile within which the customer submits monitoring for billing applications.
traffic for the service. In this event, a meter might be used to
trigger real-time traffic conditioning actions (e.g., marking) by
routing a non-conforming packet through an appropriate next-stage
action element. Alternatively, it might also be used for out-of-band
management functions like statistics monitoring for billing
applications.
Meters are logically 1:N (fan-out) devices (although a mux can be Meters are logically 1:N (fan-out) devices (although a multiplexor can
used in front of a meter). Meters are parameterized by a temporal be used in front of a meter). Meters are parameterized by a temporal
profile and by conformance levels, each of which is associated with profile and by conformance levels, each of which is associated with a
a meter's output. Each output can be connected to another functional meter's output. Each output can be connected to another functional
element. element.
Note that this model of a meter differs from that described in Note that this model of a meter differs slightly from that described in
[DSARCH]. In that description the meter is not a datapath element [DSARCH]. In that description the meter is not a datapath element but is
but is instead used to monitor the traffic stream and send control instead used to monitor the traffic stream and send control signals to
signals to action elements to dynamically modulate their behavior action elements to dynamically modulate their behavior based on the
based on the conformance of the packet. We find the description here conformance of the packet.
more powerful.
We use the following diagram to illustrate a meter with 3 levels of The following diagram illustrates a meter with 3 levels of conformance:
conformance:
unmetered metered unmetered metered
traffic traffic traffic traffic
+---------+ +---------+
| |--------> conformanceA | |--------> conformanceA
--------->| meter |--------> conformanceB --------->| meter |--------> conformanceB
| |--------> conformanceC | |--------> conformanceC
+---------+ +---------+
Figure 4. An Example Meter Figure 4. A Generic Meter
In some Diffserv examples, three levels of conformance are discussed In some Diffserv examples, three levels of conformance are discussed in
in terms of colors, with green representing conforming, yellow terms of colors, with green representing conforming, yellow representing
representing partially conforming, and red representing non- partially conforming and red representing non-conforming [AF-PHB]. These
conforming [AF-PHB]. These different conformance levels are used to different conformance levels may be used to trigger different queueing,
trigger different buffer management actions. Other example meters marking or dropping treatment later on in the processing. Other example
use a binary notion of conformance; in the general case N levels of meters use a binary notion of conformance; in the general case N levels
conformance can be supported. In general there is no constraint on of conformance can be supported. In general there is no constraint on
the type of functional element following a meter output, but care the type of functional element following a meter output, but care must
must be taken not to inadvertently configure a datapath that results be taken not to inadvertently configure a datapath that results in
in packet reordering within an OA. packet reordering within an OA.
5.2 Examples 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
thresholds and produces some number (two or more) potential results: a
given packet is said to "conform" to the meter if, at the time that the
packet is being looked at, the stream appears to be within the meter's
limit rate.
The following is a non-exhaustive list of possible meters. The concept of conformance to a meter bears comment. The concept applied
in several rate-control architectures, including ATM, Frame Relay,
Integrated Services and Differentiated Services, is variously described
as a "leaky bucket" or a "token bucket".
5.2.1 Average Rate Meter A leaky bucket algorithm is primarily used for traffic shaping (handled
under Queues and Schedulers in this model): traffic theoretically
departs from a device at a rate of one bit every so many time units but,
in fact, departs in multi-bit units (packets) at a rate approximating
that. It is also possible to build multi-rate leaky buckets, in which
traffic departs from the switch at varying rates depending on recent
activity or inactivity.
An example of a very simple meter is an average rate meter. This A simple token bucket is usually used in a Meter to measure the behavior
type of meter measures the average rate at which packets are of a peer's leaky bucket, for verification purposes. It is, by
submitted to it over a specified averaging time. definition, a relationship between some defined burst_size, rate and
interval:
interval = burst_size/rate
or
rate = burst_size/interval
Multi-rate token buckets (token buckets with both a peak and a mean rate
and sometimes more rates) are commonly used. In this case, the burst
size for the baseline traffic is conventionally referred to as the
"committed burst" and the time interval is as specified by
interval = committed_burst/mean_rate
but additional burst sizes (each an increment over its predecessor) are
defined, which are conventionally referred to as "excess" burst sizes.
The peak rate therefore equals the sum of the burst sizes for any given
interval.
A data stream is said to conform to a simple token bucket if the switch
receives at most the "burst_size" of data in any time interval of length
"interval". In the multi-rate case, the traffic is said to conform at a
given level to the token bucket at if its rate does not exceed the sum
of the relevant burst sizes in any given interval. Received traffic that
arrives pre-classified as one of the "excess" rates (e.g. AF12 or AF13
traffic for a device implementing the AF1x PHB) is only compared to the
relevant excess buckets.
<ed: the following paragraphs may need fixing when we can all agree on a
stricter vs. looser definition: for now we assume strict schedulers and
lenient meters.>
The fact that data is organized into variable length packets introduces
some uncertainty in this conformance decision. When used in a Scheduler,
a leaky bucket releases a packet only when all of its bits would have
been allowed: it does not borrow from future capacity. When used in a
Meter, a token bucket accepts a packet if any of its bits would have
been accepted and "borrows" any excess capacity required from that
allotted to equivalently classified traffic in a previous or subsequent
interval. Note that [SRTCM] and [TRTCM] insist on stricter behaviour
from a meter than the model here insists on.
Multiple classes of traffic, as identified by the classifier table, may
be presented to the same meter. Imagine, for example, that it is desired
to drop all traffic that uses any DSCP that has not been publicly
defined. A classifier entry might exist for each such DSCP, shunting it
to an "accepts everything" meter and dropping all traffic that conforms
to only that meter.
It is necessary to identify what is to be done with packets that conform
to the meter and with packets that do not. It is also necessary for the
meter to be arbitrarily extensible as some PHBs require the successive
application of an arbitrary number of meters. The approach taken in
this model is to have each meter indicate what action is to be taken for
conforming traffic and what meter is to be used for traffic which fails
to conform. With the definition of a special type of meter to which all
traffic conforms, this has the necessary flexibility.
Note that this definition of a simple token bucket meter requires that
the minimal bucket size be at least the MTU of the incoming link and it
should also be initialised with sufficient tokens to allow for at least
one MTU-sized packet to conform if it arrives at time zero.
5.1. Examples
The following are some examples of possible meters.
5.1.1. Average Rate Meter
An example of a very simple meter is an average rate meter. This type of
meter measures the average rate at which packets are 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
Profile1: output A Profile: Profile1
NonConforming: output B ConformingOutput: Queue1
NonConformingOutput: Counter1
Profile1: Profile1:
Type: AverageRate Type: AverageRate
AverageRate: 120 KBps AverageRate: 120 kbps
Delta: 1.0 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 of packets arriving between count that indicates the total number of packets arriving between time T
time T (now) and time T - 1.0 msecs. So long as an arriving packet (now) and time T - 100 msecs. So long as an arriving packet does not
does not push the count over 120 bytes, the packet would be deemed push the count over 12 kbits in the last 100 msec then the packet would
conforming. Any packet that pushes the count over 120 would be be deemed conforming. Any packet that pushes the count over 12 kbits
deemed non-conforming. Thus, this meter deems packets to correspond would be deemed non-conforming. Thus, this meter deems packets to
to one of two conformance levels: conforming or non-conforming. correspond to one of two conformance levels: conforming or non-
conforming and sends them on for the appropriate subsequent treatment.
5.2.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 is
essentially a simple IIR low-pass filter. rate(t) measures the essentially a simple IIR low-pass filter. "rate(t)" measures the number
number of incoming bytes in a small fixed sampling interval, Delta. of incoming bytes in a small fixed sampling interval, Delta. Any packet
Any packet that arrives and pushes the average rate over a predefined that arrives and pushes the average rate over a predefined rate
rate AverageRate is deemed non-conforming. An EWMA meter profile AverageRate is deemed non-conforming. An EWMA meter profile might look
might look as follows: something like the following:
Meter2: Meter2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
Profile2: output A Profile: Profile2
NonConforming: output B ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Profile2: Profile2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
AverageRate: 25 KBps AverageRate: 25 kbps
Delta: 10.0 usec Delta: 10 usec
Gain: 1/16 Gain: 1/16
5.2.3 Two-Parameter Token Bucket Meter 5.1.3. Two-Parameter Token Bucket Meter
A more sophisticated meter might measure conformance to a token A more sophisticated meter might measure conformance to a token bucket
bucket (TB) profile. A TB profile generally has two parameters, an (TB) profile. A TB profile generally has two parameters, an average
average token rate, a burst size. TB meters compare the arrival token rate and a burst size. TB meters compare the arrival rate of
rate of packets to the average rate specified by the TB profile. packets to the average rate specified by the TB profile. Logically,
Logically, byte tokens accumulate in a bucket at the average rate, tokens accumulate in a bucket at the average rate, up to a maximum
up to a maximum credit which is the burst size. Packets of length credit which is the burst size. Packets of length L bytes are considered
L bytes are considered conforming if L tokens are available in the conforming if any tokens are available in the bucket at the time of
bucket at the time of packet arrival. Packets are allowed to packet arrival: up to L bytes may then be borrowed from future token
exceed the average rate in bursts up to the burst size. Packets allocations. Packets are allowed to exceed the average rate in bursts up
which arrive to find a bucket with insufficient tokens in it are to the burst size. Packets which arrive to find a bucket with no tokens
deemed non-conforming. A two-parameter TB meter has exactly two in it are deemed non-conforming. A two-parameter TB meter has exactly
possible conformance levels (conforming, non-conforming). TB two possible conformance levels (conforming, non-conforming). TB
implementation details are discussed in Appendix A. implementation details are discussed in Appendix A. Note that this is a
"lenient" meter that allows some borrowing, as discussed above.
A two-parameter RB meter profile might look as follows: A two-parameter TB meter might appear as follows:
Meter3: Meter3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
Profile3: output A Profile: Profile3
NonConforming: output B ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Profile3: Profile3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 KBps AverageRate: 200 kbps
BurstSize: 100 KB BurstSize: 100 kbytes
5.2.4 Multi-Stage Token Bucket Meter 5.1.4. Multi-Stage Token Bucket Meter
More complicated TB meters might define two burst sizes and three More complicated TB meters might define two burst sizes and three
conformance levels. Packets found to exceed the larger burst size conformance levels. Packets found to exceed the larger burst size are
are deemed non-conforming. Packets found to exceed the smaller deemed non-conforming. Packets found to exceed the smaller burst size
burst size are deemed partially conforming. Packets exceeding are deemed partially conforming. Packets exceeding neither are deemed
neither are deemed conforming. Token bucket meters designed for conforming. Token bucket meters designed for Diffserv networks are
Diffserv networks are described in more detail in [SRTCM, TRTCM, described in more detail in [SRTCM, TRTCM, GTC]; in some of these
GTC]; in some of these references three levels of conformance are references three levels of conformance are discussed in terms of colors,
discussed in terms of colors, with green representing conforming, with green representing conforming, yellow representing partially
yellow representing partially conforming and red representing non- conforming and red representing non- conforming. Often these multi-
conforming. Often these multi-conformance level meters can be conformance level meters can be implemented using an appropriate
implemented using an appropriate configuration of multiple two- configuration of multiple two- parameter TB meters.
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: MultiTokenBucket Type: TwoRateTokenBucket
Profile4: output A ProfileA: Profile4
Profile5: output B ConformingOutputA: Queue1
NonConforming: output C ProfileB: Profile5
ConformingOutputB: Marker1
NonConformingOutput: AbsoluteDropper1
Profile4: Profile4:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 KBps AverageRate: 100 kbps
BurstSize: 20 KB BurstSize: 20 kbytes
Profile5: Profile5:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 KBps AverageRate: 100 kbps
BurstSize: 100 KB BurstSize: 100 kbytes
5.2.5 Null Meter 5.1.5. Null Meter
A null meter has only one output: always conforming, and no A null meter has only one output: always conforming, and no associated
associated temporal profile. Such a meter is useful to define in the temporal profile. Such a meter is useful to define in the event that the
event that the configuration or management interface does not have configuration or management interface does not have the flexibility to
the flexibility to omit a meter in a datapath segment. omit a meter in a datapath segment.
Meter5:
Type: NullMeter
Output: Queue1
6. Action Elements 6. Action Elements
Classifiers and meters are fan-out elements which are generally used The classifiers and meters described up to this point are fan-out
to determine the appropriate action to apply to a packet. The set of elements which are generally used to determine the appropriate action to
possible actions include: apply to a packet. The set of possible actions include:
1) Marking - Marking
2) Dropping
2) Shaping
3) Replicating
4) Monitoring
The corresponding action elements are described in the following - Absolute Dropping
paragraphs.
Policing is a general term for the process of preventing a traffic - Multiplexing
stream from seizing more than its share of resources from a Diffserv
network. Each of the first three actions described above may be used
to police traffic. Markers do so by re-marking non-conforming
packets to a DSCP value that is entitled to fewer network resources.
Shapers and droppers do so by limiting the rate at which a particular
traffic stream is submitted to the network.
6.1 Marker - Counting
Markers are 1:1 elements which set the DSCP in an IP header (in - Null action - do nothing
the case of unlabeled packets). Markers may act on unmarked packets
(submitted with DSCP of zero) or may re-mark previously marked
packets. In particular, the model supports the application of
marking based on a preceding classifier match. The DSCP set in a
packet will determine its subsequent treatment in downstream nodes
of a network, and possible in subsequent processing stages within the
router (depending on configuration).
Markers are normally parameterized by a single parameter: the 6-bit The corresponding action elements are described in the following
DSCP to be marked in the packet header. sections.
ActionElement1: Diffserv nodes may apply shaping, policing and/or marking to traffic
Type: Marker streams that exceed the bounds of their TCS in order to prevent a
Mark: 010010 traffic stream from seizing more than its share of resources from a
Diffserv network. Shaping, sometimes considered as a TC action, is
treated as a part of the queueing module in this model, as is the use of
Algorithmic Dropping techniques - see section 7. Policing is modelled
as the combination of either a meter or a scheduler with either an
absolute dropper or an algorithmic dropper. These elements will discard
packets which exceed the TCS. Marking is performed by a marker, which
(in this context) alters the DSCP, and thus the PHB, of the packet to
give it a lower-grade treatment at subsequent Diffserv nodes.
In the case of a MPLS labeled packet, the marker is parameterized 6.1. Marker
by a 3-bit EXP value to be marked in the MPLS shim header.
6.2 Dropper Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an IP
header). Markers may also act on unmarked packets (e.g. those submitted
with DSCP of zero) or may re-mark previously marked packets. In
particular, the model supports the application of marking based on a
preceding classifier match. The mark set in a packet will determine its
subsequent treatment in downstream nodes of a network and possibly also
in subsequent processing stages within this router.
Droppers simply discard packets. There are no parameters for DSCP Markers for Diffserv are normally parameterized by a single
droppers. Because a dropper is a terminating point of the datapath, parameter: the 6-bit DSCP to be marked in the packet header.
it may be desirable to forward the packet through a monitor first
for instrumentation purposes.
Droppers are not the only elements than can cause a packet to be Marker1:
discarded. The other element is an enqueueing element (see Sec. Type: DSCPMarker
6.6). However, since the enqueueing element's behavior is closely Mark: 010010
tied the state of one or more queues, we choose to distinguish them
as separate functional elements.
6.3 Shaper 6.2. Absolute Dropper
Shapers are used to shape traffic streams to a certain temporal Absolute droppers simply discard packets. There are no parameters for
profile. For example, a shaper can be used to smooth traffic these droppers. Because this dropper is a terminating point of the
arriving in bursts. In [DSARCH] a shaper is described as a datapath and have no outputs, it is probably desirable to forward the
queueing element controlled by a meter which defines its temporal packet through a counter action first for instrumentation purposes.
profile. This model of a shaper differs substantially from typical
shaper implementations. Further, with the inclusion of queueing
elements in the model a separate shaping element becomes confusing.
Therefore, the function of a shaper is embedded in a queue and is
covered in Sec. 7.
6.4 Replicating Element AbsoluteDropper1:
Type: AbsoluteDropper
It is occasionally desirable to replicate traffic on one or more Absolute droppers are not the only elements than can cause a packet to
additional interfaces for data collection purposes. A replicating be discarded: another element is an Algorithmic Dropper element (see
element is a 1:N (fan-out) element. However, each and every packet Section 6.6). However, since this element's behavior is closely tied the
follows each output path simultaneously. A replicating element is
parameterized by the number of outputs it supports.
6.5 Mux state of one or more queues, we choose to distinguish it as a separate
functional element.
It is occasionally necessary to multiplex traffic streams into a 1:1 6.3. Multiplexer
or 1:N action element or classifier. A M:1 (fan-in) mux is a simple
logical device for merging traffic streams. It is parameterized by
its number of incoming ports.
6.6 Monitor It is occasionally necessary to multiplex traffic streams into a 1:1 or
1:N action element or classifier. A M:1 (fan-in) multiplexer is a
simple logical device for merging traffic streams. It is parameterized
by its number of incoming ports.
Mux1:
Type: Multiplexer
Output: Queue2
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 processed. The statistics that result might be used later for customer
customer billing, service verification, or network engineering billing, service verification, or network engineering purposes. Counters
purposes. Monitors are 1:1 functional elements which update an are 1:1 functional elements which update a counter by L and a packet
octet counter by L and a packet counter by 1 every time a L-byte counter by 1 every time a L-byte sized packet passes through them.
sized packet passes through it. Monitors can also be used to count Counters can be used to count packets about to be be dropped by a
packets on the verge of being dropped by a dropper. dropper or a queueing element.
6.7 Null Action Counter1:
Type: Counter
Output: Queue1
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 action on the packet. Such an element is useful to define in the event
event that the configuration or management interface does not have that the configuration or management interface does not have the
the flexibility to omit an action element in a datapath segment. flexibility to omit an action element in a datapath segment.
7. Queueing block Null1:
Type: Null
Output: Queue1
The queueing block modulates the transmission of packets belonging to 7. Queueing Blocks
the different traffic streams and determines their ordering, possibly
storing them temporarily or discarding them. Packets are usually
stored either because there is a resource constraint (e.g., available
bandwidth) which prevents immediate forwarding, or because the
queueing block is being used to alter the temporal properties of a
traffic stream (i.e., shaping). Packets are discarded either because
of buffering limitations, because a buffer threshold is exceeded
(including when shaping is performed), as a feedback control signal
to reactive control protocols such as TCP, because a meter exceeds a
configured rate (i.e., policing).
The queueing block in this model is a logical abstraction of a Queueing blocks modulate the transmission of packets belonging to the
queueing system, which is used to configure PHB-related parameters. different traffic streams and determine their ordering, possibly storing
There is no conformance to this model. The model can be used to them temporarily or discarding them. Packets are usually stored either
represent a broad variety of possible implementations. However, it because there is a resource constraint (e.g., available bandwidth) which
need not necessarily map one-to-one with physical queueing systems in prevents immediate forwarding, or because the queueing block is being
a specific router implementation. Implementors should map the
configurable parameters of the implementation's queueing systems to
these queueing block parameters as appropriate to achieve equivalent
behaviors.
7.1 Model used to alter the temporal properties of a traffic stream (i.e.
shaping). Packets are discarded either because of buffering limitations,
because a buffer threshold is exceeded (including when shaping is
performed), as a feedback control signal to reactive control protocols
such as TCP, because a meter exceeds a configured rate (i.e. policing).
Queuing is a function a which lends itself to innovation. It must be The queueing block in this model is a logical abstraction of a queueing
system, which is used to configure PHB-related parameters. There is no
conformance to this model. The model can be used to represent a broad
variety of possible implementations. However, it need not necessarily
map one-to-one with physical queueing systems in a specific router
implementation. Implementors should map the configurable parameters of
the implementation's queueing systems to these queueing block parameters
as appropriate to achieve equivalent behaviors.
7.1. Queueing Model
Queueing is a function a which lends itself to innovation. It must be
modelled to allow a broad range of possible implementations to be modelled 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 lattitude.
Queueing sytems, such as the queueing block defined in this model, Queueing sytems, such as the queueing block defined in this model,
perform three distinct, but related, functions: they store packets, perform three distinct, but related, functions: they store packets,
they modulate the departure of packets belonging to various traffic they modulate the departure of packets belonging to various traffic
streams and they selectively discard packets. This model decomposes streams and they selectively discard packets. This model decomposes the
the queueing block into the component elements that perform each of queueing block into the component elements that perform each of these
these functions. These elements which may be connected together functions. These elements which may be connected together either
either dynamically or statically to construct queueing blocks. A dynamically or statically to construct queueing blocks. A queueing
queuing block is thus composed of of one or more FIFO, one or more block is thus composed of of one or more FIFOs, one or more Schedulers
scheduler, and one or more discarder. See figure TBA for an example and zero or more Algorithmic Droppers.
of a queueing block.
Note that the term FIFO is overloaded (i.e., has more than one <ed: should this be *one* or more? There are valid cases that do
meaning). In common usage it is taken to mean, among other things, a not require a dropper but they are exceptional.>
data structure that permits items to be removed only in the order in
which they were inserted, and a service discipline which is non-
reordering.
7.1.1 FIFO Note that the term FIFO has multiple different common usages: it is
sometimes taken to mean, among other things, a data structure that
permits items to be removed only in the order in which they were
inserted or a service discipline which is non- reordering.
A FIFO element is a data structure which at any time may contain zero 7.1.1. FIFO
or more packets. It may have one or more threshold associated with
it. A FIFO has one or more inputs and exactly one output. It must
support an enqueue operation to add a packet to the tail of the
queue, and a dequeue operation to remove a packet from the head of
the queue. Packets must be dequeued in the order in which they were
enqueued. A FIFO has a depth, which indicates the number of packets
that it contains at a particular time; this is a traffic dependent
variable and not used to configure a FIFO.
Typically, the FIFO element of this model will be implemented as a In this model, a FIFO element is a data structure which at any time may
FIFO data structure. However, this does not preclude implementations contain zero or more packets. It may have one or more thresholds
which are not strictly FIFO, in that they also support operations associated with it. A FIFO has one or more inputs and exactly one
that remove or examine packets (e.g., for use by discarders) other output. It must support an enqueue operation to add a packet to the tail
than at the tail. However, such operations MUST NOT have the effect of the queue, and a dequeue operation to remove a packet from the head
of reordering packets belonging to the same microflow.
In an implementation, packets are presumably stored in one or more of the queue. Packets must be dequeued in the order in which they were
buffer. Buffers are allocated from one or more free buffer pool. If enqueued. A FIFO has a current depth, which indicates the number of
there are multiple instances of a FIFO, their packet buffers may or packets that it contains at a particular time. FIFOs in this model are
may not be allocated out of the same free buffer pool. Free buffer modelled without inherent limits on their depth - obviously this does
pools may also have one or more threshold associated with them, which not reflect the reality of implementations: FIFO size limits are
may affect discarding and/or scheduling. Otherwise, buffering modelled here by an algorithmic dropper associated with the FIFO,
mechanisms are implementation specific and not part of this model. typically at its input. It is quite likely that, every FIFO will be
preceded by an algorithmic dropper. One exception might be the case
where the packet stream has already been policed to a profile that can
never exceed the scheduler bandwidth available at the FIFO's output -
this would not need an algorithmic dropper at the input to the FIFO.
A FIFO might be represented using the following parameters: This representation of a FIFO allows for one common type of depth limit,
one that results from a FIFO supplied from a limited pool of buffers,
shared between multiple FIFOs.
FIFO1: <ed: should we instead model a FIFO as having a single input and
Type: FIFO use a "multiplexer" at its input if it needs to collect from
Input: QueuingBlock.input1 multiple input sources?>
Output: Discarder2
Threshold1: 3 packets
Another FIFO may be represented using the following parameters: Typically, the FIFO element of this model will be implemented as a FIFO
data structure. However, this does not preclude implementations which
are not strictly FIFO, in that they also support operations that remove
or examine packets (e.g., for use by discarders) other than at the head
or tail. However, such operations MUST NOT have the effect of reordering
packets belonging to the same microflow.
FIFO2: In an implementation, packets are presumably stored in one or more
buffers. Buffers are allocated from one or more free buffer pools. If
there are multiple instances of a FIFO, their packet buffers may or may
not be allocated out of the same free buffer pool. Free buffer pools may
also have one or more threshold associated with them, which may affect
discarding and/or scheduling. Other than this, buffering mechanisms are
implementation specific and not part of this model.
A FIFO might be represented using the following parameters:
Fifo1:
Type: FIFO Type: FIFO
Input: Discarder1
Output: Scheduler1 Output: Scheduler1
Threshold1: 3 packets
Threshold2: 1000 octets
Threshold3: 10 packets
Threshold4: 2000 octets
7.1.2 Scheduler Note that a FIFO must provide triggers and/or current state information
to other elements upstream and downstream from it: in particular, it is
likely that the current depth will need to be used by Algorithmic
Dropper elements placed before or after the FIFO. It will also likely
need to provide an implicit "I have packets for you" signal to
downstream Scheduler elements.
A scheduler is an element which gates the departure of each packet 7.1.2. Scheduler
that arrives at one of its inputs, based on a service discipline. It
has one or more input and exactly one output. Each input has an A scheduler is an element which gates the departure of each packet that
upstream element to which it is connected, and a set of parameters arrives at one of its inputs, based on a service discipline. It has one
that affects the scheduling of packets received at that input. or more input and exactly one output. Each input has an upstream element
to which it is connected, and a set of parameters 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 may take as its inputs static parameters (such as algorithm which might take any of the following as its input(s):
relative priority, and/or absolute token bucket parameters for
maximum or minimum rates) associated with each of the scheduler's
inputs; parameters (such as packet length or DSCP) associated with
the packet present at its input; absolute time and/or local state.
Possible service disciplines fall into a number of categories, a) static parameters such as relative priority associated with each of
including (but not limited to) first come, first served (FCFS), the scheduler's inputs.
strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR,
etc.), rate-limited strict priority, and rate-based. Service
disciplines can be further distinguished by whether they are work
conserving or non-work conserving. A work conserving service
discipline transmits a packet at every transmission opportunity if
one is available. A non-work conserving service discipline transmits
packets no sooner than a scheduled departure time, even if it means
leaving packets in a FIFO while the link is idle. Non-work
conserving schedulers can be used to shape traffic streams by
delaying packets that would be deemed non-conforming by some traffic
profile. The packet is delayed until such time as it would conform
to a meter using the same profile.
[DSARCH] defines PHBs without specifying required scheduling b) absolute token bucket parameters for maximum or minimum rates
algorithms. However, PHBs such as the class selctors [DSFIELD], associated with each of the scheduler's inputs.
EF [EF-PHB] and AF [AF-PHB] have descriptions or
configuration parameters which strongly suggest the sort of
scheduling discipline needed to implement them. This memo specifies
a minimal set of queue parameters to enable realization of these per-
hop behaviors. It does not attempt to specify an all-embracing
set of parameters to cover all possible implementation models.
The mimimum set includes a minimum service rate profile, a
service priority and a maximum service rate profile (the latter is
for use only with a non-work conserving service discipline). The
minimum service rate allows rate guarantees for each traffic stream
as required by EF and AF without specifying the details of how excess
bandwidth between these traffic streams is shared. Additional
parameters to control this behavior should be made available, but are
dependent on the particular scheduling algorithm implemented. The
service priority is used only after the MinRateProfiles of all inputs
have been satisfied in order to decide how to allocate any remaining
bandwidth. It could be used for the class selectors. For the EF PHB,
using a strict priority scheduling algorithm on some links, and assuming
that the aggregate EF rate has been appropriately bounded to avoid
starvation, for this scheduler the MinRateProfile would be reported
as zero and the MaxRateProfile reported as line rate. Setting the
service priority of each input to the scheduler to the same value
enables the scheduler to satisfy the minimum service rates for each
input, so long as the sum of all minimum service rates is less than
or equal to the line rate.
A non-work conserving scheduler might be represented using the c) parameters, such as packet length or DSCP, associated with the
following parameters: packet currently present at its input.
d) absolute time and/or local state.
Possible service disciplines fall into a number of categories, including
(but not limited to) first come, first served (FCFS), strict priority,
weighted fair bandwidth sharing (e.g., WFQ, WRR, etc.), rate-limited
strict priority and rate-based. Service disciplines can be further
distinguished by whether they are work-conserving or non-work-conserving
(see Glossary). Non-work-conserving schedulers can be used to shape
traffic streams to match some profile by delaying packets that might be
deemed non-conforming by some downstream node: 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.
However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF
[AF-PHB] have descriptions or configuration parameters which strongly
suggest the sort of scheduling discipline needed to implement them. This
memo discusses a minimal set of queue parameters to enable realization
of these per- hop behaviors. It does not attempt to specify an all-
embracing set of parameters to cover all possible implementation models.
A mimimal set includes:
a) a minimum service rate profile which allows rate guarantees for
each traffic stream as required by EF and AF without specifying the
details of how excess bandwidth between these traffic streams is
shared. Additional parameters to control this behavior should be
made available, but are dependent on the particular scheduling
algorithm implemented.
b) a service priority, used only after the minimum rate profiles of
all inputs have been satisfied, to decide how to allocate any
remaining bandwidth.
c) a maximum service rate profile, for use only with a non-work-
conserving service discipline.
For an implementation of the EF PHB using a strict priority scheduling
algorithm that assumes that the aggregate EF rate has been appropriately
bounded to avoid starvation, the minimum rate profile would be reported
as zero and the maximum service rate would be reported as line rate.
Such an implementation, with multiple priority classes, could also be
used for the Diffserv class selectors [DSFIELD].
Alternatively, setting the service priority values for each input to the
scheduler to the same value enables the scheduler to satisfy the minimum
service rates for each input, so long as the sum of all minimum service
rates is less than or equal to the line rate.
For example, a non-work-conserving scheduler, allocating spare bandwidth
equally between all its inputs, might be represented using the following
parameters:
Scheduler1: Scheduler1:
Type: Scheduler Type: Scheduler2Input
Input1: Discarder1 Input1:
MaxRateProfile: Profile1 MaxRateProfile: Profile1
MinRateProfile: Profile2 MinRateProfile: Profile2
Priority: None Priority: none
Input2: Discarder1 Input2:
MaxRateProfile: Profile3 MaxRateProfile: Profile3
MinRateProfile: Profile4 MinRateProfile: Profile4
Priority: None Priority: none
A work conserving scheduler might be represented using the A work-conserving scheduler might be represented using the following
following parameters: parameters:
Scheduler2: Scheduler2:
Type: Scheduler Type: Scheduler3Input
Input1: Scheduler1, Input1:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: Profile5 MinRateProfile: Profile5
Priority: 1 Priority: 1
Input2: FIFO2 Input2:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: Profile6 MinRateProfile: Profile6
Priority: 2 Priority: 2
Input3: FIFO3 Input3:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: None MinRateProfile: none
Priority: 3 Priority: 3
7.1.3 Discarder 7.1.3. Algorithmic Dropper
A discarder is an element which selectively discards packets that An Algorithmic Dropper is an element which selectively discards packets
arrive at its input, based on a discarding discipline. It has one that arrive at its input, based on a discarding algorithm. It has one
input and one output. In this model (but not necessarily in a real data input and one output. In this model (but not necessarily in a real
implementation), a packet enters the discarder at the input, and implementation), a packet enters the dropper at its input and either its
either its buffer is returned to a free buffer pool or it exits the buffer is returned to a free buffer pool or the packet exits the dropper
discarder at the output. at the output.
Alternatively, a discarder may invoke operations on a FIFO which Alternatively, an Algorithmic Dropper may invoke operations on a FIFO
selectively remove packets, then return those packets to the free which selectively removes a packet, then return its buffer to the free
buffer pool, based on a discarding discipline. In this case, the buffer pool, based on a discarding algorithm. In this case, the
discarder's operation is modelled as a side-effect on the FIFO upon operation is modelled as a side-effect on the FIFO upon which it
which it operates, rather than as having a discrete input and output. operates, rather than as having a discrete input and output. These two
treatments are equivalent and we choose the former here.
A discarder has a trigger that causes the discarder to make a The Algorithmic Dropper is modelled as having a single input. However,
decision whether or not to drop one (or possibly more than one) it is likely that packets which were classified differently by a
packet. The trigger may internal (i.e., the arrival of a packet at Classifier in this TCB will end up passing through the same dropper. The
the input to the discarder), or it may be external (i.e., resulting dropper's algorithm may need to apply different calculations based on
from one or more state change at another element, such as a FIFO characteristics of the incoming packet e.g. its DSCP. So there is a
depth exceeding a threshold or a scheduling event). A trigger may be need, in implementations of this model, to be able to relate information
a boolean combination of events (e.g., a FIFO depth exceeding a about which classifier element was matched by a packet from a Classifier
threshold OR a buffer pool depth falling below a threshold). to an Algorithmic Dropper. This is modelled here as a reverse pointer
from one of the drop probability calculation algorithms inside the
dropper to the classifier element that selects this algorithm.
The discarding discipline is an algorithm which makes a decision to There are many formulations of a model that could represent this
forward or discard a packet. It takes as its parameters some set of linkage, other than the one described above: one way would have been to
dynamic parameters (e.g., averaged or instantaneous FIFO depth) and have multiple "inputs" fed from the preceding elements, leading
some set of static parameters (e.g. thresholds) and possibly eventually to the classifier elements that matched the packet. Another
parameters associated with the packet (e.g. its PHB, as determined by formulation might have been for the Classifier to (logically) include
a classifier). It may also have internal state. RED, RIO, and drop- some sort of "classification identifier" along with the packet along its
on-threhold are examples of a discarding discipline. Tail dropping path, for use by any subsequent element. Yet another could have been to
and head dropping are effected by the location of the discarder include a classifier inside the dropper, in order for it to pick out the
relative to the FIFO.
Note that although a discarder may need to examine the DSCP or drop algorithm to be applied. All of these other approaches were deemed
possibly other fields in a packet, it may not modify them (i.e., to be more clumsy or less useful than the approach taken here.
it is not a marker).
A discarder might be represented using the following parameters: An Algorithmic Dropper, shown in Figure 5, has one or more triggers that
Discarder1: cause it to make a decision whether or not to drop one (or possibly more
Type: Discarder than one) packet. A trigger may be internal (the arrival of a packet at
Trigger: Internal the input to the dropper) or it may be external (resulting from one or
Input: QueuingBlock.input2 more state changes at another element, such as a FIFO depth exceeding a
Output: FIFO1 threshold or a scheduling event). It is likely that an instantaneous
FIFO depth will need to be smoothed over some averaging interval. Some
dropping algorithms may require several trigger inputs feeding back from
events elsewhere in the system e.g. smoothing functions that calculate
averages over more than one time interval. Smoothing functions are
outside the scope of this document and are not modelled here, we merely
indicate where they might be added in the model.
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).
The dropping algorithm makes a decision on whether to forward or to
discard a packet. It takes as its parameters some set of dynamic
parameters (e.g. averaged or instantaneous FIFO depth) and some set of
static parameters (e.g. thresholds) and possibly parameters associated
+------------------+ +-----------+
| +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
Figure 5. Algorithmic Dropper + Queue
with the packet (e.g. its PHB, as determined by a classifier, which will
determine on which of the droppers inputs trhe packet arrives). It may
also have internal state and is likely to keep counters regarding the
dropped packets (there is no appropriate place here to include a Counter
Action element).
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
location of the dropper relative to the FIFO.
Note that, although an Algorithmic Dropper may require knowledge of data
fields in a packet, as discovered by a Classifier in the same TCB, it
may not modify the packet (i.e. it is not a marker).
<ed: have rearranged this example so as not to include a Classifier
in the Dropper - this leads to needing either multiple inputs or an
implicit classification stage to separate the in- and out-of-
profile traffic. We have chosen the former representation.>
A dropper which uses a RIO algorithm might be represented using the
following parameters:
AlgorithmicDropper1:
Type: AlgorithmicDropper
Discipline: RIO Discipline: RIO
Trigger: Internal
Output: Fifo1
Parameters: InputA: (in profile)
In-MinTh: FIFO1.Threshold1 MinThresh: Fifo1.Depth > 20 kbyte
In-MaxTh: FIFO1.Threshold2 MaxThresh: Fifo1.Depth > 30 kbyte
Out-Minth: FIFO1.Threshold3
Out-Maxth: FIFO1.Threshold4
InClassification: AFx1_PHB
OutClassifcation: AFx2_PHB
W_q .002
Max_p .01
Another discarder might be represented using the following parameters: InputB: (out of profile)
Discarder2: MinThresh: Fifo1.Depth > 10 kbyte
Type: Discarder MaxThresh: Fifo1.Depth > 20 kbyte
Trigger:
Input: FIFO2 SampleWeight .002
Output: Scheduler1.input1 MaxDropProb 1%
Another form of dropper, a threshold-dropper, might be represented using
the following parameters:
AlgorithmicDropper2:
Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Fifo2.Depth > 20 kbyte
Output: Fifo1
Parameters: Yet another dropper which drops all out-of-profile packets whenever the
Threshold FIFO2.Threshold1 FIFO threshold exceeds a certain depth (this dropper is not part of the
larger TCB example) might be represented with the following parameters:
Yet another discarder (not part of the example) might be represented AlgorithmicDropper3:
with the following parameters: Type: AlgorithmicDropper2Input
Discarder3: Discipline: Drop-out-packets-on-threshold
Type: Discarder Output: Fifo3
Operate_on FIFO3
Trigger: FIFO3.depth > 100 packets
Discipline: Drop-all-out-packets
Parameters: InputA: (in profile)
Out-DSCP: AFx2_recommended_DSCP | AFx3_recommended_DSCP Trigger: none
InputB: (out of profile)
Trigger: Fifo3.Depth > 100 kbyte
7.1.4 Constructing queueing blocks from the elements <ed: this models the dropper without using an embedded Classifier
which seems a cleaner model than embedding a classifier here>
A queuing block is constructed by concatenation of these elements 7.1.4. Constructing queueing blocks from the elements
so as to meet the meta-policy objectives of the implementation,
subject to the grammar rules specified in this section.
Elements of the same type may appear more than once in a queueing A queueing block is constructed by concatenation of these elements so as
block, either in parallel or in series. Typically, a queuing block to meet the meta-policy objectives of the implementation, subject to the
will have relatively many elements in parallel and few in series. grammar rules specified in this section.
Iteration and recursion are not supported constructs in this
grammar. A queuing block must have at least one FIFO, at least
one discarder, and at least one scheduler. The following
connections are allowed:
The input of a FIFO may be the input of the queueing block, or it Elements of the same type may appear more than once in a queueing block,
may be connected to the output of a discarder or to an output of either in parallel or in series. Typically, a queueing block will have
a scheduler. relatively many elements in parallel and few in series. Iteration and
recursion are not supported constructs in this grammar. A queueing block
must have at least one FIFO, at least one dropper, and at least one
scheduler. The following connections are allowed:
Each input of a scheduler may be connected to the output of a 1) The input of a FIFO may be the input of the queueing block or it
FIFO, to the output of a discarder or to the output of another may be connected to the output of a dropper or to an output of a
scheduler. scheduler.
The input of a discarder which has a discrete input and output 2) Each input of a scheduler may be connected to the output of a FIFO,
may be the input of the queue, or it may be connected to the to the output of a dropper or to the output of another scheduler.
3) The input of a dropper which has a discrete input and output may be
the input of the queueing block or it may be connected to the
output of a FIFO (e.g., head dropping). output of a FIFO (e.g., head dropping).
The output of the queueing block may be the output of a FIFO 4) The output of the queueing block may be the output of a FIFO
element, a discarding element or a scheduling element. element, a discarding element or a scheduling element.
Note, in particular, that schedulers may operate in series such Note, in particular, that schedulers may operate in series such that a
that a packet at the head of a FIFO feeding the concatenated packet at the head of a FIFO feeding the concatenated schedulers is
schedulers is serviced only after all of the scheduling criteria serviced only after all of the scheduling criteria are met. For example,
are met. For example, a FIFO which carries EF traffic streams
may be served first by a non-work conserving scheduler to shape a FIFO which carries EF traffic streams may be served first by a non-
the stream to a maximum rate, then by a work conserving scheduler work-conserving scheduler to shape the stream to a maximum rate, then by
to mix EF traffic streams with other traffic streams. Alternatively, a work-conserving scheduler to mix EF traffic streams with other traffic
there might be a FIFO and/or a discarder between the two schedulers. streams. Alternatively, there might be a FIFO and/or a dropper between
the two schedulers.
7.2. Shaping
7.2 Shaping
Traffic shaping is often used to condition traffic such that packets Traffic shaping is often used to condition traffic such that packets
will be deemed conforming by subsequent meters, e.g., in downstream arriving in a burst will be "smoothed" and deemed conforming by
Diffserv nodes. Shaping may also be used to isolate certain traffic subsequent downstream meters in this or other nodes. Shaping may also be
streams from the effects of other traffic streams of the same BA. used to isolate certain traffic streams from the effects of other
traffic streams of the same BA.
A shaper is realized in this model by using a non-work conserving In [DSARCH] a shaper is described as a queueing element controlled by a
scheduler. Some implementations may elect to have queues whose sole meter which defines its temporal profile. However, this representation
purpose is shaping, while others may integrate the shaping function of a shaper differs substantially from typical shaper implementations.
with other buffering, discarding and scheduling associated with access
to a resource. Shapers operate by delaying the departure of packets In this conceptual model, a shaper is realized by using a non-work-
that would be deemed non-conforming by a meter configured to the shaper's conserving scheduler. Some implementations may elect to have queues
maximum service rate profile. The packet is scheduled to depart no whose sole purpose is shaping, while others may integrate the shaping
sooner than such time that it would become conforming. function with other buffering, discarding and scheduling associated with
access to a resource. Shapers operate by delaying the departure of
packets that would be deemed non-conforming by a meter configured to the
shaper's maximum service rate profile. The packet is scheduled to depart
no sooner than such time that it would become conforming.
8. Traffic Conditioning Blocks (TCBs) 8. Traffic Conditioning Blocks (TCBs)
The classifiers, meters, action elements, and queueing elements The classifiers, meters, action elements and queueing elements described
described above can be combined into traffic conditioning blocks above can be combined into traffic conditioning blocks (TCBs). The TCB
(TCBs). The TCB is an abstraction of a functional element that may is an abstraction of a functional element that may be used to facilitate
be used to facilitate the definition of specific traffic conditioning the definition of specific traffic conditioning functionality.
functionality.
One of the simplest possible TCBs would consist of the following A general TCB might consist of the following four stages:
stages: - Classification stage
- Metering stage
- Action stage
- Queueing stage
1. Classifier stage where each stage may consist of a set of parallel datapaths consisting
2. Enqueueing stage of pipelined elements.
3. Queueing stage
Note that a classifier is a 1:N element, while an enqueueing stage is Note that a classifier is a 1:N element, metering and actions are
a N:1 element and a queue is a 1:1 element. If the classifier split typically 1:1 elements and queueing is a N:1 element. The whole TCB
traffic across multiple enqueueing elements then the queueing stage should, however, result in a 1:1 abstract element.
may consist of a hierarchy of queue sets, all resulting in a 1:1
abstract element.
A more general TCB might consists of the following four stages: TCBs are constructed by connecting elements corresponding to these
stages in any sensible order. It is possible to omit stages, to include
null elements, or to concatenate multiple stages of the same type. TCB
outputs may drive additional TCBs (on either the ingress or egress
interfaces).
1. Classifier stage 8.1. An Example TCB
2. Metering stage
3. Action stage
4. Queueing stage
where each stage may consist of a set of parallel datapaths A SLS is presumed to have been negotiated between the customer and the
consisting of pipelined elements. provider which specifies the handling of the customer's traffic by the
provider's network. The agreement might be of the following form:
TCBs are constructed by connecting elements corresponding to these DSCP PHB Profile Treatment
stages in any sensible order. It is possible to omit stages, to ---- --- ------- ----------------------
include null elements, or to concatenate multiple stages of the same 001001 EF Profile4 Discard non-conforming.
type. TCB outputs may drive additional TCBs (on either the ingress 001100 AF11 Profile5 Shape to profile, tail-drop when full.
or egress interfaces). Classifiers and meters are fan-out elements, 001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
muxes and enqueueing elements are fan-in elements. tail-drop when full.
other BE none Apply RED-like dropping.
8.1 An Example TCB This SLS specifies that the customer may submit packets marked for DSCP
001001 which will get EF treatment so long as they remain conforming to
Profile1 and will be discarded if they exceed this profile. The
discarded packets are counted in this example, perhaps for use by the
provider's sales department in convincing the customer to buy a larger
SLS. Packets marked for DSCP 001100 will be shaped to Profile2 before
forwarding. Packets marked for DSCP 001101 will be metered to Profile3
with non-conforming packets "downgraded" by being re-marked with a DSCP
of 001000. It is implicit in this agreement that conforming packets are
given the PHB originally indicated by the packets' DSCP field.
The following diagram illustrates an example TCB: Figures 6 and 7 illustrates a TCB that might be used to handle this SLS
at an ingress interface at the customer/provider boundary.
+------------> to Queue A The Classification stage of this example consists of a single BA
+-----+ | (not shown) classifier. The BA classifier is used to separate traffic based on the
| |--+ Diffserv service level requested by the customer (as indicated by the
DSCP in each submitted packet's IP header). We illustrate three DSCP
filter values: A, B and C. The 'X' in the BA classifier is a wildcard
filter that matches every packet not otherwise matched.
The paths for DSCP 001001 and 001101 then include a metering stage.
There is a separate meter for each set of packets corresponding to
classifier outputs A and C. Each meter uses a specific profile, as
specified in the TCS, for the corresponding Diffserv service level. The
meters in this example each indicate one of two conforming levels,
+-----+
| A|---------------------------> to Queue1
+->| | +->| |
| | |--+ +-----+ +-----+ | | B|--+ +-----+ +-----+
| +-----+ | | | | | | +-----+ | | | | |
| meter +->| |--->| | | Meter1 +->| |--->| |
| | | | | | | | | |
| +-----+ +-----+ | +-----+ +-----+
| monitor dropper | Counter1 Absolute
| submitted +-----+ | Dropper1
| traffic | A|-----+
| --------->| B|----------------------------------------> to Dropper1
submitted +-----+ | +-----+ +-----+ | C|-----+
traffic | A |-----+ | | | | | X|--+ |
--->| B |------->| |---->| |---> to Queue B +-----+ | | +-----+ +-----+
| C |-----+ | | | | (not shown) Classifier1| | | A|--------------->|A |
| X |--+ | +-----+ +-----+ (BA) | +->| | | |--> to Dropper2
+-----+ | | marker shaper | | B|--+ +-----+ +->|B |
BA | | queue
classifier| |
| |
| |
| |
| |
| | +-----+ +-----+
| | | |--------------->| | to Queue C
| +->| | | |->
| | |--+ +-----+ +->| | (not shown)
| +-----+ | | | | +-----+ | +-----+ | | | | +-----+
| meter +->| |-+ mux | Meter2 +->| |-+ Mux1
| | | | | |
| +-----+ | +-----+
| marker | Marker1
| +-------------------------------------> to Dropper3
+---------------------------> to Queue D
(not shown)
Figure 5: An Example Traffic Conditioning Block
This sample TCB might be suitable for an ingress interface at a Figure 6: An Example Traffic Conditioning Block (Part 1)
customer/provider boundary. A SLS is presumed to have been
negotiated between the customer and the provider which specifies the
handling of the customer's traffic by the provider's network. The
agreement might be of the following form:
DSCP PHB Profile Non-Conforming Packets conforming or non-conforming.
---- --- ------- ----------------------
001001 PHB1 Profile1 Discard
001100 PHB2 Profile2 Wait in shaper queue
001101 PHB3 Profile3 Re-mark to DSCP 001000
It is implicit in this agreement that conforming packets are given
the PHB originally indicated by the packets' DSCP field. It
specifies that the customer may submit packets marked for DSCP
001001 which will get PHB1 treatment so long as they remain
conforming to Profile1 and will be discarded if they exceed this
profile. Similar contract rules are applied for 001100 and 001101
traffic.
In this example, the classification stage consists of a single BA Following the Metering stage is the Action stage in the upper and lower
classifier. The BA classifier is used to separate traffic based on branches. Packets submitted for DSCP 001001 that are deemed non-
the Diffserv service level requested by the customer (as indicated conforming are counted and discarded while packets that are conforming
by the DSCP in each submitted packet's IP header). We illustrate are passed on to Dropper1/Queue1. Packets submitted for DSCP 001101 that
three DSCP filter values: A, B and C. The 'X' in the BA classifier are deemed non-conforming are re-marked and then conforming and non-
is the default wildcard filter that matches every packet. conforming packets are multiplexed together before being passed on to
Dropper2/Queue3. Packets submitted for DSCP 001100 are passed straight
on to Queue2.
A metering stage is next in the upper and lower branches. There is a The Queueing stage is realised as follows, shown in figure 6. The
separate meter for each set of packets corresponding to DSCPs A and conforming 001001 packets are passed directly to Queue1: there is no
C. Each meter uses a specific profile as specified in the TCS for way, with correct configuration of the scheduler for these to overflow
the corresponding Diffserv service level. The meters in this the depth of Queue1 so there is never a requirement for dropping.
example indicate one of two conforming levels, conforming or Packets marked for 001100 must be passed through a tail-dropper,
non-conforming. The middle branch has a marker which re-marks all Dropper1, which serves to limit the depth of the following queue,
packets received with DSCP B. Queue2: packets that arrive to a full queue will be discarded - this is
likely to be an error case: the customer is obviously not sticking to
Following the metering stage is the action stage in the upper and its agreed profile. Similarly, packets from the 001101 stream are
lower branches. Packets submitted for DSCP A that are deemed non- passed to Dropper2 and Queue3. Packets marked for all other DSCPs are
conforming and are counted and discarded. Packets that are passed to Dropper3 which is a RED-like algorithmic dropper: based on
conforming are passed on to Queue A. Packets submitted for DSCP C feedback of the current depth of Queue4, this dropper is likely to
that are deemed non-conforming are re-marked, and then conforming and discard enough packets from its input stream to keep the queue depth
non-conforming packets are muxed together before being forwarded to under control.
Queue C. Packets submitted for DSCP B are shaped to Profile2 before
being forwarded to Queue B.
The interconnections of the TCB elements illustrated in Fig. 5 can be These four queues are then serviced by a scheduling algorithm in
represented as follows: Scheduler1 which has been configured to give each of the queues an
appropriate priority and/or bandwidth share. Inputs A and C are given
guarantees of bandwidth, as appropriate for the contracted profiles.
Input B is given a limit on the bandwidth it can use i.e. a non-work-
conserving discipline in order to achieve the desired shaping of this
stream. Input D is given no limits or guarantees but a lower priority
than the other queues, appropriate for its best-effort status. Traffic
then exits the scheduler in a single orderly stream.
from Meter1 +-----+
------------------------------->| |----+
| | |
+-----+ |
Queue1 |
| +-----+
from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic
Dropper1 Queue2 | | +-----+
| | Scheduler1
from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ |
| | | | |
+-----+ +-----+ |
Dropper2 Queue3 |
|
from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+
| | | |
+-----+ +-----+
Dropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2)
The interconnections of the TCB elements illustrated in Figures 6 and 7
can be represented as follows:
TCB1: TCB1:
Classifier1: Classifier1:
Output A --> Meter1 FilterA: Meter1
Output B --> Marker1 FilterB: Dropper1
Output C --> Meter2 FilterC: Meter2
Output X --> QueueD Default: Dropper3
Meter1: Meter1:
Output A --> QueueA Type: AverageRate
Output B --> Monitor1 Profile: Profile1
ConformingOutput: Queue1
Monitor1: NonConformingOutput: Counter1
Output A --> Dropper1
Marker1: Counter1:
Output A --> Shaper1 Output: AbsoluteDropper1
Shaper1:
Output A --> Queue B
Meter2: Meter2:
Output A --> Mux1 Type: AverageRate
Output B --> Marker2 Profile: Profile3
ConformingOutput: Mux1.InputA
NonConformingOutput: Marker1
Marker2: Marker1:
Output A --> Mux1 Type: DSCPMarker
Mark: 001000
Output: Mux1.InputB
Mux1: Mux1:
Output A --> Queue C Output: Dropper2
8.2 An Example TCB to Support Multiple Customers Dropper1:
Type: AlgorithmicDropper
Discipline: Drop-on-threshold
Trigger: Queue2.Depth > 10kbyte
Output: Queue2
Dropper2:
Type: AlgorithmicDropper
Discipline: Drop-on-threshold
Trigger: Queue3.Depth > 20kbyte
Output: Queue3
Dropper3:
Type: AlgorithmicDropper
Discipline: RED93
Trigger: Internal
Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too>
Queue1:
Type: FIFO
Output: Scheduler1.InputA
Queue2:
Type: FIFO
Output: Scheduler1.InputB
Queue3:
Type: FIFO
Output: Scheduler1.InputC
Queue4:
Type: FIFO
Output: Scheduler1.InputD
Scheduler1:
Type: Scheduler4Input
InputA:
MaxRateProfile: none
MinRateProfile: Profile4
Priority: 20
InputB:
MaxRateProfile: Profile5
MinRateProfile: none
Priority: 40
InputC:
MaxRateProfile: none
MinRateProfile: Profile3
Priority: 20
InputD:
MaxRateProfile: none
MinRateProfile: none
Priority: 10
8.2. 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 implement a provider/customer TCS if the interface is dedicated to the
the customer. However, if a single interface is shared between customer. However, if a single interface is shared between multiple
multiple customers, then the TCB above will not suffice, since it customers, then the TCB above will not suffice, since it does not
does not differentiate among traffic from different customers. Its differentiate among traffic from different customers. Its classification
classification stage uses only BA classifiers. stage uses only BA classifiers.
The TCB is readily extended to support the case of multiple customers The TCB is readily extended to support the case of multiple customers
per interface, as follows. First, we define a TCB for each customer per interface, as follows. First, a TCB is defined for each customer to
to reflect the TCS with that customer. TCB1, defined above is the reflect the TCS with that customer: TCB1, defined above is the TCB for
TCB for customer 1. We add definitions for TCB2 and for TCB3 which customer 1 and definitions are then added for TCB2 and for TCB3 which
reflect the agreements with customers 2 and 3 respectively. reflect the agreements with customers 2 and 3 respectively.
Finally, we add a classifier which provides a front end to separate Finally, a classifier is added to the front end to separate the traffic
the traffic from the three different customers. This forms a new from the three different customers. This forms a new TCB, TCB4, which
TCB which incorporates TCB1, TCB2, and TCB3, and can be illustrated incorporates TCB1, TCB2, and TCB3 and is illustrated in Figure 8.
as follows:
submitted +-----+ A formal representation of this multi-customer TCB might be:
traffic | A |--------> TCB1
--->| B |--------> TCB2
| C |--------> TCB3
| X |--------> Dropper4
+-----+
Classifier4
Figure 6: An Example of a Multi-Customer TCB TCB4:
A formal representation of this multi-customer TCB might be: Classifier4:
Filter1: to TCB1
Filter2: to TCB2
Filter3: to TCB3
No Match: AbsoluteDropper4
TCB1: TCB1:
(as defined above) (as defined above)
TCB2: TCB2:
submitted +-----+
traffic | A|--------> TCB1
--->| B|--------> TCB2
| C|--------> TCB3
| X|--------> AbsoluteDropper4
+-----+
Classifier4
Figure 8: An Example of a Multi-Customer TCB
(similar to TCB1, perhaps with different numeric parameters) (similar to TCB1, perhaps with different numeric parameters)
TCB3: TCB3:
(similar to TCB1, perhaps with different numeric parameters) (similar to TCB1, perhaps with different numeric parameters)
TCB4: TCB4:
(the total TCB) (the total TCB)
Classifier4: and the filters, based on each customer's source MAC address, could be
Output A --> TCB1
Output B --> TCB2
Output C --> TCB3
Output X --> Dropper4
Where Classifier2 is defined as follows:
Classifier4:
Filter1: Output A
Filter2: Output B
Filter3: Output C
No Match: Output X
and the filters, based on each customer's source MAC address, are
defined as follows: defined as follows:
Filter1: Filter1:
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 In this example, Classifier4 separates traffic submitted from different
different customers based on the source MAC address in submitted customers based on the source MAC address in submitted packets. Those
packets. Those packets with recognized source MAC addresses are packets with recognized source MAC addresses are passed to the TCB
passed to the TCB implementing the TCS with the corresponding implementing the TCS with the corresponding customer. Those packets with
customer. Those packets with unrecognized source MAC addresses are unrecognized source MAC addresses are passed to a dropper.
passed to a dropper.
TCB4 has a classification stage and an action element stage, which TCB4 has a Classifier stage and an Action element stage, which consists
consists of either a dropper or another TCB. of either a dropper or another TCB.
8.3 TCBs Supporting Microflow-based Services 8.3. 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 suitable for enforcing a SLS at a router's ingress. It assumes that the
the customer marks its own traffic for the appropriate service level. customer marks its own traffic for the appropriate service level. It
It then limits the rate of aggregate traffic submitted at each then limits the rate of aggregate traffic submitted at each service
service level, thereby protecting the resources of the Diffserv level, thereby protecting the resources of the Diffserv network. It does
network. It does not provide any isolation between the customer's not provide any isolation between the customer's individual microflows.
individual microflows (other than from separated queueing).
Next we present a TCB configuration that offers additional A more complex example might be a TCB configuration that offers
functionality to the customer. It recognizes individual customer additional functionality to the customer. It recognizes individual
microflows and marks each one independently. It also isolates the
customer's individual microflows from each other in order to prevent customer microflows and marks each one independently. It also isolates
the customer's individual microflows from each other in order to prevent
a single microflow from seizing an unfair share of the resources a single microflow from seizing an unfair share of the resources
available to the customer at a certain service level. This is available to the customer at a certain service level. This is
illustrated in Figure 7 below: illustrated in Figure 9.
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
was marked. Packets exceeding the allowable limit for the microflow are
dropped.
This TCB could be formally specified as follows:
+-----+ +-----+ +-----+ +-----+
| | | |---------------+ Classifier1 | | | |---------------+
+->| |-->| | +-----+ | (MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | | +-----+ | | | | |---->| | |
| |---- +-----+ +-----+ +-----+ | | A|------ +-----+ +-----+ +-----+ |
->| |---- marker meter dropper | +-----+ to --->| B|-----+ Marker1 Meter1 Absolute |
| |-+ | +-----+ +-----+ +-->| | | C|---+ | Dropper1 | +-----+
+-----+ | | | | | |------------------>| |---> | X|-+ | | +-----+ +-----+ +-->|A |
MF | +->| |-->| | +-----+ +-->| | +-----+ | | | | | | |------------------>|B |--->
class. | | | | |---->| | | +-----+ TCB2 | | +->| |-->| | +-----+ +-->|C | to TCB2
| +-----+ +-----+ +-----+ | mux | | | | | |---->| | | +-----+
| marker meter dropper | | | +-----+ +-----+ +-----+ | Mux1
| +-----+ +-----+ | | | Marker2 Meter2 Absolute |
| | | | |---------------+ | | Dropper2 |
|--->| |-->| | +-----+ | | +-----+ +-----+ |
| | | | | |---------------+
| |--->| |-->| | +-----+
| | | | |---->| | | | | | |---->| |
| +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+
| marker meter dropper | Marker3 Meter3 Absolute
| . . . | Dropper3
V V V V V etc.
Figure 7: An Example of a Marking and Traffic Isolation TCB
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 (in this particular
example we assume that one of two different DSCPs is marked). The
metering stage limits 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.
The TCB could be formally specified as follows:
Figure 9: An Example of a Marking and Traffic Isolation TCB
TCB1: TCB1:
Classifier1: (MF) Classifier1: (MF)
Output A --> Marker1 FilterA: Marker1
Output B --> Marker2 FilterB: Marker2
Output C --> Marker3 FilterC: Marker3
. . . etc.
Marker1 --> Meter1 Marker1:
Marker2 --> Meter2 Output: Meter1
Marker3 --> Meter3
Marker2:
Output: Meter2
Marker3:
Output: Meter3
Meter1: Meter1:
Output A --> TCB2 ConformingOutput: Mux1.InputA
Output B --> ActionElement1 (dropper) NonConformingOutput: AbsoluteDropper1
Meter2: Meter2:
Output A --> TCB2 ConformingOutput: Mux1.InputB
Output B --> ActionElement2 (dropper) NonConformingOutput: AbsoluteDropper2
Meter3: Meter3:
Output A --> TCB2 ConformingOutput: Mux1.InputC
Output B --> ActionElement3 (dropper) NonConformingOutput: AbsoluteDropper3
The actual traffic element declarations are not shown here. etc.
Mux1:
Output: to TCB2
Note that the detailed traffic element declarations are not shown here.
Traffic is either dropped by TCB1 or emerges marked for one of two Traffic is either dropped by TCB1 or emerges marked for one of two
DSCPs. This traffic is then passed to TCB2, illustrated below: DSCPs. This traffic is then passed to TCB2 which is illustrated in
Figure 10.
TCB2 could then be specified as follows:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
Meter5:
ConformingOutput: Queue1
+-----+ +-----+
| |---------------> | |---------------> to Queue1
+->| | +-----+ +->| | +-----+
+-----+ | | |---->| | +-----+ | | |---->| |
| |---+ +-----+ +-----+ | A|---+ +-----+ +-----+
->| | meter dropper ->| | Meter5 AbsoluteDropper4
| |---+ +-----+ | B|---+ +-----+
+-----+ | | |---------------> +-----+ | | |---------------> to Queue2
BA +->| | +-----+ Classifier2 +->| | +-----+
classifier | |---->| | (BA) | |---->| |
+-----+ +-----+ +-----+ +-----+
meter dropper Meter6 AbsoluteDropper5
Figure 8: Additional Example TCB
TCB2 would be formally specified as follows: Figure 10: Additional Example: TCB2
Classifier2: (BA) NonConformingOutput: AbsoluteDropper4
Output A --> Meter10
Output B --> Meter11
Meter10:
Output A --> PHBQueueA
Output B --> Dropper10
Meter11: Meter6:
Output A --> PHBQueueB ConformingOutput: Queue2
Output B --> Dropper11 NonConformingOutput: AbsoluteDropper5
8.4 Cascaded TCBs 8.4. Cascaded TCBs
Conceptually, nothing prevents more complex scenarios in which one Nothing in this model prevents more complex scenarios in which one
microflow TCB precedes another (for example, TCBs implementing microflow TCB precedes another (e.g. for TCBs implementing separate TCSs
separate TCS's for the source and for a set of destinations). for the source and for a set of destinations).
9. Open Issues 9. Open Issues
o There is a difference in interpretation of token bucket behavior <ed: this section to be deleted before WG last call and RFC publication.
between this document (Appendix A) and [DSMIB]. Specifically, The current stance of this draft is supplied in parentheses.
[DSMIB] allows a packet to conform if any smaller packet would
conform.
o The meter in [SRTCM] cannot be precisely modeled using two
two-parameter token buckets because its two buckets do not
accumulate credits independently. We intended to demonstrate how
the [TRTCM] meter could be implemented but ran out of time.
o Are the queue parameters (scheduling and buffer management)
parameters defined sufficient?
o Does Queue and Queue Set really belong in the model (and the MIB
and PIB?), or should the model stick to the abstract PHB
representation and leave the implementation details to the MIB and
PIB?
o Should a classifier be part of a TCB? We argue yes. This allows a (1) FIFOs are modelled here as having infinite depth: it is up to any
TCB to be a one input/one output black box element. preceding meter/dropper to make sure that they do not overflow - a
hard stop on the depth would be modelled, for example, by preceding
the FIFO with an Absolute Dropper. Is this appropriate? (Yes)
o Is the description of a shaper sufficient? Is it overbroad? (2) We must allow algorithmic droppers that apply different dropping
behaviour to packets with different classifier matches, with these
possibly fed through different meters and actions. Should we model
the dropper as a single input element with implicit pointers back
to the matching classifier that selects different dropper
algorithms/treatments? Or as multiple droppers? Or as having
multiple logical inputs? (single input, implicit pointers).
10. Security Considerations 10. Security Considerations
Security vulnerabilities of Diffserv network operation are discussed Security vulnerabilities of Diffserv network operation are discussed in
in [DSARCH]. This document describes an abstract functional model of [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 those resulting from resource starvation may be mitigated by appropriate
appropriate configuration of these router elements; for example, by configuration of these router elements; for example, by rate limiting
rate limiting certain traffic streams or by authenticating traffic certain traffic streams or by authenticating traffic marked for higher
marked for higher quality-of-service. quality-of-service.
One particular theft- or denial-of-service issue may arise where a
token-bucket meter, with an absolute dropper for non-conforming traffic,
is used in a TCB to police a stream to a given TCS: the definition of
the token-bucket meter in section 5 indicates that it should be lenient
in accepting a packet whenever any bits of the packet would have been
within the profile; the definition of the leaky-bucket scheduler is
conservative in that a packet is to be transmitted only if the whole
packet fits 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.
11. Acknowledgments 11. Acknowledgments
Concepts, terminology, and text have been borrowed liberally from Concepts, terminology, and text have been borrowed liberally from
[DSMIB] and [PIB]. We wish to thank the authors: Fred Baker, [POLTERM], [DSMIB] and [DSPIB]. We wish to thank the authors of those
Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, and documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson,
Scott Hahn, for their permission. Kwok Chan and Scott Hahn for their contributions.
This document has benefitted from the comments and suggestions of This document has benefitted from the comments and suggestions of
several participants of the Diffserv working group. several participants of the Diffserv working group.
12. References 12. References
[DSARCH] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and [AF-PHB]
E. Davies, "An Architecture for Differentiated Services", J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured
RFC 2475, December 1998 Forwarding PHB Group", RFC 2597, June 1999.
[DSTERMS] D. Grossman, "New Terminology for Diffserv", Internet
Draft <draft-ietf-diffserv-new-terms-00.txt>, October
1999.
[E2E] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang,
M. Speer, K. Nichols, R. Braden, B. Davie, J. Wroclawski,
and E. Felstaine, "Integrated Services Operation over
Diffserv Networks", Internet Draft
<draft-ietf-issll-diffserv-rsvp-02.txt>, September 1999.
[DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[EF-PHB] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[AF-PHB] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[DSMIB] F. Baker, "Differentiated Services MIB", Internet Draft
<draft-ietf-diffserv-mib-00.txt>, June 1999.
[SRTCM] J. Heinanen, and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
and A. Smith, "Quality of Service Policy Information
Base", Internet Draft <draft-mfine-cops-pib-01.txt>,
June 1999.
[TRTCM] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker",
RFC 2698, September 1999.
[GTC] L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner",
Internet Draft <draft-lin-diffserv-gtc-01.txt>, August
1999.
[MPLSDS] J. Heinanen, "Differentiated Services in MPLS Networks",
Internet Draft <draft-heinanen-diffserv-mpls-00.txt>,
June 1999.
Appendix A. Simple Token Bucket Definition
[DSMIB] presents a fairly detailed exposition on the operation of
two-parameter token buckets for metering. However, the behavior
described does not appear to be consistent with the behavior defined
in [SRTCM] and [TRTCM]. Specifically, under the definition in
[DSMIB], a packet is assumed to conform to the meter if any of its
bytes would have been accepted, while in [SRTCM] and [TRTCM], a packet
is assumed to conform only if sufficient tokens are available for
every byte in the packet. Further, a packet has no effect on the
token occupancy if it does not conform (no tokens are decremented).
The behavior defined in [SRTCM] and [TRTCM] is not mandatory for [DSARCH]
compliance, but we give here a mathematical definition of two- M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies,
parameter token bucket operation which is consistent with these "An Architecture for Differentiated Services", RFC 2475, December
documents, and which can be used to define a shaping profile. 1998
Define a token bucket with bucket size BS, token accumulation rate [DSFIELD]
R, and instantaneous token occupancy T(t). Assume that T(0) = BS. K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
Then after an arbitrary interval with no packet arrivals, T(t) will [DSMIB]
not change since the bucket is already full of tokens. Assume a F. Baker, A. Smith, K. Chan, "Differentiated Services MIB",
packet of size B bytes at time t'. The bucket capacity T(t'-) = BS Internet Draft <draft-ietf-diffserv-mib-03.txt>, May 2000.
still. Then, as long as B <= BS, the packet conforms to the meter,
and
T(t') = BS - B. [DSPIB]
M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, and A.
Smith, "Quality of Service Policy Information Base", Internet Draft
<draft-ietf-diffserv-pib-00.txt>, March 2000.
Assume an interval v = t - t' elapses before the next packet, of [DSTERMS]
size C <= BS, arrives. T(t-) is given by the following equation: D. Grossman, "New Terminology for Diffserv", Internet Draft <draft-
ietf-diffserv-new-terms-02.txt>, November 1999.
T(t-) = min { BS, T(t') + v*R } [E2E]
Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K.
Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine,
"Integrated Services Operation over Diffserv Networks", Internet
Draft <draft-ietf-issll-diffserv-rsvp-04.txt>, March 2000.
(the packet has accumulated v*R tokens over the interval, up to a [EF-PHB]
maximum of BS tokens). V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding
PHB", RFC 2598, June 1999.
If T(t-) - C >= 0, the packet conforms and T(t) = T(t-) - C. [GTC]
Otherwise, the packet does not conform and T(t) = T(t-). L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner", Internet
Draft <draft-lin-diffserv-gtc-01.txt>, August 1999.
This function can be used to define a shaping profile. If a packet of [INTSERV]
size C arrives at time t, it will be eligible for transmission at time R. Braden, D. Clark and S. Shenker, "Integrated Services in the
te given as follows (we still assume C <= BS): Internet Architecture: an Overview" RFC 1633, June 1994.
te = max { t, t" } [POLTERM]
F. Reichmeyer, D. Grossman, J. Strassner, M. Condell, "A Common
Terminology for Policy Management", Internet Draft <draft-
where [QOSDEVMOD]
J. Strassner, W. Weiss, D. Durham, A. Westerinen, "Information
Model for Describing Network Device QoS Mechanisms", Internet Draft
t" = (C - T(t') + t'*R)/R. [SRTCM]
J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC
2697, September 1999.
T(t") = C, the time when C credits have accumulated in the bucket, [TRTCM]
and when the packet would conform if the token bucket were a meter. J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698,
te != t" only if t > t". September 1999.
Authors' Addresses 13. 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 E-mail: yoramb@microsoft.com
Andrew Smith Andrew Smith
Extreme Networks Extreme Networks
skipping to change at line 1877 skipping to change at page 44, line 38
Raleigh, NC 27606 Raleigh, NC 27606
Phone: +1 919 472 9913 Phone: +1 919 472 9913
E-mail: slblake@torrentnet.com E-mail: slblake@torrentnet.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 E-mail: dan@dma.isg.mot.com
Table of Contents
1 Introduction .................................................... 2
2 Glossary ........................................................ 3
3 Conceptual Model ................................................ 5
3.1 Elements of a Diffserv Router ................................. 5
3.1.1 Datapath .................................................... 5
3.1.2 Configuration and Management Interface ...................... 6
3.1.3 Optional QoS Agent Module ................................... 7
3.2 Hierarchical Model of Diffserv Components ..................... 7
4 Classifiers ..................................................... 10
4.1 Definition .................................................... 10
4.1.1 Filters ..................................................... 11
4.1.2 Overlapping Filters ......................................... 11
4.2 Examples ...................................................... 12
4.2.1 Behaviour Aggregate (BA) Classifier ......................... 12
4.2.2 Multi-Field (MF) Classifier ................................. 13
4.2.3 Free-form Classifier ........................................ 13
4.2.4 Other Possible Classifiers .................................. 14
5 Meters .......................................................... 14
5.1 Examples ...................................................... 17
5.1.1 Average Rate Meter .......................................... 17
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............ 18
5.1.3 Two-Parameter Token Bucket Meter ............................ 19
5.1.4 Multi-Stage Token Bucket Meter .............................. 19
5.1.5 Null Meter .................................................. 20
6 Action Elements ................................................. 20
6.1 Marker ........................................................ 21
6.2 Absolute Dropper .............................................. 21
6.3 Multiplexer ................................................... 22
6.4 Counter ....................................................... 22
6.5 Null Action ................................................... 22
7 Queueing Blocks ................................................. 22
7.1 Queueing Model ................................................ 23
7.1.1 FIFO ........................................................ 23
7.1.2 Scheduler ................................................... 25
7.1.3 Algorithmic Dropper ......................................... 27
7.1.4 Constructing queueing blocks from the elements .............. 30
7.2 Shaping ....................................................... 31
8 Traffic Conditioning Blocks (TCBs) .............................. 31
8.1 An Example TCB ................................................ 32
8.2 An Example TCB to Support Multiple Customers .................. 37
8.3 TCBs Supporting Microflow-based Services ...................... 38
8.4 Cascaded TCBs ................................................. 41
9 Open Issues ..................................................... 41
10 Security Considerations ........................................ 42
11 Acknowledgments ................................................ 42
12 References ..................................................... 42
13 Authors' Addresses ............................................. 44
14. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 295 change blocks. 
1256 lines changed or deleted 1409 lines changed or added

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