Internet Draft
Differentiated Services Y. Bernet
Internet Draft Microsoft
Expires December 1999 A. Smith
draft-ietf-diffserv-model-00.txt Extreme Networks
S. Blake
Ericsson Datacom
June 1999
A Conceptual Model for Diffserv Routers
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This draft proposes a conceptual model for use in the management of
Differentiated Services (diffserv) routers. We describe the
fundamental packet classification principles that allow traffic
streams to be differentiated. We describe the fundamental traffic
conditioning elements that comprise the traffic conditioning
functionality of diffserv routers. We describe the fundamental queue
elements that comprise the Per-Hop Behaviour (PHB) functionality of
diffserv routers. We propose a formal model for these. We also
describe parameters and variables that may be used for monitoring
the operation of the elements described above. There is no attempt
made to define the packet forwarding behaviours of diffserv routers
- these are well described elsewhere in the literature.
Bernet, Smith, Blake expires December, 1999 1
draft-ietf-diffserv-model-00.txt June, 1999
This draft is preliminary and is known to be inconsistent in some
respects with [DSMIB]. It is intended to correct this prior to the
next version, as well as to verify full consistency with the
published diffserv specifications [DSFIELD], [DSARCH], [AF-PHB],
[EF-PHB].
1. Introduction
Differentiated Services (diffserv) [DSARCH, DSFWK] is a set of
technologies by which network service providers can offer differing
levels of network quality-of-service (QoS) to different customers
and their traffic streams. The premise of diffserv networks is that
routers within the networks handle packets in different traffic
streams by applying different per-hop behaviours (PHBs) to the
packet forwarding. The PHB to be applied is indicated by a diffserv
code-point (DSCP) in the IP header of each packet [DSFIELD]. Note
that this document uses the terminology of [DSFWK].
The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behaviour aggregates (BA)
which are each forwarded using the same PHB at the router, thereby
simplifying the processing and associated storage. In addition,
there is no signaling, other than what is carried in the DSCP of
each packet, and no other related processing that is required in the
diffserv network since QoS is invoked on a packet-by-packet basis.
Although diffserv itself does not define the services that a
diffserv network can provide, its successful deployment depends on
the ability to use the technology to provide services. These
services are reflected to customers at the edges of the diffserv
network in the form of a Service Level Specification (SLS) [DSFWK].
The ability to provide these services depends on the availability of
cohesive management tools that can be used to provision and monitor
a set of diffserv routers in a coordinated manner. To facilitate the
development of such management tools it is helpful to define a
conceptual model of a diffserv router that abstracts implementation
details of diffserv routers from the management tools used to manage
them. The purpose of this draft is to define this conceptual model.
The basic forwarding functionality of a diffserv router is defined
by other specifications e.g. [DSARCH], [DSFIELD], [AF-PHB], [EF-
PHB].
This document is not intended in any way to constrain or to dictate
implementations of diffserv routers. We expect that router vendors
will demonstrate a great deal of variability in their
implementations. To the extent that vendors are able to model their
implementations using the abstractions described in this draft,
management tools will more readily be able to manage networks
incorporating diffserv routers of various implementations.
2. Organization of this Document
Bernet, Smith, Blake expires December, 1999 2
draft-ietf-diffserv-model-00.txt June, 1999
In Section 3 we start by describing the basic high-level functional
blocks of a diffserv router and then providing a block diagram and
describe the various components. We then focus on the diffserv-
specific components of the router and describe a hierarchical
management model for these.
In Section 4 we describe classification elements and in section 5,
we discuss the basic traffic conditioning elements.
In Section 6, we show how the basic classification and traffic
conditioning elements can be combined to build modules called
Traffic Conditioning Blocks (TCBs).
In Section 7, we discuss the basic queuing components.
In Section 8, we discuss those parameters that it must be possible
to monitor for the purposes of managing a diffserv router.
3. Elements of a Diffserv Router
In this section we introduce a block diagram of a diffserv router
and describe the various components illustrated. Note that the
functions of a diffserv core router are likely to be a much
simplified set of these components: the model we present here is
intended to cover the case of a diffserv edge router as well as the
core.
3.1 Conceptual Model
The conceptual model we define includes abstract definitions of the
following:
1. The basic traffic classification components.
2. The basic traffic conditioning components.
3. Certain combinations of traffic conditioning components.
4. Queuing components.
The components and combinations of components described in this
document form building blocks that need to be manageable by
diffserv management tools. One of the goals of this document is to
show how a model of a diffserv device can be built up out of these
component blocks. This model is in the form of a connected acyclic
directional graph that describes the traffic conditioning behaviour
that any particular data packet will experience when submitted to
the diffserv router.
It is anticipated that these building blocks may also be used as
the basis for a diffserv MIB or other such specific device
configuration mechanisms.
Bernet, Smith, Blake expires December, 1999 3
draft-ietf-diffserv-model-00.txt June, 1999
3.2 Block Diagram
The following diagram illustrates the major functional blocks of a
diffserv router:
+--------------+
| diffserv |
Mgmt | configuration|
<------>| & monitoring |----------------
SNMP,| | interface | |
COPS | +--------------+ |
etc. | | |
| | |
| v v
| +----------+ +-------+ +---------+ +-------+
data | |ingress | |routing| |egress | |queuing|
------->|-classif. |-->| |-->|-classif.|-->| stuff |-->
| |-TCB | +-------+ |-TCB | +-------+
| +----------+ +---------+
| ^ ^
| | |
| +----------+ |
-->| | |
------->| RSVP |--------------------
RSVP |(optional)|
cntl +----------+
msgs
In this diagram, a Traffic Conditioning Block (TCB) represents a
combination of metering, marking, shaping, dropping elements that
are discussed in more detail below.
3.2.1 Interfaces, Classification, Traffic Conditioning, Queuing and the
Routing Core
An ingress interface, routing component and egress interface are
illustrated at the center of the diagram. In actual router
implementations, there may be an arbitrary number of inbound and
outbound interfaces interconnected by the routing core. The
components of interest on these interfaces are the traffic
classifiers, the traffic conditioning components (TC) and the
queuing components that support the Per-Hop Behaviour (PHB)
[DSARCH]. These are the fundamental components comprising a diffserv
router and will be the focal point of our conceptual model.
3.2.2 Diffserv Configuration and Monitoring 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
are important for accounting purposes and for tracking compliance to
service level agreements (SLAs [DSARCH]) negotiated with customers.
Bernet, Smith, Blake expires December, 1999 4
draft-ietf-diffserv-model-00.txt June, 1999
Provisioned parameters are primarily classification rules, PHB and
TC configuration parameters. The network administrator interacts
with the diffserv configuration and monitoring interface via one or
more management protocols, such as SNMP or COPS [COPS] or through
other router configuration tools such as serial terminal or telnet
consoles.
3.2.3 Optional RSVP Module
Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E]. The example
discussed here uses the RSVP protocol. Snooping of RSVP messages may
be used, for example, to learn how to classify traffic without
actually participating as a RSVP protocol peer. Diffserv routers may
reject or admit RSVP reservation requests to provide a means of
admission control to diffserv-based services or they may use these
requests to trigger provisioning changes for a flow-aggregation in
the diffserv network. A flow-aggregation in this context might be
equivalent to a diffserv BA or it may be more fine-grained, relying
on a MF classifier. Note that the conceptual model of such a router
starts to look the same as a Integrated Services (intserv) router in
its component makeup [E2E].
Note that a RSVP component of a diffserv router, if present, might
be active only in the control plane and not in the data plane. In
this scenario, RSVP is used strictly as a signaling protocol. The
data plane of such a diffserv router can still act purely on
diffserv DSCPs and PHBs in handling data traffic.
3.3 Hierarchical Model of Diffserv Components
We focus on the diffserv specific functional components of the
router, the traffic conditioning and queuing functionality. The
example below is based on the larger block diagram shown above:
Interface A Interface B
+------------+ +-------+ +------------+
------->| ingress |---->| |---->| egress |--->
|(class.,TC) | | | |(queuing,TC)|
+------------+ |routing| +------------+
| |
+------------+ | | +------------+
<-------| egress |<----| |<----| ingress |<---
|(queuing,TC)| +-------+ |(class.,TC) |
+------------+ +------------+
Figure 1 - Traffic Conditioning and Queuing
This diagram illustrates two diffserv router interfaces, each having
an ingress and an egress component. It shows classification and TC
components on each interface's ingress and it shows both TC and PHB
components on each interface's egress. From a management
perspective, the following hierarchy exists:
Bernet, Smith, Blake expires December, 1999 5
draft-ietf-diffserv-model-00.txt June, 1999
At the top level, the router manager manages interfaces. Each
interface consists of an ingress component and an egress component.
An ingress component contains TC components. An egress component
contains PHB components and TC components. (There may be special
cases in which a router implements PHB components on an ingress
interface. This model is readily extensible to reflect such an
implementation. However, we have chosen not to do so in this case.)
The TC components on each interface are described by a traffic
conditioning table (TCT) corresponding to the interface. The TCT
describes traffic classification and conditioning elements and how
they are combined to provide the interface's traffic conditioning
functionality. Certain traffic conditioning elements may be grouped
into traffic conditioning blocks (TCBs).
PHB components contain queues and the enqueuing and dequeuing
algorithms that serve them. Queues are each independently
parameterized. There may also be parameters defining relationships
between PHBs.
4. Classification Elements
Classification is a necessary function for any device that treats
certain traffic differently from other traffic. The very nature of a
diffserv router is that it treats traffic differentially. Therefore,
classification is the most basic function required from a
differentiated service router.
Classification is performed by a classifier. Classifiers take a
single traffic stream as input and generate logically separate
traffic streams as output. Packets from the input stream are sorted
into various output streams depending on the contents of the packet
and possibly on other sources of information e.g. input sub-channel
number. The various types of classifiers are described in the
following sections.
4.1 Behaviour Aggregate (BA) Classifier
The simplest diffserv classifier is a behaviour aggregate (BA)
classifier. A BA classifier uses only the diffserv codepoint (DSCP)
in a packet's IP header to determine the logical output stream to
which the packet should be directed.
4.2 Multi-Field (MF) Classifier
Another type of classifier is a multi-field (MF) classifier. This
classifies packets based on one or more fields in the packet header
other than the DSCP. A common type of MF classifier is a 5-tuple
classifier that classifies based on the five IP header fields of
source/destination address, source/destination port and IP protocol
number. MF classifiers may classify based on other fields such as
Bernet, Smith, Blake expires December, 1999 6
draft-ietf-diffserv-model-00.txt June, 1999
MAC addresses, VLANs, link-layer traffic class or other higher layer
protocol addresses.
4.3 Other Classifier Types
Classification may be performed based on implicit information
associated with a packet (e.g. the incoming channel number on a
channelized interface) or on information derived from a different
classification operation (e.g. the outgoing interface determined by
the route lookup operation). We do not discuss these further here.
4.4 Filters
Classifiers are parameterized by filters and output streams. For
example, the following classifier separates traffic into one of
three output streams based on two filters:
Filter Matched Output Stream
-------------- ---------------
1 A
2 B
no match C
Where filters 01 and 02 are defined to be the following BA filters:
Filter DSCP
------ ------
1 101010
2 111111
A filter consists of a set of conditions on the component values of
a classification key. In the BA classifier example above, the
classification key consists of one packet header field, the DSCP,
and both Filter1 and Filter2 specify exact-match conditions on the
value of the DSCP. The third filter is a wildcard default filter
which matches every packet, but which is only selected in the event
that no other more specific filter matches.
In general there are a whole set of possible component conditions
including exact, prefix, range, wildcard and masked matches. Note
that ranges can be represented (maybe less efficiently) as a set of
prefix matches and that prefix matches are just a special case of
masked matches.
In the case of a MF classifier, the classification key consists of a
number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example
below for a TCP/IPv4 classifier:
Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort
------ ------------- ------------- ----------- ------------
Filter1 172.31.8.1/32 172.31.3.X/24 X 5003
Bernet, Smith, Blake expires December, 1999 7
draft-ietf-diffserv-model-00.txt June, 1999
In this example, the fourth octet of the destination IPv4 address
and the source TCP port are 'don't cares'.
4.5 Diagram of a Classifier
We use the following diagram to illustrate a classifier, where the
outputs are to be plumbed in to succeeding TC elements:
unclassified classified
traffic traffic
-----------
| |--> match Filter1 --> output A
----->|classifer|--> match Filter2 --> output B
| |--> no match --> output C
-----------
Figure 2 - An Example Classifier
Note that an input interface number can also be considered as an
input to the classifier if the classifier is modeled as accepting
packets from multiple input ports - this optimisation may be
important for scalability in the management plane.
4.6 Formal Representation of Classifiers
4.6.1 IPv4 5-tuple Classifier
The following formal definition can be used to represent a
classifier using masked match conditions:
Classifier0:
Filter1: output A
Filter2: output B
No Match: output C
Filter1: Filter2:
Type: IPv4 5-tuple Type: IPv4 5-tuple
Ipv4SrcAddrValue: 172.31.8.0 Ipv4SrcAddrValue: 172.31.9.0
Ipv4DestAddrValue: 0 Ipv4DestAddrValue:0
Ipv4SrcPortValue: 0 Ipv4SrcPortValue: 0
Ipv4DestPortValue: 5003 Ipv4DestPortValue:5003
Ipv4ProtocolValue: 0 Ipv4ProtocolValue:0
Ipv4SrcAddrMask: 255.255.255.0 Ipv4SrcAddrMask: 255.255.255.0
Ipv4DestAddrMask: 0.0.0.0 Ipv4DestAddrMask: 0.0.0.0
Ipv4SrcPortMask: 0 Ipv4SrcPortMask: 0
Ipv4DestPortMask: 0xFFFF Ipv4DestPortMask: 0xFFFF
Ipv4ProtocolMask: 0 Ipv4ProtocolMask: 0
4.6.2 IPv6 5-tuple Classifier
Bernet, Smith, Blake expires December, 1999 8
draft-ietf-diffserv-model-00.txt June, 1999
The following formal definition can be used to represent a IPv6
multi-field classifier using masked match conditions:
Classifier1:
Filter3: output A
No Match: output B
Filter3:
Type: IPv6 5-tuple
Ipv6SrcAddrValue: 0:0:0:0:0:FFFF:32.12.65.0
Ipv6SrcAddrMask: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0
Ipv6DestAddrValue: 1080:0:0:0:0:0:0:0
Ipv6DestAddrMask: FFFF:FFFF:FFFF:FFFF:0:0:0:0
Ipv6SrcPortValue: 0
Ipv6SrcPortMask: 0
Ipv6DestPortValue: 5003
Ipv6DestPortMask: 0xFFFF
Ipv6NextHeaderValue: 6
Ipv6NextHeaderMask: 0xFF
4.6.3 Behaviour Aggregate Classifier
A BA classifier is parameterised by a set of 6-bit DSCP {value,
mask} pairs:
Classifier1:
Filter3: output A
Filter4: output B
No Match: output C
Filter3: Filter4:
Type: BA Type: BA
Value: 111000 Value: 110000
Mask: 111111 Mask: 111111
4.6.4 IEEE802 MAC Address Classifiers
A MacAddress classifier is parameterised by a 6-byte {value, mask}
pair for either source or destination MAC address.l for example, the
following classifier sends packets matching either DA 01-02-03-04-
05-06 or SA 00-E0-2B-XX-XX-XX to output A:
Classifier2:
Filter5: output A
Filter6: output A
No Match: output B
Filter5:
Type: DestMacAddress
Bernet, Smith, Blake expires December, 1999 9
draft-ietf-diffserv-model-00.txt June, 1999
Value: 01-02-03-04-05-06 (hex)
Mask: FF-FF-FF-FF-FF-FF (hex)
Filter6:
Type: SrcMacAddress
DestValue: 00-E0-2B-00-00-00 (hex)
DestMask: FF-FF-FF-00-00-00 (hex)
4.6.5 Free-form Classifier
A FreeForm classifier is made up of a set of user definable
arbitrary filters each made up of {bit-field size, offset (from head
of packet), mask}:
Classifier3:
Filter6: output A
Filter7: output B
No Match: output C
Filter6:
Type: FreeForm
SizeBits: 3 bits
Offset: 16 bytes
Value: 100 (binary)
Mask: 101 (binary)
Filter7:
Type: FreeForm
SizeBits: 12 bits
Offset: 16 bytes
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
4.6.6 Other Standard Classifiers
e.g. IEEE802.1p, IEEE802.1Q VLAN-ID
Classifier4:
Filter8: output A
Filter9: output B
No Match: output C
Filter8:
Type: IeeePriority
Value: 100 (binary)
Mask: 101 (binary)
Filter9:
Type: IeeeVlan
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
4.6.7 Vendor-Specific Classifier
Bernet, Smith, Blake expires December, 1999 10
draft-ietf-diffserv-model-00.txt June, 1999
Other vendor specific filter formats.
4.7 Combinations of Filters
Filters may be logically combined. For example, consider the
following DestMacAddress filter:
Filter3:
Type: DestMacAddress
Value: 01-02-03-04-05-06
Mask: FF-FF-FF-FF-FF-FF
Classifier0 could then be declared as:
Classifier0:
Filter1 and Filter3: output A
Filter2 and Filter3: output B
No Match: output C
4.7.1 Conflicting Filters
Note that it is easy to define sets of conflicting filters in a
classifier. For example:
Filter1: Filter2:
Type: BA Type: BA
Value: 111000 Value: 000111 (binary)
Mask: 111000 Mask: 000111 (binary)
A packet containing the DSCP 111111 cannot be uniquely classified by
this set of filters and so a precedence must be established between
Filter1 and Filter2 in order to break the tie. This precedence must
be established either (a) by a manager which knows that the router
can accomplish this particular ordering e.g. by means of reported
capabilities or (b) by the router along with a mechanism to report
to a manager which precedence is being used. These ordering
mechanisms must be supported by the management protocol although
further discussion of this is outside the scope of this document.
5. Traffic-Conditioning Elements
Traffic-conditioning is a essential function of a diff-serv router,
defined in [DSARCH]. This section defines the elements that can be
combined to provide the traffic-conditioning functionality
described. These include meters and various action elements.
5.1 Meters
Metering is the function of monitoring the arrival times of packets
on a traffic stream and determining the level of conformance of each
packet to a profile. Diffserv network providers may offer services
to customers based on a temporal profile within which the customer
Bernet, Smith, Blake expires December, 1999 11
draft-ietf-diffserv-model-00.txt June, 1999
submits traffic for the service. In this event, a meter might be
used to trigger real-time effects (e.g. marking) downstream; it
might also just be used for out-of-band management functions like
statistics monitoring and billing applications.
Meters are parameterized by a temporal profile and by conformance
levels.
5.1.1 Types of Meters
5.1.1.1 Average Rate Meter
An example of a very simple meter is an average rate meter. This
type of meter measures the average rate at which packets are
submitted to it over a specified averaging time.
An average rate profile may take the following form:
Average Rate: 10 packets per second
Averaging Interval: 1 second
A meter measuring against this profile would continually maintain a
count that indicates the total number of packets arriving between
time T (now) and time T-1 second. So long as an arriving packet does
not push the count over 10, the packet would be deemed conforming.
Any packet that pushes the count over 10, would be deemed non-
conforming. Thus, this meter deems packets to correspond to one of
two conformance levels - conforming or non-conforming.
5.1.1.2 Exponential Weighted Moving Average Meters
The EWMA form of meter is easy to implement in silicon and can be
parameterised as follows:
avg(n+1) = (1-Gain) * avg(n) + Gain * actual(n+1)
t(n+1) = t(n) + Delta
For a packet arriving at time t(m):
if (avg(m) > AverageRate)
non-conforming
else
conforming
Gain controls the time constant (e.g. frequency response) of what is
essentially a simple IIR low-pass filter. actual(n) and avg(n)
measure the number of incoming bytes in a small fixed sampling
interval, Delta. Any packet that arrives and pushes the average rate
over a predefined rate AverageRate is deemed non-conforming.
5.1.1.3 Token Bucket Meters
Bernet, Smith, Blake expires December, 1999 12
draft-ietf-diffserv-model-00.txt June, 1999
A more sophisticated meter might measure conformance to a token
bucket (TB) profile. A TB profile generally has three parameters, an
average rate, a peak rate and a burst size. TB meters compare the
arrival rate of packets to the average rate specified by the TB
profile. Logically, byte tokens accumulate in a bucket at the
average rate, up to a maximum credit which is the burst size.
Packets of length L bytes are considered conforming if L tokens are
available in the bucket at the time of packet arrival. Packets are
allowed to exceed the average rate in bursts up to the burst size,
so long as they do not exceed the peak rate, at which point the
bucket will be drained. Packets which arrive to find a bucket with
insufficient tokens in it are deemed non-conforming.
More complicated token bucket models might define two burst sizes
and three conformance levels. Packets found to exceed the larger
burst size are deemed non-conforming. Packets found to exceed the
smaller burst size are deemed partially conforming. Packets
exceeding neither are deemed conforming. Token bucket meters
designed for diff-serv networks are described in more detail in
[SRTCM], [TRTCM] and [GTC]: in some of these references, three
levels of conformance are discussed in terms of colors, with green
representing conforming, yellow representing partially conforming
and red representing non-conforming.
5.1.2 Diagram of a Meter
We use the following diagram to illustrate a meter with 3 levels of
conformance:
unmetered metered
traffic traffic
-----------
| |--------> conformanceA
--------->| meter |--------> conformanceB
| |--------> conformanceC
-----------
Figure 3 - An Example Meter
In some diffserv examples, three levels of conformance are discussed
in terms of colors, with green representing conforming, yellow
representing partially conforming and red representing non-
conforming. Other example meters use a binary notion of conformance;
in the general case there are 'N' levels of conformance.
5.1.3 Formal Representations of Meters
5.1.3.1 Simple Token Bucket Meter
The following formal definition can be used to represent this meter:
Meter1:
Bernet, Smith, Blake expires December, 1999 13
draft-ietf-diffserv-model-00.txt June, 1999
Type: SimpleTokenBucket
Profile1: output A
NonConforming: output B
Profile1:
Type: SimpleTokenBucket
AverageRate: 100 Kbps
PeakRate: 150 Kbps
BurstSize 100 Kb
5.1.3.2 EWMA Meter
Meter2:
Type: ExpWeightedMovingAvg
Profile2: output A
NonConforming: output B
Profile2:
Type: ExpWeightedMovingAvg
Gain: 1/16
Delta: 10us
AverageRate: 200 Kbps
5.1.3.3 Two-level Token Bucket Meter
Meter3:
Type: TwoLevelTokenBucket
Profile3: output A
Profile4: output B
NonConforming: output C
Profile3:
Type: SimpleTokenBucket
AverageRate: 100 Kbps
PeakRate: 150 Kbps
BurstSize 50 Kb
Profile4:
Type: SimpleTokenBucket
AverageRate: 120 Kbps
PeakRate: 150 Kbps
BurstSize 100 Kb
5.1.3.4 Average Rate Meter
Meter4:
Type: AverageRate
Profile5: output A
NonConforming: output B
Profile5:
Type: AverageRate
AverageRate: 120 Kbps
Bernet, Smith, Blake expires December, 1999 14
draft-ietf-diffserv-model-00.txt June, 1999
Delta: 100us
5.1.3.5 Other Vendor-specific Meters
Other vendor specific meters are also possible.
5.2 Action Elements
Classifiers and meters are generally used to determine the
appropriate action to apply to a packet. The set of possible non-
exclusive actions include:
1) Marking
2) Shaping
3) Dropping
4) Monitoring
The corresponding action elements are described in the following
paragraphs. Each of these actions has a default treatment which is
to simply pass the packet on to a PHB queue.
Policing is a general term for the action of preventing a traffic
stream from seizing more than its share of resources from a diffserv
network. Each of the three action elements described may be used to
police traffic. Markers do so by re-marking submitted packets to a
DSCP that is entitled to less network resources. Shapers and
droppers do so by limiting the rate at which a particular traffic
stream is submitted to the network.
5.2.1 Markers
Markers set the DSCP in a packet header. Markers may act on unmarked
packets (submitted with DSCP of zero) or may re-mark previously
marked packets. In particular, the model supports the application of
marking based on a preceding classifier match. The DSCP set in a
packet will determine its subsequent treatment both by any following
classifier elements within the same node or by other nodes
downstream in the diffserv network.
Markers are parameterized by a single parameter - the six-bit DSCP
to be marked in packet headers.
5.2.1.1 Formal Representation of a Marker
The following formal definition can be used to represent a marker:
ActionElement1:
Type: Marker
Mark: 010010
5.2.2 Shapers
Shapers are used to shape traffic to a certain temporal profile. For
example, a shaper can be used to smooth traffic arriving in bursts.
Bernet, Smith, Blake expires December, 1999 15
draft-ietf-diffserv-model-00.txt June, 1999
Shapers operate by delaying packets that would be deemed non-
conforming to the shaper's profile. The packet is delayed until such
time that it becomes conforming. Consider the average rate profile
described previously. In the case that a burst of 11 packets was
submitted simultaneously to a meter using the average rate profile,
the 11th packet would be deemed non-conforming. In order to be
deemed conforming, the packet would have to be delayed by one
second. Thus, a shaper parameterized by the average rate profile
(see section 5.1.1.1) would delay the 11th packet for one second.
Shapers are parameterized by a single temporal profile e.g. a token
bucket.
Implicit in the definition of a shaper is a notion of a queue and a
queue depth: in order to delay a packet, a shaper must have
somewhere to store the packet and that storage area often has finite
size. The queue is modeled here as a simple FIFO with a finite
depth. Packets are dropped if the depth is exceeded - this is
considered to be an error condition.
5.2.2.1 Uses of Shapers
Shapers are often used to pre-condition traffic such that packets
are not deemed non-conforming by subsequent meters, e.g. in
downstream diffserv nodes. Shapers may also be used to isolate
certain traffic streams from the effects of other traffic streams of
the same BA. For example, consider the case of two traffic streams
that are submitted to a diffserv network for a particular diffserv
service level. The agreement between the customer and the diffserv
network provider limits the rate of traffic that can be submitted at
a certain service level. In this case, one of the two traffic
streams may attempt to seize more than its fair share of the
available capacity for the service level. By doing so, it
compromises the other traffic stream. A shaper that acts
independently on the two streams can be used to limit the effect of
the rogue stream. Note also that a BA might be metered against one
profile whilst being shaped to a different profile further
downstream in the same device.
5.2.2.2 Formal Representation of a Shaper
The following formal definition can be used to represent a shaper:
ActionElement2:
Type: Shaper
Profile: Profile1
QueueDepth: size in bytes and/or packets
Profile definitions are identical in format to those described under
the formal definition of a meter.
5.2.3 Droppers
Bernet, Smith, Blake expires December, 1999 16
draft-ietf-diffserv-model-00.txt June, 1999
Droppers simply discard packets. There are no parameters for
droppers.
5.2.3.1 Formal Representation of a Dropper
The following formal definition can be used to represent a dropper:
ActionElement03:
Type: Dropper
5.2.4 Monitoring
One passive form of an action to be taken is simply to account for
the fact that a data packet was processed. This might be used later
on in presenting statistics for customer usage-based billing.
Further discussion of instrumentation for monitoring is provided in
section 0 although the topic of accounting is not dealt with in
detail here.
6. Traffic Conditioning Blocks (TCBs)
The classifiers and traffic conditioning elements described above
can be combined into traffic conditioning blocks (TCBs). The TCB is
an abstraction of a functional block that may be used to facilitate
the definition of traffic conditioning functionality.
A general TCB consists of three stages:
1. Classifier stage
2. Metering stage
3. Action stage
TCBs are constructed by connecting elements corresponding to these
stages in any order. It is allowable to omit stages or to
concatenate multiple stages of the same type. TCB outputs may drive
additional TCBs (on the same interface or on an egress interface) or
alternatively, may be directed to a PHB queue on an egress
interface.
6.1 Example TCB
The following diagram illustrates an example TCB:
Bernet, Smith, Blake expires December, 1999 17
draft-ietf-diffserv-model-00.txt June, 1999
-------------> to Queue A
------- |
| |---
-->| |
| | |--- -------
| ------- | | |
| meter -->| |-----> discard
| | |
| -------
| dropper
|
|
| -------------> to Queue B
submitted ------- | ------- | ^
traffic | A |------- | |--- |
--->| B |-------->| | |
| C |------- | |--- ------- |
| X |---- | ------- | | | |
------- | | meter -->| |---
BA | | | |
classifier | | -------
| | shaper
| |
| |
| | -------------> to Queue C
| | ------- |
| | | |---
| -->| |
| | |--- -------
| ------- | | |
| meter -->| |---> to Queue D
| | |
| -------
| re-marker
|
----------------------------> to Queue E
Figure 4 - An Example Traffic Conditioning Block
This sample TCB might be suitable for an ingress interface at a
customer/provider interface. A SLA is presumed to have been
negotiated between the customer and the provider which specifies the
handling of the customer's traffic by the provider's network. The
agreement might be of the following form:
DSCP PHB Profile Non-Conforming Packets
---- --- ------- -------------------------
001001 PHB1 Profile1 Discarded
001100 PHB2 Profile2 Shaped to Profile1
001101 PHB3 Profile3 Re-marked to DSCP 001000
It is implicit in this agreement that conforming packets are given
the PHB originally indicated by the packets' DSCP field. It
Bernet, Smith, Blake expires December, 1999 18
draft-ietf-diffserv-model-00.txt June, 1999
specifies that the customer may submit packets marked for DSCP
001001 which will get PHB1 treatment so long as they remain
conforming to Profile1 and will be discarded if they exceed this
profile. Similar contract rules are applied for 001100 and 001101
traffic.
In this example, the classification stage consists of a single BA
classifier. The BA classifier is used to separate traffic based on
the diffserv service level requested by the customer (as indicated
by the DSCP in each submitted packet's IP header). We illustrate
three DSCP filter values: A, B and C. The 'X' in the BA classifier
indicates 'no match'.
The metering stage is next. There is a separate meter for each set
of packets corresponding to DSCPs A, B and C. Each meter uses a
specific profile as specified in the SLA for the corresponding
diffserv service level. The meters in this example indicate one of
two conforming levels, conforming or non-conforming.
Following the metering stage is the action stage. Packets submitted
for DSCP A that are deemed non-conforming are discarded. Packets
that are conforming are passed on to the queue for the corresponding
PHB.
Packets submitted for DSCP B that are deemed non-conforming are
delayed in a shaper until they become conforming. Packets that are
deemed conforming are allowed to pass directly to the queue for PHB
B.
Note that in actual implementations, non-conforming packets will
cause packets on the same traffic stream that are conforming to be
delayed in order to maintain per-stream packet ordering. However,
this is an implementation detail and need not be considered from the
abstract management perspective.
Packets submitted for DSCP C and deemed non-conforming are re-marked
for a less privileged DSCP and are directed to the appropriate PHB
queue. Packets that are deemed conforming are passed directly to the
requested PHB queue.
6.2 Formal Representation of TCB
The following is a formal representation of the interconnection of
the components of the TCB illustrated in Error! Reference source not
found.:
TCB1:
Classifier1:
Output A --> Meter1
Output B --> Meter2
Output C --> Meter3
Output X --> QueueE
Bernet, Smith, Blake expires December, 1999 19
draft-ietf-diffserv-model-00.txt June, 1999
Meter1:
Output A --> QueueA
Output B --> ActionElement1 (dropper)
Meter2:
Output A --> QueueB
Output B --> ActionElement2 (shaper)
ActionElement2:
DefaultOutput --> QueueB
Meter3:
Output A --> QueueC
Output B --> ActionElement3 (marker)
ActionElement3:
DefaultOutput --> QueueD
6.3 Example TCB to Support Multiple Customers
The TCB described above can be installed on an ingress interface to
implement a provider/customer agreement if the interface is
dedicated to the customer. However, if a single interface is shared
between multiple customers, then the TCB above will not suffice,
since it does not differentiate among traffic from different
customers. Its classification stage uses BA classifiers only.
The TCB is readily extended to support the case of multiple
customers per interface, as follows. First, we define a TCB for each
customer to reflect the agreement with that customer. TCB1, defined
above is the TCB for customer 1. We add definitions for TCB2 and for
TCB3 which reflect the agreements with customers 2 and 3
respectively.
Finally, we add a fourth TCB, TCB4, which provides a front end to
separate the traffic from the three different customers. This can be
illustrated as:
submitted +-----+
traffic | A |--------> TCB1
--->| B |--------> TCB2
| C |--------> TCB3
| X |--------> ActionElement4 (dropper)
+-----+
TCB4
Figure 5 - An Example Multi-Cusomer Front End TCB
A formal representation of this multi-customer TCB might be:
TCB1:
Bernet, Smith, Blake expires December, 1999 20
draft-ietf-diffserv-model-00.txt June, 1999
(as defined above)
TCB2:
(similar to TCB1, perhaps with different numeric parameters)
TCB3:
(similar to TCB1, perhaps with different numeric parameters)
TCB4:
Classifier2:
Output A --> TCB1
Output B --> TCB2
Output C --> TCB3
Output X --> ActionElement4 (dropper)
Where Classifier2 is defined as follows:
Classifier2:
Filter1: output A
Filter2: output B
Filter3: output C
No Match: output X
and the filters, based on each customer's source MAC address are
defined as follow:
Filter1:
Type: MacAddress
SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1)
SrcMask: FF-FF-FF-FF-FF-FF
DestValue: 00-00-00-00-00-00
DestMask: 00-00-00-00-00-00
Filter2:
(similar to Filter1 but with customer 2's source MAC address as
SrcValue)
Filter3:
(similar to Filter1 but with customer 3's source MAC address as
SrcValue)
In this example, TCB4 separates traffic submitted from different
customers based on the source MAC address in submitted packets.
Those packets with recognized source MAC addresses are passed to the
TCB implementing the agreement with the corresponding customer.
Those packets with unrecognized source MAC addresses are passed to a
dropper.
TCB4 has a classification stage and an action element stage (it is
used only for unrecognized traffic) i.e. all actions are the default
which is to pass through unchanged. Its outputs drive either the
dropper action element or additional TCBs.
Bernet, Smith, Blake expires December, 1999 21
draft-ietf-diffserv-model-00.txt June, 1999
6.4 TCBs Supporting Microflow-based Services
The TCB illustrated above describes a TC configuration that might be
suitable for enforcing a SLA at a router's ingress. It assumes that
the customer marks its own traffic for the appropriate service
level. It then limits the rate of aggregate traffic submitted at
each service level, thereby protecting the resources of the diffserv
network. It does not mark the customer's packets, nor does it
provide any isolation between the customer's individual microflows.
Next we present a TC configuration that offers additional
functionality to the customer. It recognizes individual customer
microflows and marks each one independently. It also isolates the
customer's individual microflows from each other in order to prevent
a single microflow from seizing an unfair share of the resources
available to the customer at a certain service level. This is
illustrated in Figure 6 below:
------- -------
| | | |--------------->
-->| |-->| | -------
------- | | | | |---->| |
| |---- ------- ------- -------
->| |---- marker meter dropper
| |-- | ------- -------
------- | | | | | |--------------->
MF | -->| |-->| | -------
class. | | | | |---->| |
| ------- ------- -------
| marker meter dropper
| ------- -------
| | | | |--------------->
|--->| |-->| | -------
| | | | |---->| |
| ------- ------- -------
| marker meter dropper
| . . .
V V V V
Figure 6 - An Example of a Marking and Traffic Isolation TCB
Traffic is first directed to an MF classifier which classifies
traffic based on miscellaneous classification criteria, to a
granularity sufficient to identify individual customer microflows.
Each microflow can then be marked for a specific DSCP (in this
particular example we assume that one of two different DSCPs is
marked). The metering stage limits the contribution of each of the
customer's microflows to the service level for which it was marked.
Packets exceeding the allowable limit for the microflow are dropped.
The TCB would be formally specified as follows:
Bernet, Smith, Blake expires December, 1999 22
draft-ietf-diffserv-model-00.txt June, 1999
TCB1:
Classifier1: (MF)
Output A --> Marker1
Output B --> Marker2
Output C --> Marker3
. . .
Marker1 --> Meter1
Marker2 --> Meter2
Marker3 --> Meter3
Meter1:
Output A --> TCB2
Output B --> ActionElement1 (dropper)
Meter2:
Output A --> TCB2
Output B --> ActionElement2 (dropper)
Meter3:
Output A --> TCB2
Output B --> ActionElement3 (dropper)
The actual traffic element declarations are not shown here.
Traffic is either dropped by TCB1 or emerges marked for one of two
DSCPs. This traffic is then passed to TCB2, illustrated below:
-------
| |--------------->
-->| | -------
------- | | |---->| |
| |---- ------- -------
->| | meter dropper
| |---| -------
------- | | |--------------->
BA -->| | -------
classifier | |---->| |
------- -------
meter dropper
Figure 7 - Additional Example TCB
TCB2 would be formally specified as follows:
Classifier2: (BA)
Output A --> Meter10
Output B --> Meter11
Meter10:
Output A --> PHBQueueA
Output B --> ActionElement10 (dropper)
Bernet, Smith, Blake expires December, 1999 23
draft-ietf-diffserv-model-00.txt June, 1999
Meter11:
Output A --> PHBQueueB
Output B --> ActionElement11 (dropper)
7. Queuing Components
Queuing components are the final conceptual components of the model
of a diffserv router before packets leave a device. The queuing
behaviours implemented on an egress interface are modeled as a set
of inter-dependent queues that are serviced by a queuing algorithm
with certain parameters and profiles. In particular, the scheduling
parameters may be any of the Profile types defined for TC elements
above e.g. SimpleTokenBucket, AverageRate, ExpWeightedMovingAvg.
QueueSet1:
Type: QueueSet
MaxSustRate: 100 Mbps
MinGuarRate: 20 Mbps
Interface: ifIndex
- guaranteed buffer pool for this queue set (?)
QueueA:
Type: Queue
QueueSet: QueueSet1
Profile: Profile1
MinGuarRate: 2 Mbps
QueueDepth: 200 kbytes
Priority: 5
QueueB:
Type: Queue
QueueSet: QueueSet1
Profile: Profile2
MinGuarRate: 2 Mbps
QueueDepth: 200 kbytes
Priority: 3
- guaranteed buffer pool for each queue (?)
8. Monitoring
Generally, it should be possible to retrieve the TCTs and similar
tabular representations of the different diffserv router components.
It should be possible to monitor the count of packets submitted to
each TC element and the disposition of the packet (which of the
element outputs it was directed to).
Bernet, Smith, Blake expires December, 1999 24
draft-ietf-diffserv-model-00.txt June, 1999
In the case of the installation in a router of packet filters that
conflict, it must be possible to determine the relative precedence
of the filters as implemented by the router.
9. Initial State
(TBD)
10. Security Considerations
11. References
[DSARCH] Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D.,
Davies, E., "An Architecture for Differentiated Services", RFC 2475,
December 1998
[DSFWK] Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B.,
Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework
for Differentiated Services", Internet Draft, February 1999
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework-
02.txt
[E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Nichols, K., Speer, M., Braden, R., Davie, B., "Integrated Services
Operation over Diffserv Networks", Internet Draft, June 1999,
www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-02.txt
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998.
[EF-PHB] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski "
Assured Forwarding PHB Group", RFC 2597, June 1999.
[DSMIB] Baker, F., Pan, P., Guerin, R., Bernet, Y., "Differentiated
Service Management Information Base using SMIv2", Internet Draft,
June 1999. http://www.ietf.org/internet-drafts/draft-ietf-diffserv-
mib-00.txt
[SRTCM] Heinanen, J., Guerin, R., "A Single Rate Three Color
Marker", Internet Draft, May 1999, www.ietf.org/internet-
drafts/draft-heinanen-diffserv-srtcm-01.txt
Bernet, Smith, Blake expires December, 1999 25
draft-ietf-diffserv-model-00.txt June, 1999
[TRTCM] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker",
Internet Draft, May 1999, www.ietf.org/internet-drafts/heinanen-
diffserv-trtcm-01.txt
[GTC] Lin, L., Lo, J., Ou, F., "A Generic Traffic Conditioner",
Internet Draft, April 1999, www.ietf.org/internet-drafts/draft-lin-
diffserv-qtc-00.txt
12. Author's Addresses
Yoram Bernet
Microsoft
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 9568
E-mail: yoramb@microsoft.com
Andrew Smith
Extreme Networks
3585 Monroe St.
Santa Clara, CA 95051
Phone: +1 408 579 2821
E-mail: andrew@extremenetworks.com
Steven Blake
Ericsson Datacom
3000 Aerial Center Parkway, Suite 140
Morrisville, NC 27560
Phone: 919-468-8466 x232
E-mail: slblake@torrentnet.com
Bernet, Smith, Blake expires December, 1999 26