tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3290

Informational
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DIFFSERV

An Informal Management Model for Diffserv Routers

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          Y. Bernet
Request for Comments: 3290                                     Microsoft
Category: Informational                                         S. Blake
                                                                Ericsson
                                                             D. Grossman
                                                                Motorola
                                                                A. Smith
                                                        Harbour Networks
                                                                May 2002


           An Informal Management Model for Diffserv Routers

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document proposes an informal management model of Differentiated
   Services (Diffserv) routers for use in their management and
   configuration.  This model defines functional datapath elements
   (e.g., classifiers, meters, actions, marking, absolute dropping,
   counting, multiplexing), algorithmic droppers, queues and schedulers.
   It describes possible configuration parameters for these elements and
   how they might be interconnected to realize the range of traffic
   conditioning and per-hop behavior (PHB) functionalities described in
   the Diffserv Architecture.

Table of Contents

   1 Introduction .................................................    3
   2 Glossary .....................................................    4
   3 Conceptual Model .............................................    7
   3.1 Components of a Diffserv Router ............................    7
   3.1.1 Datapath .................................................    7
   3.1.2 Configuration and Management Interface ...................    9
   3.1.3 Optional QoS Agent Module ................................   10
   3.2 Diffserv Functions at Ingress and Egress ...................   10
   3.3 Shaping and Policing .......................................   12
   3.4 Hierarchical View of the Model .............................   12
   4 Classifiers ..................................................   13

Top      ToC       Page 2 
   4.1 Definition .................................................   13
   4.1.1 Filters ..................................................   15
   4.1.2 Overlapping Filters ......................................   15
   4.2 Examples ...................................................   16
   4.2.1 Behavior Aggregate (BA) Classifier .......................   16
   4.2.2 Multi-Field (MF) Classifier ..............................   17
   4.2.3 Free-form Classifier .....................................   17
   4.2.4 Other Possible Classifiers ...............................   18
   5 Meters .......................................................   19
   5.1 Examples ...................................................   20
   5.1.1 Average Rate Meter .......................................   20
   5.1.2 Exponential Weighted Moving Average (EWMA) Meter .........   21
   5.1.3 Two-Parameter Token Bucket Meter .........................   21
   5.1.4 Multi-Stage Token Bucket Meter ...........................   22
   5.1.5 Null Meter ...............................................   23
   6 Action Elements ..............................................   23
   6.1 DSCP Marker ................................................   24
   6.2 Absolute Dropper ...........................................   24
   6.3 Multiplexor ................................................   25
   6.4 Counter ....................................................   25
   6.5 Null Action ................................................   25
   7 Queuing Elements .............................................   25
   7.1 Queuing Model ..............................................   26
   7.1.1 FIFO Queue ...............................................   27
   7.1.2 Scheduler ................................................   28
   7.1.3 Algorithmic Dropper ......................................   30
   7.2 Sharing load among traffic streams using queuing ...........   33
   7.2.1 Load Sharing .............................................   34
   7.2.2 Traffic Priority .........................................   35
   8 Traffic Conditioning Blocks (TCBs) ...........................   35
   8.1 TCB ........................................................   36
   8.1.1 Building blocks for Queuing ..............................   37
   8.2 An Example TCB .............................................   37
   8.3 An Example TCB to Support Multiple Customers ...............   42
   8.4 TCBs Supporting Microflow-based Services ...................   44
   8.5 Cascaded TCBs ..............................................   47
   9 Security Considerations ......................................   47
   10 Acknowledgments .............................................   47
   11 References ..................................................   47
   Appendix A. Discussion of Token Buckets and Leaky Buckets ......   50
   Authors' Addresses .............................................   55
   Full Copyright Statement........................................   56

Top      ToC       Page 3 
1.  Introduction

   Differentiated Services (Diffserv) [DSARCH] is a set of technologies
   which allow network service providers to offer services with
   different kinds of network quality-of-service (QoS) objectives to
   different customers and their traffic streams.  This document uses
   terminology defined in [DSARCH] and [NEWTERMS] (some of these
   definitions are included here in Section 2 for completeness).

   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].  The DSCP markings are applied either by a trusted
   upstream node, e.g., a customer, or by the edge routers on entry to
   the Diffserv network.

   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 - see [NEWTERMS]).  Whilst further
   discussion of such services is outside the scope of this document
   (see [PDBDEF]), 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 document 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.  It is expected
   that router implementers will demonstrate a great deal of variability
   in their implementations.  To the extent that implementers are able

Top      ToC       Page 4 
   to model their implementations using the abstractions described in
   this document, configuration and management tools will more readily
   be able to configure and manage networks incorporating Diffserv
   routers of assorted origins.

   This model is intended to be abstract and capable of representing the
   configuration parameters important to Diffserv functionality for a
   variety of specific router implementations.  It is not intended as a
   guide to system implementation nor as a formal modeling description.
   This model serves as the rationale for the design of an SNMP MIB
   [DSMIB] and for other configuration interfaces (e.g., other policy-
   management protocols) and, possibly, more detailed formal models
   (e.g., [QOSDEVMOD]): these should all be consistent with this model.

   o  Section 3 starts by describing the basic high-level blocks of a
      Diffserv router.  It explains the concepts used in the model,
      including the hierarchical management model for these blocks which
      uses low-level functional datapath elements such as Classifiers,
      Actions, Queues.

   o  Section 4 describes Classifier elements.

   o  Section 5 discusses Meter elements.

   o  Section 6 discusses Action elements.

   o  Section 7 discusses the basic queuing elements of Algorithmic
      Droppers, Queues, and Schedulers and their functional behaviors
      (e.g., traffic shaping).

   o  Section 8 shows how the low-level elements can be combined to
      build modules called Traffic Conditioning Blocks (TCBs) which are
      useful for management purposes.

   o  Section 9 discusses security concerns.

   o  Appendix A contains a brief discussion of the token bucket and
      leaky bucket algorithms used in this model and some of the
      practical effects of the use of token buckets within the Diffserv
      architecture.

2.  Glossary

   This document uses terminology which is defined in [DSARCH].  There
   is also current work-in-progress on this terminology in the IETF and
   some of the definitions provided here are taken from that work.  Some

Top      ToC       Page 5 
   of the terms from these other references are defined again here in
   order to provide additional detail, along with some new terms
   specific to this document.

   Absolute      A functional datapath element which simply discards all
   Dropper       packets arriving at its input.

   Algorithmic   A functional datapath element which selectively
   Dropper       discards packets that arrive at its input, based on a
                 discarding algorithm.  It has one data input and one
                 output.

   Classifier    A functional datapath element which consists of filters
                 that select matching and non-matching packets.  Based
                 on this selection, packets are forwarded along the
                 appropriate datapath within the router.  A classifier,
                 therefore, splits a single incoming traffic stream into
                 multiple outgoing streams.

   Counter       A functional datapath element which updates a packet
                 counter and also an octet counter for every
                 packet that passes through it.

   Datapath      A conceptual path taken by packets with particular
                 characteristics through a Diffserv router.  Decisions
                 as to the path taken by a packet are made by functional
                 datapath elements such as Classifiers and Meters.

   Filter        A set of wildcard, prefix, masked, range and/or exact
                 match conditions on the content of a packet's
                 headers or other data, and/or on implicit or derived
                 attributes associated with the packet.  A filter is
                 said to match only if each condition is satisfied.

   Functional    A basic building block of the conceptual router.
   Datapath      Typical elements are Classifiers, Meters, Actions,
   Element       Algorithmic Droppers, Queues and Schedulers.

   Multiplexer   A multiplexor.
   (Mux)

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

Top      ToC       Page 6 
   Non-work-     A property of a scheduling algorithm such that it
   conserving    services packets no sooner than a scheduled departure
                 time, even if this means leaving packets queued
                 while the output (e.g., a network link or connection
                 to the next element) is idle.

   Policing      The process of comparing the arrival of data packets
                 against a temporal profile and forwarding, delaying
                 or dropping them so as to make the output stream
                 conformant to the profile.

   Queuing       A combination of functional datapath elements
   Block         that modulates the transmission of packets belonging
                 to a traffic streams and determines their
                 ordering, possibly storing them temporarily or
                 discarding them.

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

   Service-Level A set of parameters and their values which together
   Specification define the treatment offered to a traffic stream by a
   (SLS)         Diffserv domain.

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

   Traffic       A logical datapath entity consisting of a number of
   Conditioning  functional datapath elements interconnected in
   Block (TCB)   such a way as to perform a specific set of traffic
                 conditioning functions on an incoming traffic stream.
                 A TCB can be thought of as an entity with one
                 input and one or more outputs and a set of control
                 parameters.

   Traffic       A set of parameters and their values which together
   Conditioning  specify a set of classifier rules and a traffic
   Specification profile.  A TCS is an integral element of a SLS.
   (TCS)

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

3.  Conceptual Model

   This section introduces a block diagram of a Diffserv router and
   describes the various components illustrated in Figure 1.  Note that
   a Diffserv core router is likely to require only a subset of these
   components: the model presented here is intended to cover the case of
   both Diffserv edge and core routers.

3.1.  Components of a Diffserv Router

   The conceptual model includes abstract definitions for the following:

      o  Traffic Classification elements.

      o  Metering functions.

      o  Actions of Marking, Absolute Dropping, Counting, and
         Multiplexing.

      o  Queuing elements, including capabilities of algorithmic
         dropping and scheduling.

      o  Certain combinations of the above functional datapath elements
         into higher-level blocks known as Traffic Conditioning Blocks
         (TCBs).

   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 queuing
   behaviors that any particular packet will experience when forwarded
   to the Diffserv router.  Figure 1 illustrates the major functional
   blocks of a Diffserv router.

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

Top      ToC       Page 8 
   and switching functionality.  The routing core moves packets between
   interfaces according to policies outside the scope of Diffserv (note:
   it is possible that such policies for output-interface selection
   might involve use of packet fields such as the DSCP but this is
   outside the scope of this model).  The actual queuing delay and
   packet loss behavior of a specific router's switching
   fabric/backplane is not modeled by the routing core; these should be
   modeled using the functional datapath elements described later.  The
   routing core of this model can be thought of as an infinite
   bandwidth, zero-delay interconnect between interfaces - properties
   like the behavior of the core when overloaded need to be reflected
   back into the queuing elements that are modeled around it (e.g., when
   too much traffic is directed across the core at an egress interface),
   the excess must either be dropped or queued somewhere: the elements
   performing these functions must be modeled on one of the interfaces
   involved.

   The components of interest at the ingress to and egress from
   interfaces are the functional datapath elements (e.g., Classifiers,
   Queuing elements) that support Diffserv traffic conditioning and
   per-hop behaviors [DSARCH].  These are the fundamental components
   comprising a Diffserv router and are the focal point of this model.

Top      ToC       Page 9 
               +---------------+
               | 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,    |
           |   |  queuing    |                 |  queuing    |
           |   +-------------+                 +-------------+
           |        ^                             ^
           |        |                             |
           |        |                             |
           |   +------------+                     |
           +-->| QOS agent  |                     |
      -------->| (optional) |---------------------+
        QOS    |(e.g., RSVP)|
        cntl   +------------+
        msgs

           Figure 1:  Diffserv Router Major Functional Blocks

3.1.2.  Configuration and Management Interface

   Diffserv operating parameters are monitored and provisioned through
   this interface.  Monitored parameters include statistics regarding
   traffic carried at various Diffserv service levels.  These statistics
   may be important for accounting purposes and/or for tracking
   compliance to Traffic Conditioning Specifications (TCSs) negotiated
   with customers.  Provisioned parameters are primarily the TCS
   parameters for Classifiers and Meters and the associated PHB
   configuration parameters for Actions and Queuing elements.  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 rules and goals governing the Diffserv behavior of a
   router are presumed to be installed by policy management mechanisms.
   However, Diffserv routers are always subject to implementation limits

Top      ToC       Page 10 
   which scope the kinds of policies which can be successfully
   implemented by the router.  External reporting of such implementation
   capabilities is considered out of scope for this document.

3.1.3.  Optional QoS Agent Module

   Diffserv routers may snoop or participate in either per-microflow or
   per-flow-aggregate signaling of QoS requirements [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 multi-field
   (MF) classifier [DSARCH].  Note that the conceptual model of such a
   router implements the Integrated Services Model as described in
   [INTSERV], applying the control plane controls to the data classified
   and conditioned in the data plane, as described in [E2E].

   Note that a QoS Agent component of a Diffserv router, if present,
   might be active only in the control plane and not in the data plane.
   In this scenario, RSVP could be used merely to signal reservation
   state without installing any actual reservations in the data plane of
   the Diffserv router: the data plane could still act purely on
   Diffserv DSCPs and provide PHBs for handling data traffic without the
   normal per-microflow handling expected to support some Intserv
   services.

3.2.  Diffserv Functions at Ingress and Egress

   This document focuses on the Diffserv-specific components of the
   router.  Figure 2 shows a high-level view of ingress and egress
   interfaces of a router.  The diagram illustrates two Diffserv router
   interfaces, each having a set of ingress and a set of egress
   elements.  It shows classification, metering, action and queuing
   functions which might be instantiated at each interface's ingress and
   egress.

   The simple diagram of Figure 2 assumes that the set of Diffserv
   functions to be carried out on traffic on a given interface are
   independent of those functions on all other interfaces.  There are
   some architectures where Diffserv functions may be shared amongst
   multiple interfaces (e.g., processor and buffering resources that
   handle multiple interfaces on the same line card before forwarding
   across a routing core).  The model presented in this document may be
   easily extended to handle such cases; however, this topic is not

Top      ToC       Page 11 
   treated further here as it leads to excessive complexity in the
   explanation of the concepts.

            Interface A                        Interface B
          +-------------+     +---------+     +-------------+
          | ingress:    |     |         |     | egress:     |
          |   classify, |     |         |     |   classify, |
      --->|   meter,    |---->|         |---->|   meter,    |--->
          |   action,   |     |         |     |   action,   |
          |   queuing   |     | routing |     |   queuing   |
          +-------------+     |  core   |     +-------------+
          | egress:     |     |         |     | ingress:    |
          |   classify, |     |         |     |   classify, |
      <---|   meter,    |<----|         |<----|   meter,    |<---
          |   action,   |     |         |     |   action,   |
          |   queuing   |     +---------+     |   queuing   |
          +-------------+                     +-------------+

          Figure 2. Traffic Conditioning and Queuing Elements

   In principle, if one were to construct a network entirely out of
   two-port routers (connected by LANs or similar media), then it might
   be necessary for each router to perform four QoS control functions in
   the datapath on traffic in each direction:

   -  Classify each message according to some set of rules, possibly
      just a "match everything" rule.

   -  If necessary, determine whether the data stream the message is
      part of is within or outside its rate by metering the stream.

   -  Perform a set of resulting actions, including applying a drop
      policy appropriate to the classification and queue in question and
      perhaps additionally marking the traffic with a Differentiated
      Services Code Point (DSCP) [DSFIELD].

   -  Enqueue the traffic for output in the appropriate queue.  The
      scheduling of output from this queue may lead to shaping of the
      traffic or may simply cause it to be forwarded with some minimum
      rate or maximum latency assurance.

   If the network is now built out of N-port routers, the expected
   behavior of the network should be identical.  Therefore, this model
   must provide for essentially the same set of functions at the ingress
   as on the egress of a router's interfaces.  The one point of
   difference in the model between ingress and the egress is that all
   traffic at the egress of an interface is queued, while traffic at the
   ingress to an interface is likely to be queued only for shaping

Top      ToC       Page 12 
   purposes, if at all.  Therefore, equivalent functional datapath
   elements may be modeled at both the ingress to and egress from an
   interface.

   Note that it is not mandatory that each of these functional datapath
   elements be implemented at both ingress and egress; equally, the
   model allows that multiple sets of these elements may be placed in
   series and/or in parallel at ingress or at egress.  The arrangement
   of elements is dependent on the service requirements on a particular
   interface on a particular router.  By modeling these elements at both
   ingress and egress, it is not implied that they must be implemented
   in this way in a specific router.  For example, a router may
   implement all shaping and PHB queuing at the interface egress or may
   instead implement it only at the ingress.  Furthermore, the
   classification needed to map a packet to an egress queue (if present)
   need not be implemented at the egress but instead might be
   implemented at the ingress, with the packet passed through the
   routing core with in-band control information to allow for egress
   queue selection.

   Specifically, some interfaces will be at the outer "edge" and some
   will be towards the "core" of the Diffserv domain.  It is to be
   expected (from the general principles guiding the motivation of
   Diffserv) that "edge" interfaces, or at least the routers that
   contain them, will implement more complexity and require more
   configuration than those in the core although this is obviously not a
   requirement.

3.3.  Shaping and Policing

   Diffserv nodes may apply shaping, policing and/or marking to traffic
   streams that exceed the bounds of their TCS in order to prevent one
   traffic stream from seizing more than its share of resources from a
   Diffserv network.  In this model, Shaping, sometimes considered as a
   TC action, is treated as a function of queuing elements - see section
   7.  Algorithmic Dropping techniques (e.g., RED) are similarly treated
   since they are often closely associated with queues.  Policing is
   modeled as either a concatenation of a Meter with an Absolute Dropper
   or as a concatenation of an Algorithmic Dropper with a Scheduler.
   These elements will discard packets which exceed the TCS.

3.4.  Hierarchical View of the Model

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

Top      ToC       Page 13 
      At the lowest level considered here, there are individual
      functional datapath elements, each with their own configuration
      parameters and management counters and flags.

      At the next level, the network administrator manages groupings of
      these functional datapath elements interconnected in a DAG.  These
      functional datapath elements are organized in self-contained TCBs
      which are used to implement some desired network policy (see
      Section 8).  One or more TCBs may be instantiated at each
      interface's ingress or egress; they may be connected in series
      and/or in parallel configurations on the multiple outputs of a
      preceding TCB.  A TCB can be thought of as a "black box" with one
      input and one or more outputs (in the data path).  Each interface
      may have a different TCB configuration and each direction (ingress
      or egress) may too.

      At the topmost level considered here, the network administrator
      manages interfaces.  Each interface has ingress and egress
      functionality, with each of these expressed as one or more TCBs.
      This level of the hierarchy is what was illustrated in Figure 2.

   Further levels may be built on top of this hierarchy, in particular
   ones for aiding in the repetitive configuration tasks likely for
   routers with many interfaces: some such "template" tools for Diffserv
   routers are outside the scope of this model but are under study by
   other working groups within IETF.

4.  Classifiers

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 using
   different filters are described in the following sections.  Figure 3
   illustrates a classifier, where the outputs connect to succeeding
   functional datapath elements.

   The simplest possible Classifier element is one that matches all
   packets that are applied at its input.  In this case, the Classifier
   element is just a no-op and may be omitted.

Top      ToC       Page 14 
   Note that we allow a Multiplexor (see Section 6.5) before the
   Classifier to allow input from multiple traffic streams.  For
   example, if traffic streams originating from multiple ingress
   interfaces feed through a single Classifier then the interface number
   could be one of the packet classification keys used by the
   Classifier.  This optimization may be important for scalability in
   the management plane.  Classifiers may also be cascaded in sequence
   to perform more complex lookup operations whilst still maintaining
   such scalability.

   Another example of a packet attribute could be an integer
   representing the BGP community string associated with the packet's
   best-matching route.  Other contextual information may also be used
   by a Classifier (e.g., knowledge that a particular interface faces a
   Diffserv domain or a legacy IP TOS domain [DSARCH] could be used when
   determining whether a DSCP is present or not).

      unclassified              classified
      traffic                   traffic
              +------------+
              |            |--> match Filter1 --> OutputA
      ------->| classifier |--> match Filter2 --> OutputB
              |            |--> no match      --> OutputC
              +------------+

      Figure 3. An Example Classifier

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

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

   Where the filters are defined to be the following BA filters
   ([DSARCH], Section 4.2.1):

      Filter        DSCP
      ------       ------
      Filter1       101010
      Filter2       111111
      Filter3       ****** (wildcard)

Top      ToC       Page 15 
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, 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   IPv4 Src Addr  IPv4 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 care".

   MF classification of IP-fragmented packets is 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 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:

      Filter   IPv4 Src Addr  IPv4 Dest Addr
      ------   -------------  --------------
      Filter5  172.31.8.X/24      X/0
      Filter6      X/0        172.30.10.1/32

   A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr
   172.30.10.1} 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

Top      ToC       Page 16 
   either (a) by a manager which knows that the router can accomplish
   this particular ordering (e.g., by means of reported capabilities),
   or (b) by the router along with a mechanism to report to a manager
   which precedence is being used.  Such precedence mechanisms must be
   supported in any translation of this model into specific syntax for
   configuration and management protocols.

   As another example, one might want first to disallow certain
   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 (possibly the wildcard default) and
   that any ambiguity between overlapping filters be resolved by
   precedence.  Therefore, the classifiers on any given interface must
   be "complete" and 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.

   This model of classifier operation makes the assumption that all
   filters of the same precedence be applied simultaneously.  Whilst
   convenient from a modeling point-of-view, this may or may not be how
   the classifier is actually implemented - this assumption is not
   intended to dictate how the implementation actually handles this,
   merely to clearly define the required end result.

4.2.  Examples

4.2.1.  Behavior Aggregate (BA) Classifier

   The simplest Diffserv classifier is a behavior aggregate (BA)
   classifier [DSARCH].  A BA classifier uses only the Diffserv
   codepoint (DSCP) in a 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.

Top      ToC       Page 17 
   The following defines a possible BA filter:

      Filter8:
      Type:   BA
      Value:  111000

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
   (possibly including the DSCP).  A common type of MF classifier is a
   6-tuple classifier that classifies based on six 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
      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.  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:    OutputA
      Filter13:    OutputB
      Default:     OutputC

Top      ToC       Page 18 
      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.4.  Other Possible Classifiers

   Classification may also be performed based on information at the
   datalink layer below IP (e.g., VLAN or datalink-layer priority) or
   perhaps on the ingress or egress IP, logical or physical interface
   identifier (e.g., the incoming channel number on a channelized
   interface).  A classifier that filters based on IEEE 802.1p Priority
   and 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 the subject of other standards or may be
   proprietary to a router vendor but they are not discussed further
   here.


Next RFC Part