Fred Baker
Draft Differentiated Services MIB July 1999
Management Information Base for the
Differentiated Services Architecture
draft-ietf-diffserv-mib-00.txt
Abstract
This memo describes a proposed MIB for the Differentiated
Services Architecture.
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026. Internet-Drafts
are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
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 particular draft is being developed in the Differentiated
Services Working Group. Discussion of it therefore belongs on
that list. The charter for Differentiated Services may be
found at http://www.ietf.org/html.charters/diffserv-
charter.html
2. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and
events for the purpose of management. The first
version of this Structure of Management Information
Fred Baker Expiration: January 2000 [Page 1]
Draft Differentiated Services MIB July 1999
(SMI) is called SMIv1 and described in RFC 1155 [2],
RFC 1212 [3] and RFC 1215 [4]. The second version,
called SMIv2, is described in RFC 2578 [5], RFC 2579
[6] and RFC 2580 [7].
o Message protocols for transferring management
information. The first version of the SNMP message
protocol is called SNMPv1 and described in RFC 1157
[8]. A second version of the SNMP message protocol,
which is not an Internet standards track protocol, is
called SNMPv2c and described in RFC 1901 [9] and RFC
1906 [10]. The third version of the message protocol
is called SNMPv3 and described in RFC 1906 [10], RFC
2572 [11] and RFC 2574 [12].
o Protocol operations for accessing management
information. The first set of protocol operations and
associated PDU formats is described in RFC 1157 [8]. A
second set of protocol operations and associated PDU
formats is described in RFC 1905 [13].
o A set of fundamental applications described in RFC
2573 [14] and the view-based access control mechanism
described in RFC 2575 [15].
A more detailed introduction to the current SNMP Management
Framework can be found in RFC 2570 [16].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Objects in the
MIB are defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the
SMIv2. A MIB conforming to the SMIv1 can be produced through
the appropriate translations. The resulting translated MIB
must be semantically equivalent, except where objects or
events are omitted because no translation is possible (use of
Counter64). Some machine-readable information in SMIv2 will be
converted into textual descriptions in SMIv1 during the
translation process. However, this loss of machine readable
information is not considered to change the semantics of the
MIB.
Fred Baker Expiration: January 2000 [Page 2]
Draft Differentiated Services MIB July 1999
3. Structure of this MIB
This MIB is designed according to the Differentiated Services
implementation conceptual model documented in [Model].
3.1. Overview
In principle, if one were to construct a network entirely out
of two-port routers (in appropriate places connected by LANs
or similar media), then it would be necessary for each router
to perform exactly four QoS control functions on traffic in
each direction:
- Classify each message according to some set of rules
- In edge devices, determine whether the data stream the
message is part of is within or outside its rate
- Perform some set of resulting actions, minimally
including applying a drop policy appropriate to the
classification and queue in question, and in edge devices
perhaps additionally marking the traffic with a
Differentiated Services Code Point (DSCP) as defined in
[DSCP].
- Enqueue the traffic for output in the appropriate queue,
which may shape the traffic or simply forward it with
some minimum rate or maximum latency.
If we build the network out of N-port routers, we expect the
behavior of the network to be identical. We are forced,
therefore, to provide essentially the same set of functions on
the ingress port of a router as on the egress port of a
router. Some interfaces will be "edge" interfaces and some
will be "interior" to the Differentiated Services domain. The
one point of difference between an ingress and an egress
interface is that all traffic on an egress interface is
queued, while traffic on an ingress interface will typically
be queued only for shaping purposes.
Hence, in this MIB, we model them identically, making the
distinction between ingress and egress interfaces an index
variable.
The MIB therefore contains five elements:
- Behavior Aggregate Classification Table
- Classifier Table
Fred Baker Expiration: January 2000 [Page 3]
Draft Differentiated Services MIB July 1999
- Meter Table
- Action Table
- Queue Table
3.2. Behavior Aggregate Classification Table
The Behavior Aggregate Classification Table is present for
several reasons. First, the DSCP must be identified somewhere
for identifying tagged streams of traffic. This could be done
in-line, and is not.
The reason the BA Classifier is pulled out into a separate
table is that we envisage the use of other tables for other
kinds of classifiers, public or proprietary. For example, the
typical "five-tuple" used in per-flow classification (as in
RSVP) might be represented by a table whose objects include
the necessary IP Addresses, the IP protocol, the necessary
TCP/UDP port numbers, and a RowStatus variable. By pulling the
classifier itself into a table that can be referenced via a
RowPointer, we enable the use of any sort of classification
table that one might wish to design. That classifier table
need not be found in this MIB. When ambiguity is present, we
disambiguate by explicitly ordering the application of
classification rules.
3.3. Classifier Table
The classifier table, now, indicates how traffic is sorted
out. It identifies separable classes of traffic, by reference
to an appropriate classifier, which may be anything from an
individual micro-flow to aggregates identified by DSCP. It
then sends these classified streams to an appropriate meter or
action. In a multi-stage meter, sub-classes of traffic may be
sent to different stages. For example, in AF1, AF11 traffic
might be sent to the first meter, AF12 traffic might be sent
to the second, and AF13 traffic sent to the second meter
stage's failure action.
The structure of the classifier table is a sequence of
unambiguous tests. Within each step in the sequence, it should
not be important in order - if order is present at all - the
tests are made. This is to facilitate optimized
implementations such as index trees. Sequence is present in
order to resolve ambiguity.
For example, one might want first to disallow certain
applications from using the network at all, or to classify
Fred Baker Expiration: January 2000 [Page 4]
Draft Differentiated Services MIB July 1999
some individual traffic streams that are not diff-serv marked.
Traffic that fails those tests might then be inspected for a
DSCP. "Then" implies sequence, and the sequence must be
somehow specified.
An important form of classifier is "everything else". The
final stage of the classifier should be configured to be
complete, as the result of an incomplete classifier is not
necessarily deterministic.
3.4. Meter Table
A meter, according to the conceptual model, measures the rate
at which a stream of traffic passes it, compares it to some
set of thresholds, and produces some number (two or more)
potential results. A given message is said to "conform" to the
meter if at the time that the message is being looked at the
stream appears to be within the meter's limit rate. In the
MIB, the structure of SNMP makes it easiest to implement this
as a set of one or more simple pass/fail tests, which are
cascaded. It is to be understood that the meter in a Traffic
Control Block is therefore implemented as a set of if-then-
else constructs.
The result of metering traffic is always some action.
The concept of conformance to a meter bears a comment. The
concept applied in several rate-control architectures,
including ATM, Frame Relay, Integrated Services, and
Differentiated Services, is variously described as a "leaky
bucket" or a "token bucket".
A leaky bucket algorithm is primarily used for traffic
shaping: traffic theoretically departs from the switch at a
flat rate of one bit every so many time units, and in fact
departs in packets at a rate approximating that. It is also
possible to build multi-rate leaky buckets, in which traffic
departs from the switch at varying rates depending on recent
activity or inactivity.
A token bucket is used to measure the behavior of a peer's
leaky bucket, for verification purposes. It is, by definition,
a relationship
interval = burst/rate, or
rate = burst/interval
Fred Baker Expiration: January 2000 [Page 5]
Draft Differentiated Services MIB July 1999
for some defined burst size, in bits, rate, in bits per
second, and time interval. Multi-rate token buckets (token
buckets with both a peak and a mean rate, and sometimes more
rates) are commonly used. In this case, the burst size for the
baseline traffic is conventionally referred to as the
"committed burst", and the time interval is as specified by
interval = committed burst/mean rate
but additional burst sizes (each an increment over its
predecessor) are defined, which are conventionally referred to
as "excess" burst sizes. The peak rate therefore equals the
sum of the burst sizes per interval.
A data stream is said to "conform" to a simple token bucket if
the switch receives at most the burst size in a given time
interval. In the multi-rate case, the traffic is said to
conform to the token bucket at a given level if its rate does
not exceed the sum of the relevant burst sizes in a given
interval. Received traffic pre-classified at one of the
"excess" rates (e.g., AF12 or AF13 traffic) is only compared
to the relevant excess buckets.
The fact that data is organized into variable length packets
introduces some uncertainty in this. For this reason, the
token bucket accepts a packet if any of its bits would have
been accepted, and "borrows" any excess capacity required from
that allotted to equivalently classified traffic in a
subsequent interval. More information about this is available
in [Model].
Multiple classes of traffic, as identified by the classifier
table, may be presented to the same meter. Imagine, for
example, that we desire to drop all traffic that uses any DSCP
that has not been publicly defined. A classifier entry might
exist for each such DSCP, shunting it to an "accepts
everything" meter, and dropping all traffic that conforms to
only that meter.
Clearly, it is necessary to identify what is to be done with
messages that conform to the meter, and with messages that do
not. It is also necessary for the meter to be arbitrarily
extensible, as some PHBs require the successive application of
an arbitrary number of meters. The approach taken in this
design is to have each meter indicate what action is to be
taken for conforming traffic, and what meter is to be used for
traffic which fails to conform. With the definition of a
Fred Baker Expiration: January 2000 [Page 6]
Draft Differentiated Services MIB July 1999
special type of meter to which all traffic conforms, we now
have the necessary flexibility.
3.5. Action Table
Considerable discussion has taken place regarding the possible
actions. Suggested actions include "no action", "mark the
traffic", "drop the traffic, randomly or all of it", and
"shape the traffic." In this MIB, three actions are
contemplated: marking the traffic, counting the traffic that
passes that route, applying a drop policy. The author notes
that marking the traffic with the same DSCP as it already has
no effect, and all traffic must expect to come up against some
drop policy.
Two sizes of objects are defined for some counters. These are
defined in accordance with the method found in [IFMIB]; both
32 and 64 bit counters are defined, with the expectation that
the 32 bit counter is simply the least significant bits of the
64 bit counter. For interfaces that operate at 20,000,000 (20
million) bits per second or less, 32-bit byte and packet
counters MUST be used. For interfaces that operate faster
than 20,000,000 bits/second, and slower than 650,000,000
bits/second, 32-bit packet counters MUST be used and 64-bit
octet counters MUST be used. For interfaces that operate at
650,000,000 bits/second or faster, 64-bit packet counters AND
64-bit octet counters MUST be used.
Traffic conforming to a meter and not dropped is presented to
a queue for further processing.
3.6. Queue Table
In this version of the MIB, a relatively simple FIFO queue is
envisaged within the Traffic Control Block. Scheduling among
TCBs is done by some external scheduler. We presume some form
of Class Weighted Round Robin within one or more sets of
queues, each of which enjoys preemptive priority over lower
numbered priorities of queue sets. Each queue is capable of
acting as a work-conserving queue (one which transmits as
rapidly as its weight allows, but guarantees to its class of
traffic, as a side-effect of its weight, a minimum rate), or
as a non-work-conserving or "shaping" queue. Queue sets and
more complex queue types - which are common and required to
correctly implement Differentiated Services, are modeled as
several of these FIFO queues.
Fred Baker Expiration: January 2000 [Page 7]
Draft Differentiated Services MIB July 1999
Multiple meters may direct their traffic to the same queue.
For example, the Assured Forwarding PHB suggests that all
traffic marked AF11, AF12, or AF13 be placed in the same queue
without reordering.
Some discussion has elapsed concerning the structure of the
queue in question, and its functions. It is expected that the
description of the queuing system will grow during working
group discussion. This is an area where vendors differ
markedly in their architectures.
3.7. The use of RowPointer
RowPointer is a textual convention used to identify a
conceptual row in an SNMP Table by pointing to one of its
objects. In this MIB, it is used in two ways: to indicate
indirection, and to indicate succession.
When used for indirection, as in the Classifier table, the
idea is to allow other MIBs, including proprietary ones, to
identify new and arcane classifiers - MAC headers, IP4 and IP6
headers, BGP Communities, and all sorts of things.
When used for succession, it answers the question "what
happens next?". Rather than presume that the next table must
be as specified in the conceptual model and providing its
index, the RowPointer takes you to the MIB row representing
that thing. In the Meter Table, for example, the "FailNext"
RowPointer might take you to another meter, while the
"SucceedNext" RowPointer would take you to an action.
Fred Baker Expiration: January 2000 [Page 8]
Draft Differentiated Services MIB July 1999
4. MIB Definition
DIFF-SERV-MIB DEFINITIONS ::= BEGIN
IMPORTS
Unsigned32, Counter32, Counter64, OBJECT-TYPE,
MODULE-IDENTITY, zeroDotZero, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, RowPointer, TestAndIncr
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
ifIndex FROM IF-MIB;
diffServMib MODULE-IDENTITY
LAST-UPDATED "9907150732Z" -- Thu Jul 15 07:32:36 PDT 1999
ORGANIZATION "Cisco Systems"
CONTACT-INFO
" Fred Baker
Postal: 519 Lado Drive
Santa Barbara, California 93111
Tel: +1 (408)526-4257
FAX: +1 (805)681-0115
E-mail: fred@cisco.com"
DESCRIPTION
"This MIB defines the objects necessary to manage a
device that uses the Differentiated Services
Architecture described in RFC 2475."
REVISION "9907150732Z" -- Thu Jul 15 07:32:36 PDT 1999
DESCRIPTION
"Initial version, published as RFC xxxx."
::= { mib-2 12345 } -- anybody who uses this
-- unassigned number
-- deserves the wrath of IANA
diffServObjects OBJECT IDENTIFIER ::= { diffServMib 1 }
diffServTables OBJECT IDENTIFIER ::= { diffServMib 2 }
diffServMIBConformance OBJECT IDENTIFIER ::= { diffServMib 3 }
Fred Baker Expiration: January 2000 [Page 9]
Draft Differentiated Services MIB July 1999
-- The tools necessary to perform basic Behavior
-- Aggregate Classification
--
Dscp ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The code point used for discriminating a traffic
stream."
SYNTAX INTEGER (0..63)
diffServAggregateTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiffServAggregateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The 'Aggregate' Table enumerates Behavior Aggregate
classifiers (DSCPs) that a system may identify traffic
using."
::= { diffServTables 1 }
diffServAggregateEntry OBJECT-TYPE
SYNTAX DiffServAggregateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An 'aggregate' entry describes a single BA
classifier."
INDEX { diffServAggregateDSCP }
::= { diffServAggregateTable 1 }
DiffServAggregateEntry ::= SEQUENCE {
diffServAggregateDSCP Dscp
}
diffServAggregateDSCP OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the Differentiated Services Code Point (DSCP)
for the classifier. This object is only meant to be
pointed to by a RowPointer from other tables, such as
the diffServClassifierMatchObject, and is no actually
configured or changed."
::= { diffServAggregateEntry 1 }
Fred Baker Expiration: January 2000 [Page 10]
Draft Differentiated Services MIB July 1999
-- This object allows a configuring system to obtain a
-- unique value for diffServClassifierNumber for purposes of
-- configuration
diffServClassifierUnique OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The diffServClassifierUnique object yields a unique
new value for diffServClassifierNumber when read and
subsequently set. This value must be tested for
uniqueness."
::= { diffServObjects 1 }
-- The Classifier Table allows us to enumerate the
-- relationship between arbitrary classifiers and
-- the meters which apply to classified streams.
diffServClassifierTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiffServClassifierEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The classifier table enumerates specific classifiers
that a system may apply, including Differentiated
Services Code Points (DSCPs) and Multi-field
discriminators such as {Source IP Address, Destination
IP Address, IP Protocol, Source TCP/UDP Port,
Destination TCP/UDP Port)."
::= { diffServTables 2 }
diffServClassifierEntry OBJECT-TYPE
SYNTAX DiffServClassifierEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the classifier table describes a single
classifier."
INDEX { ifIndex, diffServInterfaceDirection,
diffServClassifierNumber }
::= { diffServClassifierTable 1 }
DiffServClassifierEntry ::= SEQUENCE {
diffServInterfaceDirection INTEGER,
diffServClassifierNumber INTEGER,
diffServClassifierMatchObject RowPointer,
Fred Baker Expiration: January 2000 [Page 11]
Draft Differentiated Services MIB July 1999
diffServClassifierNext RowPointer,
diffServClassifierSequence Unsigned32,
diffServClassifierStatus RowStatus
}
diffServInterfaceDirection OBJECT-TYPE
SYNTAX INTEGER {
inbound(1), -- ingress interface
outbound(2) -- egress interface
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Specifies the direction for this entry on the
interface. 'inbound' traffic is operated on during
receipt, while 'outbound' traffic is operated on prior
to transmission."
::= { diffServClassifierEntry 1 }
diffServClassifierNumber OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"diffServClassifierNumber enumerates the classifier
entry."
::= { diffServClassifierEntry 2 }
diffServClassifierMatchObject OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A pointer to the row that describes the applicable
classifier. An obvious choice would be the
diffServAggregateEntry for a given DSCP, but other
choices include tables describing any classifier that
may be of interest. If the row pointed to does not
exist, the classifier is ignored.
The NULL OID zeroDotZero is interpreted to match
anything not matched by another classifier."
DEFVAL { zeroDotZero }
::= { diffServClassifierEntry 3 }
diffServClassifierNext OBJECT-TYPE
SYNTAX RowPointer
Fred Baker Expiration: January 2000 [Page 12]
Draft Differentiated Services MIB July 1999
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 'next' variable selects the appropriate meter or
action to apply to this class of traffic."
::= { diffServClassifierEntry 4 }
diffServClassifierSequence OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The sequence in which classifiers are applied, in
ascending order. Classifiers with the same sequence
number must be unambiguous. Classifiers with different
sequence numbers may overlap in their ranges, with the
understanding that the first applied classifier to
match a packet is taken."
DEFVAL { 0 }
::= { diffServClassifierEntry 5 }
diffServClassifierStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The RowStatus variable controls the activation,
deactivation, or deletion of a classifier. Any writable
variable may be modified whether the row is active or
notInService."
::= { diffServClassifierEntry 6 }
Fred Baker Expiration: January 2000 [Page 13]
Draft Differentiated Services MIB July 1999
-- This object allows a configuring system to obtain a
-- unique value for diffServClassifierNumber for purposes of
-- configuration
diffServTBMeterUnique OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The diffServTBMeterUnique object yieldiffServ a unique
new value for diffServTBMeterNumber when read and
subsequently set. This value must be tested for
uniqueness."
::= { diffServObjects 2 }
-- The Meter Table allows us to enumerate the
-- relationship between meters and the actions, other
-- meters, and queues that result from them.
diffServTBMeterTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiffServTBMeterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Meter Table enumerates specific token bucket
meters that a system may use to police a stream of
classified traffic. Such a stream may include a single
micro-flow, all traffic from a given source to a given
destination, all traffic conforming to a single
classifier, or any other cut of the traffic, including
all of it.
Note that the conceptual model requires all traffic to
pass through one or more meters, and that the last
meter configured in such a sequence must always
conform.
Counters in this table start counting on creation of
the meter that specifies their existence."
::= { diffServTables 3 }
diffServTBMeterEntry OBJECT-TYPE
SYNTAX DiffServTBMeterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the meter table describes a single token
Fred Baker Expiration: January 2000 [Page 14]
Draft Differentiated Services MIB July 1999
bucket meter. Note that a meter has exactly one rate,
defined as the burst size each time interval. Multiple
meters may be cascaded should a multi-rate token bucket
be needed in a given Per-Hop Behavior. An example of
such a PHB is AF."
INDEX { ifIndex, diffServInterfaceDirection,
diffServTBMeterNumber }
::= { diffServTBMeterTable 1 }
DiffServTBMeterEntry ::= SEQUENCE {
diffServTBMeterNumber INTEGER,
diffServTBMeterInterval Unsigned32,
diffServTBMeterBurstSize Unsigned32,
diffServTBMeterFailNext RowPointer,
diffServTBMeterSucceedNext RowPointer,
diffServTBMeterStatus RowStatus
}
diffServTBMeterNumber OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The number of the meter, for reference from the
classifier or in cascade from another meter."
::= { diffServTBMeterEntry 1 }
diffServTBMeterInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of microseconds in the token bucket
interval for this meter. Note that implementations
frequently do not keep time in microseconds internally,
so in implementation the effect of this value must be
approximated."
::= { diffServTBMeterEntry 2 }
diffServTBMeterBurstSize OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bytes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of bytes in a single transmission burst.
Fred Baker Expiration: January 2000 [Page 15]
Draft Differentiated Services MIB July 1999
The rate at which the metered traffic may run is one
burst per interval. Note that if multiple meters are
cascaded onto one PHB, such as in AF, their intervals
must be equal, and the peak rate of the data stream is
the sum of their intervals per interval."
::= { diffServTBMeterEntry 3 }
diffServTBMeterFailNext OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If the traffic does not conform to the meter, the next
meter or action to enquire of."
::= { diffServTBMeterEntry 4 }
diffServTBMeterSucceedNext OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 'Succeed Next' pointer selects which action or
queue on the interface that to be used with the
message. Incoming traffic may use the value zeroDotZero
in this variable to indicate that no queuing on receipt
occurs. Incoming interfaces generally use queuing
either to divert routing traffic for speedier
processing during a flap, or for shaping purposes."
DEFVAL { zeroDotZero }
::= { diffServTBMeterEntry 5 }
diffServTBMeterStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The RowStatus variable controls the activation,
deactivation, or deletion of a meter. Any writable
variable may be modified whether the row is active or
notInService."
::= { diffServTBMeterEntry 6 }
Fred Baker Expiration: January 2000 [Page 16]
Draft Differentiated Services MIB July 1999
-- This object allows a configuring system to obtain a
-- unique value for diffServActionNumber for purposes of
-- configuration
diffServActionUnique OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The diffServActionUnique object yields a unique new
value for diffServActionNumber when read and
subsequently set. This value must be tested for
uniqueness."
::= { diffServObjects 3 }
-- The Meter Table allows us to enumerate the
-- relationship between meters and the actions, other meters,
-- and queues that result from them.
diffServActionTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiffServActionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Action Table enumerates specific apply to a stream
of classified traffic. Such a stream may include a
single micro-flow, all traffic from a given source to a
given destination, all traffic conforming to a single
classifier, or any other cut of the traffic, including
all of it.
Counters in this table start counting on creation of
the action that specifies their existence."
::= { diffServTables 4 }
diffServActionEntry OBJECT-TYPE
SYNTAX DiffServActionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the action table describes the actions
applied to traffic conforming to a given meter."
INDEX { ifIndex, diffServInterfaceDirection,
diffServActionNumber }
::= { diffServActionTable 1 }
DiffServActionEntry ::= SEQUENCE {
Fred Baker Expiration: January 2000 [Page 17]
Draft Differentiated Services MIB July 1999
diffServActionNumber INTEGER,
diffServActionNext RowPointer,
diffServActionDSCP Dscp,
diffServActionMinThreshold Unsigned32,
diffServActionMaxThreshold Unsigned32,
diffServActionDropPolicy INTEGER,
diffServActionHCConformingPackets Counter64,
diffServActionConformingPackets Counter32,
diffServActionHCConformingOctets Counter64,
diffServActionConformingOctets Counter32,
diffServActionTailDrops Counter32,
diffServActionHCTailDrops Counter64,
diffServActionRandomDrops Counter32,
diffServActionHCRandomDrops Counter64,
diffServActionStatus RowStatus
}
diffServActionNumber OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The number of the meter, for reference from the
classifier or in cascade from another meter."
::= { diffServActionEntry 1 }
diffServActionNext OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 'Next' pointer selects which queue or Traffic
Control Block on the interface. Incoming traffic may
use the value zeroDotZero in this variable to indicate
that no queuing on receipt occurs. Incoming interfaces
generally use queuing either to divert routing traffic
for speedier processing during a flap, or for shaping
purposes."
DEFVAL { zeroDotZero }
::= { diffServActionEntry 2 }
diffServActionDSCP OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The DSCP that traffic conforming to this classifier
Fred Baker Expiration: January 2000 [Page 18]
Draft Differentiated Services MIB July 1999
and this meter is remarked with. Note that if the
classifier is working from the same DSCP value, no
effective change in the DSCP results.
Differentiated Services may result in packet remarking
both on ingress to a network and on egress, and it is
quite possible that ingress and egress would occur in
the same router."
::= { diffServActionEntry 3 }
diffServActionMinThreshold OBJECT-TYPE
SYNTAX Unsigned32
UNITS "packets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The min-threshold is the queue depth that a random
drop process will seek to manage the queue's depth to.
This object is in the action table rather than the
queue table because Differentiated Services PHBs, such
as the Assured Service, permit differently classified
traffic to have different drop parameters even though
they occupy the same queue."
::= { diffServActionEntry 4 }
diffServActionMaxThreshold OBJECT-TYPE
SYNTAX Unsigned32
UNITS "packets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The max-threshold is the maximum permissible queue
depth. In tail drop scenarios, the queue will drop if a
packet is presented to it and it is instantaneously
full by this measure. In random drop scenarios, the
queue will drop if a packet is presented to it and the
average queue depth exceeds the max-threshold.
This object is in the action table rather than the
queue table because Differentiated Services PHBs, such
as the Assured Service, permit differently classified
traffic to have different drop parameters even though
they occupy the same queue."
::= { diffServActionEntry 5 }
diffServActionDropPolicy OBJECT-TYPE
Fred Baker Expiration: January 2000 [Page 19]
Draft Differentiated Services MIB July 1999
SYNTAX INTEGER {
other(1),
alwaysDrop (2), -- Disallowed traffic
tailDrop(3), -- Fixed Queue Size
randomDrop(4) -- RED w/thresholds
-- per class
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The drop policy applied to traffic."
::= { diffServActionEntry 6 }
diffServActionHCConformingPackets OBJECT-TYPE
SYNTAX Counter64
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Packets conforming to this meter. This
object is used on high speed interfaces.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 7 }
diffServActionConformingPackets OBJECT-TYPE
SYNTAX Counter32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Packets conforming to this meter. This
object may be used on low speed interfaces, and
represents the least significant 32 bits of
diffServActionHCConformingPackets.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 8 }
diffServActionHCConformingOctets OBJECT-TYPE
SYNTAX Counter64
Fred Baker Expiration: January 2000 [Page 20]
Draft Differentiated Services MIB July 1999
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets conforming to this meter. This
object is used on high speed interfaces.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 9 }
diffServActionConformingOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets conforming to this meter. This
object may be used on low speed interfaces, and
represents the least significant 32 bits of
diffServActionHCConformingOctets.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 10 }
diffServActionTailDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets conforming to this classifier
and meter that have been dropped because either the
meter always drops, or the queue's depth exceeds the
max-threshold value. On high speed devices, this
object implements the least significant 32 bits of
diffServActionHCTailDrops .
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 11 }
Fred Baker Expiration: January 2000 [Page 21]
Draft Differentiated Services MIB July 1999
diffServActionHCTailDrops OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets conforming to this classifier
and meter that have been dropped because either the
meter always drops, or the queue's depth exceeds the
max-threshold value. This object should be used on
high speed interfaces.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 12 }
diffServActionRandomDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets conforming to this classifier
and meter that have been dropped by a random drop
process because the queue is over-full. On high speed
lines, this object reflects the least significant 32
bits of diffServActionHCRandomDrops.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime."
::= { diffServActionEntry 13 }
diffServActionHCRandomDrops OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets conforming to this classifier
and meter that have been dropped by a random drop
process because the queue is over-full. This object is
used on high speed lines.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
Fred Baker Expiration: January 2000 [Page 22]
Draft Differentiated Services MIB July 1999
ifCounterDiscontinuityTime."
::= { diffServActionEntry 14 }
diffServActionStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The RowStatus variable controls the activation,
deactivation, or deletion of a meter. Any writable
variable may be modified whether the row is active or
notInService."
::= { diffServActionEntry 15 }
Fred Baker Expiration: January 2000 [Page 23]
Draft Differentiated Services MIB July 1999
-- This object allows a configuring system to obtain a
-- unique value for diffServQueueNumber for purposes of
-- configuration
diffServQueueUnique OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The diffServQueueUnique object yields a unique new
value for diffServQueueNumber when read and
subsequently set. This value must be tested for
uniqueness."
::= { diffServObjects 4 }
-- The Queue Table allows us to describe queues
diffServQueueTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiffServQueueEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Queue Table enumerates the queues on an interface.
Queues are used to store traffic during intervals when
the arrival rate exceeds the departure rate for a class
of traffic. Because some PHBs indicate that the use of
a priority queue may be advisable, each queue in this
system is seen as having a priority. Those queues that
share the same priority operate in what may externally
appear to be a Weighted Round Robin manner, and preempt
the traffic belonging to any lower priority. For this
reason, it is strongly urged that traffic placed into
prioritized queues be strongly policed to avoid traffic
lockout.
Queues in this table also have a minimum and a maximum
rate. When a maximum rate is specified, the queue acts
as a shaper if it has sufficient traffic and capacity
is available. If it is a minimum rate, then the weight
in the WRR is effectively set to this rate divided by
the sum of the rates of queues on the interface,
guaranteeing it at least that throughput rate. If it is
a maximum rate, the queue operates as a shaper. A
shaper potentially reduces the rate of traffic through
it to the indicated rate, and minimizes variations in
rate."
::= { diffServTables 5 }
Fred Baker Expiration: January 2000 [Page 24]
Draft Differentiated Services MIB July 1999
diffServQueueEntry OBJECT-TYPE
SYNTAX DiffServQueueEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Queue Table describes a single FIFO
queue."
INDEX { ifIndex, diffServInterfaceDirection,
diffServQueueNumber }
::= { diffServQueueTable 1 }
DiffServQueueEntry ::= SEQUENCE {
diffServQueueNumber INTEGER,
diffServQueueMinimumRate Unsigned32,
diffServQueueMaximumRate Unsigned32,
diffServQueuePriority Unsigned32,
diffServQueueNextTCB RowPointer,
diffServQueueStatus RowStatus
}
diffServQueueNumber OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The number of the queue."
::= { diffServQueueEntry 1 }
diffServQueueMinimumRate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "KBPS"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The rate of the queue, in kilobits per second (KBPS).
This unit is chosen because interfaces exist at the
time of this writing which exceed the number of bits
per second which may be represented in a 32 bit number.
If the value is zero, then there is effectively no
minimum rate. If the value is non-zero, the queue set
will seek to assure this class of traffic at least this
rate."
::= { diffServQueueEntry 2 }
diffServQueueMaximumRate OBJECT-TYPE
SYNTAX Unsigned32
Fred Baker Expiration: January 2000 [Page 25]
Draft Differentiated Services MIB July 1999
UNITS "KBPS"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The rate of the queue, in kilobits per second (KBPS).
This unit is chosen because interfaces exist at the
time of this writing which exceed the number of bits
per second which may be represented in a 32 bit number.
If the value is zero, then there is effectively no
maximum rate. If the value is non-zero, the queue set
will seek to assure this class of traffic at most this
rate."
::= { diffServQueueEntry 3 }
diffServQueuePriority OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The priority of the queue. If multiple queues exist on
the same interface at the same priority, they are
effectively given Weighted Round Robin service. If
multiple priorities are configured on an interface,
traffic with a numerically higher priority number is
deemed to have higher priority than other traffic, and
is preemptively serviced."
::= { diffServQueueEntry 4 }
diffServQueueNextTCB OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 'Next' pointer selects the successor TCB on the
interface. Incoming traffic may use the value
zeroDotZero in this variable to indicate that the
packet is now to be routed; outbound traffic may use
the same value to indicate that no subsequent queuing
applies. Ingress interfaces generally use queuing
either to divert routing traffic for speedier
processing during a flap, or for shaping purposes."
DEFVAL { zeroDotZero }
::= { diffServQueueEntry 5 }
diffServQueueStatus OBJECT-TYPE
SYNTAX RowStatus
Fred Baker Expiration: January 2000 [Page 26]
Draft Differentiated Services MIB July 1999
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The RowStatus variable controls the activation,
deactivation, or deletion of a queue. Any writable
variable may be modified whether the row is active or
notInService."
::= { diffServQueueEntry 6 }
Fred Baker Expiration: January 2000 [Page 27]
Draft Differentiated Services MIB July 1999
-- MIB Compliance statements. Three variations of
-- compliance are described, for optical, LAN, and low speed
-- interfaces. The difference is the implementation of
-- diffServActionHCConformingOctets
-- and diffServActionHCConformingPackets
diffServMIBCompliances OBJECT IDENTIFIER ::= { diffServMIBConformance 1 }
diffServMIBGroups OBJECT IDENTIFIER ::= { diffServMIBConformance 2 }
diffServMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This MIB may be implemented as a read-only or as a
read-create MIB. As a result, it may be used for
monitoring or for configuration.
Standard compliance implies that the implementation
complies for interfaces for which an interface's octet
counter might wrap at most once an hour, which by the
IFMIB's convention applies to interfaces under 20 MBPS.
It thus applies to any device which might implement a
low speed serial line, Ethernet, Token Ring."
MODULE -- This Module
MANDATORY-GROUPS {
diffServMIBClassifierGroup, diffServMIBMeterGroup,
diffServMIBQueueGroup, diffServMIBActionGroup
-- note that diffServMIBHCCounterGroup is
-- mandatory for medium and high speed interfaces
-- note that diffServMIBVHCCounterGroup is
-- mandatory for high speed interfaces
-- note that the diffServMIBStaticGroup is
-- mandatory for implementations that implement a
-- read-write or read-create mode.
}
GROUP diffServMIBHCCounterGroup
DESCRIPTION
"This group is mandatory for those network interfaces
for which the value of the corresponding instance of
ifSpeed is greater than 20,000,000 bits/second."
GROUP diffServMIBVHCCounterGroup
DESCRIPTION
"This group is mandatory for those network interfaces
Fred Baker Expiration: January 2000 [Page 28]
Draft Differentiated Services MIB July 1999
for which the value of the corresponding instance of
ifSpeed is greater than 650,000,000 bits/second."
OBJECT diffServClassifierMatchObject
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierSequence
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterInterval
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterBurstSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterFailNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterSucceedNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Fred Baker Expiration: January 2000 [Page 29]
Draft Differentiated Services MIB July 1999
OBJECT diffServActionNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDSCP
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionMinThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionMaxThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDropPolicy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMinimumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMaximumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueuePriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueNextTCB
MIN-ACCESS read-only
Fred Baker Expiration: January 2000 [Page 30]
Draft Differentiated Services MIB July 1999
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { diffServMIBCompliances 1 }
Fred Baker Expiration: January 2000 [Page 31]
Draft Differentiated Services MIB July 1999
diffServMIBVHCCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This MIB may be implemented as a read-only or as a
read-create MIB. As a result, it may be used for
monitoring or for configuration.
Very High Speed compliance implies that the
implementation complies for interfaces for which an
interface's packet or octet counters might wrap more
than once an hour, which by the IFMIB's convention
applies to interfaces over 650 MBPS, or OC-12."
MODULE -- This Module
MANDATORY-GROUPS {
diffServMIBClassifierGroup, diffServMIBMeterGroup,
diffServMIBQueueGroup, diffServMIBHCCounterGroup,
diffServMIBVHCCounterGroup, diffServMIBActionGroup
-- note that the diffServMIBStaticGroup is
-- mandatory for implementations that implement a
-- read-write or read-create mode.
}
OBJECT diffServClassifierMatchObject
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierSequence
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterInterval
MIN-ACCESS read-only
DESCRIPTION
Fred Baker Expiration: January 2000 [Page 32]
Draft Differentiated Services MIB July 1999
"Write access is not required."
OBJECT diffServTBMeterBurstSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterFailNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterSucceedNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDSCP
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionMinThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionMaxThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDropPolicy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Fred Baker Expiration: January 2000 [Page 33]
Draft Differentiated Services MIB July 1999
OBJECT diffServActionStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMinimumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMaximumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueuePriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueNextTCB
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { diffServMIBCompliances 2 }
Fred Baker Expiration: January 2000 [Page 34]
Draft Differentiated Services MIB July 1999
diffServMIBHCCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"This MIB may be implemented as a read-only or as a
read-create MIB. As a result, it may be used for
monitoring or for configuration.
High Speed compliance implies that the implementation
complies for interfaces for which an interface's octet
counters might wrap more than once an hour, which by
the IFMIB's convention applies to interfaces over 20
MBPS, but under 650 MBPS. It thus applies to devices
which implement a 100 MBPS Ethernet, FDDI, E3, DS3, or
SONET/SDH interface up to OC-12."
MODULE -- This Module
MANDATORY-GROUPS {
diffServMIBClassifierGroup, diffServMIBMeterGroup,
diffServMIBQueueGroup, diffServMIBHCCounterGroup,
diffServMIBActionGroup
-- note that diffServMIBVHCCounterGroup is
-- mandatory for high speed interfaces
-- note that the diffServMIBStaticGroup is
-- mandatory for implementations that implement a
-- read-write or read-create mode.
}
GROUP diffServMIBVHCCounterGroup
DESCRIPTION
"This group is mandatory for those network interfaces
for which the value of the corresponding instance of
ifSpeed is greater than 650,000,000 bits/second."
OBJECT diffServClassifierMatchObject
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServClassifierSequence
MIN-ACCESS read-only
DESCRIPTION
Fred Baker Expiration: January 2000 [Page 35]
Draft Differentiated Services MIB July 1999
"Write access is not required."
OBJECT diffServClassifierStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterInterval
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterBurstSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterFailNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterSucceedNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServTBMeterStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionNext
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDSCP
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionMinThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Fred Baker Expiration: January 2000 [Page 36]
Draft Differentiated Services MIB July 1999
OBJECT diffServActionMaxThreshold
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionDropPolicy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServActionStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMinimumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueMaximumRate
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueuePriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueNextTCB
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT diffServQueueStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { diffServMIBCompliances 3 }
Fred Baker Expiration: January 2000 [Page 37]
Draft Differentiated Services MIB July 1999
diffServMIBClassifierGroup OBJECT-GROUP
OBJECTS {
diffServAggregateDSCP,
diffServClassifierMatchObject,
diffServClassifierNext,
diffServClassifierSequence,
diffServClassifierStatus
}
STATUS current
DESCRIPTION
"The Classifier Group defines the MIB Objects that
describe a classifier."
::= { diffServMIBGroups 1 }
diffServMIBMeterGroup OBJECT-GROUP
OBJECTS {
diffServTBMeterInterval, diffServTBMeterBurstSize,
diffServTBMeterSucceedNext, diffServTBMeterFailNext,
diffServTBMeterStatus
}
STATUS current
DESCRIPTION
"The Meter Group defines the objects used in describing
a meter."
::= { diffServMIBGroups 2 }
diffServMIBActionGroup OBJECT-GROUP
OBJECTS {
diffServActionDropPolicy,
diffServActionRandomDrops,
diffServActionTailDrops,
diffServActionMinThreshold,
diffServActionMaxThreshold, diffServActionDSCP,
diffServActionNext,
diffServActionConformingPackets,
diffServActionConformingOctets,
diffServActionStatus
}
STATUS current
DESCRIPTION
"The Action Group defines the objects used in
describing an action."
::= { diffServMIBGroups 3 }
diffServMIBHCCounterGroup OBJECT-GROUP
OBJECTS {
diffServActionHCConformingOctets
Fred Baker Expiration: January 2000 [Page 38]
Draft Differentiated Services MIB July 1999
}
STATUS current
DESCRIPTION
"At 20,000,000 bits per second or greater, the number
of octets a given class may count can overflow a 32 bit
counter in under an hour. Therefore, by convention
established in the IFMIB, the 64 bit counter must be
implemented as well."
::= { diffServMIBGroups 4 }
diffServMIBVHCCounterGroup OBJECT-GROUP
OBJECTS {
diffServActionHCConformingPackets,
diffServActionHCRandomDrops,
diffServActionHCTailDrops
}
STATUS current
DESCRIPTION
"At 650,000,000 bits per second or greater, the number
of packets a given class may count can overflow a 32
bit counter in under an hour. Therefore, by convention
established in the IFMIB, the 64 bit counter must be
implemented as well."
::= { diffServMIBGroups 5 }
diffServMIBQueueGroup OBJECT-GROUP
OBJECTS {
diffServQueueMinimumRate,
diffServQueueMaximumRate,
diffServQueuePriority, diffServQueueStatus,
diffServQueueNextTCB
}
STATUS current
DESCRIPTION
"The Queue Group contains the objects that describe an
interface's queues."
::= { diffServMIBGroups 6 }
diffServMIBStaticGroup OBJECT-GROUP
OBJECTS {
diffServClassifierUnique, diffServTBMeterUnique,
diffServQueueUnique, diffServActionUnique
}
STATUS current
DESCRIPTION
"The Static Group contains scalar objects used in
creating unique enumerations for classifiers, meters,
Fred Baker Expiration: January 2000 [Page 39]
Draft Differentiated Services MIB July 1999
and queues."
::= { diffServMIBGroups 7 }
END
Fred Baker Expiration: January 2000 [Page 40]
Draft Differentiated Services MIB July 1999
5. Acknowledgments
This MIB has been developed with active involvement from a
number of sources, but most notably Yoram Bernet, Steve Blake,
Brian Carpenter, Kwok Chan, Dave Durham, Jeremy Greene, Roch
Guerin, Scott Hahn, Keith McCloghrie, Kathleen Nichols, Ping
Pan, Andrew Smith, and Bert Wijnen.
6. Security Considerations
It is clear that this MIB is potentially useful for
configuration, and anything that can be configured can be
misconfigured, with potentially disastrous effect.
At this writing, no security holes have been identified beyond
those that SNMP Security is itself intended to address. These
relate to primarily controlled access to sensitive information
and the ability to configure a device - or which might result
from operator error, which is beyond the scope of any security
architecture.
There are a number of management objects defined in this MIB
that have a MAX-ACCESS clause of read-write and/or read-
create. Such objects may be considered sensitive or vulnerable
in some network environments. The support for SET operations
in a non-secure environment without proper protection can have
a negative effect on network operations. The use of SNMP
Version 3 is recommended over prior versions, for
configuration control, as its security model is improved.
There are a number of managed objects in this MIB that may
contain information that may be sensitive from a business
perspective, in that they may represent a customer's service
contract or the filters that the service provider chooses to
apply to a customer's ingress or egress traffic. There are no
objects which are sensitive in their own right, such as
passwords or monetary amounts.
It may be important to control even GET access to these
objects and possibly to even encrypt the values of these
object when sending them over the network via SNMP. Not all
versions of SNMP provide features for such a secure
environment.
Fred Baker Expiration: January 2000 [Page 41]
Draft Differentiated Services MIB July 1999
7. References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, Cabletron Systems, Inc., BMC Software, Inc.,
IBM T. J. Watson Research, April 1999
[2] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-based
Internets", RFC 1155, STD 16, Performance Systems
International, Hughes LAN Systems, May 1990
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
RFC 1212, STD 16, Performance Systems International,
Hughes LAN Systems, March 1991
[4] M. Rose, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, Performance Systems International,
March 1991
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", RFC 2578, STD 58, Cisco
Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April
1999
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", RFC 2579, STD 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 Management Protocol", RFC 1157, STD 15,
SNMP Research, Performance Systems International,
Performance Systems International, MIT Laboratory for
Computer Science, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, SNMP
Fred Baker Expiration: January 2000 [Page 42]
Draft Differentiated Services MIB July 1999
Research, Inc., Cisco Systems, Inc., Dover Beach
Consulting, Inc., International Network Services, January
1996.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, SNMP
Research, Inc., Cabletron Systems, Inc., BMC Software,
Inc., IBM T. J. Watson Research, April 1999
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, IBM T. J. Watson Research,
April 1999
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, SNMP Research, Inc., Secure
Computing Corporation, Cisco Systems, April 1999
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, IBM T. J. Watson
Research, BMC Software, Inc., Cisco Systems, Inc., April
1999
[16] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, SNMP Research,
Inc., TIS Labs at Network Associates, Inc., Ericsson,
Cisco Systems, April 1999
[DSCP]
K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers." RFC 2474, December 1998.
Fred Baker Expiration: January 2000 [Page 43]
Draft Differentiated Services MIB July 1999
[Architecture]
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Service." RFC
2475, December 1998.
[AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
Forwarding PHB Group." RFC 2597, June 1999.
[EF] V. Jacobson, K. Nichols, K. Poduri. "An Expedited
Forwarding PHB." RFC 2598, June 1999.
[Model]
Bernet et al, "A Conceptual Model for Diffserv Routers",
06/25/1999, draft-ietf-diffserv-model-00.txt
[IFMIB]
K. McCloghrie, F. Kastenholz. "The Interfaces Group MIB
using SMIv2", Request for Comments 2233, November 1997.
8. Author's Address:
Fred Baker
519 Lado Drive
Santa Barbara, California 93111
fred@cisco.com
Fred Baker Expiration: January 2000 [Page 44]
