Internet Draft 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]