Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3290

An Informal Management Model for Diffserv Routers

Pages: 56
Informational
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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   RFC3290 - 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 page on part 2)

Next Section