Internet Engineering Task Force                                Y. Bernet
Diffserv Working Group                                         Microsoft
INTERNET-DRAFT                                                  A. Smith
Expires: September
Expires November 2000                                   Extreme Networks
draft-ietf-diffserv-model-03.txt                                S. Blake
                                                                Ericsson
                                                             D. Grossman
                                                                Motorola
                A Conceptual Model for Diffserv Routers

                    draft-ietf-diffserv-model-02.txt

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.

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.

This document is a product of the Diffserv working group. IETF's Differentiated Services Working
Group. Comments
   on this draft should be directed addressed to the Diffserv WG's mailing list
   <diffserv@ietf.org>.

   Distribution of this memo is unlimited.

Copyright Notice at
diffserv@ietf.org. The charter for Differentiated Services may be found
at http://www.ietf.org/html.charters/diffserv-charter.html Copyright (C)
The Internet Society (1999). (2000). All Rights Reserved.

Abstract

   DISCLAIMER - for reasons outside our control

Distribution of this version has been
   rushed out with formatting errors and not checked by all authors. memo is unlimited.

Abstract

This draft proposes a conceptual model of Differentiated Services
(Diffserv) routers for use in their management and configuration.  This
model defines the general functional datapath elements (classifiers,
meters, markers, droppers, monitors, replicators, muxes, multiplexors, queues), their
possible configuration parameters, and how they might be interconnected
to realize the range of classification, traffic conditioning, and per-hop 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 representing the configuration
parameters important to Diffserv functionality for a variety of specific
router implementations. It is not intended as a guide to hardware
implementation.

This model should serve serves as a the rationale for the design of a Diffserv an SNMP MIB [DSMIB], as well [DSMIB]
and for various other configuration interfaces (such as
   [PIB]).  Since (e.g.  [DSPIB]) and more detailed
models (e.g. [QOSDEVMOD]): these documents are all evolving simultaneously there
   are discrepancies between their current revisions; this should all be
   resolved in a future revision of based upon and consistent
with this draft.

Table of Contents model.

1.  Introduction .................................................  3
   2.  Glossary  ....................................................  4
   3.  Conceptual Model .............................................  6
     3.1  Elements

Differentiated Services (Diffserv) [DSARCH] is a set of technologies
which allow network service providers to offer different kinds of
network quality-of-service (QoS) to different customers and their
traffic streams. The premise of Diffserv networks is that routers within
the core of the network handle packets in different traffic streams by
forwarding them using different per-hop behaviors (PHBs).  The PHB to be
applied is indicated by a Diffserv Router .............................  6
       3.1.1  Datapath ..............................................  7
       3.1.2  Configuration codepoint (DSCP) in the IP header of
each packet [DSFIELD].  Note that this document uses the terminology
defined in [DSARCH, DSTERMS] and Management Interface ................  8
       3.1.3  Optional RSVP Module ..................................  8
     3.2  Hierarchical Model of Diffserv Components .................  8
   4.  Classifiers .................................................. 10
     4.1  Definition ................................................ 10
       4.1.1  Filters ............................................... 11
       4.1.2  Overlapping Filters ................................... 12
       4.1.3  Filter Groups ......................................... 12
     4.2  Examples .................................................. 12
       4.2.1  Behavior Aggregate (BA) Classifier .................... 12
       4.2.2  Multi-Field (MF) Classifier ........................... 13
       4.2.3  IEEE802 MAC Address Classifier ........................ 13
       4.2.4  Free-form Classifier .................................. 14
       4.2.5  Other Possible Classifiers ............................ 14
     4.3  MPLS ...................................................... 15
   5.  Meters ....................................................... 15
     5.1  Definition ................................................ 15
     5.2  Examples .................................................. 16
       5.2.1  Average Rate Meter .................................... 16
       5.2.2  Exponentially Weighted Moving Average (EWMA) Meter .... 17
       5.2.3  Two-Parameter Token Bucket Meter ...................... 17
       5.2.4  Multi-Stage Token Bucket Meter ........................ 18
       5.2.5  Null Meter ............................................ 19
   6.  Action Elements .............................................. 19*
     6.1  Marker .................................................... 19*
     6.2  Dropper ................................................... 20*
     6.3  Shaper .................................................... 20*
     6.4  Replicating Element ....................................... 20*
     6.5  Multiplexor ............................................... 20*
     6.6  Monitor ................................................... 21*
     6.7  Null Action ............................................... 21*
   7.  Queues ....................................................... 21
     7.1  Queue Sets and Scheduling ................................. 21
     7.2  Shaping ................................................... 23

Bernet, et. al.            Expires: July 2000                  [page  2]
   8.  Traffic Conditioning Blocks (TCBs) ........................... 23
     8.1  An Example TCB ............................................ 24
     8.2  An Example TCB to Support Multiple Customers .............. 27
     8.3  TCBs Supporting Microflow-based Services .................. 28
     8.4  Cascaded TCBs ............................................. 31
   9.  Open Issues .................................................. 31
  10.  Security Considerations ...................................... 31
  11.  Acknowledgments .............................................. 31
  12.  References ................................................... 32
  Appendix A.  Simple Token Bucket Definition ....................... 33

1. Introduction

   Differentiated Services (Diffserv) [DSARCH] is a set of technologies
   which allow network service providers to 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 core of the network handle packets in different traffic
   streams by forwarding them using different per-hop behaviors (PHBs).
   The PHB to be applied is indicated by a Diffserv codepoint (DSCP) in
   the IP header of each packet [DSFIELD].   Note that this document
   uses the terminology defined in [DSARCH, DSTERMS] and in Sec. 2.

   The advantage in Section 2.

The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behavior aggregates (BA) which
are each forwarded using the same PHB at the router, thereby simplifying
the processing and associated storage. In addition, there is no
signaling, other than what is carried in the DSCP of each packet, and no
other related processing that is required in the core of the Diffserv
network since QoS is invoked on a packet-by- packet basis.

The Diffserv architecture enables a variety of possible services which
could be deployed in a network. These services are reflected to
customers at the edges of the Diffserv network in the form of a Service
Level Specification (SLS) [DSTERMS]. The ability to provide these
services depends on the availability of cohesive management and
configuration tools that can be used to provision and monitor a set of
Diffserv routers in a coordinated manner. To facilitate the development
of such configuration and management tools it is helpful to define a
conceptual model of a Diffserv router that abstracts away implementation
details of particular Diffserv routers from the parameters of interest
for configuration and management. The purpose of this draft is to define
such a model.

The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].

This document is not intended in any way to constrain or to dictate the
implementation alternatives of Diffserv routers.  We expect It is expected that
router vendors implementers will demonstrate a great deal of variability in
their implementations. To the extent that vendors implementers are able to model
their

Bernet, et. al.            Expires: September 2000             [page  3] implementations using the abstractions described in this draft,
configuration and management tools will more readily be able to
configure and manage networks incorporating Diffserv routers of
   various implementations.
   In Sec. assorted
origins.

o    Section 3 we start starts by describing the basic high-level functional
     elements of a Diffserv router and then describe the various
   components.  We
     components, then focus focussing on the Diffserv-specific components of
     the router and describe a hierarchical management model for these.

   In Sec. these
     components.

o    Section 4 we describe describes classification elements and in Sec. 5, we
   discuss the elements.

o    Section 5 discusses meter elements.

   In Sec.

o    Section 6 we discuss discusses action elements.  In Sec.

o    Section 7 we discuss discusses the basic queueing elements and their
     functional behaviors (e.g., (e.g. shaping).

   In Sec. 8, we show

o    Section 8 shows how the basic classification, meter, action, action and
     queueing elements can be combined to build modules called Traffic
     Conditioning Blocks (TCBs).

   In Sec.

o    Section 9 we discuss discusses open issues with this document and in Sec.

o    Section 10 we
   discuss discusses security concerns.

   Appendix A discusses token bucket implementation details.

2.  Glossary

   Some of the terms used in this draft are

This memo uses terminology which is defined in [DSARCH] and in
[DSTERMS].  We define a few  Some of them here the terms defined there are defined again only here in
order to provide additional detail.

   Buffer        An algorithm used detail, along with some new terms specific
to determine whether an arriving
   management    packet should be stored in a queue, or discarded.  This
   algorithm     decision is usually a function of the instantaneous or
                 average queue occupancy, but also may be a function of
                 the aggregate queue occupancy in a queue set, or of
                 other parameters. this document.

   Classifier    A functional datapath element which consists of filters
                 which select packets based on the content of packet
                 headers or other packet data, and/or on implicit or
                 derived attributes associated with the packet, and
                 forwards the packet along a particular datapath within
                 the router. A classifier splits a single incoming
                 traffic stream into multiple outgoing ones.

   Enqueueing    The process of executing

   Counter       A functional datapath element which updates a buffer management algorithm
                 to determine whether packet
                 counter and also an arriving octet counter for every
                 packet should be
                 stored in a queue. that passes through it. Used for collecting
                 statistics.

   Filter        A set of (wildcard/prefix/masked/range/exact) wildcard, prefix, masked, range and/or exact
                 match 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
                 each condition is satisfied.

   Replicating   A functional datapath element which makes one or more
   element       copies of a packet and forwards them on distinct
                 datapaths; for example to a monitoring port.

   Monitor       A functional datapath element which updates an octet
                 and a packet counter for every packet which passes
                 through it.  Used for collecting statistics.

   Multiplexer   A functional datapath element that merges multiple
   (Mux)         traffic streams (datapaths) into a single traffic
                 stream (datapath).

   Non-work

   Non-work-     A property of a scheduling algorithm such that it does
   conserving    not necessarily service    services packets no sooner than a packet scheduled departure
                 time, even if available at every
                 transmission opportunity.

   Queue         A storage location for this means leaving packets awaiting transmission or
                 processing by the next functional element in a FIFO
                 while the data-
                 path.  The queues represented in this model are
                 abstract link is idle.

   Queueing      A combination of functional datapath elements
   Block         that may be implemented by multiple
                 physical queues in series and/or in parallel in a
                 specific implementation.  Note that we assume that a
                 queue is serviced such as to preserve modulates the required
                 ordering constraint for each Ordering Aggregate (OA)
                 it queues [DSTERMS].  This can be achieved by a FIFO
                 (first in, first out) service policy or by other means
                 (e.g., multiple FIFOs exclusively servicing particular
                 OAs).

   Queue set     A set transmission of queues which are serviced by packets belonging
                 to a scheduling
                 algorithm traffic streams and which may share a buffer management
                 algorithm. determines their
                 ordering, possibly storing them temporarily or
                 discarding them.

   Scheduling    An algorithm which determines which queue of a queue
   algorithm set
   algorithm     of qyeyes to service next. This may be based on the
                 relative priority of the queues, or on a weighted fair
                 bandwidth sharing policy, policy or some other policy.  A scheduling Such
                 an algorithm may be either work-conserving or non-work-
                 conserving. non-
                 work-conserving.

   Shaping       The process of delaying packets within a traffic stream
                 to cause it to conform to some defined traffic profile.
                 Shaping can be implemented using a queue serviced by a
                 non-work conserving
                 non-work-conserving scheduling algorithm.

   Traffic       A logical datapath entity consisting of a number of
   Conditioning  other functional datapath entities interconnected in
   Block (TCB)   such a way as to perform a specific set of traffic
                 conditioning functions on an incoming traffic stream.

Bernet, et. al.            Expires: September 2000             [page  5]
                 A TCB can be thought of as an entity with at least one
                 input and one output and a set of control parameters.

   Work

   Work-         A property of a scheduling algorithm such that it
   conserving    services    servicess a packet packet, if available one is available, at every
                 transmission
                 opportunity. opportunity."

3.  Conceptual Model

   In this

This section we introduce introduces a block diagram of a Diffserv router and
   describe
describes the various components illustrated. Note that a Diffserv core
router is assumed to include only a subset of these components: the
model we present presented here is intended to cover the case of both Diffserv edge
and core routers.

3.1

3.1.  Elements of a Diffserv Router

The conceptual model we define includes abstract definitions for the following:

   o  The basic traffic classification components.    Traffic Classification elements.

   o  The basic traffic conditioning components.    Metering functions.

   o    Traffic Conditioning (TC) actions of Marking, Absolute Dropping,
        Counting and Multiplexing.

   o    Queueing elements, including capabilities of algorithmic
        dropping.

   o    Certain combinations of traffic classification and classification, traffic
        conditioning
      components.

   o  Queueing components. and queueing elements.

The components and combinations of components described in this document
form building blocks that need to be manageable by Diffserv
configuration and management tools. One of the goals of this document is
to show how a model of a Diffserv device can be built using these
component blocks. This model is in the form of a connected directed
acyclic graph (DAG) of functional datapath elements that describes the
traffic conditioning and queueing behaviors that any particular packet
will experience when forwarded to the Diffserv router.

The following diagram illustrates the major functional blocks of a
Diffserv router:

Bernet, et. al.            Expires: September 2000             [page  6]
               +---------------+
               |  Diffserv     |
        Mgmt   | configuration |
      <----+-->| & management  |------------------+
      SNMP,|   |  interface    |                  |
      COPS |   +---------------+                  |
      etc. |        |                             |
           |        |                             |
           |        v                             v
           |   +-------------+   +---------+   +-------------+
      data |   |

3.1.1.  Datapath

An ingress i/f |   |         |   | egress i/f  |
      -------->|   class.,   |-->| interface, routing |-->|   class.,   |---->
           |   |     TC,     |   | core   |   |     TC,     |
           |   |   queueing  |   |         |   |   queueing  |
           |   +-------------+   +---------+   +-------------+
           |        ^                             ^
           |        |                             |
           |        |                             |
           |   +------------+                     |
           +-->| QOS agent  |                     |
      -------->| (optional) |---------------------+
        QOS    | (e.g. RSVP)|
        cntl   +------------+
        msgs

      Figure 1:  Diffserv Router Major Functional Blocks

3.1.1  Datapath

   An ingress interface, routing core, and egress interface are illustrated
at the center of the diagram. In actual router implementations, there
may be an arbitrary number of ingress and egress interfaces
interconnected by the routing core. The routing core element serves as
an abstraction of a router's normal routing and switching functionality.
The routing core moves packets between interfaces according to policies
outside the scope of Diffserv. The actual queueing delay and packet loss
               +---------------+
               | Diffserv      |
        Mgmt   | configuration |
      <----+-->| & management  |------------------+
      SNMP,|   | interface     |                  |
      COPS |   +---------------+                  |
      etc. |        |                             |
           |        |                             |
           |        v                             v
           |   +-------------+                 +-------------+
           |   | ingress i/f |   +---------+   | egress i/f  |
     --------->|  classify,  |-->| routing |-->|  classify,  |---->
     data  |   |  meter,     |   |  core   |   |  meter      |data out
      in   |   |  action,    |   +---------+   |  action,    |
           |   |  queueing   |                 |  queueing   |
           |   +-------------+                 +-------------+
           |        ^                             ^
           |        |                             |
           |        |                             |
           |   +------------+                     |
           +-->| QOS agent  |                     |
      -------->| (optional) |---------------------+
        QOS    | (e.g. RSVP)|
        cntl   +------------+
        msgs
              Figure 1:  Diffserv Router Major Functional Blocks

behavior of a specific router's switching fabric/backplane is not
modeled by the routing core; these should be modeled using the
functional elements described later. The routing core should be thought
of as an infinite bandwidth, zero- delay backplane connecting ingress
and egress interfaces.

The components of interest on the ingress/egress interfaces are the
traffic classifiers, traffic conditioning (TC) components, and the
queueing components that support Diffserv traffic conditioning and
   per-hop per-
hop behaviors [DSARCH]. These are the fundamental components comprising
a Diffserv router and will be the focal point of our conceptual model.

Bernet, et. al.            Expires: September 2000             [page  7]

3.1.2

3.1.2.  Configuration and Management Interface

Diffserv operating parameters are monitored and provisioned through this
interface. Monitored parameters include statistics regarding traffic
carried at various Diffserv service levels. These statistics may be
important for accounting purposes and/or for tracking compliance to traffic conditioning specifications
Traffic Conditioning Specifications (TCSs) [DSTERMS] negotiated with

customers. Provisioned parameters are primarily classification rules, TC
and PHB configuration parameters. The network administrator interacts
with the Diffserv configuration and management interface via one or more
management protocols, such as SNMP or COPS, or through other router
configuration tools such as serial terminal or telnet consoles.

Specific policy 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

3.1.3.  Optional RSVP QoS Agent 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 [E2E] e.g.  using the
RSVP protocol. Snooping of RSVP messages may be used, for example, to
learn how to classify traffic without actually participating as a RSVP
protocol peer. Diffserv routers may reject or admit RSVP reservation
requests to provide a means of admission control to Diffserv-based
services or they may use these requests to trigger provisioning changes
for a flow-aggregation in the Diffserv network. A flow-aggregation in
this context might be equivalent to a Diffserv BA or it may be more
fine-grained, relying on a MF classifier [DSARCH]. Note that the
conceptual model of such a router starts to look implements the same as a Integrated Services (intserv)
   router
Model as described in [INTSERV], applying the control plane controls to
the data classified and conditioned in the data plane, as desribed in its component makeup
[E2E].

Note that a RSVP QoS Agent component of a Diffserv router, if present, might
be active only in the control plane and not in the data plane. In this
scenario, RSVP is could be used strictly as a signaling protocol.  The merely to signal reservation state without
installing any actual reservations in the data plane of such a the Diffserv router can
router: the data plane could still act purely on Diffserv DSCPs and
provide PHBs in for handling data traffic.

3.2 traffic without the normal per-microflow
handling expected to support some Intserv services.

3.2.  Hierarchical Model of Diffserv Components

   We focus

This document focuses on the Diffserv specific functional Diffserv-specific components of the router: the
classification, traffic conditioning, conditioning and queueing
   functionality.  The diagram below is based on the larger block
   diagram shown above:

Bernet, et. al.            Expires: September 2000             [page  8]
             Interface A                        Interface B
          +-------------+     +---------+     +-------------+
          | ingress i/f |     |         |     | egress i/f  |
          |   class.,   |     |         |     |   class.,   |
      --->|   meter,    |---->|         |---->|   meter,    |--->
          |   action,   |     |         |     |   action,   |
          |   queueing  |     |         |     |   queueing  |
          +-------------+     | routing |     +-------------+
                              |  core   |
          +-------------+     |         |     +-------------+
          | egress i/f  |     |         |     | ingress i/f |
          |   class.,   |     |         |     |   class.,   |
      <---|   meter,    |<----|         |<----|   meter,    |<---
          |   action,   |     |         |     |   action,   |
          |   queueing  |     +---------+     |   queueing  |
          +-------------+                     +-------------+ functions.  Figure 2.  Traffic Conditioning 2
shows a high-level view of ingress and Queueing Elements

   This egress interfaces of a router.
The diagram illustrates two Diffserv router interfaces, each having an
ingress and an egress component. It shows classification, meter,
   action, action
and queueing elements which might be instantiated on each interface's
ingress and egress component. The TC functionality is implemented by a
combination of classification, action, meter, meter and queueing elements.  We show equivalent functional elements on both
   the ingress and egress components of an interface because we expect
   an N-port router

In principle, if one were to display the same Diffserv capabilities as construct a network entirely out of 2-port two-
port routers interconnected (in appropriate places connected by LAN media [DSMIB].  Note
   that LANs or similar media),
then it is not mandatory that each of these functional elements would be
   implemented necessary for each router to perform four QoS control
functions in the datapath on both ingress and egress components; it traffic in each direction:

-    Classify each message according to some set of rules.

-    If necessary, determine whether the data stream the message is dependent on part
     of is within or outside its rate by metering the service requirements on a particular interface on stream.

-    Perform a particular
   router.  Further, we wish set of resulting actions, including applying a drop
     policy appropriate to point out that by showing these elements
   on both ingress the classification and egress components we do not mean to imply that
   they must be implemented in this way queue in question and
     perhaps additionally marking the traffic with a specific router.  For
   example, a router Differentiated
     Services Code Point (DSCP) as defined in [DSCP].

-    Enqueue the traffic for output in the appropriate queue, which may implement all shaping and PHB queueing on
     either shape the
   interface egress component, traffic or may instead implement simply forward it only on with some minimum
     rate or maximum latency.

If the
   ingress component.  Further, network is now built out of N-port routers, the classification needed to map a
   packet to an egress component queue (if present) need not be
   implemented on expected behavior
of the egress component but instead may network should be implemented identical. Therefore, this model must provide
for essentially the same set of functions on the ingress component, with the packet passed through as on the routing
   core with in-band control information to allow for
egress queue
   selection.

   From a configuration and management perspective, the following
   hierarchy exists:

   At port of the top level, router. Some interfaces will be "edge" interfaces and
some will be "interior" to the network administrator manages interfaces.  Each
   interface consists Differentiated Services domain. The one
point of difference between an ingress component and an egress component.
   Each component may contain classifier, action, interface is that

             Interface A                        Interface B
          +-------------+     +---------+     +-------------+
          | ingress i/f |     |         |     | egress i/f  |
          |   classify, |     |         |     |   classify, |
      --->|   meter, and    |---->|         |---->|   meter,    |--->
          |   action,   |     |         |     |   action,   |
          |   queueing
   elements.

Bernet, et. al.            Expires: September 2000             [page  9]
   At the next level,  |     |         |     |   queueing  |
          +-------------+     | routing |     +-------------+
                              |  core   |
          +-------------+     |         |     +-------------+
          | egress i/f  |     |         |     | ingress i/f |
          |   classify, |     |         |     |   classify, |
      <---|   meter,    |<----|         |<----|   meter,    |<---
          |   action,   |     |         |     |   action,   |
          |   queueing  |     +---------+     |   queueing  |
          +-------------+                     +-------------+

      Figure 2. Traffic Conditioning and Queueing Elements

all traffic on an egress interface is queued, while traffic on an
ingress interface will typically be queued only for shaping purposes, if
at all.  Therefore, equivalent functional elements are modelled on both
the network administrator manages groups ingress and egress components of an interface.

Note that it is not mandatory that each of these functional elements interconnected in a DAG.  These elements are
   organized in self-contained Traffic Conditioning Blocks (TCBs) which
   are used to implement some desired network policy (see Sec. 8).  One
   or more TCBs may be instantiated
implemented on each both ingress or and egress component, components; equally, the model
allows that multiple sets of these elements may be connected placed in series, series
and/or may be connected in a parallel configuration at ingress or at egress. The arrangement of elements
is dependent on the multiple outputs of service requirements on a classifier.
   We define the TCB to optionally include classification and queueing particular interface on a
particular router. By modelling these elements so as to allow for rich functionality.  A TCB can on both ingress and
egress components, it is not implied that they must be thought
   of as implemented in
this way in a "black box" with specific router. For example, a single input router may implement all
shaping and a single output (on PHB queueing on the
   main data path).  TCBs can be constructed out of interface egress component or may
instead implement it only on the ingress component. Furthermore, the
classification needed to map a DAG of other TCBs,
   recursively.  We do packet to an egress component queue (if
present) need not assume be implemented on the same TCB configuration egress component but instead may
be implemented on every the ingress component, with the packet passed through
the routing core with in-band control information to allow for egress
queue selection.

>From a device-configuration and management perspective, the following
hierarchy exists:

     At the top level, the network administrator manages interfaces.
     Each interface consists of an ingress component and an egress
     component.  Each component may contain classifier, action, meter
     and queueing elements.

     At the next level, the network administrator manages groups of
     functional elements interconnected in a DAG. These elements are
     organized in self-contained Traffic Conditioning Blocks (TCBs)
     which are used to implement some desired network policy (see
     Section 8). One or more TCBs may be instantiated on each ingress or
     egress component; they may be connected in series and/or in
     parallel configurations on the multiple outputs of a classifier.
     The TCB is defined optionally to include classification and
     queueing elements so as to allow for flexible functionality. A TCB
     can be thought of as a "black box" with one input and one output in
     the data path. Each interface (ingress or egress). egress) may have
     different TCB configurations.

     At the lowest level are individual functional elements, each with
     their own configuration parameters and management counters and
     flags.

4.  Classifiers

4.1

4.1.  Definition

Classification is performed by a classifier element. Classifiers are 1:N
(fan-out) devices: they take a single traffic stream as input and
generate N logically separate traffic streams as output. Classifiers are
parameterized by filters and output streams. Packets from the input
stream are sorted into various output streams by filters which match the
contents of the packet or possibly match other attributes associated
with the packet. Various types of classifiers are described in the
following sections.

We use the following diagram to illustrate a classifier, where the
outputs connect to succeeding functional elements:

      unclassified              classified
      traffic                   traffic
              +------------+
              |            |--> match Filter1 --> output A OutputA
      ------->| classifier |--> match Filter2 --> output B OutputB
              |            |--> no match      --> output C OutputC
              +------------+

      Figure 3. An Example Classifier

Note that we allow a mux multiplexor (see Sec. Section 6.5) before the classifier
to allow input from multiple traffic streams. For example, if multiple
ingress sub-interfaces feed through a single classifier then the
interface number can be considered by the classifier as a packet
attribute and be included in the packet's classification key. This
optimization may be important for scalability in the management plane.
Another possible example of a packet attribute could be an integer representing
the BGP community string associated with the packet's best-matching
route.

The following classifier separates traffic into one of three output
streams based on three filters:

      Filter Matched        Output Stream
      --------------       ---------------
      Filter1                    A
      Filter2                    B
      Filter3 (no match)         C

Where Filters1 and Filter2 are defined to be the following BA filters
([DSARCH], see Sec. Section 4.2.1 ):

      Filter        DSCP
      ------       ------
        1           101010
        2           111111
        3           ****** (wildcard)

4.1.1

4.1.1.  Filters

A filter consists of a set of conditions on the component values of a
packet's classification key (the header values, contents, and attributes
relevant for classification). In the BA classifier example above, the
classification key consists of one packet header field, the DSCP, and
both Filter1 and Filter2 specify exact-match conditions on the value of
the DSCP. Filter3 is a wildcard default filter which matches every
packet, but which is only selected in the event that no other more
specific filter matches.

In general there are a set of possible component conditions including
exact, prefix, range, masked, and wildcard matches. Note that ranges can
be represented (with less efficiency) as a set of prefixes and that
prefix matches are just a special case of both masked and range matches.

In the case of a MF classifier [DSARCH], the classification key consists
of a number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example below
for a IPv4/TCP classifier:

      Filter   IP Src Addr    IP Dest Addr   TCP SrcPort TCP DestPort
      ------   -------------  -------------  -----------  ------------
      Filter4  172.31.8.1/32  172.31.3.X/24       X          5003

In this example, the fourth octet of the destination IPv4 address and
the source TCP port are wildcard or "don't cares".

MF filtering classification of fragmented packets is impossible. MTU size discovery impossible if the filter uses
transport-layer port numbers e.g. TCP port numbers. MTU-discovery is
therefore a prerequisite for proper operation of a diffserv network.

4.1.2 Diffserv network that
uses such classifiers.

4.1.2.  Overlapping Filters

Note that it is easy to define sets of overlapping filters in a
classifier. For example:

      Filter5:              Filter6:
      Type:   Masked-DSCP
      Type:   Masked-DSCP
      Value:  111000
      Mask:   111000

      Filter6:
      Type:   Masked-DSCP
      Value:  000111 (binary)
      Mask:   111000        Mask:   000111 (binary)

A packet containing DSCP = 111111 cannot be uniquely classified by this
pair of filters and so a precedence must be established between Filter5
and Filter6 in order to break the tie. This precedence must be
established either (a) by a manager which knows that the router can
accomplish this particular ordering; e.g., ordering e.g. by means of reported
   capabilities
capabilities, or (b) by the router along with a mechanism to report to a
manager which precedence is being used. These ordering mechanisms must
be supported by the configuration and management protocols although
further discussion of this is outside the scope of this document.

As another example, one might want first to disallow certain
applications from using the network at all, or to classify some
individual traffic streams that are not Diffserv-marked. Traffic that is
not classified by those tests might then be inspected for a DSCP. The
word "then" implies sequence and this must be specified by means of
precedence.

An unambiguous classifier requires that every possible classification
key match at least one filter (including (possibly the wildcard default), default) and that
any ambiguity between overlapping filters be resolved by precedence.

4.1.3  Filter Groups

   Filters may be logically combined.  For example, consider
Therefore, the
   following DestMacAddress filter:

      Filter7:
      Type:        DestMacAddress
      Value:       01-02-03-04-05-06
      Mask:        FF-FF-FF-FF-FF-FF

   Classifier0 could then classifiers on any given interface must be declared as:

      Classifier0:
      Filter1 and Filter7:         output A
      Filter2 "complete" and Filter7:         output B
      Default (wildcard) filter:   output C

4.2
will often include an "everything else" filter as the lowest precedence
element in order for the result of classification to be deterministic.
Note that this completeness is only required of the first classifier
that incoming traffic will meet as it enters an interface - subsequent
classifiers on an interface only need to handle the traffic that it is
known that they will receive.

4.2.  Examples

4.2.1

4.2.1.  Behaviour Aggregate (BA) Classifier

The simplest Diffserv classifier is a behavior aggregate (BA) classifier
[DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a
packet's IP header to determine the logical output stream to which the
packet should be directed. We allow only an exact-match condition on
this field because the assigned DSCP values have no structure, and
therefore no subset of DSCP bits are significant.

The following defines a possible BA filter:

      Filter8:
      Type:   BA
      Value:  111000

4.2.2

4.2.2.  Multi-Field (MF) Classifier

Another type of classifier is a multi-field (MF) classifier [DSARCH].
This classifies packets based on one or more fields in the packet
   header (including
(possibly including the DSCP). A common type of MF classifier is a 6-
tuple classifier that classifies based on six IP header fields from the IP and TCP
or UDP headers (destination address, source address, IP protocol, source
port, destination port, and DSCP). MF classifiers may classify on other
fields such as MAC addresses, VLAN tags, link-layer traffic class fields
or other higher-layer protocol fields.

The following defines a possible MF filter:

      Filter9:
      Type:              IPv4-6-tuple
      IPv4DestAddrValue: 0 0.0.0.0
      IPv4DestAddrMask:  0.0.0.0
      IPv4SrcAddrValue:  172.31.8.0
      IPv4SrcAddrMask:   255.255.255.0
      IPv4DSCP:          28
      IPv4Protocol:      6
      IPv4DestL4PortMin: 0
      IPv4DestL4PortMax: 65535
      IPv4SrcL4PortMin:  20
      IPv4SrcL4PortMax:  20

A similar type of classifier can be defined for IPv6.

4.2.3 IEEE802 MAC Address Classifier

   A MacAddress filter is parameterized by a 6-byte {value, mask} pair
   for either source or destination MAC address.  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:

      Classifier1:
      Filter10:     output A
      Filter11:     output A
      Default:      output B
      Filter10:
      Type:        DestMacAddress
      Value:       01-02-03-04-05-06 (hex)
      Mask:        FF-FF-FF-FF-FF-FF (hex)

      Filter11:
      Type:        SrcMacAddress
      DestValue:   00-E0-2B-00-00-00 (hex)
      DestMask:    FF-FF-FF-00-00-00 (hex)

4.2.4

4.2.3.  Free-form Classifier

A Free-form classifier is made up of a set of user definable arbitrary
filters each made up of {bit-field size, offset (from head of packet),
mask}:

      Classifier2:
      Filter12:    output A    OutputA
      Filter13:     output B    OutputB
      Default:     output C     OutputC

      Filter12:
      Type:        FreeForm
      SizeBits:    3 (bits)
      Offset:      16 (bytes)
      Value:       100 (binary)
      Mask:        101 (binary)

      Filter13:
      Type:        FreeForm
      SizeBits:    12 (bits)
      Offset:      16 (bytes)
      Value:       100100000000 (binary)
      Mask:        111111111111 (binary)

Free-form filters can be combined into filter groups to form very
powerful filters.

4.2.5

4.2.4.  Other Possible Classifiers

      Classifier3:
      Filter14:     output A
      Filter15:     output B
      Default:      output C

      Filter14:
      Type:        IEEEPriority
      Value:       100 (binary)
      Mask:        101 (binary)
      Filter15:
      Type:        IEEEVLAN
      Value:       100100000000 (binary)
      Mask:        111111111111 (binary)

Classification may also be performed based on implicit information
   associated with a packet (e.g. at the incoming channel number on a
   channelized interface)
datalink layer below IP (e.g. VLAN or datalink-layer priority) or
perhaps on information derived from a different
   non-Diffserv classification operation (e.g. the outgoing ingress or egress IP, logical or physical interface
   determined by
identifier.  (e.g. the route lookup operation).  Other vendor-specific
   filter formats are possible.  We do not discuss these further here.

4.3  MPLS

   It is possible for an MPLS label-switched router (LSR) to function as incoming channel number on a Diffserv router [MPLSDS].  The interaction between MPLS channelized
interface).  A classifier that filters based on IEEE 802.1p Priority and Diffserv
   is
on 802.1Q VLAN-ID might be represented as:

      Classifier3:
      Filter14 AND Filter15:  OutputA
      Default:                OutputB

      Filter14:                        -- priority 4 or 5
      Type:        Ieee8021pPriority
      Value:       100 (binary)
      Mask:        110 (binary)

      Filter15:                        -- VLAN 2304
      Type:        Ieee8021QVlan
      Value:       100100000000 (binary)
      Mask:        111111111111 (binary)

Such classifiers may be subject of other standards or may be enterprise-
specific but are not discussed further in this document. here.

5.  Meters

5.1  Definition

Metering is the function of monitoring the arrival times of packets
   of a traffic stream and determining the level of conformance of each
   packet to a pre-established traffic profile. is defined in [DSARCH].  Diffserv network providers may
choose to offer services to customers based on a temporal (i.e., rate)
profile within which the customer submits traffic for the service. In

this event, a meter might be used to trigger real-time traffic
conditioning actions (e.g., marking) by routing a non-conforming packet
through an appropriate next-stage action element. Alternatively, it
might also be used for out-of-band management functions like statistics
monitoring for billing applications.

Meters are logically 1:N (fan-out) devices (although a mux multiplexor can
be used in front of a meter). Meters are parameterized by a temporal
profile and by conformance levels, each of which is associated with a
meter's output. Each output can be connected to another functional
element.

Note that this model of a meter differs slightly from that described in
[DSARCH]. In that description the meter is not a datapath element but is
instead used to monitor the traffic stream and send control signals to
action elements to dynamically modulate their behavior based on the
conformance of the packet.  We find the description here
   more powerful.

   We use the

The following diagram to illustrate illustrates a meter with 3 levels of conformance:

      unmetered              metered
      traffic                traffic
                +---------+
                |         |--------> conformanceA conformance A
      --------->|  meter  |--------> conformanceB conformance B
                |         |--------> conformanceC conformance C
                +---------+

      Figure 4.  An Example A Generic Meter

In some Diffserv examples, three levels of conformance are discussed in
terms of colors, with green representing conforming, yellow representing
partially conforming, conforming and red representing non-
   conforming non-conforming [AF-PHB]. These
different conformance levels are may be used to trigger different buffer management actions. queueing,
marking or dropping treatment later on in the processing. Other example
meters use a binary notion of conformance; in the general case N levels
of conformance can be supported. In general there is no constraint on
the type of functional element following a meter output, but care must
be taken not to inadvertently configure a datapath that results in
packet reordering within an OA.

5.2  Examples

   The following is a non-exhaustive list of possible meters.

5.2.1  Average Rate Meter

   An example of a very simple meter is an average rate meter.  This
   type of meter

A meter, according to this model, measures the average rate at which packets are
   submitted to it over
making up a specified averaging time.

   An average stream of traffic pass it, compares the rate profile may take to some set of
thresholds and produces some number (two or more) potential results: a
given packet is said to "conform" to the following form:

      Meter1:
      Type:                AverageRate
      Profile1:            output A
      NonConforming:       output B

      Profile1:
      Type:                AverageRate
      AverageRate:         120 KBps
      Delta:               1.0 msec
   A meter measuring against this profile would continually maintain a
   count that indicates if, at the total number of packets arriving between time T (now) and time T - 1.0 msecs.  So long as an arriving packet
   does not push the count over 120 bytes, that the
packet would be deemed
   conforming.  Any packet that pushes is being looked at, the count over 120 would be
   deemed non-conforming.  Thus, this meter deems packets to correspond stream appears to one of two conformance levels: conforming or non-conforming.

5.2.2  Exponential Weighted Moving Average (EWMA) Meter be within the meter's
limit rate.

The EWMA form concept of meter is easy conformance to implement a meter bears comment. The concept applied
in hardware several rate-control architectures, including ATM, Frame Relay,
Integrated Services and can be
   parameterized Differentiated Services, is variously described
as follows:

      avg_rate(t) = (1 - Gain) * avg_rate(t') +  Gain * rate(t)
      t = t' + Delta

   For a packet arriving "leaky bucket" or a "token bucket".

A leaky bucket algorithm is primarily used for traffic shaping (handled
under Queues and Schedulers in this model): traffic theoretically
departs from a device at a rate of one bit every so many time t:

      if (avg_rate(t) > AverageRate)
         non-conforming
      else
         conforming

   Gain controls units but,
in fact, departs in multi-bit units (packets) at a rate approximating
that. It is also possible to build multi-rate leaky buckets, in which
traffic departs from the time constant (e.g. frequency response) of what switch at varying rates depending on recent
activity or inactivity.

A simple token bucket is
   essentially usually used in a simple IIR low-pass filter.  rate(t) measures Meter to measure the
   number behavior
of incoming bytes in a small fixed sampling interval, Delta.
   Any packet that arrives peer's leaky bucket, for verification purposes. It is, by
definition, a relationship between some defined burst_size, rate and pushes the average
interval:

      interval = burst_size/rate
   or
      rate over = burst_size/interval

Multi-rate token buckets (token buckets with both a predefined peak and a mean rate AverageRate is deemed non-conforming.  An EWMA meter profile
   might look as follows:

      Meter2:
      Type:                ExpWeightedMovingAvg
      Profile2:            output A
      NonConforming:       output B

      Profile2:
      Type:                ExpWeightedMovingAvg
      AverageRate:         25 KBps
      Delta:               10.0 usec
      Gain:                1/16

5.2.3  Two-Parameter Token Bucket Meter

   A
and sometimes more sophisticated meter might measure conformance to a token
   bucket (TB) profile.  A TB profile generally has two parameters, an
   average token rate, a rates) are commonly used. In this case, the burst size.  TB meters compare
size for the arrival
   rate of packets baseline traffic is conventionally referred to as the average rate
"committed burst" and the time interval is as specified by

      interval = committed_burst/mean_rate

but additional burst sizes (each an increment over its predecessor) are
defined, which are conventionally referred to as "excess" burst sizes.
The peak rate therefore equals the TB profile.
   Logically, byte tokens accumulate in a bucket at sum of the average rate,
   up burst sizes for any given
interval.

A data stream is said to conform to a maximum credit which is the burst size.  Packets of length
   L bytes are considered conforming simple token bucket if L tokens are available in the
   bucket switch
receives at most the "burst_size" of data in any time interval of packet arrival.  Packets are allowed length
"interval". In the multi-rate case, the traffic is said to conform at a
given level to
   exceed the average token bucket at if its rate in bursts up to does not exceed the sum
of the relevant burst size.  Packets
   which arrive sizes in any given interval. Received traffic that
arrives pre-classified as one of the "excess" rates (e.g. AF12 or AF13
traffic for a device implementing the AF1x PHB) is only compared to find the
relevant excess buckets.

<ed: the following paragraphs may need fixing when we can all agree on a bucket with insufficient tokens
stricter vs. looser definition: for now we assume strict schedulers and
lenient meters.>

The fact that data is organized into variable length packets introduces
some uncertainty in it are
   deemed non-conforming.  A two-parameter TB meter has exactly two
   possible this conformance levels (conforming, non-conforming).  TB
   implementation details are discussed decision. When used in Appendix A.

   A two-parameter RB a Scheduler,
a leaky bucket releases a packet only when all of its bits would have
been allowed: it does not borrow from future capacity. When used in a
Meter, a token bucket accepts a packet if any of its bits would have
been accepted and "borrows" any excess capacity required from that
allotted to equivalently classified traffic in a previous or subsequent
interval. Note that [SRTCM] and [TRTCM] insist on stricter behaviour
from a meter profile might look than the model here insists on.

Multiple classes of traffic, as follows:

      Meter3:
      Type:                SimpleTokenBucket
      Profile3:            output identified by the classifier table, may
be presented to the same meter. Imagine, for example, that it is desired
to drop all traffic that uses any DSCP that has not been publicly
defined.  A
      NonConforming:       output B

      Profile3:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           100 KB

5.2.4  Multi-Stage Token Bucket Meter

   More complicated TB meters classifier entry might define two burst sizes exist for each such DSCP, shunting it
to an "accepts everything" meter and three
   conformance levels.  Packets found dropping all traffic that conforms
to exceed the larger burst size
   are deemed non-conforming.  Packets found only that meter.

It is necessary to identify what is to be done with packets that conform
to exceed the smaller
   burst size are deemed partially conforming.  Packets exceeding
   neither are deemed conforming.  Token bucket meters designed meter and with packets that do not. It is also necessary for
   Diffserv networks are described in more detail in [SRTCM, TRTCM,
   GTC]; in the
meter to be arbitrarily extensible as some PHBs require the successive
application of these references three levels an arbitrary number of conformance are
   discussed meters.  The approach taken in terms of colors, with green representing conforming,
   yellow representing partially
this model is to have each meter indicate what action is to be taken for
conforming traffic and red representing non-
   conforming.  Often these multi-conformance level meters can what meter is to be
   implemented using an appropriate configuration of multiple two-
   parameter TB meters.

   A profile used for traffic which fails
to conform. With the definition of a multi-stage TB meter with three levels special type of conformance
   might look as follows:

      Meter4:
      Type:                MultiTokenBucket
      Profile4:            output A
      Profile5:            output B
      NonConforming:       output C

      Profile4:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           20 KB

      Profile5:
      Type:                SimpleTokenBucket
      AverageRate:         100 KBps
      BurstSize:           100 KB

5.2.5  Null Meter

   A null meter to which all
traffic conforms, this has only one output: always conforming, and no
   associated temporal profile.  Such the necessary flexibility.

Note that this definition of a simple token bucket meter is useful to define in the
   event requires that
the configuration or management interface does not have minimal bucket size be at least the flexibility to omit a meter in a datapath segment.

6.  Action Elements

   Classifiers and meters are fan-out elements which are generally used
   to determine MTU of the appropriate action incoming link and it
should also be initialised with sufficient tokens to apply allow for at least
one MTU-sized packet to a packet. conform if it arrives at time zero.

5.1.  Examples

The set following are some examples of possible actions include:

   1) Marking
   2) Dropping
   2) Shaping
   3) Replicating
   4) Monitoring

   The corresponding action elements are described in the following
   paragraphs.

   Policing is a general term for the process meters.

5.1.1.  Average Rate Meter

An example of preventing a traffic
   stream from seizing more than its share very simple meter is an average rate meter. This type of resources from a Diffserv
   network.  Each of the first three actions described above may be used
   to police traffic.  Markers do so by re-marking non-conforming
   packets to a DSCP value that is entitled to fewer network resources.
   Shapers and droppers do so by limiting
meter measures the average rate at which a particular
   traffic stream is packets are submitted to the network.

6.1  Marker

   Markers are 1:1 elements which set the DSCP in an IP header (in
   the case of unlabeled packets).  Markers may act on unmarked packets
   (submitted with DSCP of zero) or it
over a specified averaging time.

An average rate profile may re-mark previously marked
   packets.  In particular, the model supports take the application of
   marking based on a preceding classifier match.  The DSCP set in following form:

      Meter1:
      Type:                AverageRate
      Profile:             Profile1
      ConformingOutput:    Queue1
      NonConformingOutput: Counter1

      Profile1:
      Type:                AverageRate
      AverageRate:         120 kbps
      Delta:               100 msec

A meter measuring against this profile would continually maintain a
   packet will determine its subsequent treatment in downstream nodes
count that indicates the total number of a network, packets arriving between time T
(now) and possible time T - 100 msecs. So long as an arriving packet does not
push the count over 12 kbits in subsequent processing stages within the
   router (depending on configuration).

   Markers are normally parameterized by a single parameter: last 100 msec then the 6-bit
   DSCP to packet would
be marked in the deemed conforming. Any packet header.

      ActionElement1:
      Type:                Marker
      Mark:                010010

   In that pushes the case count over 12 kbits
would be deemed non-conforming. Thus, this meter deems packets to
correspond to one of a MPLS labeled packet, two conformance levels: conforming or non-
conforming and sends them on for the marker appropriate subsequent treatment.

5.1.2.  Exponential Weighted Moving Average (EWMA) Meter

The EWMA form of meter is parameterized
   by a 3-bit EXP value easy to be marked implement in the MPLS shim header.

6.2  Dropper

   Droppers simply discard packets. There are no parameters for
   droppers.  Because a dropper is a terminating point of the datapath,
   it may hardware and can be desirable to forward the
parameterized as follows:

      avg_rate(t) = (1 - Gain) * avg_rate(t') +  Gain * rate(t)
      t = t' + Delta

For a packet through arriving at time t:

      if (avg_rate(t) > AverageRate)
         non-conforming
      else
         conforming

"Gain" controls the time constant (e.g. frequency response) of what is
essentially a monitor first
   for instrumentation purposes.

   Droppers are not simple IIR low-pass filter. "rate(t)" measures the only elements than can cause number
of incoming bytes in a small fixed sampling interval, Delta.  Any packet to be
   discarded.  The other element is an enqueueing element (see Sec.
   6.6).  However, since
that arrives and pushes the enqueueing element's behavior average rate over a predefined rate
AverageRate is closely
   tied deemed non-conforming. An EWMA meter profile might look
something like the state of one or following:

      Meter2:
      Type:                ExpWeightedMovingAvg
      Profile:             Profile2
      ConformingOutput:    Queue1
      NonConformingOutput: AbsoluteDropper1

      Profile2:
      Type:                ExpWeightedMovingAvg
      AverageRate:         25 kbps
      Delta:               10 usec
      Gain:                1/16

5.1.3.  Two-Parameter Token Bucket Meter

A more queues, we choose to distinguish them
   as separate functional elements.

6.3  Shaper

   Shapers are used to shape traffic streams sophisticated meter might measure conformance to a certain temporal token bucket
(TB) profile.  For example, A TB profile generally has two parameters, an average
token rate and a shaper can be used burst size. TB meters compare the arrival rate of
packets to smooth traffic
   arriving in bursts.  In [DSARCH] a shaper is described as a
   queueing element controlled the average rate specified by a meter which defines its temporal the TB profile.  This model of  Logically,
tokens accumulate in a shaper differs substantially from typical
   shaper implementations.  Further, with bucket at the average rate, up to a maximum
credit which is the inclusion burst size. Packets of queueing
   elements length L bytes are considered
conforming if any tokens are available in the model a separate shaping element becomes confusing.
   Therefore, bucket at the function time of a shaper is embedded in a queue and is
   covered
packet arrival: up to L bytes may then be borrowed from future token
allocations. Packets are allowed to exceed the average rate in Sec. 7.

6.4  Replicating Element

   It is occasionally desirable bursts up
to replicate traffic on one or more
   additional interfaces for data collection purposes.  A replicating
   element is a 1:N (fan-out) element.  However, each and every packet
   follows each output path simultaneously.  A replicating element is
   parameterized by the number of outputs it supports.

6.5  Mux

   It is occasionally necessary burst size. Packets which arrive to multiplex traffic streams into find a 1:1
   or 1:N action element or classifier. bucket with no tokens
in it are deemed non-conforming. A M:1 (fan-in) mux is a simple
   logical device for merging traffic streams.  It is parameterized by
   its number of incoming ports.

6.6  Monitor

   One passive action is to account for the fact two-parameter TB meter has exactly
two possible conformance levels (conforming, non-conforming). TB
implementation details are discussed in Appendix A. Note that this is a data packet was
   processed.  The statistics
"lenient" meter that result allows some borrowing, as discussed above.

A two-parameter TB meter might be used later for
   customer billing, service verification, or network engineering
   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
   sized packet passes through it.  Monitors can also be used appear as follows:

      Meter3:
      Type:                SimpleTokenBucket
      Profile:             Profile3
      ConformingOutput:    Queue1
      NonConformingOutput: AbsoluteDropper1

      Profile3:
      Type:                SimpleTokenBucket
      AverageRate:         200 kbps
      BurstSize:           100 kbytes

5.1.4.  Multi-Stage Token Bucket Meter

More complicated TB meters might define two burst sizes and three
conformance levels. Packets found to count
   packets on exceed the larger burst size are
deemed non-conforming. Packets found to exceed the verge smaller burst size
are deemed partially conforming. Packets exceeding neither are deemed
conforming. Token bucket meters designed for Diffserv networks are
described in more detail in [SRTCM, TRTCM, GTC]; in some of being dropped by these
references three levels of conformance are discussed in terms of colors,
with green representing conforming, yellow representing partially
conforming and red representing non- conforming. Often these multi-
conformance level meters can be implemented using an appropriate
configuration of multiple two- parameter TB meters.

A profile for a dropper.

6.7 multi-stage TB meter with three levels of conformance
might look as follows:

      Meter4:
      Type:                TwoRateTokenBucket
      ProfileA:            Profile4
      ConformingOutputA:   Queue1
      ProfileB:            Profile5
      ConformingOutputB:   Marker1
      NonConformingOutput: AbsoluteDropper1

      Profile4:
      Type:                SimpleTokenBucket
      AverageRate:         100 kbps
      BurstSize:           20 kbytes

      Profile5:
      Type:                SimpleTokenBucket
      AverageRate:         100 kbps
      BurstSize:           100 kbytes

5.1.5.  Null Action Meter

A null action meter has only one input output: always conforming, and one output.  The element performs no
   action on the packet. associated
temporal profile. Such an element a meter is useful to define in the event that the
configuration or management interface does not have the flexibility to
omit an action element a meter in a datapath segment.

7.  Queueing block

      Meter5:
      Type:                NullMeter
      Output:              Queue1

6.  Action Elements

The queueing block modulates the transmission of packets belonging to
   the different traffic streams classifiers and determines their ordering, possibly
   storing them temporarily or discarding them.  Packets meters described up to this point are usually
   stored either because there is a resource constraint (e.g., available
   bandwidth) fan-out
elements which prevents immediate forwarding, or because the
   queueing block is being are generally used to alter determine the temporal properties appropriate action to
apply to a packet. The set of possible actions include:

-    Marking

-    Absolute Dropping

-    Multiplexing

-    Counting

-    Null action - do nothing

The corresponding action elements are described in the following
sections.

Diffserv nodes may apply shaping, policing and/or marking to traffic
streams that exceed the bounds of their TCS in order to prevent a
traffic stream (i.e., shaping).  Packets are discarded either because from seizing more than its share of buffering limitations, because resources from a buffer threshold is exceeded
   (including when shaping is performed),
Diffserv network. Shaping, sometimes considered as a feedback control signal
   to reactive control protocols such TC action, is
treated as TCP, because a meter exceeds a
   configured rate (i.e., policing).

   The part of the queueing block module in this model model, as is a logical abstraction the use of a
   queueing system, which is used to configure PHB-related parameters.
   There
Algorithmic Dropping techniques - see section 7.  Policing is no conformance to this model.  The model can be used to
   represent a broad variety modelled
as the combination of possible implementations.  However, it
   need not necessarily map one-to-one either a meter or a scheduler with physical queueing systems in either an
absolute dropper or an algorithmic dropper.  These elements will discard
packets which exceed the TCS.  Marking is performed by a specific router implementation.  Implementors should map marker, which
(in this context) alters the
   configurable parameters DSCP, and thus the PHB, of the implementation's queueing systems to
   these queueing block parameters as appropriate packet to achieve equivalent
   behaviors.

7.1  Model

   Queuing is a function
give it a lower-grade treatment at subsequent Diffserv nodes.

6.1.  Marker

Markers are 1:1 elements which lends itself to innovation.  It must be
   modelled to allow set a broad range of possible implementations to be
   represented using common structures and parameters.  This model uses
   functional decomposition as a tool to permit the needed lattitude.

   Queueing sytems, such as codepoint (e.g. the queueing block defined DSCP in this model,
   perform three distinct, but related, functions:  they store packets,
   they modulate the departure of an IP
header). Markers may also act on unmarked packets belonging to various traffic
   streams and they selectively discard (e.g. those submitted
with DSCP of zero) or may re-mark previously marked packets.  This model decomposes In
particular, the queueing block into model supports 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 application of marking based on a
preceding classifier match. The mark set in a packet will determine its
subsequent treatment in downstream nodes of one or more FIFO, one or more
   scheduler, a network and one or more discarder.  See figure TBA possibly also
in subsequent processing stages within this router.

DSCP Markers for an example
   of Diffserv are normally parameterized by a queueing block.

   Note that single
parameter: the term FIFO 6-bit DSCP to be marked in the packet header.

      Marker1:
      Type:                DSCPMarker
      Mark:                010010

6.2.  Absolute Dropper

Absolute droppers simply discard packets. There are no parameters for
these droppers. Because this dropper is overloaded (i.e., has more than one
   meaning).  In common usage a terminating point of the
datapath and have no outputs, it is taken probably desirable to mean, among other things, forward the
packet through a
   data structure that permits items counter action first for instrumentation purposes.

      AbsoluteDropper1:
      Type:                AbsoluteDropper

Absolute droppers are not the only elements than can cause a packet to
be removed only in discarded: another element is an Algorithmic Dropper element (see
Section 6.6). However, since this element's behavior is closely tied the order in
   which they were inserted, and

state of one or more queues, we choose to distinguish it as a service discipline which separate
functional element.

6.3.  Multiplexer

It is non-
   reordering.

7.1.1  FIFO

   A FIFO occasionally necessary to multiplex traffic streams into a 1:1 or
1:N action element or classifier.  A M:1 (fan-in) multiplexer is a
simple logical device for merging traffic streams. It is parameterized
by its number of incoming ports.

      Mux1:
      Type:                Multiplexer
      Output:              Queue2

6.4.  Counter

One passive action is to account for the fact that a data structure packet was
processed. The statistics that result might be used later for customer
billing, service verification, or network engineering purposes. Counters
are 1:1 functional elements which at any update a counter by L and a packet
counter by 1 every time may contain zero
   or more packets.  It may have one a L-byte sized packet passes through them.
Counters can be used to count packets about to be be dropped by a
dropper or more threshold associated with
   it. a queueing element.

      Counter1:
      Type:                Counter
      Output:              Queue1

6.5.  Null Action

A FIFO null action has one or more inputs input and exactly one output.  It must
   support The element performs no
action on the packet. Such an enqueue operation to add a packet element is useful to define in the tail of event
that the
   queue, and a dequeue operation configuration or management interface does not have the
flexibility to remove omit an action element in a packet from datapath segment.

      Null1:
      Type:                Null
      Output:              Queue1

7.  Queueing Blocks

Queueing blocks modulate the head transmission of packets belonging to the queue.  Packets must be dequeued in the order in which they were
   enqueued.  A FIFO has
different traffic streams and determine their ordering, possibly storing
them temporarily or discarding them. Packets are usually stored either
because there is a depth, resource constraint (e.g., available bandwidth) which indicates
prevents immediate forwarding, or because the number queueing block is being

used to alter the temporal properties of packets
   that it contains at a particular time; traffic stream (i.e.
shaping). Packets are discarded either because of buffering limitations,
because a buffer threshold is exceeded (including when shaping is
performed), as a feedback control signal to reactive control protocols
such as TCP, because a meter exceeds a configured rate (i.e. policing).

The queueing block in this model is a traffic dependent
   variable and not logical abstraction of a queueing
system, which is used to configure a FIFO.

   Typically, the FIFO element of PHB-related parameters.  There is no
conformance to this model. The model will can be implemented as used to represent a
   FIFO data structure. broad
variety of possible implementations. However, this does not preclude implementations
   which are it need not strictly FIFO, necessarily
map one-to-one with physical queueing systems in that they also support operations
   that remove or examine packets (e.g., for use by discarders) other
   than at a specific router
implementation. Implementors should map the tail.  However, such operations MUST NOT have configurable parameters of
the effect implementation's queueing systems to these queueing block parameters
as appropriate to achieve equivalent behaviors.

7.1.  Queueing Model

Queueing is a function a which lends itself to innovation. It must be
modelled to allow a broad range of reordering packets belonging possible implementations to the same microflow.

   In an implementation, packets are presumably stored be
represented using common structures and parameters. This model uses
functional decomposition as a tool to permit the needed lattitude.

Queueing sytems, such as the queueing block defined in this model,
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 queueing
block is thus composed of of one or more
   buffer.  Buffers are allocated from FIFOs, one or more free buffer pool.  If
   there Schedulers
and zero or more Algorithmic Droppers.

     <ed: should this be *one* or more? There are valid cases that do
     not require a dropper but they are exceptional.>

Note that the term FIFO has multiple instances of different common usages: it is
sometimes taken to mean, among other things, a FIFO, their packet buffers may or
   may not data structure that
permits items to be allocated out of removed only in the same free buffer pool.  Free buffer
   pools order in which they were
inserted or a service discipline which is non- reordering.

7.1.1.  FIFO

In this model, a FIFO element is a data structure which at any time may
contain zero or more packets. It may also have one or more threshold thresholds
associated with them, which
   may affect discarding and/or scheduling.  Otherwise, buffering
   mechanisms are implementation specific and not part of this model. it. A FIFO might be represented using has one or more inputs and exactly one
output. It must support an enqueue operation to add a packet to the following parameters:

	FIFO1:
	Type:       FIFO
	Input:      QueuingBlock.input1
	Output:     Discarder2
	Threshold1: 3 packets

   Another FIFO may tail
of the queue, and a dequeue operation to remove a packet from the head

of the queue. Packets must be represented using dequeued in 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 order in which they were
enqueued. A scheduler is an element FIFO has a current depth, which gates indicates the departure number of each packet
packets that arrives it contains at one a particular time. FIFOs in this model are
modelled without inherent limits on their depth - obviously this does
not reflect the reality of implementations: FIFO size limits are
modelled here by an algorithmic dropper associated with the FIFO,
typically at its inputs, based on a service discipline. input. It
   has one or more input and exactly one output.  Each input has is quite likely that, every FIFO will be
preceded by an
   upstream element algorithmic dropper.  One exception might be the case
where the packet stream has already been policed to which it is connected, and a set of parameters profile that affects can
never exceed the scheduling of packets received scheduler bandwidth available at that input.

   The service discipline (also known as a scheduling algorithm) is the FIFO's output -
this would not need 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 algorithmic dropper at the scheduler's
   inputs; parameters (such as packet length or DSCP) associated with input to the packet present at its input; absolute time and/or local state.

   Possible service disciplines fall into FIFO.

This representation of a number FIFO allows for one common type of categories,
   including (but not depth limit,
one that results from a FIFO supplied from a limited to) first come, first served (FCFS),
   strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR,
   etc.), rate-limited strict priority, pool of buffers,
shared between multiple FIFOs.

     <ed: should we instead model a FIFO as having a single input 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
     use a packet "multiplexer" at every transmission opportunity if
   one is available.  A non-work conserving service discipline transmits
   packets no sooner than a scheduled departure time, even its input if it means
   leaving packets in a FIFO while the link is idle.  Non-work
   conserving schedulers can be used needs to shape traffic streams by
   delaying packets that would collect from
     multiple input sources?>

Typically, the FIFO element of this model will be deemed non-conforming by some traffic
   profile.  The packet is delayed until such time implemented as it would conform
   to a meter using 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 same profile.

   [DSARCH] defines PHBs without specifying required scheduling
   algorithms. head
or tail. However, PHBs such as  the class selctors [DSFIELD],
   EF [EF-PHB] and AF [AF-PHB] operations MUST NOT 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 effect of these per-
   hop behaviors.  It does not attempt reordering
packets belonging to specify the same microflow.

In an all-embracing
   set implementation, packets are presumably stored in one or more
buffers. Buffers are allocated from one or more free buffer pools. If
there are multiple instances 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 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 a non-work conserving service discipline).  The
   minimum service rate allows rate guarantees for each traffic stream
   as required by EF them, which may affect
discarding and/or scheduling. Other than this, buffering mechanisms are
implementation specific and AF without specifying the details not part of how excess
   bandwidth between these traffic streams is shared.  Additional
   parameters to control this behavior should model.

A FIFO might be made available, but are
   dependent on represented using the particular scheduling algorithm implemented.  The
   service priority following parameters:

     Fifo1:
     Type:       FIFO
     Output:     Scheduler1

Note that a FIFO must provide triggers and/or current state information
to other elements upstream and downstream from it: in particular, it is used only after
likely that the MinRateProfiles of all inputs
   have been satisfied in order to decide how current depth will need to allocate any remaining
   bandwidth.  It could be used for the class selectors. For the EF PHB,
   using a strict priority scheduling algorithm on some links, and assuming
   that by Algorithmic
Dropper elements placed before or after the aggregate EF rate has been appropriately bounded FIFO. It will also likely
need to avoid
   starvation, provide an implicit "I have packets for this you" signal to
downstream Scheduler elements.

7.1.2.  Scheduler

A scheduler is an element which gates the MinRateProfile would be reported
   as zero and the MaxRateProfile reported as line rate.  Setting the
   service priority departure 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.

   A non-work conserving scheduler might be represented using the
   following parameters:

	Scheduler1:
	Type:           Scheduler

	Input1:         Discarder1
	MaxRateProfile:	Profile1
	MinRateProfile:	Profile2
	Priority:       None

	Input2:         Discarder1
	MaxRateProfile:	Profile3
	MinRateProfile:	Profile4
	Priority:       None

   A work conserving scheduler might be represented using the
   following parameters:

	Scheduler2:
	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

7.1.3 Discarder

   A discarder is an element which selectively discards packets packet that
   arrive
arrives at one of its input, inputs, based on a discarding service discipline. It has one
or more input and exactly one output.  In this model (but not necessarily in a real
   implementation), a packet enters the discarder at the input, and
   either its buffer is returned Each input has an upstream element
to a free buffer pool or which it exits is connected, and a set of parameters that affects the
   discarder
scheduling of packets received at the output.

   Alternatively, a discarder may invoke operations on that input.

The service discipline (also known as a FIFO scheduling algorithm) is an
algorithm which
   selectively remove packets, then return those packets to the free
   buffer pool, based on a discarding discipline.  In this case, might take any of the
   discarder's operation is modelled following as a  side-effect on the FIFO upon
   which it operates, rather than its input(s):

a)   static parameters such as having a discrete input and output.

   A discarder has a trigger that causes relative priority associated with each of
     the discarder to make a
   decision whether scheduler's inputs.

b)   absolute token bucket parameters for maximum or not to drop one (or possibly more than one)
   packet.  The trigger may internal (i.e., the arrival minimum rates
     associated with each of a packet at
   the input to the discarder), or it may be external (i.e., resulting
   from one or more state change at another element, scheduler's inputs.

c)   parameters, such as a FIFO
   depth exceeding a threshold packet length or DSCP, associated with the
     packet currently present at its input.

d)   absolute time and/or local state.

Possible service disciplines fall into a scheduling event).  A trigger may be
   a boolean combination number of events 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
(see Glossary). Non-work-conserving schedulers can be used to shape
traffic streams to match some profile by delaying packets that might be
deemed non-conforming by some downstream node: a FIFO depth exceeding a
   threshold OR a buffer pool depth falling below a threshold).

   The discarding discipline packet is an algorithm which makes a decision delayed until
such time as it would conform to
   forward or discard a packet.  It takes downstream meter using the same
profile.

[DSARCH] defines PHBs without specifying required scheduling algorithms.
However, PHBs such as its  the class selectors [DSFIELD], EF [EF-PHB] and AF
[AF-PHB] have descriptions or configuration parameters some which strongly
suggest the sort of scheduling discipline needed to implement them. This
memo discusses a minimal set of
   dynamic queue parameters (e.g., averaged or instantaneous FIFO depth) and
   some to enable realization
of these per- hop behaviors. It does not attempt to specify an all-
embracing set of static parameters (e.g. thresholds) and possibly
   parameters associated with the packet (e.g. its PHB, to cover all possible implementation models.
A mimimal set includes:

a)   a minimum service rate profile which allows rate guarantees for
     each traffic stream as determined required by
   a classifier).  It may also have internal state.  RED, RIO, EF and drop-
   on-threhold AF without specifying the
     details of how excess bandwidth between these traffic streams is
     shared. Additional parameters to control this behavior should be
     made available, but are examples dependent on the particular scheduling
     algorithm implemented.

b)   a service priority, used only after the minimum rate profiles of
     all inputs have been satisfied, to decide how to allocate any
     remaining bandwidth.

c)   a discarding maximum service rate profile, for use only with a non-work-
     conserving service discipline.  Tail dropping

For an implementation of the EF PHB using a strict priority scheduling
algorithm that assumes that the aggregate EF rate has been appropriately
bounded to avoid starvation, the minimum rate profile would be reported
as zero and head dropping are effected by the location of maximum service rate would be reported as line rate.
Such an implementation, with multiple priority classes, could also be
used for the discarder
   relative Diffserv class selectors [DSFIELD].

Alternatively, setting the service priority values for each input to the FIFO.

Note that although a discarder may need
scheduler to examine the DSCP or
possibly other fields in a packet, it may not modify them (i.e.,
it 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 not less than or equal to the line rate.

For example, a marker).

A discarder non-work-conserving scheduler, allocating spare bandwidth
equally between all its inputs, might be represented using the following
parameters:
	Discarder1:

     Scheduler1:
     Type:			Discarder
	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           Scheduler2Input

     Input1:
     MaxRateProfile: Profile1
     MinRateProfile: Profile2
     Priority:       none

     Input2:
     MaxRateProfile: Profile3
     MinRateProfile: Profile4
     Priority:       none

A work-conserving scheduler 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:

     Scheduler2:
     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           Scheduler3Input

     Input1:
     MaxRateProfile: WorkConserving
     MinRateProfile: Profile5
     Priority:       1

     Input2:
     MaxRateProfile: WorkConserving
     MinRateProfile: Profile6
     Priority:       2

     Input3:
     MaxRateProfile: WorkConserving
     MinRateProfile: none
     Priority:       3

7.1.3.  Algorithmic Dropper

An Algorithmic Dropper 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, an element which selectively discards packets
that arrive at least its input, based on a discarding algorithm. It has one discarder,
data input and at least one scheduler.   The following
connections are allowed:

The input of output. In this model (but not necessarily in a FIFO may be real
implementation), a packet enters the dropper at its input of the queueing block, or it
may be connected and either its
buffer is returned to the output of a discarder free buffer pool or to the packet exits the dropper
at the output.

Alternatively, an output of Algorithmic Dropper may invoke operations on a scheduler.

Each input of FIFO
which selectively removes a scheduler may be connected packet, then return its buffer to the output of free
buffer pool, based on a
FIFO, to discarding algorithm. In this case, the output of
operation is modelled as a discarder or to side-effect on the output of another
scheduler.

The input of a discarder FIFO upon which has it
operates, rather than as having a discrete input and output
may be the input of output.  These two
treatments are equivalent and we choose the queue, or former here.

The Algorithmic Dropper is modelled as having a single input. However,
it is likely that packets which were classified differently by a
Classifier in this TCB will end up passing through the same dropper. The
dropper's algorithm may be connected need to the
output apply different calculations based on
characteristics of the incoming packet e.g. its DSCP. So there is a FIFO (e.g., head dropping).

The output
need, in implementations of the queueing block may this model, to be the output of a FIFO
element, a discarding able to relate information
about which classifier element or a scheduling element.

Note, in particular, that schedulers may operate in series such
that was matched by a packet at the head of from a FIFO feeding the concatenated
schedulers Classifier
to an Algorithmic Dropper.  This is serviced only after all modelled here as a reverse pointer
from one of the scheduling criteria drop probability calculation algorithms inside the
dropper to the classifier element that selects this algorithm.

There are met.  For example, a FIFO which carries EF traffic streams
may be served first by many formulations of a non-work conserving scheduler to shape model that could represent this
linkage, other than the stream one described above: one way would have been to a maximum rate, then by a work conserving scheduler
have multiple "inputs" fed from the preceding elements, leading
eventually 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 classifier elements that packets
will be deemed conforming matched the packet. Another
formulation might have been for the Classifier to (logically) include
some sort of "classification identifier" along with the packet along its
path, for use by any subsequent meters, e.g., element. Yet another could have been to
include a classifier inside the dropper, in downstream
Diffserv nodes.  Shaping may also be used order for it to isolate certain traffic
streams from pick out the effects

drop algorithm to be applied. All of these other traffic streams of approaches were deemed
to be more clumsy or less useful than the same BA.

A shaper  is realized approach taken here.

An Algorithmic Dropper, shown in this model by using Figure 5, has one or more triggers that
cause it to make a non-work conserving
scheduler.  Some implementations may elect decision whether or not to have queues whose sole
purpose is shaping, while others drop one (or possibly more
than one) packet. A trigger may integrate be internal (the arrival of a packet at
the shaping function
with other buffering, discarding and scheduling associated with access input to a resource.  Shapers operate by delaying the departure of packets
that would dropper) or it may be deemed non-conforming by external (resulting from one or
more state changes at another element, such as a meter configured to the shaper's
maximum service rate profile.  The packet FIFO depth exceeding a
threshold or a scheduling event). It is scheduled likely that an instantaneous
FIFO depth will need to depart no
sooner be smoothed over some averaging interval. Some
dropping algorithms may require several trigger inputs feeding back from
events elsewhere in the system e.g. smoothing functions that calculate
averages over more than such one time that it would become conforming.

8.  Traffic Conditioning Blocks (TCBs)

   The classifiers, meters, action elements, interval.  Smoothing functions are
outside the scope of this document and queueing elements
   described above can are not modelled here, we merely
indicate where they might be combined into traffic conditioning blocks
   (TCBs).  The TCB is an abstraction of a functional element that added in the model.

A trigger may be used to facilitate the definition of specific traffic conditioning
   functionality.

   One of the simplest possible TCBs would consist of the following
   stages:

   1.  Classifier stage
   2.  Enqueueing stage
   3.  Queueing stage

   Note that a classifier is a 1:N element, while an enqueueing stage is a N:1 element and boolean combination of events (e.g. a queue is FIFO depth
exceeding a 1:1 element.  If the classifier split
   traffic across multiple enqueueing elements then the queueing stage
   may consist of threshold OR a hierarchy of queue sets, all resulting in buffer pool depth falling below a 1:1
   abstract element.

   A more general TCB might consists of the following four stages:

   1. Classifier stage
   2. Metering stage
   3. Action stage
   4. Queueing stage

   where each stage may consist of threshold).

The dropping algorithm makes a set of parallel datapaths
   consisting of pipelined elements.

   TCBs are constructed by connecting elements corresponding to these
   stages in any sensible order.  It is possible to omit stages, decision on whether to
   include null elements, forward or to concatenate multiple stages
discard a packet. It takes as its parameters some set of the same
   type.  TCB outputs may drive additional TCBs (on either the ingress dynamic
parameters (e.g. averaged or egress interfaces).   Classifiers instantaneous FIFO depth) and meters are fan-out elements,
   muxes some set of
static parameters (e.g. thresholds) and enqueueing elements are fan-in elements.

8.1  An Example TCB

   The following diagram illustrates an example TCB:

                                       +------------> to Queue A
                              +-----+  |              (not shown)
                              |     |--+
                           +->|     |
                           |  |     |--+  +-----+    +-----+
                           |  +-----+  |  |     |    |     |
                           |   meter   +->|     |--->|     |
                           |              |     |    |     |
                           |              +-----+    +-----+
                           |              monitor    dropper
                           |
                           |
                           |
     submitted +-----+     |  +-----+     +-----+
     traffic   |  A  |-----+  |     |     |     |
           --->|  B  |------->|     |---->|     |---> to Queue B
               |  C  |-----+  |     |     |     |     (not shown)
               |  X  |--+  |  +-----+     +-----+
               +-----+  |  |   marker     shaper
                 BA possibly parameters associated

           +------------------+      +-----------+
           | +-------+        |              queue
              classifier|  n   |smoothing  |
           | |trigger|<----------/---|function(s)|
           | |calc.  |        |      |(optional) |
           | +-------+        |      +-----------+
           |     |            |  +-----+                +-----+          ^
           |     v            |          |Depth
  Input    |     |--------------->| +-------+ no     |      ------------+   to Queue C Scheduler
  ---------->|discard|-------------->    |x|x|x|x|------->
           |  +->| |   ?   |     |->        |      ------------+
           |     |--+  +-----+ +->| +-------+        | (not shown)           FIFO
           |     +-----+    |yes          |
           |  | |  +-----+ |      meter   +->|     |-+    mux           |
           |  | v |                 +-----+ count +   |                 marker
           |
                        +---------------------------> to Queue D
                                                      (not shown)  +---+ bit-bucket|
           +------------------+
           Algorithmic
           Dropper

      Figure 5:  An Example Traffic Conditioning Block

   This sample TCB might be suitable for an ingress interface at 5. Algorithmic Dropper + Queue

with the packet (e.g. its PHB, as determined by a
   customer/provider boundary.  A SLS classifier, which will
determine on which of the droppers inputs trhe packet arrives). It may
also have internal state and is presumed likely to have been
   negotiated between keep counters regarding the customer
dropped packets (there is no appropriate place here to include a Counter
Action element).

RED, RED-on-In-and-Out (RIO) and the provider which specifies the
   handling Drop-on-threshold are examples of the customer's traffic
dropping algorithms. Tail-dropping and head-dropping are effected by the provider's network.  The
   agreement might be
location of the following form:

      DSCP         PHB       Profile       Non-Conforming Packets
      ----         ---       -------       ----------------------
      001001       PHB1      Profile1      Discard
      001100       PHB2      Profile2      Wait in shaper queue
      001101       PHB3      Profile3      Re-mark dropper relative to DSCP 001000
   It is implicit in this agreement that conforming packets are given
   the PHB originally indicated by the packets' DSCP field.  It
   specifies that FIFO.

Note that, although an Algorithmic Dropper may require knowledge of data
fields in a packet, as discovered by a Classifier in the customer same TCB, it
may submit packets marked for DSCP
   001001 which will get PHB1 treatment not modify the packet (i.e. it is not a marker).

     <ed: have rearranged this example so long as they remain
   conforming not to Profile1 and will be discarded if they exceed this
   profile.  Similar contract rules are applied for 001100 and 001101
   traffic.

   In this example, include a Classifier
     in the Dropper - this leads to needing either multiple inputs or an
     implicit 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 in- and C.  The 'X' in the BA classifier
   is the default wildcard filter that matches every packet.

   A metering stage is next in out-of-
     profile traffic. We have chosen the upper and lower branches.  There is a
   separate meter for each set of packets corresponding to DSCPs former representation.>

A and
   C.  Each meter dropper which uses a specific profile as specified in the TCS for RIO algorithm might be represented using the corresponding Diffserv service level.  The meters in this
   example indicate one
following parameters:

      AlgorithmicDropper1:
      Type:                   AlgorithmicDropper
      Discipline:             RIO
      Trigger:                Internal
      Output:                 Fifo1

      InputA: (in profile)
      MinThresh:              Fifo1.Depth > 20 kbyte
      MaxThresh:              Fifo1.Depth > 30 kbyte

      InputB: (out of profile)
      MinThresh:              Fifo1.Depth > 10 kbyte
      MaxThresh:              Fifo1.Depth > 20 kbyte

      SampleWeight            .002
      MaxDropProb             1%

Another form of two conforming levels, conforming or
   non-conforming.  The middle branch has dropper, a marker threshold-dropper, might be represented using
the following parameters:

      AlgorithmicDropper2:
      Type:                   AlgorithmicDropper
      Discipline:             Drop-on-threshold
      Trigger:                Fifo2.Depth > 20 kbyte
      Output:                 Fifo1

Yet another dropper which re-marks drops all out-of-profile packets received with DSCP B.

   Following whenever the metering stage
FIFO threshold exceeds a certain depth (this dropper is the action stage in the upper and
   lower branches.  Packets submitted for DSCP A that are deemed non-
   conforming and are counted and discarded.  Packets that are
   conforming are passed on to Queue A.  Packets submitted for DSCP C
   that are deemed non-conforming are re-marked, and then conforming and
   non-conforming packets are muxed together before being forwarded to
   Queue C.  Packets submitted for DSCP B are shaped to Profile2 before
   being forwarded to Queue B.

   The interconnections not part of the
larger TCB elements illustrated in Fig. 5 can example) might be represented as follows:

      TCB1:

      Classifier1:
      Output A --> Meter1
      Output B --> Marker1
      Output C --> Meter2
      Output X --> QueueD

      Meter1:
      Output A --> QueueA
      Output B --> Monitor1

      Monitor1:
      Output A --> Dropper1

      Marker1:
      Output A --> Shaper1
      Shaper1:
      Output A --> Queue B

      Meter2:
      Output A --> Mux1
      Output B --> Marker2

      Marker2:
      Output A --> Mux1

      Mux1:
      Output A --> Queue C

8.2  An Example TCB to Support Multiple Customers

   The TCB described above can be installed on with the following parameters:

      AlgorithmicDropper3:
      Type:                   AlgorithmicDropper2Input
      Discipline:             Drop-out-packets-on-threshold
      Output:                 Fifo3

      InputA: (in profile)
      Trigger:                none
      InputB: (out of profile)
      Trigger:                Fifo3.Depth > 100 kbyte

     <ed: this models the dropper without using an ingress interface to
   implement embedded Classifier
     which seems a provider/customer TCS if cleaner model than embedding a classifier here>

7.1.4.  Constructing queueing blocks from the interface elements

A queueing block is dedicated constructed by concatenation of these elements so as
to meet the customer.  However, if a single interface is shared between
   multiple customers, then meta-policy objectives of the TCB above will not suffice, since it
   does not differentiate among traffic from different customers.  Its
   classification stage uses only BA classifiers.

   The TCB is readily extended implementation, subject to support the case of multiple customers
   per interface, as follows.  First, we define
grammar rules specified in this section.

Elements of the same type may appear more than once in a TCB for each customer
   to reflect queueing block,
either in parallel or in series. Typically, a queueing block will have
relatively many elements in parallel and few in series.  Iteration and
recursion are not supported constructs in this grammar. A queueing block
must have at least one FIFO, at least one dropper, and at least one
scheduler.  The following connections are allowed:

1)   The input of a FIFO may be the TCS with that customer.  TCB1, defined above is input of the
   TCB for customer 1.  We add definitions for TCB2 and for TCB3 which
   reflect queueing block or it
     may be connected to the agreements with customers 2 and 3 respectively.

   Finally, we add output of a classifier which provides dropper or to an output of a front end
     scheduler.

2)   Each input of a scheduler may be connected to separate the traffic from output of a FIFO,
     to the three different customers.  This forms output of a new
   TCB dropper or to the output of another scheduler.

3)   The input of a dropper which incorporates TCB1, TCB2, and TCB3, has a discrete input and can output may be illustrated
   as follows:

      submitted +-----+
      traffic   |  A  |--------> TCB1
            --->|  B  |--------> TCB2
                |  C  |--------> TCB3
                |  X  |--------> Dropper4
                +-----+
                Classifier4

      Figure 6: An Example
     the input of the queueing block or it may be connected to the
     output of a Multi-Customer TCB

   A formal representation FIFO (e.g., head dropping).

4)   The output of this multi-customer TCB might be:

      TCB1:
      (as defined above)

      TCB2:
      (similar to TCB1, perhaps with different numeric parameters)
      TCB3:
      (similar to TCB1, perhaps with different numeric parameters)

      TCB4:
      (the total TCB)

      Classifier4:
      Output A --> TCB1
      Output B --> TCB2
      Output C --> TCB3
      Output X --> Dropper4

   Where Classifier2 is defined as follows:

      Classifier4:
      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 follows:

      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, Classifier4 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 TCS with queueing block may be the corresponding
   customer.  Those packets with unrecognized source MAC addresses are
   passed to output of a dropper.

   TCB4 has FIFO
     element, a classification stage and an action discarding element stage, which
   consists of either a dropper or another TCB.

8.3 TCBs Supporting Microflow-based Services

   The TCB illustrated above describes a configuration scheduling element.

Note, in particular, that schedulers may operate in series such that might be
   suitable for enforcing a SLS
packet at a router's ingress.  It assumes that
   the customer marks its own traffic for the appropriate service level.
   It then limits head of a FIFO feeding the rate concatenated schedulers is
serviced only after all of aggregate traffic submitted at each
   service level, thereby protecting the resources of the Diffserv
   network.  It does not provide any isolation between 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 customer's
   individual microflows (other than from separated queueing).

   Next we present stream to a TCB configuration that offers additional
   functionality maximum rate, then by
a work-conserving scheduler to mix EF traffic streams with other traffic
streams. Alternatively, there might be a FIFO  and/or a dropper between
the customer.  It recognizes individual customer
   microflows two schedulers.

7.2.  Shaping

Traffic shaping is often used to condition traffic such that packets
arriving in a burst will be "smoothed" and marks each one independently.  It also isolates the
   customer's individual microflows from each other deemed conforming by
subsequent downstream meters in order this or other nodes. Shaping may also be
used to prevent
   a single microflow isolate certain traffic streams from seizing an unfair share of the resources
   available to effects of other
traffic streams of the customer at same BA.

In [DSARCH] a certain service level.  This shaper is
   illustrated in Figure 7 below:

                     +-----+   +-----+
                     |     |   |     |---------------+
                  +->|     |-->|     |     +-----+   |
        +-----+   |  |     |   |     |---->|     |   |
        |     |----  +-----+   +-----+     +-----+   |
      ->|     |----  marker described as a queueing element controlled by a
meter      dropper   |   +-----+ which defines its temporal profile. However, this representation
of a shaper differs substantially from typical shaper implementations.

In this conceptual model, a shaper is realized by using a non-work-
conserving scheduler. Some implementations may elect to
        |     |-+ |  +-----+   +-----+               +-->|     |
        +-----+ | |  |     |   |     |------------------>|     |--->
          MF    | +->|     |-->|     |     +-----+   +-->|     |
        class.  |    |     |   |     |---->|     |   |   +-----+  TCB2
                |    +-----+   +-----+     +-----+   |    mux
                |    marker     meter      dropper   |
                |    +-----+   +-----+               |
                |    |     |   |     |---------------+
                |--->|     |-->|     |     +-----+
                |    |     |   |     |---->|     |
                |    +-----+   +-----+     +-----+
                |    marker     meter      dropper
                |       .         .     .
                V       V         V     V

      Figure 7: An Example of a Marking and Traffic Isolation TCB

   Traffic have queues
whose sole purpose is first directed to a MF classifier which classifies traffic
   based on miscellaneous classification criteria, to a granularity
   sufficient shaping, while others may integrate the shaping
function with other buffering, discarding and scheduling associated with
access 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 resource. Shapers operate by delaying the contribution of each departure of the customer's
   microflows
packets that would be deemed non-conforming by a meter configured to the
shaper's maximum service level for which rate profile. The packet is scheduled to depart
no sooner than such time that it was marked.  Packets
   exceeding the allowable limit for the microflow are dropped. would become conforming.

8.  Traffic Conditioning Blocks (TCBs)

The classifiers, meters, action elements and queueing elements described
above can be combined into traffic conditioning blocks (TCBs). The TCB could
is an abstraction of a functional element that may be formally specified as follows:

      TCB1:
      Classifier1: (MF)
      Output used to facilitate
the definition of specific traffic conditioning functionality.

A --> Marker1
      Output B --> general TCB might consist of the following four stages:
  - Classification stage
  - Metering stage
  - Action stage
  - Queueing stage

where each stage may consist of a set of parallel datapaths consisting
of pipelined elements.

Note that a classifier is a 1:N element, metering and actions are
typically 1:1 elements and queueing is a N:1 element. The whole TCB
should, however, result in a 1:1 abstract element.

TCBs are constructed by connecting elements corresponding to these
stages in any sensible order. It is possible to omit stages, to include
null elements, or to concatenate multiple stages of the same type. TCB
outputs may drive additional TCBs (on either the ingress or egress
interfaces).

8.1.  An Example TCB

A SLS is presumed to have been negotiated between the customer and the
provider which specifies the handling of the customer's traffic by the
provider's network. The agreement might be of the following form:

   DSCP     PHB   Profile     Treatment
   ----     ---   -------     ----------------------
   001001   EF    Profile4    Discard non-conforming.
   001100   AF11  Profile5    Shape to profile, tail-drop when full.
   001101   AF21  Profile3    Re-mark non-conforming to DSCP 001000,
                                 tail-drop when full.
   other    BE    none        Apply RED-like dropping.

This SLS specifies that the customer may submit packets marked for DSCP
001001 which will get EF treatment so long as they remain conforming to
Profile1 and will be discarded if they exceed this profile. The
discarded packets are counted in this example, perhaps for use by the
provider's sales department in convincing the customer to buy a larger
SLS.  Packets marked for DSCP 001100 will be shaped to Profile2 before
forwarding. Packets marked for DSCP 001101 will be metered to Profile3
with non-conforming packets "downgraded" by being re-marked with a DSCP
of 001000.  It is implicit in this agreement that conforming packets are
given the PHB originally indicated by the packets' DSCP field.

Figures 6 and 7 illustrates a TCB that might be used to handle this SLS
at an ingress interface at the customer/provider boundary.

The Classification stage of this example 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 is a wildcard
filter that matches every packet not otherwise matched.

The paths for DSCP 001001 and 001101 then include a metering stage.
There is a separate meter for each set of packets corresponding to
classifier outputs A and C. Each meter uses a specific profile, as
specified in the TCS, for the corresponding Diffserv service level. The
meters in this example each indicate one of two conforming levels,
                          +-----+
                          |    A|---------------------------> to Queue1
                       +->|     |
                       |  |    B|--+  +-----+    +-----+
                       |  +-----+  |  |     |    |     |
                       |  Meter1   +->|     |--->|     |
                       |              |     |    |     |
                       |              +-----+    +-----+
                       |              Counter1   Absolute
 submitted +-----+     |                         Dropper1
 traffic   |    A|-----+
 --------->|    B|----------------------------------------> to Dropper1
           |    C|-----+
           |    X|--+  |
           +-----+  |  |  +-----+                +-----+
         Classifier1|  |  |    A|--------------->|A    |
            (BA)    |  +->|     |                |     |--> to Dropper2
                    |     |    B|--+  +-----+ +->|B    |
                    |     +-----+  |  |     | |  +-----+
                    |     Meter2   +->|     |-+    Mux1
                    |                 |     |
                    |                 +-----+
                    |                 Marker1
                    +-------------------------------------> to Dropper3

      Figure 6:  An Example Traffic Conditioning Block (Part 1)

conforming or non-conforming.

Following the Metering stage is the Action stage in the upper and lower
branches. Packets submitted for DSCP 001001 that are deemed non-
conforming are counted and discarded while packets that are conforming
are passed on to Dropper1/Queue1. Packets submitted for DSCP 001101 that
are deemed non-conforming are re-marked and then conforming and non-
conforming packets are multiplexed together before being passed on to
Dropper2/Queue3. Packets submitted for DSCP 001100 are passed straight
on to Queue2.

The Queueing stage is realised as follows, shown in figure 6.  The
conforming 001001 packets are passed directly to Queue1: there is no
way, with correct configuration of the scheduler for these to overflow
the depth of Queue1 so there is never a requirement for dropping.
Packets marked for 001100 must be passed through a tail-dropper,
Dropper1, which serves to limit the depth of the following queue,
Queue2: packets that arrive to a full queue will be discarded - this is
likely to be an error case: the customer is obviously not sticking to

its agreed profile.  Similarly, packets from the 001101 stream are
passed to Dropper2 and Queue3.  Packets marked for all other DSCPs are
passed to Dropper3 which is a RED-like algorithmic dropper: based on
feedback of the current depth of Queue4, this dropper is likely to
discard enough packets from its input stream to keep the queue depth
under control.

These four queues are then serviced by a scheduling algorithm in
Scheduler1 which has been configured to give each of the queues an
appropriate priority and/or bandwidth share. Inputs A and C are given
guarantees of bandwidth, as appropriate for the contracted profiles.
Input B is given a limit on the bandwidth it can use i.e. a non-work-
conserving discipline in order to achieve the desired shaping of this
stream.  Input D is given no limits or guarantees but a lower priority
than the other queues, appropriate for its best-effort status.  Traffic
then exits the scheduler in a single orderly stream.

    from Meter1                     +-----+
    ------------------------------->|     |----+
                                    |     |    |
                                    +-----+    |
                                    Queue1     |
                                               |  +-----+
    from Classifier1 +-----+        +-----+    +->|A    |
    ---------------->|     |------->|     |------>|B    |------->
                     |     |        |     |  +--->|C    |  exiting
                     +-----+        +-----+  | +->|D    |  traffic
                     Dropper1       Queue2   | |  +-----+
                                             | |  Scheduler1
    from Mux1        +-----+        +-----+  | |
    ---------------->|     |------->|     |--+ |
                     |     |        |     |    |
                     +-----+        +-----+    |
                     Dropper2       Queue3     |
                                               |
    from Classifier1 +-----+        +-----+    |
    ---------------->|     |------->|     |----+
                     |     |        |     |
                     +-----+        +-----+
                     Dropper3       Queue4

      Figure 7: An Example Traffic Conditioning Block (Part 2)

The interconnections of the TCB elements illustrated in Figures 6 and 7
can be represented as follows:

      TCB1:

      Classifier1:
      FilterA:             Meter1
      FilterB:             Dropper1
      FilterC:             Meter2
      Default:             Dropper3

      Meter1:
      Type:                AverageRate
      Profile:             Profile1
      ConformingOutput:    Queue1
      NonConformingOutput: Counter1

      Counter1:
      Output:              AbsoluteDropper1

      Meter2:
      Type:                AverageRate
      Profile:             Profile3
      ConformingOutput:    Mux1.InputA
      NonConformingOutput: Marker1

      Marker1:
      Type:                DSCPMarker
      Mark:                001000
      Output:              Mux1.InputB

      Mux1:
      Output:              Dropper2

      Dropper1:
      Type:                AlgorithmicDropper
      Discipline:          Drop-on-threshold
      Trigger:             Queue2.Depth > 10kbyte
      Output:              Queue2

      Dropper2:
      Type:                AlgorithmicDropper
      Discipline:          Drop-on-threshold
      Trigger:             Queue3.Depth > 20kbyte
      Output:              Queue3

      Dropper3:

      Type:                AlgorithmicDropper
      Discipline:          RED93
      Trigger:             Internal
      Output:              Queue3
      MinThresh:           Queue3.Depth > 20 kbyte
      MaxThresh:           Queue3.Depth > 40 kbyte
         <other RED parms too>

      Queue1:
      Type:                FIFO
      Output:              Scheduler1.InputA

      Queue2:
      Type:                FIFO
      Output:              Scheduler1.InputB

      Queue3:
      Type:                FIFO
      Output:              Scheduler1.InputC

      Queue4:
      Type:                FIFO
      Output:              Scheduler1.InputD

      Scheduler1:
      Type:                Scheduler4Input
      InputA:
      MaxRateProfile:      none
      MinRateProfile:      Profile4
      Priority:            20
      InputB:
      MaxRateProfile:      Profile5
      MinRateProfile:      none
      Priority:            40
      InputC:
      MaxRateProfile:      none
      MinRateProfile:      Profile3
      Priority:            20
      InputD:
      MaxRateProfile:      none
      MinRateProfile:      none
      Priority:            10

8.2.  An Example TCB to Support Multiple Customers

The TCB described above can be installed on an ingress interface to
implement a provider/customer TCS 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 only BA classifiers.

The TCB is readily extended to support the case of multiple customers
per interface, as follows. First, a TCB is defined for each customer to
reflect the TCS with that customer: TCB1, defined above is the TCB for
customer 1 and definitions are then added for TCB2 and for TCB3 which
reflect the agreements with customers 2 and 3 respectively.

Finally, a classifier is added to the front end to separate the traffic
from the three different customers. This forms a new TCB, TCB4, which
incorporates TCB1, TCB2, and TCB3 and is illustrated in Figure 8.

A formal representation of this multi-customer TCB might be:

      TCB4:

      Classifier4:
      Filter1:     to TCB1
      Filter2:     to TCB2
      Filter3:     to TCB3
      No Match:    AbsoluteDropper4

      TCB1:
      (as defined above)

      TCB2:

      submitted +-----+
      traffic   |    A|--------> TCB1
            --->|    B|--------> TCB2
                |    C|--------> TCB3
                |    X|--------> AbsoluteDropper4
                +-----+
                Classifier4

      Figure 8: An Example of a Multi-Customer TCB
      (similar to TCB1, perhaps with different numeric parameters)

      TCB3:
      (similar to TCB1, perhaps with different numeric parameters)

      TCB4:
      (the total TCB)

and the filters, based on each customer's source MAC address, could be
defined as follows:

      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, Classifier4 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 TCS with the corresponding customer. Those packets with
unrecognized source MAC addresses are passed to a dropper.

TCB4 has a Classifier stage and an Action element stage, which consists
of either a dropper or another TCB.

8.3.  TCBs Supporting Microflow-based Services

The TCB illustrated above describes a configuration that might be
suitable for enforcing a SLS at a router's ingress. It assumes that the
customer marks its own traffic for the appropriate service level.  It
then limits the rate of aggregate traffic submitted at each service
level, thereby protecting the resources of the Diffserv network. It does
not provide any isolation between the customer's individual microflows.

A more complex example might be a TCB 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 9.

Suppose that the customer has an SLS which specifices 2 service levels,
to be identifed to the provider by DSCP A and DSCP B.  Traffic is first
directed to a MF classifier which classifies traffic based on
miscellaneous classification criteria, to a granularity sufficient to
identify individual customer microflows. Each microflow can then be
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
was marked. Packets exceeding the allowable limit for the microflow are
dropped.

This TCB could be formally specified as follows:

                     +-----+   +-----+
    Classifier1      |     |   |     |---------------+
        (MF)      +->|     |-->|     |     +-----+   |
      +-----+     |  |     |   |     |---->|     |   |
      |    A|------  +-----+   +-----+     +-----+   |
  --->|    B|-----+  Marker1   Meter1      Absolute  |
      |    C|---+ |                        Dropper1  |   +-----+
      |    X|-+ | |  +-----+   +-----+               +-->|A    |
      +-----+ | | |  |     |   |     |------------------>|B    |--->
              | | +->|     |-->|     |     +-----+   +-->|C    | to TCB2
              | |    |     |   |     |---->|     |   |   +-----+
              | |    +-----+   +-----+     +-----+   |    Mux1
              | |    Marker2
      Output C -->   Meter2      Absolute  |
              | |                          Dropper2  |
              | |    +-----+   +-----+               |
              | |    |     |   |     |---------------+
              | |--->|     |-->|     |     +-----+
              |      |     |   |     |---->|     |
              |      +-----+   +-----+     +-----+
              |      Marker3
      . . .   Meter3      Absolute
              |                            Dropper3
              V etc.

      Figure 9: An Example of a Marking and Traffic Isolation TCB
      TCB1:
      Classifier1: (MF)
      FilterA:             Marker1 --> Meter1
      FilterB:             Marker2 --> Meter2
      FilterC:             Marker3 -->
      etc.

      Marker1:
      Output:              Meter1

      Marker2:
      Output:              Meter2

      Marker3:
      Output:              Meter3

      Meter1:
      Output A --> TCB2
      Output B --> ActionElement1 (dropper)
      ConformingOutput:    Mux1.InputA
      NonConformingOutput: AbsoluteDropper1

      Meter2:
      Output A --> TCB2
      Output B --> ActionElement2 (dropper)
      ConformingOutput:    Mux1.InputB
      NonConformingOutput: AbsoluteDropper2

      Meter3:
      Output A -->
      ConformingOutput:    Mux1.InputC
      NonConformingOutput: AbsoluteDropper3

      etc.

      Mux1:
      Output:              to TCB2
      Output B --> ActionElement3 (dropper)

   The actual

Note that the detailed 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, TCB2 which is illustrated below: in
Figure 10.

TCB2 could then be specified as follows:

      Classifier2: (BA)
      FilterA:               Meter5
      FilterB:               Meter6

      Meter5:
      ConformingOutput:      Queue1
                     +-----+
                     |     |---------------> to Queue1
                  +->|     |     +-----+
        +-----+   |  |     |---->|     |
        |     |---+    A|---+  +-----+     +-----+
      ->|     |       meter      dropper       Meter5     AbsoluteDropper4
        |     |---+    B|---+  +-----+
        +-----+   |  |     |--------------->
          BA to Queue2
      Classifier2 +->|     |     +-----+
        classifier   |     |---->|     |
                     +-----+     +-----+
                      meter      dropper

      Figure 8: Additional Example TCB

   TCB2 would be formally specified as follows:

      Classifier2:
         (BA)
      Output A --> Meter10
      Output B --> Meter11
      Meter10:
      Output A --> PHBQueueA
      Output B --> Dropper10

      Meter11:
      Output A --> PHBQueueB
      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

  o  There is a difference in interpretation of token bucket behavior
     between this document (Appendix A) and [DSMIB].  Specifically,
     [DSMIB] allows a packet to conform if any smaller packet would
     conform.

  o  The meter in [SRTCM] cannot be precisely modeled using two
     two-parameter token buckets because its two buckets do not
     accumulate credits independently.  We intended to demonstrate how
     the [TRTCM] meter could be implemented but ran out of time.

  o  Are the queue parameters (scheduling and buffer management)
     parameters defined sufficient?

  o  Does Queue and Queue Set really belong        |     |---->|     |
                     +-----+     +-----+
                      Meter6     AbsoluteDropper5

      Figure 10: Additional Example: TCB2

      NonConformingOutput:   AbsoluteDropper4

      Meter6:
      ConformingOutput:      Queue2
      NonConformingOutput:   AbsoluteDropper5

8.4.  Cascaded TCBs

Nothing in the this model (and prevents more complex scenarios in which one
microflow TCB precedes another (e.g. for TCBs implementing separate TCSs
for the MIB source and PIB?), or should the model stick for a set of destinations).

9.  Open Issues

<ed: this section to the abstract PHB
     representation be deleted before WG last call and leave the implementation details RFC publication.
The current stance of this draft is supplied in parentheses.

(1)  FIFOs are modelled here as having infinite depth: it is up to the MIB and
     PIB?

  o  Should any
     preceding meter/dropper to make sure that they do not overflow - a classifier
     hard stop on the depth would be part of a TCB? modelled, for example, by preceding
     the FIFO with an Absolute Dropper. Is this appropriate? (Yes)

(2)  We argue yes.  This allows a
     TCB must allow algorithmic droppers that apply different dropping
     behaviour to be a one input/one output black box element.

  o  Is packets with different classifier matches, with these
     possibly fed through different meters and actions. Should we model
     the description of dropper as a shaper sufficient?  Is it overbroad? single input element with implicit pointers back
     to the matching classifier that selects different dropper
     algorithms/treatments? Or as multiple droppers? Or as having
     multiple logical inputs? (single input, implicit pointers).

10.  Security Considerations

Security vulnerabilities of Diffserv network operation are discussed in
[DSARCH]. This document describes an abstract functional model of
Diffserv router elements. Certain denial-of-service attacks such as
those resulting from resource starvation may be mitigated mitigated by appropriate
configuration of these router elements; for example, by rate limiting
certain traffic streams or by authenticating traffic marked for higher
quality-of-service.

One particular theft- or denial-of-service issue may arise where a
token-bucket meter, with an absolute dropper for non-conforming traffic,
is used in a TCB to police a stream to a given TCS: the definition of
the token-bucket meter in section 5 indicates that it should be lenient
in accepting a packet whenever any bits of the packet would have been
within the profile; the definition of the leaky-bucket scheduler is
conservative in that a packet is to be transmitted only if the whole
packet fits within the profile. This difference may be exploited by
   appropriate configuration of these router elements; a
malicious scheduler either to obtain QoS treatment for example, by
   rate limiting certain traffic streams more octets than
allowed in the TCS or by authenticating to disrupt (perhaps only slightly) the QoS
guarantees promised to other traffic
   marked for higher quality-of-service. streams.

11.  Acknowledgments

Concepts, terminology, and text have been borrowed liberally from
[POLTERM], [DSMIB] and [PIB]. [DSPIB].  We wish to thank the authors: authors of those
documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson,
Kwok Chan, Chan and Scott Hahn, Hahn for their permission. contributions.

This document has benefitted from the comments and suggestions of
several participants of the Diffserv working group.

12.  References

[AF-PHB]
     J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured
     Forwarding PHB Group", RFC 2597, June 1999.

[DSARCH]
     M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies,
     "An Architecture for Differentiated Services", RFC 2475, December
     1998

[DSFIELD]
     K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the
     Differentiated Services Field (DS Field) in the IPv4 and IPv6
     Headers", RFC 2474, December 1998.

[DSMIB]
     F. Baker, A. Smith, K. Chan, "Differentiated Services MIB",
     Internet Draft <draft-ietf-diffserv-mib-03.txt>, May 2000.

[DSPIB]
     M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, and A.
     Smith, "Quality of Service Policy Information Base", Internet Draft
     <draft-ietf-diffserv-pib-00.txt>, March 2000.

[DSTERMS]
     D. Grossman, "New Terminology for Diffserv", Internet Draft <draft-ietf-diffserv-new-terms-00.txt>, October <draft-
     ietf-diffserv-new-terms-02.txt>, November 1999.

[E2E]
     Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K.
     Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine,
     "Integrated Services Operation over Diffserv Networks", Internet
     Draft
              <draft-ietf-issll-diffserv-rsvp-02.txt>, September 1999.

   [DSFIELD]  K. Nichols, S. Blake, F. Baker, and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998. <draft-ietf-issll-diffserv-rsvp-04.txt>, March 2000.

[EF-PHB]
     V. Jacobson,  K. Nichols, and K. Poduri, "An Expedited Forwarding
     PHB", RFC 2598, June 1999.

   [AF-PHB]

[GTC]
     L. Lin, J. Heinanen, F. Baker, W. Weiss, Lo, and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [DSMIB] F. Baker, "Differentiated Services MIB", Ou, "A Generic Traffic Conditioner", Internet
     Draft
              <draft-ietf-diffserv-mib-00.txt>, June <draft-lin-diffserv-gtc-01.txt>, August 1999.

   [SRTCM]    J. Heinanen, and

[INTSERV]
     R. Guerin, "A Single Rate Three Color
              Marker", Braden, D. Clark and S. Shenker, "Integrated Services in the
     Internet Architecture: an Overview" RFC 2697, September 1999.

   [PIB] 1633, June 1994.

[POLTERM]
     F. Reichmeyer,  D. Grossman, J. Strassner, M. Fine, K. McCloghrie, Condell, "A Common
     Terminology for Policy Management", Internet Draft <draft-

[QOSDEVMOD]
     J. Seligson, K. Chan, S. Hahn,
              and Strassner, W. Weiss, D. Durham, A. Smith, "Quality of Service Policy Information
              Base", Westerinen, "Information
     Model for Describing Network Device QoS Mechanisms", Internet Draft <draft-mfine-cops-pib-01.txt>,
              June

[SRTCM]
     J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC
     2697, September 1999.

[TRTCM]
     J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698,
     September 1999.

   [GTC]      L. Lin, J. Lo,

13.  Authors' 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
   920 Main Campus Drive, Suite 500
   Raleigh, NC  27606
   Phone:  +1 919 472 9913
   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

Table of Contents

1 Introduction ....................................................    2
2 Glossary ........................................................    3
3 Conceptual Model ................................................    5
3.1 Elements of a Diffserv Router .................................    5
3.1.1 Datapath ....................................................    5
3.1.2 Configuration and F. Ou, "A Generic Management Interface ......................    6
3.1.3 Optional QoS Agent Module ...................................    7
3.2 Hierarchical Model of Diffserv Components .....................    7

4 Classifiers .....................................................   10
4.1 Definition ....................................................   10
4.1.1 Filters .....................................................   11
4.1.2 Overlapping Filters .........................................   11
4.2 Examples ......................................................   12
4.2.1 Behaviour Aggregate (BA) Classifier .........................   12
4.2.2 Multi-Field (MF) Classifier .................................   13
4.2.3 Free-form Classifier ........................................   13
4.2.4 Other Possible Classifiers ..................................   14
5 Meters ..........................................................   14
5.1 Examples ......................................................   17
5.1.1 Average Rate Meter ..........................................   17
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............   18
5.1.3 Two-Parameter Token Bucket Meter ............................   19
5.1.4 Multi-Stage Token Bucket Meter ..............................   19
5.1.5 Null Meter ..................................................   20
6 Action Elements .................................................   20
6.1 Marker ........................................................   21
6.2 Absolute Dropper ..............................................   21
6.3 Multiplexer ...................................................   22
6.4 Counter .......................................................   22
6.5 Null Action ...................................................   22
7 Queueing Blocks .................................................   22
7.1 Queueing Model ................................................   23
7.1.1 FIFO ........................................................   23
7.1.2 Scheduler ...................................................   25
7.1.3 Algorithmic Dropper .........................................   27
7.1.4 Constructing queueing blocks from the elements ..............   30
7.2 Shaping .......................................................   31
8 Traffic Conditioner",
              Internet Draft <draft-lin-diffserv-gtc-01.txt>, August
              1999.

   [MPLSDS]   J. Heinanen, "Differentiated Conditioning Blocks (TCBs) ..............................   31
8.1 An Example TCB ................................................   32
8.2 An Example TCB to Support Multiple Customers ..................   37
8.3 TCBs Supporting Microflow-based Services in MPLS Networks", ......................   38
8.4 Cascaded TCBs .................................................   41
9 Open Issues .....................................................   41
10 Security Considerations ........................................   42
11 Acknowledgments ................................................   42
12 References .....................................................   42
13 Authors' Addresses .............................................   44

14.  Full Copyright

   Copyright (C) The Internet Draft <draft-heinanen-diffserv-mpls-00.txt>,
              June 1999.

Appendix A.  Simple Token Bucket Definition

  [DSMIB] presents a fairly detailed exposition on the operation Society (2000). All Rights Reserved.

   This document and translations of
  two-parameter token buckets for metering.  However, the behavior
  described does not appear to it may be consistent with the behavior defined
  in [SRTCM] copied and [TRTCM].  Specifically, under the definition in
  [DSMIB], a packet is assumed to conform furnished to the meter if any of its
  bytes would have been accepted, while in [SRTCM]
   others, and [TRTCM], a packet
  is assumed to conform only if sufficient tokens are available for
  every byte in the packet.  Further, a packet has no effect derivative works that comment on the
  token occupancy if or otherwise explain it does not conform (no tokens are decremented).

  The behavior defined
   or assist in [SRTCM] and [TRTCM] is not mandatory for
  compliance, but we give here a mathematical definition of two-
  parameter token bucket operation which is consistent with these
  documents, and which can be used to define a shaping profile.

  Define a token bucket with bucket size BS, token accumulation rate
  R, and instantaneous token occupancy T(t).  Assume that T(0) = BS.

  Then after an arbitrary interval with no packet arrivals, T(t) will
  not change since the bucket is already full of tokens.  Assume a
  packet of size B bytes at time t'.  The bucket capacity T(t'-) = BS
  still.  Then, as long as B <= BS, the packet conforms to the meter, its implmentation may be prepared, copied, published and

     T(t') = BS - B.

  Assume an interval v = t - t' elapses before the next packet,
   distributed, in whole or in part, without restriction of
  size C <= BS, arrives.  T(t-) is given by any kind,
   provided that the following equation:

     T(t-) = min { BS, T(t') + v*R }

  (the packet has accumulated v*R tokens over above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the interval, up copyright notice or references to a
  maximum the Internet Society or other
   Internet organizations, except as needed for the purpose of BS tokens).

  If T(t-) - C >= 0,
   developing Internet standards in which case the packet conforms and T(t) = T(t-) - C.
  Otherwise, procedures for
   copyrights defined in the packet does not conform and T(t) = T(t-).

  This function can Internet Standards process must be used
   followed, or as required to define a shaping profile.  If a packet of
  size C arrives at time t, translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be eligible for transmission at time
  te given as follows (we still assume C <= BS):

     te = max { t, t" }

  where

     t" = (C - T(t') + t'*R)/R.

  T(t") = C, the time when C credits have accumulated in
   revoked by the bucket, Internet Society or its successors or assigns.

   This document and when the packet would conform if the token bucket were a meter.
  te != t" only if t > t".

Authors' 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
   920 Main Campus Drive, Suite 500
   Raleigh, NC  27606
   Phone:  +1 919 472 9913
   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 information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.