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-00.txt

			  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

	  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.

	  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 five six elements:
	  - Behavior Aggregate Classification Table
	  - Multi-Field	Classification Table

	  Draft		   Differentiated Services MIB	    October 1999

	  - Classifier Table
	  - 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, 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.

	  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

	  Two forms of thresholds, classifiers are Behavior	Aggregate (BA) 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
	  Multi-Field (MF) Classifiers.	 These classifiers are specified
	  here at the
	  stream appears to per interface level,  they can be within the meter's limit	rate. In the
	  MIB,	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 structure diffServClassifierConfigType	attribute of	SNMP makes it easiest the
	  diffServClassifierEntry object.  The attribute

	  Draft		   Differentiated Services MIB	    October 1999

	  diffServClassifierConfigTypeInfo can be used to implement this
	  as a set of one or more simple pass/fail tests, 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	are
	  cascaded. It	the classifier is to be	understood derived.  With BGP ConfigType, the
	  ConfigTypeInfo can hold the BGP Community String that
	  identifies the meter in a Traffic
	  Control Block BGP Routing Policy from which the classifier is therefore implemented as a set of if-then-
	  else constructs.

	  The result
	  derived.  With the use of	metering traffic higher level policies, the
	  classifier table is always some	action.

	  The concept of conformance to	a meter	bears a	comment. used primarily for monitoring purpose, but
	  this does not	exclude	its use	for configuration purpose.

	  3.2.1.  Behavior Aggregate Classification Table

	  The
	  concept applied in Behavior Aggregate Classification	Table is present for
	  several rate-control architectures,
	  including ATM, Frame Relay, Integrated Services, reasons. First, the DSCP must	be identified somewhere
	  for identifying tagged streams of traffic. This could	be done
	  in-line, and
	  Differentiated Services, is variously	described as a "leaky
	  bucket" or not.

	  The reason the BA Classifier is pulled out into a "token bucket".

	  A leaky bucket algorithm separate
	  table	is primarily	used for traffic
	  shaping: traffic theoretically departs from that	we envisage the switch at a
	  flat rate	use of one bit every so	many time units, and other tables for	other
	  kinds	of classifiers,	public or proprietary. For example, the
	  typical "five-tuple" used in	fact
	  departs per-flow	classification (as in packets at
	  RSVP)	might be represented by	a rate approximating that. It is also
	  possible to build multi-rate leaky buckets, in which traffic
	  departs from table	whose objects include
	  the switch at varying rates depending on	recent
	  activity or inactivity.

	  A token bucket is used to measure necessary	IP Addresses, 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 IP protocol, the necessary
	  TCP/UDP port numbers,	and a mean rate, and	sometimes more
	  rates) are commonly used. In this case, RowStatus	variable. By pulling the burst size for
	  classifier itself into a table that can be referenced	via a
	  RowPointer, we enable	the
	  baseline traffic is conventionally referred use	of any sort of classification
	  table	that one might wish to as the
	  "committed burst", and the time interval design. That classifier table
	  need not be found in this MIB. When ambiguity	is as specified present, we
	  disambiguate 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 explicitly ordering the
	  sum application of
	  classification rules.

	  3.2.2.  Multi-Field Classification Table

	  In the burst sizes per interval.

	  A data stream	is said	to "conform" to	a simple token bucket if same spirit as	the switch receives at most BA Classification Table, the burst	size Multi-
	  Field	Classification Table is	in a given	time
	  interval. In separate table that can be
	  referenced via a RowPointer, namely
	  diffServClassifierMatchObject	attribute of
	  diffServClassifierEntry object.  Each	entry in the multi-rate case, MF
	  Classification Table defines a MF Classifier.	 With the	traffic use of
	  InetEndpoint for both	IPv4 and IPv6 addressing.  The use of MF
	  Classifiers is said	to
	  conform discussed in [DSARCH] and abstract examples of
	  how they might be configured are provided in [DSMODEL].

	  Draft		   Differentiated Services MIB	    October 1999

	  3.3.	Meter Table

	  A meter, according to	the token bucket conceptual model, measures the rate
	  at which a given level if its rate does
	  not exceed the sum stream of	the relevant burst sizes in a given
	  interval. Received traffic pre-classified at one passes it, compares it to some
	  set of the
	  "excess" rates (e.g.,	AF12 thresholds, and produces some number (two or	AF13 traffic) more)
	  potential results. A given message is only compared	said to	"conform" to the relevant excess buckets.

	  The fact
	  meter	if at the time that	data the	message	is	organized into variable	length packets
	  introduces some uncertainty in this. For this	reason, being looked	at the
	  token	bucket accepts
	  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 packet	if any set of its bits would have
	  been accepted, and "borrows" any excess capacity required from
	  that allotted one or more simple pass/fail tests, which	are
	  cascaded. It is to equivalently	classified traffic be	understood that	the meter in a
	  subsequent interval. More information	about this Traffic
	  Control Block	is available
	  in [Model].

	  Multiple classes of traffic, therefore implemented 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 a set of if-then-
	  else constructs.

	  The result of	metering 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 always some PHBs require the successive application of
	  an arbitrary number of meters.	action.

	  The approach taken in	this
	  design is concept of conformance to have each	a meter indicate	what action is to be
	  taken	for conforming traffic,	bears a	comment. The
	  concept applied in several rate-control architectures,
	  including ATM, Frame Relay, Integrated Services, and what meter
	  Differentiated Services, is to be variously	described as a "leaky
	  bucket" or a "token bucket".

	  A leaky bucket algorithm is primarily	used for traffic which	fails to conform. With
	  shaping: traffic theoretically departs from the definition of switch at a
	  special type
	  flat rate of meter 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 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
	  departs from the traffic, randomly switch at varying rates depending on	recent
	  activity or all of it", and
	  "shape inactivity.

	  A token bucket is used to measure 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	behavior of objects are defined a peer's
	  leaky	bucket,	for verification purposes. It is, by definition,
	  a relationship

			    interval = burst/rate, or
			      rate = burst/interval

	  for some counters. These are defined burst size, in accordance	with the method	found bits,	rate, 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
	  second, 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 time interval. Multi-rate	token buckets (token
	  buckets with both a meter peak and not	dropped	is presented to a queue for further processing.

	  3.6.	Queue Table mean rate, and	sometimes more
	  rates) are commonly used. In this version of case, the MIB, a	relatively simple FIFO queue burst size for the
	  baseline traffic is
	  envisaged within conventionally referred to as the Traffic Control Block. Scheduling among
	  TCBs
	  "committed burst", and the time interval is done as specified 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

		       interval	= committed burst/mean rate

	  Draft		   Differentiated Services MIB	    October 1999

	  but additional burst sizes (each an increment	over	lower
	  numbered priorities its
	  predecessor) are defined, which are conventionally referred to
	  as "excess" burst sizes.  The	peak rate therefore equals the
	  sum of queue sets. Each queue the burst sizes per interval.

	  A data stream	is capable of
	  acting as said	to "conform" to	a work-conserving queue (one which transmits as
	  rapidly as its weight	allows,	but guarantees 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 class rate does
	  not exceed the sum of
	  traffic, as	the relevant burst sizes in a	side-effect given
	  interval. Received traffic pre-classified at one of its weight, a minimum rate), the
	  "excess" rates (e.g.,	AF12 or
	  as	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 non-work-conserving or "shaping"	queue. Queue sets and
	  more complex queue types - which are common packet	if any of its bits would have
	  been accepted, and "borrows" any excess capacity required from
	  that allotted	to
	  correctly implement Differentiated Services, are modeled as
	  several of these FIFO	queues. equivalently	classified traffic in a
	  subsequent interval. More information	about this is available
	  in [Model].

	  Multiple meters classes of traffic, as identified by	the classifier
	  table, may direct their traffic be	presented to the same queue.
	  For meter. Imagine, for
	  example, the Assured Forwarding PHB suggests that	we desire to drop all traffic marked AF11, AF12, or	AF13 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	placed 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 same queue
	  without reordering.

	  Some 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 elapsed concerning taken place regarding the structure of	possible
	  actions.  Suggested actions include "no action", "mark the
	  queue	in question,
	  traffic", "drop the traffic, randomly	or all of it", and its functions.	It is expected
	  "shape the traffic." In this MIB, three actions are

	  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
	  description 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 queuing system will grow during working
	  group	discussion. This 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 area where vendors differ
	  markedly inter- face
	  is specified.	 When all the queues in their architectures.

	  3.7.	The	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

	  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"

	  Draft		   Differentiated Services MIB	    October 1999

	  RowPointer might take	you to another meter, while the
	  "SucceedNext"	RowPointer would take you to an	action.

	  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 }

	  Draft		   Differentiated Services MIB	    October 1999

	  diffServMIBConformance OBJECT	IDENTIFIER ::= { diffServMib 3 }

	  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 }

	  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 RowPointer

	  RowPointer is MF	(IP 6-tuple multi-field) classifier
		 entries that a textual convention used	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
	  conceptual row in an SNMP Table by pointing to one of	its
	  objects. In this MIB,	it single MF
		 classifier."
	      INDEX { diffServMFClassifierIndex	}
	      ::= { diffServMFClassifierTable 1	}

	  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 used in two ways:	to indicate
	  indirection, and to indicate succession.

	  When used a unique index for	indirection, as	in the Classifier table, the
	  idea classifier. This object
		 is meant to allow other MIBs, including proprietary ones, be	pointed	to
	  identify new and arcane classifiers -	MAC headers, IP4 and IP6
	  headers, BGP Communities, and	all sorts 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 things.

	  When 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

	  Draft		   Differentiated Services MIB	    October 1999

	      DESCRIPTION
		 "A mask for	succession, it answers the question "what
	  happens next?".  Rather than presume that matching of the	next table must
	  be as	specified destination IP	address.
		 A zero	bit in the conceptual model and providing	its
	  index, mask	means that the RowPointer	takes you 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 MIB row representing
	  that thing. In the Meter Table, source IP	address
		 of each packet."
	      ::= { diffServMFClassifierEntry 5	}

	  diffServMFClassifierSrcAddrMask OBJECT-TYPE
	      SYNTAX	     InetEndpoint
	      MAX-ACCESS     read-create
	      STATUS	     current
	      DESCRIPTION
		 "A mask for example, the "FailNext"
	  RowPointer might take	you to another meter, while matching of the
	  "SucceedNext"	RowPointer would take you to an	action.

	  4.  MIB Definition

	  DIFF-SERV-MIB	DEFINITIONS source	IP address."
	      ::=	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" { diffServMFClassifierEntry 6	}

	  diffServMFClassifierDscp OBJECT-TYPE
	      SYNTAX	     INTEGER (-1 | 0..63)
	      MAX-ACCESS     read-create
	      STATUS	     current
	      DESCRIPTION
		 "This MIB defines the objects necessary to manage a
		 device
		 "The value that uses the Differentiated Services
		 Architecture described DSCP in RFC 2475."
	      REVISION "9907150732Z" --	Thu Jul 15 07:32:36 PDT 1999
	      DESCRIPTION
		 "Initial version, published as	RFC xxxx." 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."
	      ::= { mib-2 12345 diffServMFClassifierEntry 7	}  -- anybody who uses this
				   -- unassigned

	  diffServMFClassifierProtocol OBJECT-TYPE
	      SYNTAX	     INTEGER (0..255)
	      MAX-ACCESS     read-create
	      STATUS	     current
	      DESCRIPTION
		 "The IP protocol to match against the IPv4 protocol
		 number
				   -- deserves	in the wrath packet. A value of IANA

	  diffServObjects OBJECT IDENTIFIER ::=	{ diffServMib 1	}
	  diffServTables OBJECT	IDENTIFIER zero means match all."
	      ::= { diffServMib 2 diffServMFClassifierEntry 8	}
	  diffServMIBConformance OBJECT	IDENTIFIER

	  diffServMFClassifierDstL4PortMin OBJECT-TYPE
	      SYNTAX	     MFClassifierL4Port
	      MAX-ACCESS     read-create
	      STATUS	     current

	  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."
	      ::= { diffServMib 3 diffServMFClassifierEntry 9	}
	  -- The tools necessary to perform basic Behavior
	  -- Aggregate Classification
	  --
	  Dscp ::= TEXTUAL-CONVENTION
	      DISPLAY-HINT "d"

	  diffServMFClassifierDstL4PortMax OBJECT-TYPE
	      SYNTAX	     MFClassifierL4Port
	      MAX-ACCESS     read-create
	      STATUS	     current
	      DESCRIPTION
		 "The code point used 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 discriminating a traffic
		 stream."
	      SYNTAX   INTEGER (0..63)

	  diffServAggregateTable this entry in
		 diffServMFClassifierDstL4PortMin."
	      ::= { diffServMFClassifierEntry 10 }

	  diffServMFClassifierSrcL4PortMin OBJECT-TYPE
	      SYNTAX	   SEQUENCE OF DiffServAggregateEntry	     MFClassifierL4Port
	      MAX-ACCESS   not-accessible     read-create
	      STATUS	     current
	      DESCRIPTION
		 "The 'Aggregate' Table	enumerates Behavior Aggregate
		 classifiers (DSCPs) minimum value that a system may identify	traffic
		 using." the layer-4 source port number
		 in the	packet must have in order to match this
		 classifier entry."
	      ::= { diffServTables 1 diffServMFClassifierEntry 11 }

	  diffServAggregateEntry

	  diffServMFClassifierSrcL4PortMax OBJECT-TYPE
	      SYNTAX	   DiffServAggregateEntry	     MFClassifierL4Port
	      MAX-ACCESS   not-accessible     read-create
	      STATUS	     current
	      DESCRIPTION
		 "An 'aggregate'
		 "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 describes a single BA
		 classifier."
	      INDEX { diffServAggregateDSCP }
	      ::= { diffServAggregateTable 1 }

	  DiffServAggregateEntry in
		 dsSixTupleIpSrcL4PortMin."
	      ::= SEQUENCE {
	      diffServAggregateDSCP	    Dscp diffServMFClassifierEntry 12 }

	  diffServAggregateDSCP

	  diffServMFClassifierStatus OBJECT-TYPE
	      SYNTAX	   Dscp	  RowStatus
	      MAX-ACCESS   read-only  read-create
	      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 indicates the diffServClassifierMatchObject, and	is no actually
		 configured or changed." status of this classifier entry."
	      ::= { diffServAggregateEntry 1 diffServMFClassifierEntry 13 }

	  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 1 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 2 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,

	  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 }

	  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
		 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 taken."
	      DEFVAL	configured."
	      ::= { 0 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 5 7 }

	  diffServClassifierStatus OBJECT-TYPE
	      SYNTAX	   RowStatus

	  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 6 8 }

	  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 2 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 3 4 }

	  diffServTBMeterEntry OBJECT-TYPE
	      SYNTAX	   DiffServTBMeterEntry
	      MAX-ACCESS   not-accessible
	      STATUS	   current
	      DESCRIPTION
		 "An entry in the meter	table describes	a single token

	  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.

	  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 }

	  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 3 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 4 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  {

	  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

	  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

	  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

	  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 }

	  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

	  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 }

	  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 4 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 5 6 }

	  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

	  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

	  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 6 7 }

	  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

	  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."

	  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

	  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 }

	  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

	  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."

	  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 }

	  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

	  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."

	  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 }

	  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

	  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,

	  Draft		   Differentiated Services MIB	    October 1999

		 and queues."
	      ::= { diffServMIBGroups 7	}
	  END

	  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.

	  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
	  [3]  Rose, M., and K.	McCloghrie, "Concise MIB Definitions",
	       RFC 1212, STD 16, Performance Systems International,
	  [4]  M. Rose,	"A Convention for Defining Traps for use with
	       the SNMP", RFC 1215, Performance	Systems	International,
	  [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,
	  [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,
	  [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

	  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,
	  [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,
	  [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
	  [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,
	  [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.

	  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.  Author's	Address:  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