draft-ietf-diffserv-mib-01

[フレーム]

 Draft Differentiated Services MIB October 1999
 
 Fred Baker
 Kwok Ho Chan
 Nortel Networks
 Andrew Smith
 Extreme Networks
 
 Management Information Base for the
 Differentiated Services Architecture
 
 draft-ietf-diffserv-mib-01.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, etc Expiration: April 2000 [Page 1]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 2]

 Draft Differentiated Services MIB October 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 six elements:
 - Behavior Aggregate Classification Table
 - Multi-Field Classification Table
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 3]

 Draft Differentiated Services MIB October 1999
 
 
 - Classifier Table
 - Meter Table
 - Action Table
 - Queue Table
 
 3.2. Classifier Table
 
 The classifier table 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
 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.
 
 Two forms of classifiers are Behavior Aggregate (BA) and
 Multi-Field (MF) Classifiers. These classifiers are specified
 here at the per interface level, they can be derived from
 some higher level policies. For example, QoS Policies
 provisioned via QoS PIB (Policy Information Base), Routing
 Policies with QoS information via BGP Policy setting
 mechanism, and Routing Policies with QoS information from
 traffic engineered routes. The source of classifier is
 indicated by the diffServClassifierConfigType attribute of the
 diffServClassifierEntry object. The attribute
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 4]

 Draft Differentiated Services MIB October 1999
 
 
 diffServClassifierConfigTypeInfo can be used to further
 associate the classifier with specific grouping based on the
 ConfigType. For example, with PIB ConfigType, the
 ConfigTypeInfo attribute can hold the RoleCombination from
 which the classifier is derived. With BGP ConfigType, the
 ConfigTypeInfo can hold the BGP Community String that
 identifies the BGP Routing Policy from which the classifier is
 derived. With the use of higher level policies, the
 classifier table is used primarily for monitoring purpose, but
 this does not exclude its use for configuration purpose.
 
 3.2.1. 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.2.2. Multi-Field Classification Table
 
 In the same spirit as the BA Classification Table, the Multi-
 Field Classification Table is in a separate table that can be
 referenced via a RowPointer, namely
 diffServClassifierMatchObject attribute of
 diffServClassifierEntry object. Each entry in the MF
 Classification Table defines a MF Classifier. With the use of
 InetEndpoint for both IPv4 and IPv6 addressing. The use of MF
 Classifiers is discussed in [DSARCH] and abstract examples of
 how they might be configured are provided in [DSMODEL].
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 5]

 Draft Differentiated Services MIB October 1999
 
 
 3.3. 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
 
 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
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 6]

 Draft Differentiated Services MIB October 1999
 
 
 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
 special type of meter to which all traffic conforms, we now
 have the necessary flexibility.
 
 3.4. 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
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 7]

 Draft Differentiated Services MIB October 1999
 
 
 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.5. Queue Table
 
 In this version of the MIB, a relatively simple FIFO queue is
 envisaged within the Traffic Control Block (TCB). 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 structure can be built from these FIFO queues, including
 chain of queues using the NextTCB attribute. The scheduling
 discipline of a queue amongst the queue set of an inter- face
 is specified. When all the queues in a queue set uses
 priority queue discipline, the queue set will use strict
 priority queue scheduling using each queue's priority
 attribute. When all the queues in a queue set uses weighted
 fair queue discipline, the queue set will use weighted fair
 queue scheduling, with the weight specified by the minimum
 rate attribute. A mixed scheduling discipline can be built
 for a queue set. For example, with the following queue set:
 Q Number Q Discipline Q MinRate Q Priority
 -------- ------------ --------- ----------
 11 PQ 0 10
 12 PQ 0 9
 13 WFQ 800 KBPS 8
 14 WFQ 600 KBPS 8
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 8]

 Draft Differentiated Services MIB October 1999
 
 
 15 WFQ 300 KBPS 8
 
 All traffic in queue 11 will be serviced first, then all
 traffic in queue 12 will be serviced second. After traffic in
 queues 11 and 12 are serviced, queues 13, 14, 15 are serviced
 among themselves in a round robin fashion, with their
 respective weights indicated by their minimum rate attribute.
 
 The queue can also operate as a traffic shaper by using the
 maximum rate attribute.
 
 In addition some dropping algorithms rely on an averaged queue
 depth to measure sustained, as opposed to instantaneous,
 congestion. There are several methods for averaging the queue
 depth. All of these methods share a mechanism specifying the
 influence of the actual queue depth on the averaged queue
 depth. Hence the attribute diffServQueueOccupancyWeight is
 used.
 
 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.6. 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"
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 9]

 Draft Differentiated Services MIB October 1999
 
 
 RowPointer might take you to another meter, while the
 "SucceedNext" RowPointer would take you to an action.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 10]

 Draft Differentiated Services MIB October 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;
 InetEndpointType, InetEndpoint FROM INET-ENDPOINT-MIB;
 
 diffServMib MODULE-IDENTITY
 LAST-UPDATED "9907190100Z" -- Mon Jul 19 01:00:00 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"
 " Kwok Ho Chan
 Postal: 600 Technology Park Drive
 Billerica, Massachusetts 01821, USA
 Tel: +1 (978)288-8175
 E-mail: khchan@nortelnetworks.com"
 " Andrew Smith
 Postal: 3585 Monroe St.
 Santa Clara, California 95051
 Tel: +1 (408) 579 2821
 FAX: +1 (408) 579 3000
 E-mail: andrew@extremenetworks.com"
 DESCRIPTION
 "This MIB defines the objects necessary to manage a
 device that uses the Differentiated Services
 Architecture described in RFC 2475."
 REVISION "9907190100Z" -- Mon Jul 19 01:00:00 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 }
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 11]

 Draft Differentiated Services MIB October 1999
 
 
 diffServMIBConformance OBJECT IDENTIFIER ::= { diffServMib 3 }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 12]

 Draft Differentiated Services MIB October 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 not actually
 configured or changed."
 ::= { diffServAggregateEntry 1 }
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 13]

 Draft Differentiated Services MIB October 1999
 
 
 -- The tools for MultiField Classification.
 --
 -- This textual convention has no effect on either the syntax
 -- nor the semantics of any managed object. Objects defined
 -- using this convention are always encoded by means of the
 -- rules that define their primitive type.
 --
 MFClassifierL4Port ::= TEXTUAL-CONVENTION
 DISPLAY-HINT "d"
 STATUS current
 DESCRIPTION
 "A value indicating a Layer-4 protocol port number."
 SYNTAX INTEGER (0..65535)
 
 -- This object allows a configuring system to obtain a
 -- unique value for diffServClassifierNumber for purposes of
 -- configuration.
 
 diffServMFClassifierUnique OBJECT-TYPE
 SYNTAX TestAndIncr
 MAX-ACCESS read-write
 STATUS current
 DESCRIPTION
 "The diffServMFClassifierUnique object yields a
 unique new value for diffServMFClassifierIndex when read and
 subsequently set. This value must be tested for
 uniqueness."
 ::= { diffServObjects 1 }
 
 diffServMFClassifierTable OBJECT-TYPE
 SYNTAX SEQUENCE OF diffServMFClassifierEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "A table of MF (IP 6-tuple multi-field) classifier
 entries that a system may use to identify traffic."
 ::= { diffServTables 2 }
 
 diffServMFClassifierEntry OBJECT-TYPE
 SYNTAX DiffServMFClassifierEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "A multi-field classifier entry describes a single MF
 classifier."
 INDEX { diffServMFClassifierIndex }
 ::= { diffServMFClassifierTable 1 }
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 14]

 Draft Differentiated Services MIB October 1999
 
 
 DiffServMFClassifierEntry ::= SEQUENCE {
 diffServMFClassifierIndex INTEGER,
 diffServMFClassifierAddrType InetEndpointType,
 diffServMFClassifierDstAddr InetEndpoint,
 diffServMFClassifierDstAddrMask InetEndpoint,
 diffServMFClassifierSrcAddr InetEndpoint,
 diffServMFClassifierSrcAddrMask InetEndpoint,
 diffServMFClassifierDscp INTEGER,
 diffServMFClassifierProtocol INTEGER,
 diffServMFClassifierDstL4PortMin MFClassifierL4Port,
 diffServMFClassifierDstL4PortMax MFClassifierL4Port,
 diffServMFClassifierSrcL4PortMin MFClassifierL4Port,
 diffServMFClassifierSrcL4PortMax MFClassifierL4Port,
 diffServMFClassifierStatus RowStatus
 }
 
 diffServMFClassifierIndex OBJECT-TYPE
 SYNTAX INTEGER (1..2147483647)
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "This is a unique index for the classifier. This object
 is meant to be pointed to by a RowPointer from other
 tables, such as the diffServClassifierMatchObject."
 ::= { diffServMFClassifierEntry 1 }
 
 diffServMFClassifierAddrType OBJECT-TYPE
 SYNTAX InetEndpointType
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The type of IP address used by this classifier entry."
 ::= { diffServMFClassifierEntry 2 }
 
 diffServMFClassifierDstAddr OBJECT-TYPE
 SYNTAX InetEndpoint
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The IP address to match against the packet's
 destination IP address."
 ::= { diffServMFClassifierEntry 3 }
 
 diffServMFClassifierDstAddrMask OBJECT-TYPE
 SYNTAX InetEndpoint
 MAX-ACCESS read-create
 STATUS current
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 15]

 Draft Differentiated Services MIB October 1999
 
 
 DESCRIPTION
 "A mask for the matching of the destination IP address.
 A zero bit in the mask means that the corresponding bit
 in the address always matches."
 ::= { diffServMFClassifierEntry 4 }
 
 diffServMFClassifierSrcAddr OBJECT-TYPE
 SYNTAX InetEndpoint
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The IP address to match against the source IP address
 of each packet."
 ::= { diffServMFClassifierEntry 5 }
 
 diffServMFClassifierSrcAddrMask OBJECT-TYPE
 SYNTAX InetEndpoint
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "A mask for the matching of the source IP address."
 ::= { diffServMFClassifierEntry 6 }
 
 diffServMFClassifierDscp OBJECT-TYPE
 SYNTAX INTEGER (-1 | 0..63)
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The value that the DSCP in the packet must have to
 match this entry. A value of -1 indicates that a
 specific DSCP value has not been defined and thus all
 DSCP values are considered a match."
 ::= { diffServMFClassifierEntry 7 }
 
 diffServMFClassifierProtocol OBJECT-TYPE
 SYNTAX INTEGER (0..255)
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The IP protocol to match against the IPv4 protocol
 number in the packet. A value of zero means match all."
 ::= { diffServMFClassifierEntry 8 }
 
 diffServMFClassifierDstL4PortMin OBJECT-TYPE
 SYNTAX MFClassifierL4Port
 MAX-ACCESS read-create
 STATUS current
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 16]

 Draft Differentiated Services MIB October 1999
 
 
 DESCRIPTION
 "The minimum value that the layer-4 destination port
 number in the packet must have in order to match this
 classifier entry."
 ::= { diffServMFClassifierEntry 9 }
 
 diffServMFClassifierDstL4PortMax OBJECT-TYPE
 SYNTAX MFClassifierL4Port
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The maximum value that the layer-4 destination port
 number in the packet must have in order to match this
 classifier entry. This value must be equal to or
 greater that the value specified for this entry in
 diffServMFClassifierDstL4PortMin."
 ::= { diffServMFClassifierEntry 10 }
 
 diffServMFClassifierSrcL4PortMin OBJECT-TYPE
 SYNTAX MFClassifierL4Port
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The minimum value that the layer-4 source port number
 in the packet must have in order to match this
 classifier entry."
 ::= { diffServMFClassifierEntry 11 }
 
 diffServMFClassifierSrcL4PortMax OBJECT-TYPE
 SYNTAX MFClassifierL4Port
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The maximum value that the layer-4 source port number
 in the packet must have in oder to match this
 classifier entry. This value must be equal to or
 greater that the value specified for this entry in
 dsSixTupleIpSrcL4PortMin."
 ::= { diffServMFClassifierEntry 12 }
 
 diffServMFClassifierStatus OBJECT-TYPE
 SYNTAX RowStatus
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "This indicates the status of this classifier entry."
 ::= { diffServMFClassifierEntry 13 }
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 17]

 Draft Differentiated Services MIB October 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 2 }
 
 -- 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 3 }
 
 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, etc Expiration: April 2000 [Page 18]

 Draft Differentiated Services MIB October 1999
 
 
 diffServClassifierNext RowPointer,
 diffServClassifierSequence Unsigned32,
 diffServClassifierConfigType INTEGER,
 diffServClassifierConfigTypeInfo OCTET STRING,
 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 }
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 19]

 Draft Differentiated Services MIB October 1999
 
 
 diffServClassifierNext OBJECT-TYPE
 SYNTAX RowPointer
 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 }
 
 diffServClassifierConfigType OBJECT-TYPE
 SYNTAX INTEGER {
 OTHER (0),
 MIB (1), -- Configured via MIB
 PIB (2), -- Configured via PIB
 BGP (3) -- Configured via BGP
 }
 MAX-ACCESS read-write
 STATUS current
 DESCRIPTION
 "Used to indicate how the classifer is configured."
 ::= { diffServClassifierEntry 6 }
 
 diffServClassifierConfigTypeInfo OBJECT-TYPE
 SYNTAX OCTET STRING
 MAX-ACCESS read-write
 STATUS current
 DESCRIPTION
 "Additional information associated with how the
 classifier is configured."
 ::= { diffServClassifierEntry 7 }
 
 diffServClassifierStatus OBJECT-TYPE
 SYNTAX RowStatus
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 20]

 Draft Differentiated Services MIB October 1999
 
 
 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 8 }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 21]

 Draft Differentiated Services MIB October 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 3 }
 
 -- 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 4 }
 
 diffServTBMeterEntry OBJECT-TYPE
 SYNTAX DiffServTBMeterEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "An entry in the meter table describes a single token
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 22]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 23]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 24]

 Draft Differentiated Services MIB October 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 4 }
 
 -- 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 5 }
 
 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, etc Expiration: April 2000 [Page 25]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 26]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 27]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 28]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 29]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 30]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 31]

 Draft Differentiated Services MIB October 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 5 }
 
 -- 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 6 }
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 32]

 Draft Differentiated Services MIB October 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,
 diffServQueueOccupancyWeight Unsigned32,
 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
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 33]

 Draft Differentiated Services MIB October 1999
 
 
 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
 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 }
 
 diffServQueueOccupancyWeight OBJECT-TYPE
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 34]

 Draft Differentiated Services MIB October 1999
 
 
 SYNTAX Unsigned32
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The amount, in the form of a factor, that the current,
 actual queue occupancy should influence the averaged
 queue occupancy. The averaged queue occupancy can be
 used for comparison to configured drop thresholds in
 RED or RED-like dropper implementations. Larger the
 weight, the greater the instantaneous queue occupancy
 influences the averaged queue occupancy. Usually,
 dramatic changes in the instantaneous queue occupancy
 is the result of bursty input streams. Notice this
 numeric attribute is divided by 10,000 to get the
 effective fractional factor used in the actual
 calculations."
 ::= { diffServQueueEntry 6 }
 
 diffServQueueStatus OBJECT-TYPE
 SYNTAX RowStatus
 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 7 }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 35]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 36]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 37]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 38]

 Draft Differentiated Services MIB October 1999
 
 
 DESCRIPTION
 "Write access is not required."
 
 OBJECT diffServQueueStatus
 MIN-ACCESS read-only
 DESCRIPTION
 "Write access is not required."
 ::= { diffServMIBCompliances 1 }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 39]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 40]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 41]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 42]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 43]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 44]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 45]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 46]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 47]

 Draft Differentiated Services MIB October 1999
 
 
 and queues."
 ::= { diffServMIBGroups 7 }
 END
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 48]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 49]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 50]

 Draft Differentiated Services MIB October 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, etc Expiration: April 2000 [Page 51]

 Draft Differentiated Services MIB October 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. Authors' Addresses:
 
 Fred Baker
 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
 Extreme Networks
 3585 Monroe Street
 Santa Clara, CA 95051
 USA
 andrew@extremenetworks.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fred Baker, etc Expiration: April 2000 [Page 52]
 

AltStyle によって変換されたページ (->オリジナル) /