As per Relevance of the word different, we have this rfc below:
Network Working Group F.
Request for Comments: 3289 Cisco
Category: Standards Track K.
Nortel
A.
Harbour
May 2002
Management Information Base for
Differentiated Services
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This memo describes an SMIv2 (Structure of Management
version 2) MIB for a device implementing the Differentiated
Architecture. It may be used both for monitoring and
of a router or switch capable of Differentiated
functionality
Table of
1 The SNMP Management Framework ................................. 3
2 Relationship to other working group documents ................. 4
2.1 Relationship to the Informal Management Model
Differentiated Services Router ............................. 4
2.2 Relationship to other MIBs and Policy Management ............ 5
3 MIB Overview .................................................. 6
3.1 Processing Path ............................................. 7
3.1.1 diffServDataPathTable - The Data Path Table ............... 7
3.2 Classifier .................................................. 7
3.2.1 diffServClfrElementTable - The Classifier Element Table ... 8
3.2.2 diffServMultiFieldClfrTable - The Multi-field
Table ...................................................... 9
3.3 Metering Traffic ............................................ 10
3.3.1 diffServMeterTable - The Meter Table ...................... 11
Baker, et. al. Standards Track [Page 1]
RFC 3289 Differentiated Services MIB May 2002
3.3.2 diffServTBParamTable - The Token Bucket Parameters Table... 11
3.4 Actions applied to packets .................................. 12
3.4.1 diffServActionTable - The Action Table .................... 12
3.4.2 diffServCountActTable - The Count Action Table ............ 12
3.4.3 diffServDscpMarkActTable - The Mark Action Table .......... 13
3.4.4 diffServAlgDropTable - The Algorithmic Drop Table ......... 13
3.4.5 diffServRandomDropTable - The Random Drop Parameters Table 14
3.5 Queuing and Scheduling of Packets ........................... 16
3.5.1 diffServQTable - The Class or Queue Table ................. 16
3.5.2 diffServSchedulerTable - The Scheduler Table .............. 16
3.5.3 diffServMinRateTable - The Minimum Rate Table ............. 16
3.5.4 diffServMaxRateTable - The Maximum Rate Table ............. 17
3.5.5 Using queues and schedulers together ...................... 17
3.6 Example configuration for AF and EF ......................... 20
3.6.1 AF and EF Ingress Interface Configuration ................. 20
3.6.1.1 Classification In The Example ........................... 22
3.6.1.2 AF Implementation On an Ingress Edge Interface .......... 22
3.6.1.2.1 AF Metering On an Ingress Edge Interface .............. 22
3.6.1.2.2 AF Actions On an Ingress Edge Interface ............... 23
3.6.1.3 EF Implementation On an Ingress Edge Interface .......... 23
3.6.1.3.1 EF Metering On an Ingress Edge Interface .............. 23
3.6.1.3.2 EF Actions On an Ingress Edge Interface ............... 23
3.7 AF and EF Egress Edge Interface Configuration ............... 24
3.7.1 Classification On an Egress Edge Interface ................ 24
3.7.2 AF Implementation On an Egress Edge Interface ............. 26
3.7.2.1 AF Metering On an Egress Edge Interface ................. 26
3.7.2.2 AF Actions On an Egress Edge Interface .................. 29
3.7.2.3 AF Rate-based Queuing On an Egress Edge Interface ....... 30
3.7.3 EF Implementation On an Egress Edge Interface ............. 30
3.7.3.1 EF Metering On an Egress Edge Interface ................. 30
3.7.3.2 EF Actions On an Egress Edge Interface .................. 30
3.7.3.3 EF Priority Queuing On an Egress Edge Interface ......... 32
4 Conventions used in this MIB .................................. 33
4.1 The use of RowPointer to indicate data path linkage ......... 33
4.2 The use of RowPointer to indicate parameters ................ 34
4.3 Conceptual row creation and deletion ........................ 34
5 Extending this MIB ............................................ 35
6 MIB Definition ................................................ 35
7 Acknowledgments ............................................... 110
8 Security Considerations ....................................... 110
9 Intellectual Property Rights .................................. 111
10 References ................................................... 112
11 Authors' Addresses ........................................... 115
12 Full Copyright Statement ..................................... 116
Baker, et. al. Standards Track [Page 2]
RFC 3289 Differentiated Services MIB May 2002
1. The SNMP Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in [RFC 2571].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and is
in [RFC 1155], [RFC 1212] and [RFC 1215]. The second version
called SMIv2, is described in [RFC 2578], RFC 2579 [RFC 2579]
and [RFC 2580].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
is described in [RFC 1157]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and is described in [RFC 1901]
[RFC 1906]. The third version of the message protocol
called SNMPv3 and is described in [RFC 1906], [RFC 2572]
[RFC 2574].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in [RFC 1157]. A second set of protocol
and associated PDU formats is described in [RFC 1905].
o A set of fundamental applications described in [RFC 2573]
the view-based access control mechanism described in [
2575].
A more detailed introduction to the current SNMP Management
can be found in [RFC 2570].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
is no translation is possible (use of Counter64). Some machine
readable information in SMIv2 will be converted into
descriptions in SMIv1 during the translation process. However,
loss of machine readable information is not considered to change
semantics of the MIB
Baker, et. al. Standards Track [Page 3]
RFC 3289 Differentiated Services MIB May 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC 2119].
2. Relationship to other working group
The Differentiated Services Working Group and related working
developed other documents, notably the Informal Management Model
the policy configuration paradigm of SNMPCONF. The
between the MIB and those documents is clarified here
2.1. Relationship to the Informal Management Model for
Services
This MIB is similar in design to [MODEL], although it can be used
build functional data paths that the model would not well describe
The model conceptually describes ingress and egress interfaces of
n-port router, which may find some interfaces at a network edge
others facing into the network core. It describes the
and management of a Differentiated Services interface in terms of
or more Traffic Conditioning Blocks (TCB), each containing,
in the specified order, by definition, zero or more classifiers
meters, actions, algorithmic droppers, queues and schedulers
Traffic may be classified, and classified traffic may be metered
Each stream of traffic identified by a combination of classifiers
meters may have some set of actions performed on it; it may
dropping algorithms applied and it may ultimately be stored into
queue before being scheduled out to its next destination, either
a link or to another TCB. At times, the treatment for a given
must have any of those elements repeated. [MODEL] models this
cascading multiple TCBs, while this MIB describes the policy
directly linking the functional data path elements
The MIB represents this cascade by following the "Next" attributes
the various elements. They indicate what the next step
Differentiated Services processing will be, whether it be
classifier, meter, action, algorithmic dropper, queue, scheduler or
decision to now forward a packet
The higher level concept of a TCB is not required in
parameterization or in the linking together of the
elements, hence it is not used in the MIB itself and is
mentioned in the text for relating the MIB with the [MODEL]. Rather
the MIB models the individual elements that make up the TCBs
This MIB uses the notion of a Data Path to indicate
Differentiated Services processing a packet may experience. The
Path a packet will initially follow is an attribute of the
Baker, et. al. Standards Track [Page 4]
RFC 3289 Differentiated Services MIB May 2002
in question. The Data Path Table provides a starting point for
direction (ingress or egress) on each interface. A Data Path
Entry indicates the first of possible multiple elements that
apply Differentiated Services treatment to the packet
2.2. Relationship to other MIBs and Policy
This MIB provides for direct reporting and manipulation of
functional elements. These elements consist of a structural
and one or more parameter-bearing elements. While this can
cumbersome, it allows the reuse of parameters. For example,
service provider may offer three varieties of contracts,
configure three parameter elements. Each such data path on
system may then refer to these sets of parameters.
diffServDataPathTable couples each direction on each interface
the specified data path linkage. The concept of "interface" is
defined by InterfaceIndex/ifIndex of the IETF Interfaces MIB [IF
MIB].
Other MIBs and data structure definitions for policy
mechanisms, other than SNMP/SMIv2 are likely to exist in the
for the purpose of abstracting the model in other ways. An
is the Differentiated Services Policy Information Base, [DSPIB].
In particular, abstractions in the direction of less
definitions of Differentiated Services functionality are likely e.g
some form of "Per-Hop Behavior"-based definition involving a
of detailed object values which is applied to specific instances
objects in this MIB semi-automatically
Another possible direction of abstraction is one using a concept
"roles" (often, but not always, applied to interfaces). In
case, it may be possible to re-use the object definitions in
MIB, especially the parameterization tables. The Data Path
will help in the reuse of the data path linkage tables by having
interface specific information centralized, allowing
mechanical replacement of ifIndex by some sort of "roleIndex".
work is ongoing
The reuse of parameter blocks on a variety of functional data
is intended to simplify network management. In many cases, one
also re-use the structural elements as well; this has the
side-effect of re-using the counters, so that monitoring
is lost. For this reason, the re-use of structural elements is
generally recommended
Baker, et. al. Standards Track [Page 5]
RFC 3289 Differentiated Services MIB May 2002
3. MIB
The Differentiated Services Architecture does not specify how
implementation should be assembled. The [MODEL] describes a
approach to implementation design, or to user interface design.
components could, however, be assembled in a different way.
example, traffic conforming to a meter might be run through a
meter, or reclassified
This MIB models the same functional data path elements, allowing
network manager to assemble them in any fashion that meets
relevant policy. These data path elements include Classifiers
Meters, Actions of various sorts, Queues, and Schedulers
In many of these tables, a distinction is drawn between the
of the policy (do this, then do that) and the parameters applied
specific policy elements. This is to facilitate configuration,
the MIB is used for that. The concept is that a set of parameters
such as the values that describe a specific token bucket, might
configured once and applied to many interfaces
The RowPointer Textual Convention is therefore used in two ways
this MIB. It is defined for the purpose of connecting an object
an entry dynamically; the RowPointer object identifies the
object in the target Entry, and in so doing points to the
entry. In this MIB, it is used as a connector between
functional data path elements, and as the link between the
structure and the parameters that are used. When used as
connector, it says what happens "next"; what happens to
traffic, to traffic conforming or not conforming to a meter, and
on. When used to indicate the parameters applied in a policy,
says "specifically" what is meant; the structure points to
parameters of its policy
The use of RowPointers as connectors allows for the simple
of the MIB. The RowPointers, whether "next" or "specific", may
to Entries defined in other MIB modules. For example, the only
of meter defined in this MIB is a token bucket meter; if another
of meter is required, another MIB could be defined describing
type of meter, and diffServMeterSpecific could point to it
Similarly, if a new action is required, the "next" pointer of
previous functional datapath element could point to an Entry
in another MIB, public or proprietary
Baker, et. al. Standards Track [Page 6]
RFC 3289 Differentiated Services MIB May 2002
3.1. Processing
An interface has an ingress and an egress direction, and
generally have a different policy in each direction. As
enters an edge interface, it may be classified, metered, counted,
marked. Traffic leaving the same interface might be
according to the contract with the next network, queued to manage
bandwidth, and so on. As [MODEL] points out, the functional
elements used on ingress and egress are of the same type, but may
structured in very different ways to implement the relevant policies
3.1.1. diffServDataPathTable - The Data Path
Therefore, when traffic arrives at an ingress or egress interface
the first step in applying the policy is determining what
applies. This MIB does that by providing a table of pointers to
first functional data path element, indexed by interface
direction on that interface. The content of
diffServDataPathEntry is a single RowPointer, which points to
functional data path element
When diffServDataPathStart in a direction on an interface
undefined or is set to zeroDotZero, the implication is that there
no specific policy to apply
3.2.
Classifiers are used to differentiate among types of traffic. In
Differentiated Services architecture, one usually discusses
behavior aggregate identified by the application of one or
Differentiated Services Code Points (DSCPs). However, especially
network edges (which include hosts and first hop routers
hosts), traffic may arrive unmarked or the marks may not be trusted
In these cases, one applies a Multi-Field Classifier, which
select an aggregate as coarse as "all traffic", as fine as a
microflow identified by IP Addresses, IP Protocol, and TCP or
ports, or variety of slices in between
Classifiers can be simple or complex. In a core interface, one
expect to find simple behavior aggregate classification to be used
However, in an edge interface, one might first ask what
is being used, meter the arriving traffic, and then apply
policies to the non-conforming traffic depending on the
System number advertising the destination address. To
such a thing, traffic must be classified, metered, and
reclassified. To this end, the MIB defines separate classifiers
which may be applied at any point in processing, and may
different content as needed
Baker, et. al. Standards Track [Page 7]
RFC 3289 Differentiated Services MIB May 2002
The MIB also allows for ambiguous classification in a
fashion. In the end, traffic classification must be unambiguous;
must know for certain what policy to apply to any given packet
However, writing an unambiguous specification is often tedious,
writing a specification in steps that permits and excludes
kinds of traffic may be simpler and more intuitive. In such a case
the classification "steps" are enumerated; all
elements of one precedence are applied as if in parallel, and
all classification elements of the next precedence
This MIB defines a single classifier parameter entry, the Multi-
Classifier. A degenerate case of this multi-field classifier is
Behavior Aggregate classifier. Other classifiers may be defined
other MIB modules, to select traffic from a given layer two
or a given interface, traffic whose addresses belong to a given
Community or Autonomous System, and so on
3.2.1. diffServClfrElementTable - The Classifier Element
A classifier consists of classifier elements. A classifier
identifies a specific set of traffic that forms part of a
aggregate; other classifier elements within the same classifier
identify other traffic that also falls into the behavior aggregate
For example, in identifying AF traffic for the aggregate AF1,
might implement separate classifier elements for AF11, AF12, and AF13
within the same classifier and pointing to the same subsequent meter
Generally, one would expect the Data Path Entry to point to
classifier (which is to say, a set of one or more
elements), although it may point to something else when appropriate
Reclassification in a functional data path is achieved by pointing
another Classifier Entry when appropriate
A classifier element is a structural element, indexed by
ID and element ID. It has a precedence value, allowing
structured ambiguity as described above, a "specific" pointer
identifies what rule is to be applied, and a "next" pointer
traffic matching the classifier to the next functional data
element. If the "next" pointer is zeroDotZero, the indication
that there is no further differentiated services processing for
behavior aggregate. However, if the "specific" pointer
zeroDotZero, the device is misconfigured. In such a case,
classifier element should be operationally treated as if it were
present
When the MIB is used for configuration, diffServClfrNextFree
diffServClfrElementNextFree always contain legal values
diffServClfrId and diffServClfrElementId that are not currently
Baker, et. al. Standards Track [Page 8]
RFC 3289 Differentiated Services MIB May 2002
in the system's configuration. The values are validated
creating diffServClfrId and diffServClfrElementId, and in the
of a failure (which would happen if two managers
attempted to create an entry) must be re-read
3.2.2. diffServMultiFieldClfrTable - The Multi-field Classifier
This MIB defines a single parameter type for classification,
Multi-field Classifier. As a parameter, a filter may be
once and applied to many interfaces,
diffServClfrElementSpecific. This filter matches
o IP source address prefix, including host, CIDR Prefix, and "
source address
o IP destination address prefix, including host, CIDR Prefix,
"any destination address
o IPv6 Flow
o IP protocol or "any
o TCP/UDP/SCTP source port range, including "any
o TCP/UDP/SCTP destination port range, including "any
o Differentiated Services Code
Since port ranges, IP prefixes, or "any" are defined in each case,
is clear that a wide variety of filters can be constructed.
Differentiated Services Behavior Aggregate filter is a special
of this filter, in which only the DSCP is specified
Other MIB modules may define similar filters in the same way.
example, a filter for Ethernet information might define source
destination MAC addresses of "any", Ethernet Packet Type, IEEE 802.2
SAPs, and IEEE 802.1 priorities. A filter related to policy
might be structured like the diffServMultiFieldClfrTable, but
the BGP Communities of the source and destination prefix rather
the prefix itself, meaning "any prefix in this community". For
a filter, a table similar to diffServMultiFieldClfrTable
constructed, and diffServClfrElementSpecific is configured to
to it
Baker, et. al. Standards Track [Page 9]
RFC 3289 Differentiated Services MIB May 2002
When the MIB is used for configuration
diffServMultiFieldClfrNextFree always contains a legal value
diffServMultiFieldClfrId that is not currently used in the system'
configuration
3.3. Metering
As discussed in [MODEL], a meter and a shaper are functions
operate on opposing ends of a link. A shaper schedules traffic
transmission at specific times in order to approximate a
line speed or combination of line speeds. In its simplest form,
the traffic stream contains constant sized packets, it might
one packet per unit time to build the equivalent of a CBR circuit
However, various factors intervene to make the approximation inexact
multiple classes of traffic may occasionally schedule their
at the same time, the variable length nature of IP traffic
introduce variation, and factors in the link or physical layer
change traffic timing. A meter integrates the arrival rate
traffic and determines whether the shaper at the far end
correctly applied, or whether the behavior of the application
question is naturally close enough to such behavior to be
under a given policy
A common type of meter is a Token Bucket meter, such as [srTCM]
[trTCM]. This type of meter assumes the use of a shaper at
previous node; applications which send at a constant rate
sending may conform if the token bucket is properly specified.
specifies the acceptable arrival rate and quantifies the
variability, often by specifying a burst size or an interval;
rate = quantity/time, specifying any two of those parameters
the third, and a large interval provides for a forgiving system
Multiple rates may be specified, as in AF, such that a subset of
traffic (up to one rate) is accepted with one set of guarantees,
traffic in excess of that but below another rate has a different
of guarantees. Other types of meters exist as well
One use of a meter is when a service provider sells at most,
certain bit rate to one of its customers, and wants to drop
excess. In such a case, the fractal nature of normal
traffic must be reflected in large burst intervals, as TCP
sends packet pairs or larger bursts, and responds poorly when
than one packet in a round trip interval is dropped.
like FTP contain the effect by simply staying below the target
rate; this type of configuration very adversely affects
applications like HTTP, however. Another use of a meter is in the
specification, in which excess traffic is marked with a related
and subjected to slightly more active queue depth management.
Baker, et. al. Standards Track [Page 10]
RFC 3289 Differentiated Services MIB May 2002
application is not sharply limited to a contracted rate in such
case, but can be readily contained should its traffic create
burden
3.3.1. diffServMeterTable - The Meter
The Meter Table is a structural table, specifying a
functional data path element. Its entry consists essentially
three RowPointers - a "succeed" pointer, for traffic conforming
the meter, a "fail" pointer, for traffic not conforming to the meter
and a "specific" pointer, to identify the parameters in question
This structure is a bow to SNMP's limitations; it would be better
have a structure with N rates and N+1 "next" pointers, with a
algorithm specified. In this case, multiple meter entries
by the "fail" link are understood to contain the parameters for
specified algorithm, and traffic conforming to a given rate
their "succeed" paths. Within this MIB, only Token Bucket
are specified; other varieties of meters may be designed in other
modules
When the MIB is used for configuration, diffServMeterNextFree
contains a legal value for diffServMeterId that is not currently
in the system's configuration
3.3.2. diffServTBParamTable - The Token Bucket Parameters
The Token Bucket Parameters Table is a set of parameters that
a Token Bucket Meter. As a parameter, a token bucket may
specified once and applied to many interfaces,
diffServMeterSpecific. Specifically, several modes of [srTCM]
[trTCM] are addressed. Other varieties of meters may be specified
other MIB modules
In general, if a Token Bucket has N rates, it has N+1
outcomes - the traffic stream is slower than and therefore
to all of the rates, it fails the first few but is slower than
therefore conforms to the higher rates, or it fails all of them.
such, multi-rate meters should specify those rates in
increasing order, passing through the diffServMeterFailNext from
committed to more excess rates, and finally falling
diffServMeterFailNext to the set of actions that apply to
which conforms to none of the specified rates.
in the first entry indicates the algorithm being used. At each rate
diffServTBParamRate is derivable from diffServTBParamBurstSize
diffServTBParamInterval; a superior implementation will allow
Baker, et. al. Standards Track [Page 11]
RFC 3289 Differentiated Services MIB May 2002
configuration of any two of diffServTBParamRate
diffServTBParamBurstSize, and diffServTBParamInterval, and
with the appropriate error code if all three are specified but
not mathematically related
When the MIB is used for configuration,
always contains a legal value for diffServTBParamId that is
currently used in the system's configuration
3.4. Actions applied to
"Actions" are the things a differentiated services interface PHB
do to a packet in transit. At a minimum, such a policy
calculate statistics on traffic in various configured classes,
it with a DSCP, drop it, or enqueue it before passing it on for
processing
Actions are composed of a structural element,
diffServActionTable, and various component action entries that may
applied. In the case of the Algorithmic Dropper, an
parameter table may be specified to control Active Queue Management
as defined in [RED93] and other AQM specifications
3.4.1. diffServActionTable - The Action
The action table identifies sequences of actions to be applied to
packet. Successive actions are chained through diffServActionNext
ultimately resulting in zeroDotZero (indicating that the policy
complete), a pointer to a queue, or a pointer to some
functional data path element
When the MIB is used for configuration, diffServActionNextFree
contains a legal value for diffServActionId that is not
used in the system's configuration
3.4.2. diffServCountActTable - The Count Action
The count action accumulates statistics pertaining to traffic
through a given path through the policy. It is intended to be
for usage-based billing, for statistical studies, or for analysis
the behavior of a policy in a given network. The objects in
Count Action are various counters and a discontinuity time.
counters display the number of packets and bytes encountered on
path since the discontinuity time. They share the same
time, which is the discontinuity time of the interface or agent
Baker, et. al. Standards Track [Page 12]
RFC 3289 Differentiated Services MIB May 2002
The designers of this MIB expect that every path through a
should have a corresponding counter. In early versions, it
impossible to configure an action without implementing a counter
although the current design makes them in effect the
manager's option, as a result of making actions consistent
structure and extensibility. The assurance of proper debugging
accounting is therefore left with the policy designer
When the MIB is used for configuration,
always contains a legal value for diffServCountActId that is
currently used in the system's configuration
3.4.3. diffServDscpMarkActTable - The Mark Action
The Mark Action table is an unusual table, both in SNMP and in
MIB. It might be viewed not so much as an array of single-
entries as an array of OBJECT-IDENTIFIER conventions, as the OID
a diffServDscpMarkActDscp instance conveys all of the
information: packets are to be marked with the requisite DSCP
As such, contrary to common practice, the index for the table
read- only, and is both the Entry's index and its only value
3.4.4. diffServAlgDropTable - The Algorithmic Drop
The Algorithmic Drop Table identifies a dropping algorithm,
packets, and counts the drops. Classified as an action, it is
effect a method which applies a packet to a queue, and may
either. When the algorithm is "always drop", this is simple;
the algorithm calls for head-drop, tail-drop, or a variety of
Queue Management, the queue is inspected, and in the case of
Queue Management, additional parameters are REQUIRED
What may not be clear from the name is that an Algorithmic
action often does not drop traffic. Algorithms other than "
drop" normally drop a few percent of packets at most. The
inspects the diffServQEntry that diffServAlgDropQMeasure points to
order to determine whether the packet should be dropped
When the MIB is used for configuration,
always contains a legal value for diffServAlgDropId that is
currently used in the system's configuration
Baker, et. al. Standards Track [Page 13]
RFC 3289 Differentiated Services MIB May 2002
3.4.5. diffServRandomDropTable - The Random Drop Parameters
The Random Drop Table is an extension of the Algorithmic Drop
intended for use on queues whose depth is actively managed.
Queue Management algorithms are typified by [RED93], but
parameters they use vary. It was deemed for the purposes of this
that the proper values to represent include
o Target case mean queue depth, expressed in bytes or
o Worst case mean queue depth, expressed in bytes or
o Maximum drop rate expressed as drops per
o Coefficient of an exponentially weighted moving average
expressed as the numerator of a fraction whose denominator
65536.
o Sampling
An example of the representation chosen in this MIB for this
is shown in Figure 1.
Random droppers often have their drop probability function
as a plot of drop probability (P) against averaged queue length (Q).
(Qmin,Pmin) then defines the start of the characteristic plot
Normally Pmin=0, meaning with average queue length below Qmin,
will be no drops. (Qmax,Pmax) defines a "knee" on the plot,
which point the drop probability becomes more progressive (
slope). (Qclip,1) defines the queue length at which all packets
be dropped. Notice this is different from Tail Drop because
uses an averaged queue length, although it is possible for Qclip
equal Qmax
In the MIB module, diffServRandomDropMinThreshBytes
diffServRandomDropMinThreshPkts represent Qmin
diffServRandomDropMaxThreshBytes and
represent Qmax. diffServAlgDropQThreshold represents Qclip
diffServRandomDropInvProbMax represents Pmax (inverse). This
does not represent Pmin (assumed to be zero unless
represented). In addition, since message memory is finite,
generally have some upper bound above which they are incapable
storing additional traffic. Normally this number is equal to Qclip
specified by diffServAlgDropQThreshold
Baker, et. al. Standards Track [Page 14]
RFC 3289 Differentiated Services MIB May 2002
AlgDrop
+-----------------+ +-------+
--->| Next ---------+--+------------------->| Next -+--> ...
| QMeasure -------+--+ | ... |
| QThreshold | RandomDrop +-------+
| Type=randomDrop | +----------------+
| Specific -------+---->| MinThreshBytes |
+-----------------+ | MaxThreshBytes |
| ProbMax |
| Weight |
| SamplingRate |
+----------------+
Figure 1: Example Use of the RandomDropTable for Random
Each random dropper specification is associated with a queue.
allows multiple drop processes (of same or different types) to
associated with the same queue, as different PHB implementations
require. This also allows for sequences of multiple droppers
necessary
The calculation of a smoothed queue length may also have an
bearing on the behavior of the dropper: parameters may include
sampling interval or rate, and the weight of each sample.
performance may be very sensitive to the values of these
and a wide range of possible values may be required due to a
range of link speeds. Most algorithms include a sample weight
represented here by diffServRandomDropWeight. The availability
diffServRandomDropSamplingRate as readable is important,
information provided by Sampling Rate is essential to
configuration of diffServRandomDropWeight. Having Sampling Rate
configurable is also helpful, as line speed increases, the ability
have queue sampling be less frequent than packet arrival is needed
Note, however, that there is ongoing research on this topic, see e.g
[ACTQMGMT] and [AQMROUTER].
Additional parameters may be added in an enterprise MIB module, e.g
by using AUGMENTS on this table, to handle aspects of random
algorithms that are not standardized here
When the MIB is used for configuration,
always contains a legal value for diffServRandomDropId that is
currently used in the system's configuration
Baker, et. al. Standards Track [Page 15]
RFC 3289 Differentiated Services MIB May 2002
3.5. Queuing and Scheduling of
These include Queues and Schedulers, which are inter-related in
use of queuing techniques. By doing so, it is possible to
multi-level schedulers, such as those which treat a set of queues
having priority among them, and at a specific priority find
secondary WFQ scheduler with some number of queues
3.5.1. diffServQTable - The Class or Queue
The Queue Table models simple FIFO queues. The Scheduler
allows flexibility in constructing both simple and somewhat
complex queuing hierarchies from those queues
Queue Table entries are pointed at by the "next" attributes of
upstream elements, such as diffServMeterSucceedNext
diffServActionNext. Note that multiple upstream elements may
their traffic to the same Queue Table entry. For example,
Assured Forwarding PHB suggests that all traffic marked AF11, AF12
AF13 be placed in the same queue, after metering, without reordering
To accomplish that, the upstream diffServAlgDropNext pointers
point to the same diffServQEntry
A common requirement of a queue is that its traffic enjoy a
minimum or maximum rate, or that it be given a certain priority
Functionally, the selection of such is a function of a scheduler
The parameter is associated with the queue, however, using
Minimum or Maximum Rate Parameters Table
When the MIB is used for configuration, diffServQNextFree
contains a legal value for diffServQId that is not currently used
the system's configuration
3.5.2. diffServSchedulerTable - The Scheduler
The scheduler, and therefore the Scheduler Table, accepts inputs
either queues or a preceding scheduler. The Scheduler Table
flexibility in constructing both simple and somewhat more
queuing hierarchies from those queues
When the MIB is used for configuration,
always contains a legal value for diffServSchedulerId that is
currently used in the system's configuration
3.5.3. diffServMinRateTable - The Minimum Rate
When the output rate of a queue or scheduler must be given a
rate or a priority, this is done using the diffServMinRateTable
Baker, et. al. Standards Track [Page 16]
RFC 3289 Differentiated Services MIB May 2002
Rates may be expressed as absolute rates, or as a fraction
ifSpeed, and imply the use of a rate-based scheduler such as WFQ
WRR. The use of a priority implies the use of a Priority Scheduler
Only one of the Absolute or Relative rates needs to be set; the
takes the relevant value as a result. Excess capacity is
proportionally among the inputs to a scheduler using the
rate. More complex functionality may be described by augmenting
MIB
When a priority scheduler is used, its effect is to give the
the entire capacity of the subject interface less the capacity
by higher priorities, if there is traffic present to use it. This
true regardless of the rate specifications applied to that queue
other queues on the interface. Policing excess traffic will
this behavior
When the MIB is used for configuration,
always contains a legal value for diffServMinRateId that is
currently used in the system's configuration
3.5.4. diffServMaxRateTable - The Maximum Rate
When the output rate of a queue or scheduler must be limited to
most a specified maximum rate, this is done using
diffServMaxRateTable. Rates may be expressed as absolute rates,
as a fraction of ifSpeed. Only one of the Absolute or Relative
needs to be set; the other takes the relevant value as a result
The definition of a multirate shaper requires
diffServMaxRateEntries. In this case, an algorithm such as [SHAPER
is used. In that algorithm, more than one rate is specified, and
any given time traffic is shaped to the lowest specified rate
exceeds the arrival rate of traffic
When the MIB is used for configuration,
always contains a legal value for diffServMaxRateId that is
currently used in the system's configuration
3.5.5. Using queues and schedulers
For representing a Strict Priority scheduler, each scheduler input
assigned a priority with respect to all the other inputs feeding
same scheduler, with default values for the other parameters
Higher-priority traffic that is not being delayed for shaping will
serviced before a lower-priority input. An example is found
Figure 2.
Baker, et. al. Standards Track [Page 17]
RFC 3289 Differentiated Services MIB May 2002
For weighted scheduling methods, such as WFQ or WRR, the "weight"
a given scheduler input is represented with a Minimum Service
leaky-bucket profile which provides a guaranteed minimum bandwidth
that input, if required. This is represented by a
diffServMinRateAbsolute; the classical weight is the ratio
that rate and the interface speed, or perhaps the ratio between
rate and the sum of the configured rates for classes. The rate
be represented by a relative value, as a fraction of the interface'
current line rate, diffServMinRateRelative, to assist in cases
line rates are variable or where a higher-level policy might
expressed in terms of fractions of network resources. The two
parameters are inter-related and changes in one may be reflected
the other. An example is found in figure 3.
+-----+
+-------+ | P S |
| Queue +------------>+ r c |
+-------+-+--------+ | i h |
|Priority| | o e |
+--------+ | r d +----------->
+-------+ | i u |
| Queue +------------>+ t l |
+-------+-+--------+ | y e |
|Priority| | r |
+--------+ +-----+
Figure 2: Priority Scheduler with two
For weighted scheduling methods, one can say loosely, that
focuses on meeting bandwidth sharing, without concern for
delay amongst the queues; where WFQ controls both queue the
order and the amount of traffic serviced, providing bandwidth
and relative delay ordering amongst the queues
A queue or scheduled set of queues (which is an input to a scheduler
may also be capable of acting as a non-work-conserving [MODEL
traffic shaper: this is done by defining a Maximum Service
leaky-bucket profile in order to limit the scheduler
available to that input. This is represented by a rate,
diffServMaxRateAbsolute; the classical weight is the ratio
that rate and the interface speed, or perhaps the ratio between
rate and the sum of the configured rates for classes. The rate
be represented by a relative value, as a fraction of the interface'
current line rate, diffServMaxRateRelative. This MIB presumes
shaping is something a scheduler does to its inputs, which it
as a queue with a maximum rate or a scheduler whose output has
maximum rate
Baker, et. al. Standards Track [Page 18]
RFC 3289 Differentiated Services MIB May 2002
+-----+
+-------+ | W S |
| Queue +------------>+ R c |
+-------+-+--------+ | R h |
| Rate | | e |
+--------+ | o d +----------->
+-------+ | r u |
| Queue +------------>+ l |
+-------+-+--------+ | W e |
| Rate | | F r |
+--------+ | Q |
+-----+
Figure 3: WRR or WFQ rate-based scheduler with two
The same may be done on a queue, if a given class is to be shaped
a maximum rate without shaping other classes, as in Figure 5.
Other types of priority and weighted scheduling methods can
defined using existing parameters in diffServMinRateEntry. NOTE
diffServSchedulerMethod uses OBJECT IDENTIFIER syntax, with
different types of scheduling methods defined as OBJECT-IDENTITY
+---+
+-------+ | S |
| Queue +------------>+ c |
+-------+-+--------+ | h |
| | | e +----------->
+--------+ | d +-+-------+
| u | |Shaping
+-------+ | l | | Rate |
| Queue +------------>+ e | +-------+
+-------+-+--------+ | r |
| | +---+
+--------+
Figure 4: Shaping scheduled traffic to a known
Baker, et. al. Standards Track [Page 19]
RFC 3289 Differentiated Services MIB May 2002
+---+
+-------+ | S |
| Queue +------------>+ c |
+-------+-+--------+ | h |
|Min Rate| | e +----------->
+--------+ | d |
| u |
+-------+ | l |
| Queue +------------>+ e |
+-------+-+--------+ | r |
|Min Rate| | |
+--------+ | |
|Max Rate| | |
+--------+ +---+
Figure 5: Shaping one input to a work-conserving
Future scheduling methods may be defined in other MIBs.
requires an OBJECT-IDENTITY definition, a description of how
existing objects are reused, if they are, and any new objects
require
To implement an EF and two AF classes, one must use a combination
priority and WRR/WFQ scheduling. This requires us to cascade
schedulers. If one were to additionally shape the output of
system to a rate lower than the interface rate, one must place
upper bound rate on the output of the priority scheduler. See
6.
3.6. Example configuration for AF and
For the sake of argument, let us build an example with one EF
and four AF classes using the constructs in this MIB
3.6.1. AF and EF Ingress Interface
The ingress edge interface identifies traffic into classes,
it, and ensures that any excess is appropriately dealt with
to the PHB. For AF, this means marking excess; for EF, it
dropping excess or shaping it to a maximum rate
Baker, et. al. Standards Track [Page 20]
RFC 3289 Differentiated Services MIB May 2002
+-----+
+-------+ | P S |
| Queue +---------------------------------->+ r c |
+-------+----------------------+--------+ | i h |
|Priority| | o e +----------->
+--------+ | r d +-+-------+
+------+ | i u | |Shaping
+-------+ | W S +------------->+ t l | | Rate |
| Queue +------------>+ R c +-+--------+ | y e | +-------+
+-------+-+--------+ | R h | |Priority| | r |
|Min Rate| | e | +--------+ +-----+
+--------+ | o d |
+-------+ | r u |
| Queue +------------>+ l |
+-------+-+--------+ | W e |
|Min Rate| | F r |
+--------+ | Q |
+------+
Figure 6: Combined EF and AF services using cascaded schedulers
+-----------------------+
| diffServDataPathStart |
+-----------+-----------+
|
+----------+
|
+--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM
|Meter| |Meter| |Meter| |Meter| |Meter
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions
+||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| |
VVV VVV VVV VVV
Accepted traffic is sent to IP
Figure 7: combined EF and AF implementation, ingress
Baker, et. al. Standards Track [Page 21]
RFC 3289 Differentiated Services MIB May 2002
3.6.1.1. Classification In The
A packet arriving at an ingress interface picks up its policy
the diffServDataPathTable. This points to a classifier, which
select traffic according to some specification for each
class
An example of a classifier for an AFm class would be a set of
classifier elements, each pointing to a Multi-field
parameter block identifying one of the AFmn DSCPs. Alternatively
the filters might contain selectors for HTTP traffic or some
application
An example of a classifier for EF traffic might be a
element pointing to a filter specifying the EF code point,
collection of classifiers with parameter blocks specifying
telephone calls, or a variety of other approaches
Typically, of course, a classifier identifies a variety of
and breaks it up into separate classes. It might very well
fourteen classifier elements indicating the twelve AFmn DSCP values
EF, and "everything else". These would presumably direct
down six functional data paths: one for each AF or EF class, and
for all other traffic
3.6.1.2. AF Implementation On an Ingress Edge
Each AFm class applies a Two Rate Three Color Meter, dividing
into three groups. These groups of traffic conform to both
rates, only the higher one, or none. The intent, on the
interface at the edge of the network, is to measure and
mark traffic
3.6.1.2.1. AF Metering On an Ingress Edge
Each AFm class applies a Two Rate Three Color Meter, dividing
into three groups. If two rates R and S, where R < S, are
and traffic arrives at rate T, traffic comprising up to R bits
second is considered to conform to the "confirmed" rate, R.
R < T, traffic comprising up to S-R bits per second is considered
conform to the "excess" rate, S. Any further excess is non
conformant
Two meter entries are used to configure this, one for the
rate and one for the excess rate. The rate parameters are stored
associated Token Bucket Parameter Entries. The "FailNext" pointer
the lower rate Meter Entry points to the other Meter Entry;
"SucceedNext" pointers and the "FailNext" pointer of the higher
Baker, et. al. Standards Track [Page 22]
RFC 3289 Differentiated Services MIB May 2002
Entry point to lists of actions. In the color-blind mode, all
classifier "next" entries point to the lower rate meter entry.
the color-aware mode, the AFm1 classifier points to the lower
entry, the AFm2 classifier points to the higher rate entry (as it
only compared against that rate), and the AFm3 classifier
directly to the actions taken when both rates fail
3.6.1.2.2. AF Actions On an Ingress Edge
For network planning and perhaps for billing purposes,
traffic is normally counted. Therefore, a "count" action,
of an action table entry pointing to a count table entry,
configured
Also, traffic is marked with the appropriate DSCP. The first R
per second are marked AFm1, the next S-R bits per second are
AFm2, and the rest is marked AFm3. It may be that traffic
arriving marked with the same DSCP, but in general, the
complexity of deciding that it is being remarked to the same value
not useful. Therefore, a "mark" action, consisting of an
table entry pointing to a mark table entry, is configured
At this point, the usual case is that traffic is now forwarded in
usual manner. To indicate this, the "SucceedNext" pointer of
Mark Action is set to zeroDotZero
3.6.1.3. EF Implementation On an Ingress Edge
The EF class applies a Single Rate Two Color Meter, dividing
into "conforming" and "excess" groups. The intent, on the
interface at the edge of the network, is to measure and
mark conforming traffic and drop the excess
3.6.1.3.1. EF Metering On an Ingress Edge
A single rate two color (srTCM) meter requires one token bucket.
is therefore configured using a single meter entry with
corresponding Token Bucket Parameter Entry. Arriving traffic
"succeeds" or "fails".
3.6.1.3.2. EF Actions On an Ingress Edge
For network planning and perhaps for billing purposes,
traffic that conforms to the meter is normally counted. Therefore,
"count" action, consisting of an action table entry pointing to
count table entry, is configured
Baker, et. al. Standards Track [Page 23]
RFC 3289 Differentiated Services MIB May 2002
Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark
action, consisting of an action table entry pointing to a mark
entry, is configured
At this point, the successful traffic is now forwarded in the
manner. To indicate this, the "SucceedNext" pointer of the
Action is set to zeroDotZero
Traffic that exceeded the arrival policy, however, is to be dropped
One can use a count action on this traffic if the several
are interesting. However, since the drop counter in the
Drop Entry will count packets dropped, this is not clearly necessary
An Algorithmic Drop Entry of the type "alwaysDrop" with no
is sufficient
3.7. AF and EF Egress Edge Interface
3.7.1. Classification On an Egress Edge
A packet arriving at an egress interface may have been classified
an ingress interface, and the egress interface may have access
that information. If it is relevant, there is no reason not to
that information. If it is not available, however, there may be
need to (re)classify on the egress interface. In any event, it
up its "program" from the diffServDataPathTable. This points to
classifier, which will select traffic according to some
for each traffic class
Baker, et. al. Standards Track [Page 24]
RFC 3289 Differentiated Services MIB May 2002
+-----------------------+
| diffServDataPathStart |
+-----------+-----------+
|
+----------+
|
+--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM
|Meter| |Meter| |Meter| |Meter| |Meter
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions
+||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| |
+-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+
| Queue| | Queue| | Queue| | Queue| | Queue
+--+---+ +--+---+ +--+---+ +--+---+ +--+---+
| | | | |
+--+-----------+-----------+-----------+---+ |
| WFQ/WRR Scheduler | |
+--------------------------------------+---+ |
| |
+-----+-----------+----+
| Priority Scheduler |
+----------+-----------+
|
Figure 8: combined EF and AF
An example of a classifier for an AFm class would be a succession
three classifier elements, each pointing to a Multi-
classification parameter block identifying one of the AFmn DSCPs
Alternatively, the filter might contain selectors for HTTP traffic
some other application
Baker, et. al. Standards Track [Page 25]
RFC 3289 Differentiated Services MIB May 2002
An example of a classifier for EF traffic might be either
classifier element pointing to a Multi-field parameter specifying
EF code point, or a collection of classifiers with parameter
specifying individual telephone calls, or a variety of
approaches
Each classifier delivers traffic to appropriate functional data
elements
3.7.2. AF Implementation On an Egress Edge
Each AFm class applies a Two Rate Three Color Meter, dividing
into three groups. These groups of traffic conform to both
rates, only the higher one, or none. The intent, on the
interface at the edge of the network, is to measure and
mark traffic
3.7.2.1. AF Metering On an Egress Edge
Each AFm class applies a Two Rate Three Color Meter, dividing
into three groups. If two rates R and S, where R < S, are
and traffic arrives at rate T, traffic comprising up to R bits
second is considered to conform to the "confirmed" rate, R.
R < T, traffic comprising up to S-R bits per second is considered
conform to the "excess" rate, S. Any further excess is non
conformant
Two meter entries are used to configure this, one for the
rate and one for the excess rate. The rate parameters are stored
associated Token Bucket Parameter Entries. The "FailNext" pointer
the lower rate Meter Entry points to the other Meter Entry;
"SucceedNext" pointers and the "FailNext" pointer of the higher
Entry point to lists of actions. In the color-blind mode, all
classifier "next" entries point to the lower rate meter entry.
the color-aware mode, the AFm1 classifier points to the lower
entry, the AFm2 classifier points to the higher rate entry (as it
only compared against that rate), and the AFm3 classifier
directly to the actions taken when both rates fail
Baker, et. al. Standards Track [Page 26]
RFC 3289 Differentiated Services MIB May 2002
+-----------------------------------------------------+
| Classifier |
+--------+--------------------------------------------+
|Green| Yellow|
| | |
+--+-----+-------+--+ Fail +--------------------+
| Meter +------+ Meter |
+--+----------------+ +---+-------+--------+
| Succeed (Green) | |Fail (Red
| +---------+ |
| | Succeed (Yellow)|
+----+----+ +----+----+ +----+----+
| Count | | Count | | Count |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+----+----+ +----+----+ +----+----+
|Mark AFx1| |Mark AFx2| |Mark AFx3|
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+----+----+ +----+----+ +----+----+
| Random | | Random | | Random |
| Drop | | Drop | | Drop |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+--------+-----------------+-----------------+--------+
| Queue |
+--------------------------+--------------------------+
|
+----+----+
| Rate |
|Scheduler
+----+----+
|
Figure 9a: Typical AF Edge egress interface configuration
using color-blind
Baker, et. al. Standards Track [Page 27]
RFC 3289 Differentiated Services MIB May 2002
+-----------------------------------------------------+
| Classifier |
+--------+--------------------------------------------+
|Green | Yellow |
| | |
+----+----+ +----+----+ |
| Count | | Count | |
| Action +-------+ Action +------------+
+----+----+ Fail +----+----+ Fail |
|Succeed |Succeed |
+----+----+ +----+----+ +----+----+
| Count | | Count | | Count |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+----+----+ +----+----+ +----+----+
|Mark AFx1| |Mark AFx2| |Mark AFx3|
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+----+----+ +----+----+ +----+----+
| Random | | Random | | Random |
| Drop | | Drop | | Drop |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+--------+-----------------+-----------------+--------+
| Queue |
+--------------------------+--------------------------+
|
+----+----+
| Rate |
|Scheduler
+----+----+
|
Figure 9b: Typical AF Edge egress interface configuration
using color-aware
Baker, et. al. Standards Track [Page 28]
RFC 3289 Differentiated Services MIB May 2002
+-----------------------------------------------------+
| Classifier |
+--------+-----------------+-----------------+--------+
| Green | Yellow |
| | |
+----+----+ +----+----+ +----+----+
| Count | | Count | | Count |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+----+----+ +----+----+ +----+----+
| Random | | Random | | Random |
| Drop | | Drop | | Drop |
| Action | | Action | | Action |
+----+----+ +----+----+ +----+----+
| | |
+--------+-----------------+-----------------+--------+
| Queue |
+--------------------------+--------------------------+
|
+----+----+
| Rate |
|Scheduler
+----+----+
|
Figure 10: Typical AF Edge core interface
3.7.2.2. AF Actions On an Egress Edge
For network planning and perhaps for billing purposes,
traffic is normally counted. Therefore, a "count" action,
of an action table entry pointing to a count table entry,
configured
Also, traffic may be marked with an appropriate DSCP. The first
bits per second are marked AFm1, the next S-R bits per second
marked AFm2, and the rest is marked AFm3. It may be that traffic
arriving marked with the same DSCP, but in general, the
complexity of deciding that it is being remarked to the same value
not useful. Therefore, a "mark" action, consisting of an
table entry pointing to a mark table entry, is configured
At this point, the usual case is that traffic is now queued
transmission. The queue uses Active Queue Management, using
algorithm such as RED. Therefore, an Algorithmic Dropper
Baker, et. al. Standards Track [Page 29]
RFC 3289 Differentiated Services MIB May 2002
configured for each AFmn traffic stream, with a slightly lower min
threshold (and possibly lower max-threshold) for the excess
than for the committed traffic
3.7.2.3. AF Rate-based Queuing On an Egress Edge
The queue expected by AF is normally a work-conserving queue.
usually has a specified minimum rate, and may have a maximum
below the bandwidth of the interface. In concept, it will use
much bandwidth as is available to it, but assure the lower bound
Common ways to implement this include various forms of Weighted
Queuing (WFQ) or Weighted Round Robin (WRR). Integrated over
longer interval, these give each class a predictable throughput rate
They differ in that over short intervals they will order
differently. In general, traffic classes that keep traffic in
will tend to absorb latency from queues with lower mean occupancy,
exchange for which they make use of any available capacity
3.7.3. EF Implementation On an Egress Edge
The EF class applies a Single Rate Two Color Meter, dividing
into "conforming" and "excess" groups. The intent, on the
interface at the edge of the network, is to measure and
mark conforming traffic and drop the excess
3.7.3.1. EF Metering On an Egress Edge
A single rate two color (srTCM) meter requires one token bucket.
is therefore configured using a