draft-ietf-diffserv-model-00.txt   draft-ietf-diffserv-model-01.txt 
Differentiated Services Y. Bernet Internet Engineering Task Force Y. Bernet
Internet Draft Microsoft Diffserv Working Group Microsoft
Expires December 1999 A. Smith INTERNET-DRAFT A. Smith
draft-ietf-diffserv-model-00.txt Extreme Networks Expires: April 2000 Extreme Networks
S. Blake S. Blake
Ericsson Datacom Ericsson
October 1999
A Conceptual Model for Diffserv Routers A Conceptual Model for Diffserv Routers
draft-ietf-diffserv-model-01.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 provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet- Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material 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 The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt.
Draft Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Diffserv working group. Comments
on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This draft proposes a conceptual model for use in the management of This draft proposes a conceptual model of Differentiated Services
Differentiated Services (diffserv) routers. We describe the (Diffserv) routers for use in their management and configuration.
fundamental packet classification principles that allow traffic This model defines the general functional datapath elements
streams to be differentiated. We describe the fundamental traffic (classifiers, meters, markers, droppers, monitors, mirrors, muxes,
conditioning elements that comprise the traffic conditioning queues), their possible configuration parameters, and how they might
functionality of diffserv routers. We describe the fundamental queue be interconnected to realize the range of classification, traffic
elements that comprise the Per-Hop Behaviour (PHB) functionality of conditioning, and per-hop behavior (PHB) functionalities described in
diffserv routers. We propose a formal model for these. We also [DSARCH]. The model is intended to be abstract and capable of
describe parameters and variables that may be used for monitoring representing the configuration parameters important to Diffserv
the operation of the elements described above. There is no attempt functionality for a variety of specific router implementations. It
made to define the packet forwarding behaviours of diffserv routers
- these are well described elsewhere in the literature.
Bernet, Smith, Blake expires December, 1999 1 Bernet, et. al. Expires: April 2000 [page 1]
This draft is preliminary and is known to be inconsistent in some is not intended as a guide to hardware implementation.
respects with [DSMIB]. It is intended to correct this prior to the
next version, as well as to verify full consistency with the This model should serve as a rationale for the design of a Diffserv
published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB], MIB [DSMIB], as well for various configuration interfaces (such as
[EF-PHB]. [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
2. Glossary .................................................... 4
3. Conceptual Model ............................................. 6
3.1 Elements of a Diffserv Router ............................. 6
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 Mirroring Element ......................................... 20
6.5 Multiplexor ............................................... 20
6.6 Enqueueing Element ........................................ 20
6.7 Monitor ................................................... 21
6.8 Null Action ............................................... 21
7. Queues ....................................................... 21
7.1 Queue Sets and Scheduling ................................. 21
7.2 Shaping ................................................... 23
8. Traffic Conditioning Blocks (TCBs) ........................... 23
8.1 An Example TCB ............................................ 24
Bernet, et. al. Expires: April 2000 [page 2]
8.2 An Example TCB to Support Multiple Customers .............. 27
8.3 TCBs Supporting Microflow-based Services .................. 28
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, DSFWK] is a set of Differentiated Services (Diffserv) [DSARCH] is a set of technologies
technologies by which network service providers can offer differing which allow network service providers to offer differing levels of
levels of network quality-of-service (QoS) to different customers network quality-of-service (QoS) to different customers and their
and their traffic streams. The premise of diffserv networks is that traffic streams. The premise of Diffserv networks is that routers
routers within the networks handle packets in different traffic within the core of the network handle packets in different traffic
streams by applying different per-hop behaviours (PHBs) to the streams by forwarding them using different per-hop behaviors (PHBs).
packet forwarding. The PHB to be applied is indicated by a diffserv The PHB to be applied is indicated by a Diffserv codepoint (DSCP) in
code-point (DSCP) in the IP header of each packet [DSFIELD]. Note the IP header of each packet [DSFIELD]. Note that this document
that this document uses the terminology of [DSFWK]. uses the terminology defined in [DSARCH, DSTERMS] and in Sec. 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 behaviour aggregates (BA) aggregated to one of a small number of behavior aggregates (BA)
which are each forwarded using the same PHB at the router, thereby which are each forwarded using the same PHB at the router, thereby
simplifying the processing and associated storage. In addition, simplifying the processing and associated storage. In addition,
there is no signaling, other than what is carried in the DSCP of 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 each packet, and no other related processing that is required in the
diffserv network since QoS is invoked on a packet-by-packet basis. core of the Diffserv network since QoS is invoked on a packet-by-
packet basis.
Although diffserv itself does not define the services that a The Diffserv architecture enables a variety of possible services
diffserv network can provide, its successful deployment depends on which could be deployed in a network. These services are reflected
the ability to use the technology to provide services. These to customers at the edges of the Diffserv network in the form of a
services are reflected to customers at the edges of the diffserv Service Level Specification (SLS) [DSTERMS]. The ability to provide
network in the form of a Service Level Specification (SLS) [DSFWK]. these services depends on the availability of cohesive management and
The ability to provide these services depends on the availability of configuration tools that can be used to provision and monitor a set
cohesive management tools that can be used to provision and monitor of Diffserv routers in a coordinated manner. To facilitate the
a set of diffserv routers in a coordinated manner. To facilitate the development of such configuration and management tools it is helpful
development of such 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 implementation away implementation details of particular Diffserv routers from the
details of diffserv routers from the management tools used to manage parameters of interest for configuration and management. The purpose
them. The purpose of this draft is to define this conceptual model. of this draft is to define such a model.
The basic forwarding functionality of a diffserv router is defined The basic forwarding functionality of a Diffserv router is defined in
by other specifications e.g. [DSARCH], [DSFIELD], [AF-PHB], [EF- other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
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
implementations of diffserv routers. We expect that router vendors the implementation alternatives of Diffserv routers. We expect that
will demonstrate a great deal of variability in their router vendors will demonstrate a great deal of variability in their
implementations. To the extent that vendors are able to model their implementations. To the extent that vendors are able to model their
implementations using the abstractions described in this draft, implementations using the abstractions described in this draft,
management tools will more readily be able to manage networks configuration and management tools will more readily be able to
incorporating diffserv routers of various implementations. configure and manage networks incorporating Diffserv routers of
2. Organization of this Document Bernet, et. al. Expires: April 2000 [page 3]
various implementations.
In Sec. 3 we start by describing the basic high-level functional
elements of a Diffserv router and then describe the various
components. We then focus on the Diffserv-specific components of
the router and describe a hierarchical management model for these.
Bernet, Smith, Blake expires December, 1999 2 In Sec. 4 we describe classification elements and in Sec. 5, we
In Section 3 we start by describing the basic high-level functional discuss the meter elements.
blocks of a diffserv router and then providing a block diagram and
describe the various components. We then focus on the diffserv-
specific components of the router and describe a hierarchical
management model for these.
In Section 4 we describe classification elements and in section 5, In Sec. 6 we discuss action elements. In Sec. 7 we discuss the
we discuss the basic traffic conditioning elements. basic queueing elements and their functional behaviors (e.g.,
shaping).
In Section 6, we show how the basic classification and traffic In Sec. 8, we show how the basic classification, meter, action, and
conditioning elements can be combined to build modules called queueing elements can be combined to build modules called Traffic
Traffic Conditioning Blocks (TCBs). Conditioning Blocks (TCBs).
In Section 7, we discuss the basic queuing components. In Sec. 9 we discuss open issues with this document and in Sec. 10 we
discuss security concerns.
In Section 8, we discuss those parameters that it must be possible Appendix A discusses token bucket implementation details.
to monitor for the purposes of managing a diffserv router.
3. Elements of a Diffserv Router 2. Glossary
In this section we introduce a block diagram of a diffserv router Some of the terms used in this draft are defined in [DSARCH] and in
and describe the various components illustrated. Note that the [DSTERMS]. We define a few of them here again only to provide
functions of a diffserv core router are likely to be a much additional detail.
simplified set of these components: the model we present here is
intended to cover the case of a diffserv edge router as well as the
core.
3.1 Conceptual Model 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.
The conceptual model we define includes abstract definitions of the Classifier A functional datapath element which consists of filters
which select packets based on the content of packet
headers or other packet data, and/or on implicit or
derived attributes associated with the packet, and
forwards the packet along a particular datapath within
the router. A classifier splits a single incoming
traffic stream into multiple outgoing ones.
Enqueueing The process of executing a buffer management algorithm
to determine whether an arriving packet should be
stored in a queue.
Filter A set of (wildcard/prefix/masked/range/exact)
conditions on the components of a packet's
classification key. A filter is said to match only if
each condition is satisfied.
Bernet, et. al. Expires: April 2000 [page 4]
Mirroring 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 increments 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
(Mux) traffic streams (datapaths) into a single traffic
stream (datapath).
Non-work A property of a scheduling algorithm such that it does
conserving not necessarily service a packet if available at every
transmission opportunity.
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
algorithm and which may share a buffer management
algorithm.
Scheduling An algorithm which determines which queue of a queue
algorithm set to service next. This may be based on the relative
priority of the queues, or on a weighted fair bandwidth
sharing policy, or some other policy. A scheduling
algorithm may be either work-conserving or non-work-
conserving.
Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined traffic profile.
Shaping can be implemented using a queue serviced by a
non-work conserving scheduling algorithm.
Traffic A logical datapath element consisting of a number of
Conditioning other 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 a "black box" with a single
input and output.
Bernet, et. al. Expires: April 2000 [page 5]
Work A property of a scheduling algorithm such that it
conserving services a packet if available at every transmission
opportunity.
3. Conceptual Model
In this section we introduce a block diagram of a Diffserv router and
describe the various components illustrated. Note that a Diffserv
core router is assumed to include only a subset of these components:
the model we present here is intended to cover the case of both
Diffserv edge and core routers.
3.1 Elements of a Diffserv Router
The conceptual model we define includes abstract definitions for the
following: following:
1. The basic traffic classification components. o The basic traffic classification components.
2. The basic traffic conditioning components.
3. Certain combinations of traffic conditioning components.
4. Queuing components.
The components and combinations of components described in this o The basic traffic conditioning components.
document form building blocks that need to be manageable by
diffserv management tools. One of the goals of this document is to
show how a model of a diffserv device can be built up out of these
component blocks. This model is in the form of a connected acyclic
directional graph that describes the traffic conditioning behaviour
that any particular data packet will experience when submitted to
the diffserv router.
It is anticipated that these building blocks may also be used as o Certain combinations of traffic classification and conditioning
the basis for a diffserv MIB or other such specific device components.
configuration mechanisms.
Bernet, Smith, Blake expires December, 1999 3 o Queueing components.
3.2 Block Diagram 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 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: April 2000 [page 6]
| diffserv | +---------------+
| Diffserv |
Mgmt | configuration| Mgmt | configuration|
<------>| & monitoring |---------------- <----+-->| & management |------------------+
SNMP,| | interface | | SNMP,| | interface | |
COPS | +--------------+ | COPS | +---------------+ |
etc. | | | etc. | | |
| | | | | |
| v v | v v
| +----------+ +-------+ +---------+ +-------+ | +-------------+ +---------+ +-------------+
data | |ingress | |routing| |egress | |queuing| data | | ingress i/f | | | | egress i/f |
------->|-classif. |-->| |-->|-classif.|-->| stuff |--> -------->| class., |-->| routing |-->| class., |---->
| |-TCB | +-------+ |-TCB | +-------+ | | TC, | | core | | TC, |
| +----------+ +---------+ | | queueing | | | | queueing |
| +-------------+ +---------+ +-------------+
| ^ ^ | ^ ^
| | | | | |
| +----------+ | | | |
-->| | | | +------------+ |
------->| RSVP |-------------------- +-->| RSVP | |
RSVP |(optional)| -------->| (optional) |---------------------+
cntl +----------+ RSVP +------------+
cntl
msgs msgs
In this diagram, a Traffic Conditioning Block (TCB) represents a Figure 1: Diffserv Router Major Functional Blocks
combination of metering, marking, shaping, dropping elements that
are discussed in more detail below.
3.2.1 Interfaces, Classification, Traffic Conditioning, Queuing and the 3.1.1 Datapath
Routing Core
An ingress interface, routing component and egress interface are An ingress interface, routing core, and egress interface are
illustrated at the center of the diagram. In actual router illustrated at the center of the diagram. In actual router
implementations, there may be an arbitrary number of inbound and implementations, there may be an arbitrary number of ingress and
outbound interfaces interconnected by the routing core. The egress interfaces interconnected by the routing core. The routing
components of interest on these interfaces are the traffic core element serves as an abstraction of a router's normal routing
classifiers, the traffic conditioning components (TC) and the and switching functionality. The routing core moves packets between
queuing components that support the Per-Hop Behaviour (PHB) interfaces according to policies outside the scope of Diffserv. The
[DSARCH]. These are the fundamental components comprising a diffserv actual queueing delay and packet loss behavior of a specific router's
router and will be the focal point of our conceptual model. 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.
3.2.2 Diffserv Configuration and Monitoring Interface The components of interest on the ingress/egress interfaces are the
traffic classifiers, traffic conditioning (TC) components, and the
queueing components that support Diffserv traffic conditioning and
per-hop behaviors [DSARCH]. These are the fundamental components
comprising a Diffserv router and will be the focal point of our
conceptual model.
Bernet, et. al. Expires: April 2000 [page 7]
3.1.2 Configuration and Management Interface
Diffserv operating parameters are monitored and provisioned through Diffserv operating parameters are monitored and provisioned through
this interface. Monitored parameters include statistics regarding this interface. Monitored parameters include statistics regarding
traffic carried at various diffserv service levels. These statistics traffic carried at various Diffserv service levels. These statistics
are important for accounting purposes and for tracking compliance to may be important for accounting purposes and/or for tracking
service level agreements (SLAs [DSARCH]) negotiated with customers. compliance to traffic conditioning specifications (TCSs) [DSTERMS]
negotiated with customers. Provisioned parameters are primarily
Bernet, Smith, Blake expires December, 1999 4 classification rules, TC and PHB configuration parameters. The
Provisioned parameters are primarily classification rules, PHB and network administrator interacts with the Diffserv configuration and
TC configuration parameters. The network administrator interacts management interface via one or more management protocols, such as
with the diffserv configuration and monitoring interface via one or SNMP or COPS, or through other router configuration tools such as
more management protocols, such as SNMP or COPS [COPS] or through serial terminal or telnet consoles.
other router configuration tools such as serial terminal or telnet
consoles.
3.2.3 Optional RSVP Module 3.1.3 Optional RSVP 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]. The example
discussed here uses the RSVP protocol. Snooping of RSVP messages may discussed here uses the RSVP protocol. Snooping of RSVP messages may
be used, for example, to learn how to classify traffic without be used, for example, to learn how to classify traffic without
actually participating as a RSVP protocol peer. Diffserv routers may actually participating as a RSVP protocol peer. Diffserv routers may
reject or admit RSVP reservation requests to provide a means of reject or admit RSVP reservation requests to provide a means of
admission control to diffserv-based services or they may use these admission control to Diffserv-based services or they may use these
requests to trigger provisioning changes for a flow-aggregation in requests to trigger provisioning changes for a flow-aggregation in
the diffserv network. A flow-aggregation in this context might be the Diffserv network. A flow-aggregation in this context might be
equivalent to a diffserv BA or it may be more fine-grained, relying equivalent to a Diffserv BA or it may be more fine-grained, relying
on a MF classifier. Note that the conceptual model of such a router on a MF classifier [DSARCH]. Note that the conceptual model of such
starts to look the same as a Integrated Services (intserv) router in a router starts to look the same as a Integrated Services (intserv)
its component makeup [E2E]. router in its component makeup [E2E].
Note that a RSVP component of a diffserv router, if present, might Note that a RSVP 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 scenario, RSVP is used strictly as a signaling protocol. The this scenario, RSVP is used strictly as a signaling protocol. The
data plane of such a diffserv router can still act purely on data plane of such a Diffserv router can still act purely on Diffserv
diffserv DSCPs and PHBs in handling data traffic. DSCPs and PHBs in handling data traffic.
3.3 Hierarchical Model of Diffserv Components 3.2 Hierarchical Model of Diffserv Components
We focus on the diffserv specific functional components of the We focus on the Diffserv specific functional components of the
router, the traffic conditioning and queuing functionality. The router: the classification, traffic conditioning, and queueing
example below is based on the larger block diagram shown above: functionality. The diagram below is based on the larger block
diagram shown above:
Bernet, et. al. Expires: April 2000 [page 8]
Interface A Interface B Interface A Interface B
+------------+ +-------+ +------------+ +-------------+ +---------+ +-------------+
------->| ingress |---->| |---->| egress |---> | ingress i/f | | | | egress i/f |
|(class.,TC) | | | |(queuing,TC)| | class., | | | | class., |
+------------+ |routing| +------------+ --->| meter, |---->| |---->| meter, |--->
| | | action, | | | | action, |
+------------+ | | +------------+ | queueing | | | | queueing |
<-------| egress |<----| |<----| ingress |<--- +-------------+ | routing | +-------------+
|(queuing,TC)| +-------+ |(class.,TC) | | core |
+------------+ +------------+ +-------------+ | | +-------------+
| egress i/f | | | | ingress i/f |
Figure 1 - Traffic Conditioning and Queuing | class., | | | | class., |
<---| meter, |<----| |<----| meter, |<---
This diagram illustrates two diffserv router interfaces, each having | action, | | | | action, |
an ingress and an egress component. It shows classification and TC | queueing | +---------+ | queueing |
components on each interface's ingress and it shows both TC and PHB +-------------+ +-------------+
components on each interface's egress. From a management
perspective, the following hierarchy exists:
Bernet, Smith, Blake expires December, 1999 5
At the top level, the router manager manages interfaces. Each
interface consists of an ingress component and an egress component.
An ingress component contains TC components. An egress component
contains PHB components and TC components. (There may be special
cases in which a router implements PHB components on an ingress
interface. This model is readily extensible to reflect such an
implementation. However, we have chosen not to do so in this case.)
The TC components on each interface are described by a traffic Figure 2. Traffic Conditioning and Queueing Elements
conditioning table (TCT) corresponding to the interface. The TCT
describes traffic classification and conditioning elements and how
they are combined to provide the interface's traffic conditioning
functionality. Certain traffic conditioning elements may be grouped
into traffic conditioning blocks (TCBs).
PHB components contain queues and the enqueuing and dequeuing This diagram illustrates two Diffserv router interfaces, each having
algorithms that serve them. Queues are each independently an ingress and an egress component. It shows classification, meter,
parameterized. There may also be parameters defining relationships action, and queueing elements which might be instantiated on each
between PHBs. interface's ingress and egress component. The TC functionality is
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.
4. Classification Elements From a configuration and management perspective, the following
hierarchy exists:
Classification is a necessary function for any device that treats At the top level, the network administrator manages interfaces. Each
certain traffic differently from other traffic. The very nature of a interface consists of an ingress component and an egress component.
diffserv router is that it treats traffic differentially. Therefore, Each component may contain classifier, action, meter, and queueing
classification is the most basic function required from a elements.
differentiated service router.
Classification is performed by a classifier. Classifiers take a Bernet, et. al. Expires: April 2000 [page 9]
single traffic stream as input and generate logically separate At the next level, the network administrator manages groups of
traffic streams as output. Packets from the input stream are sorted functional elements interconnected in a DAG. These elements are
into various output streams depending on the contents of the packet organized in self-contained Traffic Conditioning Blocks (TCBs) which
and possibly on other sources of information e.g. input sub-channel are used to implement some desired network policy (see Sec. 8). One
number. The various types of classifiers are described in the or more TCBs may be instantiated on each ingress or egress component,
following sections. may be connected in series, and/or may be connected in a
parallel configuration on the multiple outputs of a classifier.
We define the TCB to optionally include classification and queueing
elements so as to allow for rich functionality. A TCB can be thought
of as a "black box" with a single input and a single output (on the
main data path). TCBs can be constructed out of a DAG of other TCBs,
recursively. We do not assume the same TCB configuration on every
interface (ingress or egress).
4.1 Behaviour Aggregate (BA) Classifier At the lowest level are individual functional elements, each with
their own configuration parameters and management counters and flags.
The simplest diffserv classifier is a behaviour aggregate (BA) 4. Classifiers
classifier. 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.
4.2 Multi-Field (MF) Classifier 4.1 Definition
Another type of classifier is a multi-field (MF) classifier. This Classification is performed by a classifier element. Classifiers are
classifies packets based on one or more fields in the packet header 1:N (fan-out) devices: they take a single traffic stream as input and
other than the DSCP. A common type of MF classifier is a 5-tuple generate N logically separate traffic streams as output. Classifiers
classifier that classifies based on the five IP header fields of are parameterized by filters and output streams. Packets from the
source/destination address, source/destination port and IP protocol input stream are sorted into various output streams by filters which
number. MF classifiers may classify based on other fields such as match the contents of the packet or possibly match other attributes
associated with the packet. Various types of classifiers are
described in the following sections.
Bernet, Smith, Blake expires December, 1999 6 We use the following diagram to illustrate a classifier, where the
MAC addresses, VLANs, link-layer traffic class or other higher layer outputs connect to succeeding functional elements:
protocol addresses.
4.3 Other Classifier Types unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> output A
------->| classifier |--> match Filter2 --> output B
| |--> no match --> output C
+------------+
Classification may be performed based on implicit information Figure 3. An Example Classifier
associated with a packet (e.g. the incoming channel number on a
channelized interface) or on information derived from a different
classification operation (e.g. the outgoing interface determined by
the route lookup operation). We do not discuss these further here.
4.4 Filters Note that we allow a mux (see Sec. 6.5) before the classifier to
allow input from multiple traffic streams. For example, if multiple
ingress sub-interfaces feed through a single classifier then the
interface number can be considered by the classifier as a packet
attribute and be included in the packet's classification key. This
optimization may be important for scalability in the management
plane. Another possible packet attribute could be an integer
representing the BGP community string associated with the packet's
best-matching route.
Classifiers are parameterized by filters and output streams. For The following classifier separates traffic into one of three output
example, the following classifier separates traffic into one of streams based on three filters:
three output streams based on two filters:
Filter Matched Output Stream Filter Matched Output Stream
-------------- --------------- -------------- ---------------
1 A Filter1 A
2 B Filter2 B
no match C Filter3 (no match) C
Where filters 01 and 02 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 ):
Filter DSCP Filter DSCP
------ ------ ------ ------
1 101010 1 101010
2 111111 2 111111
3 ****** (wildcard)
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 classification key. In the BA classifier example above, the a packet's classification key (the header values, contents, and
classification key consists of one packet header field, the DSCP, attributes relevant for classification). In the BA classifier
and both Filter1 and Filter2 specify exact-match conditions on the example above, the classification key consists of one packet header
value of the DSCP. The third filter is a wildcard default filter field, the DSCP, and both Filter1 and Filter2 specify exact-match
which matches every packet, but which is only selected in the event conditions on the value of the DSCP. Filter3 is a wildcard default
that no other more specific filter matches. 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 whole set of possible component conditions In general there are a set of possible component conditions including
including exact, prefix, range, wildcard and masked matches. Note exact, prefix, range, masked, and wildcard matches. Note that ranges
that ranges can be represented (maybe less efficiently) as a set of can be represented (with less efficiency) as a set of prefixes and
prefix matches and that prefix matches are just a special case of that prefix matches are just a special case of both masked and range
masked matches. matches.
In the case of a MF classifier, the classification key consists of a In the case of a MF classifier [DSARCH], the classification key
number of packet header fields. The filter may specify a different consists of a number of packet header fields. The filter may
condition for each key component, as illustrated in the example specify a different condition for each key component, as illustrated
below for a TCP/IPv4 classifier: in the example below 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
------ ------------- ------------- ----------- ------------ ------ ------------- ------------- ----------- ------------
Filter1 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
Bernet, Smith, Blake expires December, 1999 7
In this example, the fourth octet of the destination IPv4 address In this example, the fourth octet of the destination IPv4 address
and the source TCP port are 'don't cares'. and the source TCP port are wildcard or "don't cares".
4.5 Diagram of a Classifier 4.1.2 Overlapping Filters
We use the following diagram to illustrate a classifier, where the Note that it is easy to define sets of overlapping filters in a
outputs are to be plumbed in to succeeding TC elements: classifier. For example:
unclassified classified Filter5: Filter6:
traffic traffic Type: Masked-DSCP Type: Masked-DSCP
----------- Value: 111000 Value: 000111 (binary)
| |--> match Filter1 --> output A Mask: 111000 Mask: 000111 (binary)
----->|classifer|--> match Filter2 --> output B
| |--> no match --> output C
-----------
Figure 2 - An Example Classifier 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.
Note that an input interface number can also be considered as an An unambiguous classifier requires that every possible classification
input to the classifier if the classifier is modeled as accepting key match at least one filter (including the wildcard default), and
packets from multiple input ports - this optimisation may be that any ambiguity between overlapping filters be resolved by
important for scalability in the management plane. precedence.
4.6 Formal Representation of Classifiers 4.1.3 Filter Groups
4.6.1 IPv4 5-tuple Classifier Filters may be logically combined. For example, consider the
following DestMacAddress filter:
The following formal definition can be used to represent a Filter7:
classifier using masked match conditions: Type: DestMacAddress
Value: 01-02-03-04-05-06
Mask: FF-FF-FF-FF-FF-FF
<Editorial Note: are masked matches sufficient? Do we need Classifier0 could then be declared as:
ranges here? Can we narrow it down even more to prefix match
conditions for some/all fields?>
Classifier0: Classifier0:
Filter1: output A Filter1 and Filter7: output A
Filter2: output B Filter2 and Filter7: output B
No Match: output C Default (wildcard) filter: output C
Filter1: Filter2:
Type: IPv4 5-tuple Type: IPv4 5-tuple
Ipv4SrcAddrValue: 172.31.8.0 Ipv4SrcAddrValue: 172.31.9.0
Ipv4DestAddrValue: 0 Ipv4DestAddrValue:0
Ipv4SrcPortValue: 0 Ipv4SrcPortValue: 0
Ipv4DestPortValue: 5003 Ipv4DestPortValue:5003
Ipv4ProtocolValue: 0 Ipv4ProtocolValue:0
Ipv4SrcAddrMask: 255.255.255.0 Ipv4SrcAddrMask: 255.255.255.0
Ipv4DestAddrMask: 0.0.0.0 Ipv4DestAddrMask: 0.0.0.0
Ipv4SrcPortMask: 0 Ipv4SrcPortMask: 0
Ipv4DestPortMask: 0xFFFF Ipv4DestPortMask: 0xFFFF
Ipv4ProtocolMask: 0 Ipv4ProtocolMask: 0
4.6.2 IPv6 5-tuple Classifier 4.2 Examples
Bernet, Smith, Blake expires December, 1999 8 4.2.1 Behaviour Aggregate (BA) Classifier
The following formal definition can be used to represent a IPv6
multi-field classifier using masked match conditions:
Classifier1: The simplest Diffserv classifier is a behavior aggregate (BA)
Filter3: output A classifier [DSARCH]. A BA classifier uses only the Diffserv
No Match: output B 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.
Filter3: The following defines a possible BA filter:
Type: IPv6 5-tuple
Ipv6SrcAddrValue: 0:0:0:0:0:FFFF:32.12.65.0
Ipv6SrcAddrMask: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0
Ipv6DestAddrValue: 1080:0:0:0:0:0:0:0
Ipv6DestAddrMask: FFFF:FFFF:FFFF:FFFF:0:0:0:0
Ipv6SrcPortValue: 0
Ipv6SrcPortMask: 0
Ipv6DestPortValue: 5003
Ipv6DestPortMask: 0xFFFF
Ipv6NextHeaderValue: 6
Ipv6NextHeaderMask: 0xFF
4.6.3 Behaviour Aggregate Classifier Filter8:
Type: BA
Value: 111000
A BA classifier is parameterised by a set of 6-bit DSCP {value, 4.2.2 Multi-Field (MF) Classifier
mask} pairs:
Classifier1: Another type of classifier is a multi-field (MF) classifier [DSARCH].
Filter3: output A This classifies packets based on one or more fields in the packet
Filter4: output B header (including the DSCP). A common type of MF classifier is a 6-
No Match: output C tuple classifier that classifies based on six IP header fields
(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.
Filter3: Filter4: The following defines a possible MF filter:
Type: BA Type: BA
Value: 111000 Value: 110000
Mask: 111111 Mask: 111111
<note: can IPv4 and IPv6 BA classifiers be modeled the same as each Filter9:
other?> Type: IPv4-6-tuple
IPv4DestAddrValue: 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
4.6.4 IEEE802 MAC Address Classifiers A similar type of classifier can be defined for IPv6.
A MacAddress classifier is parameterised by a 6-byte {value, mask} 4.2.3 IEEE802 MAC Address Classifier
pair for either source or destination MAC address.l 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:
Classifier2: A MacAddress filter is parameterized by a 6-byte {value, mask} pair
Filter5: output A for either source or destination MAC address. For example, the
Filter6: output A following classifier sends packets matching either DA =
No Match: output B 01-02-03-04-05-06 or SA = 00-E0-2B-XX-XX-XX to output A:
Filter5: Classifier1:
Filter10: output A
Filter11: output A
Default: output B
Filter10:
Type: DestMacAddress Type: DestMacAddress
Bernet, Smith, Blake expires December, 1999 9
Value: 01-02-03-04-05-06 (hex) Value: 01-02-03-04-05-06 (hex)
Mask: FF-FF-FF-FF-FF-FF (hex) Mask: FF-FF-FF-FF-FF-FF (hex)
Filter6: Filter11:
Type: SrcMacAddress Type: SrcMacAddress
DestValue: 00-E0-2B-00-00-00 (hex) DestValue: 00-E0-2B-00-00-00 (hex)
DestMask: FF-FF-FF-00-00-00 (hex) DestMask: FF-FF-FF-00-00-00 (hex)
4.6.5 Free-form Classifier 4.2.4 Free-form Classifier
A FreeForm classifier is made up of a set of user definable 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 arbitrary filters each made up of {bit-field size, offset (from head
of packet), mask}: of packet), mask}:
Classifier3: Classifier2:
Filter6: output A Filter12: output A
Filter7: output B Filter13: output B
No Match: output C Default: output C
Filter6: 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)
Filter7: 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)
4.6.6 Other Standard Classifiers Free-form filters can be combined into filter groups to form very
powerful filters.
e.g. IEEE802.1p, IEEE802.1Q VLAN-ID 4.2.5 Other Possible Classifiers
Classifier4: Classifier3:
Filter8: output A Filter14: output A
Filter9: output B Filter15: output B
No Match: output C Default: output C
Filter8: Filter14:
Type: IeeePriority Type: IEEEPriority
Value: 100 (binary) Value: 100 (binary)
Mask: 101 (binary) Mask: 101 (binary)
Filter15:
Filter9: Type: IEEEVLAN
Type: IeeeVlan
Value: 100100000000 (binary) Value: 100100000000 (binary)
Mask: 111111111111 (binary) Mask: 111111111111 (binary)
4.6.7 Vendor-Specific Classifier Classification may be performed based on implicit information
associated with a packet (e.g. the incoming channel number on a
Bernet, Smith, Blake expires December, 1999 10 channelized interface) or on information derived from a different
Other vendor specific filter formats. non-Diffserv classification operation (e.g. the outgoing interface
determined by the route lookup operation). Other vendor-specific
4.7 Combinations of Filters filter formats are possible. We do not discuss these further here.
Filters may be logically combined. For example, consider the
following DestMacAddress filter:
Filter3: 4.3 MPLS
Type: DestMacAddress
Value: 01-02-03-04-05-06
Mask: FF-FF-FF-FF-FF-FF
Classifier0 could then be declared as: It is possible for an MPLS label-switched router (LSR) to function as
a Diffserv router [MPLSDS]. In this case the IP header is not
visible for inspection and all header classification must be
performed on the MPLS label, and in the event of shim encapsulation,
on the 3-bit EXP field in addition. In general a MPLS classification
filter may specify either wildcard- or exact-match conditions for
either field (but not both wildcard at once). The distinction to be
drawn here is that MPLS labels are dynamically established and torn
down. An EXP-only classifier may be statically configured but a
label or label + EXP classifier must be established dynamically along
with the LSP. In all other respects (except marking) the labeled
packet can be treated identically to an unlabeled packet.
Classifier0: 5. Meters
Filter1 and Filter3: output A
Filter2 and Filter3: output B
No Match: output C
4.7.1 Conflicting Filters 5.1 Definition
Note that it is easy to define sets of conflicting filters in a Metering is the function of monitoring the arrival times of packets
classifier. For example: of a traffic stream and determining the level of conformance of each
packet to a pre-established traffic profile. 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, it might also be used for out-of-band
management functions like statistics monitoring for billing
applications.
Filter1: Filter2: Meters are logically 1:N (fan-out) devices (although a mux can be
Type: BA Type: BA used in front of a meter). Meters are parameterized by a temporal
Value: 111000 Value: 000111 (binary) profile and by conformance levels, each of which is associated with
Mask: 111000 Mask: 000111 (binary) a meter's output. Each output can be connected to another functional
element.
A packet containing the DSCP 111111 cannot be uniquely classified by Note that this model of a meter differs from that described in
this set of filters and so a precedence must be established between [DSARCH]. In that description the meter is not a datapath element
Filter1 and Filter2 in order to break the tie. This precedence must but is instead used to monitor the traffic stream and send control
be established either (a) by a manager which knows that the router signals to action elements to dynamically modulate their behavior
can accomplish this particular ordering e.g. by means of reported based on the conformance of the packet. We find the description here
capabilities or (b) by the router along with a mechanism to report more powerful.
to a manager which precedence is being used. These ordering
mechanisms must be supported by the management protocol although
further discussion of this is outside the scope of this document.
5. Traffic-Conditioning Elements We use the following diagram to illustrate a meter with 3 levels of
conformance:
Traffic-conditioning is a essential function of a diff-serv router, unmetered metered
defined in [DSARCH]. This section defines the elements that can be traffic traffic
combined to provide the traffic-conditioning functionality
described. These include meters and various action elements.
5.1 Meters +---------+
| |--------> conformanceA
--------->| meter |--------> conformanceB
| |--------> conformanceC
+---------+
Metering is the function of monitoring the arrival times of packets Figure 4. An Example Meter
on a traffic stream and determining the level of conformance of each
packet to a profile. Diffserv network providers may offer services
to customers based on a temporal profile within which the customer
Bernet, Smith, Blake expires December, 1999 11 In some Diffserv examples, three levels of conformance are discussed
submits traffic for the service. In this event, a meter might be in terms of colors, with green representing conforming, yellow
used to trigger real-time effects (e.g. marking) downstream; it representing partially conforming, and red representing non-
might also just be used for out-of-band management functions like conforming [AF-PHB]. These different conformance levels are used to
statistics monitoring and billing applications. trigger different buffer management actions. 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 element following a meter output, but care
must be taken not to inadvertently configure a datapath that results
in packet reordering within an OA.
Meters are parameterized by a temporal profile and by conformance 5.2 Examples
levels.
5.1.1 Types of Meters The following is a non-exhaustive list of possible meters.
5.1.1.1 Average Rate Meter 5.2.1 Average Rate Meter
An example of a very simple meter is an average rate meter. This An example of a very simple meter is an average rate meter. This
type of meter measures the average rate at which packets are type of meter measures the average rate at which packets are
submitted to it over a specified averaging time. submitted to it over a specified averaging time.
An average rate profile may take the following form: An average rate profile may take the following form:
Average Rate: 10 packets per second Meter1:
Averaging Interval: 1 second Type: AverageRate
Profile1: output A
NonConforming: output B
Profile1:
Type: AverageRate
AverageRate: 120 KBps
Delta: 1.0 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 (now) and time T-1 second. So long as an arriving packet does time T (now) and time T - 1.0 msecs. So long as an arriving packet
not push the count over 10, the packet would be deemed conforming. does not push the count over 120 bytes, the packet would be deemed
Any packet that pushes the count over 10, would be deemed non- conforming. Any packet that pushes the count over 120 would be
conforming. Thus, this meter deems packets to correspond to one of deemed non-conforming. Thus, this meter deems packets to correspond
two conformance levels - conforming or non-conforming. to one of two conformance levels: conforming or non-conforming.
5.1.1.2 Exponential Weighted Moving Average Meters 5.2.2 Exponential Weighted Moving Average (EWMA) Meter
The EWMA form of meter is easy to implement in silicon and can be The EWMA form of meter is easy to implement in hardware and can be
parameterised as follows: parameterized as follows:
avg(n+1) = (1-Gain) * avg(n) + Gain * actual(n+1) avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t(n+1) = t(n) + Delta t = t' + Delta
For a packet arriving at time t(m): For a packet arriving at time t:
if (avg(m) > 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. actual(n) and avg(n) essentially a simple IIR low-pass filter. rate(t) measures the
measure the number of incoming bytes in a small fixed sampling number of incoming bytes in a small fixed sampling interval, Delta.
interval, Delta. Any packet that arrives and pushes the average rate Any packet that arrives and pushes the average rate over a predefined
over a predefined rate AverageRate is deemed non-conforming. rate AverageRate is deemed non-conforming. An EWMA meter profile
might look as follows:
5.1.1.3 Token Bucket Meters
Bernet, Smith, Blake expires December, 1999 12
A more sophisticated meter might measure conformance to a token
bucket (TB) profile. A TB profile generally has three parameters, an
average rate, a peak rate and a burst size. TB meters compare the
arrival rate of packets to the average rate specified by the TB
profile. Logically, byte tokens accumulate in a bucket at the
average rate, up to a maximum credit which is the burst size.
Packets of length L bytes are considered conforming if L tokens are
available in the bucket at the time of packet arrival. Packets are
allowed to exceed the average rate in bursts up to the burst size,
so long as they do not exceed the peak rate, at which point the
bucket will be drained. Packets which arrive to find a bucket with
insufficient tokens in it are deemed non-conforming.
More complicated token bucket models might define two burst sizes
and three 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. Token bucket meters
designed for diff-serv networks are described in more detail in
[SRTCM], [TRTCM] and [GTC]: 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.
5.1.2 Diagram of a Meter
We use the following diagram to illustrate a meter with 3 levels of
conformance:
unmetered metered
traffic traffic
-----------
| |--------> conformanceA
--------->| meter |--------> conformanceB
| |--------> conformanceC
-----------
Figure 3 - An Example Meter
In some diffserv examples, three levels of conformance are discussed
in terms of colors, with green representing conforming, yellow
representing partially conforming and red representing non-
conforming. Other example meters use a binary notion of conformance;
in the general case there are 'N' levels of conformance.
5.1.3 Formal Representations of Meters
5.1.3.1 Simple Token Bucket Meter
The following formal definition can be used to represent this meter:
Meter1:
Bernet, Smith, Blake expires December, 1999 13
Type: SimpleTokenBucket
Profile1: output A
NonConforming: output B
Profile1:
Type: SimpleTokenBucket
AverageRate: 100 Kbps
PeakRate: 150 Kbps
BurstSize 100 Kb
5.1.3.2 EWMA Meter
Meter2: Meter2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
Profile2: output A Profile2: output A
NonConforming: output B NonConforming: output B
Profile2: Profile2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
AverageRate: 25 KBps
Delta: 10.0 usec
Gain: 1/16 Gain: 1/16
Delta: 10us
AverageRate: 200 Kbps
5.1.3.3 Two-level Token Bucket Meter 5.2.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, a burst size. TB meters compare the arrival
rate of packets to the average rate specified by the TB profile.
Logically, byte tokens accumulate in a bucket at the average rate,
up to a maximum credit which is the burst size. Packets of length
L bytes are considered conforming if L tokens are available in the
bucket at the time of packet arrival. Packets are allowed to
exceed the average rate in bursts up to the burst size. Packets
which arrive to find a bucket with insufficient tokens in it are
deemed non-conforming. A two-parameter TB meter has exactly two
possible conformance levels (conforming, non-conforming). TB
implementation details are discussed in Appendix A.
A two-parameter RB meter profile might look as follows:
Meter3: Meter3:
Type: TwoLevelTokenBucket Type: SimpleTokenBucket
Profile3: output A Profile3: output A
Profile4: output B NonConforming: output B
NonConforming: output C
Profile3: Profile3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 Kbps AverageRate: 100 KBps
PeakRate: 150 Kbps BurstSize: 100 KB
BurstSize 50 Kb
Profile4: 5.2.4 Multi-Stage Token Bucket Meter
Type: SimpleTokenBucket
AverageRate: 120 Kbps
PeakRate: 150 Kbps
BurstSize 100 Kb
5.1.3.4 Average Rate Meter More complicated TB meters might define two burst sizes and three
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. Token bucket meters designed for
Diffserv networks are described in more detail in [SRTCM, TRTCM,
GTC]; 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. Often these multi-conformance level meters can be
implemented using an appropriate configuration of multiple two-
parameter TB meters.
A profile for a multi-stage TB meter with three levels of conformance
might look as follows:
Meter4: Meter4:
Type: AverageRate Type: MultiTokenBucket
Profile5: output A Profile4: output A
NonConforming: output B Profile5: output B
NonConforming: output C
Profile5: Profile4:
Type: AverageRate Type: SimpleTokenBucket
AverageRate: 120 Kbps AverageRate: 100 KBps
BurstSize: 20 KB
Bernet, Smith, Blake expires December, 1999 14 Profile5:
Delta: 100us Type: SimpleTokenBucket
AverageRate: 100 KBps
BurstSize: 100 KB
5.1.3.5 Other Vendor-specific Meters 5.2.5 Null Meter
Other vendor specific meters are also possible. 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.
5.2 Action Elements 6. Action Elements
Classifiers and meters are generally used to determine the Classifiers and meters are fan-out elements which are generally used
appropriate action to apply to a packet. The set of possible non- to determine the appropriate action to apply to a packet. The set of
exclusive actions include: possible actions include:
1) Marking 1) Marking
2) Dropping
2) Shaping 2) Shaping
3) Dropping 3) Mirroring
4) Monitoring 4) Monitoring
The corresponding action elements are described in the following The corresponding action elements are described in the following
paragraphs. Each of these actions has a default treatment which is paragraphs.
to simply pass the packet on to a PHB queue.
Policing is a general term for the action of preventing a traffic Policing is a general term for the process of preventing a traffic
stream from seizing more than its share of resources from a diffserv stream from seizing more than its share of resources from a Diffserv
network. Each of the three action elements described may be used to network. Each of the first three actions described above may be used
police traffic. Markers do so by re-marking submitted packets to a to police traffic. Markers do so by re-marking non-conforming
DSCP that is entitled to less network resources. Shapers and packets to a DSCP value that is entitled to fewer network resources.
droppers do so by limiting the rate at which a particular traffic Shapers and droppers do so by limiting the rate at which a particular
stream is submitted to the network. traffic stream is submitted to the network.
5.2.1 Markers 6.1 Marker
Markers set the DSCP in a packet header. Markers may act on unmarked Markers are 1:1 elements which set the DSCP in an IP header (in
packets (submitted with DSCP of zero) or may re-mark previously the case of unlabeled packets). Markers may act on unmarked packets
marked packets. In particular, the model supports the application of (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 marking based on a preceding classifier match. The DSCP set in a
packet will determine its subsequent treatment both by any following packet will determine its subsequent treatment in downstream nodes
classifier elements within the same node or by other nodes of a network, and possible in subsequent processing stages within the
downstream in the diffserv network. router (depending on configuration).
Markers are parameterized by a single parameter - the six-bit DSCP
to be marked in packet headers.
5.2.1.1 Formal Representation of a Marker
The following formal definition can be used to represent a marker: Markers are normally parameterized by a single parameter: the 6-bit
DSCP to be marked in the packet header.
ActionElement1: ActionElement1:
Type: Marker Type: Marker
Mark: 010010 Mark: 010010
5.2.2 Shapers
Shapers are used to shape traffic to a certain temporal profile. For In the case of a MPLS labeled packet, the marker is parameterized
example, a shaper can be used to smooth traffic arriving in bursts. by a 3-bit EXP value to be marked in the MPLS shim header.
Bernet, Smith, Blake expires December, 1999 15 6.2 Dropper
Shapers operate by delaying packets that would be deemed non-
conforming to the shaper's profile. The packet is delayed until such
time that it becomes conforming. Consider the average rate profile
described previously. In the case that a burst of 11 packets was
submitted simultaneously to a meter using the average rate profile,
the 11th packet would be deemed non-conforming. In order to be
deemed conforming, the packet would have to be delayed by one
second. Thus, a shaper parameterized by the average rate profile
(see section 5.1.1.1) would delay the 11th packet for one second.
Shapers are parameterized by a single temporal profile e.g. a token
bucket.
Implicit in the definition of a shaper is a notion of a queue and a Droppers simply discard packets. There are no parameters for
queue depth: in order to delay a packet, a shaper must have droppers. Because a dropper is a terminating point of the datapath,
somewhere to store the packet and that storage area often has finite it may be desirable to forward the packet through a monitor first
size. The queue is modeled here as a simple FIFO with a finite for instrumentation purposes.
depth. Packets are dropped if the depth is exceeded - this is
considered to be an error condition.
5.2.2.1 Uses of Shapers Droppers are not the only elements than can cause a packet to be
discarded. The other element is an enqueueing element (see Sec.
6.6). However, since the enqueueing element's behavior is closely
tied the state of one or more queues, we choose to distinguish them
as separate functional elements.
Shapers are often used to pre-condition traffic such that packets 6.3 Shaper
are not deemed non-conforming by subsequent meters, e.g. in
downstream diffserv nodes. Shapers may also be used to isolate
certain traffic streams from the effects of other traffic streams of
the same BA. For example, consider the case of two traffic streams
that are submitted to a diffserv network for a particular diffserv
service level. The agreement between the customer and the diffserv
network provider limits the rate of traffic that can be submitted at
a certain service level. In this case, one of the two traffic
streams may attempt to seize more than its fair share of the
available capacity for the service level. By doing so, it
compromises the other traffic stream. A shaper that acts
independently on the two streams can be used to limit the effect of
the rogue stream. Note also that a BA might be metered against one
profile whilst being shaped to a different profile further
downstream in the same device.
5.2.2.2 Formal Representation of a Shaper Shapers are used to shape traffic streams to a certain temporal
profile. For example, a shaper can be used to smooth traffic
arriving in bursts. In [DSARCH] a shaper is described as a
queueing element controlled by a meter which defines its temporal
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.
The following formal definition can be used to represent a shaper: 6.4 Mirroring Element
ActionElement2: It is occasionally desirable to mirror data traffic on one or more
Type: Shaper additional interfaces for data collection purposes. A mirroring
Profile: Profile1 element is a 1:N (fan-out) element. However, each and every packet
QueueDepth: size in bytes and/or packets follows each output path simultaneously. A mirroring element is
parameterized by the number of outputs it supports.
Profile definitions are identical in format to those described under 6.5 Mux
the formal definition of a meter.
<note: do we need to discuss dropping algorithms for shapers here?> It is occasionally necessary to multiplex traffic streams into a 1:1
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.
5.2.3 Droppers 6.6 Enqueueing Element
Bernet, Smith, Blake expires December, 1999 16 Queueing elements (discussed in Sec. 7) require an action element to
Droppers simply discard packets. There are no parameters for execute the appropriate buffer management algorithm and store or
droppers. discard a packet. This is performed by an enqueueing element, which
is an M:1 (fan-in) element. An enqueueing element executes the
buffer management algorithm appropriate for the queue it is feeding.
This may include a deterministic discard behavior if the queue size
exceeds a threshold, it may include a random discard behavior that
is a function of the average queue size [AF-PHB], or it may include
a more complex policy which is a function of the state of several
queues in a queue set (see Sec. 7). The particular parameters to
apply to a packet may depend on the particular input port the element
receives it on; this allows packets which are classified into
different colors to follow different datapaths and be processed
appropriately at the enqueueing element.
5.2.3.1 Formal Representation of a Dropper The configuration parameters for an enqueueing element will depend on
the details of the algorithm it is executing. For an algorithm such
as the one recommended in [AF-PHB], the parameters would include
separate RED min_th, max_th, and max_p parameters per-element input
port.
The following formal definition can be used to represent a dropper: An enqueueing element must maintain octet/packet counters for both
the forwarded and discarded packets received at each element input
port. Counters should be provided to distinguish between losses due
to the normal operation of the algorithm (e.g., random drop) and
those due to resource exhaustion (e.g., tail drop) [DSMIB].
ActionElement03: 6.7 Monitor
Type: Dropper
5.2.4 Monitoring 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. Monitors are 1:1 functional elements which increment an
octet counter by L and a packet counter by 1 every time a L-byte
sized packet passes through it. Monitors can also be used to count
packets on the verge of being dropped by a dropper.
One passive form of an action to be taken is simply to account for 6.8 Null Action
the fact that a data packet was processed. This might be used later
on in presenting statistics for customer usage-based billing.
Further discussion of instrumentation for monitoring is provided in
section 0 although the topic of accounting is not dealt with in
detail here.
6. Traffic Conditioning Blocks (TCBs) 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.
The classifiers and traffic conditioning elements described above 7. Queues
can be combined into traffic conditioning blocks (TCBs). The TCB is
an abstraction of a functional block that may be used to facilitate
the definition of traffic conditioning functionality.
A general TCB consists of three stages: 7.1 Queue Sets and Scheduling
Queues are used to store packets prior to transmission or prior to
forwarding to the next functional element. Packets are usually
stored either because there is a resource constraint (e.g., available
bandwidth) which prevents immediate forwarding, or because the queue
is being used to alter the temporal properties of a traffic stream
(shaping). Queues may be organized into queue sets, which are
serviced using a common scheduling algorithm (although each queue may
be individually parameterized). Queue sets can be treated as
functional elements and organized hierarchically in queue supersets,
using an n-th order scheduling algorithm. Such a queue set may be
used to implement the entire range of PHBs on an egress interface,
for instance.
Possible queue scheduling algorithms fall into a number of
categories, including strict priority, weighted fair bandwidth
sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, etc.
Scheduling algorithms can be further distinguished by whether they
are work conserving or non-work conserving. A work conserving
algorithm will always transmit an available packet at every
transmission opportunity, while a non-work conserving algorithm will
not. 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 that it
would conform to a meter using the same profile.
[DSARCH] defines PHBs without specifying required queueing
algorithms. However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
configuration parameters which strongly suggest the sort of queue
scheduling algorithm needed to implement them. We have selected a
minimal set of queue parameters to enable realization of these per-
hop behaviors. These include a minimum service rate and a strict
service priority along with an optional maximum service rate profile
(depending on whether the queue is meant to be non-work conserving).
The minimum service rate allows throughput guarantees for each queue
as required by EF and AF without specifying the details of how excess
bandwidth between these queues is shared (additional parameters to
control this behavior should be made available, but are dependent on
the particular scheduling algorithm implemented). The strict service
priority is useful for implementing EF on some links (assuming that
the aggregate EF rate has been appropriately bounded to avoid
starvation). Setting the service priority of each queue in a queue
set to the same value enables the scheduler to satisfy the minimum
service rate for each queue. Queue sets can be serviced like
individual queues in a queue superset using the same scheduling
parameters.
It should be noted that the queues in this model are logical
abstractions used to configure PHB-related parameters. They are not
expected to map one-to-one with physical queues in a specific router
implementation. An implementor should map the configurable
parameters of the physical queues to these queue parameters as
appropriate to achieve equivalent behaviors.
Other queue parameters such as maximum capacity are assumed to be
mapped to the buffer management algorithm used by the enqueueing
element feeding the queue.
A queue set might be represented using the following parameters:
QueueSet1:
Type: QueueSet
MaxProfile: WorkConserving
MinGuarRate: 20 MBps
Interface: ifIndex
QueueA:
Type: Queue
QueueSet: QueueSet1
MaxProfile: Profile1
MinGuarRate: 2 MBps
Priority: 3
QueueB:
Type: Queue
QueueSet: QueueSet1
MaxProfile: WorkConserving
MinGuarRate: 8 MBps
Priority: 3
7.2 Shaping
Shapers are often used to pre-condition traffic such that packets
are deemed conforming by subsequent meters, e.g., in downstream
Diffserv nodes. Shapers may also be used to isolate certain traffic
streams from the effects of other traffic streams of the same BA.
A shaper action element is implemented in this model by using a non-
work conserving queue. Shapers operate by delaying packets that
would be deemed non-conforming by a meter configured to the shaper's
maximum service rate profile. The packet is delayed until such
time that it would become conforming.
Profile definitions are identical in format to those described for
meters. The use of a meter algorithm to control shaping is further
discussed in Appendix A. Average, EWMA, and TB profiles are all
feasible for shaping. Because a shaper is implemented as a queue it
can also utilize a variety of buffer management algorithms
(implemented in a enqueueing element).
A shaping queue might be represented using the following parameters:
QueueA:
Type: Queue
QueueSet: QueueSet1
MaxProfile: Profile1
MinGuarRate: 2 MBps
Priority: 3
Profile1:
Type: SimpleTokenBucket
AverageRate: 3 MBps
BurstSize: 8 KB
8. Traffic Conditioning Blocks (TCBs)
The classifiers, meters, action elements, and queueing elements
described above can be combined into traffic conditioning blocks
(TCBs). The TCB is an abstraction of a functional element that may
be used to facilitate the definition of specific traffic conditioning
functionality.
One of the simplest possible TCBs would consist of the following
stages:
1. Classifier stage
2. Enqueueing stage
3. Queueing stage
Note that a classifier is a 1:N element, while an enqueueing stage is
a N:1 element and a queue is a 1:1 element. If the classifier split
traffic across multiple enqueueing elements then the queueing stage
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:
1. Classifier stage 1. Classifier stage
2. Metering stage 2. Metering stage
3. Action stage 3. Action stage
4. Queueing stage
where each stage may consist of a set of parallel datapaths
consisting of pipelined elements.
TCBs are constructed by connecting elements corresponding to these TCBs are constructed by connecting elements corresponding to these
stages in any order. It is allowable to omit stages or to stages in any sensible order. It is possible to omit stages, to
concatenate multiple stages of the same type. TCB outputs may drive include null elements, or to concatenate multiple stages of the same
additional TCBs (on the same interface or on an egress interface) or type. TCB outputs may drive additional TCBs (on either the ingress
alternatively, may be directed to a PHB queue on an egress or egress interfaces). Classifiers and meters are fan-out elements,
interface. muxes and enqueueing elements are fan-in elements.
6.1 Example TCB 8.1 An Example TCB
The following diagram illustrates an example TCB: The following diagram illustrates an example TCB:
Bernet, Smith, Blake expires December, 1999 17 +------------> to Queue A
-------------> to Queue A +-----+ | (not shown)
------- | | |--+
| |--- +->| |
-->| | | | |--+ +-----+ +-----+
| | |--- ------- | +-----+ | | | | |
| ------- | | | | meter +->| |--->| |
| meter -->| |-----> discard | | | | |
| | | | +-----+ +-----+
| ------- | monitor dropper
| dropper
| |
| |
| -------------> to Queue B |
submitted ------- | ------- | ^ submitted +-----+ | +-----+ +-----+
traffic | A |------- | |--- | traffic | A |-----+ | | | |
--->| B |-------->| | | --->| B |------->| |---->| |---> to Queue B
| C |------- | |--- ------- | | C |-----+ | | | | (not shown)
| X |---- | ------- | | | | | X |--+ | +-----+ +-----+
------- | | meter -->| |--- +-----+ | | marker shaper
BA | | | | BA | | queue
classifier | | ------- classifier| |
| | shaper
| | | |
| | | |
| | -------------> to Queue C | |
| | ------- | | |
| | | |--- | | +-----+ +-----+
| -->| | | | | |--------------->| | to Queue C
| | |--- ------- | +->| | | |->
| ------- | | | | | |--+ +-----+ +->| | (not shown)
| meter -->| |---> to Queue D | +-----+ | | | | +-----+
| meter +->| |-+ mux
| | | | | |
| ------- | +-----+
| re-marker | marker
| |
----------------------------> to Queue E +---------------------------> to Queue D
(not shown)
Figure 4 - An Example Traffic Conditioning Block Figure 5: An Example Traffic Conditioning Block
This sample TCB might be suitable for an ingress interface at a This sample TCB might be suitable for an ingress interface at a
customer/provider interface. A SLA is presumed to have been customer/provider boundary. A SLS is presumed to have been
negotiated between the customer and the provider which specifies the negotiated between the customer and the provider which specifies the
handling of the customer's traffic by the provider's network. The handling of the customer's traffic by the provider's network. The
agreement might be of the following form: agreement might be of the following form:
DSCP PHB Profile Non-Conforming Packets DSCP PHB Profile Non-Conforming Packets
---- --- ------- ------------------------- ---- --- ------- ----------------------
001001 PHB1 Profile1 Discarded 001001 PHB1 Profile1 Discard
001100 PHB2 Profile2 Shaped to Profile1 001100 PHB2 Profile2 Wait in shaper queue
001101 PHB3 Profile3 Re-marked to DSCP 001000 001101 PHB3 Profile3 Re-mark to DSCP 001000
It is implicit in this agreement that conforming packets are given It is implicit in this agreement that conforming packets are given
the PHB originally indicated by the packets' DSCP field. It the PHB originally indicated by the packets' DSCP field. It
Bernet, Smith, Blake expires December, 1999 18
specifies that the customer may submit packets marked for DSCP specifies that the customer may submit packets marked for DSCP
001001 which will get PHB1 treatment so long as they remain 001001 which will get PHB1 treatment so long as they remain
conforming to Profile1 and will be discarded if they exceed this conforming to Profile1 and will be discarded if they exceed this
profile. Similar contract rules are applied for 001100 and 001101 profile. Similar contract rules are applied for 001100 and 001101
traffic. traffic.
In this example, the classification stage consists of a single BA In this example, the classification stage consists of a single BA
classifier. The BA classifier is used to separate traffic based on classifier. The BA classifier is used to separate traffic based on
the diffserv service level requested by the customer (as indicated the Diffserv service level requested by the customer (as indicated
by the DSCP in each submitted packet's IP header). We illustrate 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 three DSCP filter values: A, B and C. The 'X' in the BA classifier
indicates 'no match'. is the default wildcard filter that matches every packet.
The metering stage is next. There is a separate meter for each set
of packets corresponding to DSCPs A, B and C. Each meter uses a
specific profile as specified in the SLA for the corresponding
diffserv service level. The meters in this example indicate one of
two conforming levels, conforming or non-conforming.
Following the metering stage is the action stage. Packets submitted
for DSCP A that are deemed non-conforming are discarded. Packets
that are conforming are passed on to the queue for the corresponding
PHB.
Packets submitted for DSCP B that are deemed non-conforming are
delayed in a shaper until they become conforming. Packets that are
deemed conforming are allowed to pass directly to the queue for PHB
B.
Note that in actual implementations, non-conforming packets will
cause packets on the same traffic stream that are conforming to be
delayed in order to maintain per-stream packet ordering. However,
this is an implementation detail and need not be considered from the
abstract management perspective.
Packets submitted for DSCP C and deemed non-conforming are re-marked A metering stage is next in the upper and lower branches. There is a
for a less privileged DSCP and are directed to the appropriate PHB separate meter for each set of packets corresponding to DSCPs A and
queue. Packets that are deemed conforming are passed directly to the C. Each meter uses a specific profile as specified in the TCS for
requested PHB queue. the corresponding Diffserv service level. The meters in this
example indicate one of two conforming levels, conforming or
non-conforming. The middle branch has a marker which re-marks all
packets received with DSCP B.
6.2 Formal Representation of TCB Following the metering stage is the action stage in the upper and
lower branches. Packets submitted for DSCP A that are deemed non-
conforming and are counted and discarded. Packets that are
conforming are passed on to Queue A. Packets submitted for DSCP C
that are deemed non-conforming are re-marked, and then conforming and
non-conforming packets are muxed together before being forwarded to
Queue C. Packets submitted for DSCP B are shaped to Profile2 before
being forwarded to Queue B.
The following is a formal representation of the interconnection of The interconnections of the TCB elements illustrated in Fig. 5 can be
the components of the TCB illustrated in Error! Reference source not represented as follows:
found.:
TCB1: TCB1:
Classifier1: Classifier1:
Output A --> Meter1 Output A --> Meter1
Output B --> Meter2 Output B --> Marker1
Output C --> Meter3 Output C --> Meter2
Output X --> QueueE Output X --> QueueD
Bernet, Smith, Blake expires December, 1999 19
Meter1: Meter1:
Output A --> QueueA Output A --> QueueA
Output B --> ActionElement1 (dropper) Output B --> Monitor1
Meter2: Monitor1:
Output A --> Dropper1
Marker1:
Output A --> Shaper1
Shaper1:
Output A --> QueueB Output A --> QueueB
Output B --> ActionElement2 (shaper)
ActionElement2: Meter2:
DefaultOutput --> QueueB Output A --> Mux1
Output B --> Marker2
Meter3: Marker2:
Output A --> QueueC Output A --> Mux1
Output B --> ActionElement3 (marker)
ActionElement3: Mux1:
DefaultOutput --> QueueD Output A --> Queue C
6.3 Example TCB to Support Multiple Customers 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 agreement if the interface is implement a provider/customer TCS if the interface is dedicated to
dedicated to the customer. However, if a single interface is shared the customer. However, if a single interface is shared between
between multiple customers, then the TCB above will not suffice, multiple customers, then the TCB above will not suffice, since it
since it does not differentiate among traffic from different does not differentiate among traffic from different customers. Its
customers. Its classification stage uses BA classifiers only. classification stage uses only BA classifiers.
The TCB is readily extended to support the case of multiple The TCB is readily extended to support the case of multiple customers
customers per interface, as follows. First, we define a TCB for each per interface, as follows. First, we define a TCB for each customer
customer to reflect the agreement with that customer. TCB1, defined to reflect the TCS with that customer. TCB1, defined above is the
above is the TCB for customer 1. We add definitions for TCB2 and for TCB for customer 1. We add definitions for TCB2 and for TCB3 which
TCB3 which reflect the agreements with customers 2 and 3 reflect the agreements with customers 2 and 3 respectively.
respectively.
Finally, we add a fourth TCB, TCB4, which provides a front end to Finally, we add a classifier which provides a front end to separate
separate the traffic from the three different customers. This can be the traffic from the three different customers. This forms a new
illustrated as: TCB which incorporates TCB1, TCB2, and TCB3, and can be illustrated
as follows:
submitted +-----+ submitted +-----+
traffic | A |--------> TCB1 traffic | A |--------> TCB1
--->| B |--------> TCB2 --->| B |--------> TCB2
| C |--------> TCB3 | C |--------> TCB3
| X |--------> ActionElement4 (dropper) | X |--------> Dropper4
+-----+ +-----+
TCB4 Classifier4
Figure 5 - An Example Multi-Cusomer Front End TCB Figure 6: An Example of a Multi-Customer TCB
A formal representation of this multi-customer TCB might be: A formal representation of this multi-customer TCB might be:
TCB1: TCB1:
Bernet, Smith, Blake expires December, 1999 20
(as defined above) (as defined above)
TCB2: TCB2:
(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)
Classifier2: Classifier4:
Output A --> TCB1 Output A --> TCB1
Output B --> TCB2 Output B --> TCB2
Output C --> TCB3 Output C --> TCB3
Output X --> ActionElement4 (dropper) Output X --> Dropper4
Where Classifier2 is defined as follows: Where Classifier2 is defined as follows:
Classifier2: Classifier4:
Filter1: output A Filter1: Output A
Filter2: output B Filter2: Output B
Filter3: output C Filter3: Output C
No Match: output X No Match: Output X
and the filters, based on each customer's source MAC address are and the filters, based on each customer's source MAC address, are
defined as follow: 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, TCB4 separates traffic submitted from different In this example, Classifier4 separates traffic submitted from
customers based on the source MAC address in submitted packets. different customers based on the source MAC address in submitted
Those packets with recognized source MAC addresses are passed to the packets. Those packets with recognized source MAC addresses are
TCB implementing the agreement with the corresponding customer. passed to the TCB implementing the TCS with the corresponding
Those packets with unrecognized source MAC addresses are passed to a customer. Those packets with unrecognized source MAC addresses are
dropper. passed to a dropper.
TCB4 has a classification stage and an action element stage (it is
used only for unrecognized traffic) i.e. all actions are the default
which is to pass through unchanged. Its outputs drive either the
dropper action element or additional TCBs.
Bernet, Smith, Blake expires December, 1999 21 TCB4 has a classification stage and an action element stage, which
consists of either a dropper or another TCB.
6.4 TCBs Supporting Microflow-based Services 8.3 TCBs Supporting Microflow-based Services
The TCB illustrated above describes a TC configuration that might be The TCB illustrated above describes a configuration that might be
suitable for enforcing a SLA at a router's ingress. It assumes that suitable for enforcing a SLS at a router's ingress. It assumes that
the customer marks its own traffic for the appropriate service the customer marks its own traffic for the appropriate service level.
level. It then limits the rate of aggregate traffic submitted at It then limits the rate of aggregate traffic submitted at each
each service level, thereby protecting the resources of the diffserv service level, thereby protecting the resources of the Diffserv
network. It does not mark the customer's packets, nor does it network. It does not provide any isolation between the customer's
provide any isolation between the customer's individual microflows. individual microflows (other than from separated queueing).
Next we present a TC configuration that offers additional Next we present a TCB configuration that offers additional
functionality to the customer. It recognizes individual customer functionality to the customer. It recognizes individual customer
microflows and marks each one independently. It also isolates the microflows and marks each one independently. It also isolates the
customer's individual microflows from each other in order to prevent 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 6 below: illustrated in Figure 7 below:
------- ------- +-----+ +-----+
| | | |---------------> | | | |---------------+
-->| |-->| | ------- +->| |-->| | +-----+ |
------- | | | | |---->| | +-----+ | | | | |---->| | |
| |---- ------- ------- ------- | |---- +-----+ +-----+ +-----+ |
->| |---- marker meter dropper ->| |---- marker meter dropper | +-----+ to
| |-- | ------- ------- | |-+ | +-----+ +-----+ +-->| |
------- | | | | | |---------------> +-----+ | | | | | |------------------>| |--->
MF | -->| |-->| | ------- MF | +->| |-->| | +-----+ +-->| |
class. | | | | |---->| | class. | | | | |---->| | | +-----+ TCB2
| ------- ------- ------- | +-----+ +-----+ +-----+ | mux
| marker meter dropper | marker meter dropper |
| ------- ------- | +-----+ +-----+ |
| | | | |---------------> | | | | |---------------+
|--->| |-->| | ------- |--->| |-->| | +-----+
| | | | |---->| | | | | | |---->| |
| ------- ------- ------- | +-----+ +-----+ +-----+
| marker meter dropper | marker meter dropper
| . . . | . . .
V V V V V V V V
Figure 6 - An Example of a Marking and Traffic Isolation TCB Figure 7: An Example of a Marking and Traffic Isolation TCB
Traffic is first directed to an 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 would be formally specified as follows: 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.
Bernet, Smith, Blake expires December, 1999 22 The TCB could be formally specified as follows:
TCB1: TCB1:
Classifier1: (MF) Classifier1: (MF)
Output A --> Marker1 Output A --> Marker1
Output B --> Marker2 Output B --> Marker2
Output C --> Marker3 Output C --> Marker3
. . . . . .
Marker1 --> Meter1 Marker1 --> Meter1
Marker2 --> Meter2 Marker2 --> Meter2
skipping to change at line 1209 skipping to change at page 30, line 33
Meter3: Meter3:
Output A --> TCB2 Output A --> TCB2
Output B --> ActionElement3 (dropper) Output B --> ActionElement3 (dropper)
The actual traffic element declarations are not shown here. The actual 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, illustrated below:
------- +-----+
| |---------------> | |--------------->
-->| | ------- +->| | +-----+
------- | | |---->| | +-----+ | | |---->| |
| |---- ------- ------- | |---+ +-----+ +-----+
->| | meter dropper ->| | meter dropper
| |---| ------- | |---+ +-----+
------- | | |---------------> +-----+ | | |--------------->
BA -->| | ------- BA +->| | +-----+
classifier | |---->| | classifier | |---->| |
------- ------- +-----+ +-----+
meter dropper meter dropper
Figure 7 - Additional Example TCB Figure 8: Additional Example TCB
TCB2 would be formally specified as follows: TCB2 would be formally specified as follows:
Classifier2: (BA) Classifier2: (BA)
Output A --> Meter10 Output A --> Meter10
Output B --> Meter11 Output B --> Meter11
Meter10: Meter10:
Output A --> PHBQueueA Output A --> PHBQueueA
Output B --> ActionElement10 (dropper) Output B --> Dropper10
Bernet, Smith, Blake expires December, 1999 23
Meter11: Meter11:
Output A --> PHBQueueB Output A --> PHBQueueB
Output B --> ActionElement11 (dropper) Output B --> Dropper11
7. Queuing Components 9. Open Issues
Queuing components are the final conceptual components of the model o There is a difference in interpretation of token bucket behavior
of a diffserv router before packets leave a device. The queuing between this document (Appendix A) and [DSMIB]. Specifically,
behaviours implemented on an egress interface are modeled as a set [DSMIB] allows a packet to conform if any smaller packet would
of inter-dependent queues that are serviced by a queuing algorithm conform.
with certain parameters and profiles. In particular, the scheduling
parameters may be any of the Profile types defined for TC elements
above e.g. SimpleTokenBucket, AverageRate, ExpWeightedMovingAvg.
QueueSet1: o The meter in [SRTCM] cannot be precisely modeled using two
Type: QueueSet two-parameter token buckets because its two buckets do not
MaxSustRate: 100 Mbps accumulate credits independently. We intended to demonstrate how
MinGuarRate: 20 Mbps the [TRTCM] meter could be implemented but ran out of time.
Interface: ifIndex
- guaranteed buffer pool for this queue set (?) o Are the queue parameters (scheduling and buffer management)
parameters defined sufficient?
QueueA: o Does Queue and Queue Set really belong in the model (and the MIB
Type: Queue and PIB?), or should the model stick to the abstract PHB
QueueSet: QueueSet1 representation and leave the implementation details to the MIB and
Profile: Profile1 PIB?
MinGuarRate: 2 Mbps
QueueDepth: 200 kbytes
Priority: 5
QueueB: o Should a classifier be part of a TCB? We argue yes. This allows a
Type: Queue TCB to be a one input/one output black box element.
QueueSet: QueueSet1
Profile: Profile2
MinGuarRate: 2 Mbps
QueueDepth: 200 kbytes
Priority: 3
- guaranteed buffer pool for each queue (?) o Is the description of a shaper sufficient? Is it overbroad?
<Editor's note: this set of parameters is a strawman for comment> 10. Security Considerations
8. Monitoring Security vulnerabilities of Diffserv network operation are discussed
in [DSARCH]. This document describes an abstract functional model of
Diffserv router elements. Certain denial-of-service attacks such as
those resulting from resource starvation may be mitigated by
appropriate configuration of these router elements; for example, by
rate limiting certain traffic streams or by authenticating traffic
marked for higher quality-of-service.
Generally, it should be possible to retrieve the TCTs and similar 11. Acknowledgments
tabular representations of the different diffserv router components.
It should be possible to monitor the count of packets submitted to
each TC element and the disposition of the packet (which of the
element outputs it was directed to).
Bernet, Smith, Blake expires December, 1999 24 Concepts, terminology, and text have been borrowed liberally from
In the case of the installation in a router of packet filters that [DSMIB] and [PIB]. We wish to thank the authors: Fred Baker,
conflict, it must be possible to determine the relative precedence Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, and
of the filters as implemented by the router. Scott Hahn, for their permission.
9. Initial State This document has benefitted from the comments and suggestions of
several participants of the Diffserv working group.
(TBD) 12. References
<should we discuss here the assumed initial state of a diffserv [DSARCH] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and
router?> E. Davies, "An Architecture for Differentiated Services",
RFC 2475, December 1998
10. Security Considerations [DSTERMS] D. Grossman, "New Terminology for Diffserv", Internet
Draft <draft-ietf-diffserv-new-terms-00.txt>, October
1999.
<add here> [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.
11. References [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.
[DSARCH] Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., [EF-PHB] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited
Davies, E., "An Architecture for Differentiated Services", RFC 2475, Forwarding PHB", RFC 2598, June 1999.
December 1998
[DSFWK] Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B., [AF-PHB] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski,
Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework "Assured Forwarding PHB Group", RFC 2597, June 1999.
for Differentiated Services", Internet Draft, February 1999
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework-
02.txt
[E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [DSMIB] F. Baker, "Differentiated Services MIB", Internet Draft
Nichols, K., Speer, M., Braden, R., Davie, B., "Integrated Services <draft-ietf-diffserv-mib-00.txt>, June 1999.
Operation over Diffserv Networks", Internet Draft, June 1999,
www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-02.txt
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, [SRTCM] J. Heinanen, and R. Guerin, "A Single Rate Three Color
"Definition of the Differentiated Services Field (DS Field) in the Marker", RFC 2697, September 1999.
IPv4 and IPv6 Headers", RFC 2474, December 1998.
[EF-PHB] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
Forwarding PHB", RFC 2598, June 1999. and A. Smith, "Quality of Service Policy Information
Base", Internet Draft <draft-mfine-cops-pib-01.txt>,
June 1999.
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski " [TRTCM] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker",
Assured Forwarding PHB Group", RFC 2597, June 1999. RFC 2698, September 1999.
[DSMIB] Baker, F., Pan, P., Guerin, R., Bernet, Y., "Differentiated [GTC] L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner",
Service Management Information Base using SMIv2", Internet Draft, Internet Draft <draft-lin-diffserv-gtc-01.txt>, August
June 1999. http://www.ietf.org/internet-drafts/draft-ietf-diffserv- 1999.
mib-00.txt
[SRTCM] Heinanen, J., Guerin, R., "A Single Rate Three Color [MPLSDS] J. Heinanen, "Differentiated Services in MPLS Networks",
Marker", Internet Draft, May 1999, www.ietf.org/internet- Internet Draft <draft-heinanen-diffserv-mpls-00.txt>,
drafts/draft-heinanen-diffserv-srtcm-01.txt June 1999.
Bernet, Smith, Blake expires December, 1999 25 Appendix A. Simple Token Bucket Definition
[TRTCM] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker",
Internet Draft, May 1999, www.ietf.org/internet-drafts/heinanen-
diffserv-trtcm-01.txt
[GTC] Lin, L., Lo, J., Ou, F., "A Generic Traffic Conditioner", [DSMIB] presents a fairly detailed exposition on the operation of
Internet Draft, April 1999, www.ietf.org/internet-drafts/draft-lin- two-parameter token buckets for metering. However, the behavior
diffserv-qtc-00.txt 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).
12. Author's Addresses The behavior defined in [SRTCM] and [TRTCM] is not mandatory for
compliance, but we give here a mathematical definition of two-
parameter token bucket operation which is consistent with these
documents, and which can be used to define a shaping profile.
Define a token bucket with bucket size BS, token accumulation rate
R, and instantaneous token occupancy T(t). Assume that T(0) = BS.
Then after an arbitrary interval with no packet arrivals, T(t) will
not change since the bucket is already full of tokens. Assume a
packet of size B bytes at time t'. The bucket capacity T(t'-) = BS
still. Then, as long as B <= BS, the packet conforms to the meter,
and
T(t') = BS - B.
Assume an interval v = t - t' elapses before the next packet, of
size C <= BS, arrives. T(t-) is given by the following equation:
T(t-) = max { BS, T(t') + v*R }
(the packet has accumulated v*R tokens over the interval, up to a
maximum of BS tokens).
If T(t-) - C >= 0, the packet conforms and T(t) = T(t-) - C.
Otherwise, the packet does not conform and T(t) = T(t-).
This function can be used to define a shaping profile. If a packet of
size C arrives at time t, it will be eligible for transmission at time
te given as follows (we still assume C <= BS):
te = max { t, t" }
where
t" = (C - T(t') + t'*R)/R.
T(t") = C, the time when C credits have accumulated in the bucket,
and when the packet would conform if the token bucket were a meter.
te != t" only if t > t".
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
3585 Monroe St. 3585 Monroe St.
Santa Clara, CA 95051 Santa Clara, CA 95051
Phone: +1 408 579 2821 Phone: +1 408 579 2821
E-mail: andrew@extremenetworks.com E-mail: andrew@extremenetworks.com
Steven Blake Steven Blake
Ericsson Datacom Ericsson
3000 Aerial Center Parkway, Suite 140 3000 Aerial Center Parkway, Suite 140
Morrisville, NC 27560 Morrisville, NC 27560
Phone: 919-468-8466 x232 Phone: +1 919 468 8466 x232
E-mail: slblake@torrentnet.com E-mail: slblake@torrentnet.com
Bernet, Smith, Blake expires December, 1999 26
 End of changes. 270 change blocks. 
887 lines changed or deleted 1204 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/