draft-ietf-diffserv-model-03.txt   draft-ietf-diffserv-model-04.txt 
Internet Engineering Task Force Y. Bernet Internet Engineering Task Force Y. Bernet
Diffserv Working Group Microsoft Diffserv Working Group Microsoft
INTERNET-DRAFT A. Smith INTERNET-DRAFT S. Blake
Expires November 2000 Extreme Networks Expires January 2001 Ericsson
draft-ietf-diffserv-model-03.txt S. Blake draft-ietf-diffserv-model-04.txt D. Grossman
Ericsson
D. Grossman
Motorola Motorola
A Conceptual Model for Diffserv Routers A. Smith
<editor>
An Informal Management Model for Diffserv Routers
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 39 skipping to change at page 1, line 40
This document is a product of the IETF's Differentiated Services Working This document is a product of the IETF's Differentiated Services Working
Group. Comments should be addressed to WG's mailing list at Group. Comments should be addressed to WG's mailing list at
diffserv@ietf.org. The charter for Differentiated Services may be found diffserv@ietf.org. The charter for Differentiated Services may be found
at http://www.ietf.org/html.charters/diffserv-charter.html Copyright (C) at http://www.ietf.org/html.charters/diffserv-charter.html Copyright (C)
The Internet Society (2000). All Rights Reserved. The Internet Society (2000). All Rights Reserved.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
This draft proposes a conceptual model of Differentiated Services This memo proposes an informal management model of Differentiated
(Diffserv) routers for use in their management and configuration. This Services (Diffserv) routers for use in their management and
model defines the general functional datapath elements (classifiers, configuration. This model defines functional datapath elements (e.g.
meters, markers, droppers, monitors, multiplexors, queues), their classifiers, meters, actions (e.g. marking, absolute dropping, counting,
possible configuration parameters, and how they might be interconnected multiplexing), algorithmic droppers, queues and schedulers. It describes
to realize the range of classification, traffic conditioning, and per- possible configuration parameters for these elements and how they might
hop behavior (PHB) functionalities described in [DSARCH]. The model is be interconnected to realize the range of traffic conditioning and per-
intended to be abstract and capable of representing the configuration hop behavior (PHB) functionalities described in the Diffserv
parameters important to Diffserv functionality for a variety of specific Architecture [DSARCH].
router implementations. It is not intended as a guide to hardware
implementation.
The model is intended to be abstract and capable of representing the
configuration parameters important to Diffserv functionality for a
variety of specific router implementations. It is not intended as a
guide to system implementation nor as a formal modelling description.
This model serves as the rationale for the design of an SNMP MIB [DSMIB] This model serves as the rationale for the design of an SNMP MIB [DSMIB]
and for other configuration interfaces (e.g. [DSPIB]) and more detailed and for other configuration interfaces (e.g. [DSPIB]) and, possibly,
models (e.g. [QOSDEVMOD]): these should all be based upon and consistent more detailed formal models (e.g. [QOSDEVMOD]): these should all be
with this model. consistent with this model.
1. Introduction 1. Introduction
Differentiated Services (Diffserv) [DSARCH] is a set of technologies Differentiated Services (Diffserv) [DSARCH] is a set of technologies
which allow network service providers to offer different kinds of which allow network service providers to offer services with different
network quality-of-service (QoS) to different customers and their kinds of network quality-of-service (QoS) objectives to different
traffic streams. The premise of Diffserv networks is that routers within customers and their traffic streams. The premise of Diffserv networks is
the core of the network handle packets in different traffic streams by that routers within the core of the network handle packets in different
forwarding them using different per-hop behaviors (PHBs). The PHB to be traffic streams by forwarding them using different per-hop behaviors
applied is indicated by a Diffserv codepoint (DSCP) in the IP header of (PHBs). The PHB to be applied is indicated by a Diffserv codepoint
each packet [DSFIELD]. Note that this document uses the terminology (DSCP) in the IP header of each packet [DSFIELD]. Note that this
defined in [DSARCH, DSTERMS] and in Section 2. document uses the terminology defined in [DSARCH, DSTERMS] and in
Section 2.
The advantage of such a scheme is that many traffic streams can be The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behavior aggregates (BA) which aggregated to one of a small number of behavior aggregates (BA) which
are each forwarded using the same PHB at the router, thereby simplifying are each forwarded using the same PHB at the router, thereby simplifying
the processing and associated storage. In addition, there is no the processing and associated storage. In addition, there is no
signaling, other than what is carried in the DSCP of each packet, and no signaling, other than what is carried in the DSCP of each packet, and no
other related processing that is required in the core of the Diffserv other related processing that is required in the core of the Diffserv
network since QoS is invoked on a packet-by- packet basis. network since QoS is invoked on a packet-by- packet basis.
The Diffserv architecture enables a variety of possible services which The Diffserv architecture enables a variety of possible services which
could be deployed in a network. These services are reflected to could be deployed in a network. These services are reflected to
customers at the edges of the Diffserv network in the form of a Service customers at the edges of the Diffserv network in the form of a Service
Level Specification (SLS) [DSTERMS]. The ability to provide these Level Specification (SLS) [DSTERMS]. The ability to provide these
services depends on the availability of cohesive management and services depends on the availability of cohesive management and
configuration tools that can be used to provision and monitor a set of configuration tools that can be used to provision and monitor a set of
Diffserv routers in a coordinated manner. To facilitate the development Diffserv routers in a coordinated manner. To facilitate the development
of such configuration and management tools it is helpful to define a of such configuration and management tools it is helpful to define a
conceptual model of a Diffserv router that abstracts away implementation conceptual model of a Diffserv router that abstracts away implementation
details of particular Diffserv routers from the parameters of interest details of particular Diffserv routers from the parameters of interest
for configuration and management. The purpose of this draft is to define for configuration and management. The purpose of this memo is to define
such a model. such a model.
The basic forwarding functionality of a Diffserv router is defined in The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB]. other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
This document is not intended in any way to constrain or to dictate the This document is not intended in any way to constrain or to dictate the
implementation alternatives of Diffserv routers. It is expected that implementation alternatives of Diffserv routers. It is expected that
router implementers will demonstrate a great deal of variability in router implementers will demonstrate a great deal of variability in
their implementations. To the extent that implementers are able to model their implementations. To the extent that implementers are able to model
their implementations using the abstractions described in this draft, their implementations using the abstractions described in this memo,
configuration and management tools will more readily be able to configuration and management tools will more readily be able to
configure and manage networks incorporating Diffserv routers of assorted configure and manage networks incorporating Diffserv routers of assorted
origins. origins.
o Section 3 starts by describing the basic high-level functional o Section 3 starts by describing the basic high-level blocks of a
elements of a Diffserv router and then describe the various Diffserv router. It explains the concepts used in the model,
components, then focussing on the Diffserv-specific components of including the hierarchical management model for these blocks which
the router and a hierarchical management model for these uses low-level functional datapath elements such as Classifiers,
components. Actions, Queues.
o Section 4 describes classification elements.
o Section 5 discusses meter elements. o Section 4 describes Classifier elements.
o Section 6 discusses action elements. o Section 5 discusses Meter elements.
o Section 7 discusses the basic queueing elements and their o Section 6 discusses Action elements.
functional behaviors (e.g. shaping).
o Section 8 shows how the basic classification, meter, action and o Section 7 discusses the basic queueing elements of Algorithmic
queueing elements can be combined to build modules called Traffic Droppers, Queues and Schedulers and their functional behaviors
Conditioning Blocks (TCBs). (e.g. traffic shaping).
o Section 9 discusses open issues with this document o Section 8 shows how the low-level elements can be combined to build
modules called Traffic Conditioning Blocks (TCBs) which are useful
for management purposes.
o Section 10 discusses security concerns. o Section 9 discusses security concerns.
2. Glossary 2. Glossary
This memo uses terminology which is defined in [DSARCH] and in This memo uses terminology which is defined in [DSARCH] and in
[DSTERMS]. Some of the terms defined there are defined again here in [DSTERMS]. Some of the terms defined there are defined again here in
order to provide additional detail, along with some new terms specific order to provide additional detail, along with some new terms specific
to this document. to this document.
Absolute A functional datapath element which simply discards all
Dropper packets arriving at its input.
Algorithmic A functional datapath element which selectively discards
Dropper packets that arrive at its input, based on a discarding
algorithm. It has one data input and one output.
Classifier A functional datapath element which consists of filters Classifier A functional datapath element which consists of filters
which select packets based on the content of packet which select matching and non-matching packets and
headers or other packet data, and/or on implicit or forwards them along a particular datapath within the
derived attributes associated with the packet, and router. A classifier splits a single incoming traffic
forwards the packet along a particular datapath within stream into multiple outgoing ones.
the router. A classifier splits a single incoming
traffic stream into multiple outgoing ones.
Counter A functional datapath element which updates a packet Counter A functional datapath element which updates a packet
counter and also an octet counter for every counter and also an octet counter for every
packet that passes through it. Used for collecting packet that passes through it. Used for collecting
statistics. statistics.
Filter A set of wildcard, prefix, masked, range and/or exact Filter A set of wildcard, prefix, masked, range and/or exact
match conditions on the components of a packet's match conditions on the content of a packet's
classification key. A filter is said to match only if headers or other data, and/or on implicit or derived
each condition is satisfied. attributes associated with the packet. A filter is
said to match only if each condition is satisfied.
Multiplexer A functional datapath element that merges multiple Functional A basic building block of the conceptual router.
Datapath Typical elements are Classifiers, Meters, Actions,
Element Algorithmic Droppers, Queues and Schedulers.
Multiplexer A multiplexor.
(Mux)
Multiplexor A functional datapath element that merges multiple
(Mux) traffic streams (datapaths) into a single traffic (Mux) traffic streams (datapaths) into a single traffic
stream (datapath). stream (datapath).
Non-work- A property of a scheduling algorithm such that it Non-work- A property of a scheduling algorithm such that it
conserving services packets no sooner than a scheduled departure conserving services packets no sooner than a scheduled departure
time, even if this means leaving packets in a FIFO time, even if this means leaving packets in a FIFO
while the link is idle. while the link is idle.
Policing The process of comparing the arrival of data packets
against a temporal profile and forwarding, delaying
or dropping them so as to make the output stream
conformant to the profile. Policing is modelled
here as the combination of either a meter or a
scheduler with either an absolute dropper or an
algorithmic dropper.
Queueing A combination of functional datapath elements Queueing A combination of functional datapath elements
Block that modulates the transmission of packets belonging Block that modulates the transmission of packets belonging
to a traffic streams and determines their to a traffic streams and determines their
ordering, possibly storing them temporarily or ordering, possibly storing them temporarily or
discarding them. discarding them.
Scheduling An algorithm which determines which queue of a set Scheduling An algorithm which determines which queue of a set
algorithm of qyeyes to service next. This may be based on the algorithm of queues to service next. This may be based on the
relative priority of the queues, on a weighted fair relative priority of the queues, on a weighted fair
bandwidth sharing policy or some other policy. Such bandwidth sharing policy or some other policy. Such
an algorithm may be either work-conserving or non- an algorithm may be either work-conserving or non-
work-conserving. work-conserving.
Shaping The process of delaying packets within a traffic stream Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined traffic profile. to cause it to conform to some defined temporal profile.
Shaping can be implemented using a queue serviced by a Shaping can be implemented using a queue serviced by a
non-work-conserving scheduling algorithm. non-work-conserving scheduling algorithm.
Traffic A logical datapath entity consisting of a number of Traffic A logical datapath entity consisting of a number of
Conditioning other functional datapath entities interconnected in Conditioning functional datapath elements interconnected in
Block (TCB) such a way as to perform a specific set of traffic Block (TCB) such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream. conditioning functions on an incoming traffic stream.
A TCB can be thought of as an entity with one A TCB can be thought of as an entity with one
input and one output and a set of control parameters. input and one or more outputs and a set of control
parameters.
Work- A property of a scheduling algorithm such that it Work- A property of a scheduling algorithm such that it
conserving servicess a packet, if one is available, at every conserving services a packet, if one is available, at every
transmission opportunity." transmission opportunity."
3. Conceptual Model 3. Conceptual Model
This section introduces a block diagram of a Diffserv router and This section introduces a block diagram of a Diffserv router and
describes the various components illustrated. Note that a Diffserv core describes the various components illustrated in Figure 1. Note that a
router is assumed to include only a subset of these components: the Diffserv core router is assumed to include only a subset of these
model presented here is intended to cover the case of both Diffserv edge components: the model presented here is intended to cover the case of
and core routers. both Diffserv edge and core routers.
3.1. Elements of a Diffserv Router 3.1. Elements of a Diffserv Router
The conceptual model includes abstract definitions for the following: The conceptual model includes abstract definitions for the following:
o Traffic Classification elements. o Traffic Classification elements.
o Metering functions. o Metering functions.
o Traffic Conditioning (TC) actions of Marking, Absolute Dropping, o Actions of Marking, Absolute Dropping, Counting and
Counting and Multiplexing. Multiplexing.
o Queueing elements, including capabilities of algorithmic o Queueing elements, including capabilities of algorithmic
dropping. dropping and scheduling.
o Certain combinations of traffic classification, traffic o Certain combinations of the above functional datapath elements
conditioning and queueing elements. into higher-level blocks known as Traffic Conditioning Blocks
(TCBs).
The components and combinations of components described in this document The components and combinations of components described in this document
form building blocks that need to be manageable by Diffserv form building blocks that need to be manageable by Diffserv
configuration and management tools. One of the goals of this document is configuration and management tools. One of the goals of this document is
to show how a model of a Diffserv device can be built using these 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 component blocks. This model is in the form of a connected directed
acyclic graph (DAG) of functional datapath elements that describes the acyclic graph (DAG) of functional datapath elements that describes the
traffic conditioning and queueing behaviors that any particular packet traffic conditioning and queueing behaviors that any particular packet
will experience when forwarded to the Diffserv router. will experience when forwarded to the Diffserv router.
The following diagram illustrates the major functional blocks of a Figure 1 illustrates the major functional blocks of a Diffserv router:
Diffserv router:
3.1.1. Datapath 3.1.1. Datapath
An ingress interface, routing core and egress interface are illustrated An ingress interface, routing core and egress interface are illustrated
at the center of the diagram. In actual router implementations, there at the center of the diagram. In actual router implementations, there
may be an arbitrary number of ingress and egress interfaces may be an arbitrary number of ingress and egress interfaces
interconnected by the routing core. The routing core element serves as interconnected by the routing core. The routing core element serves as
an abstraction of a router's normal routing and switching functionality. an abstraction of a router's normal routing and switching functionality.
The routing core moves packets between interfaces according to policies The routing core moves packets between interfaces according to policies
outside the scope of Diffserv. The actual queueing delay and packet loss outside the scope of Diffserv. The actual queueing delay and packet loss
behavior of a specific router's switching fabric/backplane is not
modeled by the routing core; these should be modeled using the
functional datapath elements described later. The routing core should be
thought of as an infinite bandwidth, zero- delay backplane connecting
ingress and egress interfaces.
The components of interest on the ingress/egress interfaces are the
functional datapath elements (e.g. classifiers, queueing elements) that
support Diffserv traffic conditioning and per-hop behaviors [DSARCH].
These are the fundamental components comprising a Diffserv router and
will be the focal point of our conceptual model.
3.1.2. Configuration and Management Interface
Diffserv operating parameters are monitored and provisioned through this
interface. Monitored parameters include statistics regarding traffic
carried at various Diffserv service levels. These statistics may be
important for accounting purposes and/or for tracking compliance to
Traffic Conditioning Specifications (TCSs) [DSTERMS] negotiated with
+---------------+ +---------------+
| Diffserv | | Diffserv |
Mgmt | configuration | Mgmt | configuration |
<----+-->| & management |------------------+ <----+-->| & management |------------------+
SNMP,| | interface | | SNMP,| | interface | |
COPS | +---------------+ | COPS | +---------------+ |
etc. | | | etc. | | |
| | | | | |
| v v | v v
| +-------------+ +-------------+ | +-------------+ +-------------+
skipping to change at page 6, line 31 skipping to change at page 7, line 31
| | | | | |
| | | | | |
| +------------+ | | +------------+ |
+-->| QOS agent | | +-->| QOS agent | |
-------->| (optional) |---------------------+ -------->| (optional) |---------------------+
QOS | (e.g. RSVP)| QOS | (e.g. RSVP)|
cntl +------------+ cntl +------------+
msgs msgs
Figure 1: Diffserv Router Major Functional Blocks Figure 1: Diffserv Router Major Functional Blocks
behavior of a specific router's switching fabric/backplane is not
modeled by the routing core; these should be modeled using the
functional elements described later. The routing core should be thought
of as an infinite bandwidth, zero- delay backplane connecting ingress
and egress interfaces.
The components of interest on the ingress/egress interfaces are the
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.
3.1.2. Configuration and Management Interface
Diffserv operating parameters are monitored and provisioned through this
interface. Monitored parameters include statistics regarding traffic
carried at various Diffserv service levels. These statistics may be
important for accounting purposes and/or for tracking compliance to
Traffic Conditioning Specifications (TCSs) [DSTERMS] negotiated with
customers. Provisioned parameters are primarily classification rules, TC customers. Provisioned parameters are primarily classification rules, TC
and PHB configuration parameters. The network administrator interacts and PHB configuration parameters. The network administrator interacts
with the Diffserv configuration and management interface via one or more with the Diffserv configuration and management interface via one or more
management protocols, such as SNMP or COPS, or through other router management protocols, such as SNMP or COPS, or through other router
configuration tools such as serial terminal or telnet consoles. configuration tools such as serial terminal or telnet consoles.
Specific policy objectives are presumed to be installed by or retrieved Specific policy rules and goals governing the Diffserv behaviour of a
from policy management mechanisms. However, diffserv routers are subject router are presumed to be installed by policy management mechanisms.
to implementation decisions which form a meta- policy that scopes the However, Diffserv routers are subject to implementation decisions which
kinds of policies which can be created. form a meta- policy that scopes the kinds of policies which can be
successfully implemented by the router. External reporting of such
implementation capabilities are considered out of scope for this
document.
3.1.3. Optional QoS Agent Module 3.1.3. Optional QoS Agent Module
Diffserv routers may snoop or participate in either per-microflow or Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the
RSVP protocol. Snooping of RSVP messages may be used, for example, to RSVP protocol. Snooping of RSVP messages may be used, for example, to
learn how to classify traffic without actually participating as a RSVP learn how to classify traffic without actually participating as a RSVP
protocol peer. Diffserv routers may reject or admit RSVP reservation protocol peer. Diffserv routers may reject or admit RSVP reservation
requests to provide a means of admission control to Diffserv-based requests to provide a means of admission control to Diffserv-based
services or they may use these requests to trigger provisioning changes services or they may use these requests to trigger provisioning changes
for a flow-aggregation in the Diffserv network. A flow-aggregation in for a flow-aggregation in the Diffserv network. A flow-aggregation in
this context might be equivalent to a Diffserv BA or it may be more this context might be equivalent to a Diffserv BA or it may be more
fine-grained, relying on a MF classifier [DSARCH]. Note that the fine-grained, relying on a MF classifier [DSARCH]. Note that the
conceptual model of such a router implements the Integrated Services conceptual model of such a router implements the Integrated Services
Model as described in [INTSERV], applying the control plane controls to Model as described in [INTSERV], applying the control plane controls to
the data classified and conditioned in the data plane, as desribed in the data classified and conditioned in the data plane, as desribed in
skipping to change at page 7, line 43 skipping to change at page 8, line 27
Note that a QoS Agent component of a Diffserv router, if present, might Note that a QoS Agent component of a Diffserv router, if present, might
be active only in the control plane and not in the data plane. In this be active only in the control plane and not in the data plane. In this
scenario, RSVP could be used merely to signal reservation state without scenario, RSVP could be used merely to signal reservation state without
installing any actual reservations in the data plane of the Diffserv installing any actual reservations in the data plane of the Diffserv
router: the data plane could still act purely on Diffserv DSCPs and router: the data plane could still act purely on Diffserv DSCPs and
provide PHBs for handling data traffic without the normal per-microflow provide PHBs for handling data traffic without the normal per-microflow
handling expected to support some Intserv services. handling expected to support some Intserv services.
3.2. Hierarchical Model of Diffserv Components 3.2. Hierarchical Model of Diffserv Components
This document focuses on the Diffserv-specific components of the router: This document focuses on the Diffserv-specific components of the router.
classification, traffic conditioning and queueing functions. Figure 2 Figure 2 shows a high-level view of ingress and egress interfaces of a
shows a high-level view of ingress and egress interfaces of a router. router. The diagram illustrates two Diffserv router interfaces, each
The diagram illustrates two Diffserv router interfaces, each having an having an ingress and an egress component. It shows classification,
ingress and an egress component. It shows classification, meter, action metering, action and queueing functions which might be instantiated on
and queueing elements which might be instantiated on each interface's each interface's ingress and egress component.
ingress and egress component. The TC functionality is implemented by a
combination of classification, action, meter and queueing elements.
In principle, if one were to construct a network entirely out of two- In principle, if one were to construct a network entirely out of two-
port routers (in appropriate places connected by LANs or similar media), port routers (in appropriate places connected by LANs or similar media),
then it would be necessary for each router to perform four QoS control then it would be necessary for each router to perform four QoS control
functions in the datapath on traffic in each direction: functions in the datapath on traffic in each direction:
- Classify each message according to some set of rules. - Classify each message according to some set of rules, possibly just
a "match everything" rule.
- If necessary, determine whether the data stream the message is part - If necessary, determine whether the data stream the message is part
of is within or outside its rate by metering the stream. of is within or outside its rate by metering the stream.
- Perform a set of resulting actions, including applying a drop - Perform a set of resulting actions, including applying a drop
policy appropriate to the classification and queue in question and policy appropriate to the classification and queue in question and
perhaps additionally marking the traffic with a Differentiated perhaps additionally marking the traffic with a Differentiated
Services Code Point (DSCP) as defined in [DSCP]. Services Code Point (DSCP) as defined in [DSCP].
- Enqueue the traffic for output in the appropriate queue, which may
either shape the traffic or simply forward it with some minimum
rate or maximum latency.
If the network is now built out of N-port routers, the expected behavior
of the network should be identical. Therefore, this model must provide
for essentially the same set of functions on the ingress as on the
egress port of the router. Some interfaces will be "edge" interfaces and
some will be "interior" to the Differentiated Services domain. The one
point of difference between an ingress and an egress interface is that
Interface A Interface B Interface A Interface B
+-------------+ +---------+ +-------------+ +-------------+ +---------+ +-------------+
| ingress i/f | | | | egress i/f | | ingress i/f | | | | egress i/f |
| classify, | | | | classify, | | classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |---> --->| meter, |---->| |---->| meter, |--->
| action, | | | | action, | | action, | | | | action, |
| queueing | | | | queueing | | queueing | | | | queueing |
+-------------+ | routing | +-------------+ +-------------+ | routing | +-------------+
| core | | core |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| egress i/f | | | | ingress i/f | | egress i/f | | | | ingress i/f |
| classify, | | | | classify, | | classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<--- <---| meter, |<----| |<----| meter, |<---
| action, | | | | action, | | action, | | | | action, |
| queueing | +---------+ | queueing | | queueing | +---------+ | queueing |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 2. Traffic Conditioning and Queueing Elements Figure 2. Traffic Conditioning and Queueing Elements
- Enqueue the traffic for output in the appropriate queue, which may
either shape the traffic or simply forward it with some minimum
rate or maximum latency.
If the network is now built out of N-port routers, the expected behavior
of the network should be identical. Therefore, this model must provide
for essentially the same set of functions on the ingress as on the
egress port of the router. Some interfaces will be "edge" interfaces and
some will be "interior" to the Differentiated Services domain. The one
point of difference between an ingress and an egress interface is that
all traffic on an egress interface is queued, while traffic on an all traffic on an egress interface is queued, while traffic on an
ingress interface will typically be queued only for shaping purposes, if ingress interface will typically be queued only for shaping purposes, if
at all. Therefore, equivalent functional elements are modelled on both at all. Therefore, equivalent functional datapath elements may be
the ingress and egress components of an interface. modelled on both the ingress and egress components of an interface.
Note that it is not mandatory that each of these functional elements be Note that it is not mandatory that each of these functional datapath
implemented on both ingress and egress components; equally, the model elements be implemented on both ingress and egress components; equally,
allows that multiple sets of these elements may be placed in series the model allows that multiple sets of these elements may be placed in
and/or in parallel at ingress or at egress. The arrangement of elements series and/or in parallel at ingress or at egress. The arrangement of
is dependent on the service requirements on a particular interface on a elements is dependent on the service requirements on a particular
particular router. By modelling these elements on both ingress and interface on a particular router. By modelling these elements on both
egress components, it is not implied that they must be implemented in ingress and egress components, it is not implied that they must be
this way in a specific router. For example, a router may implement all implemented in this way in a specific router. For example, a router may
shaping and PHB queueing on the interface egress component or may implement all shaping and PHB queueing on the interface egress component
instead implement it only on the ingress component. Furthermore, the or may instead implement it only on the ingress component. Furthermore,
classification needed to map a packet to an egress component queue (if the classification needed to map a packet to an egress component queue
present) need not be implemented on the egress component but instead may (if present) need not be implemented on the egress component but instead
be implemented on the ingress component, with the packet passed through
the routing core with in-band control information to allow for egress
queue selection.
>From a device-configuration and management perspective, the following may be implemented on the ingress component, with the packet passed
through the routing core with in-band control information to allow for
egress queue selection.
>From a device-level configuration management perspective, the following
hierarchy exists: hierarchy exists:
At the top level, the network administrator manages interfaces. At the lowest level considered here, are individual functional
Each interface consists of an ingress component and an egress datapath elements, each with their own configuration parameters and
component. Each component may contain classifier, action, meter management counters and flags.
and queueing elements.
At the next level, the network administrator manages groups of At the next level, the network administrator manages groupings of
functional elements interconnected in a DAG. These elements are these functional datapath elements interconnected in a DAG. These
organized in self-contained Traffic Conditioning Blocks (TCBs) functional datapath elements are organized in self-contained TCBs
which are used to implement some desired network policy (see which are used to implement some desired network policy (see
Section 8). One or more TCBs may be instantiated on each ingress or Section 8). One or more TCBs may be instantiated on each ingress or
egress component; they may be connected in series and/or in egress component; they may be connected in series and/or in
parallel configurations on the multiple outputs of a classifier. parallel configurations on the multiple outputs of a preceding TCB.
The TCB is defined optionally to include classification and A TCB can be thought of as a "black box" with one input and one or
queueing elements so as to allow for flexible functionality. A TCB more outputs (in the data path). Each interface (ingress or egress)
can be thought of as a "black box" with one input and one output in may have a different TCB configuration.
the data path. Each interface (ingress or egress) may have
different TCB configurations.
At the lowest level are individual functional elements, each with At the topmost level considered here, the network administrator
their own configuration parameters and management counters and manages interfaces. Each interface consists of an ingress component
flags. and an egress component. Each component may contain one or more
TCBs.
4. Classifiers 4. Classifiers
4.1. Definition 4.1. Definition
Classification is performed by a classifier element. Classifiers are 1:N Classification is performed by a classifier element. Classifiers are 1:N
(fan-out) devices: they take a single traffic stream as input and (fan-out) devices: they take a single traffic stream as input and
generate N logically separate traffic streams as output. Classifiers are generate N logically separate traffic streams as output. Classifiers are
parameterized by filters and output streams. Packets from the input parameterized by filters and output streams. Packets from the input
stream are sorted into various output streams by filters which match the stream are sorted into various output streams by filters which match the
contents of the packet or possibly match other attributes associated contents of the packet or possibly match other attributes associated
with the packet. Various types of classifiers are described in the with the packet. Various types of classifiers using different filters
following sections. are described in the following sections. Figure 3 illustrates a
classifier, where the outputs connect to succeeding functional datapath
elements.
We use the following diagram to illustrate a classifier, where the The simplest possible Classifier element is one that matches all packets
outputs connect to succeeding functional elements: that are applied at its input. In this case, the Classifier element is
just a no-op and may be omitted.
unclassified classified unclassified classified
traffic traffic traffic traffic
+------------+ +------------+
| |--> match Filter1 --> OutputA | |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB ------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC | |--> no match --> OutputC
+------------+ +------------+
Figure 3. An Example Classifier Figure 3. An Example Classifier
skipping to change at page 11, line 18 skipping to change at page 12, line 4
2 111111 2 111111
3 ****** (wildcard) 3 ****** (wildcard)
4.1.1. Filters 4.1.1. Filters
A filter consists of a set of conditions on the component values of a A filter consists of a set of conditions on the component values of a
packet's classification key (the header values, contents, and attributes packet's classification key (the header values, contents, and attributes
relevant for classification). In the BA classifier example above, the relevant for classification). In the BA classifier example above, the
classification key consists of one packet header field, the DSCP, and classification key consists of one packet header field, the DSCP, and
both Filter1 and Filter2 specify exact-match conditions on the value of both Filter1 and Filter2 specify exact-match conditions on the value of
the DSCP. Filter3 is a wildcard default filter which matches every the DSCP. Filter3 is a wildcard default filter which matches every
packet, but which is only selected in the event that no other more packet, but which is only selected in the event that no other more
specific filter matches. specific filter matches.
In general there are a set of possible component conditions including In general there are a set of possible component conditions including
exact, prefix, range, masked, and wildcard matches. Note that ranges can exact, prefix, range, masked and wildcard matches. Note that ranges can
be represented (with less efficiency) as a set of prefixes and that be represented (with less efficiency) as a set of prefixes and that
prefix matches are just a special case of both masked and range matches. prefix matches are just a special case of both masked and range matches.
In the case of a MF classifier [DSARCH], the classification key consists In the case of a MF classifier [DSARCH], the classification key consists
of a number of packet header fields. The filter may specify a different of a number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example below condition for each key component, as illustrated in the example below
for a IPv4/TCP classifier: for a IPv4/TCP classifier:
Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort
------ ------------- ------------- ----------- ------------ ------ ------------- ------------- ----------- ------------
skipping to change at page 12, line 17 skipping to change at page 13, line 4
Type: Masked-DSCP Type: Masked-DSCP
Value: 000111 (binary) Value: 000111 (binary)
Mask: 000111 (binary) Mask: 000111 (binary)
A packet containing DSCP = 111111 cannot be uniquely classified by this A packet containing DSCP = 111111 cannot be uniquely classified by this
pair of filters and so a precedence must be established between Filter5 pair of filters and so a precedence must be established between Filter5
and Filter6 in order to break the tie. This precedence must be and Filter6 in order to break the tie. This precedence must be
established either (a) by a manager which knows that the router can established either (a) by a manager which knows that the router can
accomplish this particular ordering e.g. by means of reported accomplish this particular ordering e.g. by means of reported
capabilities, or (b) by the router along with a mechanism to report to a 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 manager which precedence is being used. Such precedence mechanisms must
further discussion of this is outside the scope of this document. be supported in any translation of this model into specific syntax for
configuration and management protocols.
As another example, one might want first to disallow certain As another example, one might want first to disallow certain
applications from using the network at all, or to classify some applications from using the network at all, or to classify some
individual traffic streams that are not Diffserv-marked. Traffic that is individual traffic streams that are not Diffserv-marked. Traffic that is
not classified by those tests might then be inspected for a DSCP. The not classified by those tests might then be inspected for a DSCP. The
word "then" implies sequence and this must be specified by means of word "then" implies sequence and this must be specified by means of
precedence. precedence.
An unambiguous classifier requires that every possible classification An unambiguous classifier requires that every possible classification
key match at least one filter (possibly the wildcard default) and that key match at least one filter (possibly the wildcard default) and that
any ambiguity between overlapping filters be resolved by precedence. any ambiguity between overlapping filters be resolved by precedence.
Therefore, the classifiers on any given interface must be "complete" and Therefore, the classifiers on any given interface must be "complete" and
will often include an "everything else" filter as the lowest precedence will often include an "everything else" filter as the lowest precedence
element in order for the result of classification to be deterministic. element in order for the result of classification to be deterministic.
Note that this completeness is only required of the first classifier Note that this completeness is only required of the first classifier
that incoming traffic will meet as it enters an interface - subsequent that incoming traffic will meet as it enters an interface - subsequent
classifiers on an interface only need to handle the traffic that it is classifiers on an interface only need to handle the traffic that it is
known that they will receive. known that they will receive.
This model of classifier operation makes the assumption that all filters
of the same precedence be applied simultaneously. Whilst convenient from
a modelling point-of-view, this may or may not be how the classifier is
actually implemented - this assumption is not intended to dictate how
the implementation actually handles this, merely to clearly define the
required end result.
4.2. Examples 4.2. Examples
4.2.1. Behaviour Aggregate (BA) Classifier 4.2.1. Behaviour Aggregate (BA) Classifier
The simplest Diffserv classifier is a behavior aggregate (BA) classifier The simplest Diffserv classifier is a behavior aggregate (BA) classifier
[DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a [DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a
packet's IP header to determine the logical output stream to which the packet's IP header to determine the logical output stream to which the
packet should be directed. We allow only an exact-match condition on packet should be directed. We allow only an exact-match condition on
this field because the assigned DSCP values have no structure, and this field because the assigned DSCP values have no structure, and
therefore no subset of DSCP bits are significant. therefore no subset of DSCP bits are significant.
skipping to change at page 14, line 47 skipping to change at page 15, line 42
Filter15: -- VLAN 2304 Filter15: -- VLAN 2304
Type: Ieee8021QVlan Type: Ieee8021QVlan
Value: 100100000000 (binary) Value: 100100000000 (binary)
Mask: 111111111111 (binary) Mask: 111111111111 (binary)
Such classifiers may be subject of other standards or may be enterprise- Such classifiers may be subject of other standards or may be enterprise-
specific but are not discussed further here. specific but are not discussed further here.
5. Meters 5. Meters
Metering is is defined in [DSARCH]. Diffserv network providers may Metering is defined in [DSARCH]. Diffserv network providers may choose
choose to offer services to customers based on a temporal (i.e., rate) to offer services to customers based on a temporal (i.e., rate) profile
profile within which the customer submits traffic for the service. In within which the customer submits traffic for the service. In this
event, a meter might be used to trigger real-time traffic conditioning
this event, a meter might be used to trigger real-time traffic actions (e.g., marking) by routing a non-conforming packet through an
conditioning actions (e.g., marking) by routing a non-conforming packet appropriate next-stage action element. Alternatively, by counting
through an appropriate next-stage action element. Alternatively, it conforming and/or non-conforming traffic, it might also be used for
might also be used for out-of-band management functions like statistics collecting data for out-of-band management functions such as billing
monitoring for billing applications. applications.
Meters are logically 1:N (fan-out) devices (although a multiplexor can Meters are logically 1:N (fan-out) devices (although a multiplexor can
be used in front of a meter). Meters are parameterized by a temporal be used in front of a meter). Meters are parameterized by a temporal
profile and by conformance levels, each of which is associated with a profile and by conformance levels, each of which is associated with a
meter's output. Each output can be connected to another functional meter's output. Each output can be connected to another functional
element. element.
Note that this model of a meter differs slightly from that described in Note that this model of a meter differs slightly from that described in
[DSARCH]. In that description the meter is not a datapath element but is [DSARCH]. In that description the meter is not a datapath element but is
instead used to monitor the traffic stream and send control signals to instead used to monitor the traffic stream and send control signals to
action elements to dynamically modulate their behavior based on the action elements to dynamically modulate their behavior based on the
conformance of the packet. conformance of the packet. Figure 4 illustrates a meter with 3 levels of
conformance.
The following diagram illustrates a meter with 3 levels of conformance:
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
In some Diffserv examples, three levels of conformance are discussed in In some Diffserv examples, three levels of conformance are discussed in
terms of colors, with green representing conforming, yellow representing terms of colors, with green representing conforming, yellow representing
partially conforming and red representing non-conforming [AF-PHB]. These partially conforming and red representing non-conforming [AF-PHB]. These
different conformance levels may be used to trigger different queueing, different conformance levels may be used to trigger different queueing,
marking or dropping treatment later on in the processing. Other example marking or dropping treatment later on in the processing. Other example
meters use a binary notion of conformance; in the general case N levels 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 of conformance can be supported. In general there is no constraint on
the type of functional element following a meter output, but care must the type of functional datapath element following a meter output, but
be taken not to inadvertently configure a datapath that results in care must be taken not to inadvertently configure a datapath that
packet reordering within an OA. results in packet reordering that is not consistent with PHB
requirements.
A meter, according to this model, measures the rate at which packets A meter, according to this model, measures the rate at which packets
making up a stream of traffic pass it, compares the rate to some set of making up a stream of traffic pass it, compares the rate to some set of
thresholds and produces some number (two or more) potential results: a thresholds and produces some number (two or more) potential results: a
given packet is said to "conform" to the meter if, at the time that the given packet is said to "conform" to the meter if, at the time that the
packet is being looked at, the stream appears to be within the meter's packet is being looked at, the stream appears to be within the meter's
limit rate. limit rate.
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
5.1. Token-Bucket Model
The concept of conformance to a meter bears comment. The concept applied The concept of conformance to a meter bears comment. The concept applied
in several rate-control architectures, including ATM, Frame Relay, in several rate-control architectures, including ATM, Frame Relay,
Integrated Services and Differentiated Services, is variously described Integrated Services and Differentiated Services, is variously described
as a "leaky bucket" or a "token bucket". as a "leaky bucket" or a "token bucket". Both token buckets and leaky
buckets are, by definition, theoretical relationships between some
defined burst_size, rate and interval:
A leaky bucket algorithm is primarily used for traffic shaping (handled rate = burst_size/interval
under Queues and Schedulers in this model): traffic theoretically
departs from a device at a rate of one bit every so many time units but,
in fact, departs in multi-bit units (packets) at a rate approximating
that. It is also possible to build multi-rate leaky buckets, in which
traffic departs from the switch at varying rates depending on recent
activity or inactivity.
A simple token bucket is usually used in a Meter to measure the behavior Thus, a token bucket or leaky bucket might specify an information rate
of a peer's leaky bucket, for verification purposes. It is, by of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token
definition, a relationship between some defined burst_size, rate and rate is 1,200,000 bits per second, the token burst is 12,000 bits and
interval: the token interval is 10 milliseconds. The specification says that
conforming traffic will in the worst case come in 100 bursts per second
of 1500 bytes and at a rate not to exceed 1.2 Mbps.
interval = burst_size/rate A leaky bucket algorithm is primarily used for traffic shaping (handled
or under Queues and Schedulers in this model). Traffic theoretically
rate = burst_size/interval departs from a device at a rate of one bit every so many time units (in
the example, one bit every 0.83 microseconds) but, in fact, departs in
multi-bit units (packets) at a rate approximating that. In the example,
it might send one 1500 byte packet every 10 ms, or one 500 byte packet
every 3.3 ms. It is also possible to build multi-rate leaky buckets, in
which traffic departs from the switch at varying rates depending on
recent activity or inactivity.
Multi-rate token buckets (token buckets with both a peak and a mean rate Implementations generally seek as constant a transmission rate as
and sometimes more rates) are commonly used. In this case, the burst achievable. In theory, a 10 Mbps shaped transmission stream from an
size for the baseline traffic is conventionally referred to as the algorithmic implementation and a stream which is running at 10 Mbps
"committed burst" and the time interval is as specified by because its bottleneck link has been a 10 Mbps Ethernet link should be
indistinguishable. Depending on configuration, the approximation to
theoretical smoothness may vary by moving as much as an MTU from one
token interval to another. Traffic may also be jostled by traffic
competing for the same transmission resources.
interval = committed_burst/mean_rate A token bucket measures the arrival rate of traffic from another system,
which may have originally been shaped using a leaky bucket shaper or its
equivalent, and determines whether it (still) conforms to the
specification. Multi-rate token buckets (token buckets with both a peak
and a mean rate, and sometimes more rates) are commonly used, such as
described in [SRTCM] and [TRTCM]. In this case, absolute smoothness is
not expected, but conformance to one or more of the specified rates is
expected.
but additional burst sizes (each an increment over its predecessor) are Simplistically, a data stream is said to conform to a simple token
defined, which are conventionally referred to as "excess" burst sizes. bucket parameterised by a {rate, burst_size} if the system receives in
The peak rate therefore equals the sum of the burst sizes for any given any time interval, t, at most, an amount of data not exceeding (rate *
interval. t) + burst_size.
A data stream is said to conform to a simple token bucket if the switch For the multi-rate token bucket case, the data stream is said to conform
receives at most the "burst_size" of data in any time interval of length if, for each of the rates, the stream conforms to the token-bucket
"interval". In the multi-rate case, the traffic is said to conform at a profile appropriate for traffic of that class. For example, received
given level to the token bucket at if its rate does not exceed the sum traffic that arrives pre-classified as one of the "excess" rates (e.g.
of the relevant burst sizes in any given interval. Received traffic that AF12 or AF13 traffic for a device implementing the AF1x PHB) is only
arrives pre-classified as one of the "excess" rates (e.g. AF12 or AF13 compared to the relevant "excess" token bucket profile.
traffic for a device implementing the AF1x PHB) is only compared to the
relevant excess buckets.
<ed: the following paragraphs may need fixing when we can all agree on a When used as a leaky bucket shaper, this definition interacts with clock
stricter vs. looser definition: for now we assume strict schedulers and granularity in ways one might not expect. A leaky bucket releases a
lenient meters.> packet only when all of its bits would have been allowed: it does not
borrow from future capacity. If the clock is very fine grain, on the
order of the bit rate or faster, this is not an issue. But if the clock
is relatively slow (and millisecond or multi-millisecond clocks are not
unusual in networking equipment), this can introduce jitter to the
shaped stream.
The fact that data is organized into variable length packets introduces The fact that data is organized into variable length packets introduces
some uncertainty in this conformance decision. When used in a Scheduler, some uncertainty in this conformance decision. When used in a Scheduler,
a leaky bucket releases a packet only when all of its bits would have a leaky bucket releases a packet only when all of its bits would have
been allowed: it does not borrow from future capacity. When used in a been allowed: it does not borrow from future capacity. Ideally, when
Meter, a token bucket accepts a packet if any of its bits would have used in a Meter, a token bucket accepts a packet only if all of its bits
been accepted and "borrows" any excess capacity required from that would have been accepted and does not borrow excess capacity required
allotted to equivalently classified traffic in a previous or subsequent from future capacity. This is consistent with [SRTCM] and [TRTCM]. In
interval. Note that [SRTCM] and [TRTCM] insist on stricter behaviour real-world deployment, where MTUs are often larger than the burst size
from a meter than the model here insists on. offered by a link-layer network service provider and TCP is more
commonly ACK-paced than shaped using a leaky bucket, the loose model
Multiple classes of traffic, as identified by the classifier table, may offers a solution to the problems that arise. For a more detailed look
be presented to the same meter. Imagine, for example, that it is desired at the practical issues, see Appendix A.
to drop all traffic that uses any DSCP that has not been publicly
defined. A classifier entry might exist for each such DSCP, shunting it
to an "accepts everything" meter and dropping all traffic that conforms
to only that meter.
It is necessary to identify what is to be done with packets that conform
to the meter and with packets that do not. It is also necessary for the
meter to be arbitrarily extensible as some PHBs require the successive
application of an arbitrary number of meters. The approach taken in
this model is to have each meter indicate what action is to be taken for
conforming traffic and what meter is to be used for traffic which fails
to conform. With the definition of a special type of meter to which all
traffic conforms, this has the necessary flexibility.
Note that this definition of a simple token bucket meter requires that
the minimal bucket size be at least the MTU of the incoming link and it
should also be initialised with sufficient tokens to allow for at least
one MTU-sized packet to conform if it arrives at time zero.
5.1. Examples 5.2. Examples
The following are some examples of possible meters. The following are some examples of possible meters.
5.1.1. Average Rate Meter 5.2.1. Average Rate Meter
An example of a very simple meter is an average rate meter. This type of An example of a very simple meter is an average rate meter. This type of
meter measures the average rate at which packets are submitted to it meter measures the average rate at which packets are submitted to it
over a specified averaging time. over a specified averaging time.
An average rate profile may take the following form: An average rate profile may take the following form:
Meter1: Meter1:
Type: AverageRate Type: AverageRate
Profile: Profile1 Profile: Profile1
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: Counter1 NonConformingOutput: Counter1
Profile1: Profile1:
Type: AverageRate Type: AverageRate
AverageRate: 120 kbps AverageRate: 120 kbps
Delta: 100 msec Delta: 100 msec
skipping to change at page 18, line 20 skipping to change at page 19, line 24
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 time T count that indicates the total number of packets arriving between time T
(now) and time T - 100 msecs. So long as an arriving packet does not (now) and time T - 100 msecs. So long as an arriving packet does not
push the count over 12 kbits in the last 100 msec then the packet would push the count over 12 kbits in the last 100 msec then the packet would
be deemed conforming. Any packet that pushes the count over 12 kbits be deemed conforming. Any packet that pushes the count over 12 kbits
would be deemed non-conforming. Thus, this meter deems packets to would be deemed non-conforming. Thus, this meter deems packets to
correspond to one of two conformance levels: conforming or non- correspond to one of two conformance levels: conforming or non-
conforming and sends them on for the appropriate subsequent treatment. conforming and sends them on for the appropriate subsequent treatment.
5.1.2. Exponential Weighted Moving Average (EWMA) Meter 5.2.2. Exponential Weighted Moving Average (EWMA) Meter
The EWMA form of meter is easy to implement in hardware and can be The EWMA form of meter is easy to implement in hardware and can be
parameterized as follows: parameterized as follows:
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t) avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta t = t' + Delta
For a packet arriving at time t: For a packet arriving at time t:
if (avg_rate(t) > AverageRate) if (avg_rate(t) > AverageRate)
skipping to change at page 18, line 47 skipping to change at page 20, line 4
of incoming bytes in a small fixed sampling interval, Delta. Any packet of incoming bytes in a small fixed sampling interval, Delta. Any packet
that arrives and pushes the average rate over a predefined rate that arrives and pushes the average rate over a predefined rate
AverageRate is deemed non-conforming. An EWMA meter profile might look AverageRate is deemed non-conforming. An EWMA meter profile might look
something like the following: something like the following:
Meter2: Meter2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
Profile: Profile2 Profile: Profile2
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile2: Profile2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
AverageRate: 25 kbps AverageRate: 25 kbps
Delta: 10 usec Delta: 10 usec
Gain: 1/16 Gain: 1/16
5.1.3. Two-Parameter Token Bucket Meter 5.2.3. Two-Parameter Token Bucket Meter
A more sophisticated meter might measure conformance to a token bucket A more sophisticated meter might measure conformance to a token bucket
(TB) profile. A TB profile generally has two parameters, an average (TB) profile. A TB profile generally has two parameters, an average
token rate and a burst size. TB meters compare the arrival rate of token rate and a burst size. TB meters compare the arrival rate of
packets to the average rate specified by the TB profile. Logically, packets to the average rate specified by the TB profile. Logically,
tokens accumulate in a bucket at the average rate, up to a maximum 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 credit which is the burst size. Packets of length L bytes are considered
conforming if any tokens are available in the bucket at the time of conforming if any tokens are available in the bucket at the time of
packet arrival: up to L bytes may then be borrowed from future token packet arrival: up to L bytes may then be borrowed from future token
allocations. Packets are allowed to exceed the average rate in bursts up allocations. Packets are allowed to exceed the average rate in bursts up
skipping to change at page 19, line 37 skipping to change at page 20, line 40
Type: SimpleTokenBucket Type: SimpleTokenBucket
Profile: Profile3 Profile: Profile3
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile3: Profile3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 200 kbps AverageRate: 200 kbps
BurstSize: 100 kbytes BurstSize: 100 kbytes
5.1.4. Multi-Stage Token Bucket Meter 5.2.4. Multi-Stage Token Bucket Meter
More complicated TB meters might define two burst sizes and three More complicated TB meters might define two burst sizes and three
conformance levels. Packets found to exceed the larger burst size are conformance levels. Packets found to exceed the larger burst size are
deemed non-conforming. Packets found to exceed the smaller burst size deemed non-conforming. Packets found to exceed the smaller burst size
are deemed partially conforming. Packets exceeding neither are deemed are deemed partially conforming. Packets exceeding neither are deemed
conforming. Token bucket meters designed for Diffserv networks are conforming. Token bucket meters designed for Diffserv networks are
described in more detail in [SRTCM, TRTCM, GTC]; in some of these described in more detail in [SRTCM, TRTCM, GTC]; in some of these
references three levels of conformance are discussed in terms of colors, references three levels of conformance are discussed in terms of colors,
with green representing conforming, yellow representing partially with green representing conforming, yellow representing partially
conforming and red representing non- conforming. Often these multi- conforming and red representing non- conforming. Often these multi-
skipping to change at page 20, line 26 skipping to change at page 21, line 29
Profile4: Profile4:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 20 kbytes BurstSize: 20 kbytes
Profile5: Profile5:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 100 kbytes BurstSize: 100 kbytes
5.1.5. Null Meter 5.2.5. Null Meter
A null meter has only one output: always conforming, and no associated A null meter has only one output: always conforming, and no associated
temporal profile. Such a meter is useful to define in the event that the temporal profile. Such a meter is useful to define in the event that the
configuration or management interface does not have the flexibility to configuration or management interface does not have the flexibility to
omit a meter in a datapath segment. omit a meter in a datapath segment.
Meter5: Meter5:
Type: NullMeter Type: NullMeter
Output: Queue1 Output: Queue1
6. Action Elements 6. Action Elements
The classifiers and meters described up to this point are fan-out The classifiers and meters described up to this point are fan-out
elements which are generally used to determine the appropriate action to elements which are generally used to determine the appropriate action to
apply to a packet. The set of possible actions include: apply to a packet. The set of possible actions that can then be applied
include:
- Marking - Marking
- Absolute Dropping - Absolute Dropping
- Multiplexing - Multiplexing
- Counting - Counting
- Null action - do nothing - Null action - do nothing
The corresponding action elements are described in the following The corresponding action elements are described in the following
sections. sections.
Diffserv nodes may apply shaping, policing and/or marking to traffic Diffserv nodes may apply shaping, policing and/or marking to traffic
streams that exceed the bounds of their TCS in order to prevent a streams that exceed the bounds of their TCS in order to prevent a
traffic stream from seizing more than its share of resources from a traffic stream from seizing more than its share of resources from a
Diffserv network. Shaping, sometimes considered as a TC action, is Diffserv network. Shaping, sometimes considered as a TC action, is
treated as a part of the queueing module in this model, as is the use of treated as a part of the queueing module in this model, as is the use of
Algorithmic Dropping techniques - see section 7. Policing is modelled Algorithmic Dropping techniques - see section 7. Policing is modelled
as the combination of either a meter or a scheduler with either an as either a concatenation of a Meter with an Absolute Dropper or as a
absolute dropper or an algorithmic dropper. These elements will discard concatenation of an Algorithmic Dropper with a Scheduler. These elements
packets which exceed the TCS. Marking is performed by a marker, which will discard packets which exceed the TCS. Marking is performed by a
(in this context) alters the DSCP, and thus the PHB, of the packet to Marker Action, which (in this context) alters the DSCP, and thus the
give it a lower-grade treatment at subsequent Diffserv nodes. PHB, of the packet to give it a lower-grade treatment at subsequent
Diffserv nodes.
6.1. Marker 6.1. Marker
Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an IP Markers are 1:1 elements which set a codepoint (e.g. the DSCP in an IP
header). Markers may also act on unmarked packets (e.g. those submitted header). Markers may also act on unmarked packets (e.g. those submitted
with DSCP of zero) or may re-mark previously marked packets. In with DSCP of zero) or may re-mark previously marked packets. In
particular, the model supports the application of marking based on a particular, the model supports the application of marking based on a
preceding classifier match. The mark set in a packet will determine its preceding classifier match. The mark set in a packet will determine its
subsequent treatment in downstream nodes of a network and possibly also subsequent treatment in downstream nodes of a network and possibly also
in subsequent processing stages within this router. in subsequent processing stages within this router.
DSCP Markers for Diffserv are normally parameterized by a single DSCP Markers for Diffserv are normally parameterized by a single
parameter: the 6-bit DSCP to be marked in the packet header. parameter: the 6-bit DSCP to be marked in the packet header.
Marker1: Marker1:
Type: DSCPMarker Type: DSCPMarker
Mark: 010010 Mark: 010010
6.2. Absolute Dropper 6.2. Absolute Dropper
Absolute droppers simply discard packets. There are no parameters for Absolute Droppers simply discard packets. There are no parameters for
these droppers. Because this dropper is a terminating point of the these droppers. Because this Algorithmic Dropper is a terminating point
datapath and have no outputs, it is probably desirable to forward the of the datapath and has no outputs, it is probably desirable to forward
packet through a counter action first for instrumentation purposes. the packet through a Counter Action first for instrumentation purposes.
AbsoluteDropper1: AbsoluteDropper1:
Type: AbsoluteDropper Type: AbsoluteDropper
Absolute droppers are not the only elements than can cause a packet to Absolute Droppers are not the only elements than can cause a packet to
be discarded: another element is an Algorithmic Dropper element (see be discarded: another element is an Algorithmic Dropper element (see
Section 6.6). However, since this element's behavior is closely tied the Section 7.1.3). However, since this element's behavior is closely tied
the state of one or more queues, we choose to distinguish it as a
state of one or more queues, we choose to distinguish it as a separate separate functional datapath element.
functional element.
6.3. Multiplexer 6.3. Multiplexor
It is occasionally necessary to multiplex traffic streams into a 1:1 or It is occasionally necessary to multiplex traffic streams into a
1:N action element or classifier. A M:1 (fan-in) multiplexer is a functional datapath element with a single input. A M:1 (fan-in)
simple logical device for merging traffic streams. It is parameterized multiplexor is a simple logical device for merging traffic streams. It
by its number of incoming ports. is parameterized by its number of incoming ports.
Mux1: Mux1:
Type: Multiplexer Type: Multiplexor
Output: Queue2 Output: Queue2
6.4. Counter 6.4. Counter
One passive action is to account for the fact that a data packet was One passive action is to account for the fact that a data packet was
processed. The statistics that result might be used later for customer processed. The statistics that result might be used later for customer
billing, service verification, or network engineering purposes. Counters billing, service verification or network engineering purposes. Counters
are 1:1 functional elements which update a counter by L and a packet are 1:1 functional datapath elements which update a counter by L and a
counter by 1 every time a L-byte sized packet passes through them. packet counter by 1 every time a L-byte sized packet passes through
Counters can be used to count packets about to be be dropped by a them. Counters can be used to count packets about to be be dropped by an
dropper or a queueing element. Absolute Dropper or to count packets arriving at or departing from some
other functional element.
Counter1: Counter1:
Type: Counter Type: Counter
Output: Queue1 Output: Queue1
6.5. Null Action 6.5. Null Action
A null action has one input and one output. The element performs no A null action has one input and one output. The element performs no
action on the packet. Such an element is useful to define in the event action on the packet. Such an element is useful to define in the event
that the configuration or management interface does not have the that the configuration or management interface does not have the
flexibility to omit an action element in a datapath segment. flexibility to omit an action element in a datapath segment.
Null1: Null1:
Type: Null Type: Null
Output: Queue1 Output: Queue1
7. Queueing Blocks 7. Queueing Elements
Queueing blocks modulate the transmission of packets belonging to the Queueing elements modulate the transmission of packets belonging to the
different traffic streams and determine their ordering, possibly storing different traffic streams and determine their ordering, possibly storing
them temporarily or discarding them. Packets are usually stored either them temporarily or discarding them. Packets are usually stored either
because there is a resource constraint (e.g., available bandwidth) which because there is a resource constraint (e.g., available bandwidth) which
prevents immediate forwarding, or because the queueing block is being prevents immediate forwarding, or because the queueing block is being
used to alter the temporal properties of a traffic stream (i.e. used to alter the temporal properties of a traffic stream (i.e.
shaping). Packets are discarded either because of buffering limitations, shaping). Packets are discarded either because of buffering limitations,
because a buffer threshold is exceeded (including when shaping is because a buffer threshold is exceeded (including when shaping is
performed), as a feedback control signal to reactive control protocols performed), as a feedback control signal to reactive control protocols
such as TCP, because a meter exceeds a configured rate (i.e. policing). such as TCP, because a meter exceeds a configured profile (i.e.
policing).
The queueing block in this model is a logical abstraction of a queueing The queueing elements in this model represent a logical abstraction of a
system, which is used to configure PHB-related parameters. There is no queueing system, which is used to configure PHB-related parameters. The
conformance to this model. The model can be used to represent a broad model can be used to represent a broad variety of possible
variety of possible implementations. However, it need not necessarily implementations. However, it need not necessarily map one-to-one with
map one-to-one with physical queueing systems in a specific router physical queueing systems in a specific router implementation.
implementation. Implementors should map the configurable parameters of Implementors should map the configurable parameters of the
the implementation's queueing systems to these queueing block parameters implementation's queueing systems to these queueing element parameters
as appropriate to achieve equivalent behaviors. as appropriate to achieve equivalent behaviors.
7.1. Queueing Model 7.1. Queueing Model
Queueing is a function a which lends itself to innovation. It must be Queueing is a function a which lends itself to innovation. It must be
modelled to allow a broad range of possible implementations to be modelled to allow a broad range of possible implementations to be
represented using common structures and parameters. This model uses represented using common structures and parameters. This model uses
functional decomposition as a tool to permit the needed lattitude. functional decomposition as a tool to permit the needed lattitude.
Queueing sytems, such as the queueing block defined in this model, Queueing systems perform three distinct, but related, functions: they
perform three distinct, but related, functions: they store packets, store packets, they modulate the departure of packets belonging to
they modulate the departure of packets belonging to various traffic various traffic streams and they selectively discard packets. This model
streams and they selectively discard packets. This model decomposes the decomposes the queueing block into the component elements that perform
queueing block into the component elements that perform each of these each of these functions: Queues, Schedulers and Algorithmic Droppers,
functions. These elements which may be connected together either respectively. These elements may be connected together as part of a TCB
dynamically or statically to construct queueing blocks. A queueing containing one or more Queues, zero or more Algorithmic Droppers and one
block is thus composed of of one or more FIFOs, one or more Schedulers or more Schedulers.
and zero or more Algorithmic Droppers.
<ed: should this be *one* or more? There are valid cases that do The remainder of this section discusses FIFO Queues: typically, the
not require a dropper but they are exceptional.> Queue element of this model will be implemented as a FIFO data
structure. However, this does not preclude implementations which are not
strictly FIFO, in that they also support operations that remove or
examine packets (e.g., for use by discarders) other than at the head or
tail. However, such operations MUST NOT have the effect of reordering
packets belonging to the same microflow.
Note that the term FIFO has multiple different common usages: it is Note that the term FIFO has multiple different common usages: it is
sometimes taken to mean, among other things, a data structure that sometimes taken to mean, among other things, a data structure that
permits items to be removed only in the order in which they were permits items to be removed only in the order in which they were
inserted or a service discipline which is non- reordering. inserted or a service discipline which is non- reordering.
7.1.1. FIFO 7.1.1. FIFO Queue
In this model, a FIFO element is a data structure which at any time may
contain zero or more packets. It may have one or more thresholds
associated with it. A FIFO has one or more inputs and exactly one
output. It must support an enqueue operation to add a packet to the tail
of the queue, and a dequeue operation to remove a packet from the head
of the queue. Packets must be dequeued in the order in which they were In this model, a FIFO Queue element is a data structure which at any
enqueued. A FIFO has a current depth, which indicates the number of time may contain zero or more packets. It may have one or more
thresholds associated with it. A FIFO has one or more inputs and exactly
one output. It must support an enqueue operation to add a packet to the
tail of the queue, and a dequeue operation to remove a packet from the
head of the queue. Packets must be dequeued in the order in which they
were enqueued. A FIFO has a current depth, which indicates the number of
packets that it contains at a particular time. FIFOs in this model are packets that it contains at a particular time. FIFOs in this model are
modelled without inherent limits on their depth - obviously this does modelled without inherent limits on their depth - obviously this does
not reflect the reality of implementations: FIFO size limits are not reflect the reality of implementations: FIFO size limits are
modelled here by an algorithmic dropper associated with the FIFO, modelled here by an algorithmic dropper associated with the FIFO,
typically at its input. It is quite likely that, every FIFO will be typically at its input. It is quite likely that, every FIFO will be
preceded by an algorithmic dropper. One exception might be the case preceded by an algorithmic dropper. One exception might be the case
where the packet stream has already been policed to a profile that can where the packet stream has already been policed to a profile that can
never exceed the scheduler bandwidth available at the FIFO's output - never exceed the scheduler bandwidth available at the FIFO's output -
this would not need an algorithmic dropper at the input to the FIFO. this would not need an algorithmic dropper at the input to the FIFO.
This representation of a FIFO allows for one common type of depth limit, This representation of a FIFO allows for one common type of depth limit,
one that results from a FIFO supplied from a limited pool of buffers, one that results from a FIFO supplied from a limited pool of buffers,
shared between multiple FIFOs. shared between multiple FIFOs.
<ed: should we instead model a FIFO as having a single input and
use a "multiplexer" at its input if it needs to collect from
multiple input sources?>
Typically, the FIFO element of this model will be implemented as a FIFO
data structure. However, this does not preclude implementations which
are not strictly FIFO, in that they also support operations that remove
or examine packets (e.g., for use by discarders) other than at the head
or tail. However, such operations MUST NOT have the effect of reordering
packets belonging to the same microflow.
In an implementation, packets are presumably stored in one or more In an implementation, packets are presumably stored in one or more
buffers. Buffers are allocated from one or more free buffer pools. If buffers. Buffers are allocated from one or more free buffer pools. If
there are multiple instances of a FIFO, their packet buffers may or may there are multiple instances of a FIFO, their packet buffers may or may
not be allocated out of the same free buffer pool. Free buffer pools may not be allocated out of the same free buffer pool. Free buffer pools may
also have one or more threshold associated with them, which may affect also have one or more threshold associated with them, which may affect
discarding and/or scheduling. Other than this, buffering mechanisms are discarding and/or scheduling. Other than this, buffering mechanisms are
implementation specific and not part of this model. implementation specific and not part of this model.
A FIFO might be represented using the following parameters: A FIFO might be represented using the following parameters:
Fifo1: Queue1:
Type: FIFO Type: FIFO
Output: Scheduler1 Output: Scheduler1
Note that a FIFO must provide triggers and/or current state information Note that a FIFO must provide triggers and/or current state information
to other elements upstream and downstream from it: in particular, it is to other elements upstream and downstream from it: in particular, it is
likely that the current depth will need to be used by Algorithmic likely that the current depth will need to be used by Algorithmic
Dropper elements placed before or after the FIFO. It will also likely Dropper elements placed before or after the FIFO. It will also likely
need to provide an implicit "I have packets for you" signal to need to provide an implicit "I have packets for you" signal to
downstream Scheduler elements. downstream Scheduler elements.
7.1.2. Scheduler 7.1.2. Scheduler
A scheduler is an element which gates the departure of each packet that A scheduler is an element which gates the departure of each packet that
arrives at one of its inputs, based on a service discipline. It has one arrives at one of its inputs, based on a service discipline. It has one
or more input and exactly one output. Each input has an upstream element or more input and exactly one output. Each input has an upstream element
to which it is connected, and a set of parameters that affects the to which it is connected, and a set of parameters that affects the
scheduling of packets received at that input. scheduling of packets received at that input.
skipping to change at page 27, line 20 skipping to change at page 28, line 23
Input3: Input3:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: none MinRateProfile: none
Priority: 3 Priority: 3
7.1.3. Algorithmic Dropper 7.1.3. Algorithmic Dropper
An Algorithmic Dropper is an element which selectively discards packets An Algorithmic Dropper is an element which selectively discards packets
that arrive at its input, based on a discarding algorithm. It has one that arrive at its input, based on a discarding algorithm. It has one
data input and one output. In this model (but not necessarily in a real data input and one output.
implementation), a packet enters the dropper at its input and either its
buffer is returned to a free buffer pool or the packet exits the dropper
at the output.
In this model (but not necessarily in a real implementation), a packet
enters the dropper at its input and either its buffer is returned to a
free buffer pool or the packet exits the dropper at the output.
Alternatively, an Algorithmic Dropper may invoke operations on a FIFO Alternatively, an Algorithmic Dropper may invoke operations on a FIFO
which selectively removes a packet, then return its buffer to the free which selectively removes a packet, then return its buffer to the free
buffer pool, based on a discarding algorithm. In this case, the buffer pool, based on a discarding algorithm. In this case, the
operation is modelled as a side-effect on the FIFO upon which it operation ould be modelled as a side-effect on the FIFO upon which it
operates, rather than as having a discrete input and output. These two operated, rather than as having a discrete input and output. These two
treatments are equivalent and we choose the former here. treatments are equivalent and we choose the former here.
The Algorithmic Dropper is modelled as having a single input. However, The Algorithmic Dropper is modelled as having a single input. It is
it is likely that packets which were classified differently by a possible that packets which were classified differently by a Classifier
Classifier in this TCB will end up passing through the same dropper. The in this TCB will end up passing through the same dropper. The dropper's
dropper's algorithm may need to apply different calculations based on algorithm may need to apply different calculations based on
characteristics of the incoming packet e.g. its DSCP. So there is a characteristics of the incoming packet e.g. its DSCP. So there is a
need, in implementations of this model, to be able to relate information need, in implementations of this model, to be able to relate information
about which classifier element was matched by a packet from a Classifier about which classifier element was matched by a packet from a Classifier
to an Algorithmic Dropper. This is modelled here as a reverse pointer to an Algorithmic Dropper. In the rare cases where this is required,
from one of the drop probability calculation algorithms inside the the chosen model is to insert another Classifier element at this point
dropper to the classifier element that selects this algorithm. in the flow and for it to feed into multiple Algorithmic Dropper
elements, each one implementing a drop calculation that is independent
of any classification keys of the packet: this will likely require the
creation of a new TCB to contain the Classifier and the Algorithmic
Dropper elements.
There are many formulations of a model that could represent this There are many other formulations of a model that could represent this
linkage, other than the one described above: one way would have been to linkage, other than the one described above: one formulation would have
have multiple "inputs" fed from the preceding elements, leading
eventually to the classifier elements that matched the packet. Another
formulation might have been for the Classifier to (logically) include
some sort of "classification identifier" along with the packet along its
path, for use by any subsequent element. Yet another could have been to
include a classifier inside the dropper, in order for it to pick out the
drop algorithm to be applied. All of these other approaches were deemed been to have a pointer from one of the drop probability calculation
to be more clumsy or less useful than the approach taken here. algorithms inside the dropper to the original Classifier element that
selects this algorithm. Another way would have been to have multiple
"inputs" to the Algorithmic Dropper element fed from the preceding
elements, leading eventually back to the Classifier elements that
matched the packet. Yet another formulation might have been for the
Classifier to (logically) include some sort of "classification
identifier" along with the packet along its path, for use by any
subsequent element. And yet another could have been to include a
classifier inside the dropper, in order for it to pick out the drop
algorithm to be applied. All of these other approaches were deemed to be
more clumsy or less useful than the approach taken here.
An Algorithmic Dropper, shown in Figure 5, has one or more triggers that An Algorithmic Dropper, shown in Figure 5, has one or more triggers that
cause it to make a decision whether or not to drop one (or possibly more cause it to make a decision whether or not to drop one (or possibly more
than one) packet. A trigger may be internal (the arrival of a packet at than one) packet. A trigger may be internal (the arrival of a packet at
the input to the dropper) or it may be external (resulting from one or the input to the dropper) or it may be external (resulting from one or
more state changes at another element, such as a FIFO depth exceeding a more state changes at another element, such as a FIFO depth exceeding a
threshold or a scheduling event). It is likely that an instantaneous threshold or a scheduling event). It is likely that an instantaneous
FIFO depth will need to be smoothed over some averaging interval. Some FIFO depth will need to be smoothed over some averaging interval. Some
dropping algorithms may require several trigger inputs feeding back from dropping algorithms may require several trigger inputs feeding back from
events elsewhere in the system e.g. smoothing functions that calculate events elsewhere in the system e.g. smoothing functions that calculate
skipping to change at page 28, line 28 skipping to change at page 29, line 38
outside the scope of this document and are not modelled here, we merely outside the scope of this document and are not modelled here, we merely
indicate where they might be added in the model. indicate where they might be added in the model.
A trigger may be a boolean combination of events (e.g. a FIFO depth A trigger may be a boolean combination of events (e.g. a FIFO depth
exceeding a threshold OR a buffer pool depth falling below a threshold). exceeding a threshold OR a buffer pool depth falling below a threshold).
The dropping algorithm makes a decision on whether to forward or to The dropping algorithm makes a decision on whether to forward or to
discard a packet. It takes as its parameters some set of dynamic discard a packet. It takes as its parameters some set of dynamic
parameters (e.g. averaged or instantaneous FIFO depth) and some set of parameters (e.g. averaged or instantaneous FIFO depth) and some set of
static parameters (e.g. thresholds) and possibly parameters associated static parameters (e.g. thresholds) and possibly parameters associated
+------------------+ +-----------+
| +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
Figure 5. Algorithmic Dropper + Queue
with the packet (e.g. its PHB, as determined by a classifier, which will with the packet (e.g. its PHB, as determined by a classifier, which will
determine on which of the droppers inputs trhe packet arrives). It may determine on which of the droppers inputs the packet arrives). It may
also have internal state and is likely to keep counters regarding the also have internal state and is likely to keep counters regarding the
dropped packets (there is no appropriate place here to include a Counter dropped packets (there is no appropriate place here to include a Counter
Action element). Action element).
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of
dropping algorithms. Tail-dropping and head-dropping are effected by the dropping algorithms. Tail-dropping and head-dropping are effected by the
location of the dropper relative to the FIFO. location of the dropper relative to the FIFO.
Note that, although an Algorithmic Dropper may require knowledge of data Note that, although an Algorithmic Dropper may require knowledge of data
fields in a packet, as discovered by a Classifier in the same TCB, it fields in a packet, as discovered by a Classifier in the same TCB, it
may not modify the packet (i.e. it is not a marker). may not modify the packet (i.e. it is not a marker).
<ed: have rearranged this example so as not to include a Classifier +--------------------------------------+
in the Dropper - this leads to needing either multiple inputs or an | +------------+ +-----------+ |Algorithmic
implicit classification stage to separate the in- and out-of- | | smoothing | n |trigger & | |Dropper
profile traffic. We have chosen the former representation.> | | function(s)|---/--->|discard | |
| | (optional) | |calc. | |
| +------------+ +-----------+ |
| ^ TailDrop| |HeadDrop |
+------------|-------------|-|---------+
| | |
+---|-------------+ |
| | |
v |Depth v
Input ----------------------+ to Scheduler
-----------------------------> |x|x|x|x|x|x|x|------------------->
----------------------+
FIFO |
|
| | |
| v | bit-bucket
+---+
A dropper which uses a RIO algorithm might be represented using the Figure 5. Algorithmic Dropper + Queue
following parameters:
An Algorithmic Dropper which uses a RIO algorithm might be represented
using the following parameters:
AlgorithmicDropper1: AlgorithmicDropper1:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RIO Discipline: RIO
Trigger: Internal Trigger: Internal
Output: Fifo1 Output: Fifo1
InputA: (in profile) InputA: (in profile)
MinThresh: Fifo1.Depth > 20 kbyte MinThresh: Fifo1.Depth > 20 kbyte
MaxThresh: Fifo1.Depth > 30 kbyte MaxThresh: Fifo1.Depth > 30 kbyte
InputB: (out of profile) InputB: (out of profile)
MinThresh: Fifo1.Depth > 10 kbyte MinThresh: Fifo1.Depth > 10 kbyte
MaxThresh: Fifo1.Depth > 20 kbyte MaxThresh: Fifo1.Depth > 20 kbyte
SampleWeight .002 SampleWeight .002
MaxDropProb 1% MaxDropProb 1%
Another form of dropper, a threshold-dropper, might be represented using Another form of Algorithmic Dropper, a threshold-dropper, might be
the following parameters: represented using the following parameters:
AlgorithmicDropper2: AlgorithmicDropper2:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Fifo2.Depth > 20 kbyte Trigger: Fifo2.Depth > 20 kbyte
Output: Fifo1 Output: Fifo1
Yet another dropper which drops all out-of-profile packets whenever the Yet another Algorithmic Dropper which drops all out-of-profile packets
FIFO threshold exceeds a certain depth (this dropper is not part of the whenever the FIFO threshold exceeds a certain depth (this Algorithmic
larger TCB example) might be represented with the following parameters: Dropper is not part of the larger TCB example) might be represented with
the following parameters:
AlgorithmicDropper3: AlgorithmicDropper3:
Type: AlgorithmicDropper2Input Type: AlgorithmicDropper2Input
Discipline: Drop-out-packets-on-threshold Discipline: Drop-out-packets-on-threshold
Output: Fifo3 Output: Fifo3
InputA: (in profile) InputA: (in profile)
Trigger: none Trigger: none
InputB: (out of profile) InputB: (out of profile)
Trigger: Fifo3.Depth > 100 kbyte Trigger: Fifo3.Depth > 100 kbyte
<ed: this models the dropper without using an embedded Classifier
which seems a cleaner model than embedding a classifier here>
7.1.4. Constructing queueing blocks from the elements 7.1.4. Constructing queueing blocks from the elements
A queueing block is constructed by concatenation of these elements so as A queueing block is constructed by concatenation of these functional
to meet the meta-policy objectives of the implementation, subject to the datapath elements. Elements of the same type may appear more than once
grammar rules specified in this section. in a queueing block, either in parallel or in series. Typically, a
queueing block will have relatively many elements in parallel and few in
Elements of the same type may appear more than once in a queueing block, series. Iteration and recursion are not supported constructs in this
either in parallel or in series. Typically, a queueing block will have grammar. A queueing block must have at least one Queue, zero or more
relatively many elements in parallel and few in series. Iteration and Algorithmic Droppers and at least one Scheduler. The following inter-
recursion are not supported constructs in this grammar. A queueing block connections are allowed:
must have at least one FIFO, at least one dropper, and at least one
scheduler. The following connections are allowed:
1) The input of a FIFO may be the input of the queueing block or it 1) The input of a Queue may be the input of the queueing block or it
may be connected to the output of a dropper or to an output of a may be connected to the output of an Algorithmic Dropper or to an
scheduler. output of a Scheduler.
2) Each input of a scheduler may be connected to the output of a FIFO, 2) Each input of a Scheduler may be connected to the output of a
to the output of a dropper or to the output of another scheduler. Queue, to the output of an Algorithmic Dropper or to the output of
another Scheduler.
3) The input of a dropper which has a discrete input and output may be 3) The input of an Algorithmic Dropper must be the input of the
the input of the queueing block or it may be connected to the queueing block.
output of a FIFO (e.g., head dropping).
4) The output of the queueing block may be the output of a FIFO 4) The output of the queueing block may be the output of a Queue, an
element, a discarding element or a scheduling element. Algorithmic Dropper or a Scheduler.
Note, in particular, that schedulers may operate in series such that a Note, in particular, that Schedulers may operate in series such that a
packet at the head of a FIFO feeding the concatenated schedulers is packet at the head of a Queue feeding the concatenated Schedulers is
serviced only after all of the scheduling criteria are met. For example, serviced only after all of the scheduling criteria are met. For example,
a Queue which carries EF traffic streams may be served first by a non-
work-conserving Scheduler to shape the stream to a maximum rate, then by
a work-conserving Scheduler to mix EF traffic streams with other traffic
streams. Alternatively, there might be a Queue and/or a dropper between
the two Schedulers.
a FIFO which carries EF traffic streams may be served first by a non- 7.2. Sharing load among traffic streams using queueing
work-conserving scheduler to shape the stream to a maximum rate, then by
a work-conserving scheduler to mix EF traffic streams with other traffic
streams. Alternatively, there might be a FIFO and/or a dropper between
the two schedulers.
7.2. Shaping Queues are used, in Differentiated Services, for a number of purposes.
In essence, they are simply places to store traffic until it is
transmitted. However, when several queues are used together in a
queueing system, they can also achieve effects beyond that for given
traffic streams. They can be used to limit variation in delay or impose
a maximum rate (shaping), to permit several streams to share a link in a
semi-predictable fashion (load sharing), or to move variation in delay
from some streams to other streams.
Traffic shaping is often used to condition traffic such that packets Traffic shaping is often used to condition traffic such that packets
arriving in a burst will be "smoothed" and deemed conforming by arriving in a burst will be "smoothed" and deemed conforming by
subsequent downstream meters in this or other nodes. Shaping may also be subsequent downstream meters in this or other nodes. Shaping may also be
used to isolate certain traffic streams from the effects of other used to isolate certain traffic streams from the effects of other
traffic streams of the same BA. traffic streams of the same BA.
In [DSARCH] a shaper is described as a queueing element controlled by a In [DSARCH] a shaper is described as a queueing element controlled by a
meter which defines its temporal profile. However, this representation meter which defines its temporal profile. However, this representation
of a shaper differs substantially from typical shaper implementations. of a shaper differs substantially from typical shaper implementations.
In this conceptual model, a shaper is realized by using a non-work- In this conceptual model, a shaper is realized by using a non-work-
conserving scheduler. Some implementations may elect to have queues conserving Scheduler. Some implementations may elect to have queues
whose sole purpose is shaping, while others may integrate the shaping whose sole purpose is shaping, while others may integrate the shaping
function with other buffering, discarding and scheduling associated with function with other buffering, discarding and scheduling associated with
access to a resource. Shapers operate by delaying the departure of access to a resource. Shapers operate by delaying the departure of
packets that would be deemed non-conforming by a meter configured to the packets that would be deemed non-conforming by a meter configured to the
shaper's maximum service rate profile. The packet is scheduled to depart shaper's maximum service rate profile. The packet is scheduled to depart
no sooner than such time that it would become conforming. no sooner than such time that it would become conforming.
7.2.1. Load Sharing
Load sharing is the traditional use of queues. It was theoretically
explored in a paper by Floyd [FLOYD] in 1993, but has been in use in
communications systems since the 1970's.
[DSARCH] discusses load sharing as dividing an interface among traffic
classes predictably or applying a minimum rate to each of a set of
traffic classes, which might be measured as an absolute lower bound on
the rate a traffic stream achieves, or a fraction of the rate an
interface offers. It is generally implemented as some form of weighted
round robin among a set of FIFO queues or WFQ system. This has
interesting side-effects.
A key effect sought is to ensure that the mean rate the traffic in a
stream experiences is never lower than some threshold when there is at
least that much traffic to send. When there is less traffic than this,
the queue tends to be starved for traffic, meaning that the queuing
system will not delay its traffic by very much. When there is
significantly more and the queue fills, packets in this class will be
delayed significantly more than traffic in other classes that are under-
using their available capacity. This form of queuing system therefore
tends to move delay and variation in delay from under-used classes of
traffic to heavier users, as well as managing the rates of the traffic
streams.
A side-effect of a WRR or WFQ implementation is that between any two
packets in a given traffic class, the scheduler may emit one or more
packets from each of the other classes in the queuing system. In cases
where average behavior is in view, this is perfectly acceptable. In
cases where traffic is very intolerant of jitter and there are a number
of competing classes, this may have undesirable consequences.
7.2.2. Traffic Priority
Traffic Prioritization is a special case of load sharing, wherein a
certain traffic class is deemed so jitter-intolerant that if it has
traffic present, that traffic must be sent at the earliest possible
time. By extension, several priorities might be defined, such that
traffic in each of several classes is given preferential service over
any traffic of a lower class. It is the obvious implementation of IP
Precedence as described in [RFC 791], of 802.1p traffic classes
[802.1D], and other similar technologies.
Priority is often abused in real networks; people tend to think that
traffic which has a business priority deserves this treatment, and talk
more about the business imperatives than the actual application
requirements. This can have severe consequences; networks have been
configured which placed business-critical traffic at a higher priority
than routing traffic, resulting in congestive collapse of the networks.
However, it has a legitimate use in services like EF, where it is
absolutely known, due to policing, that a traffic stream does not abuse
its rate, and the application is indeed jitter-intolerant enough to
merit this type of handling.
8. Traffic Conditioning Blocks (TCBs) 8. Traffic Conditioning Blocks (TCBs)
The classifiers, meters, action elements and queueing elements described The Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler
above can be combined into traffic conditioning blocks (TCBs). The TCB functional datapath elements described above can be combined into
is an abstraction of a functional element that may be used to facilitate Traffic Conditioning Blocks (TCBs). A TCB is an abstraction of a set of
the definition of specific traffic conditioning functionality. functional datapath elements that may be used to facilitate the
definition of specific traffic conditioning functionality e.g. it might
be likened to a template which can be replicated multiple times for
different traffic streams or different customers. It has no likely
physical representation in the implementation of the data path: it is
invented purely as an abstraction for use by management tools.
A general TCB might consist of the following four stages: This model describes the configuration and management of a Diffserv
interface in terms of a TCB that contains, by definition, zero or more
Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler
elements. These elements are arranged arbitrarily according to the
policy being expressed, but always in the order here. Traffic may be
classified; classified traffic may be metered; each stream of traffic
identified by a combination of classifiers and meters may have some set
of actions performed on it, followed by drop algorithms; packets of the
traffic stream may ultimately be stored into a queue and then be
scheduled out to the next TCB or physical interface. It is possible to
omit elements or include null elements of any type, or to concatenate
multiple functional datapath elements of the same type.
When the Diffserv treatment for a given packet needs to have those
building blocks repeated, this is performed by cascading multiple TCBs:
an output of one TCB may drive the input of a succeeding one. For
example, consider the case where traffic of a set of classes is shaped
to a set of rates, but the total output rate of the group of classes
must also be limited to a rate. One might imagine a set of network news
feeds, each with a certain maximum rate, and a policy that their
aggregate may not exceed some figure. This may be simply accomplished by
cascading two TCBs. The first classifies the traffic into its separate
feeds and queues each feed separately. The feeds (or a subset of them)
are now fed into a second TCB, which places all input (these news feeds)
into a single queue with a certain maximum rate. In implementation, one
could imagine this as the several literal queues, a CBQ or WFQ system
with an appropriate (and complex) weighting scheme, or a number of other
approaches. But they would have the same externally measurable effect on
the traffic as if they had been literally implemented with separate
TCBs.
A generalised TCB might consist of the following stages:
- Classification stage - Classification stage
- Metering stage - Metering stage
- Action stage - Action stage
- Algorithmic Dropping stage
- Queueing stage - Queueing stage
- Scheduling stage
where each stage may consist of a set of parallel datapaths consisting where each stage may consist of a set of parallel datapaths consisting
of pipelined elements. of pipelined elements.
Note that a classifier is a 1:N element, metering and actions are A Classifier or a Meter is typically a 1:N element, an Action,
typically 1:1 elements and queueing is a N:1 element. The whole TCB Algorithmic Dropper or Queue is typically a 1:1 element and a Scheduler
should, however, result in a 1:1 abstract element. is a N:1 element. A complete TCB should, however, result in a 1:1 or 1:N
abstract element. Note that the fan-in or fan-out of an element is not
TCBs are constructed by connecting elements corresponding to these an important defining characteristic of this taxonomy.
stages in any sensible order. It is possible to omit stages, to include
null elements, or to concatenate multiple stages of the same type. TCB
outputs may drive additional TCBs (on either the ingress or egress
interfaces).
8.1. An Example TCB 8.1. An Example TCB
A SLS is presumed to have been negotiated between the customer and the A SLS is presumed to have been negotiated between the customer and the
provider which specifies the handling of the customer's traffic by the provider which specifies the handling of the customer's traffic by the
provider's network. The agreement might be of the following form: provider's network. The agreement might be of the following form:
DSCP PHB Profile Treatment DSCP PHB Profile Treatment
---- --- ------- ---------------------- ---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming. 001001 EF Profile4 Discard non-conforming.
skipping to change at page 32, line 42 skipping to change at page 36, line 4
with non-conforming packets "downgraded" by being re-marked with a DSCP with non-conforming packets "downgraded" by being re-marked with a DSCP
of 001000. It is implicit in this agreement that conforming packets are of 001000. It is implicit in this agreement that conforming packets are
given the PHB originally indicated by the packets' DSCP field. given the PHB originally indicated by the packets' DSCP field.
Figures 6 and 7 illustrates a TCB that might be used to handle this SLS Figures 6 and 7 illustrates a TCB that might be used to handle this SLS
at an ingress interface at the customer/provider boundary. at an ingress interface at the customer/provider boundary.
The Classification stage of this example consists of a single BA The Classification stage of this example consists of a single BA
classifier. The BA classifier is used to separate traffic based on the classifier. The BA classifier is used to separate traffic based on the
Diffserv service level requested by the customer (as indicated by the Diffserv service level requested by the customer (as indicated by the
DSCP in each submitted packet's IP header). We illustrate three DSCP
filter values: A, B and C. The 'X' in the BA classifier is a wildcard
filter that matches every packet not otherwise matched.
The paths for DSCP 001001 and 001101 then include a metering stage.
There is a separate meter for each set of packets corresponding to
classifier outputs A and C. Each meter uses a specific profile, as
specified in the TCS, for the corresponding Diffserv service level. The
meters in this example each indicate one of two conforming levels,
+-----+ +-----+
| A|---------------------------> to Queue1 | A|---------------------------> to Queue1
+->| | +->| |
| | B|--+ +-----+ +-----+ | | B|--+ +-----+ +-----+
| +-----+ | | | | | | +-----+ | | | | |
| Meter1 +->| |--->| | | Meter1 +->| |--->| |
| | | | | | | | | |
| +-----+ +-----+ | +-----+ +-----+
| Counter1 Absolute | Counter1 Absolute
submitted +-----+ | Dropper1 submitted +-----+ | Dropper1
skipping to change at page 33, line 31 skipping to change at page 36, line 31
| | B|--+ +-----+ +->|B | | | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+ | +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1 | Meter2 +->| |-+ Mux1
| | | | | |
| +-----+ | +-----+
| Marker1 | Marker1
+-------------------------------------> to Dropper3 +-------------------------------------> to Dropper3
Figure 6: An Example Traffic Conditioning Block (Part 1) Figure 6: An Example Traffic Conditioning Block (Part 1)
conforming or non-conforming. DSCP in each submitted packet's IP header). We illustrate three DSCP
filter values: A, B and C. The 'X' in the BA classifier is a wildcard
filter that matches every packet not otherwise matched.
Following the Metering stage is the Action stage in the upper and lower The path for DSCP 001100 proceeds directly to Dropper1 whilst the paths
branches. Packets submitted for DSCP 001001 that are deemed non- for DSCP 001001 and 001101 include a metering stage. All other traffic
conforming are counted and discarded while packets that are conforming is passed directly on to Dropper3. There is a separate meter for each
are passed on to Dropper1/Queue1. Packets submitted for DSCP 001101 that set of packets corresponding to classifier outputs A and C. Each meter
are deemed non-conforming are re-marked and then conforming and non- uses a specific profile, as specified in the TCS, for the corresponding
conforming packets are multiplexed together before being passed on to Diffserv service level. The meters in this example each indicate one of
Dropper2/Queue3. Packets submitted for DSCP 001100 are passed straight two conformance levels: conforming or non-conforming.
on to Queue2.
The Queueing stage is realised as follows, shown in figure 6. The Following the Metering stage is an Action stage in some of the branches.
conforming 001001 packets are passed directly to Queue1: there is no Packets submitted for DSCP 001001 (Classifier output A) that are deemed
way, with correct configuration of the scheduler for these to overflow non- conforming by Meter1 are counted and discarded while packets that
the depth of Queue1 so there is never a requirement for dropping. are conforming are passed on to Queue1. Packets submitted for DSCP
Packets marked for 001100 must be passed through a tail-dropper, 001101 (Classifier output C) that are deemed non-conforming by Meter2
are re-marked and then both conforming and non-conforming packets are
multiplexed together before being passed on to Dropper2/Queue3.
The Algorithmic Dropping, Queueing and Scheduling stages are realised as
follows, illustrated in figure 7. Note that the figure does not show any
of the implicit control linkages between elements that allow e.g. an
Algorithmic Dropper to sense the current state of a succeeding Queue.
Conforming DSCP 001001 packets from Meter1 are passed directly to
Queue1: there is no way, with a configuration of the following Scheduler
that patches the metering, for these packets to overflow the depth of
Queue1 so there is never a requirement for dropping at this point.
Packets marked for DSCP 001100 must be passed through a tail-dropper,
Dropper1, which serves to limit the depth of the following queue, Dropper1, which serves to limit the depth of the following queue,
Queue2: packets that arrive to a full queue will be discarded - this is Queue2: packets that arrive to a full queue will be discarded - this is
likely to be an error case: the customer is obviously not sticking to likely to be an error case: the customer is obviously not sticking to
its agreed profile. Similarly, all packets from the original DSCP
001101 stream (some may have been re-marked by this stage) are passed to
Dropper2 and Queue3. Packets marked for all other DSCPs are passed to
Dropper3 which is a RED-like algorithmic dropper: based on feedback of
the current depth of Queue4, this dropper is likely to discard enough
packets from its input stream to keep the queue depth under control.
its agreed profile. Similarly, packets from the 001101 stream are These four Queue elements are then serviced by a Scheduler element
passed to Dropper2 and Queue3. Packets marked for all other DSCPs are Scheduler1: tis must be configured to give each of its inputs an
passed to Dropper3 which is a RED-like algorithmic dropper: based on
feedback of the current depth of Queue4, this dropper is likely to
discard enough packets from its input stream to keep the queue depth
under control.
These four queues are then serviced by a scheduling algorithm in
Scheduler1 which has been configured to give each of the queues an
appropriate priority and/or bandwidth share. Inputs A and C are given appropriate priority and/or bandwidth share. Inputs A and C are given
guarantees of bandwidth, as appropriate for the contracted profiles. guarantees of bandwidth, as appropriate for the contracted profiles.
Input B is given a limit on the bandwidth it can use i.e. a non-work- Input B is given a limit on the bandwidth it can use i.e. a non-work-
conserving discipline in order to achieve the desired shaping of this conserving discipline in order to achieve the desired shaping of this
stream. Input D is given no limits or guarantees but a lower priority stream. Input D is given no limits or guarantees but a lower priority
than the other queues, appropriate for its best-effort status. Traffic than the other queues, appropriate for its best-effort status. Traffic
then exits the scheduler in a single orderly stream. then exits the Scheduler in a single orderly stream.
The interconnections of the TCB elements illustrated in Figures 6 and 7
can be represented as follows:
TCB1:
Classifier1:
FilterA: Meter1
FilterB: Dropper1
FilterC: Meter2
Default: Dropper3
Meter1:
Type: AverageRate
Profile: Profile1
ConformingOutput: Queue1
NonConformingOutput: Counter1
Counter1:
from Meter1 +-----+ from Meter1 +-----+
------------------------------->| |----+ ------------------------------->| |----+
| | | | | |
+-----+ | +-----+ |
Queue1 | Queue1 |
| +-----+ | +-----+
from Classifier1 +-----+ +-----+ +->|A | from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |-------> ---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting | | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic +-----+ +-----+ | +->|D | traffic
Dropper1 Queue2 | | +-----+ AlgDropper1 Queue2 | | +-----+
| | Scheduler1 | | Scheduler1
from Mux1 +-----+ +-----+ | | from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ | ---------------->| |------->| |--+ |
| | | | | | | | | |
+-----+ +-----+ | +-----+ +-----+ |
Dropper2 Queue3 | AlgDropper2 Queue3 |
| |
from Classifier1 +-----+ +-----+ | from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+ ---------------->| |------->| |----+
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
Dropper3 Queue4 AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2) Figure 7: An Example Traffic Conditioning Block (Part 2)
The interconnections of the TCB elements illustrated in Figures 6 and 7
can be represented as follows:
TCB1:
Classifier1:
FilterA: Meter1
FilterB: Dropper1
FilterC: Meter2
Default: Dropper3
Meter1:
Type: AverageRate
Profile: Profile1
ConformingOutput: Queue1
NonConformingOutput: Counter1
Counter1:
Output: AbsoluteDropper1 Output: AbsoluteDropper1
Meter2: Meter2:
Type: AverageRate Type: AverageRate
Profile: Profile3 Profile: Profile3
ConformingOutput: Mux1.InputA ConformingOutput: Mux1.InputA
NonConformingOutput: Marker1 NonConformingOutput: Marker1
Marker1: Marker1:
Type: DSCPMarker Type: DSCPMarker
Mark: 001000 Mark: 001000
Output: Mux1.InputB Output: Mux1.InputB
Mux1: Mux1:
Output: Dropper2 Output: Dropper2
Dropper1: AlgDropper1:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Queue2.Depth > 10kbyte Trigger: Queue2.Depth > 10kbyte
Output: Queue2 Output: Queue2
Dropper2: AlgDropper2:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold Discipline: Drop-on-threshold
Trigger: Queue3.Depth > 20kbyte Trigger: Queue3.Depth > 20kbyte
Output: Queue3 Output: Queue3
Dropper3: AlgDropper3:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED93 Discipline: RED93
Trigger: Internal Trigger: Internal
Output: Queue3 Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too> <other RED parms too>
Queue1: Queue1:
Type: FIFO Type: FIFO
skipping to change at page 37, line 14 skipping to change at page 40, line 19
8.2. An 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 TCS if the interface is dedicated to the implement a provider/customer TCS if the interface is dedicated to the
customer. However, if a single interface is shared between multiple customer. However, if a single interface is shared between multiple
customers, then the TCB above will not suffice, since it does not customers, then the TCB above will not suffice, since it does not
differentiate among traffic from different customers. Its classification differentiate among traffic from different customers. Its classification
stage uses only BA classifiers. stage uses only BA classifiers.
The TCB is readily extended to support the case of multiple customers The configuration is readily modified to support the case of multiple
per interface, as follows. First, a TCB is defined for each customer to customers per interface, as follows. First, a TCB is defined for each
reflect the TCS with that customer: TCB1, defined above is the TCB for customer to reflect the TCS with that customer: TCB1, defined above is
customer 1 and definitions are then added for TCB2 and for TCB3 which the TCB for customer 1 and elements are created for TCB2 and for TCB3
reflect the agreements with customers 2 and 3 respectively. which reflect the agreements with customers 2 and 3 respectively. These
3 TCBs may or may not share the same elements and parameters.
Finally, a classifier is added to the front end to separate the traffic Finally, a classifier is added to the front end to separate the traffic
from the three different customers. This forms a new TCB, TCB4, which from the three different customers. This forms a new TCB, TCB4, which is
incorporates TCB1, TCB2, and TCB3 and is illustrated in Figure 8. illustrated in Figure 8.
A formal representation of this multi-customer TCB might be: A representation of this multi-customer TCB might be:
TCB4: TCB4:
Classifier4: Classifier4:
submitted +-----+
traffic | A|--------> TCB1
--------->| B|--------> TCB2
| C|--------> TCB3
| X|------+ +-----+
+-----+ +-->| |
Classifier4 +-----+
AbsoluteDrop4
Figure 8: An Example of a Multi-Customer TCB
Filter1: to TCB1 Filter1: to TCB1
Filter2: to TCB2 Filter2: to TCB2
Filter3: to TCB3 Filter3: to TCB3
No Match: AbsoluteDropper4 No Match: AbsoluteDropper4
TCB1: TCB1:
(as defined above) (as defined above)
TCB2: TCB2:
(similar to TCB1, perhaps with different
submitted +-----+ elements or numeric parameters)
traffic | A|--------> TCB1
--->| B|--------> TCB2
| C|--------> TCB3
| X|--------> AbsoluteDropper4
+-----+
Classifier4
Figure 8: An Example of a Multi-Customer TCB
(similar to TCB1, perhaps with different numeric parameters)
TCB3: TCB3:
(similar to TCB1, perhaps with different numeric parameters) (similar to TCB1, perhaps with different
elements or numeric parameters)
TCB4:
(the total TCB)
and the filters, based on each customer's source MAC address, could be and the filters, based on each customer's source MAC address, could be
defined as follows: defined as follows:
Filter1: Filter1:
Type: MacAddress Type: MacAddress
SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1)
SrcMask: FF-FF-FF-FF-FF-FF SrcMask: FF-FF-FF-FF-FF-FF
DestValue: 00-00-00-00-00-00 DestValue: 00-00-00-00-00-00
DestMask: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00
skipping to change at page 38, line 36 skipping to change at page 41, line 44
Filter3: Filter3:
(similar to Filter1 but with customer 3's source MAC address as (similar to Filter1 but with customer 3's source MAC address as
SrcValue) SrcValue)
In this example, Classifier4 separates traffic submitted from different In this example, Classifier4 separates traffic submitted from different
customers based on the source MAC address in submitted packets. Those customers based on the source MAC address in submitted packets. Those
packets with recognized source MAC addresses are passed to the TCB packets with recognized source MAC addresses are passed to the TCB
implementing the TCS with the corresponding customer. Those packets with implementing the TCS with the corresponding customer. Those packets with
unrecognized source MAC addresses are passed to a dropper. unrecognized source MAC addresses are passed to a dropper.
TCB4 has a Classifier stage and an Action element stage, which consists TCB4 has a Classifier stage and an Action element stage performing
of either a dropper or another TCB. dropping of all unmatched traffic.
8.3. TCBs Supporting Microflow-based Services 8.3. TCBs Supporting Microflow-based Services
The TCB illustrated above describes a configuration that might be The TCB illustrated above describes a configuration that might be
suitable for enforcing a SLS at a router's ingress. It assumes that the suitable for enforcing a SLS at a router's ingress. It assumes that the
customer marks its own traffic for the appropriate service level. It customer marks its own traffic for the appropriate service level. It
then limits the rate of aggregate traffic submitted at each service then limits the rate of aggregate traffic submitted at each service
level, thereby protecting the resources of the Diffserv network. It does level, thereby protecting the resources of the Diffserv network. It does
not provide any isolation between the customer's individual microflows. not provide any isolation between the customer's individual microflows.
A more complex example might be a TCB configuration that offers A more complex example might be a TCB configuration that offers
additional functionality to the customer. It recognizes individual additional functionality to the customer. It recognizes individual
customer microflows and marks each one independently. It also isolates customer microflows and marks each one independently. It also isolates
the customer's individual microflows from each other in order to prevent the customer's individual microflows from each other in order to prevent
a single microflow from seizing an unfair share of the resources a single microflow from seizing an unfair share of the resources
available to the customer at a certain service level. This is available to the customer at a certain service level. This is
illustrated in Figure 9. illustrated in Figure 9.
Suppose that the customer has an SLS which specifices 2 service levels, Suppose that the customer has an SLS which specifices 2 service levels,
to be identifed to the provider by DSCP A and DSCP B. Traffic is first to be identifed to the provider by DSCP A and DSCP B. Traffic is first
directed to a MF classifier which classifies traffic based on directed to a MF classifier which classifies traffic based on
miscellaneous classification criteria, to a granularity sufficient to miscellaneous classification criteria, to a granularity sufficient to
skipping to change at page 39, line 16 skipping to change at page 42, line 23
the customer's individual microflows from each other in order to prevent the customer's individual microflows from each other in order to prevent
a single microflow from seizing an unfair share of the resources a single microflow from seizing an unfair share of the resources
available to the customer at a certain service level. This is available to the customer at a certain service level. This is
illustrated in Figure 9. illustrated in Figure 9.
Suppose that the customer has an SLS which specifices 2 service levels, Suppose that the customer has an SLS which specifices 2 service levels,
to be identifed to the provider by DSCP A and DSCP B. Traffic is first to be identifed to the provider by DSCP A and DSCP B. Traffic is first
directed to a MF classifier which classifies traffic based on directed to a MF classifier which classifies traffic based on
miscellaneous classification criteria, to a granularity sufficient to miscellaneous classification criteria, to a granularity sufficient to
identify individual customer microflows. Each microflow can then be identify individual customer microflows. Each microflow can then be
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
was marked. Packets exceeding the allowable limit for the microflow are
dropped.
This TCB could be formally specified as follows:
+-----+ +-----+ +-----+ +-----+
Classifier1 | | | |---------------+ Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ | (MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | | +-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ | | A|------ +-----+ +-----+ +-----+ |
--->| B|-----+ Marker1 Meter1 Absolute | --->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+ | C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A | | X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |---> +-----+ | | | | | | |------------------>|B |--->
skipping to change at page 40, line 4 skipping to change at page 43, line 4
| | +-----+ +-----+ | | | +-----+ +-----+ |
| | | | | |---------------+ | | | | | |---------------+
| |--->| |-->| | +-----+ | |--->| |-->| | +-----+
| | | | |---->| | | | | | |---->| |
| +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute | Marker3 Meter3 Absolute
| Dropper3 | Dropper3
V etc. V etc.
Figure 9: An Example of a Marking and Traffic Isolation TCB Figure 9: An Example of a Marking and Traffic Isolation TCB
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
was marked. Packets exceeding the allowable limit for the microflow are
dropped.
This TCB could be formally specified as follows:
TCB1: TCB1:
Classifier1: (MF) Classifier1: (MF)
FilterA: Marker1 FilterA: Marker1
FilterB: Marker2 FilterB: Marker2
FilterC: Marker3 FilterC: Marker3
etc. etc.
Marker1: Marker1:
Output: Meter1 Output: Meter1
skipping to change at page 40, line 42 skipping to change at page 44, line 5
etc. etc.
Mux1: Mux1:
Output: to TCB2 Output: to TCB2
Note that the detailed traffic element declarations are not shown here. Note that the detailed traffic element declarations are not shown 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 which is illustrated in DSCPs. This traffic is then passed to TCB2 which is illustrated in
Figure 10. Figure 10.
TCB2 could then be specified as follows:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
Meter5:
ConformingOutput: Queue1
+-----+ +-----+
| |---------------> to Queue1 | |---------------> to Queue1
+->| | +-----+ +->| | +-----+
+-----+ | | |---->| | +-----+ | | |---->| |
| A|---+ +-----+ +-----+ | A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4 ->| | Meter5 AbsoluteDropper4
| B|---+ +-----+ | B|---+ +-----+
+-----+ | | |---------------> to Queue2 +-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+ Classifier2 +->| | +-----+
(BA) | |---->| | (BA) | |---->| |
+-----+ +-----+ +-----+ +-----+
Meter6 AbsoluteDropper5 Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2 Figure 10: Additional Example: TCB2
TCB2 could then be specified as follows:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
Meter5:
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper4 NonConformingOutput: AbsoluteDropper4
Meter6: Meter6:
ConformingOutput: Queue2 ConformingOutput: Queue2
NonConformingOutput: AbsoluteDropper5 NonConformingOutput: AbsoluteDropper5
8.4. Cascaded TCBs 8.4. Cascaded TCBs
Nothing in this model prevents more complex scenarios in which one Nothing in this model prevents more complex scenarios in which one
microflow TCB precedes another (e.g. for TCBs implementing separate TCSs microflow TCB precedes another (e.g. for TCBs implementing separate TCSs
for the source and for a set of destinations). for the source and for a set of destinations).
9. Open Issues 9. Security Considerations
<ed: this section to be deleted before WG last call and RFC publication.
The current stance of this draft is supplied in parentheses.
(1) FIFOs are modelled here as having infinite depth: it is up to any
preceding meter/dropper to make sure that they do not overflow - a
hard stop on the depth would be modelled, for example, by preceding
the FIFO with an Absolute Dropper. Is this appropriate? (Yes)
(2) We must allow algorithmic droppers that apply different dropping
behaviour to packets with different classifier matches, with these
possibly fed through different meters and actions. Should we model
the dropper as a single input element with implicit pointers back
to the matching classifier that selects different dropper
algorithms/treatments? Or as multiple droppers? Or as having
multiple logical inputs? (single input, implicit pointers).
10. Security Considerations
Security vulnerabilities of Diffserv network operation are discussed in Security vulnerabilities of Diffserv network operation are discussed in
[DSARCH]. This document describes an abstract functional model of [DSARCH]. This document describes an abstract functional model of
Diffserv router elements. Certain denial-of-service attacks such as Diffserv router elements. Certain denial-of-service attacks such as
those resulting from resource starvation may be mitigated by appropriate those resulting from resource starvation may be mitigated by appropriate
configuration of these router elements; for example, by rate limiting configuration of these router elements; for example, by rate limiting
certain traffic streams or by authenticating traffic marked for higher certain traffic streams or by authenticating traffic marked for higher
quality-of-service. quality-of-service.
One particular theft- or denial-of-service issue may arise where a One particular theft- or denial-of-service issue may arise where a
skipping to change at page 42, line 27 skipping to change at page 45, line 17
is used in a TCB to police a stream to a given TCS: the definition of is used in a TCB to police a stream to a given TCS: the definition of
the token-bucket meter in section 5 indicates that it should be lenient the token-bucket meter in section 5 indicates that it should be lenient
in accepting a packet whenever any bits of the packet would have been in accepting a packet whenever any bits of the packet would have been
within the profile; the definition of the leaky-bucket scheduler is within the profile; the definition of the leaky-bucket scheduler is
conservative in that a packet is to be transmitted only if the whole conservative in that a packet is to be transmitted only if the whole
packet fits within the profile. This difference may be exploited by a packet fits within the profile. This difference may be exploited by a
malicious scheduler either to obtain QoS treatment for more octets than malicious scheduler either to obtain QoS treatment for more octets than
allowed in the TCS or to disrupt (perhaps only slightly) the QoS allowed in the TCS or to disrupt (perhaps only slightly) the QoS
guarantees promised to other traffic streams. guarantees promised to other traffic streams.
11. Acknowledgments 10. Acknowledgments
Concepts, terminology, and text have been borrowed liberally from Concepts, terminology, and text have been borrowed liberally from
[POLTERM], [DSMIB] and [DSPIB]. We wish to thank the authors of those [POLTERM], [DSMIB] and [DSPIB]. We wish to thank the authors of those
documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson,
Kwok Chan and Scott Hahn for their contributions. Kwok Chan and Scott Hahn for their contributions.
This document has benefitted from the comments and suggestions of This document has benefitted from the comments and suggestions of
several participants of the Diffserv working group. several participants of the Diffserv working group.
12. References 11. References
[AF-PHB] [AF-PHB]
J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999. Forwarding PHB Group", RFC 2597, June 1999.
[DSARCH] [DSARCH]
M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies,
"An Architecture for Differentiated Services", RFC 2475, December "An Architecture for Differentiated Services", RFC 2475, December
1998 1998
[DSFIELD] [DSFIELD]
K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
[DSMIB] [DSMIB]
F. Baker, A. Smith, K. Chan, "Differentiated Services MIB", F. Baker, A. Smith, K. Chan, "Differentiated Services MIB",
Internet Draft <draft-ietf-diffserv-mib-03.txt>, May 2000. Internet Draft <http://www.ietf.org/internet-drafts/draft-ietf-
diffserv-mib-04.txt>, July 2000.
[DSPIB] [DSPIB]
M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, and A. M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, and A.
Smith, "Quality of Service Policy Information Base", Internet Draft Smith, "Quality of Service Policy Information Base", Internet Draft
<draft-ietf-diffserv-pib-00.txt>, March 2000. <draft-ietf-diffserv-pib-00.txt>, March 2000.
[DSTERMS] [DSTERMS]
D. Grossman, "New Terminology for Diffserv", Internet Draft <draft- D. Grossman, "New Terminology for Diffserv", Internet Draft <draft-
ietf-diffserv-new-terms-02.txt>, November 1999. ietf-diffserv-new-terms-02.txt>, November 1999.
[E2E] [E2E]
Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K. Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K.
Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine,
skipping to change at page 43, line 24 skipping to change at page 46, line 16
<draft-ietf-diffserv-pib-00.txt>, March 2000. <draft-ietf-diffserv-pib-00.txt>, March 2000.
[DSTERMS] [DSTERMS]
D. Grossman, "New Terminology for Diffserv", Internet Draft <draft- D. Grossman, "New Terminology for Diffserv", Internet Draft <draft-
ietf-diffserv-new-terms-02.txt>, November 1999. ietf-diffserv-new-terms-02.txt>, November 1999.
[E2E] [E2E]
Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K. Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K.
Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine,
"Integrated Services Operation over Diffserv Networks", Internet "Integrated Services Operation over Diffserv Networks", Internet
Draft <draft-ietf-issll-diffserv-rsvp-04.txt>, March 2000. Draft <http://www.ietf.org/internet-drafts/draft-ietf-issll-
diffserv-rsvp-04.txt>, March 2000.
[EF-PHB] [EF-PHB]
V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding
PHB", RFC 2598, June 1999. PHB", RFC 2598, June 1999.
[FLOYD]
S. Floyd, "General Load Sharing", 1993.
[GTC] [GTC]
L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner", Internet L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner", Internet
Draft <draft-lin-diffserv-gtc-01.txt>, August 1999. Draft <http://www.ietf.org/internet-drafts/draft-lin-diffserv-
gtc-01.txt>, August 1999.
[INTSERV] [INTSERV]
R. Braden, D. Clark and S. Shenker, "Integrated Services in the R. Braden, D. Clark and S. Shenker, "Integrated Services in the
Internet Architecture: an Overview" RFC 1633, June 1994. Internet Architecture: an Overview" RFC 1633, June 1994.
[POLTERM] [POLTERM]
F. Reichmeyer, D. Grossman, J. Strassner, M. Condell, "A Common F. Reichmeyer, D. Grossman, J. Strassner, M. Condell, "A Common
Terminology for Policy Management", Internet Draft <draft- Terminology for Policy Management", Internet Draft
<http://www.ietf.org/internet-drafts/draft-reichmeyer-polterm-
[QOSDEVMOD] [QOSDEVMOD]
J. Strassner, W. Weiss, D. Durham, A. Westerinen, "Information J. Strassner, W. Weiss, D. Durham, A. Westerinen, "Information
Model for Describing Network Device QoS Mechanisms", Internet Draft Model for Describing Network Device QoS Mechanisms", Internet Draft
<http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-
[QUEUEMGMT]
B. Braden et al., "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[SRTCM] [SRTCM]
J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC
2697, September 1999. 2697, September 1999.
[TRTCM] [TRTCM]
J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698, J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698,
September 1999. September 1999.
[VIC]
McCanne, S. and Jacobson, V., "vic: A Flexible Framework for Packet
Video", ACM Multimedia '95, November 1995, San Francisco, CA, pp.
511-522. <ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[802.1D]
"Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks -
Common specifications - Part 3: Media Access Control (MAC) Bridges:
Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.",
ISO/IEC 15802-3: 1998.
12. Appendix A. Simple Token Bucket Discussion and Definition
Internet Protocol (IP) packets are of variable-length but theoretical
token buckets operate using fixed-length time intervals or pieces of
data. This leaves an implementor of a token bucket scheme with a
dilemma. When the amount of bandwidth tokens, TB, left in the token
bucket is positive but less than the size of the packet being operated
on, one of three things can be done:
(1) The whole size of the packet can be substracted from the bucket,
leaving it negative, remembering that the token bucket size must
be added to TB rather than simply setting it "full". This
potentially puts more than the token bucket size into this token
bucket interval and less into the next. It does, however, make
the average amount accepted per token bucket interval equal to
the token burst. This approach accepts traffic if any bit in the
packet would be accepted and borrows up to one MTU of capacity
from one or more subsequent intervals when necessary. Such a
token bucket implementation is said to be a "loose" token bucket.
(2) Alternatively, the amount can be left unchanged (and maybe an
attempt could be made to accept the packet under another
threshold in another bucket), remembering that the token bucket
size must be added to the TB variable rather than simply setting
it "full". This potentially puts less than the token bucket size
into this token bucket interval and more into the next. Like the
first option, it makes the average amount accepted per token
bucket interval equal to the token burst. This approach accepts
traffic if every bit in the packet would be accepted and borrows
up to one MTU of capacity from one or more previous intervals
when necessary. Such a token bucket implementation is said to be
a "strict" (or perhaps "stricter") token bucket.
(3) The TB variable can be set to zero to account for the first part
of the packet and the remainder of the packet size can be taken
out of the next-colored bucket. This, of course, has another bug:
the same packet cannot have both conforming and nonconforming
components in the Diffserv architecture and so is not really
appropriate here.
Unfortunately, the thing that cannot be done is exactly to fit the token
burst specification with random sized packets: therefore token buckets
in a variable length packet environment always have a some variance from
theoretical reality. This has also been observed in the ATM Guaranteed
Frame Rate (GFR) service category specification and Frame Relay.
Some find the behavior of a "loose" token bucket unacceptable, as it is
significantly different than the token bucket description for ATM and
for Frame Relay. However, the "strict" token bucket approach has three
characteristics which are important to keep in mind:
(1) First, if the maximum token burst is smaller than the MTU, it is
possible that traffic never matches the specification. This may
be avoided by not allowing such a specification.
(2) Second, the strict token bucket specifications [SRTCM] and
[TRTCM], as specified, are subject to a persistent under-run.
These accumulate burst capacity over time, up to the maximum
burst size. Suppose that the maximum burst size is exactly the
size of the packets being sent - which one might call the
"strictest" token bucket implementation. In such a case, when one
packet has been accepted, the token depth becomes zero, and
starts to accumulate. If the next packet is received any time
earlier than a token interval later, it will not be accepted. If
the next packet arrives exactly on time, it will be accepted and
the token depth again set to zero. If it arrives later, however,
the token depth will stop accumulating, as it is capped by the
maximum burst size, and tokens that would have accumulated
between the end of that token interval and the actual arrival of
the packet are lost. As a result, natural jitter in the network
conspires against the algorithm to reduce the actual acceptance
rate. Overcoming this error requires the maximum token bucket
size to be significantly greater than the MTU.
(3) Third, operationally, a strict token bucket is reasonable for
traffic which has been shaped by a leaky bucket shaper or a
serial line. However, traffic in the Internet is rarely shaped in
that way. TCP applies no shaping to its traffic, but rather
depends on longer-range Ack Clocking behavior to help it
approximate a certain rate and explicitly sends traffic bursts
during slow start, retransmission and fast recovery. Video-on-IP
implementations such as [VIC] may have a leaky bucket shaper
available to them, but often do not, and simply enqueue the
output of their codec for transmission on the appropriate
interface. As a result, in each of these cases, a strict shaper
may reject traffic in the short term (single token interval)
which it would have accepted if it had a longer time in view and
which it needs to accept for the application to work properly. To
work around this, the token interval must approximate or exceed
the RTT of the session or sessions in question and the burst size
must accommodate the largest burst that the originator might
send.
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 those 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-) = min { BS, T(t') + v*R }
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".
13. Authors' Addresses 13. Authors' Addresses
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 936 9568 Phone: +1 425 936 9568
E-mail: yoramb@microsoft.com E-mail: yoramb@microsoft.com
Andrew Smith Andrew Smith
Extreme Networks FAX: +1 414 345 1827
3585 Monroe St. E-mail: ah_smith@pacbell.net
Santa Clara, CA 95051
Phone: +1 408 579 2821
E-mail: andrew@extremenetworks.com
Steven Blake Steven Blake
Ericsson Ericsson
920 Main Campus Drive, Suite 500 920 Main Campus Drive, Suite 500
Raleigh, NC 27606 Raleigh, NC 27606
Phone: +1 919 472 9913 Phone: +1 919 472 9913
E-mail: slblake@torrentnet.com E-mail: slblake@torrentnet.com
Daniel Grossman Daniel Grossman
Motorola Inc. Motorola Inc.
skipping to change at page 44, line 45 skipping to change at page 50, line 48
Mansfield, MA 02048 Mansfield, MA 02048
Phone: +1 508 261 5312 Phone: +1 508 261 5312
E-mail: dan@dma.isg.mot.com E-mail: dan@dma.isg.mot.com
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Glossary ........................................................ 3 2 Glossary ........................................................ 3
3 Conceptual Model ................................................ 5 3 Conceptual Model ................................................ 5
3.1 Elements of a Diffserv Router ................................. 5 3.1 Elements of a Diffserv Router ................................. 5
3.1.1 Datapath .................................................... 5 3.1.1 Datapath .................................................... 6
3.1.2 Configuration and Management Interface ...................... 6 3.1.2 Configuration and Management Interface ...................... 6
3.1.3 Optional QoS Agent Module ................................... 7
3.2 Hierarchical Model of Diffserv Components ..................... 7
3.1.3 Optional QoS Agent Module ................................... 7
3.2 Hierarchical Model of Diffserv Components ..................... 8
4 Classifiers ..................................................... 10 4 Classifiers ..................................................... 10
4.1 Definition .................................................... 10 4.1 Definition .................................................... 10
4.1.1 Filters ..................................................... 11 4.1.1 Filters ..................................................... 11
4.1.2 Overlapping Filters ......................................... 11 4.1.2 Overlapping Filters ......................................... 12
4.2 Examples ...................................................... 12 4.2 Examples ...................................................... 13
4.2.1 Behaviour Aggregate (BA) Classifier ......................... 12 4.2.1 Behaviour Aggregate (BA) Classifier ......................... 13
4.2.2 Multi-Field (MF) Classifier ................................. 13 4.2.2 Multi-Field (MF) Classifier ................................. 14
4.2.3 Free-form Classifier ........................................ 13 4.2.3 Free-form Classifier ........................................ 14
4.2.4 Other Possible Classifiers .................................. 14 4.2.4 Other Possible Classifiers .................................. 15
5 Meters .......................................................... 14 5 Meters .......................................................... 15
5.1 Examples ...................................................... 17 5.1 Token-Bucket Model ............................................ 17
5.1.1 Average Rate Meter .......................................... 17 5.2 Examples ...................................................... 18
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............ 18 5.2.1 Average Rate Meter .......................................... 18
5.1.3 Two-Parameter Token Bucket Meter ............................ 19 5.2.2 Exponential Weighted Moving Average (EWMA) Meter ............ 19
5.1.4 Multi-Stage Token Bucket Meter .............................. 19 5.2.3 Two-Parameter Token Bucket Meter ............................ 20
5.1.5 Null Meter .................................................. 20 5.2.4 Multi-Stage Token Bucket Meter .............................. 20
6 Action Elements ................................................. 20 5.2.5 Null Meter .................................................. 21
6.1 Marker ........................................................ 21 6 Action Elements ................................................. 21
6.2 Absolute Dropper .............................................. 21 6.1 Marker ........................................................ 22
6.3 Multiplexer ................................................... 22 6.2 Absolute Dropper .............................................. 22
6.4 Counter ....................................................... 22 6.3 Multiplexor ................................................... 23
6.5 Null Action ................................................... 22 6.4 Counter ....................................................... 23
7 Queueing Blocks ................................................. 22 6.5 Null Action ................................................... 23
7.1 Queueing Model ................................................ 23 7 Queueing Elements ............................................... 24
7.1.1 FIFO ........................................................ 23 7.1 Queueing Model ................................................ 24
7.1.2 Scheduler ................................................... 25 7.1.1 FIFO Queue .................................................. 25
7.1.3 Algorithmic Dropper ......................................... 27 7.1.2 Scheduler ................................................... 26
7.1.4 Constructing queueing blocks from the elements .............. 30 7.1.3 Algorithmic Dropper ......................................... 28
7.2 Shaping ....................................................... 31 7.1.4 Constructing queueing blocks from the elements .............. 31
8 Traffic Conditioning Blocks (TCBs) .............................. 31 7.2 Sharing load among traffic streams using queueing ............. 32
8.1 An Example TCB ................................................ 32 7.2.1 Load Sharing ................................................ 32
8.2 An Example TCB to Support Multiple Customers .................. 37 7.2.2 Traffic Priority ............................................ 33
8.3 TCBs Supporting Microflow-based Services ...................... 38 8 Traffic Conditioning Blocks (TCBs) .............................. 34
8.4 Cascaded TCBs ................................................. 41 8.1 An Example TCB ................................................ 35
9 Open Issues ..................................................... 41 8.2 An Example TCB to Support Multiple Customers .................. 40
10 Security Considerations ........................................ 42 8.3 TCBs Supporting Microflow-based Services ...................... 41
11 Acknowledgments ................................................ 42 8.4 Cascaded TCBs ................................................. 44
12 References ..................................................... 42 9 Security Considerations ......................................... 44
13 Authors' Addresses ............................................. 44 10 Acknowledgments ................................................ 45
11 References ..................................................... 45
12 Appendix A. Simple Token Bucket Discussion and Definition ...... 47
13 Authors' Addresses ............................................. 50
14. Full Copyright 14. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
 End of changes. 170 change blocks. 
591 lines changed or deleted 866 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/