Network Working Group                                           F. Baker
Request for Comments: 3289                                  Cisco System
Category: Standards Track                                        K. Chan
                                                         Nortel Networks
                                                                A. Smith
                                                        Harbour Networks
                                                                May 2002


                  Management Information Base for the
                  Differentiated Services Architecture

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo describes an SMIv2 (Structure of Management Information
   version 2) MIB for a device implementing the Differentiated Services
   Architecture.  It may be used both for monitoring and configuration
   of a router or switch capable of Differentiated Services
   functionality.

Table of Contents

   1 The SNMP Management Framework .................................   3
   2 Relationship to other working group documents .................   4
   2.1  Relationship to the Informal Management Model for
        Differentiated Services Router .............................   4
   2.2 Relationship to other MIBs and Policy Management ............   5
   3 MIB Overview ..................................................   6
   3.1 Processing Path .............................................   7
   3.1.1 diffServDataPathTable - The Data Path Table ...............   7
   3.2 Classifier ..................................................   7
   3.2.1 diffServClfrElementTable - The Classifier Element Table ...   8
   3.2.2 diffServMultiFieldClfrTable - The Multi-field Classifier
        Table ......................................................   9
   3.3 Metering Traffic ............................................  10
   3.3.1 diffServMeterTable - The Meter Table ......................  11

   3.3.2 diffServTBParamTable - The Token Bucket Parameters Table...  11
   3.4 Actions applied to packets ..................................  12
   3.4.1 diffServActionTable - The Action Table ....................  12
   3.4.2 diffServCountActTable - The Count Action Table ............  12
   3.4.3 diffServDscpMarkActTable - The Mark Action Table ..........  13
   3.4.4 diffServAlgDropTable - The Algorithmic Drop Table .........  13
   3.4.5 diffServRandomDropTable - The Random Drop Parameters Table   14
   3.5 Queuing and Scheduling of Packets ...........................  16
   3.5.1 diffServQTable - The Class or Queue Table .................  16
   3.5.2 diffServSchedulerTable - The Scheduler Table ..............  16
   3.5.3 diffServMinRateTable - The Minimum Rate Table .............  16
   3.5.4 diffServMaxRateTable - The Maximum Rate Table .............  17
   3.5.5 Using queues and schedulers together ......................  17
   3.6 Example configuration for AF and EF .........................  20
   3.6.1 AF and EF Ingress Interface Configuration .................  20
   3.6.1.1 Classification In The Example ...........................  22
   3.6.1.2 AF Implementation On an Ingress Edge Interface ..........  22
   3.6.1.2.1 AF Metering On an Ingress Edge Interface ..............  22
   3.6.1.2.2 AF Actions On an Ingress Edge Interface ...............  23
   3.6.1.3 EF Implementation On an Ingress Edge Interface ..........  23
   3.6.1.3.1 EF Metering On an Ingress Edge Interface ..............  23
   3.6.1.3.2 EF Actions On an Ingress Edge Interface ...............  23
   3.7 AF and EF Egress Edge Interface Configuration ...............  24
   3.7.1 Classification On an Egress Edge Interface ................  24
   3.7.2 AF Implementation On an Egress Edge Interface .............  26
   3.7.2.1 AF Metering On an Egress Edge Interface .................  26
   3.7.2.2 AF Actions On an Egress Edge Interface ..................  29
   3.7.2.3 AF Rate-based Queuing On an Egress Edge Interface .......  30
   3.7.3 EF Implementation On an Egress Edge Interface .............  30
   3.7.3.1 EF Metering On an Egress Edge Interface .................  30
   3.7.3.2 EF Actions On an Egress Edge Interface ..................  30
   3.7.3.3 EF Priority Queuing On an Egress Edge Interface .........  32
   4 Conventions used in this MIB ..................................  33
   4.1 The use of RowPointer to indicate data path linkage .........  33
   4.2 The use of RowPointer to indicate parameters ................  34
   4.3 Conceptual row creation and deletion ........................  34
   5 Extending this MIB ............................................  35
   6 MIB Definition ................................................  35
   7 Acknowledgments ............................................... 110
   8 Security Considerations ....................................... 110
   9 Intellectual Property Rights .................................. 111
   10 References ................................................... 112
   11 Authors' Addresses ........................................... 115
   12 Full Copyright Statement ..................................... 116

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

      o  An overall architecture, described in [RFC 2571].

      o  Mechanisms for describing and naming objects and events for the
         purpose of management.  The first version of this Structure of
         Management Information (SMI) is called SMIv1 and is described
         in [RFC 1155], [RFC 1212] and [RFC 1215].  The second version,
         called SMIv2, is described in [RFC 2578], RFC 2579 [RFC 2579]
         and [RFC 2580].

      o  Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         is described in [RFC 1157].  A second version of the SNMP
         message protocol, which is not an Internet standards track
         protocol, is called SNMPv2c and is described in [RFC 1901] and
         [RFC 1906].  The third version of the message protocol is
         called SNMPv3 and is described in [RFC 1906], [RFC 2572] and
         [RFC 2574].

      o  Protocol operations for accessing management information.  The
         first set of protocol operations and associated PDU formats is
         described in [RFC 1157].  A second set of protocol operations
         and associated PDU formats is described in [RFC 1905].

      o  A set of fundamental applications described in [RFC 2573] and
         the view-based access control mechanism described in [RFC
         2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in [RFC 2570].

   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 there
   is 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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2.  Relationship to other working group documents

   The Differentiated Services Working Group and related working groups
   developed other documents, notably the Informal Management Model and
   the policy configuration paradigm of SNMPCONF.  The relationship
   between the MIB and those documents is clarified here.

2.1.  Relationship to the Informal Management Model for Differentiated
      Services Router

   This MIB is similar in design to [MODEL], although it can be used to
   build functional data paths that the model would not well describe.
   The model conceptually describes ingress and egress interfaces of an
   n-port router, which may find some interfaces at a network edge and
   others facing into the network core.  It describes the configuration
   and management of a Differentiated Services interface in terms of one
   or more Traffic Conditioning Blocks (TCB), each containing, arranged
   in the specified order, by definition, zero or more classifiers,
   meters, actions, algorithmic droppers, queues and schedulers.
   Traffic may be classified, and classified traffic may be metered.
   Each stream of traffic identified by a combination of classifiers and
   meters may have some set of actions performed on it; it may have
   dropping algorithms applied and it may ultimately be stored into a
   queue before being scheduled out to its next destination, either onto
   a link or to another TCB.  At times, the treatment for a given packet
   must have any of those elements repeated.  [MODEL] models this by
   cascading multiple TCBs, while this MIB describes the policy by
   directly linking the functional data path elements.

   The MIB represents this cascade by following the "Next" attributes of
   the various elements.  They indicate what the next step in
   Differentiated Services processing will be, whether it be a
   classifier, meter, action, algorithmic dropper, queue, scheduler or a
   decision to now forward a packet.

   The higher level concept of a TCB is not required in the
   parameterization or in the linking together of the individual
   elements, hence it is not used in the MIB itself and is only
   mentioned in the text for relating the MIB with the [MODEL].  Rather,
   the MIB models the individual elements that make up the TCBs.

   This MIB uses the notion of a Data Path to indicate the
   Differentiated Services processing a packet may experience.  The Data
   Path a packet will initially follow is an attribute of the interface

   in question.  The Data Path Table provides a starting point for each
   direction (ingress or egress) on each interface.  A Data Path Table
   Entry indicates the first of possible multiple elements that will
   apply Differentiated Services treatment to the packet.

2.2.  Relationship to other MIBs and Policy Management

   This MIB provides for direct reporting and manipulation of detailed
   functional elements.  These elements consist of a structural element
   and one or more parameter-bearing elements.  While this can be
   cumbersome, it allows the reuse of parameters.  For example, a
   service provider may offer three varieties of contracts, and
   configure three parameter elements.  Each such data path on the
   system may then refer to these sets of parameters.  The
   diffServDataPathTable couples each direction on each interface with
   the specified data path linkage.  The concept of "interface" is as
   defined by InterfaceIndex/ifIndex of the IETF Interfaces MIB [IF-
   MIB].

   Other MIBs and data structure definitions for policy management
   mechanisms, other than SNMP/SMIv2 are likely to exist in the future
   for the purpose of abstracting the model in other ways.  An example
   is the Differentiated Services Policy Information Base, [DSPIB].

   In particular, abstractions in the direction of less detailed
   definitions of Differentiated Services functionality are likely e.g.
   some form of "Per-Hop Behavior"-based definition involving a template
   of detailed object values which is applied to specific instances of
   objects in this MIB semi-automatically.

   Another possible direction of abstraction is one using a concept of
   "roles" (often, but not always, applied to interfaces).  In this
   case, it may be possible to re-use the object definitions in this
   MIB, especially the parameterization tables.  The Data Path table
   will help in the reuse of the data path linkage tables by having the
   interface specific information centralized, allowing easier
   mechanical replacement of ifIndex by some sort of "roleIndex".  This
   work is ongoing.

   The reuse of parameter blocks on a variety of functional data paths
   is intended to simplify network management.  In many cases, one could
   also re-use the structural elements as well; this has the unfortunate
   side-effect of re-using the counters, so that monitoring information
   is lost.  For this reason, the re-use of structural elements is not
   generally recommended.