Request for Comments: 3290 Microsoft
Category: Informational S. Blake
Ericsson
D. Grossman
Motorola
A. Smith
Harbour Networks
May 2002
An Informal Management Model for Diffserv Routers
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document proposes an informal management model of Differentiated
Services (Diffserv) routers for use in their management and
configuration. This model defines functional datapath elements
(e.g., classifiers, meters, actions, marking, absolute dropping,
counting, multiplexing), algorithmic droppers, queues and schedulers.
It describes possible configuration parameters for these elements and
how they might be interconnected to realize the range of traffic
conditioning and per-hop behavior (PHB) functionalities described in
the Diffserv Architecture.
Table of Contents
1 Introduction ................................................. 3
2 Glossary ..................................................... 4
3 Conceptual Model ............................................. 7
3.1 Components of a Diffserv Router ............................ 7
3.1.1 Datapath ................................................. 7
3.1.2 Configuration and Management Interface ................... 9
3.1.3 Optional QoS Agent Module ................................ 10
3.2 Diffserv Functions at Ingress and Egress ................... 10
3.3 Shaping and Policing ....................................... 12
3.4 Hierarchical View of the Model ............................. 12
4 Classifiers .................................................. 13
4.1 Definition ................................................. 13
4.1.1 Filters .................................................. 15
4.1.2 Overlapping Filters ...................................... 15
4.2 Examples ................................................... 16
4.2.1 Behavior Aggregate (BA) Classifier ....................... 16
4.2.2 Multi-Field (MF) Classifier .............................. 17
4.2.3 Free-form Classifier ..................................... 17
4.2.4 Other Possible Classifiers ............................... 18
5 Meters ....................................................... 19
5.1 Examples ................................................... 20
5.1.1 Average Rate Meter ....................................... 20
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ......... 21
5.1.3 Two-Parameter Token Bucket Meter ......................... 21
5.1.4 Multi-Stage Token Bucket Meter ........................... 22
5.1.5 Null Meter ............................................... 23
6 Action Elements .............................................. 23
6.1 DSCP Marker ................................................ 24
6.2 Absolute Dropper ........................................... 24
6.3 Multiplexor ................................................ 25
6.4 Counter .................................................... 25
6.5 Null Action ................................................ 25
7 Queuing Elements ............................................. 25
7.1 Queuing Model .............................................. 26
7.1.1 FIFO Queue ............................................... 27
7.1.2 Scheduler ................................................ 28
7.1.3 Algorithmic Dropper ...................................... 30
7.2 Sharing load among traffic streams using queuing ........... 33
7.2.1 Load Sharing ............................................. 34
7.2.2 Traffic Priority ......................................... 35
8 Traffic Conditioning Blocks (TCBs) ........................... 35
8.1 TCB ........................................................ 36
8.1.1 Building blocks for Queuing .............................. 37
8.2 An Example TCB ............................................. 37
8.3 An Example TCB to Support Multiple Customers ............... 42
8.4 TCBs Supporting Microflow-based Services ................... 44
8.5 Cascaded TCBs .............................................. 47
9 Security Considerations ...................................... 47
10 Acknowledgments ............................................. 47
11 References .................................................. 47
Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 50
Authors' Addresses ............................................. 55
Full Copyright Statement........................................ 56
1. Introduction
Differentiated Services (Diffserv) [DSARCH] is a set of technologies
which allow network service providers to offer services with
different kinds of network quality-of-service (QoS) objectives to
different customers and their traffic streams. This document uses
terminology defined in [DSARCH] and [NEWTERMS] (some of these
definitions are included here in Section 2 for completeness).
The premise of Diffserv networks is that routers within the core of
the network handle packets in different traffic streams by forwarding
them using different per-hop behaviors (PHBs). The PHB to be applied
is indicated by a Diffserv codepoint (DSCP) in the IP header of each
packet [DSFIELD]. The DSCP markings are applied either by a trusted
upstream node, e.g., a customer, or by the edge routers on entry to
the Diffserv network.
The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behavior aggregates (BA),
which are each forwarded using the same PHB at the router, thereby
simplifying the processing and associated storage. In addition,
there is no signaling other than what is carried in the DSCP of each
packet, and no other related processing that is required in the core
of the Diffserv network since QoS is invoked on a packet-by-packet
basis.
The Diffserv architecture enables a variety of possible services
which could be deployed in a network. These services are reflected
to customers at the edges of the Diffserv network in the form of a
Service Level Specification (SLS - see [NEWTERMS]). Whilst further
discussion of such services is outside the scope of this document
(see [PDBDEF]), the ability to provide these services depends on the
availability of cohesive management and configuration tools that can
be used to provision and monitor a set of Diffserv routers in a
coordinated manner. To facilitate the development of such
configuration and management tools it is helpful to define a
conceptual model of a Diffserv router that abstracts away
implementation details of particular Diffserv routers from the
parameters of interest for configuration and management. The purpose
of this document is to define such a model.
The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
This document is not intended in any way to constrain or to dictate
the implementation alternatives of Diffserv routers. It is expected
that router implementers will demonstrate a great deal of variability
in their implementations. To the extent that implementers are able
to model their implementations using the abstractions described in
this document, configuration and management tools will more readily
be able to configure and manage networks incorporating Diffserv
routers of assorted origins.
This 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 system implementation nor as a formal modeling description.
This model serves as the rationale for the design of an SNMP MIB
[DSMIB] and for other configuration interfaces (e.g., other policy-
management protocols) and, possibly, more detailed formal models
(e.g., [QOSDEVMOD]): these should all be consistent with this model.
o Section 3 starts by describing the basic high-level blocks of a
Diffserv router. It explains the concepts used in the model,
including the hierarchical management model for these blocks which
uses low-level functional datapath elements such as Classifiers,
Actions, Queues.
o Section 4 describes Classifier elements.
o Section 5 discusses Meter elements.
o Section 6 discusses Action elements.
o Section 7 discusses the basic queuing elements of Algorithmic
Droppers, Queues, and Schedulers and their functional behaviors
(e.g., traffic shaping).
o Section 8 shows how the low-level elements can be combined to
build modules called Traffic Conditioning Blocks (TCBs) which are
useful for management purposes.
o Section 9 discusses security concerns.
o Appendix A contains a brief discussion of the token bucket and
leaky bucket algorithms used in this model and some of the
practical effects of the use of token buckets within the Diffserv
architecture.
2. Glossary
This document uses terminology which is defined in [DSARCH]. There
is also current work-in-progress on this terminology in the IETF and
some of the definitions provided here are taken from that work. Some
of the terms from these other references are defined again here in
order to provide additional detail, along with some new terms
specific to this document.
Absolute A functional datapath element which simply discards all
Dropper packets arriving at its input.
Algorithmic A functional datapath element which selectively
Dropper discards packets that arrive at its input, based on a
discarding algorithm. It has one data input and one
output.
Classifier A functional datapath element which consists of filters
that select matching and non-matching packets. Based
on this selection, packets are forwarded along the
appropriate datapath within the router. A classifier,
therefore, splits a single incoming traffic stream into
multiple outgoing streams.
Counter A functional datapath element which updates a packet
counter and also an octet counter for every
packet that passes through it.
Datapath A conceptual path taken by packets with particular
characteristics through a Diffserv router. Decisions
as to the path taken by a packet are made by functional
datapath elements such as Classifiers and Meters.
Filter A set of wildcard, prefix, masked, range and/or exact
match conditions on the content of a packet's
headers or other data, and/or on implicit or derived
attributes associated with the packet. A filter is
said to match only if each condition is satisfied.
Functional A basic building block of the conceptual router.
Datapath Typical elements are Classifiers, Meters, Actions,
Element Algorithmic Droppers, Queues and Schedulers.
Multiplexer A multiplexor.
(Mux)
Multiplexor A functional datapath element that merges multiple
(Mux) traffic streams (datapaths) into a single traffic
stream (datapath).
Non-work- A property of a scheduling algorithm such that it
conserving services packets no sooner than a scheduled departure
time, even if this means leaving packets queued
while the output (e.g., a network link or connection
to the next element) is idle.
Policing The process of comparing the arrival of data packets
against a temporal profile and forwarding, delaying
or dropping them so as to make the output stream
conformant to the profile.
Queuing A combination of functional datapath elements
Block that modulates the transmission of packets belonging
to a traffic streams and determines their
ordering, possibly storing them temporarily or
discarding them.
Scheduling An algorithm which determines which queue of a set
algorithm of queues to service next. This may be based on the
relative priority of the queues, on a weighted fair
bandwidth sharing policy or some other policy. Such
an algorithm may be either work-conserving or non-
work-conserving.
Service-Level A set of parameters and their values which together
Specification define the treatment offered to a traffic stream by a
(SLS) Diffserv domain.
Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined temporal
profile. Shaping can be implemented using a queue
serviced by a non-work-conserving scheduling algorithm.
Traffic A logical datapath entity consisting of a number of
Conditioning functional datapath elements interconnected in
Block (TCB) such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream.
A TCB can be thought of as an entity with one
input and one or more outputs and a set of control
parameters.
Traffic A set of parameters and their values which together
Conditioning specify a set of classifier rules and a traffic
Specification profile. A TCS is an integral element of a SLS.
(TCS)
Work- A property of a scheduling algorithm such that it
conserving services a packet, if one is available, at every
transmission opportunity.
3. Conceptual Model
This section introduces a block diagram of a Diffserv router and
describes the various components illustrated in Figure 1. Note that
a Diffserv core router is likely to require only a subset of these
components: the model presented here is intended to cover the case of
both Diffserv edge and core routers.
3.1. Components of a Diffserv Router
The conceptual model includes abstract definitions for the following:
o Traffic Classification elements.
o Metering functions.
o Actions of Marking, Absolute Dropping, Counting, and
Multiplexing.
o Queuing elements, including capabilities of algorithmic
dropping and scheduling.
o Certain combinations of the above functional datapath elements
into higher-level blocks known as Traffic Conditioning Blocks
(TCBs).
The components and combinations of components described in this
document form building blocks that need to be manageable by Diffserv
configuration and management tools. One of the goals of this
document is to show how a model of a Diffserv device can be built
using these component blocks. This model is in the form of a
connected directed acyclic graph (DAG) of functional datapath
elements that describes the traffic conditioning and queuing
behaviors that any particular packet will experience when forwarded
to the Diffserv router. Figure 1 illustrates the major functional
blocks of a Diffserv router.
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 (note:
it is possible that such policies for output-interface selection
might involve use of packet fields such as the DSCP but this is
outside the scope of this model). The actual queuing delay and
packet loss behavior of a specific router's switching
fabric/backplane is not modeled by the routing core; these should be
modeled using the functional datapath elements described later. The
routing core of this model can be thought of as an infinite
bandwidth, zero-delay interconnect between interfaces - properties
like the behavior of the core when overloaded need to be reflected
back into the queuing elements that are modeled around it (e.g., when
too much traffic is directed across the core at an egress interface),
the excess must either be dropped or queued somewhere: the elements
performing these functions must be modeled on one of the interfaces
involved.
The components of interest at the ingress to and egress from
interfaces are the functional datapath elements (e.g., Classifiers,
Queuing elements) that support Diffserv traffic conditioning and
per-hop behaviors [DSARCH]. These are the fundamental components
comprising a Diffserv router and are the focal point of this model.
+---------------+
| Diffserv |
Mgmt | configuration |
<----+-->| & management |------------------+
SNMP,| | interface | |
COPS | +---------------+ |
etc. | | |
| | |
| v v
| +-------------+ +-------------+
| | ingress i/f | +---------+ | egress i/f |
-------->| classify, |-->| routing |-->| classify, |---->
data | | meter, | | core | | meter |data out
in | | action, | +---------+ | action, |
| | queuing | | queuing |
| +-------------+ +-------------+
| ^ ^
| | |
| | |
| +------------+ |
+-->| QOS agent | |
-------->| (optional) |---------------------+
QOS |(e.g., RSVP)|
cntl +------------+
msgs
Figure 1: Diffserv Router Major Functional Blocks
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) negotiated
with customers. Provisioned parameters are primarily the TCS
parameters for Classifiers and Meters and the associated PHB
configuration parameters for Actions and Queuing elements. 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 rules and goals governing the Diffserv behavior of a
router are presumed to be installed by policy management mechanisms.
However, Diffserv routers are always subject to implementation limits
which scope the kinds of policies which can be successfully
implemented by the router. External reporting of such implementation
capabilities is considered out of scope for this document.
3.1.3. Optional QoS Agent Module
Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E] (e.g., using
the RSVP protocol). Snooping of RSVP messages may be used, for
example, to learn how to classify traffic without actually
participating as a RSVP protocol peer. Diffserv routers may reject
or admit RSVP reservation requests to provide a means of admission
control to Diffserv-based services or they may use these requests to
trigger provisioning changes for a flow-aggregation in the Diffserv
network. A flow-aggregation in this context might be equivalent to a
Diffserv BA or it may be more fine-grained, relying on a multi-field
(MF) classifier [DSARCH]. Note that the conceptual model of such a
router implements the Integrated Services Model as described in
[INTSERV], applying the control plane controls to the data classified
and conditioned in the data plane, as described in [E2E].
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 this scenario, RSVP could be used merely to signal reservation
state without installing any actual reservations in the data plane of
the Diffserv 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. Diffserv Functions at Ingress and Egress
This document focuses on the Diffserv-specific components of the
router. Figure 2 shows a high-level view of ingress and egress
interfaces of a router. The diagram illustrates two Diffserv router
interfaces, each having a set of ingress and a set of egress
elements. It shows classification, metering, action and queuing
functions which might be instantiated at each interface's ingress and
egress.
The simple diagram of Figure 2 assumes that the set of Diffserv
functions to be carried out on traffic on a given interface are
independent of those functions on all other interfaces. There are
some architectures where Diffserv functions may be shared amongst
multiple interfaces (e.g., processor and buffering resources that
handle multiple interfaces on the same line card before forwarding
across a routing core). The model presented in this document may be
easily extended to handle such cases; however, this topic is not
treated further here as it leads to excessive complexity in the
explanation of the concepts.
Interface A Interface B
+-------------+ +---------+ +-------------+
| ingress: | | | | egress: |
| classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |--->
| action, | | | | action, |
| queuing | | routing | | queuing |
+-------------+ | core | +-------------+
| egress: | | | | ingress: |
| classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<---
| action, | | | | action, |
| queuing | +---------+ | queuing |
+-------------+ +-------------+
Figure 2. Traffic Conditioning and Queuing Elements
In principle, if one were to construct a network entirely out of
two-port routers (connected by LANs or similar media), then it might
be necessary for each router to perform four QoS control functions in
the datapath on traffic in each direction:
- Classify each message according to some set of rules, possibly
just a "match everything" rule.
- 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) [DSFIELD].
- Enqueue the traffic for output in the appropriate queue. The
scheduling of output from this queue may lead to shaping of the
traffic or may simply cause it to be forwarded with some minimum
rate or maximum latency assurance.
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 at the ingress
as on the egress of a router's interfaces. The one point of
difference in the model between ingress and the egress is that all
traffic at the egress of an interface is queued, while traffic at the
ingress to an interface is likely to be queued only for shaping
purposes, if at all. Therefore, equivalent functional datapath
elements may be modeled at both the ingress to and egress from an
interface.
Note that it is not mandatory that each of these functional datapath
elements be implemented at both ingress and egress; 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 modeling these elements at both
ingress and egress, it is not implied that they must be implemented
in this way in a specific router. For example, a router may
implement all shaping and PHB queuing at the interface egress or may
instead implement it only at the ingress. Furthermore, the
classification needed to map a packet to an egress queue (if present)
need not be implemented at the egress but instead might be
implemented at the ingress, with the packet passed through the
routing core with in-band control information to allow for egress
queue selection.
Specifically, some interfaces will be at the outer "edge" and some
will be towards the "core" of the Diffserv domain. It is to be
expected (from the general principles guiding the motivation of
Diffserv) that "edge" interfaces, or at least the routers that
contain them, will implement more complexity and require more
configuration than those in the core although this is obviously not a
requirement.
3.3. Shaping and Policing
Diffserv nodes may apply shaping, policing and/or marking to traffic
streams that exceed the bounds of their TCS in order to prevent one
traffic stream from seizing more than its share of resources from a
Diffserv network. In this model, Shaping, sometimes considered as a
TC action, is treated as a function of queuing elements - see section
7. Algorithmic Dropping techniques (e.g., RED) are similarly treated
since they are often closely associated with queues. Policing is
modeled as either a concatenation of a Meter with an Absolute Dropper
or as a concatenation of an Algorithmic Dropper with a Scheduler.
These elements will discard packets which exceed the TCS.
3.4. Hierarchical View of the Model
From a device-level configuration management perspective, the
following hierarchy exists:
At the lowest level considered here, there are individual
functional datapath elements, each with their own configuration
parameters and management counters and flags.
At the next level, the network administrator manages groupings of
these functional datapath elements interconnected in a DAG. These
functional datapath elements are organized in self-contained TCBs
which are used to implement some desired network policy (see
Section 8). One or more TCBs may be instantiated at each
interface's ingress or egress; they may be connected in series
and/or in parallel configurations on the multiple outputs of a
preceding TCB. A TCB can be thought of as a "black box" with one
input and one or more outputs (in the data path). Each interface
may have a different TCB configuration and each direction (ingress
or egress) may too.
At the topmost level considered here, the network administrator
manages interfaces. Each interface has ingress and egress
functionality, with each of these expressed as one or more TCBs.
This level of the hierarchy is what was illustrated in Figure 2.
Further levels may be built on top of this hierarchy, in particular
ones for aiding in the repetitive configuration tasks likely for
routers with many interfaces: some such "template" tools for Diffserv
routers are outside the scope of this model but are under study by
other working groups within IETF.
4. Classifiers
4.1. Definition
Classification is performed by a classifier element. Classifiers are
1:N (fan-out) devices: they take a single traffic stream as input and
generate N logically separate traffic streams as output. Classifiers
are parameterized by filters and output streams. Packets from the
input stream are sorted into various output streams by filters which
match the contents of the packet or possibly match other attributes
associated with the packet. Various types of classifiers using
different filters are described in the following sections. Figure 3
illustrates a classifier, where the outputs connect to succeeding
functional datapath elements.
The simplest possible Classifier element is one that matches all
packets that are applied at its input. In this case, the Classifier
element is just a no-op and may be omitted.
Note that we allow a Multiplexor (see Section 6.5) before the
Classifier to allow input from multiple traffic streams. For
example, if traffic streams originating from multiple ingress
interfaces feed through a single Classifier then the interface number
could be one of the packet classification keys used by the
Classifier. This optimization may be important for scalability in
the management plane. Classifiers may also be cascaded in sequence
to perform more complex lookup operations whilst still maintaining
such scalability.
Another example of a packet attribute could be an integer
representing the BGP community string associated with the packet's
best-matching route. Other contextual information may also be used
by a Classifier (e.g., knowledge that a particular interface faces a
Diffserv domain or a legacy IP TOS domain [DSARCH] could be used when
determining whether a DSCP is present or not).
unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC
+------------+
Figure 3. An Example Classifier
The following BA classifier separates traffic into one of three
output streams based on matching filters:
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Where the filters are defined to be the following BA filters
([DSARCH], Section 4.2.1):
Filter DSCP
------ ------
Filter1 101010
Filter2 111111
Filter3 ****** (wildcard)
4.1.1. Filters
A filter consists of a set of conditions on the component values of a
packet's classification key (the header values, contents, and
attributes relevant for classification). In the BA classifier
example above, the classification key consists of one packet header
field, the DSCP, and both Filter1 and Filter2 specify exact-match
conditions on the value of the DSCP. Filter3 is a wildcard default
filter which matches every packet, but which is only selected in the
event that no other more specific filter matches.
In general there are a set of possible component conditions including
exact, prefix, range, masked and wildcard matches. Note that ranges
can be represented (with less efficiency) as a set of prefixes and
that prefix matches are just a special case of both masked and range
matches.
In the case of a MF classifier, the classification key consists of a
number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example below
for a IPv4/TCP classifier:
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address and
the source TCP port are wildcard or "don't care".
MF classification of IP-fragmented packets is impossible if the
filter uses 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
Note that it is easy to define sets of overlapping filters in a
classifier. For example:
Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- --------------
Filter5 172.31.8.X/24 X/0
Filter6 X/0 172.30.10.1/32
A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr
172.30.10.1} 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. Such precedence mechanisms must be
supported in any translation of this model into specific syntax for
configuration and management protocols.
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.
An unambiguous classifier requires that every possible classification
key match at least one filter (possibly the wildcard default) and
that any ambiguity between overlapping filters be resolved by
precedence. 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.
This model of classifier operation makes the assumption that all
filters of the same precedence be applied simultaneously. Whilst
convenient from a modeling point-of-view, this may or may not be how
the classifier is actually implemented - this assumption is not
intended to dictate how the implementation actually handles this,
merely to clearly define the required end result.
4.2. Examples
4.2.1. Behavior Aggregate (BA) Classifier
The simplest Diffserv classifier is a behavior aggregate (BA)
classifier [DSARCH]. A BA classifier uses only the Diffserv
codepoint (DSCP) in a packet's IP header to determine the logical
output stream to which the packet should be directed. We allow only
an exact-match condition on this field because the assigned DSCP
values have no structure, and therefore no subset of DSCP bits are
significant.
The following defines a possible BA filter:
Filter8:
Type: BA
Value: 111000
4.2.2. Multi-Field (MF) Classifier
Another type of classifier is a multi-field (MF) classifier [DSARCH].
This classifies packets based on one or more fields in the packet
(possibly including the DSCP). A common type of MF classifier is a
6-tuple classifier that classifies based on six fields from the IP
and TCP or UDP headers (destination address, source address, IP
protocol, source port, destination port, and DSCP). MF classifiers
may classify on other fields such as MAC addresses, VLAN tags, link-
layer traffic class fields, or other higher-layer protocol fields.
The following defines a possible MF filter:
Filter9:
Type: IPv4-6-tuple
IPv4DestAddrValue: 0.0.0.0
IPv4DestAddrMask: 0.0.0.0
IPv4SrcAddrValue: 172.31.8.0
IPv4SrcAddrMask: 255.255.255.0
IPv4DSCP: 28
IPv4Protocol: 6
IPv4DestL4PortMin: 0
IPv4DestL4PortMax: 65535
IPv4SrcL4PortMin: 20
IPv4SrcL4PortMax: 20
A similar type of classifier can be defined for IPv6.
4.2.3. Free-form Classifier
A Free-form classifier is made up of a set of user definable
arbitrary filters each made up of {bit-field size, offset (from head
of packet), mask}:
Classifier2:
Filter12: OutputA
Filter13: OutputB
Default: OutputC
Filter12:
Type: FreeForm
SizeBits: 3 (bits)
Offset: 16 (bytes)
Value: 100 (binary)
Mask: 101 (binary)
Filter13:
Type: FreeForm
SizeBits: 12 (bits)
Offset: 16 (bytes)
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
Free-form filters can be combined into filter groups to form very
powerful filters.
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:
Filter14 AND Filter15: OutputA
Default: OutputB
Filter14: -- priority 4 or 5
Type: Ieee8021pPriority
Value: 100 (binary)
Mask: 110 (binary)
Filter15: -- VLAN 2304
Type: Ieee8021QVlan
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
Such classifiers may be the subject of other standards or may be
proprietary to a router vendor but they are not discussed further
here.
5. Meters
Metering 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 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, by counting conforming and/or non-conforming traffic
using a Counter element downstream of the Meter, it might also be
used to help in collecting data for out-of-band management functions
such as billing applications.
Meters are logically 1:N (fan-out) devices (although a multiplexor
can be used in front of a meter). Meters are parameterized by a
temporal profile and by conformance levels, each of which is
associated with a meter's output. Each output can be connected to
another functional element.
Note that this model of a meter differs slightly from that described
in [DSARCH]. In that description the meter is not a datapath element
but is instead used to monitor the traffic stream and send control
signals to action elements to dynamically modulate their behavior
based on the conformance of the packet. This difference in the
description does not change the function of a meter. Figure 4
illustrates a meter with 3 levels of conformance.
In some Diffserv examples (e.g., [AF-PHB]), three levels of
conformance are discussed in terms of colors, with green representing
conforming, yellow representing partially conforming and red
representing non-conforming. These different conformance levels may
be used to trigger different queuing, marking or dropping treatment
later on in the processing. Other example meters use a binary notion
of conformance; in the general case N levels of conformance can be
supported. In general there is no constraint on the type of
functional datapath element following a meter output, but care must
be taken not to inadvertently configure a datapath that results in
packet reordering that is not consistent with the requirements of the
relevant PHB specification.
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
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 of potential results (two or
more): a given packet is said to be "conformant" to a level of the
meter if, at the time that the packet is being examined, the stream
appears to be within the rate limit for the profile associated with
that level. A fuller discussion of conformance to meter profiles
(and the associated requirements that this places on the schedulers
upstream) is provided in Appendix A.
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:
Meter1:
Type: AverageRate
Profile: Profile1
ConformingOutput: Queue1
NonConformingOutput: Counter1
Profile1:
Type: AverageRate
AverageRate: 120 kbps
Delta: 100 msec
A Meter measuring against this profile would continually maintain a
count that indicates the total number and/or cumulative byte-count of
packets arriving between time T (now) and time T - 100 msecs. So
long as an arriving packet does not push the count over 12 kbits in
the last 100 msec, the packet would be deemed conforming. Any packet
that pushes the count over 12 kbits would be deemed non-conforming.
Thus, this Meter deems packets to correspond to one of two
conformance levels: conforming or non-conforming, and sends them on
for the appropriate subsequent treatment.
5.1.2. Exponential Weighted Moving Average (EWMA) Meter
The EWMA form of Meter is easy to implement in hardware and can be
parameterized as follows:
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta
For a packet arriving at time t:
if (avg_rate(t) > AverageRate)
non-conforming
else
conforming
"Gain" controls the time constant (e.g., frequency response) of what
is essentially a simple IIR low-pass filter. "Rate(t)" measures the
number of incoming bytes in a small fixed sampling interval, Delta.
Any packet that arrives and pushes the average rate over a predefined
rate AverageRate is deemed non-conforming. An EWMA Meter profile
might look something like the following:
Meter2:
Type: ExpWeightedMovingAvg
Profile: Profile2
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Profile2:
Type: ExpWeightedMovingAvg
AverageRate: 25 kbps
Delta: 10 usec
Gain: 1/16
5.1.3. Two-Parameter Token Bucket Meter
A more sophisticated Meter might measure conformance to a token
bucket (TB) profile. A TB profile generally has two parameters, an
average token rate, R, and a burst size, B. TB Meters compare the
arrival rate of packets to the average rate specified by the TB
profile. Logically, tokens accumulate in a bucket at the average
rate, R, up to a maximum credit which is the burst size, B. When a
packet of length L arrives, a conformance test is applied. There are
at least two such tests in widespread use:
Strict conformance
Packets of length L bytes are considered conforming only if there
are sufficient tokens available in the bucket at the time of
packet arrival for the complete packet (i.e., the current depth is
greater than or equal to L): no tokens may be borrowed from future
token allocations. For examples of this approach, see [SRTCM] and
[TRTCM].
Loose conformance
Packets of length L bytes are considered conforming if any tokens
are available in the bucket at the time of packet arrival: up to L
bytes may then be borrowed from future token allocations.
Packets are allowed to exceed the average rate in bursts up to the
burst size. For further discussion of loose and strict conformance
to token bucket profiles, as well as system and implementation
issues, see Appendix A.
A two-parameter TB meter has exactly two possible conformance levels
(conforming, non-conforming). Such a meter might appear as follows:
Meter3:
Type: SimpleTokenBucket
Profile: Profile3
ConformanceType: loose
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Profile3:
Type: SimpleTokenBucket
AverageRate: 200 kbps
BurstSize: 100 kbytes
5.1.4. Multi-Stage Token Bucket Meter
More complicated TB meters might define multiple burst sizes and more
conformance levels. Packets found to exceed the larger burst size
are deemed non-conforming. Packets found to exceed the smaller burst
size are deemed partially-conforming. Packets exceeding neither are
deemed conforming. Some token bucket meters designed for Diffserv
networks are described in more detail in [SRTCM, TRTCM]; in some of
these references, three levels of conformance are discussed in terms
of colors with green representing conforming, yellow representing
partially conforming, and red representing non-conforming. Note that
these multiple-conformance-level meters can sometimes be implemented
using an appropriate sequence of multiple two-parameter TB meters.
A profile for a multi-stage TB meter with three levels of conformance
might look as follows:
Meter4:
Type: TwoRateTokenBucket
ProfileA: Profile4
ConformanceTypeA: strict
ConformingOutputA: Queue1
ProfileB: Profile5
ConformanceTypeB: strict
ConformingOutputB: Marker1
NonConformingOutput: AbsoluteDropper1
Profile4:
Type: SimpleTokenBucket
AverageRate: 100 kbps
BurstSize: 20 kbytes
Profile5:
Type: SimpleTokenBucket
AverageRate: 100 kbps
BurstSize: 100 kbytes
5.1.5. Null Meter
A null meter has only one output: always conforming, and no
associated temporal profile. Such a meter is useful to define in the
event that the configuration or management interface does not have
the flexibility to omit a meter in a datapath segment.
Meter5:
Type: NullMeter
Output: Queue1
6. Action Elements
The classifiers and meters described up to this point are fan-out
elements which are generally used to determine the appropriate action
to apply to a packet. The set of possible actions that can then be
applied include:
- Marking
- Absolute Dropping
- Multiplexing
- Counting
- Null action - do nothing
The corresponding action elements are described in the following
sections.
6.1. DSCP Marker
DSCP Markers are 1:1 elements which set a codepoint (e.g., the DSCP
in an IP header). DSCP 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 PHB treatment in downstream
nodes of a network and possibly also in subsequent processing stages
within this router.
DSCP Markers for Diffserv are normally parameterized by a single
parameter: the 6-bit DSCP to be marked in the packet header.
Marker1:
Type: DSCPMarker
Mark: 010010
6.2. Absolute Dropper
Absolute Droppers simply discard packets. There are no parameters
for these droppers. Because this Absolute Dropper is a terminating
point of the datapath and has no outputs, it is probably desirable to
forward the packet through a Counter Action first for instrumentation
purposes.
AbsoluteDropper1:
Type: AbsoluteDropper
Absolute Droppers are not the only elements than can cause a packet
to be discarded: another element is an Algorithmic Dropper element
(see Section 7.1.3). However, since this element's behavior is
closely tied the state of one or more queues, we choose to
distinguish it as a separate functional datapath element.
6.3. Multiplexor
It is occasionally necessary to multiplex traffic streams into a
functional datapath element with a single input. A M:1 (fan-in)
multiplexor is a simple logical device for merging traffic streams.
It is parameterized by its number of incoming ports.
Mux1:
Type: Multiplexor
Output: Queue2
6.4. Counter
One passive action is to account for the fact that a data packet was
processed. The statistics that result might be used later for
customer billing, service verification or network engineering
purposes. Counters are 1:1 functional datapath elements which update
a counter by L and a packet counter by 1 every time a L-byte sized
packet passes through them. Counters can be used to count packets
about to be dropped by an Absolute Dropper or to count packets
arriving at or departing from some other functional element.
Counter1:
Type: Counter
Output: Queue1
6.5. Null Action
A null action has one input and one output. The element performs no
action on the packet. Such an element is useful to define in the
event that the configuration or management interface does not have
the flexibility to omit an action element in a datapath segment.
Null1:
Type: Null
Output: Queue1
7. Queuing Elements
Queuing elements modulate the transmission of packets belonging to
the different traffic streams and determine 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
queuing block is being used to alter the temporal properties of a
traffic stream (i.e., shaping). Packets are discarded for one of the
following reasons:
- 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