RFC 3290
An Informal Management Model for Diffserv Routers
Pages: 56
Informational
Informational
Part 1 of 3 – Pages 1 to 18
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
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
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
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
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).
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)
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
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.
+---------------+ | 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 Blocks3.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
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
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
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:
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.
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)
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
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.
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
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)