draft-ietf-diffserv-model-01.txt   draft-ietf-diffserv-model-02.txt 
Internet Engineering Task Force Y. Bernet Internet Engineering Task Force Y. Bernet
Diffserv Working Group Microsoft Diffserv Working Group Microsoft
INTERNET-DRAFT A. Smith INTERNET-DRAFT A. Smith
Expires: April 2000 Extreme Networks Expires: September 2000 Extreme Networks
S. Blake S. Blake
Ericsson Ericsson
October 1999 D. Grossman
Motorola
A Conceptual Model for Diffserv Routers A Conceptual Model for Diffserv Routers
draft-ietf-diffserv-model-01.txt draft-ietf-diffserv-model-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 10, line ? skipping to change at page 10, line ?
<diffserv@ietf.org>. <diffserv@ietf.org>.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
DISCLAIMER - for reasons outside our control this version has been
rushed out with formatting errors and not checked by all authors.
This draft proposes a conceptual model of Differentiated Services This draft proposes a conceptual model of Differentiated Services
(Diffserv) routers for use in their management and configuration. (Diffserv) routers for use in their management and configuration.
This model defines the general functional datapath elements This model defines the general functional datapath elements
(classifiers, meters, markers, droppers, monitors, mirrors, muxes, (classifiers, meters, markers, droppers, monitors, replicators, muxes,
queues), their possible configuration parameters, and how they might queues), their possible configuration parameters, and how they might
be interconnected to realize the range of classification, traffic be interconnected to realize the range of classification, traffic
conditioning, and per-hop behavior (PHB) functionalities described in conditioning, and per-hop behavior (PHB) functionalities described in
Bernet, et. al. Expires: September 2000 [page 1]
[DSARCH]. The model is intended to be abstract and capable of [DSARCH]. The model is intended to be abstract and capable of
representing the configuration parameters important to Diffserv representing the configuration parameters important to Diffserv
functionality for a variety of specific router implementations. It functionality for a variety of specific router implementations. It
Bernet, et. al. Expires: April 2000 [page 1]
is not intended as a guide to hardware implementation. is not intended as a guide to hardware implementation.
This model should serve as a rationale for the design of a Diffserv This model should serve as a rationale for the design of a Diffserv
MIB [DSMIB], as well for various configuration interfaces (such as MIB [DSMIB], as well for various configuration interfaces (such as
[PIB]). Since these documents are all evolving simultaneously there [PIB]). Since these documents are all evolving simultaneously there
are discrepancies between their current revisions; this should be are discrepancies between their current revisions; this should be
resolved in a future revision of this draft. resolved in a future revision of this draft.
Table of Contents Table of Contents
skipping to change at page 10, line ? skipping to change at page 10, line ?
4.2.5 Other Possible Classifiers ............................ 14 4.2.5 Other Possible Classifiers ............................ 14
4.3 MPLS ...................................................... 15 4.3 MPLS ...................................................... 15
5. Meters ....................................................... 15 5. Meters ....................................................... 15
5.1 Definition ................................................ 15 5.1 Definition ................................................ 15
5.2 Examples .................................................. 16 5.2 Examples .................................................. 16
5.2.1 Average Rate Meter .................................... 16 5.2.1 Average Rate Meter .................................... 16
5.2.2 Exponentially Weighted Moving Average (EWMA) Meter .... 17 5.2.2 Exponentially Weighted Moving Average (EWMA) Meter .... 17
5.2.3 Two-Parameter Token Bucket Meter ...................... 17 5.2.3 Two-Parameter Token Bucket Meter ...................... 17
5.2.4 Multi-Stage Token Bucket Meter ........................ 18 5.2.4 Multi-Stage Token Bucket Meter ........................ 18
5.2.5 Null Meter ............................................ 19 5.2.5 Null Meter ............................................ 19
6. Action Elements .............................................. 19 6. Action Elements .............................................. 19*
6.1 Marker .................................................... 19 6.1 Marker .................................................... 19*
6.2 Dropper ................................................... 20 6.2 Dropper ................................................... 20*
6.3 Shaper .................................................... 20 6.3 Shaper .................................................... 20*
6.4 Mirroring Element ......................................... 20 6.4 Replicating Element ....................................... 20*
6.5 Multiplexor ............................................... 20 6.5 Multiplexor ............................................... 20*
6.6 Enqueueing Element ........................................ 20 6.6 Monitor ................................................... 21*
6.7 Monitor ................................................... 21 6.7 Null Action ............................................... 21*
6.8 Null Action ............................................... 21
7. Queues ....................................................... 21 7. Queues ....................................................... 21
7.1 Queue Sets and Scheduling ................................. 21 7.1 Queue Sets and Scheduling ................................. 21
7.2 Shaping ................................................... 23 7.2 Shaping ................................................... 23
Bernet, et. al. Expires: July 2000 [page 2]
8. Traffic Conditioning Blocks (TCBs) ........................... 23 8. Traffic Conditioning Blocks (TCBs) ........................... 23
8.1 An Example TCB ............................................ 24 8.1 An Example TCB ............................................ 24
Bernet, et. al. Expires: April 2000 [page 2]
8.2 An Example TCB to Support Multiple Customers .............. 27 8.2 An Example TCB to Support Multiple Customers .............. 27
8.3 TCBs Supporting Microflow-based Services .................. 28 8.3 TCBs Supporting Microflow-based Services .................. 28
8.4 Cascaded TCBs ............................................. 31
9. Open Issues .................................................. 31 9. Open Issues .................................................. 31
10. Security Considerations ...................................... 31 10. Security Considerations ...................................... 31
11. Acknowledgments .............................................. 31 11. Acknowledgments .............................................. 31
12. References ................................................... 32 12. References ................................................... 32
Appendix A. Simple Token Bucket Definition ....................... 33 Appendix A. Simple Token Bucket Definition ....................... 33
1. Introduction 1. Introduction
Differentiated Services (Diffserv) [DSARCH] is a set of technologies Differentiated Services (Diffserv) [DSARCH] is a set of technologies
which allow network service providers to offer differing levels of which allow network service providers to offer differing levels of
skipping to change at page 10, line ? skipping to change at page 10, line ?
parameters of interest for configuration and management. The purpose parameters of interest for configuration and management. The purpose
of this draft is to define such a model. of this draft is to define such a model.
The basic forwarding functionality of a Diffserv router is defined in The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB]. other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
This document is not intended in any way to constrain or to dictate This document is not intended in any way to constrain or to dictate
the implementation alternatives of Diffserv routers. We expect that the implementation alternatives of Diffserv routers. We expect that
router vendors will demonstrate a great deal of variability in their router vendors will demonstrate a great deal of variability in their
implementations. To the extent that vendors are able to model their implementations. To the extent that vendors are able to model their
Bernet, et. al. Expires: September 2000 [page 3]
implementations using the abstractions described in this draft, implementations using the abstractions described in this draft,
configuration and management tools will more readily be able to configuration and management tools will more readily be able to
configure and manage networks incorporating Diffserv routers of configure and manage networks incorporating Diffserv routers of
Bernet, et. al. Expires: April 2000 [page 3]
various implementations. various implementations.
In Sec. 3 we start by describing the basic high-level functional In Sec. 3 we start by describing the basic high-level functional
elements of a Diffserv router and then describe the various elements of a Diffserv router and then describe the various
components. We then focus on the Diffserv-specific components of components. We then focus on the Diffserv-specific components of
the router and describe a hierarchical management model for these. the router and describe a hierarchical management model for these.
In Sec. 4 we describe classification elements and in Sec. 5, we In Sec. 4 we describe classification elements and in Sec. 5, we
discuss the meter elements. discuss the meter elements.
In Sec. 6 we discuss action elements. In Sec. 7 we discuss the In Sec. 6 we discuss action elements. In Sec. 7 we discuss the
skipping to change at page 10, line ? skipping to change at page 10, line ?
forwards the packet along a particular datapath within forwards the packet along a particular datapath within
the router. A classifier splits a single incoming the router. A classifier splits a single incoming
traffic stream into multiple outgoing ones. traffic stream into multiple outgoing ones.
Enqueueing The process of executing a buffer management algorithm Enqueueing The process of executing a buffer management algorithm
to determine whether an arriving packet should be to determine whether an arriving packet should be
stored in a queue. stored in a queue.
Filter A set of (wildcard/prefix/masked/range/exact) Filter A set of (wildcard/prefix/masked/range/exact)
conditions on the components of a packet's conditions on the components of a packet's
Bernet, et. al. Expires: September 2000 [page 4]
classification key. A filter is said to match only if classification key. A filter is said to match only if
each condition is satisfied. each condition is satisfied.
Bernet, et. al. Expires: April 2000 [page 4] Replicating A functional datapath element which makes one or more
Mirroring A functional datapath element which makes one or more
element copies of a packet and forwards them on distinct element copies of a packet and forwards them on distinct
datapaths; for example to a monitoring port. datapaths; for example to a monitoring port.
Monitor A functional datapath element which increments an octet Monitor A functional datapath element which updates an octet
and a packet counter for every packet which passes and a packet counter for every packet which passes
through it. Used for collecting statistics. through it. Used for collecting statistics.
Multiplexer A functional datapath element that merges multiple Multiplexer A functional datapath element that merges multiple
(Mux) traffic streams (datapaths) into a single traffic (Mux) traffic streams (datapaths) into a single traffic
stream (datapath). stream (datapath).
Non-work A property of a scheduling algorithm such that it does Non-work A property of a scheduling algorithm such that it does
conserving not necessarily service a packet if available at every conserving not necessarily service a packet if available at every
transmission opportunity. transmission opportunity.
skipping to change at page 10, line ? skipping to change at page 10, line ?
priority of the queues, or on a weighted fair bandwidth priority of the queues, or on a weighted fair bandwidth
sharing policy, or some other policy. A scheduling sharing policy, or some other policy. A scheduling
algorithm may be either work-conserving or non-work- algorithm may be either work-conserving or non-work-
conserving. conserving.
Shaping The process of delaying packets within a traffic stream Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined traffic profile. to cause it to conform to some defined traffic profile.
Shaping can be implemented using a queue serviced by a Shaping can be implemented using a queue serviced by a
non-work conserving scheduling algorithm. non-work conserving scheduling algorithm.
Traffic A logical datapath element consisting of a number of Traffic A logical datapath entity consisting of a number of
Conditioning other functional datapath elements interconnected in Conditioning other functional datapath entities interconnected in
Block (TCB) such a way as to perform a specific set of traffic Block (TCB) such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream. conditioning functions on an incoming traffic stream.
A TCB can be thought of as a "black box" with a single
input and output.
Bernet, et. al. Expires: April 2000 [page 5] Bernet, et. al. Expires: September 2000 [page 5]
A TCB can be thought of as an entity with at least one
input and output 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 services a packet if available at every transmission conserving services a packet if available at every transmission
opportunity. opportunity.
3. Conceptual Model 3. Conceptual Model
In this section we introduce a block diagram of a Diffserv router and In this section we introduce a block diagram of a Diffserv router and
describe the various components illustrated. Note that a Diffserv describe the various components illustrated. Note that a Diffserv
core router is assumed to include only a subset of these components: core router is assumed to include only a subset of these components:
the model we present here is intended to cover the case of both the model we present here is intended to cover the case of both
skipping to change at page 10, line ? skipping to change at page 10, line ?
document is to show how a model of a Diffserv device can be built document is to show how a model of a Diffserv device can be built
using these component blocks. This model is in the form of a using these component blocks. This model is in the form of a
connected directed acyclic graph (DAG) of functional datapath connected directed acyclic graph (DAG) of functional datapath
elements that describes the traffic conditioning and queueing elements that describes the traffic conditioning and queueing
behaviors that any particular packet will experience when forwarded behaviors that any particular packet will experience when forwarded
to the Diffserv router. to the Diffserv router.
The following diagram illustrates the major functional blocks of a The following diagram illustrates the major functional blocks of a
Diffserv router: Diffserv router:
Bernet, et. al. Expires: April 2000 [page 6] Bernet, et. al. Expires: September 2000 [page 6]
+---------------+ +---------------+
| Diffserv | | Diffserv |
Mgmt | configuration | Mgmt | configuration |
<----+-->| & management |------------------+ <----+-->| & management |------------------+
SNMP,| | interface | | SNMP,| | interface | |
COPS | +---------------+ | COPS | +---------------+ |
etc. | | | etc. | | |
| | | | | |
| v v | v v
| +-------------+ +---------+ +-------------+ | +-------------+ +---------+ +-------------+
data | | ingress i/f | | | | egress i/f | data | | ingress i/f | | | | egress i/f |
-------->| class., |-->| routing |-->| class., |----> -------->| class., |-->| routing |-->| class., |---->
| | TC, | | core | | TC, | | | TC, | | core | | TC, |
| | queueing | | | | queueing | | | queueing | | | | queueing |
| +-------------+ +---------+ +-------------+ | +-------------+ +---------+ +-------------+
| ^ ^ | ^ ^
| | | | | |
| | | | | |
| +------------+ | | +------------+ |
+-->| RSVP | | +-->| QOS agent | |
-------->| (optional) |---------------------+ -------->| (optional) |---------------------+
RSVP +------------+ QOS | (e.g. RSVP)|
cntl cntl +------------+
msgs msgs
Figure 1: Diffserv Router Major Functional Blocks Figure 1: Diffserv Router Major Functional Blocks
3.1.1 Datapath 3.1.1 Datapath
An ingress interface, routing core, and egress interface are An ingress interface, routing core, and egress interface are
illustrated at the center of the diagram. In actual router illustrated at the center of the diagram. In actual router
implementations, there may be an arbitrary number of ingress and implementations, there may be an arbitrary number of ingress and
egress interfaces interconnected by the routing core. The routing egress interfaces interconnected by the routing core. The routing
skipping to change at page 10, line ? skipping to change at page 10, line ?
routing core should be thought of as an infinite bandwidth, zero- routing core should be thought of as an infinite bandwidth, zero-
delay backplane connecting ingress and egress interfaces. delay backplane connecting ingress and egress interfaces.
The components of interest on the ingress/egress interfaces are the The components of interest on the ingress/egress interfaces are the
traffic classifiers, traffic conditioning (TC) components, and the traffic classifiers, traffic conditioning (TC) components, and the
queueing components that support Diffserv traffic conditioning and queueing components that support Diffserv traffic conditioning and
per-hop behaviors [DSARCH]. These are the fundamental components per-hop behaviors [DSARCH]. These are the fundamental components
comprising a Diffserv router and will be the focal point of our comprising a Diffserv router and will be the focal point of our
conceptual model. conceptual model.
Bernet, et. al. Expires: April 2000 [page 7] Bernet, et. al. Expires: September 2000 [page 7]
3.1.2 Configuration and Management Interface 3.1.2 Configuration and Management Interface
Diffserv operating parameters are monitored and provisioned through Diffserv operating parameters are monitored and provisioned through
this interface. Monitored parameters include statistics regarding this interface. Monitored parameters include statistics regarding
traffic carried at various Diffserv service levels. These statistics traffic carried at various Diffserv service levels. These statistics
may be important for accounting purposes and/or for tracking may be important for accounting purposes and/or for tracking
compliance to traffic conditioning specifications (TCSs) [DSTERMS] compliance to traffic conditioning specifications (TCSs) [DSTERMS]
negotiated with customers. Provisioned parameters are primarily negotiated with customers. Provisioned parameters are primarily
classification rules, TC and PHB configuration parameters. The classification rules, TC and PHB configuration parameters. The
network administrator interacts with the Diffserv configuration and network administrator interacts with the Diffserv configuration and
management interface via one or more management protocols, such as management interface via one or more management protocols, such as
SNMP or COPS, or through other router configuration tools such as SNMP or COPS, or through other router configuration tools such as
serial terminal or telnet consoles. serial terminal or telnet consoles.
Specific policy objectives are presumed to be installed by or
retrieved from policy management mechanisms. However, diffserv
routers are subject to implementation decisions which form a meta-
policy that scopes the kinds of policies which can be created.
3.1.3 Optional RSVP Module 3.1.3 Optional RSVP Module
Diffserv routers may snoop or participate in either per-microflow or Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E]. The example per-flow-aggregate signaling of QoS requirements [E2E]. The example
discussed here uses the RSVP protocol. Snooping of RSVP messages may discussed here uses the RSVP protocol. Snooping of RSVP messages may
be used, for example, to learn how to classify traffic without be used, for example, to learn how to classify traffic without
actually participating as a RSVP protocol peer. Diffserv routers may actually participating as a RSVP protocol peer. Diffserv routers may
reject or admit RSVP reservation requests to provide a means of reject or admit RSVP reservation requests to provide a means of
admission control to Diffserv-based services or they may use these admission control to Diffserv-based services or they may use these
requests to trigger provisioning changes for a flow-aggregation in requests to trigger provisioning changes for a flow-aggregation in
skipping to change at page 10, line ? skipping to change at page 10, line ?
data plane of such a Diffserv router can still act purely on Diffserv data plane of such a Diffserv router can still act purely on Diffserv
DSCPs and PHBs in handling data traffic. DSCPs and PHBs in handling data traffic.
3.2 Hierarchical Model of Diffserv Components 3.2 Hierarchical Model of Diffserv Components
We focus on the Diffserv specific functional components of the We focus on the Diffserv specific functional components of the
router: the classification, traffic conditioning, and queueing router: the classification, traffic conditioning, and queueing
functionality. The diagram below is based on the larger block functionality. The diagram below is based on the larger block
diagram shown above: diagram shown above:
Bernet, et. al. Expires: April 2000 [page 8] Bernet, et. al. Expires: September 2000 [page 8]
Interface A Interface B Interface A Interface B
+-------------+ +---------+ +-------------+ +-------------+ +---------+ +-------------+
| ingress i/f | | | | egress i/f | | ingress i/f | | | | egress i/f |
| class., | | | | class., | | class., | | | | class., |
--->| meter, |---->| |---->| meter, |---> --->| meter, |---->| |---->| meter, |--->
| action, | | | | action, | | action, | | | | action, |
| queueing | | | | queueing | | queueing | | | | queueing |
+-------------+ | routing | +-------------+ +-------------+ | routing | +-------------+
| core | | core |
+-------------+ | | +-------------+ +-------------+ | | +-------------+
skipping to change at page 10, line ? skipping to change at page 10, line ?
selection. selection.
From a configuration and management perspective, the following From a configuration and management perspective, the following
hierarchy exists: hierarchy exists:
At the top level, the network administrator manages interfaces. Each At the top level, the network administrator manages interfaces. Each
interface consists of an ingress component and an egress component. interface consists of an ingress component and an egress component.
Each component may contain classifier, action, meter, and queueing Each component may contain classifier, action, meter, and queueing
elements. elements.
Bernet, et. al. Expires: April 2000 [page 9] Bernet, et. al. Expires: September 2000 [page 9]
At the next level, the network administrator manages groups of At the next level, the network administrator manages groups of
functional elements interconnected in a DAG. These elements are functional elements interconnected in a DAG. These elements are
organized in self-contained Traffic Conditioning Blocks (TCBs) which organized in self-contained Traffic Conditioning Blocks (TCBs) which
are used to implement some desired network policy (see Sec. 8). One are used to implement some desired network policy (see Sec. 8). One
or more TCBs may be instantiated on each ingress or egress component, or more TCBs may be instantiated on each ingress or egress component,
may be connected in series, and/or may be connected in a may be connected in series, and/or may be connected in a
parallel configuration on the multiple outputs of a classifier. parallel configuration on the multiple outputs of a classifier.
We define the TCB to optionally include classification and queueing We define the TCB to optionally include classification and queueing
elements so as to allow for rich functionality. A TCB can be thought elements so as to allow for rich functionality. A TCB can be thought
of as a "black box" with a single input and a single output (on the of as a "black box" with a single input and a single output (on the
skipping to change at page 12, line 5 skipping to change at page 11, line 54
specify a different condition for each key component, as illustrated specify a different condition for each key component, as illustrated
in the example below for a IPv4/TCP classifier: in the example below for a IPv4/TCP classifier:
Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort
------ ------------- ------------- ----------- ------------ ------ ------------- ------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003 Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address In this example, the fourth octet of the destination IPv4 address
and the source TCP port are wildcard or "don't cares". and the source TCP port are wildcard or "don't cares".
MF filtering of fragmented packets is impossible. MTU size discovery
is therefore prerequisite for proper operation of a diffserv network.
4.1.2 Overlapping Filters 4.1.2 Overlapping Filters
Note that it is easy to define sets of overlapping filters in a Note that it is easy to define sets of overlapping filters in a
classifier. For example: classifier. For example:
Filter5: Filter6: Filter5: Filter6:
Type: Masked-DSCP Type: Masked-DSCP Type: Masked-DSCP Type: Masked-DSCP
Value: 111000 Value: 000111 (binary) Value: 111000 Value: 000111 (binary)
Mask: 111000 Mask: 000111 (binary) Mask: 111000 Mask: 000111 (binary)
skipping to change at page 15, line 19 skipping to change at page 15, line 19
Classification may be performed based on implicit information Classification may be performed based on implicit information
associated with a packet (e.g. the incoming channel number on a associated with a packet (e.g. the incoming channel number on a
channelized interface) or on information derived from a different channelized interface) or on information derived from a different
non-Diffserv classification operation (e.g. the outgoing interface non-Diffserv classification operation (e.g. the outgoing interface
determined by the route lookup operation). Other vendor-specific determined by the route lookup operation). Other vendor-specific
filter formats are possible. We do not discuss these further here. filter formats are possible. We do not discuss these further here.
4.3 MPLS 4.3 MPLS
It is possible for an MPLS label-switched router (LSR) to function as It is possible for an MPLS label-switched router (LSR) to function as
a Diffserv router [MPLSDS]. In this case the IP header is not a Diffserv router [MPLSDS]. The interaction between MPLS and Diffserv
visible for inspection and all header classification must be is not discussed further in this document.
performed on the MPLS label, and in the event of shim encapsulation,
on the 3-bit EXP field in addition. In general a MPLS classification
filter may specify either wildcard- or exact-match conditions for
either field (but not both wildcard at once). The distinction to be
drawn here is that MPLS labels are dynamically established and torn
down. An EXP-only classifier may be statically configured but a
label or label + EXP classifier must be established dynamically along
with the LSP. In all other respects (except marking) the labeled
packet can be treated identically to an unlabeled packet.
5. Meters 5. Meters
5.1 Definition 5.1 Definition
Metering is the function of monitoring the arrival times of packets Metering is the function of monitoring the arrival times of packets
of a traffic stream and determining the level of conformance of each of a traffic stream and determining the level of conformance of each
packet to a pre-established traffic profile. Diffserv network packet to a pre-established traffic profile. Diffserv network
providers may choose to offer services to customers based on a providers may choose to offer services to customers based on a
temporal (i.e., rate) profile within which the customer submits temporal (i.e., rate) profile within which the customer submits
skipping to change at page 19, line 21 skipping to change at page 19, line 21
6. Action Elements 6. Action Elements
Classifiers and meters are fan-out elements which are generally used Classifiers and meters are fan-out elements which are generally used
to determine the appropriate action to apply to a packet. The set of to determine the appropriate action to apply to a packet. The set of
possible actions include: possible actions include:
1) Marking 1) Marking
2) Dropping 2) Dropping
2) Shaping 2) Shaping
3) Mirroring 3) Replicating
4) Monitoring 4) Monitoring
The corresponding action elements are described in the following The corresponding action elements are described in the following
paragraphs. paragraphs.
Policing is a general term for the process of preventing a traffic Policing is a general term for the process of preventing a traffic
stream from seizing more than its share of resources from a Diffserv stream from seizing more than its share of resources from a Diffserv
network. Each of the first three actions described above may be used network. Each of the first three actions described above may be used
to police traffic. Markers do so by re-marking non-conforming to police traffic. Markers do so by re-marking non-conforming
packets to a DSCP value that is entitled to fewer network resources. packets to a DSCP value that is entitled to fewer network resources.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
Shapers are used to shape traffic streams to a certain temporal Shapers are used to shape traffic streams to a certain temporal
profile. For example, a shaper can be used to smooth traffic profile. For example, a shaper can be used to smooth traffic
arriving in bursts. In [DSARCH] a shaper is described as a arriving in bursts. In [DSARCH] a shaper is described as a
queueing element controlled by a meter which defines its temporal queueing element controlled by a meter which defines its temporal
profile. This model of a shaper differs substantially from typical profile. This model of a shaper differs substantially from typical
shaper implementations. Further, with the inclusion of queueing shaper implementations. Further, with the inclusion of queueing
elements in the model a separate shaping element becomes confusing. elements in the model a separate shaping element becomes confusing.
Therefore, the function of a shaper is embedded in a queue and is Therefore, the function of a shaper is embedded in a queue and is
covered in Sec. 7. covered in Sec. 7.
6.4 Mirroring Element 6.4 Replicating Element
It is occasionally desirable to mirror data traffic on one or more It is occasionally desirable to replicate traffic on one or more
additional interfaces for data collection purposes. A mirroring additional interfaces for data collection purposes. A replicating
element is a 1:N (fan-out) element. However, each and every packet element is a 1:N (fan-out) element. However, each and every packet
follows each output path simultaneously. A mirroring element is follows each output path simultaneously. A replicating element is
parameterized by the number of outputs it supports. parameterized by the number of outputs it supports.
6.5 Mux 6.5 Mux
It is occasionally necessary to multiplex traffic streams into a 1:1 It is occasionally necessary to multiplex traffic streams into a 1:1
or 1:N action element or classifier. A M:1 (fan-in) mux is a simple or 1:N action element or classifier. A M:1 (fan-in) mux is a simple
logical device for merging traffic streams. It is parameterized by logical device for merging traffic streams. It is parameterized by
its number of incoming ports. its number of incoming ports.
6.6 Enqueueing Element 6.6 Monitor
Queueing elements (discussed in Sec. 7) require an action element to
execute the appropriate buffer management algorithm and store or
discard a packet. This is performed by an enqueueing element, which
is an M:1 (fan-in) element. An enqueueing element executes the
buffer management algorithm appropriate for the queue it is feeding.
This may include a deterministic discard behavior if the queue size
exceeds a threshold, it may include a random discard behavior that
is a function of the average queue size [AF-PHB], or it may include
a more complex policy which is a function of the state of several
queues in a queue set (see Sec. 7). The particular parameters to
apply to a packet may depend on the particular input port the element
receives it on; this allows packets which are classified into
different colors to follow different datapaths and be processed
appropriately at the enqueueing element.
The configuration parameters for an enqueueing element will depend on
the details of the algorithm it is executing. For an algorithm such
as the one recommended in [AF-PHB], the parameters would include
separate RED min_th, max_th, and max_p parameters per-element input
port.
An enqueueing element must maintain octet/packet counters for both
the forwarded and discarded packets received at each element input
port. Counters should be provided to distinguish between losses due
to the normal operation of the algorithm (e.g., random drop) and
those due to resource exhaustion (e.g., tail drop) [DSMIB].
6.7 Monitor
One passive action is to account for the fact that a data packet was One passive action is to account for the fact that a data packet was
processed. The statistics that result might be used later for processed. The statistics that result might be used later for
customer billing, service verification, or network engineering customer billing, service verification, or network engineering
purposes. Monitors are 1:1 functional elements which increment an purposes. Monitors are 1:1 functional elements which update an
octet counter by L and a packet counter by 1 every time a L-byte octet counter by L and a packet counter by 1 every time a L-byte
sized packet passes through it. Monitors can also be used to count sized packet passes through it. Monitors can also be used to count
packets on the verge of being dropped by a dropper. packets on the verge of being dropped by a dropper.
6.8 Null Action 6.7 Null Action
A null action has one input and one output. The element performs no A null action has one input and one output. The element performs no
action on the packet. Such an element is useful to define in the action on the packet. Such an element is useful to define in the
event that the configuration or management interface does not have event that the configuration or management interface does not have
the flexibility to omit an action element in a datapath segment. the flexibility to omit an action element in a datapath segment.
7. Queues 7. Queueing block
7.1 Queue Sets and Scheduling
Queues are used to store packets prior to transmission or prior to The queueing block modulates the transmission of packets belonging to
forwarding to the next functional element. Packets are usually the different traffic streams and determines their ordering, possibly
storing them temporarily or discarding them. Packets are usually
stored either because there is a resource constraint (e.g., available stored either because there is a resource constraint (e.g., available
bandwidth) which prevents immediate forwarding, or because the queue bandwidth) which prevents immediate forwarding, or because the
is being used to alter the temporal properties of a traffic stream queueing block is being used to alter the temporal properties of a
(shaping). Queues may be organized into queue sets, which are traffic stream (i.e., shaping). Packets are discarded either because
serviced using a common scheduling algorithm (although each queue may of buffering limitations, because a buffer threshold is exceeded
be individually parameterized). Queue sets can be treated as (including when shaping is performed), as a feedback control signal
functional elements and organized hierarchically in queue supersets, to reactive control protocols such as TCP, because a meter exceeds a
using an n-th order scheduling algorithm. Such a queue set may be configured rate (i.e., policing).
used to implement the entire range of PHBs on an egress interface,
for instance.
Possible queue scheduling algorithms fall into a number of The queueing block in this model is a logical abstraction of a
categories, including strict priority, weighted fair bandwidth queueing system, which is used to configure PHB-related parameters.
sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, etc. There is no conformance to this model. The model can be used to
Scheduling algorithms can be further distinguished by whether they represent a broad variety of possible implementations. However, it
are work conserving or non-work conserving. A work conserving need not necessarily map one-to-one with physical queueing systems in
algorithm will always transmit an available packet at every a specific router implementation. Implementors should map the
transmission opportunity, while a non-work conserving algorithm will configurable parameters of the implementation's queueing systems to
not. Non-work conserving schedulers can be used to shape traffic these queueing block parameters as appropriate to achieve equivalent
streams by delaying packets that would be deemed non-conforming by behaviors.
some traffic profile. The packet is delayed until such time that it
would conform to a meter using the same profile.
[DSARCH] defines PHBs without specifying required queueing 7.1 Model
algorithms. However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
configuration parameters which strongly suggest the sort of queue Queuing is a function a which lends itself to innovation. It must be
scheduling algorithm needed to implement them. We have selected a modelled to allow a broad range of possible implementations to be
minimal set of queue parameters to enable realization of these per- represented using common structures and parameters. This model uses
hop behaviors. These include a minimum service rate and a strict functional decomposition as a tool to permit the needed lattitude.
service priority along with an optional maximum service rate profile
(depending on whether the queue is meant to be non-work conserving). Queueing sytems, such as the queueing block defined in this model,
The minimum service rate allows throughput guarantees for each queue perform three distinct, but related, functions: they store packets,
they modulate the departure of packets belonging to various traffic
streams and they selectively discard packets. This model decomposes
the queueing block into the component elements that perform each of
these functions. These elements which may be connected together
either dynamically or statically to construct queueing blocks. A
queuing block is thus composed of of one or more FIFO, one or more
scheduler, and one or more discarder. See figure TBA for an example
of a queueing block.
Note that the term FIFO is overloaded (i.e., has more than one
meaning). In common usage it is taken to mean, among other things, a
data structure that permits items to be removed only in the order in
which they were inserted, and a service discipline which is non-
reordering.
7.1.1 FIFO
A FIFO element is a data structure which at any time may contain zero
or more packets. It may have one or more threshold associated with
it. A FIFO has one or more inputs and exactly one output. It must
support an enqueue operation to add a packet to the tail of the
queue, and a dequeue operation to remove a packet from the head of
the queue. Packets must be dequeued in the order in which they were
enqueued. A FIFO has a depth, which indicates the number of packets
that it contains at a particular time; this is a traffic dependent
variable and not used to configure a FIFO.
Typically, the FIFO element of this model will be implemented as a
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 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
buffer. Buffers are allocated from one or more free buffer pool. If
there are multiple instances of a FIFO, their packet buffers may or
may not be allocated out of the same free buffer pool. Free buffer
pools may also have one or more threshold associated with them, which
may affect discarding and/or scheduling. Otherwise, buffering
mechanisms are implementation specific and not part of this model.
A FIFO might be represented using the following parameters:
FIFO1:
Type: FIFO
Input: QueuingBlock.input1
Output: Discarder2
Threshold1: 3 packets
Another FIFO may be represented using the following parameters:
FIFO2:
Type: FIFO
Input: Discarder1
Output: Scheduler1
Threshold1: 3 packets
Threshold2: 1000 octets
Threshold3: 10 packets
Threshold4: 2000 octets
7.1.2 Scheduler
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 or more input and exactly one output. Each input has an
upstream element to which it is connected, and a set of parameters
that affects the scheduling of packets received at that input.
The service discipline (also known as a scheduling algorithm) is an
algorithm which may take as its inputs static parameters (such as
relative priority, and/or absolute token bucket parameters for
maximum or minimum rates) associated with each of the scheduler's
inputs; parameters (such as packet length or DSCP) associated with
the packet present at its input; absolute time and/or local state.
Possible service disciplines fall into a number of categories,
including (but not limited to) first come, first served (FCFS),
strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR,
etc.), rate-limited strict priority, and rate-based. Service
disciplines can be further distinguished by whether they are work
conserving or non-work conserving. A work conserving service
discipline transmits a packet at every transmission opportunity if
one is available. A non-work conserving service discipline transmits
packets no sooner than a scheduled departure time, even if it means
leaving packets in a FIFO while the link is idle. Non-work
conserving schedulers can be used to shape traffic streams by
delaying packets that would be deemed non-conforming by some traffic
profile. The packet is delayed until such time as it would conform
to a meter using the same profile.
[DSARCH] defines PHBs without specifying required scheduling
algorithms. However, PHBs such as the class selctors [DSFIELD],
EF [EF-PHB] and AF [AF-PHB] have descriptions or
configuration parameters which strongly suggest the sort of
scheduling discipline needed to implement them. This memo specifies
a minimal set of queue parameters to enable realization of these per-
hop behaviors. It does not attempt to specify an all-embracing
set of parameters to cover all possible implementation models.
The mimimum set includes a minimum service rate profile, a
service priority and a maximum service rate profile (the latter is
for use only with a non-work conserving service discipline). The
minimum service rate allows rate guarantees for each traffic stream
as required by EF and AF without specifying the details of how excess as required by EF and AF without specifying the details of how excess
bandwidth between these queues is shared (additional parameters to bandwidth between these traffic streams is shared. Additional
control this behavior should be made available, but are dependent on parameters to control this behavior should be made available, but are
the particular scheduling algorithm implemented). The strict service dependent on the particular scheduling algorithm implemented. The
priority is useful for implementing EF on some links (assuming that service priority is used only after the MinRateProfiles of all inputs
the aggregate EF rate has been appropriately bounded to avoid have been satisfied in order to decide how to allocate any remaining
starvation). Setting the service priority of each queue in a queue bandwidth. It could be used for the class selectors. For the EF PHB,
set to the same value enables the scheduler to satisfy the minimum using a strict priority scheduling algorithm on some links, and assuming
service rate for each queue. Queue sets can be serviced like that the aggregate EF rate has been appropriately bounded to avoid
individual queues in a queue superset using the same scheduling starvation, for this scheduler the MinRateProfile would be reported
parameters. as zero and the MaxRateProfile reported as line rate. Setting the
service priority of each input to the scheduler to the same value
enables the scheduler to satisfy the minimum service rates for each
input, so long as the sum of all minimum service rates is less than
or equal to the line rate.
It should be noted that the queues in this model are logical A non-work conserving scheduler might be represented using the
abstractions used to configure PHB-related parameters. They are not following parameters:
expected to map one-to-one with physical queues in a specific router
implementation. An implementor should map the configurable
parameters of the physical queues to these queue parameters as
appropriate to achieve equivalent behaviors.
Other queue parameters such as maximum capacity are assumed to be Scheduler1:
mapped to the buffer management algorithm used by the enqueueing Type: Scheduler
element feeding the queue.
A queue set might be represented using the following parameters: Input1: Discarder1
MaxRateProfile: Profile1
MinRateProfile: Profile2
Priority: None
QueueSet1: Input2: Discarder1
Type: QueueSet MaxRateProfile: Profile3
MaxProfile: WorkConserving MinRateProfile: Profile4
MinGuarRate: 20 MBps Priority: None
Interface: ifIndex
QueueA:
Type: Queue
QueueSet: QueueSet1
MaxProfile: Profile1
MinGuarRate: 2 MBps
Priority: 3
QueueB: A work conserving scheduler might be represented using the
Type: Queue following parameters:
QueueSet: QueueSet1
MaxProfile: WorkConserving Scheduler2:
MinGuarRate: 8 MBps Type: Scheduler
Input1: Scheduler1,
MaxRateProfile: WorkConserving
MinRateProfile: Profile5
Priority: 1
Input2: FIFO2
MaxRateProfile: WorkConserving
MinRateProfile: Profile6
Priority: 2
Input3: FIFO3
MaxRateProfile: WorkConserving
MinRateProfile: None
Priority: 3 Priority: 3
7.2 Shaping 7.1.3 Discarder
Shapers are often used to pre-condition traffic such that packets A discarder is an element which selectively discards packets that
are deemed conforming by subsequent meters, e.g., in downstream arrive at its input, based on a discarding discipline. It has one
Diffserv nodes. Shapers may also be used to isolate certain traffic input and one output. In this model (but not necessarily in a real
streams from the effects of other traffic streams of the same BA. implementation), a packet enters the discarder at the input, and
either its buffer is returned to a free buffer pool or it exits the
discarder at the output.
A shaper action element is implemented in this model by using a non- Alternatively, a discarder may invoke operations on a FIFO which
work conserving queue. Shapers operate by delaying packets that selectively remove packets, then return those packets to the free
would be deemed non-conforming by a meter configured to the shaper's buffer pool, based on a discarding discipline. In this case, the
maximum service rate profile. The packet is delayed until such discarder's operation is modelled as a side-effect on the FIFO upon
time that it would become conforming. which it operates, rather than as having a discrete input and output.
Profile definitions are identical in format to those described for A discarder has a trigger that causes the discarder to make a
meters. The use of a meter algorithm to control shaping is further decision whether or not to drop one (or possibly more than one)
discussed in Appendix A. Average, EWMA, and TB profiles are all packet. The trigger may internal (i.e., the arrival of a packet at
feasible for shaping. Because a shaper is implemented as a queue it the input to the discarder), or it may be external (i.e., resulting
can also utilize a variety of buffer management algorithms from one or more state change at another element, such as a FIFO
(implemented in a enqueueing element). depth exceeding a threshold or a scheduling event). 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).
A shaping queue might be represented using the following parameters: The discarding discipline is an algorithm which makes a decision to
forward or discard a packet. It takes as its parameters some set of
dynamic parameters (e.g., averaged or instantaneous FIFO depth) and
some set of static parameters (e.g. thresholds) and possibly
parameters associated with the packet (e.g. its PHB, as determined by
a classifier). It may also have internal state. RED, RIO, and drop-
on-threhold are examples of a discarding discipline. Tail dropping
and head dropping are effected by the location of the discarder
relative to the FIFO.
QueueA: Note that although a discarder may need to examine the DSCP or
Type: Queue possibly other fields in a packet, it may not modify them (i.e.,
QueueSet: QueueSet1 it is not a marker).
MaxProfile: Profile1
MinGuarRate: 2 MBps
Priority: 3
Profile1: A discarder might be represented using the following parameters:
Type: SimpleTokenBucket Discarder1:
AverageRate: 3 MBps Type: Discarder
BurstSize: 8 KB Trigger: Internal
Input: QueuingBlock.input2
Output: FIFO1
Discipline: RIO
Parameters:
In-MinTh: FIFO1.Threshold1
In-MaxTh: FIFO1.Threshold2
Out-Minth: FIFO1.Threshold3
Out-Maxth: FIFO1.Threshold4
InClassification: AFx1_PHB
OutClassifcation: AFx2_PHB
W_q .002
Max_p .01
Another discarder might be represented using the following parameters:
Discarder2:
Type: Discarder
Trigger:
Input: FIFO2
Output: Scheduler1.input1
Discipline: Drop-on-threshold
Parameters:
Threshold FIFO2.Threshold1
Yet another discarder (not part of the example) might be represented
with the following parameters:
Discarder3:
Type: Discarder
Operate_on FIFO3
Trigger: FIFO3.depth > 100 packets
Discipline: Drop-all-out-packets
Parameters:
Out-DSCP: AFx2_recommended_DSCP | AFx3_recommended_DSCP
7.1.4 Constructing queueing blocks from the elements
A queuing block is constructed by concatenation of these elements
so as to meet the meta-policy objectives of the implementation,
subject to the grammar rules specified in this section.
Elements of the same type may appear more than once in a queueing
block, either in parallel or in series. Typically, a queuing block
will have relatively many elements in parallel and few in series.
Iteration and recursion are not supported constructs in this
grammar. A queuing block must have at least one FIFO, at least
one discarder, and at least one scheduler. The following
connections are allowed:
The input of a FIFO may be the input of the queueing block, or it
may be connected to the output of a discarder or to an output of
a scheduler.
Each input of a scheduler may be connected to the output of a
FIFO, to the output of a discarder or to the output of another
scheduler.
The input of a discarder which has a discrete input and output
may be the input of the queue, or it may be connected to the
output of a FIFO (e.g., head dropping).
The output of the queueing block may be the output of a FIFO
element, a discarding element or a scheduling element.
Note, in particular, that schedulers may operate in series such
that a packet at the head of a FIFO feeding the concatenated
schedulers is serviced only after all of the scheduling criteria
are met. For example, a FIFO 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 FIFO and/or a discarder between the two schedulers.
7.2 Shaping
Traffic shaping is often used to condition traffic such that packets
will be deemed conforming by subsequent meters, e.g., in downstream
Diffserv nodes. Shaping may also be used to isolate certain traffic
streams from the effects of other traffic streams of the same BA.
A shaper is realized in this model by using a non-work conserving
scheduler. Some implementations may elect to have queues whose sole
purpose is shaping, while others may integrate the shaping function
with other buffering, discarding and scheduling associated with access
to a resource. Shapers operate by delaying the departure of packets
that would be deemed non-conforming by a meter configured to the shaper's
maximum service rate profile. The packet is scheduled to depart no
sooner than such time that it would become conforming.
8. Traffic Conditioning Blocks (TCBs) 8. Traffic Conditioning Blocks (TCBs)
The classifiers, meters, action elements, and queueing elements The classifiers, meters, action elements, and queueing elements
described above can be combined into traffic conditioning blocks described above can be combined into traffic conditioning blocks
(TCBs). The TCB is an abstraction of a functional element that may (TCBs). The TCB is an abstraction of a functional element that may
be used to facilitate the definition of specific traffic conditioning be used to facilitate the definition of specific traffic conditioning
functionality. functionality.
One of the simplest possible TCBs would consist of the following One of the simplest possible TCBs would consist of the following
skipping to change at page 31, line 12 skipping to change at page 31, line 12
Output A --> Meter10 Output A --> Meter10
Output B --> Meter11 Output B --> Meter11
Meter10: Meter10:
Output A --> PHBQueueA Output A --> PHBQueueA
Output B --> Dropper10 Output B --> Dropper10
Meter11: Meter11:
Output A --> PHBQueueB Output A --> PHBQueueB
Output B --> Dropper11 Output B --> Dropper11
8.4 Cascaded TCBs
Conceptually, nothing prevents more complex scenarios in which one
microflow TCB precedes another (for example, TCBs implementing
separate TCS's for the source and for a set of destinations).
9. Open Issues 9. Open Issues
o There is a difference in interpretation of token bucket behavior o There is a difference in interpretation of token bucket behavior
between this document (Appendix A) and [DSMIB]. Specifically, between this document (Appendix A) and [DSMIB]. Specifically,
[DSMIB] allows a packet to conform if any smaller packet would [DSMIB] allows a packet to conform if any smaller packet would
conform. conform.
o The meter in [SRTCM] cannot be precisely modeled using two o The meter in [SRTCM] cannot be precisely modeled using two
two-parameter token buckets because its two buckets do not two-parameter token buckets because its two buckets do not
accumulate credits independently. We intended to demonstrate how accumulate credits independently. We intended to demonstrate how
skipping to change at page 33, line 36 skipping to change at page 33, line 36
not change since the bucket is already full of tokens. Assume a 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 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, still. Then, as long as B <= BS, the packet conforms to the meter,
and and
T(t') = BS - B. T(t') = BS - B.
Assume an interval v = t - t' elapses before the next packet, of Assume an interval v = t - t' elapses before the next packet, of
size C <= BS, arrives. T(t-) is given by the following equation: size C <= BS, arrives. T(t-) is given by the following equation:
T(t-) = max { BS, T(t') + v*R } T(t-) = min { BS, T(t') + v*R }
(the packet has accumulated v*R tokens over the interval, up to a (the packet has accumulated v*R tokens over the interval, up to a
maximum of BS tokens). maximum of BS tokens).
If T(t-) - C >= 0, the packet conforms and T(t) = T(t-) - C. 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-). 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 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 size C arrives at time t, it will be eligible for transmission at time
te given as follows (we still assume C <= BS): te given as follows (we still assume C <= BS):
skipping to change at page 34, line 23 skipping to change at page 34, line 23
Andrew Smith Andrew Smith
Extreme Networks Extreme Networks
3585 Monroe St. 3585 Monroe St.
Santa Clara, CA 95051 Santa Clara, CA 95051
Phone: +1 408 579 2821 Phone: +1 408 579 2821
E-mail: andrew@extremenetworks.com E-mail: andrew@extremenetworks.com
Steven Blake Steven Blake
Ericsson Ericsson
3000 Aerial Center Parkway, Suite 140 920 Main Campus Drive, Suite 500
Morrisville, NC 27560 Raleigh, NC 27606
Phone: +1 919 468 8466 x232 Phone: +1 919 472 9913
E-mail: slblake@torrentnet.com E-mail: slblake@torrentnet.com
Daniel Grossman
Motorola Inc.
20 Cabot Blvd.
Mansfield, MA 02048
Phone: +1 508 261 5312
E-mail: dan@dma.isg.mot.com
 End of changes. 57 change blocks. 
184 lines changed or deleted 369 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/