draft-ietf-diffserv-mib-16.txt   rfc3289.txt 
Internet Engineering Task Force F. Baker Network Working Group F. Baker
Diffserv Working Group Cisco Systems Request for Comments: 3289 Cisco System
INTERNET-DRAFT K. Chan Category: Standards Track K. Chan
Expires May 2002 Nortel Networks Nortel Networks
draft-ietf-diffserv-mib-16.txt A. Smith A. Smith
Allegro Networks Harbour Networks
November 2001 May 2002
Management Information Base for the Management Information Base for the
Differentiated Services Architecture Differentiated Services Architecture
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document specifies an Internet standards track protocol for the
provisions of Section 10 of RFC 2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, and improvements. Please refer to the current edition of the "Internet
its working groups. Note that other groups may also distribute working Official Protocol Standards" (STD 1) for the standardization state
documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This document is a product of the IETF's Differentiated Services Working Copyright Notice
Group. Comments should be addressed to WG's mailing list at
Differentiated Services@ietf.org. The charter for Differentiated
Services may be found at
http://www.ietf.org/html.charters/Differentiated Services-charter.html
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Distribution of this memo is unlimited.
Abstract Abstract
This memo describes an SMIv2 MIB for a device implementing the This memo describes an SMIv2 (Structure of Management Information
Differentiated Services Architecture. It may be used both for version 2) MIB for a device implementing the Differentiated Services
monitoring and configuration of a router or switch capable of Architecture. It may be used both for monitoring and configuration
Differentiated Services functionality. of a router or switch capable of Differentiated Services
functionality.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Table of Contents
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. 1 The SNMP Management Framework ................................. 3
2 Relationship to other working group documents ................. 4
2.1 Relationship to the Informal Management Model for
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 Classifier
Table ...................................................... 9
3.3 Metering Traffic ............................................ 10
3.3.1 diffServMeterTable - The Meter Table ...................... 11
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
1. The SNMP Management Framework 1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2571 [1]. o An overall architecture, described in [RFC 2571].
o Mechanisms for describing and naming objects and events for the o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in Management Information (SMI) is called SMIv1 and is described
RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second in [RFC 1155], [RFC 1212] and [RFC 1215]. The second version,
version, called SMIv2, is described in RFC 2578 [5], RFC 2579 called SMIv2, is described in [RFC 2578], RFC 2579 [RFC 2579]
[6] and RFC 2580 [7]. and [RFC 2580].
o Message protocols for transferring management information. The o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [8]. A second version of the SNMP message is described in [RFC 1157]. A second version of the SNMP
protocol, which is not an Internet standards track protocol, is message protocol, which is not an Internet standards track
called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. protocol, is called SNMPv2c and is described in [RFC 1901] and
The third version of the message protocol is called SNMPv3 and [RFC 1906]. The third version of the message protocol is
described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. called SNMPv3 and is described in [RFC 1906], [RFC 2572] and
[RFC 2574].
o Protocol operations for accessing management information. The o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is first set of protocol operations and associated PDU formats is
described in RFC 1157 [8]. A second set of protocol operations described in [RFC 1157]. A second set of protocol operations
and associated PDU formats is described in RFC 1905 [13]. and associated PDU formats is described in [RFC 1905].
o A set of fundamental applications described in RFC 2573 [14] and o A set of fundamental applications described in [RFC 2573] and
the view-based access control mechanism described in RFC 2575 the view-based access control mechanism described in [RFC
[15]. 2575].
A more detailed introduction to the current SNMP Management Framework A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [16]. can be found in [RFC 2570].
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined using the Management Information Base or MIB. Objects in the MIB are
the mechanisms defined in the SMI. defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A MIB This memo specifies a MIB module that is compliant to the SMIv2. A
conforming to the SMIv1 can be produced through the appropriate MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because there
translation is possible (use of Counter64). Some machine-readable is no translation is possible (use of Counter64). Some machine-
information in SMIv2 will be converted into textual descriptions in readable information in SMIv2 will be converted into textual
SMIv1 during the translation process. However, this loss of machine descriptions in SMIv1 during the translation process. However, this
readable information is not considered to change the semantics of the loss of machine readable information is not considered to change the
MIB. semantics of the MIB.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Relationship to other working group documents 2. Relationship to other working group documents
The Differentiated Services Working Group and related working groups The Differentiated Services Working Group and related working groups
developed other documents, notably the Informal Management Model and the developed other documents, notably the Informal Management Model and
policy configuration paradigm of SNMPCONF. The relationship between the the policy configuration paradigm of SNMPCONF. The relationship
MIB and those documents is clarified here. between the MIB and those documents is clarified here.
2.1. Relationship to the Informal Management Model for Differentiated 2.1. Relationship to the Informal Management Model for Differentiated
Services Router Services Router
This MIB is similar in design to [MODEL], although it can be used to This MIB is similar in design to [MODEL], although it can be used to
build functional data paths that the model would not well describe. The build functional data paths that the model would not well describe.
model conceptually describes ingress and egress interfaces of an n-port The model conceptually describes ingress and egress interfaces of an
router, which may find some interfaces at a network edge and others n-port router, which may find some interfaces at a network edge and
facing into the network core. It describes the configuration and others facing into the network core. It describes the configuration
management of a Differentiated Services interface in terms of one or and management of a Differentiated Services interface in terms of one
more Traffic Conditioning Block (TCB), each containing, arranged in the or more Traffic Conditioning Blocks (TCB), each containing, arranged
specified order, by definition, zero or more classifiers, meters, in the specified order, by definition, zero or more classifiers,
actions, algorithmic droppers, queues and schedulers. Traffic may be meters, actions, algorithmic droppers, queues and schedulers.
classified, and classified traffic may be metered. Each stream of Traffic may be classified, and classified traffic may be metered.
traffic identified by a combination of classifiers and meters may have Each stream of traffic identified by a combination of classifiers and
some set of actions performed on it; it may have dropping algorithms meters may have some set of actions performed on it; it may have
applied and it may ultimately be stored into a queue before being dropping algorithms applied and it may ultimately be stored into a
scheduled out to its next destination, either onto a link or to another queue before being scheduled out to its next destination, either onto
TCB. At times, the treatment for a given packet must have any of those a link or to another TCB. At times, the treatment for a given packet
elements repeated. [MODEL] models this by cascading multiple TCBs, must have any of those elements repeated. [MODEL] models this by
while this MIB describes the policy by directly linking the functional cascading multiple TCBs, while this MIB describes the policy by
data path elements. directly linking the functional data path elements.
The MIB represents this cascade by following the "Next" attributes of The MIB represents this cascade by following the "Next" attributes of
the various elements. They indicate what the next step in the various elements. They indicate what the next step in
Differentiated Services processing will be, whether it be a classifier, Differentiated Services processing will be, whether it be a
meter, action, algorithmic dropper, queue, scheduler or a decision to classifier, meter, action, algorithmic dropper, queue, scheduler or a
now forward a packet. decision to now forward a packet.
The higher level concept of a TCB is not required in the The higher level concept of a TCB is not required in the
parameterization or in the linking together of the individual elements, parameterization or in the linking together of the individual
hence it is not used in the MIB itself and is only mentioned in the text elements, hence it is not used in the MIB itself and is only
for relating the MIB with the [MODEL]. Rather, the MIB models the mentioned in the text for relating the MIB with the [MODEL]. Rather,
individual elements that make up the TCBs. the MIB models the individual elements that make up the TCBs.
This MIB uses the notion of a Data Path to indicate the Differentiated This MIB uses the notion of a Data Path to indicate the
Services processing a packet may experience. The Data Path a packet Differentiated Services processing a packet may experience. The Data
will initially follow is an attribute of the interface in question. The Path a packet will initially follow is an attribute of the interface
Data Path Table provides a starting point for each direction (ingress or in question. The Data Path Table provides a starting point for each
egress) on each interface. A Data Path Table Entry indicates the first direction (ingress or egress) on each interface. A Data Path Table
of possibly multiple elements that will apply Differentiated Services Entry indicates the first of possible multiple elements that will
treatment to the packet. apply Differentiated Services treatment to the packet.
2.2. Relationship to other MIBs and Policy Management 2.2. Relationship to other MIBs and Policy Management
This MIB provides for direct reporting and manipulation of detailed This MIB provides for direct reporting and manipulation of detailed
functional elements. These elements consist of a structural element and functional elements. These elements consist of a structural element
one or more parameter-bearing elements. While this can be cumbersome, and one or more parameter-bearing elements. While this can be
it allows the reuse of parameters. For example, a service provider may cumbersome, it allows the reuse of parameters. For example, a
offer three varieties of contracts, and configure three parameter service provider may offer three varieties of contracts, and
elements. Each such data path on the system may then refer to these configure three parameter elements. Each such data path on the
sets of parameters. The diffServDataPathTable couples each direction on system may then refer to these sets of parameters. The
each interface with the specified data path linkage. The concept of diffServDataPathTable couples each direction on each interface with
"interface" is as defined by InterfaceIndex/ifIndex of the IETF the specified data path linkage. The concept of "interface" is as
Interfaces MIB [IF-MIB]. defined by InterfaceIndex/ifIndex of the IETF Interfaces MIB [IF-
MIB].
Other MIBs and data structure definitions for policy management Other MIBs and data structure definitions for policy management
mechanisms other than SNMP/SMIv2 are likely to exist in the future for mechanisms, other than SNMP/SMIv2 are likely to exist in the future
the purposes of abstracting the model in other ways. An example is the for the purpose of abstracting the model in other ways. An example
Differentiated Services Policy Information Base, [DSPIB]. is the Differentiated Services Policy Information Base, [DSPIB].
In particular, abstractions in the direction of less detailed In particular, abstractions in the direction of less detailed
definitions of Differentiated Services functionality are likely e.g. definitions of Differentiated Services functionality are likely e.g.
some form of "Per-Hop Behavior"-based definition involving a template of some form of "Per-Hop Behavior"-based definition involving a template
detailed object values which is applied to specific instances of objects of detailed object values which is applied to specific instances of
in this MIB semi-automatically. objects in this MIB semi-automatically.
Another possible direction of abstraction is one using a concept of Another possible direction of abstraction is one using a concept of
"roles" (often, but not always, applied to interfaces). In this case, "roles" (often, but not always, applied to interfaces). In this
it may be possible to re-use the object definitions in this MIB, case, it may be possible to re-use the object definitions in this
especially the parameterization tables. The Data Path table will help MIB, especially the parameterization tables. The Data Path table
in the reuse of the data path linkage tables by having the interface will help in the reuse of the data path linkage tables by having the
specific information centralized, allowing easier mechanical replacement interface specific information centralized, allowing easier
of ifIndex by some sort of "roleIndex". This work is ongoing. mechanical replacement of ifIndex by some sort of "roleIndex". This
work is ongoing.
The reuse of parameter blocks on a variety of functional data paths is The reuse of parameter blocks on a variety of functional data paths
intended to simplify network management. In many cases, one could also is intended to simplify network management. In many cases, one could
re-use the structural elements as well; this has the unfortunate side- also re-use the structural elements as well; this has the unfortunate
effect of re-using the counters, so that monitoring information is lost. side-effect of re-using the counters, so that monitoring information
For this reason, the re-use of structural elements is not generally is lost. For this reason, the re-use of structural elements is not
recommended. generally recommended.
3. MIB Overview 3. MIB Overview
The Differentiated Services Architecture does not specify how an The Differentiated Services Architecture does not specify how an
implementation should be assembled. The [MODEL] describes a general implementation should be assembled. The [MODEL] describes a general
approach to implementation design, or to user interface design. Its approach to implementation design, or to user interface design. Its
components could, however, be assembled in a different way. Traffic components could, however, be assembled in a different way. For
conforming to a meter might be run through a second meter, for example, example, traffic conforming to a meter might be run through a second
or reclassified. meter, or reclassified.
This MIB models the same functional data path elements, allowing the This MIB models the same functional data path elements, allowing the
network manager to assemble them in any fashion that meets the relevant network manager to assemble them in any fashion that meets the
policy. These data path elements include Classifiers, Meters, Actions relevant policy. These data path elements include Classifiers,
of various sorts, Queues, and Schedulers. Meters, Actions of various sorts, Queues, and Schedulers.
In many of these tables, a distinction is drawn between the structure of In many of these tables, a distinction is drawn between the structure
the policy (do this, then do that) and the parameters applied to of the policy (do this, then do that) and the parameters applied to
specific policy elements. This is to facilitate configuration, if the specific policy elements. This is to facilitate configuration, if
MIB is used for that. The concept is that a set of parameters, such as the MIB is used for that. The concept is that a set of parameters,
the values that describe a specific token bucket, might be configured such as the values that describe a specific token bucket, might be
once and applied to many interfaces. configured once and applied to many interfaces.
The RowPointer Textual Convention is therefore used in two ways in this The RowPointer Textual Convention is therefore used in two ways in
MIB. It is defined for the purpose of connecting an object to an entry this MIB. It is defined for the purpose of connecting an object to
dynamically; the RowPointer object identifies the first object in the an entry dynamically; the RowPointer object identifies the first
target Entry, and in so doing points to the entire entry. In this MIB, object in the target Entry, and in so doing points to the entire
it is used as a connector between successive functional data path entry. In this MIB, it is used as a connector between successive
elements, and as the link between the policy structure and the functional data path elements, and as the link between the policy
parameters that are used. When used as a connector, it says what structure and the parameters that are used. When used as a
happens "next"; what happens to classified traffic, to traffic connector, it says what happens "next"; what happens to classified
conforming or not conforming to a meter, and so on. When used to traffic, to traffic conforming or not conforming to a meter, and so
indicate the parameters applied in a policy, it says "specifically" what on. When used to indicate the parameters applied in a policy, it
is meant; the structure points to the parameters of its policy. says "specifically" what is meant; the structure points to the
parameters of its policy.
The use of RowPointers as connectors allows for the simple extension of The use of RowPointers as connectors allows for the simple extension
the MIB. The RowPointers, whether "next" or "specific", may point to of the MIB. The RowPointers, whether "next" or "specific", may point
Entries defined in other MIB modules. For example, the only type of to Entries defined in other MIB modules. For example, the only type
meter defined in this MIB is a token bucket meter; if another type of of meter defined in this MIB is a token bucket meter; if another type
meter is required, another MIB could be defined describing that type of of meter is required, another MIB could be defined describing that
meter, and diffServMeterSpecific could point to it. Similarly, if a new type of meter, and diffServMeterSpecific could point to it.
action is required, the "next" pointer of the previous functional Similarly, if a new action is required, the "next" pointer of the
datapath element could point to an Entry defined in another MIB, public previous functional datapath element could point to an Entry defined
or proprietary. in another MIB, public or proprietary.
3.1. Processing Path 3.1. Processing Path
An interface has an ingress and an egress direction, and will generally An interface has an ingress and an egress direction, and will
have a different policy in each direction. As traffic enters an edge generally have a different policy in each direction. As traffic
interface, it may be classified, metered, counted, and marked. Traffic enters an edge interface, it may be classified, metered, counted, and
leaving the same interface might be remarked according to the contract marked. Traffic leaving the same interface might be remarked
with the next network, queued to manage the bandwidth, and so on. As according to the contract with the next network, queued to manage the
[MODEL] points out, the functional datapath elements used on ingress and bandwidth, and so on. As [MODEL] points out, the functional datapath
egress are of the same type, but may be structured in very different elements used on ingress and egress are of the same type, but may be
ways to implement the relevant policies. structured in very different ways to implement the relevant policies.
3.1.1. diffServDataPathTable - The Data Path Table 3.1.1. diffServDataPathTable - The Data Path Table
Therefore, when traffic arrives at an ingress or egress interface, the Therefore, when traffic arrives at an ingress or egress interface,
first step in applying the policy is determining what policy applies. the first step in applying the policy is determining what policy
This MIB does that by providing a table of pointers to the first applies. This MIB does that by providing a table of pointers to the
functional data path element, indexed by interface and direction on that first functional data path element, indexed by interface and
interface. The content of the diffServDataPathEntry is a single direction on that interface. The content of the
RowPointer, which points to that functional data path element. diffServDataPathEntry is a single RowPointer, which points to that
functional data path element.
When diffServDataPathStart in a direction on an interface is undefined When diffServDataPathStart in a direction on an interface is
or is set to zeroDotZero, the implication is that there is no specific undefined or is set to zeroDotZero, the implication is that there is
policy to apply. no specific policy to apply.
3.2. Classifier 3.2. Classifier
Classifiers are used to differentiate among types of traffic. In the Classifiers are used to differentiate among types of traffic. In the
Differentiated Services architecture, one usually discusses a behavior Differentiated Services architecture, one usually discusses a
aggregate identified by the application of one or more Differentiated behavior aggregate identified by the application of one or more
Services Code Points (DSCPs). However, especially at network edges Differentiated Services Code Points (DSCPs). However, especially at
(which include hosts and first hop routers serving hosts), traffic may network edges (which include hosts and first hop routers serving
arrive unmarked or the marks may not be trusted. In these cases, one hosts), traffic may arrive unmarked or the marks may not be trusted.
applies a Multi-Field Classifier, which may select an aggregate as In these cases, one applies a Multi-Field Classifier, which may
coarse as "all traffic", as fine as a specific microflow identified by select an aggregate as coarse as "all traffic", as fine as a specific
IP Addresses, IP Protocol, and TCP or UDP ports, or variety of slices in microflow identified by IP Addresses, IP Protocol, and TCP or UDP
between. ports, or variety of slices in between.
Classifiers can be simple or complex. In a core interface, one would Classifiers can be simple or complex. In a core interface, one would
expect to find simple behavior aggregate classification to be used. expect to find simple behavior aggregate classification to be used.
However, in an edge interface, one might first ask what application is However, in an edge interface, one might first ask what application
being used, meter the arriving traffic, and then apply various policies is being used, meter the arriving traffic, and then apply various
to the non-conforming traffic depending on the Autonomous System number policies to the non-conforming traffic depending on the Autonomous
advertising the destination address. To accomplish such a thing, System number advertising the destination address. To accomplish
traffic must be classified, metered, and then reclassified. To this such a thing, traffic must be classified, metered, and then
end, the MIB defines separate classifiers, which may be applied at any reclassified. To this end, the MIB defines separate classifiers,
point in processing, and may have different content as needed. which may be applied at any point in processing, and may have
different content as needed.
The MIB also allows for ambiguous classification in a structured The MIB also allows for ambiguous classification in a structured
fashion. In the end, traffic classification must be unambiguous; one fashion. In the end, traffic classification must be unambiguous; one
must know for certain what policy to apply to any given packet. must know for certain what policy to apply to any given packet.
However, writing an unambiguous specification is often tedious, while However, writing an unambiguous specification is often tedious, while
writing a specification in steps that permits and excludes various kinds writing a specification in steps that permits and excludes various
of traffic may be simpler and more intuitive. In such a case, the kinds of traffic may be simpler and more intuitive. In such a case,
classification "steps" are enumerated; all classification elements of the classification "steps" are enumerated; all classification
one precedence are applied as if in parallel, and then all elements of one precedence are applied as if in parallel, and then
classification elements of the next precedence. all classification elements of the next precedence.
This MIB defines a single classifier parameter entry, the Multi-field This MIB defines a single classifier parameter entry, the Multi-field
Classifier. A degenerate case of this multi-field classifier is a Classifier. A degenerate case of this multi-field classifier is a
Behavior Aggregate classifier. Other classifiers may be defined in Behavior Aggregate classifier. Other classifiers may be defined in
other MIB modules, to select traffic from a given layer two neighbor or other MIB modules, to select traffic from a given layer two neighbor
a given interface, traffic whose addresses belong to a given BGP or a given interface, traffic whose addresses belong to a given BGP
Community or Autonomous System, and so on. Community or Autonomous System, and so on.
3.2.1. diffServClfrElementTable - The Classifier Element Table 3.2.1. diffServClfrElementTable - The Classifier Element Table
A classifier consists of classifier elements. A classifier element A classifier consists of classifier elements. A classifier element
identifies a specific set of traffic that forms part of a behavior identifies a specific set of traffic that forms part of a behavior
aggregate; other classifier elements within the same classifier may aggregate; other classifier elements within the same classifier may
identify other traffic that also falls into the behavior aggregate. For identify other traffic that also falls into the behavior aggregate.
example, in identifying AF traffic for the aggregate AF1, one might For example, in identifying AF traffic for the aggregate AF1, one
implement separate classifier elements for AF11, AF12, and AF13 within might implement separate classifier elements for AF11, AF12, and AF13
the same classifier and pointing to the same subsequent meter. within the same classifier and pointing to the same subsequent meter.
Generally, one would expect Data Path Entry to point to a classifier Generally, one would expect the Data Path Entry to point to a
(which is to say, a set of one or more classifier elements), although it classifier (which is to say, a set of one or more classifier
may point to something else when appropriate. Reclassification in a elements), although it may point to something else when appropriate.
functional data path is achieved by pointing to another Classifier Entry Reclassification in a functional data path is achieved by pointing to
when appropriate. another Classifier Entry when appropriate.
A classifier element is a structural element, indexed by classifier ID A classifier element is a structural element, indexed by classifier
and element ID. It has a precedence value, allowing for structured ID and element ID. It has a precedence value, allowing for
ambiguity as described above, a "specific" pointer that identifies what structured ambiguity as described above, a "specific" pointer that
rule is to be applied, and a "next" pointer directing traffic matching identifies what rule is to be applied, and a "next" pointer directing
the classifier to the next functional data path element. If the "next" traffic matching the classifier to the next functional data path
pointer is zeroDotZero, the indication is that there is no further element. If the "next" pointer is zeroDotZero, the indication is
differentiated services processing for this behavior aggregate. If the that there is no further differentiated services processing for this
"specific" pointer is zeroDotZero, however, the device is misconfigured. behavior aggregate. However, if the "specific" pointer is
In such a case, the classifier element should be operationally treated zeroDotZero, the device is misconfigured. In such a case, the
as if it were not present. classifier element should be operationally treated as if it were not
present.
When the MIB is used for configuration, diffServClfrNextFree and When the MIB is used for configuration, diffServClfrNextFree and
diffServClfrElementNextFree always contain legal values for diffServClfrElementNextFree always contain legal values for
diffServClfrId and diffServClfrElementId that are not currently used in diffServClfrId and diffServClfrElementId that are not currently used
the system's configuration. The values are validated when creating in the system's configuration. The values are validated when
diffServClfrId and diffServClfrElementId, and in the event of a failure creating diffServClfrId and diffServClfrElementId, and in the event
(which would happen if two managers simultaneously attempted to create of a failure (which would happen if two managers simultaneously
an entry) must be re-read. attempted to create an entry) must be re-read.
3.2.2. diffServMultiFieldClfrTable - The Multi-field Classifier Table 3.2.2. diffServMultiFieldClfrTable - The Multi-field Classifier Table
This MIB defines a single parameter type for classification, the Multi- This MIB defines a single parameter type for classification, the
field Classifier. As a parameter, a filter may be specified once and Multi-field Classifier. As a parameter, a filter may be specified
applied to many interfaces, using diffServClfrElementSpecific. This once and applied to many interfaces, using
filter matches: diffServClfrElementSpecific. This filter matches:
o IP source address prefix, including host, CIDR Prefix, and "any o IP source address prefix, including host, CIDR Prefix, and "any
source address" source address"
o IP destination address prefix, including host, CIDR Prefix, and o IP destination address prefix, including host, CIDR Prefix, and
"any destination address" "any destination address"
o IPv6 Flow ID o IPv6 Flow ID
o IP protocol or "any" o IP protocol or "any"
o TCP/UDP/SCTP source port range, including "any" o TCP/UDP/SCTP source port range, including "any"
o TCP/UDP/SCTP destination port range, including "any" o TCP/UDP/SCTP destination port range, including "any"
o Differentiated Services Code Point o Differentiated Services Code Point
Since port ranges, IP prefixes, or "any" are defined in each case, it is Since port ranges, IP prefixes, or "any" are defined in each case, it
clear that a wide variety of filters can be constructed. The is clear that a wide variety of filters can be constructed. The
Differentiated Services Behavior Aggregate filter is a special case of Differentiated Services Behavior Aggregate filter is a special case
this filter, in which only the DSCP is specified. of this filter, in which only the DSCP is specified.
Other MIB modules may define similar filters in the same way. For Other MIB modules may define similar filters in the same way. For
example, a filter for Ethernet information might define source and example, a filter for Ethernet information might define source and
destination MAC addresses of "any", Ethernet Packet Type, IEEE 802.2 destination MAC addresses of "any", Ethernet Packet Type, IEEE 802.2
SAPs, and IEEE 802.1 priorities. A filter related to policy routing SAPs, and IEEE 802.1 priorities. A filter related to policy routing
might be structured like the diffServMultiFieldClfrTable, but containing might be structured like the diffServMultiFieldClfrTable, but contain
the BGP Communities of the source and destination prefix rather than the the BGP Communities of the source and destination prefix rather than
prefix itself, meaning "any prefix in this community". For such a the prefix itself, meaning "any prefix in this community". For such
filter, a table similar to diffServMultiFieldClfrTable is constructed, a filter, a table similar to diffServMultiFieldClfrTable is
and diffServClfrElementSpecific configured to point to it. constructed, and diffServClfrElementSpecific is configured to point
to it.
When the MIB is used for configuration, diffServMultiFieldClfrNextFree When the MIB is used for configuration,
always contains a legal value for diffServMultiFieldClfrId that is not diffServMultiFieldClfrNextFree always contains a legal value for
currently used in the system's configuration. diffServMultiFieldClfrId that is not currently used in the system's
configuration.
3.3. Metering Traffic 3.3. Metering Traffic
As discussed in [MODEL], a meter and a shaper are functions that operate As discussed in [MODEL], a meter and a shaper are functions that
on opposing ends of a link. A shaper schedules traffic for transmission operate on opposing ends of a link. A shaper schedules traffic for
at specific times in order to approximate a particular line speed or transmission at specific times in order to approximate a particular
combination of line speeds. In its simplest form, if the traffic stream line speed or combination of line speeds. In its simplest form, if
contains constant sized packet, it might transmit one packet per unit the traffic stream contains constant sized packets, it might transmit
time to build the equivalent of a CBR circuit. However, various factors one packet per unit time to build the equivalent of a CBR circuit.
intervene to make the approximation inexact; multiple classes of traffic However, various factors intervene to make the approximation inexact;
may occasionally schedule their traffic at the same time, the variable multiple classes of traffic may occasionally schedule their traffic
length nature of IP traffic may introduce variation, and factors in the at the same time, the variable length nature of IP traffic may
link or physical layer may change traffic timing. A meter integrates introduce variation, and factors in the link or physical layer may
the arrival rate of traffic and determines whether the shaper at the far change traffic timing. A meter integrates the arrival rate of
end was correctly applied, or whether the behavior of the application in traffic and determines whether the shaper at the far end was
question is naturally close enough to such behavior to be acceptable correctly applied, or whether the behavior of the application in
under a given policy. question is naturally close enough to such behavior to be acceptable
under a given policy.
A common type of meter is a Token Bucket meter, such as [srTCM] or A common type of meter is a Token Bucket meter, such as [srTCM] or
[trTCM]. This type of meter assumes the use of a shaper at a previous [trTCM]. This type of meter assumes the use of a shaper at a
node; applications which send at a constant rate when sending may previous node; applications which send at a constant rate when
conform if the token bucket is properly specified. It specifies the sending may conform if the token bucket is properly specified. It
acceptable arrival rate and quantifies the acceptable variability, often specifies the acceptable arrival rate and quantifies the acceptable
by specifying a burst size or an interval; since rate = quantity/time, variability, often by specifying a burst size or an interval; since
specifying any two of those parameters implies the third, and a large rate = quantity/time, specifying any two of those parameters implies
interval provides for a forgiving system. Multiple rates may be the third, and a large interval provides for a forgiving system.
specified, as in AF, such that a subset of the traffic (up to one rate) Multiple rates may be specified, as in AF, such that a subset of the
is accepted with one set of guarantees, and traffic in excess of that traffic (up to one rate) is accepted with one set of guarantees, and
but below another rate has a different set of guarantees. Other types traffic in excess of that but below another rate has a different set
of meters exist as well. of guarantees. Other types of meters exist as well.
One use of a meter is when a service provider sells at most a certain One use of a meter is when a service provider sells at most, a
bit rate to one of its customers, and wants to drop the excess. In such certain bit rate to one of its customers, and wants to drop the
a case, the fractal nature of normal Internet traffic must be reflected excess. In such a case, the fractal nature of normal Internet
in large burst intervals, as TCP frequently sends packet pairs or larger traffic must be reflected in large burst intervals, as TCP frequently
bursts, and responds poorly when more than one packet in a round trip sends packet pairs or larger bursts, and responds poorly when more
interval is dropped. Applications like FTP contain the effect by simply than one packet in a round trip interval is dropped. Applications
staying below the target bit rate; this type of configuration very like FTP contain the effect by simply staying below the target bit
adversely affects transaction applications like HTTP, however. Another rate; this type of configuration very adversely affects transaction
use of a meter is in the AF specification, in which excess traffic is applications like HTTP, however. Another use of a meter is in the AF
marked with a related DSCP and subjected to slightly more active queue specification, in which excess traffic is marked with a related DSCP
depth management. The application is not sharply limited to a and subjected to slightly more active queue depth management. The
contracted rate in such a case, but can be readily contained should its application is not sharply limited to a contracted rate in such a
traffic create a burden. case, but can be readily contained should its traffic create a
burden.
3.3.1. diffServMeterTable - The Meter Table 3.3.1. diffServMeterTable - The Meter Table
The Meter Table is a structural table, specifying a specific functional The Meter Table is a structural table, specifying a specific
data path element. Its entry consists essentially of three RowPointers functional data path element. Its entry consists essentially of
- a "succeed" pointer, for traffic conforming to the meter, a "fail" three RowPointers - a "succeed" pointer, for traffic conforming to
pointer, for traffic not conforming, and a "specific" pointer, to the meter, a "fail" pointer, for traffic not conforming to the meter,
identify the parameters in question. This structure is a bow to SNMP's and a "specific" pointer, to identify the parameters in question.
limitations; it would be better to have a structure with N rates and N+1 This structure is a bow to SNMP's limitations; it would be better to
"next" pointers, with a single algorithm specified. In this case, have a structure with N rates and N+1 "next" pointers, with a single
multiple meter entries connected by the "fail" link are understood to algorithm specified. In this case, multiple meter entries connected
contain the parameters for a specified algorithm, and traffic conforming by the "fail" link are understood to contain the parameters for a
to a given rate follows their "succeed" paths. Within this MIB, only specified algorithm, and traffic conforming to a given rate follows
Token Bucket parameters are specified; other varieties of meters may be their "succeed" paths. Within this MIB, only Token Bucket parameters
designed in other MIB modules. are specified; other varieties of meters may be designed in other MIB
modules.
When the MIB is used for configuration, diffServMeterNextFree always When the MIB is used for configuration, diffServMeterNextFree always
contains a legal value for diffServMeterId that is not currently used in contains a legal value for diffServMeterId that is not currently used
the system's configuration. in the system's configuration.
3.3.2. diffServTBParamTable - The Token Bucket Parameters Table 3.3.2. diffServTBParamTable - The Token Bucket Parameters Table
The Token Bucket Parameters Table is a set of parameters that define a The Token Bucket Parameters Table is a set of parameters that define
Token Bucket Meter. As a parameter, a token bucket may be specified a Token Bucket Meter. As a parameter, a token bucket may be
once and applied to many interfaces, using diffServMeterSpecific. specified once and applied to many interfaces, using
Specifically, several modes of [srTCM] and [trTCM] are addressed. Other diffServMeterSpecific. Specifically, several modes of [srTCM] and
varieties of meters may be specified in other MIB modules. [trTCM] are addressed. Other varieties of meters may be specified in
other MIB modules.
In general, if a Token Bucket has N rates, it has N+1 potential outcomes In general, if a Token Bucket has N rates, it has N+1 potential
- the traffic stream is slower than and therefore conforms to all of the outcomes - the traffic stream is slower than and therefore conforms
rates, it fails the first few but is slower than and therefore conforms to all of the rates, it fails the first few but is slower than and
to the higher rates, or it fails all of them. As such, multi-rate therefore conforms to the higher rates, or it fails all of them. As
meters should specify those rates in monotonically increasing order, such, multi-rate meters should specify those rates in monotonically
passing through the diffServMeterFailNext from more committed to more increasing order, passing through the diffServMeterFailNext from more
excess rates, and finally falling through diffServMeterFailNext to the committed to more excess rates, and finally falling through
set of actions that apply to traffic which conforms to none of the diffServMeterFailNext to the set of actions that apply to traffic
specified rates. diffServTBParamType in the first entry indicates the which conforms to none of the specified rates. diffServTBParamType
algorithm being used. At each rate, diffServTBParamRate is derivable in the first entry indicates the algorithm being used. At each rate,
from diffServTBParamBurstSize and diffServTBParamInterval; a superior diffServTBParamRate is derivable from diffServTBParamBurstSize and
implementation will allow the configuration of any two of diffServTBParamInterval; a superior implementation will allow the
diffServTBParamRate, diffServTBParamBurstSize, and configuration of any two of diffServTBParamRate,
diffServTBParamInterval, and respond with the appropriate error code if diffServTBParamBurstSize, and diffServTBParamInterval, and respond
all three are specified but are not mathematically related. with the appropriate error code if all three are specified but are
not mathematically related.
When the MIB is used for configuration, diffServTBParamNextFree always When the MIB is used for configuration, diffServTBParamNextFree
contains a legal value for diffServTBParamId that is not currently used always contains a legal value for diffServTBParamId that is not
in the system's configuration. currently used in the system's configuration.
3.4. Actions applied to packets 3.4. Actions applied to packets
"Actions" are the things a differentiated services interface PHB may do "Actions" are the things a differentiated services interface PHB may
to a packet in transit. At minimum, such a policy might calculate do to a packet in transit. At a minimum, such a policy might
statistics on traffic in various configured classes, mark it with a calculate statistics on traffic in various configured classes, mark
DSCP, drop it, or enqueue it before passing it on for other processing. it with a DSCP, drop it, or enqueue it before passing it on for other
processing.
Actions are composed of a structural element, the diffServActionTable, Actions are composed of a structural element, the
and various component action entries that may be applied. In the case diffServActionTable, and various component action entries that may be
of the Algorithmic Dropper, an additional parameter table may be applied. In the case of the Algorithmic Dropper, an additional
specified to control Active Queue Management, as defined in [RED93] and parameter table may be specified to control Active Queue Management,
other AQM specifications. as defined in [RED93] and other AQM specifications.
3.4.1. diffServActionTable - The Action Table 3.4.1. diffServActionTable - The Action Table
The action table identifies sequences of actions to be applied to a The action table identifies sequences of actions to be applied to a
packet. Successive actions are chained through diffServActionNext, packet. Successive actions are chained through diffServActionNext,
ultimately terminating in zeroDotZero (indicating that the policy is ultimately resulting in zeroDotZero (indicating that the policy is
complete), a pointer to a queue, or a pointer to some other functional complete), a pointer to a queue, or a pointer to some other
data path element. functional data path element.
When the MIB is used for configuration, diffServActionNextFree always When the MIB is used for configuration, diffServActionNextFree always
contains a legal value for diffServActionId that is not currently used contains a legal value for diffServActionId that is not currently
in the system's configuration. used in the system's configuration.
3.4.2. diffServCountActTable - The Count Action Table 3.4.2. diffServCountActTable - The Count Action Table
The count action accumulates statistics pertaining to traffic passing The count action accumulates statistics pertaining to traffic passing
through a given path through the policy. It is intended to be useful through a given path through the policy. It is intended to be useful
for usage-based billing, for statistical studies, or for analysis of the for usage-based billing, for statistical studies, or for analysis of
behavior of a policy in a given network. The objects in the Count the behavior of a policy in a given network. The objects in the
Action are various counters and a discontinuity time. The counters Count Action are various counters and a discontinuity time. The
display the number of packets and bytes encountered on the path since counters display the number of packets and bytes encountered on the
the discontinuity time. They share the same discontinuity time, which path since the discontinuity time. They share the same discontinuity
is the discontinuity time of the interface or agent. time, which is the discontinuity time of the interface or agent.
The designers of this MIB expect that every path through a policy should The designers of this MIB expect that every path through a policy
have a corresponding counter. In early versions, it was impossible to should have a corresponding counter. In early versions, it was
configure an action without implementing a counter, although the current impossible to configure an action without implementing a counter,
design makes them in effect the network manager's option, as a result of although the current design makes them in effect the network
making actions consistent in structure and extensible. The assurance of manager's option, as a result of making actions consistent in
proper debug and accounting is therefore left with the policy designer. structure and extensibility. The assurance of proper debugging and
accounting is therefore left with the policy designer.
When the MIB is used for configuration, diffServCountActNextFree always When the MIB is used for configuration, diffServCountActNextFree
contains a legal value for diffServCountActId that is not currently used always contains a legal value for diffServCountActId that is not
in the system's configuration. currently used in the system's configuration.
3.4.3. diffServDscpMarkActTable - The Mark Action Table 3.4.3. diffServDscpMarkActTable - The Mark Action Table
The Mark Action table is an unusual table, both in SNMP and in this MIB. The Mark Action table is an unusual table, both in SNMP and in this
It might be viewed not so much as an array of single-object entries as MIB. It might be viewed not so much as an array of single-object
an array of OBJECT-IDENTIFIER conventions, as the OID for a entries as an array of OBJECT-IDENTIFIER conventions, as the OID for
diffServDscpMarkActDscp instance conveys all of the necessary a diffServDscpMarkActDscp instance conveys all of the necessary
information: packets are to be marked with the requisite DSCP. information: packets are to be marked with the requisite DSCP.
As such, contrary to common practice, the index for the table is read- As such, contrary to common practice, the index for the table is
only, and is both the Entry's index and its only value. read- only, and is both the Entry's index and its only value.
3.4.4. diffServAlgDropTable - The Algorithmic Drop Table 3.4.4. diffServAlgDropTable - The Algorithmic Drop Table
The Algorithmic Drop Table identifies a dropping algorithm, drops The Algorithmic Drop Table identifies a dropping algorithm, drops
packets, and counts the drops. Classified as an action, it is in effect packets, and counts the drops. Classified as an action, it is in
a method which applies a packet to a queue, and may modify either. When effect a method which applies a packet to a queue, and may modify
the algorithm is "always drop", this is simple; when the algorithm calls either. When the algorithm is "always drop", this is simple; when
for head-drop, tail-drop, or a variety of Active Queue Management, the the algorithm calls for head-drop, tail-drop, or a variety of Active
queue is inspected, and in the case of Active Queue Management, Queue Management, the queue is inspected, and in the case of Active
additional parameters are required. Queue Management, additional parameters are REQUIRED.
What may not be clear from the name is that an Algorithmic Drop action What may not be clear from the name is that an Algorithmic Drop
often does not drop traffic. Algorithms other than "always drop" action often does not drop traffic. Algorithms other than "always
normally drop a few percent of packets at most. The action inspects the drop" normally drop a few percent of packets at most. The action
diffServQEntry that diffServAlgDropQMeasure points to in order to inspects the diffServQEntry that diffServAlgDropQMeasure points to in
determine whether the packet should be dropped. order to determine whether the packet should be dropped.
When the MIB is used for configuration, diffServAlgDropNextFree always When the MIB is used for configuration, diffServAlgDropNextFree
contains a legal value for diffServAlgDropId that is not currently used always contains a legal value for diffServAlgDropId that is not
in the system's configuration. currently used in the system's configuration.
3.4.5. diffServRandomDropTable - The Random Drop Parameters Table 3.4.5. diffServRandomDropTable - The Random Drop Parameters Table
The Random Drop Table is an extension of the Algorithmic Drop Table The Random Drop Table is an extension of the Algorithmic Drop Table
intended for use on queues whose depth is actively managed. Active intended for use on queues whose depth is actively managed. Active
Queue Management algorithms are typified by [RED93], but the parameters Queue Management algorithms are typified by [RED93], but the
they use vary. It was deemed for the purposes of this MIB that the parameters they use vary. It was deemed for the purposes of this MIB
proper values to represent include: that the proper values to represent include:
o Target case mean queue depth, expressed in bytes or packets o Target case mean queue depth, expressed in bytes or packets
o Worst case mean queue depth, expressed in bytes or packets o Worst case mean queue depth, expressed in bytes or packets
o Maximum drop rate expressed as drops per thousand
o Coefficient of an exponentially weighted moving average, o Maximum drop rate expressed as drops per thousand
expressed as the numerator of a fraction whose denominator is
65536.
o Sampling rate o Coefficient of an exponentially weighted moving average,
expressed as the numerator of a fraction whose denominator is
65536.
An example of the representation chosen in this MIB for this element is o Sampling rate
shown in Figure 1.
Random droppers often have their drop probability function described as An example of the representation chosen in this MIB for this element
a plot of drop probability (P) against averaged queue length (Q). is shown in Figure 1.
(Qmin,Pmin) then defines the start of the characteristic plot. Normally
Pmin=0, meaning with average queue length below Qmin, there will be no
drops. (Qmax,Pmax) defines a "knee" on the plot, after which point the
drop probability become more progressive (greater slope). (Qclip,1)
defines the queue length at which all packets will be dropped. Notice
this is different from Tail Drop because this uses an averaged queue
length, although it is possible for Qclip to equal Qmax.
In the MIB module, diffServRandomDropMinThreshBytes and Random droppers often have their drop probability function described
diffServRandomDropMinThreshPkts represent Qmin. as a plot of drop probability (P) against averaged queue length (Q).
diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPkts (Qmin,Pmin) then defines the start of the characteristic plot.
represent Qmax. diffServAlgDropQThreshold represents Qclip. Normally Pmin=0, meaning with average queue length below Qmin, there
diffServRandomDropInvProbMax represents Pmax (inverse). This MIB does will be no drops. (Qmax,Pmax) defines a "knee" on the plot, after
not represent Pmin (assumed to be zero unless otherwise represented). which point the drop probability becomes more progressive (greater
In addition, since message memory is finite, queues generally have some slope). (Qclip,1) defines the queue length at which all packets will
upper bound above which they are incapable of storing additional be dropped. Notice this is different from Tail Drop because this
traffic. Normally this number is equal to Qclip, specified by uses an averaged queue length, although it is possible for Qclip to
equal Qmax.
In the MIB module, diffServRandomDropMinThreshBytes and
diffServRandomDropMinThreshPkts represent Qmin.
diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPkts
represent Qmax. diffServAlgDropQThreshold represents Qclip.
diffServRandomDropInvProbMax represents Pmax (inverse). This MIB
does not represent Pmin (assumed to be zero unless otherwise
represented). In addition, since message memory is finite, queues
generally have some upper bound above which they are incapable of
storing additional traffic. Normally this number is equal to Qclip,
specified by diffServAlgDropQThreshold.
AlgDrop Queue AlgDrop Queue
+-----------------+ +-------+ +-----------------+ +-------+
--->| Next ---------+--+------------------->| Next -+--> ... --->| Next ---------+--+------------------->| Next -+--> ...
| QMeasure -------+--+ | ... | | QMeasure -------+--+ | ... |
| QThreshold | RandomDrop +-------+ | QThreshold | RandomDrop +-------+
| Type=randomDrop | +----------------+ | Type=randomDrop | +----------------+
| Specific -------+---->| MinThreshBytes | | Specific -------+---->| MinThreshBytes |
+-----------------+ | MaxThreshBytes | +-----------------+ | MaxThreshBytes |
| ProbMax | | ProbMax |
| Weight | | Weight |
| SamplingRate | | SamplingRate |
+----------------+ +----------------+
Figure 1: Example Use of the RandomDropTable for Random Droppers Figure 1: Example Use of the RandomDropTable for Random Droppers
diffServAlgDropQThreshold.
Each random dropper specification is associated with a queue. This Each random dropper specification is associated with a queue. This
allows multiple drop processes (of same or different types) to be allows multiple drop processes (of same or different types) to be
associated with the same queue, as different PHB implementations may associated with the same queue, as different PHB implementations may
require. This also allows for sequences of multiple droppers if require. This also allows for sequences of multiple droppers if
necessary. necessary.
The calculation of a smoothed queue length may also have an important The calculation of a smoothed queue length may also have an important
bearing on the behavior of the dropper: parameters may include the bearing on the behavior of the dropper: parameters may include the
sampling interval or rate, and the weight of each sample. The sampling interval or rate, and the weight of each sample. The
performance may be very sensitive to the values of these parameters and performance may be very sensitive to the values of these parameters
a wide range of possible values may be required due to a wide range of and a wide range of possible values may be required due to a wide
link speeds. Most algorithms include a sample weight, represented here range of link speeds. Most algorithms include a sample weight,
by diffServRandomDropWeight. The availability of represented here by diffServRandomDropWeight. The availability of
diffServRandomDropSamplingRate as readable is important, the information diffServRandomDropSamplingRate as readable is important, the
provided by Sampling Rate is essential to the configuration of information provided by Sampling Rate is essential to the
diffServRandomDropWeight. Having Sampling Rate be configurable is also configuration of diffServRandomDropWeight. Having Sampling Rate be
helpful, as line speed increases, the ability to have queue sampling be configurable is also helpful, as line speed increases, the ability to
less frequent than packet arrival is needed. Note, however, that there have queue sampling be less frequent than packet arrival is needed.
is ongoing research on this topic, see e.g. [ACTQMGMT] and [AQMROUTER]. 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 Additional parameters may be added in an enterprise MIB module, e.g.
using AUGMENTS on this table, to handle aspects of random drop by using AUGMENTS on this table, to handle aspects of random drop
algorithms that are not standardized here. algorithms that are not standardized here.
When the MIB is used for configuration, diffServRandomDropNextFree When the MIB is used for configuration, diffServRandomDropNextFree
always contains a legal value for diffServRandomDropId that is not always contains a legal value for diffServRandomDropId that is not
currently used in the system's configuration. currently used in the system's configuration.
3.5. Queuing and Scheduling of Packets 3.5. Queuing and Scheduling of Packets
These include Queues and Schedulers, which are inter-related in their These include Queues and Schedulers, which are inter-related in their
use of queuing techniques. By doing so, it is possible to build multi- use of queuing techniques. By doing so, it is possible to build
level schedulers, such as those which treat a set of queues as having multi-level schedulers, such as those which treat a set of queues as
priority among them, and at a specific priority find a secondary WFQ having priority among them, and at a specific priority find a
scheduler with some number of queues. secondary WFQ scheduler with some number of queues.
3.5.1. diffServQTable - The Class or Queue Table 3.5.1. diffServQTable - The Class or Queue Table
The Queue Table models simple FIFO queues. The Scheduler Table allows The Queue Table models simple FIFO queues. The Scheduler Table
flexibility in constructing both simple and somewhat more complex allows flexibility in constructing both simple and somewhat more
queuing hierarchies from those queues. complex queuing hierarchies from those queues.
Queue Table entries are pointed at by the "next" attributes of the Queue Table entries are pointed at by the "next" attributes of the
upstream elements, such as diffServMeterSucceedNext or upstream elements, such as diffServMeterSucceedNext or
diffServActionNext. Note that multiple upstream elements may direct diffServActionNext. Note that multiple upstream elements may direct
their traffic to the same Queue Table entry. For example, the Assured their traffic to the same Queue Table entry. For example, the
Forwarding PHB suggests that all traffic marked AF11, AF12 or AF13 be Assured Forwarding PHB suggests that all traffic marked AF11, AF12 or
placed in the same queue, after metering, without reordering. To AF13 be placed in the same queue, after metering, without reordering.
accomplish that, the upstream diffServAlgDropNext pointers each point to To accomplish that, the upstream diffServAlgDropNext pointers each
the same diffServQEntry. point to the same diffServQEntry.
A common requirement of a queue is that its traffic enjoy a certain A common requirement of a queue is that its traffic enjoy a certain
minimum or maximum rate, or that it be given a certain priority. minimum or maximum rate, or that it be given a certain priority.
Functionally, the selection of such is a function of a scheduler. The Functionally, the selection of such is a function of a scheduler.
parameter is associated with the queue, however, using the Minimum or The parameter is associated with the queue, however, using the
Maximum Rate Parameters Table. Minimum or Maximum Rate Parameters Table.
When the MIB is used for configuration, diffServQNextFree always When the MIB is used for configuration, diffServQNextFree always
contains a legal value for diffServQId that is not currently used in the contains a legal value for diffServQId that is not currently used in
system's configuration. the system's configuration.
3.5.2. diffServSchedulerTable - The Scheduler Table 3.5.2. diffServSchedulerTable - The Scheduler Table
The scheduler, and therefore the Scheduler Table, accepts inputs from The scheduler, and therefore the Scheduler Table, accepts inputs from
either queues or a preceding scheduler. The Scheduler Table allows either queues or a preceding scheduler. The Scheduler Table allows
flexibility in constructing both simple and somewhat more complex flexibility in constructing both simple and somewhat more complex
queuing hierarchies from those queues. queuing hierarchies from those queues.
When the MIB is used for configuration, diffServSchedulerNextFree always When the MIB is used for configuration, diffServSchedulerNextFree
contains a legal value for diffServSchedulerId that is not currently always contains a legal value for diffServSchedulerId that is not
used in the system's configuration. currently used in the system's configuration.
3.5.3. diffServMinRateTable - The Minimum Rate Table 3.5.3. diffServMinRateTable - The Minimum Rate Table
When the output rate of a queue or scheduler must be given a minimum When the output rate of a queue or scheduler must be given a minimum
rate or a priority, this is done using the diffServMinRateTable. Rates rate or a priority, this is done using the diffServMinRateTable.
may be expressed as absolute rates, or as a fraction of ifSpeed, and
imply the use of a rate-based scheduler such as WFQ or WRR. The use of
a priority implies the use of a Priority Scheduler. Only one of the
Absolute or Relative rate need be set; the other takes the relevant
value as a result. Excess capacity is distributed proportionally among
the inputs to a scheduler using the assured rate. More complex
functionality may be described by augmenting this MIB.
When a priority scheduler is used, its effect is to give the queue the Rates may be expressed as absolute rates, or as a fraction of
entire capacity of the subject interface less the capacity used by ifSpeed, and imply the use of a rate-based scheduler such as WFQ or
higher priorities, if there is traffic present to use it. This is true WRR. The use of a priority implies the use of a Priority Scheduler.
regardless of the rate specifications applied to that queue or other Only one of the Absolute or Relative rates needs to be set; the other
queues on the interface. Policing excess traffic will mitigate this takes the relevant value as a result. Excess capacity is distributed
behavior. proportionally among the inputs to a scheduler using the assured
rate. More complex functionality may be described by augmenting this
MIB.
When the MIB is used for configuration, diffServMinRateNextFree always When a priority scheduler is used, its effect is to give the queue
contains a legal value for diffServMinRateId that is not currently used the entire capacity of the subject interface less the capacity used
in the system's configuration. by higher priorities, if there is traffic present to use it. This is
true regardless of the rate specifications applied to that queue or
other queues on the interface. Policing excess traffic will mitigate
this behavior.
When the MIB is used for configuration, diffServMinRateNextFree
always contains a legal value for diffServMinRateId that is not
currently used in the system's configuration.
3.5.4. diffServMaxRateTable - The Maximum Rate Table 3.5.4. diffServMaxRateTable - The Maximum Rate Table
When the output rate of a queue or scheduler must be limited to at most When the output rate of a queue or scheduler must be limited to at
a specified maximum rate, this is done using the diffServMaxRateTable. most a specified maximum rate, this is done using the
Rates may be expressed as absolute rates, or as a fraction of ifSpeed. diffServMaxRateTable. Rates may be expressed as absolute rates, or
Only one of the Absolute or Relative rate need be set; the other takes as a fraction of ifSpeed. Only one of the Absolute or Relative rate
the relevant value as a result. needs to be set; the other takes the relevant value as a result.
The definition of a multirate shaper requires multiple The definition of a multirate shaper requires multiple
diffServMaxRateEntries. In this case, an algorithm such as [SHAPER] is diffServMaxRateEntries. In this case, an algorithm such as [SHAPER]
used. In that algorithm, more than one rate is specified, and at any is used. In that algorithm, more than one rate is specified, and at
given time traffic is shaped to the lowest specified rate which exceeds any given time traffic is shaped to the lowest specified rate which
the arrival rate of traffic. exceeds the arrival rate of traffic.
When the MIB is used for configuration, diffServMaxRateNextFree always When the MIB is used for configuration, diffServMaxRateNextFree
contains a legal value for diffServMaxRateId that is not currently used always contains a legal value for diffServMaxRateId that is not
in the system's configuration. currently used in the system's configuration.
3.5.5. Using queues and schedulers together 3.5.5. Using queues and schedulers together
For representing a Strict Priority scheduler, each scheduler input is For representing a Strict Priority scheduler, each scheduler input is
assigned a priority with respect to all the other inputs feeding the assigned a priority with respect to all the other inputs feeding the
same scheduler, with default values for the other parameters. Higher- same scheduler, with default values for the other parameters.
priority traffic that is not being delayed for shaping will be serviced Higher-priority traffic that is not being delayed for shaping will be
before a lower-priority input. An example is found in Figure 2. serviced before a lower-priority input. An example is found in
Figure 2.
For weighted scheduling methods, such as WFQ or WRR, the "weight" of a For weighted scheduling methods, such as WFQ or WRR, the "weight" of
given scheduler input is represented with a Minimum Service Rate leaky- a given scheduler input is represented with a Minimum Service Rate
bucket profile which provides guaranteed minimum bandwidth to that leaky-bucket profile which provides a guaranteed minimum bandwidth to
input, if required. This is represented by a rate that input, if required. This is represented by a rate
diffServMinRateAbsolute; the classical weight is the ratio between that diffServMinRateAbsolute; the classical weight is the ratio between
rate and the interface speed, or perhaps the ratio between that rate and that rate and the interface speed, or perhaps the ratio between that
the sum of the configured rates for classes. The rate may be rate and the sum of the configured rates for classes. The rate may
represented by a relative value, as a fraction of the interface's be represented by a relative value, as a fraction of the interface's
current line rate, diffServMinRateRelative, to assist in cases where current line rate, diffServMinRateRelative, to assist in cases where
line rates are variable or where a higher-level policy might be line rates are variable or where a higher-level policy might be
expressed in terms of fractions of network resources. The two rate expressed in terms of fractions of network resources. The two rate
parameters are inter-related and changes in one may be reflected in the parameters are inter-related and changes in one may be reflected in
+-----+ 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 queues +-----+
+-------+ | P S |
| Queue +------------>+ r c |
+-------+-+--------+ | i h |
|Priority| | o e |
+--------+ | r d +----------->
+-------+ | i u |
| Queue +------------>+ t l |
+-------+-+--------+ | y e |
|Priority| | r |
+--------+ +-----+
other. An example is found in figure 3. Figure 2: Priority Scheduler with two queues
For weighted scheduling methods, one can say loosely, that WRR focuses For weighted scheduling methods, one can say loosely, that WRR
on meeting bandwidth sharing, without concern for relative delay amongst focuses on meeting bandwidth sharing, without concern for relative
the queues; where WFQ controls both queue the service order and the delay amongst the queues; where WFQ controls both queue the service
amount of traffic serviced, providing bandwidth sharing and relative order and the amount of traffic serviced, providing bandwidth sharing
delay ordering amongst the queues. and relative delay ordering amongst the queues.
A queue or scheduled set of queues (which is an input to a scheduler) 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 may also be capable of acting as a non-work-conserving [MODEL]
shaper: this is done by defining a Maximum Service Rate leaky-bucket traffic shaper: this is done by defining a Maximum Service Rate
profile in order to limit the scheduler bandwidth available to that leaky-bucket profile in order to limit the scheduler bandwidth
input. This is represented by a rate, in diffServMaxRateAbsolute; the available to that input. This is represented by a rate, in
classical weight is the ratio between that rate and the interface speed, diffServMaxRateAbsolute; the classical weight is the ratio between
that rate and the interface speed, or perhaps the ratio between that
rate and the sum of the configured rates for classes. The rate may
be represented by a relative value, as a fraction of the interface's
current line rate, diffServMaxRateRelative. This MIB presumes that
shaping is something a scheduler does to its inputs, which it models
as a queue with a maximum rate or a scheduler whose output has a
maximum rate.
+-----+ +-----+
+-------+ | W S | +-------+ | W S |
| Queue +------------>+ R c | | Queue +------------>+ R c |
+-------+-+--------+ | R h | +-------+-+--------+ | R h |
| Rate | | e | | Rate | | e |
+--------+ | o d +-----------> +--------+ | o d +----------->
+-------+ | r u | +-------+ | r u |
| Queue +------------>+ l | | Queue +------------>+ l |
+-------+-+--------+ | W e | +-------+-+--------+ | W e |
| Rate | | F r | | Rate | | F r |
+--------+ | Q | +--------+ | Q |
+-----+ +-----+
Figure 3: WRR or WFQ rate-based scheduler with two inputs Figure 3: WRR or WFQ rate-based scheduler with two inputs
or perhaps the ratio between that rate and the sum of the configured
rates for classes. The rate may be represented by a relative value, as
a fraction of the interface's current line rate,
diffServMaxRateRelative. This MIB presumes that shaping is something a
scheduler does to its inputs, which it models as a queue with a maximum
rate or a scheduler whose output has a maximum rate.
The same may be done on a queue, if a given class is to be shaped to a The same may be done on a queue, if a given class is to be shaped to
maximum rate without shaping other classes, as in Figure 5. a maximum rate without shaping other classes, as in Figure 5.
Other types of priority and weighted scheduling methods can be defined Other types of priority and weighted scheduling methods can be
using existing parameters in diffServMinRateEntry. NOTE: defined using existing parameters in diffServMinRateEntry. NOTE:
diffServSchedulerMethod uses OBJECT IDENTIFIER syntax, with the diffServSchedulerMethod uses OBJECT IDENTIFIER syntax, with the
different types of scheduling methods defined as OBJECT-IDENTITY. different types of scheduling methods defined as OBJECT-IDENTITY.
+---+ +---+
+-------+ | S | +-------+ | S |
| Queue +------------>+ c | | Queue +------------>+ c |
+-------+-+--------+ | h | +-------+-+--------+ | h |
| | | e +-----------> | | | e +----------->
+--------+ | d +-+-------+ +--------+ | d +-+-------+
| u | |Shaping| | u | |Shaping|
+-------+ | l | | Rate | +-------+ | l | | Rate |
| Queue +------------>+ e | +-------+ | Queue +------------>+ e | +-------+
+-------+-+--------+ | r | +-------+-+--------+ | r |
| | +---+ | | +---+
+--------+ +--------+
Figure 4: Shaping scheduled traffic to a known rate Figure 4: Shaping scheduled traffic to a known rate
+---+
+-------+ | 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 scheduler
+-------+ | 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 scheduler
Future scheduling methods may be defined in other MIBs. This requires
an OBJECT-IDENTITY definition, a description of how the existing objects
are reused, if they are, and any new objects they require.
To implement an EF and two AF classes, one must use a combination of Future scheduling methods may be defined in other MIBs. This
priority and WRR/WFQ scheduling. This requires us to cascade two requires an OBJECT-IDENTITY definition, a description of how the
schedulers. If one were to additionally shape the output of the system existing objects are reused, if they are, and any new objects they
to a rate lower than the interface rate, one must place an upper bound require.
rate on the output of the priority scheduler. See figure 6.
To implement an EF and two AF classes, one must use a combination of
priority and WRR/WFQ scheduling. This requires us to cascade two
schedulers. If one were to additionally shape the output of the
system to a rate lower than the interface rate, one must place an
upper bound rate on the output of the priority scheduler. See figure
6.
3.6. Example configuration for AF and EF 3.6. Example configuration for AF and EF
For the sake of argument, let us build an example with one EF class and For the sake of argument, let us build an example with one EF class
four AF classes using the constructs in this MIB. and four AF classes using the constructs in this MIB.
3.6.1. AF and EF Ingress Interface Configuration 3.6.1. AF and EF Ingress Interface Configuration
The ingress edge interface identifies traffic into classes, meters it, The ingress edge interface identifies traffic into classes, meters
and ensures that any excess is appropriately dealt with according to the it, and ensures that any excess is appropriately dealt with according
PHB. For AF, this means marking excess; for EF, it means dropping to the PHB. For AF, this means marking excess; for EF, it means
excess or shaping it to a maximum rate. dropping excess or shaping it to a maximum rate.
+-----+ +-----+
+-------+ | P S | +-------+ | P S |
| Queue +---------------------------------->+ r c | | Queue +---------------------------------->+ r c |
+-------+----------------------+--------+ | i h | +-------+----------------------+--------+ | i h |
|Priority| | o e +-----------> |Priority| | o e +----------->
+--------+ | r d +-+-------+ +--------+ | r d +-+-------+
+------+ | i u | |Shaping| +------+ | i u | |Shaping|
+-------+ | W S +------------->+ t l | | Rate | +-------+ | W S +------------->+ t l | | Rate |
| Queue +------------>+ R c +-+--------+ | y e | +-------+ | Queue +------------>+ R c +-+--------+ | y e | +-------+
+-------+-+--------+ | R h | |Priority| | r | +-------+-+--------+ | R h | |Priority| | r |
|Min Rate| | e | +--------+ +-----+ |Min Rate| | e | +--------+ +-----+
+--------+ | o d | +--------+ | o d |
+-------+ | r u | +-------+ | r u |
| Queue +------------>+ l | | Queue +------------>+ l |
+-------+-+--------+ | W e | +-------+-+--------+ | W e |
|Min Rate| | F r | |Min Rate| | F r |
+--------+ | Q | +--------+ | Q |
+------+ +------+
Figure 6: Combined EF and AF services using cascaded schedulers. Figure 6: Combined EF and AF services using cascaded schedulers.
+-----------------------+ +-----------------------+
| diffServDataPathStart | | diffServDataPathStart |
+-----------+-----------+ +-----------+-----------+
| |
+----------+ +----------+
| |
+--+--+ +-----+ +-----+ +-----+ +-----+ +--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF | | AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM| |trTCM| |trTCM| |trTCM| |trTCM| |srTCM|
|Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter|
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | | ||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+ +-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+ |+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions| ||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions|
+||Actions| +||Actions| +||Actions| +||Actions| +| | +||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+ +| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ | +-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| | ||| ||| ||| ||| |
VVV VVV VVV VVV V VVV VVV VVV VVV V
Accepted traffic is sent to IP forwarding Accepted traffic is sent to IP forwarding
Figure 7: combined EF and AF implementation, ingress side Figure 7: combined EF and AF implementation, ingress side
3.6.1.1. Classification In The Example 3.6.1.1. Classification In The Example
A packet arriving at an ingress interface picks up its policy from the A packet arriving at an ingress interface picks up its policy from
diffServDataPathTable. This points to a classifier, which will select the diffServDataPathTable. This points to a classifier, which will
traffic according to some specification for each traffic class. select traffic according to some specification for each traffic
class.
An example of a classifier for an AFm class would be a set of three An example of a classifier for an AFm class would be a set of three
classifier elements, each pointing to a Multi-field classification classifier elements, each pointing to a Multi-field classification
parameter block identifying one of the AFmn DSCPs. Alternatively, the parameter block identifying one of the AFmn DSCPs. Alternatively,
filters might contain selectors for HTTP traffic or some other the filters might contain selectors for HTTP traffic or some other
application. application.
An example of a classifier for EF traffic might be either a classifier An example of a classifier for EF traffic might be a classifier
element pointing to a filter specifying the EF code point, or a element pointing to a filter specifying the EF code point, a
collection of classifiers with parameter blocks specifying individual collection of classifiers with parameter blocks specifying individual
telephone calls, or a variety of other approaches. telephone calls, or a variety of other approaches.
Typically, of course, a classifier identifies a variety of traffic and Typically, of course, a classifier identifies a variety of traffic
breaks it up into separate classes. It might very well contain fourteen and breaks it up into separate classes. It might very well contain
classifier elements indicating the twelve AFmn DSCP values, EF, and fourteen classifier elements indicating the twelve AFmn DSCP values,
"everything else". These would presumably direct traffic down six EF, and "everything else". These would presumably direct traffic
functional data paths: one for each AF or EF class, and one for all down six functional data paths: one for each AF or EF class, and one
other traffic. for all other traffic.
3.6.1.2. AF Implementation On an Ingress Edge Interface 3.6.1.2. AF Implementation On an Ingress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. These groups of traffic conform to both specified into three groups. These groups of traffic conform to both specified
rates, only the higher one, or none. The intent, on the ingress rates, only the higher one, or none. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately interface at the edge of the network, is to measure and appropriately
mark traffic. mark traffic.
3.6.1.2.1. AF Metering On an Ingress Edge Interface 3.6.1.2.1. AF Metering On an Ingress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. If two rates R and S, with R < S, are specified and into three groups. If two rates R and S, where R < S, are specified
traffic arrives at rate T, traffic comprising up to R bits per second is and traffic arrives at rate T, traffic comprising up to R bits per
considered to conform to the "confirmed" rate, R. If R < T, traffic second is considered to conform to the "confirmed" rate, R. If
comprising up to S-R bits per second is considered to conform to the R < T, traffic comprising up to S-R bits per second is considered to
"excess" rate, S. Any further excess is non-conformant. conform to the "excess" rate, S. Any further excess is non-
conformant.
Two meter entries are used to configure this, one for the conforming Two meter entries are used to configure this, one for the conforming
rate and one for the excess rate. The rate parameters are stored in rate and one for the excess rate. The rate parameters are stored in
associated Token Bucket Parameter Entries. The "FailNext" pointer of associated Token Bucket Parameter Entries. The "FailNext" pointer of
the lower rate Meter Entry points to the other Meter Entry; both the lower rate Meter Entry points to the other Meter Entry; both
"SucceedNext" pointers and the "FailNext" pointer of the higher Meter "SucceedNext" pointers and the "FailNext" pointer of the higher Meter
Entry point to lists of actions. In the color-blind mode, all three Entry point to lists of actions. In the color-blind mode, all three
classifier "next" entries point to the lower rate meter entry. In the classifier "next" entries point to the lower rate meter entry. In
color-aware mode, the AFm1 classifier points to the lower rate entry, the color-aware mode, the AFm1 classifier points to the lower rate
the AFm2 classifier points to the higher rate entry (as it is only entry, the AFm2 classifier points to the higher rate entry (as it is
compared against that rate), and the AFm3 classifier points directly to only compared against that rate), and the AFm3 classifier points
the actions taken when both rates fail. directly to the actions taken when both rates fail.
3.6.1.2.2. AF Actions On an Ingress Edge Interface 3.6.1.2.2. AF Actions On an Ingress Edge Interface
For network planning and perhaps for billing purposes, arriving traffic For network planning and perhaps for billing purposes, arriving
is normally counted. Therefore, a "count" action, consisting of an traffic is normally counted. Therefore, a "count" action, consisting
action table entry pointing to a count table entry, is configured. of an action table entry pointing to a count table entry, is
configured.
Also, traffic is marked with the appropriate DSCP. The first R bits per Also, traffic is marked with the appropriate DSCP. The first R bits
second are marked AFm1, the next S-R bits per second are marked AFm2, per second are marked AFm1, the next S-R bits per second are marked
and the rest is marked AFm3. It may be that traffic is arriving marked AFm2, and the rest is marked AFm3. It may be that traffic is
with the same DSCP, but in general, the additional complexity of arriving marked with the same DSCP, but in general, the additional
deciding that it is being remarked to the same value is not useful. complexity of deciding that it is being remarked to the same value is
Therefore, a "mark" action, consisting of an action table entry pointing not useful. Therefore, a "mark" action, consisting of an action
to a mark table entry, is configured. table entry pointing to a mark table entry, is configured.
At this point, the usual case is that traffic is now forwarded in the At this point, the usual case is that traffic is now forwarded in the
usual manner. To indicate this, the "SucceedNext" pointer of the Mark usual manner. To indicate this, the "SucceedNext" pointer of the
Action is set to zeroDotZero. Mark Action is set to zeroDotZero.
3.6.1.3. EF Implementation On an Ingress Edge Interface 3.6.1.3. EF Implementation On an Ingress Edge Interface
The EF class applies a Single Rate Two Color Meter, dividing traffic The EF class applies a Single Rate Two Color Meter, dividing traffic
into "conforming" and "excess" groups. The intent, on the ingress into "conforming" and "excess" groups. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately interface at the edge of the network, is to measure and appropriately
mark conforming traffic and drop the excess. mark conforming traffic and drop the excess.
3.6.1.3.1. EF Metering On an Ingress Edge Interface 3.6.1.3.1. EF Metering On an Ingress Edge Interface
A single rate two color (srTCM) meter requires one token bucket. It is A single rate two color (srTCM) meter requires one token bucket. It
therefore configured using a single meter entry with a corresponding is therefore configured using a single meter entry with a
Token Bucket Parameter Entry. Arriving traffic either "succeeds" or corresponding Token Bucket Parameter Entry. Arriving traffic either
"fails". "succeeds" or "fails".
3.6.1.3.2. EF Actions On an Ingress Edge Interface 3.6.1.3.2. EF Actions On an Ingress Edge Interface
For network planning and perhaps for billing purposes, arriving traffic For network planning and perhaps for billing purposes, arriving
that conforms to the meter is normally counted. Therefore, a "count" traffic that conforms to the meter is normally counted. Therefore, a
action, consisting of an action table entry pointing to a count table "count" action, consisting of an action table entry pointing to a
entry, is configured. count table entry, is configured.
Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark" Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark"
action, consisting of an action table entry pointing to a mark table action, consisting of an action table entry pointing to a mark table
entry, is configured. entry, is configured.
At this point, the successful traffic is now forwarded in the usual At this point, the successful traffic is now forwarded in the usual
manner. To indicate this, the "SucceedNext" pointer of the Mark Action manner. To indicate this, the "SucceedNext" pointer of the Mark
is set to zeroDotZero. Action is set to zeroDotZero.
Traffic that exceeded the arrival policy, however, is to be dropped. Traffic that exceeded the arrival policy, however, is to be dropped.
One can use a count action on this traffic if the several counters are One can use a count action on this traffic if the several counters
interesting. However, since the drop counter in the Algorithmic Drop are interesting. However, since the drop counter in the Algorithmic
Entry will count packets dropped, this is not clearly necessary. An Drop Entry will count packets dropped, this is not clearly necessary.
Alorithmic Drop Entry of the type "alwaysDrop" with no successor is An Algorithmic Drop Entry of the type "alwaysDrop" with no successor
sufficient. is sufficient.
3.7. AF and EF Egress Edge Interface Configuration 3.7. AF and EF Egress Edge Interface Configuration
3.7.1. Classification On an Egress Edge Interface 3.7.1. Classification On an Egress Edge Interface
A packet arriving at an egress interface may have been classified on an A packet arriving at an egress interface may have been classified on
ingress interface, and the egress interface may have access to that an ingress interface, and the egress interface may have access to
information. If it is relevant, there is no reason not to use that that information. If it is relevant, there is no reason not to use
that information. If it is not available, however, there may be a
need to (re)classify on the egress interface. In any event, it picks
up its "program" from the diffServDataPathTable. This points to a
classifier, which will select traffic according to some specification
for each traffic class.
+-----------------------+ +-----------------------+
| diffServDataPathStart | | diffServDataPathStart |
+-----------+-----------+ +-----------+-----------+
| |
+----------+ +----------+
| |
+--+--+ +-----+ +-----+ +-----+ +-----+ +--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF | | AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | | ||| ||| ||| ||| | |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM| |trTCM| |trTCM| |trTCM| |trTCM| |srTCM|
|Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter| |Meter|
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | | ||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+ +-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+ |+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions| ||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions|
+||Actions| +||Actions| +||Actions| +||Actions| +| | +||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+ +| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ | +-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| | ||| ||| ||| ||| |
+-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+ +-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+
| Queue| | Queue| | Queue| | Queue| | Queue| | Queue| | Queue| | Queue| | Queue| | Queue|
+--+---+ +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ +--+---+
| | | | | | | | | |
+--+-----------+-----------+-----------+---+ | +--+-----------+-----------+-----------+---+ |
| WFQ/WRR Scheduler | | | WFQ/WRR Scheduler | |
+--------------------------------------+---+ | +--------------------------------------+---+ |
| | | |
+-----+-----------+----+ +-----+-----------+----+
| Priority Scheduler | | Priority Scheduler |
+----------+-----------+ +----------+-----------+
| |
V V
Figure 8: combined EF and AF implementation Figure 8: combined EF and AF implementation
information. If it is not available, however, there may be a need to
(re)classify on the egress interface. In any event, it picks up its
"program" from the diffServDataPathTable. This points to a classifier,
which will select traffic according to some specification for each
traffic class.
An example of a classifier for an AFm class would be a succession of An example of a classifier for an AFm class would be a succession of
three classifier elements, each pointing to a Multi-field classification three classifier elements, each pointing to a Multi-field
parameter block identifying one of the AFmn DSCPs. Alternatively, the classification parameter block identifying one of the AFmn DSCPs.
filter might contain selectors for HTTP traffic or some other Alternatively, the filter might contain selectors for HTTP traffic or
application. some other application.
An example of a classifier for EF traffic might be either a classifier An example of a classifier for EF traffic might be either a
element pointing to a Multi-field parameter specifying the EF code classifier element pointing to a Multi-field parameter specifying the
point, or a collection of classifiers with parameter blocks specifying EF code point, or a collection of classifiers with parameter blocks
individual telephone calls, or a variety of other approaches. specifying individual telephone calls, or a variety of other
approaches.
Each classifier delivers traffic to appropriate functional data path Each classifier delivers traffic to appropriate functional data path
elements. elements.
3.7.2. AF Implementation On an Egress Edge Interface 3.7.2. AF Implementation On an Egress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. These groups of traffic conform to both specified into three groups. These groups of traffic conform to both specified
rates, only the higher one, or none. The intent, on the ingress rates, only the higher one, or none. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately interface at the edge of the network, is to measure and appropriately
mark traffic. mark traffic.
3.7.2.1. AF Metering On an Egress Edge Interface 3.7.2.1. AF Metering On an Egress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. If two rates R and S, with R < S, are specified and into three groups. If two rates R and S, where R < S, are specified
traffic arrives at rate T, traffic comprising up to R bits per second is and traffic arrives at rate T, traffic comprising up to R bits per
considered to conform to the "confirmed" rate, R. If R < T, traffic second is considered to conform to the "confirmed" rate, R. If
comprising up to S-R bits per second is considered to conform to the R < T, traffic comprising up to S-R bits per second is considered to
"excess" rate, S. Any further excess is non-conformant. conform to the "excess" rate, S. Any further excess is non-
conformant.
Two meter entries are used to configure this, one for the conforming Two meter entries are used to configure this, one for the conforming
rate and one for the excess rate. The rate parameters are stored in rate and one for the excess rate. The rate parameters are stored in
associated Token Bucket Parameter Entries. The "FailNext" pointer of associated Token Bucket Parameter Entries. The "FailNext" pointer of
the lower rate Meter Entry points to the other Meter Entry; both the lower rate Meter Entry points to the other Meter Entry; both
"SucceedNext" pointers and the "FailNext" pointer of the higher Meter "SucceedNext" pointers and the "FailNext" pointer of the higher Meter
Entry point to lists of actions. In the color-blind mode, all three Entry point to lists of actions. In the color-blind mode, all three
classifier "next" entries point to the lower rate meter entry. In the classifier "next" entries point to the lower rate meter entry. In
color-aware mode, the AFm1 classifier points to the lower rate entry, the color-aware mode, the AFm1 classifier points to the lower rate
the AFm2 classifier points to the higher rate entry (as it is only entry, the AFm2 classifier points to the higher rate entry (as it is
+-----------------------------------------------------+ only compared against that rate), and the AFm3 classifier points
| Classifier | directly to the actions taken when both rates fail.
+--------+--------------------------------------------+
|Green| Yellow| Red
| | |
+--+-----+-------+--+ 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, +-----------------------------------------------------+
| Classifier |
+--------+--------------------------------------------+
|Green| Yellow| Red
| | |
+--+-----+-------+--+ 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 meters using color-blind meters
+-----------------------------------------------------+
| Classifier |
+--------+--------------------------------------------+
|Green | Yellow | Red
| | |
+----+----+ +----+----+ |
| 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 meters | Classifier |
+-----------------------------------------------------+ +--------+--------------------------------------------+
| Classifier | |Green | Yellow | Red
+--------+-----------------+-----------------+--------+ | | |
| Green | Yellow | Red +----+----+ +----+----+ |
| | | | Count | | Count | |
+----+----+ +----+----+ +----+----+ | Action +-------+ Action +------------+
| Count | | Count | | Count | +----+----+ Fail +----+----+ Fail |
| Action | | Action | | Action | |Succeed |Succeed |
+----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
| | | | Count | | Count | | Count |
+----+----+ +----+----+ +----+----+ | Action | | Action | | Action |
| Random | | Random | | Random | +----+----+ +----+----+ +----+----+
| Drop | | Drop | | Drop | | | |
| Action | | Action | | Action | +----+----+ +----+----+ +----+----+
+----+----+ +----+----+ +----+----+ |Mark AFx1| |Mark AFx2| |Mark AFx3|
| | | | Action | | Action | | Action |
+--------+-----------------+-----------------+--------+ +----+----+ +----+----+ +----+----+
| Queue | | | |
+--------------------------+--------------------------+ +----+----+ +----+----+ +----+----+
| | Random | | Random | | Random |
+----+----+ | Drop | | Drop | | Drop |
| Rate | | Action | | Action | | Action |
|Scheduler| +----+----+ +----+----+ +----+----+
+----+----+ | | |
| +--------+-----------------+-----------------+--------+
| Queue |
+--------------------------+--------------------------+
|
+----+----+
| Rate |
|Scheduler|
+----+----+
|
Figure 10: Typical AF Edge core interface configuration Figure 9b: Typical AF Edge egress interface configuration,
using color-aware meters
compared against that rate), and the AFm3 classifier points directly to +-----------------------------------------------------+
the actions taken when both rates fail. | Classifier |
+--------+-----------------+-----------------+--------+
| Green | Yellow | Red
| | |
+----+----+ +----+----+ +----+----+
| 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 configuration
3.7.2.2. AF Actions On an Egress Edge Interface 3.7.2.2. AF Actions On an Egress Edge Interface
For network planning and perhaps for billing purposes, departing traffic For network planning and perhaps for billing purposes, departing
is normally counted. Therefore, a "count" action, consisting of an traffic is normally counted. Therefore, a "count" action, consisting
action table entry pointing to a count table entry, is configured. of an action table entry pointing to a count table entry, is
configured.
Also, traffic may be marked with an appropriate DSCP. The first R bits Also, traffic may be marked with an appropriate DSCP. The first R
per second are marked AFm1, the next S-R bits per second are marked bits 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 is arriving marked AFm2, and the rest is marked AFm3. It may be that traffic is
marked with the same DSCP, but in general, the additional complexity of arriving marked with the same DSCP, but in general, the additional
deciding that it is being remarked to the same value is not useful. complexity of deciding that it is being remarked to the same value is
Therefore, a "mark" action, consisting of an action table entry pointing not useful. Therefore, a "mark" action, consisting of an action
to a mark table entry, is configured. table entry pointing to a mark table entry, is configured.
At this point, the usual case is that traffic is now queued for At this point, the usual case is that traffic is now queued for
transmission. The queue uses Active Queue Management, using an transmission. The queue uses Active Queue Management, using an
algorithm such as RED. Therefore, an Algorithmic Dropper is configured algorithm such as RED. Therefore, an Algorithmic Dropper is
for each AFmn traffic stream, with a slightly lower min- threshold (and configured for each AFmn traffic stream, with a slightly lower min-
possibly lower max-threshold) for the excess traffic than for the threshold (and possibly lower max-threshold) for the excess traffic
committed traffic. than for the committed traffic.
3.7.2.3. AF Rate-based Queuing On an Egress Edge Interface 3.7.2.3. AF Rate-based Queuing On an Egress Edge Interface
The queue expected by AF is normally a work-conserving queue. It The queue expected by AF is normally a work-conserving queue. It
usually has a specified minimum rate, and may have a maximum rate below usually has a specified minimum rate, and may have a maximum rate
the bandwidth of the interface. In concept, it will use as much below the bandwidth of the interface. In concept, it will use as
bandwidth as is available to it, but assure the lower bound. much bandwidth as is available to it, but assure the lower bound.
Common ways to implement this include various forms of Weighted Fair Common ways to implement this include various forms of Weighted Fair
Queuing (WFQ) or Weighted Round Robin (WRR). Integrated over a longer Queuing (WFQ) or Weighted Round Robin (WRR). Integrated over a
interval, these give each class a predictable throughput rate. They longer interval, these give each class a predictable throughput rate.
differ in that over short intervals they will order traffic differently. They differ in that over short intervals they will order traffic
In general, traffic classes that keep traffic in queue will tend to differently. In general, traffic classes that keep traffic in queue
absorb latency from queues with lower mean occupancy, in exchange for will tend to absorb latency from queues with lower mean occupancy, in
which they make use of any available capacity. exchange for which they make use of any available capacity.
3.7.3. EF Implementation On an Egress Edge Interface 3.7.3. EF Implementation On an Egress Edge Interface
The EF class applies a Single Rate Two Color Meter, dividing traffic The EF class applies a Single Rate Two Color Meter, dividing traffic
into "conforming" and "excess" groups. The intent, on the egress into "conforming" and "excess" groups. The intent, on the egress
interface at the edge of the network, is to measure and appropriately interface at the edge of the network, is to measure and appropriately
mark conforming traffic and drop the excess. mark conforming traffic and drop the excess.
3.7.3.1. EF Metering On an Egress Edge Interface 3.7.3.1. EF Metering On an Egress Edge Interface
A single rate two color (srTCM) meter requires one token bucket. It is A single rate two color (srTCM) meter requires one token bucket. It
therefore configured using a single meter entry with a corresponding is therefore configured using a single meter entry with a
Token Bucket Parameter Entry. Arriving traffic either "succeeds" or corresponding Token Bucket Parameter Entry. Arriving traffic either
"fails". "succeeds" or "fails".
3.7.3.2. EF Actions On an Egress Edge Interface 3.7.3.2. EF Actions On an Egress Edge Interface
For network planning and perhaps for billing purposes, departing traffic For network planning and perhaps for billing purposes, departing
that conforms to the meter is normally counted. Therefore, a "count" traffic that conforms to the meter is normally counted. Therefore, a
action, consisting of an action table entry pointing to a count table "count" action, consisting of an action table entry pointing to a
entry, is configured. count table entry, is configured.
Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark" Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark"
action, consisting of an action table entry pointing to a mark table action, consisting of an action table entry pointing to a mark table
entry, is configured. entry, is configured.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Classifier | | Classifier |
+-------------------------+---------------------------+ +-------------------------+---------------------------+
| Voice | Voice
| |
+-------------+----------+ +-------------+----------+
| Meter | | Meter |
+----+-------------+-----+ +----+-------------+-----+
| Succeed | Fail | Succeed | Fail
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| Count | | Always | | Count | | Always |
| Action | | Drop | | Action | | Drop |
+----+----+ | Action | +----+----+ | Action |
| +---------+ | +---------+
+----+---------+ +----+---------+
| Algorithmic | | Algorithmic |
| Drop Action | | Drop Action |
+----+---------+ +----+---------+
| |
+----------------+---------------+ +----------------+---------------+
| Queue | | Queue |
+----------------+---------------+ +----------------+---------------+
| |
+-----+-----+ +-----+-----+
| Priority | | Priority |
| Scheduler | | Scheduler |
+-----+-----+ +-----+-----+
Figure 11: Typical EF Edge (Policing) Configuration Figure 11: Typical EF Edge (Policing) Configuration
+--------------------------------+ +--------------------------------+
| Classifier | | Classifier |
+----------------+---------------+ +----------------+---------------+
| Voice | Voice
| |
+----+----+ +----+----+
| Count | | Count |
| Action | | Action |
+----+----+ +----+----+
| |
+------+-------+ +------+-------+
| Algorithmic | | Algorithmic |
| Drop Action | | Drop Action |
+------+-------+ +------+-------+
| |
+----------------+---------------+ +----------------+---------------+
| Queue | | Queue |
+----------------+---------------+ +----------------+---------------+
| |
+-----+-----+ +-----+-----+
| Priority | | Priority |
| Scheduler | | Scheduler |
+-----+-----+ +-----+-----+
Figure 12: Typical EF Core interface Configuration Figure 12: Typical EF Core interface Configuration
At this point, the successful traffic is now queued for transmission, At this point, the successful traffic is now queued for transmission,
using a priority queue or perhaps a rate-based queue with significant using a priority queue or perhaps a rate-based queue with significant
over-provision. Since the amount of traffic present is known, one might over-provision. Since the amount of traffic present is known, one
not drop from this queue at all. might not drop from this queue at all.
Traffic that exceeded the policy, however, is dropped. A count action Traffic that exceeded the policy, however, is dropped. A count
can be used on this traffic if the several counters are interesting. action can be used on this traffic if the several counters are
However, since the drop counter in the Algorithmic Drop Entry will count interesting. However, since the drop counter in the Algorithmic Drop
packets dropped, this is not clearly necessary. An Alorithmic Drop Entry will count packets dropped, this is not clearly necessary. An
Entry of the type "alwaysDrop" with no successor is sufficient. Algorithmic Drop Entry of the type "alwaysDrop" with no successor is
sufficient.
3.7.3.3. EF Priority Queuing On an Egress Edge Interface 3.7.3.3. EF Priority Queuing On an Egress Edge Interface
The normal implementation is a priority queue, to minimize induced The normal implementation is a priority queue, to minimize induced
jitter. A separate queue is used for each EF class, with a strict jitter. A separate queue is used for each EF class, with a strict
ordering. ordering.
4. Conventions used in this MIB 4. Conventions used in this MIB
4.1. The use of RowPointer to indicate data path linkage 4.1. The use of RowPointer to indicate data path linkage
RowPointer is a textual convention used to identify a conceptual row in RowPointer is a textual convention used to identify a conceptual row
a MIB Table by pointing to one of its objects. One of the ways this MIB in a MIB Table by pointing to one of its objects. One of the ways
uses it is to indicate succession, pointing to data path linkage table this MIB uses it is to indicate succession, pointing to data path
entries. linkage table entries.
For succession, it answers the question "what happens next?". Rather For succession, it answers the question "what happens next?". Rather
than presume that the next table must be as specified in the conceptual than presume that the next table must be as specified in the
model [MODEL] and providing its index, the RowPointer takes you to the conceptual model [MODEL] and providing its index, the RowPointer
MIB row representing that thing. In the diffServMeterTable, for example, takes you to the MIB row representing that thing. In the
the diffServMeterFailNext RowPointer might take you to another meter, diffServMeterTable, for example, the diffServMeterFailNext RowPointer
while the diffServMeterSucceedNext RowPointer would take you to an might take you to another meter, while the diffServMeterSucceedNext
action. RowPointer would take you to an action.
Since a RowPointer is not tied to any specific object except by the Since a RowPointer is not tied to any specific object except by the
value it contains, it is possible and acceptable to use RowPointers to value it contains, it is possible and acceptable to use RowPointers
merge data paths. An obvious example of such a use is in the to merge data paths. An obvious example of such a use is in the
classifier: traffic matching the DSCPs AF11, AF12, and AF13 might be classifier: traffic matching the DSCPs AF11, AF12, and AF13 might be
presented to the same meter in order to perform the processing described presented to the same meter in order to perform the processing
in the Assured Forwarding PHB. Another use would be to merge data paths described in the Assured Forwarding PHB. Another use would be to
from several interfaces; if they represent a single service contract, merge data paths from several interfaces; if they represent a single
having them share a common set of counters and common policy may be a service contract, having them share a common set of counters and
desirable configuration. Note well, however, that such configurations common policy may be a desirable configuration. Note well, however,
may have related implementation issues - if Differentiated Services that such configurations may have related implementation issues - if
processing for the interfaces is implemented in multiple forwarding Differentiated Services processing for the interfaces is implemented
engines, the engines will need to communicate if they are to implement in multiple forwarding engines, the engines will need to communicate
such a feature. An implementation that fails to provide this capability if they are to implement such a feature. An implementation that
is not considered to have failed the intention of this MIB or of the fails to provide this capability is not considered to have failed the
[MODEL]; an implementation that does provide it is not considered intention of this MIB or of the [MODEL]; an implementation that does
superior from a standards perspective. provide it is not considered superior from a standards perspective.
NOTE -- the RowPointer construct is used to connect the functional NOTE -- the RowPointer construct is used to connect the functional
data paths. The [MODEL] describes these as TCBs, as an aid to data paths. The [MODEL] describes these as TCBs, as an aid to
understanding. This MIB, however, does not model TCBs directly. It understanding. This MIB, however, does not model TCBs directly.
operates at a lower level of abstraction using only individual It operates at a lower level of abstraction using only individual
elements, connected in succession by RowPointers. Therefore, the elements, connected in succession by RowPointers. Therefore, the
concept of TCBs enclosing individual Functional Data Path elements concept of TCBs enclosing individual Functional Data Path elements
is not directly applicable to this MIB, although management tools is not directly applicable to this MIB, although management tools
that use this MIB may employ such a concept. that use this MIB may employ such a concept.
It is possible that a path through a device following a set of It is possible that a path through a device following a set of
RowPointers is indeterminate i.e. it ends in a dangling RowPointer. RowPointers is indeterminate i.e. it ends in a dangling RowPointer.
Guidance is provided in the MIB module's DESCRIPTION-clause for each of Guidance is provided in the MIB module's DESCRIPTION-clause for each
the linkage attribute. In general, for both zeroDotZero and dangling of the linkage attribute. In general, for both zeroDotZero and
RowPointer, it is assumed the data path ends and the traffic should be dangling RowPointer, it is assumed the data path ends and the traffic
given to the next logical part of the device, usually a forwarding should be given to the next logical part of the device, usually a
process or a transmission engine, or the proverbial bit-bucket. Any forwarding process or a transmission engine, or the proverbial bit-
variation from this usage is indicated by the attribute affected. bucket. Any variation from this usage is indicated by the attribute
affected.
4.2. The use of RowPointer to indicate parameters 4.2. The use of RowPointer to indicate parameters
RowPointer is also used in this MIB to indicate parameterization, for RowPointer is also used in this MIB to indicate parameterization, for
pointing to parameterization table entries. pointing to parameterization table entries.
For indirection (as in the diffServClfrElementTable), the idea is to For indirection (as in the diffServClfrElementTable), the idea is to
allow other MIBs, including proprietary ones, to define new and arcane allow other MIBs, including proprietary ones, to define new and
filters - MAC headers, IPv4 and IPv6 headers, BGP Communities and all arcane filters - MAC headers, IPv4 and IPv6 headers, BGP Communities
sorts of other things - whilst still utilizing the structures of this and all sorts of other things - while still utilizing the structures
MIB. This is a form of class inheritance (in "object oriented" of this MIB. This is a form of class inheritance (in "object
language): it allows base object definitions ("classes") to be extended oriented" language): it allows base object definitions ("classes") to
in proprietary or standard ways, in the future, by other documents. be extended in proprietary or standard ways, in the future, by other
documents.
RowPointer also clearly indicates the identified conceptual row's RowPointer also clearly indicates the identified conceptual row's
content does not change, hence they can be simultaneously used, pointed content does not change, hence they can be simultaneously used and
to, by more than one data path linkage table entries. The pointed to, by more than one data path linkage table entries. The
identification of RowPointer allows higher level policy mechanisms to identification of RowPointer allows higher level policy mechanisms to
take advantage of this characteristic. take advantage of this characteristic.
4.3. Conceptual row creation and deletion 4.3. Conceptual row creation and deletion
A number of conceptual tables defined in this MIB use as an index an A number of conceptual tables defined in this MIB use as an index an
arbitrary integer value, unique across the scope of the agent. In order arbitrary integer value, unique across the scope of the agent. In
to help with multi-manager row-creation problems, a mechanism must be order to help with multi-manager row-creation problems, a mechanism
provided to allow a manager to obtain unique values for such an index must be provided to allow a manager to obtain unique values for such
and to ensure that, when used, the manager knows whether it got what it an index and to ensure that, when used, the manager knows whether it
wanted or not. got what it wanted or not.
Typically, such a table has an associated NextFree variable e.g. Typically, such a table has an associated NextFree variable e.g.
diffServClfrNextFree which provides a suitable value for the index of diffServClfrNextFree which provides a suitable value for the index of
the next row to be created e.g. diffServClfrId. The value zero is used the next row to be created e.g. diffServClfrId. The value zero is
to indicate that the agent can configure no more entries. The table used to indicate that the agent can configure no more entries. The
also has a columnar Status attribute with RowStatus syntax [6]. table also has a columnar Status attribute with RowStatus syntax [RFC
2579].
Generally, if a manager attempts to create a row, the agent will create Generally, if a manager attempts to create a row, the agent will
the row and return success. If the agent has insufficient resources or create the row and return success. If the agent has insufficient
such a row already exists, then it returns an error. A manager must be resources or such a row already exists, then it returns an error. A
prepared to try again in such circumstances, probably by re-reading the manager must be prepared to try again in such circumstances, probably
NextFree to obtain a new index value in case a second manager had got in by re-reading the NextFree to obtain a new index value in case a
between the first manager's read of the NextFree value and the first second manager had got in between the first manager's read of the
manager's row-creation attempt. NextFree value and the first manager's row-creation attempt.
To simplify management creation and deletion of rows in this MIB, the To simplify management creation and deletion of rows in this MIB, the
agent is expected to assist in maintaining its consistency. It may agent is expected to assist in maintaining its consistency. It may
accomplish this by maintaining internal usage counters for any row that accomplish this by maintaining internal usage counters for any row
might be pointed to by a RowPointer, or by any equivalent means. When a that might be pointed to by a RowPointer, or by any equivalent means.
RowPointer is created or written, and the row it points to does not When a RowPointer is created or written, and the row it points to
exist, the SET returns an inconsistentValue error. When a RowStatus does not exist, the SET returns an inconsistentValue error. When a
variable is set to 'destroy' but the usage counter is non-zero, the SET RowStatus variable is set to 'destroy' but the usage counter is non-
returns no error but the indicated row is left intact. The agent should zero, the SET returns no error but the indicated row is left intact.
later remove the row in the event that the usage counter becomes zero. The agent should later remove the row in the event that the usage
counter becomes zero.
The use of RowStatus is covered in more detail in [6]. The use of RowStatus is covered in more detail in [RFC 2579].
5. Extending this MIB 5. Extending this MIB
With the structures of this MIB divided into data path linkage tables With the structures of this MIB divided into data path linkage tables
and parameterization tables, and with the use of RowPointer, new data and parameterization tables, and with the use of RowPointer, new data
path linkage and parameterization tables can be defined in other MIB path linkage and parameterization tables can be defined in other MIB
modules, and used with tables defined in this MIB. This MIB does not modules, and used with tables defined in this MIB. This MIB does not
limit the type of entries its RowPointer attributes can point to, hence limit the type of entries its RowPointer attributes can point to,
new functional data path elements can be defined in other MIBs and hence new functional data path elements can be defined in other MIBs
integrated with functional data path elements of this MIB. For example, and integrated with functional data path elements of this MIB. For
new Action functional data path element can be defined for Traffic example, new Action functional data path element can be defined for
Engineering and be integrated with Differentiated Services functional Traffic Engineering and be integrated with Differentiated Services
data path elements, possibly used within the same data path sharing the functional data path elements, possibly used within the same data
same classifiers and meters. path sharing the same classifiers and meters.
It is more likely that new parameterization tables will be created in It is more likely that new parameterization tables will be created in
other MIBs as new methods or proprietary methods get deployed for other MIBs as new methods or proprietary methods get deployed for
existing Differentiated Services Functional Data Path Elements. For existing Differentiated Services Functional Data Path Elements. For
example, different kinds of filters can be defined by using new filter example, different kinds of filters can be defined by using new
parameterization tables. New scheduling methods can be deployed by filter parameterization tables. New scheduling methods can be
defining new scheduling method OIDs and new scheduling parameter tables. deployed by defining new scheduling method OIDs and new scheduling
parameter tables.
Notice both new data path linkage tables and parameterization tables can Notice both new data path linkage tables and parameterization tables
be added without needing to change this MIB document or affect existing can be added without needing to change this MIB document or affect
tables and their usage. existing tables and their usage.
6. MIB Definition 6. MIB Definition
DIFFSERV-DSCP-TC DEFINITIONS ::= BEGIN DIFFSERV-DSCP-TC DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Integer32, MODULE-IDENTITY, mib-2 Integer32, MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
diffServDSCPTC MODULE-IDENTITY diffServDSCPTC MODULE-IDENTITY
LAST-UPDATED "200111010933Z" LAST-UPDATED "200205090000Z"
ORGANIZATION "IETF Differentiated Services WG" ORGANIZATION "IETF Differentiated Services WG"
CONTACT-INFO CONTACT-INFO
" Fred Baker " Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 1121 Via Del Rey
Santa Barbara, CA 93111, USA Santa Barbara, CA 93117, USA
E-mail: fred@cisco.com E-mail: fred@cisco.com
Kwok Ho Chan Kwok Ho Chan
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821, USA Billerica, MA 01821, USA
E-mail: khchan@nortelnetworks.com E-mail: khchan@nortelnetworks.com
Andrew Smith Andrew Smith
Allegro Networks Harbour Networks
6399 San Ignacio Ave Jiuling Building
San Jose, CA 95119, USA 21 North Xisanhuan Ave.
E-mail: andrew@allegronetworks.com Beijing, 100089, PRC
E-mail: ah_smith@acm.org
Differentiated Services Working Group: Differentiated Services Working Group:
diffserv@ietf.org" diffserv@ietf.org"
DESCRIPTION DESCRIPTION
"The Textual Conventions defined in this module should be used "The Textual Conventions defined in this module should be used
whenever a Differentiated Services Code Point is used in a MIB." whenever a Differentiated Services Code Point is used in a MIB."
REVISION "200111010933Z" REVISION "200205090000Z"
DESCRIPTION DESCRIPTION
"Initial version, published as RFC xxxx." "Initial version, published as RFC 3289."
::= { mib-2 xxx } -- to be assigned by IANA ::= { mib-2 96 }
Dscp ::= TEXTUAL-CONVENTION Dscp ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d" DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A Differentiated Services Code-Point that may be used for "A Differentiated Services Code-Point that may be used for
marking a traffic stream." marking a traffic stream."
REFERENCE REFERENCE
"RFC 2474, RFC 2780" "RFC 2474, RFC 2780"
SYNTAX Integer32 (0..63) SYNTAX Integer32 (0..63)
skipping to change at page 37, line 4 skipping to change at page 37, line 11
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The IP header Differentiated Services Code-Point that may be "The IP header Differentiated Services Code-Point that may be
used for discriminating among traffic streams. The value -1 is used for discriminating among traffic streams. The value -1 is
used to indicate a wild card i.e. any value." used to indicate a wild card i.e. any value."
REFERENCE REFERENCE
"RFC 2474, RFC 2780" "RFC 2474, RFC 2780"
SYNTAX Integer32 (-1 | 0..63) SYNTAX Integer32 (-1 | 0..63)
END END
DIFFSERV-MIB DEFINITIONS ::= BEGIN DIFFSERV-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Unsigned32, Counter64, MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32, Counter64, MODULE-IDENTITY, OBJECT-TYPE,
zeroDotZero, mib-2 OBJECT-IDENTITY, zeroDotZero, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, RowPointer, TEXTUAL-CONVENTION, RowStatus, RowPointer,
StorageType, AutonomousType StorageType, AutonomousType
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
ifIndex, InterfaceIndexOrZero ifIndex, InterfaceIndexOrZero
FROM IF-MIB FROM IF-MIB
InetAddressType, InetAddress, InetAddressPrefixLength, InetAddressType, InetAddress, InetAddressPrefixLength,
InetPortNumber InetPortNumber
FROM INET-ADDRESS-MIB FROM INET-ADDRESS-MIB
BurstSize BurstSize
FROM INTEGRATED-SERVICES-MIB FROM INTEGRATED-SERVICES-MIB
Dscp, DscpOrAny Dscp, DscpOrAny
FROM DIFFSERV-DSCP-TC; FROM DIFFSERV-DSCP-TC;
diffServMib MODULE-IDENTITY diffServMib MODULE-IDENTITY
LAST-UPDATED "200111010933Z" LAST-UPDATED "200202070000Z"
ORGANIZATION "IETF Differentiated Services WG" ORGANIZATION "IETF Differentiated Services WG"
CONTACT-INFO CONTACT-INFO
" Fred Baker " Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 1121 Via Del Rey
Santa Barbara, CA 93111, USA Santa Barbara, CA 93117, USA
E-mail: fred@cisco.com E-mail: fred@cisco.com
Kwok Ho Chan Kwok Ho Chan
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821, USA Billerica, MA 01821, USA
E-mail: khchan@nortelnetworks.com E-mail: khchan@nortelnetworks.com
Andrew Smith Andrew Smith
Allegro Networks Harbour Networks
6399 San Ignacio Ave Jiuling Building
San Jose, CA 95119, USA 21 North Xisanhuan Ave.
E-mail: andrew@allegronetworks.com Beijing, 100089, PRC
E-mail: ah_smith@acm.org
Differentiated Services Working Group: Differentiated Services Working Group:
diffserv@ietf.org" diffserv@ietf.org"
DESCRIPTION DESCRIPTION
"This MIB defines the objects necessary to manage a device that "This MIB defines the objects necessary to manage a device that
uses the Differentiated Services Architecture described in RFC uses the Differentiated Services Architecture described in RFC
2475. The Conceptual Model of a Differentiated Services Router 2475. The Conceptual Model of a Differentiated Services Router
provides supporting information on how such a router is modeled." provides supporting information on how such a router is modeled."
REVISION "200111010933Z" REVISION "200202070000Z"
DESCRIPTION DESCRIPTION
"Initial version, published as RFC xxxx." "Initial version, published as RFC 3289."
::= { mib-2 xxx } -- to be assigned by IANA ::= { mib-2 97 }
diffServMIBObjects OBJECT IDENTIFIER ::= { diffServMib 1 } diffServMIBObjects OBJECT IDENTIFIER ::= { diffServMib 1 }
diffServMIBConformance OBJECT IDENTIFIER ::= { diffServMib 2 } diffServMIBConformance OBJECT IDENTIFIER ::= { diffServMib 2 }
diffServMIBAdmin OBJECT IDENTIFIER ::= { diffServMib 3 } diffServMIBAdmin OBJECT IDENTIFIER ::= { diffServMib 3 }
IndexInteger ::= TEXTUAL-CONVENTION IndexInteger ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d" DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An integer which may be used as a table index." "An integer which may be used as a table index."
skipping to change at page 60, line 50 skipping to change at page 58, line 10
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
UNITS "kilobits per second" UNITS "kilobits per second"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The token-bucket rate, in kilobits per second (kbps). This "The token-bucket rate, in kilobits per second (kbps). This
attribute is used for: attribute is used for:
1. CIR in RFC 2697 for srTCM 1. CIR in RFC 2697 for srTCM
2. CIR and PIR in RFC 2698 for trTCM 2. CIR and PIR in RFC 2698 for trTCM
3. CTR and PTR in RFC 2859 for TSWTCM 3. CTR and PTR in RFC 2859 for TSWTCM
4. AverageRate in RFC XXXX." 4. AverageRate in RFC 3290."
::= { diffServTBParamEntry 3 } ::= { diffServTBParamEntry 3 }
diffServTBParamBurstSize OBJECT-TYPE diffServTBParamBurstSize OBJECT-TYPE
SYNTAX BurstSize SYNTAX BurstSize
UNITS "Bytes" UNITS "Bytes"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum number of bytes in a single transmission burst. This "The maximum number of bytes in a single transmission burst. This
attribute is used for: attribute is used for:
1. CBS and EBS in RFC 2697 for srTCM 1. CBS and EBS in RFC 2697 for srTCM
2. CBS and PBS in RFC 2698 for trTCM 2. CBS and PBS in RFC 2698 for trTCM
3. Burst Size in RFC XXXX." 3. Burst Size in RFC 3290."
::= { diffServTBParamEntry 4 } ::= { diffServTBParamEntry 4 }
diffServTBParamInterval OBJECT-TYPE diffServTBParamInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295) SYNTAX Unsigned32 (1..4294967295)
UNITS "microseconds" UNITS "microseconds"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The time interval used with the token bucket. For: "The time interval used with the token bucket. For:
1. Average Rate Meter, the Informal Differentiated Services Model 1. Average Rate Meter, the Informal Differentiated Services Model
skipping to change at page 90, line 8 skipping to change at page 82, line 34
DEFVAL { zeroDotZero } DEFVAL { zeroDotZero }
::= { diffServSchedulerEntry 4 } ::= { diffServSchedulerEntry 4 }
diffServSchedulerMaxRate OBJECT-TYPE diffServSchedulerMaxRate OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This RowPointer indicates the entry in diffServMaxRateTable "This RowPointer indicates the entry in diffServMaxRateTable
which indicates the maximum output rate from this scheduler. which indicates the maximum output rate from this scheduler.
When more than one maximum rate applies (eg, when a mulkti-rate When more than one maximum rate applies (eg, when a multi-rate
shaper is in view), it points to the first of those rate entries. shaper is in view), it points to the first of those rate entries.
This attribute is used only when there is more than one level of This attribute is used only when there is more than one level of
scheduler. scheduler.
When it has the value zeroDotZero, it indicates that no maximum When it has the value zeroDotZero, it indicates that no maximum
rate is imposed. rate is imposed.
Setting this to point to a target that does not exist results in Setting this to point to a target that does not exist results in
an inconsistentValue error. If the row pointed to is removed or an inconsistentValue error. If the row pointed to is removed or
becomes inactive by other means, the treatment is as if this becomes inactive by other means, the treatment is as if this
skipping to change at page 100, line 4 skipping to change at page 91, line 33
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this conceptual row. All writable objects in this "The status of this conceptual row. All writable objects in this
row may be modified at any time. Setting this variable to row may be modified at any time. Setting this variable to
'destroy' when the MIB contains one or more RowPointers pointing 'destroy' when the MIB contains one or more RowPointers pointing
to it results in destruction being delayed until the row is no to it results in destruction being delayed until the row is no
longer used." longer used."
::= { diffServMaxRateEntry 7 } ::= { diffServMaxRateEntry 7 }
-- --
-- MIB Compliance statements. -- MIB Compliance statements.
-- --
diffServMIBCompliances OBJECT IDENTIFIER ::= { diffServMIBConformance 1 } diffServMIBCompliances OBJECT IDENTIFIER ::=
diffServMIBGroups OBJECT IDENTIFIER ::= { diffServMIBConformance 2 } { diffServMIBConformance 1 }
diffServMIBGroups OBJECT IDENTIFIER ::=
{ diffServMIBConformance 2 }
diffServMIBFullCompliance MODULE-COMPLIANCE diffServMIBFullCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"When this MIB is implemented with support for read-create, then "When this MIB is implemented with support for read-create, then
such an implementation can claim full compliance. Such devices such an implementation can claim full compliance. Such devices
can then be both monitored and configured with this MIB." can then be both monitored and configured with this MIB."
MODULE IF-MIB -- The interfaces MIB, RFC2863 MODULE IF-MIB -- The interfaces MIB, RFC2863
MANDATORY-GROUPS { MANDATORY-GROUPS {
skipping to change at page 119, line 4 skipping to change at page 109, line 43
OBJECTS { OBJECTS {
diffServMaxRateNextFree, diffServMaxRateAbsolute, diffServMaxRateNextFree, diffServMaxRateAbsolute,
diffServMaxRateRelative, diffServMaxRateThreshold, diffServMaxRateRelative, diffServMaxRateThreshold,
diffServMaxRateStorage, diffServMaxRateStatus diffServMaxRateStorage, diffServMaxRateStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Maximum Rate Parameter Group contains the objects that "The Maximum Rate Parameter Group contains the objects that
describe packet schedulers' maximum rate guarantees." describe packet schedulers' maximum rate guarantees."
::= { diffServMIBGroups 15 } ::= { diffServMIBGroups 15 }
END END
7. Acknowledgments 7. Acknowledgments
This MIB builds on all the work that has gone into the Informal This MIB builds on all the work that has gone into the Informal
Management Model for Differentiated Services Routers, Differentiated Management Model for Differentiated Services Routers, Differentiated
Services PIB, and Differentiated Services Policy MIB (SNMPCONF WG). Services PIB, and Differentiated Services Policy MIB (SNMPCONF WG).
It has been developed with the active involvement of many people, but It has been developed with the active involvement of many people, but
most notably Yoram Bernet, Steve Blake, Brian Carpenter, Dave Durham, most notably Yoram Bernet, Steve Blake, Brian Carpenter, Dave Durham,
Michael Fine, Victor Firoiu, Jeremy Greene, Dan Grossman, Roch Guerin, Michael Fine, Victor Firoiu, Jeremy Greene, Dan Grossman, Roch
Scott Hahn, Joel Halpern, Van Jacobsen, Keith McCloghrie, Bob Moore, Guerin, Scott Hahn, Joel Halpern, Van Jacobsen, Keith McCloghrie, Bob
Kathleen Nichols, Ping Pan, Nabil Seddigh, John Seligson, and Walter Moore, Kathleen Nichols, Ping Pan, Nabil Seddigh, John Seligson, and
Weiss. Walter Weiss.
Juergen Schoenwaelder, Dave Perkins, Frank Strauss, Harrie Hazewinkel, Juergen Schoenwaelder, Dave Perkins, Frank Strauss, Harrie
and Bert Wijnen are especially to be noted for review comments on the Hazewinkel, and Bert Wijnen are especially to be noted for review
structure and usage of the MIB for network management purposes, and its comments on the structure and usage of the MIB for network management
compliance with SMIv2. purposes, and its compliance with SMIv2.
8. Security Considerations 8. Security Considerations
It is clear that this MIB is potentially useful for configuration. It is clear that this MIB is potentially useful for configuration.
Anything that can be configured can be misconfigured, with potentially Anything that can be configured can be misconfigured, with
disastrous effect. potentially disastrous effects.
At this writing, no security holes have been identified beyond those At this writing, no security holes have been identified beyond those
that SNMP Security is itself intended to address. These relate primarily that SNMP Security is itself intended to address. These relate
to controlled access to sensitive information and the ability to primarily to controlled access to sensitive information and the
configure a device - or which might result from operator error, which is ability to configure a device - or which might result from operator
beyond the scope of any security architecture. error, which is beyond the scope of any security architecture.
There are many read-write and read-create management objects defined in There are many read-write and read-create management objects defined
this MIB. Such objects are often sensitive or vulnerable in some network in this MIB. Such objects are often sensitive or vulnerable in some
environments. The support for SET operations in a non-secure environment network environments. The support for SET operations in a non-secure
without proper protection can have a negative effect on network environment without proper protection can have a negative effect on
operations. The use of SNMP Version 3 is recommended over prior versions network operations. The use of SNMP Version 3 is recommended over
for configuration control as its security model is improved. prior versions for configuration control as its security model is
improved.
There are a number of managed objects in this MIB that may contain There are a number of managed objects in this MIB that may contain
information that may be sensitive from a business perspective, in that information that may be sensitive from a business perspective, in
they may represent a customer's service contract or the filters that the that they may represent a customer's service contract or the filters
service provider chooses to apply to a customer's ingress or egress that the service provider chooses to apply to a customer's ingress or
traffic. There are no objects which are sensitive in their own right, egress traffic. There are no objects which are sensitive in their
such as passwords or monetary amounts. own right, such as passwords or monetary amounts.
It may be important to control even GET access to these objects and It may be important to even control GET access to these objects and
possibly to even encrypt the values of these object when sending them possibly to even encrypt the values of these objects when sending
over the network via SNMP. Not all versions of SNMP provide features for them over the network via SNMP. Not all versions of SNMP provide
such a secure environment. features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network itself SNMPv1 by itself is not a secure environment. Even if the network
is secure (for example by using IPSec), even then, there is no control itself is secure (for example by using IPSec), even then, there is no
as to who on the secure network is allowed to access and GET/SET control as to who on the secure network is allowed to access and
(read/change/create/delete) the objects in this MIB. GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementors consider the security features It is recommended that the implementors consider the security
as provided by the SNMPv3 framework. Specifically, the use of the User- features as provided by the SNMPv3 framework. Specifically, the use
based Security Model [12] and the View-based Access Control Model [15] of the User-based Security Model [RFC 2574] and the View-based Access
is recommended. Control Model [RFC 2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity It is then a customer/user responsibility to ensure that the SNMP
giving access to an instance of this MIB, is properly configured to give entity giving access to an instance of this MIB, is properly
access to the objects only to those principals (users) that have configured to give access to the objects only to those principals
legitimate rights to indeed GET or SET (change/create/delete) them. (users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
9. References 9. Intellectual Property Rights
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for The IETF takes no position regarding the validity or scope of any
Describing SNMP Management Frameworks", RFC 2571, Cabletron intellectual property or other rights that might be claimed to
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April pertain to the implementation or use of the technology described in
1999 this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
[2] Rose, M., and K. McCloghrie, "Structure and Identification of The IETF invites any interested party to bring to its attention any
Management Information for TCP/IP-based Internets", RFC 1155, STD copyrights, patents or patent applications, or other proprietary
16, Performance Systems International, Hughes LAN Systems, May 1990 rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 10. References
STD 16, Performance Systems International, Hughes LAN Systems,
March 1991
[4] M. Rose, "A Convention for Defining Traps for use with the SNMP", [RFC 2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
RFC 1215, Performance Systems International, March 1991 Architecture for Describing SNMP Management
Frameworks", RFC 2571, April 1999.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [RFC 1155] Rose, M. and K. McCloghrie, "Structure and
and S. Waldbusser, "Structure of Management Information Version 2 Identification of Management Information for TCP/IP-
(SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU based Internets", STD 16, RFC 1155, May 1990.
Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [RFC 1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD STD 16, RFC 1212, March 1991.
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April 1999
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580,
STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research,
First Virtual Holdings, International Network Services, April 1999
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network [RFC 1215] Rose, M., "A Convention for Defining Traps for use with
Management Protocol", RFC 1157, STD 15, SNMP Research, Performance the SNMP", RFC 1215, March 1991.
Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [RFC 2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
"Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, J., Rose, M. and S. Waldbusser, "Structure of
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Management Information Version 2 (SMIv2)", STD 58, RFC
International Network Services, January 1996. 2578, April 1999.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport [RFC 2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
Mappings for Version 2 of the Simple Network Management Protocol J., Rose, M. and S. Waldbusser, "Textual Conventions
(SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., for SMIv2", STD 58, RFC 2579, April 1999.
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message [RFC 2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
Processing and Dispatching for the Simple Network Management J., Rose, M. and S. Waldbusser, "Conformance Statements
Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, for SMIv2", STD 58, RFC 2580, April 1999.
Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for [RFC 1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC "Simple Network Management Protocol", STD 15, RFC 1157,
2574, IBM T. J. Watson Research, April 1999 May 1990.
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol [RFC 1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Operations for Version 2 of the Simple Network Management Protocol "Introduction to Community-based SNMPv2", RFC 1901,
(SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., January 1996.
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC [RFC 1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2573, SNMP Research, Inc., Secure Computing Corporation, Cisco "Transport Mappings for Version 2 of the Simple Network
Systems, April 1999 Management Protocol (SNMPv2)", RFC 1906, January 1996.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [RFC 2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
Control Model (VACM) for the Simple Network Management Protocol "Message Processing and Dispatching for the Simple
(SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., Network Management Protocol (SNMP)", RFC 2572, April
Cisco Systems, Inc., April 1999 1999.
[16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to [RFC 2574] Blumenthal, U. and B. Wijnen, "User-based Security
Version 3 of the Internet-standard Network Management Framework", Model (USM) for version 3 of the Simple Network
RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, Management Protocol (SNMPv3)", RFC 2574, April 1999.
Inc., Ericsson, Cisco Systems, April 1999
[RFC2119] [RFC 1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
S. Bradner, "Key words to use in the RFCs", RFC 2119. Mar 1997. "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[ACTQMGMT] [RFC 2573] Levi, D., Meyer, P. and B. Stewart, "SNMP
V. Firoiu, M. Borden "A Study of Active Queue Management for Applications", RFC 2573, April 1999.
Congestion Control", March 2000, In IEEE Infocom 2000,
http://www.ieee-infocom.org/2000/papers/405.pdf
[AQMROUTER] [RFC 2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
V.Misra, W.Gong, D.Towsley "Fuid-based analysis of a network of AQM Access Control Model (VACM) for the Simple Network
routers supporting TCP flows with an application to RED", In Management Protocol (SNMP)", RFC 2575, April 1999.
SIGCOMM 2000,
http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-4-
3.ps.gz
[AF-PHB] [RFC 2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding "Introduction to Version 3 of the Internet-standard
PHB Group.", RFC 2597, June 1999. Network Management Framework", RFC 2570, April 1999.
[DSARCH] [RFC 2119] Bradner, S., "Key words to use in the RFCs", BCP 14,
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An RFC 2119, March 1997.
Architecture for Differentiated Service", RFC 2475, December 1998.
[DSFIELD] [ACTQMGMT] V. Firoiu, M. Borden, "A Study of Active Queue
K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Management for Congestion Control", March 2000, In IEEE
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Infocom 2000, http://www.ieee-
Headers", RFC 2474, December 1998. infocom.org/2000/papers/405.pdf
[DSPIB] [AQMROUTER] V. Misra, W. Gong, D. Towsley, "Fluid-based analysis of
M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, a network of AQM routers supporting TCP flows with an
"Differentiated Services Quality of Service Policy Information application to RED", In SIGCOMM
Base", Internet Draft <draft-ietf-diffserv-pib-04.txt>, 07/25/2001 2000,http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-4-3.ps.gz
[DSTERMS] [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
D. Grossman, "New Terminology for Differentiated Services", "Assured Forwarding PHB Group", RFC 2597, June 1999.
Internet Draft <draft-ietf-diffserv-new-terms-05.txt>, 08/28/2001.
[EF-PHB] [DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB." and W. Weiss, "An Architecture for Differentiated
Internet Draft, <draft-ietf-diffserv-rfc2598bis-02.txt>, Service", RFC 2475, December 1998.
09/04/2001.
[IF-MIB] [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB using "Definition of the Differentiated Services Field (DS
SMIv2", RFC 2863, June 2000. Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[INETADDRESS] [DSPIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn,
Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., S. and A. Smith, "Differentiated Services Quality of
"Textual Conventions for Internet Network Addresses.", draft-ietf- Service Policy Information Base", Work in Progress.
ops-rfc2851-update-02.txt. [PRIVATE NOTE TO RFC EDITOR: YES, THIS
IS INDEED A NORMATIVE REFERENCE. JUERGEN TELLS ME THAT HE WILL
PUBLISH IT POSTE HASTE].
[INTSERVMIB] [DSTERMS] Grossman, D., "New Terminology for Differentiated
F. Baker, J. Krawczyk, A. Sastry, "Integrated Services Management Services", RFC 3260, April 2002.
Information Base using SMIv2", RFC 2213, September 1997.
[MODEL] [EF-PHB] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Y. Bernet, S. Blake, A. Smith, D. Grossman, "An Informal Management Forwarding PHB", RFC 3246, March 2002.
Model for Differentiated Services Routers", Internet Draft <draft-
ietf-Differentiated Services-model-06.txt>,
[RED93] [IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
"Random Early Detection", 1993. MIB using SMIv2", RFC 2863, June 2000.
[srTCM] [INETADDRESS] Daniele, M., Haberman, B., Routhier, S. and J.
J. Heinanen, R. Guerin, "A Single Rate Three Color Marker", RFC Schoenwaelder, "Textual Conventions for Internet
2697, September 1999. Network Addresses.", RFC 3291, May 2002.
[trTCM] [INTSERVMIB] Baker, F., Krawczyk, J. and A. Sastry, "Integrated
J. Heinanen, R. Guerin, "A Two Rate Three Color Marker", RFC 2698, Services Management Information Base using SMIv2", RFC
September 1999. 2213, September 1997.
[TSWTCM] [MODEL] Bernet, Y., Blake, S., Smith, A. and D. Grossman, "An
W. Fang, N. Seddigh, B. Nandy "A Time Sliding Window Three Color Informal Management Model for Differentiated Services
Marker", RFC 2859, June 2000. Routers", Work in Progress.
[SHAPER] [RED93] "Random Early Detection", 1993.
"A Rate Adaptive Shaper for Differentiated Services" FC 2963,
October 2000.
10. Authors' Addresses [srTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
Fred Baker [trTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Cisco Systems Marker", RFC 2698, September 1999.
519 Lado Drive
Santa Barbara, California 93111
fred@cisco.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
khchan@nortelnetworks.com
Andrew Smith [TSWTCM] Fang, W., Seddigh, N. and B. Nandy, "A Time Sliding
Allegro Networks Window Three Color Marker (TSWTCM)", RFC 2859, June
6399 San Ignacio Ave 2000.
San Jose, CA 95119
andrew@allegronetworks.com
Table of Contents [SHAPER] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive
Shaper for Differentiated Services", RFC 2963, October
2000.
1 The SNMP Management Framework ................................... 2 11. Authors' Addresses
2 Relationship to other working group documents ................... 4
2.1 Relationship to the Informal Management Model for
Differentiated Services Router ............................... 4
2.2 Relationship to other MIBs and Policy Management .............. 5
3 MIB Overview .................................................... 5
3.1 Processing Path ............................................... 6
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 Classifier
Table ........................................................ 9
3.3 Metering Traffic .............................................. 9
3.3.1 diffServMeterTable - The Meter Table ........................ 10
3.3.2 diffServTBParamTable - The Token Bucket Parameters Table
.............................................................. 11
3.4 Actions applied to packets .................................... 11
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
.............................................................. 13
3.5 Queuing and Scheduling of Packets ............................. 15
3.5.1 diffServQTable - The Class or Queue Table ................... 15
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 ............................. 21
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 ................. 22
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 ............... 25
3.7.2.1 AF Metering On an Egress Edge Interface ................... 25
3.7.2.2 AF Actions On an Egress Edge Interface .................... 28
3.7.2.3 AF Rate-based Queuing On an Egress Edge Interface ......... 29
3.7.3 EF Implementation On an Egress Edge Interface ............... 29
3.7.3.1 EF Metering On an Egress Edge Interface ................... 29
3.7.3.2 EF Actions On an Egress Edge Interface .................... 29
3.7.3.3 EF Priority Queuing On an Egress Edge Interface ........... 31
4 Conventions used in this MIB .................................... 32
4.1 The use of RowPointer to indicate data path linkage ........... 32
4.2 The use of RowPointer to indicate parameters .................. 33
4.3 Conceptual row creation and deletion .......................... 33
5 Extending this MIB .............................................. 34
6 MIB Definition .................................................. 35
7 Acknowledgments ................................................. 120
8 Security Considerations ......................................... 120
9 References ...................................................... 121
10 Authors' Addresses ............................................. 124
11. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved. Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
EMail: fred@cisco.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
EMail: khchan@nortelnetworks.com
Andrew Smith
Harbour Networks
Jiuling Building
21 North Xisanhuan Ave.
Beijing, 100089, PRC
EMail: ah_smith@acm.org
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 252 change blocks. 
1438 lines changed or deleted 1476 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/