RFC 3747

The Differentiated Services Configuration MIB

📅 published April 2004, from ietf

RFC 3747: The Differentiated Services Configuration MIB ✨🎀

Title block tea 🫖💖 Here's who made this and what it's about, bestie:

  • Network Working Group 🌸 Authors: H. Hazewinkel, Ed. (I.Net) and D. Partain, Ed. (Ericsson)
  • Category: Standards Track 👑
  • Date: April 2004 📅
  • Obsoletes / Updates: this header doesn't list anything it obsoletes or updates 🦋

Status of This Memo 💅

okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Also, distribution of this memo is unlimited, so go share it 💜

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

Abstract 🧚

okay this memo describes a MIB module that acts as a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem, and the instance-specific information. That instance-specific stuff includes details like the parameters for all the queues associated with each interface in a system ✨ Basically it gives you a way to configure differentiated services at a conceptually higher layer than the Differentiated Services MIB does 🔥

Table of Contents 🍓

1.  The Internet-Standard Management Framework . . . . . . . . . .  2
2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.  Other Documents. . . . . . . . . . . . . . . . . . . . . . . .  3
4.  Relationship to other MIBs . . . . . . . . . . . . . . . . . .  3
    4.1.  The Policy-based Management MIB Module . . . . . . . . .  3
    4.2.  The Differentiated Services MIB Module . . . . . . . . .  4
5.  The Differentiated Services Configuration MIB Module Design. .  5
6.  Template Cloning . . . . . . . . . . . . . . . . . . . . . . .  6
    6.1.  An Approach to Template Cloning. . . . . . . . . . . . .  6
    6.2.  Example. . . . . . . . . . . . . . . . . . . . . . . . .  7
          6.2.1.  The Initial Situation. . . . . . . . . . . . . .  8
          6.2.2.  The Configuration Template . . . . . . . . . . .  9
          6.2.3.  Applying the Template. . . . . . . . . . . . . . 11
          6.2.4.  Applying the Template Using SNMP Messages. . . . 14
7.  Managed Objects Definitions (MIB Module) . . . . . . . . . . . 15
8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 20
9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
    10.1. Normative References . . . . . . . . . . . . . . . . . . 22
    10.2. Informative References . . . . . . . . . . . . . . . . . 23
11. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24

1. The Internet-Standard Management Framework 🎀

for a detailed overview of the docs that describe the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 📖

okay so managed objects are accessed via a virtual information store called the Management Information Base, or MIB 🗂️ MIB objects are generally accessed through the Simple Network Management Protocol (SNMP) 📡 Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI) 🧩 This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 💜

2. Introduction 🦋

this memo defines a MIB module that can be used to convey management information about desired network-wide Differentiated Services based policy behavior 🌸 It's designed to integrate with the Differentiated Services MIB module [RFC3289] so it can provide template configurations for that module 🫶 The MIB module defined in this memo (the DIFFSERV-CONFIG-MIB) may be used in combination with the Policy-based Management MIB module [PMMIBDR], but that is not a requirement 🙈 Without the Policy-based Management MIB module, a management application has to emulate the behavior that module provides, using equivalent "low-level" SNMP operations in normal manager/agent communication 🛠️

Together, this memo, [RFC3289], and [PMMIBDR] represent an instance of an integrated architecture for both device-specific and network-wide policy (configuration) management 👑 It's fully integrated with the Internet Standard Management Framework, which is giving main character energy ✨

The Differentiated Services MIB module [RFC3289] operates on a device level 💻 The DIFFSERV-CONFIG-MIB in this memo creates a coherent configuration management view as an umbrella over [RFC3289] 🌂 That means DIFFSERV-CONFIG-MIB provides a conceptual Application Program Interface (API) for configuring the Differentiated Services parameters 🎀 Since the Differentiated Services MIB module can maintain configuration information, the DIFFSERV-CONFIG-MIB configuration API consists only of configuration template information and the start of the so-called functional datapath 🧚

3. Other Documents 📚

it's assumed that you're familiar with Differentiated Services ([RFC2474] and [RFC2475]), the Policy-based Management MIB ([PMMIBDR]), and "Configuring Networks and Devices With SNMP" ([RFC3512]) 🍓 These documents include all of the necessary terminology for understanding this memo 💅 Note though that using the MIB module in this memo does not require [PMMIBDR] 🙈

[RFC3512] also provides an example MIB module, which may help you understand the relationship between DIFFSERV-CONFIG-MIB and the Differentiated Services MIB in [RFC3289] 🦋

4. Relationship to other MIBs 🌈

in this section, we describe how this MIB module relates to other MIB modules 🧩 The overall architecture used for policy configuration management is described in [PMMIBDR] 📖

4.1. The Policy-based Management MIB Module ⭐

[PMMIBDR] defines a MIB module that enables policy-based configuration management of infrastructure using the Internet Standard Management Framework 🔥 The document includes a table for configuring policies to be implemented 📝 It also has tables for storing the roles of elements on a particular device 🎭 plus a table representing the capabilities of a device with respect to policy management 💪 and a table for referencing elements affected by a policy, as well as other infrastructure 🏗️

There is no requirement that [PMMIBDR] be used in conjunction with the MIB module defined in this memo, so you're free either way 🫶

See [PMMIBDR] for a full description of the policy-based configuration framework it provides 💜

4.2. The Differentiated Services MIB Module 💖

The Differentiated Services MIB module [RFC3289] provides a common set of managed objects that are useful for configuring Differentiated Services parameters on a Differentiated Services capable device 🌸 This is what's referred to as instance-level configuration 🧁 Altering the instance-level information in that MIB module can be done using the objects in the MIB module defined in this memo 🎀

vendors may include additional managed objects in their devices (via vendor-specific MIB modules) for configuring Differentiated Services parameters, and that's totally recognized 🤝 If a vendor chooses to use the objects defined in this memo for configuration, the vendor should provide additional managed objects in a similar approach to the one defined for the Differentiated Services MIB module ✨

since the managed objects of the Differentiated Services MIB [RFC3289] aren't directly associated with an instance (an interface and interface direction), the same managed objects can be used for traffic treatment configuration templates in a Differentiated Services capable device, and then applied to multiple instances 🦋 So the tables defined in the Differentiated Services MIB can be used directly for template configuration purposes 🍓 Those tables are:

  • diffServClfrTable
  • diffServClfrElementTable
  • diffServMultiFieldClfrTable
  • diffServMeterTable
  • diffServTBParamTable
  • diffServActionTable
  • diffServDscpMarkActTable
  • diffServCountActTable
  • diffServAlgDropTable
  • diffServRandomDropTable
  • diffServQTable
  • diffServSchedulerTable
  • diffServMinRateTable
  • diffServMaxRateTable

Readers who know the Differentiated Services MIB will notice that these are all templates 👀 Only the diffServDataPathTable defines a managed instance for Differentiated Services traffic treatment, by its indexes of the interface and its direction 🔥 This also means the tables above can be used as a configuration template without defining anything directly related to a managed instance 👑

5. The Differentiated Services Configuration MIB Module Design ✨

Okay bestie, so the Differentiated Services Configuration MIB module (this memo's star 🌟) of the SNMP-based configuration management framework sits right between the Policy-based Management MIB module and the instance-specific Differentiated Services MIB module, just like we covered above 🎀

This MIB module is designed to maintain configuration templates for the Differentiated Services MIB [RFC3289] module. It only has one template table, which describes a Differentiated Services traffic treatment by giving the starting pointer of the functional datapath. The templates basically represent a specific configuration of traffic treatment in a functional datapath of a Differentiated Services capable device 💅

To avoid duplicating managed objects, the actual templates that define the functional datapath live in the Differentiated Services MIB module. Those same templates are also used for managing the instances, so the DIFFSERV-CONFIG-MIB implementation uses the tables defined in the Differentiated Services MIB. As soon as a configuration is made active via the POLICY-MANAGEMENT-MIB or using normal SNMP operations, the configuration defined in this MIB module gets instantiated in the DIFFSERV-MIB 🦋

Note that this is a conceptual process 🧠 That means the configuration may not actually go through an API available in the subsystem that implements the DIFFSERV-MIB module. But configuration via the DIFFSERV-CONFIG-MIB module will alter the same instrumentation as the DIFFSERV-MIB module, whether it does it via the DIFFSERV-MIB module or not. Iconic energy, honestly 😭

The Differentiated Services Configuration MIB module only needs to define a starting point of a traffic treatment configuration template. This table is similar to the diffServDataPathTable [RFC3289], but there's a semantic difference. The diffServDataPathTable is associated with an instance (interface and interface direction), whereas the diffServConfigTable in this memo is not 🙈

Unlike most MIB modules, changes to the managed objects in this MIB module do not cause a change in the external/traffic behavior of the device. This MIB module is used to set up per-hop-behavior configurations. As soon as configurations are made active via the POLICY-MANAGEMENT-MIB or SNMP operations, the configurations defined within this MIB module will be instantiated in the DIFFSERV-MIB 🍓

The only table in this MIB module is the diffServConfigTable, which provides managed objects for registering traffic treatment configurations used in differentiated services. Its sole purpose is to provide the starting point for a traffic treatment configuration template. The traffic treatment itself is performed by functional datapath elements [RFC3289] 👑

6. Template Cloning 🧚

The concept of the DIFFSERV-CONFIG-MIB is based on having traffic treatment configuration templates. The templates provide a set of configuration values that give a particular behavior, such as Expedited Forwarding traffic treatment, in the functional datapath. The template (or functional datapath) is kind of like a linked list from a starting point, and each (functional datapath) element is connected to the next element via the so-called next RowPointer 🔗

The moment a template is activated (instantiated) on an interface and its interface direction, the template needs to be copied/cloned, so that the template stays a template 💖 The template is logically "locked" through the cloning process, which means the template cannot be changed part way through the cloning process. Except for the indices, the cloned template will be identical to the source template ✨

A literal copy/clone of the template is not possible, since the same indices inside the element tables cannot be re-used. The instantiation process must therefore generate a new index for each element. As a result, the 'NEXT' pointers also need to be updated. Otherwise, those will point to the template 🙃

6.1. An Approach to Template Cloning 🎀

What should a system containing Differentiated Services capabilities and Differentiated Services configuration capabilities do conceptually at the moment a template is activated on an interface? Good question, babe 🤔 The following approach should not be considered implementation guidelines. It's more of a conceptual explanation of what should be done.

   1) Get the index of the template to be activated
   2) Get RowPointer (current) from
         diffServConfigStart.index
         of the diffServConfigTable
   3) Check if RowPointer (current) exists
   4) Logically "lock" the entry (current) pointed to by
      RowPointer so that its values are not changed part way
      through the cloning process.
   5) Copy/Clone the entry (current) pointed to by RowPointer
         a) Get a new index for the entry
         b) Configure the new entry with the values
            of the entry to be cloned
         c) Update the NEXT pointer with a new RowPointer
            that pointed to the previous entry that was copied
            part of this template
   6) Store RowPointer of cloned entry as (previous) in order to
      update the NEXT pointer with the next cloned entry.
   7) Get the RowPointer of the next element in the template
      as (current)
   8) If (current) RowPointer does not equal zeroDotZero go to 4
   9) Logically "unlock" all the locked entries done by step 4).

If a configuration/template is activated via a means other than a direct SNMP SET request, such as via the Policy-based Management MIB, the handling of the activation and any potential error response code must be provided via that mechanism 📬 If a configuration/template is activated using SNMP SET requests, an accurate error response value must be returned. For example, if a configuration/template has inconsistent values, the SNMP SET should return an error. Whether the configuration is already finished is not of direct importance, since the SNMP SET response must be accurate 💯 On systems where the activation may take a long time, a response may be given before completion, but extra mechanisms must be provided to detect any errors 🫶

6.2. Example 🦋

This section gives an example of the process described in the previous section. The example shows a Differentiated Services capable incoming (ingress) interface that only counts the traffic stream. Then, with the policy-based configuration concept defined in this document and in [PMMIBDR], a traffic marking configuration will be applied. The example walks you through all of the steps involved in this process 🚶‍♀️ Again, the use of [PMMIBDR] is simply an example and is not required.

NOTE WELL: For brevity and clarity, the example does not always show the complete entry (row) of a table. The only objects shown are those needed for creating the row pointers to the next functional datapath element or needed to provide information about the specific parameters of the functional datapath elements. The column named 'INDEX' always defines the complete index as defined for the associated entry. In some cases, this is a combined index of multiple components. Therefore, the names of the columns are omitted. Also note that the values Assured Forwarding and Expedited Forwarding are abstracted as DSCP(AF) and DSCP(EF) (respectively) or simply as AF and EF. For the actual values refer to [RFC3289].

6.2.1. The Initial Situation 🌸

The initial configuration is the existing configuration of an ingress interface.

   +------------------------------------------------------------+
   |   ingress functional datapath                              |
   |                        +----------+                        |
-->|----------->----------->| count    |----------->----------->|-->
   |                        +----------+                        |
   +------------------------------------------------------------+

This figure shows a simple traffic treatment functional datapath for an ingress interface. The functional datapath only consists of a count action 📊

Within the DIFFSERV-MIB, this would be instantiated as follows. Note that RowPointer objects must point to the first accessible columnar object in the conceptual row. So while it might be more instructive to use the index value for the RowPointer object's value (e.g., diffServCountActId.1) in the example, it would nonetheless be incorrect. The first accessible columnar object has been used instead, as it should be (e.g., diffServCountActOctets.1) 🙌

diffServDataPathTable
+-----------------+-----------------------------+--
| INDEX           | diffServDataPathStart       |
+-----------------+-----------------------------+--
| ifIndex.ingress | diffServActionNext.1        |
+-----------------+-----------------------------+--
diffServActionTable
+-------+--------------------+-------------------------+--
| INDEX | diffServActionNext |diffServActionSpecific   |
+-------+--------------------+-------------------------+--
| 1     | 0.0                |diffServCountActOctets.1 |
+-------+--------------------+-------------------------+--

diffServCountActTable
+-------+------------------------+--
| INDEX | diffServCountActOctets |
+-------+------------------------+--
| 1     |                        |
+-------+------------------------+--

Part 2 of 5 is a wrap! 🌈 Still plenty of spec to go 💅

6.2.2. The Configuration Template ✨

okay so this is the example bestie, and it's giving classic edge router 🦋 Traffic gets classified by a specific IP filter, which makes two classifiers (one for the IP filter and one for match all). Then both streams get metered, marked, and counted. This is the setup for an edge (ingress interface) of a Differentiated Services domain that wants Expedited Forwarding and Assured Forwarding marked traffic inside the domain. ngl it's so clean 💅

   +------------------------------------------------------------+
   |   ingress functional datapath                              |
   |   +------------+   +-------+   +---------+   +---------+   |
   |   |            |   |       |   | action: |   | action: |   |
-->|-->| classifier |-->| meter |-->| mark EF |-->| count   |-->|----->
   |   | match <IP> |   |       |   |         |   |         |   |
   |   +------------+   +-------+   +---------+   +---------+   |
   |         |                 \                                |
   |         |                  \      +---------+              |
   |         |                   \     | action: |              |routing
   |         |                    * -->| dropper |              |core
   |         |                   /     |         |              |
   |         |                  /      +---------+              |
   |         V                 /                                |
   |   +------------+   +-------+   +---------+   +---------+   |
   |   |            |   |       |   | action: |   | action: |   |
   |   | classifier |-->| meter |-->| mark AF |-->| count   |-->|----->
   |   | match all  |   |       |   |         |   |         |   |
   |   +------------+   +-------+   +---------+   +---------+   |
   +------------------------------------------------------------+

this figure shows a policy config for ingress traffic treatment on a Differentiated Services capable device 🎀 It's represented in the DIFFSERV-CONFIG-MIB module and the DIFFSERV-MIB module, so you'll see it show up in both places.

Also, the original (existing) traffic treatment from 6.2.1 is in the tables too, so don't be confused when you spot it 🙈

Quick heads up on the diffServDscpMarkActTable: DSCP(EF) is the DSCP value for Expedited Forwarding, and DSCP(AF) is the DSCP value for Assured Forwarding 🌸

 diffServConfigTable (in the MIB module in this memo)
 +-------+-------------------------+---------------------------+--
 | INDEX | diffServConfigStart     | diffServConfigDescr       |
 +-------+-------------------------+---------------------------+--
 | "foo" | diffServClfrStorage.1   | Example traffic treatment |
 +-------+-------------------------+---------------------------+--
 diffServClfrTable
 +-------+---------------------+--------------------+
 | INDEX | diffServClfrStorage | diffServClfrStatus |
 +-------+---------------------+--------------------+
 | 1     |                     |                    |
 +-------+---------------------+--------------------+
 diffServClfrElementTable (shares index with diffServClfrTable)
 +-------+---------------------------+-------------------------------+--
 | INDEX | diffServClfrElementNext   | diffServClfrElementPrecedence |
 +-------+---------------------------+-------------------------------+--
 | 1.1   |diffServMeterSucceedNext.1 | 1                             |
 | 1.2   |diffServMeterSucceedNext.2 | 2                             |
 +-------+---------------------------+-------------------------------+--
 diffServMeterTable
 +-------+--------------------------+-----------------------+--
 | INDEX | diffServMeterSucceedNext |diffServMeterFailNext  |
 +-------+--------------------------+-----------------------+--
 | 1     | diffServActionNext.2     | diffServAlgDropType.1 |
 | 2     | diffServActionNext.3     | diffServAlgDropType.1 |
 +-------+--------------------------+-----------------------+--
 diffServActionTable
 +-------+----------------------+----------------------------+--
 | INDEX | diffServActionNext   | diffServActionSpecific     |
 +-------+----------------------+----------------------------+--
 | 1     | 0.0                  | diffServCountActOctets.1   |
 | 2     | diffServActionNext.4 | diffServDscpMarkActDscp.EF |
 | 3     | diffServActionNext.5 | diffServDscpMarkActDscp.AF |
 | 4     | 0.0                  | diffServCountActOctets.2   |
 | 5     | 0.0                  | diffServCountActOctets.3   |
 +-------+----------------------+----------------------------+--
 diffServCountActTable
 +-------+------------------------+--
 | INDEX | diffServCountActOctets |
 +-------+------------------------+--
 | 1     |                        |
 | 2     |                        |
 | 3     |                        |
 +-------+------------------------+--
 diffServAlgDropTable
 +-------+---------------------+-------------------------+--
 | INDEX | diffServAlgDropType | diffServAlgDropSpecific |
 +-------+---------------------+-------------------------+--
 | 1     | alwaysDrop(5)       | 0.0                     |
 +-------+---------------------+-------------------------+--
 diffServDscpMarkActTable
 +-------------------------+
 | diffServDscpMarkActDscp |
 +-------------------------+
 | DSCP(EF)                |
 | DSCP(AF)                |
 +-------------------------+

6.2.3. Applying the Template 🧚

okay so now we've got the original ingress interface config AND the policy config we want on the actual interface 💖

The example policy has to give the required Differentiated Services traffic treatment to every interface that system administrators use. The traffic treatment is the one described in 6.2.2 above, so go back and check if you forgot 💀

So we end up with this example policy, configured through the POLICY-BASED-MANAGEMENT-MIB module (see [PMMIBDR]) 🫶

   if ( roleMatch("Administrator") )
   then
      /*
       * The $0 gets the "element" returned from the previous
       * statement.  the .1 at the end is the ingress interface
       * This sets, for example, diffServDataPathStart.3.1 to be
       * "diffServConfigStart.3.f.o.o" if interface 3 has the role
       * "Administrator".
       */
      setVar("diffServDataPathStart.$0.1",
              "diffServConfigStart.3.f.o.o", Oid)

we only apply this on the inbound (ingress) direction of the interface, no exceptions 🔥

Also, even though the PolicyScript example uses object descriptors, the running script has to use the object identifiers instead. If you want more on policies and their syntax, check out [PMMIBDR] 📚

The tables below have the cloned entries in the DIFFSERV-MIB module tables. All tables can have columns with contents or administrative objects that aren't shown here. Those columns don't decide anything in the datapath, so they're left out to keep the cloning mechanism easy to see ✨

Same deal as before: the original traffic treatment from 6.2.1 and 6.2.2 is in the tables as well 🌈

diffServConfigTable
+-------+-------------------------+---------------------------+--
| INDEX | diffServConfigStart     | diffServConfigDescr       |
+-------+-------------------------+---------------------------+--
| "foo" | diffServClfrStorage.1   | Example traffic treatment |
+-------+-------------------------+---------------------------+--
diffServDataPathTable
+-----------------+-----------------------------+--
| INDEX           | diffServDataPathStart       |
+-----------------+-----------------------------+--
| ifIndex.ingress | diffServActionNext.2        |
+-----------------+-----------------------------+--
diffServClfrTable
+-------+---------------------+--------------------+
| INDEX | diffServClfrStorage | diffServClfrStatus |
+-------+---------------------+--------------------+
| 1     |                     |                    |
| 2     |                     |                    |
+-------+---------------------+--------------------+
diffServClfrElementTable
+-------+----------------------------+-------------------------------+--
| INDEX | diffServClfrElementNext    | diffServClfrElementPrecedence |
+-------+----------------------------+-------------------------------+--
| 1.1   | diffServMeterSucceedNext.1 | 1                             |
| 1.2   | diffServMeterSucceedNext.2 | 2                             |
| 2.3   | diffServMeterSucceedNext.3 | 1                             |
| 2.4   | diffServMeterSucceedNext.4 | 2                             |
+-------+----------------------------+-------------------------------+--
diffServMeterTable
+-------+--------------------------+-----------------------+--
| INDEX | diffServMeterSucceedNext | diffServMeterFailNext |
+-------+--------------------------+-----------------------+--
| 1     | diffServActionNext.2     | diffServAlgDropType.1 |
| 2     | diffServActionNext.3     | diffServAlgDropType.1 |
| 3     | diffServActionNext.6     | diffServAlgDropType.2 |
| 4     | diffServActionNext.7     | diffServAlgDropType.2 |
+-------+--------------------------+-----------------------+--
diffServActionTable
+-------+----------------------+----------------------------+--
| INDEX | diffServActionNext   | diffServActionSpecific     |
+-------+----------------------+----------------------------+--
| 1     | 0.0                  | diffServCountActOctets.1   |
| 2     | diffServActionNext.4 | diffServDscpMarkActDscp.EF |
| 3     | diffServActionNext.5 | diffServDscpMarkActDscp.AF |
| 4     | 0.0                  | diffServCountActOctets.2   |
| 5     | 0.0                  | diffServCountActOctets.3   |
| 6     | diffServActionNext.8 | diffServDscpMarkActDscp.EF |
| 7     | diffServActionNext.9 | diffServDscpMarkActDscp.AF |
| 8     | 0.0                  | diffServCountActOctets.4   |
| 9     | 0.0                  | diffServCountActOctets.5   |
+-------+----------------------+----------------------------+--
diffServCountActTable
+-------+------------------------+--
| INDEX | diffServActCountOctets |
+-------+------------------------+--
| 1     |                        |
| 2     |                        |
| 3     |                        |
| 4     |                        |
| 5     |                        |
+-------+------------------------+--
diffServAlgDropTable
+-------+---------------------+-------------------------+--
| INDEX | diffServAlgDropType | diffServAlgDropSpecific |
+-------+---------------------+-------------------------+--
| 1     | alwaysDrop(5)       | 0.0                     |
+-------+---------------------+-------------------------+--
diffServDscpMarkActTable
+-------------------------+
| diffServDscpMarkActDscp |
+-------------------------+
| DSCP(EF)                |
| DSCP(AF)                |
+-------------------------+

so yeah, look at what's happening here 👑 The main elements that build a functional datapath get duplicated, copied, and cloned, and that's the whole point, because it keeps the policy config around so it can be reused later 🦋

It's up to the SNMP agent to keep track of which network interfaces are under policy control and which policy rules are in use. That stops policy enforcement from getting duplicated. How the agent does this is an implementation issue 🌸

And the old functional datapath configs just stay in the MIB module tables. It's up to the SNMP agent implementation to decide whether it deletes stale entries or keeps them. Garbage collection of stale entries is an implementation issue too 🗑️✨

6.2.4. Applying the Template Using SNMP Messages 💌

okay so in this bit we're gonna see the same example from before but through SNMP 🤓 the chat is between the SNMP "manager" and the SNMP "agent", and the manager is the one asking the questions while the agent is the one on the device 🧚

so the SNMP manager must have a list of the roles of the interfaces, which means it has to do an SNMP-SET for every interface that's an Administrator one. the pseudo code is basically a little function that does exactly that 💅

set_template_if_administrator_interface(
         <interface_list>, <template_name>
) {
   template_oid = SNMP-GET("diffServConfigStart.<template_name>");
   foreach interface (<ifRole_list>) {
      if (interface.role == "Administrator") {
         SNMP-SET("diffServDataPathStart.$interface.1",
               Oid, template_oid);
      }
   }
}

for an example, say there's a system with 3 interfaces 🎀 the manager already knows this list, where the first value is the interface number (ifIndex) and the second value is its role:

interface_list IF_LIST = {
    { 1, ... , "Administrator", ... },
    { 2, ... , "User", ... },
    { 3, ... , "Administrator", ... } }

so this ends up as a chat of 1 SNMP-GET and 2 SNMP-SETs between the manager and the agent ✨

  • SNMP-GET("diffServConfigStart.3.f.o.o")
  • SNMP-SET("diffServDataPathStart.1.1", Oid, "diffServActionNext.1")
  • SNMP-SET("diffServDataPathStart.3.1", Oid, "diffServActionNext.1")

7. Managed Objects Definitions (MIB Module) 👑

okay the juicy part, the MIB module itself 🦋 here's the whole DIFFSERV-CONFIG-MIB, copied exactly so nothing gets lost in translation 🫶

DIFFSERV-CONFIG-MIB DEFINITIONS ::= BEGIN
    IMPORTS

    OBJECT-TYPE, MODULE-IDENTITY,
    zeroDotZero, mib-2            FROM SNMPv2-SMI          -- [RFC2578]

    RowStatus, StorageType,
    RowPointer, DateAndTime       FROM SNMPv2-TC           -- [RFC2579]

    MODULE-COMPLIANCE,
    OBJECT-GROUP                  FROM SNMPv2-CONF         -- [RFC2580]
    SnmpAdminString               FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]

diffServConfigMib MODULE-IDENTITY
    LAST-UPDATED "200401220000Z" -- 22 January 2004
    ORGANIZATION "SNMPCONF WG"
    CONTACT-INFO
       "SNMPCONF Working Group
        http://www.ietf.org/html.charters/snmpconf-charter.html
        WG mailing list: snmpconf@snmp.com

        Editors:
        Harrie Hazewinkel
        I.Net
        via Darwin 85
        20019 - Settimo Milanese (MI)
        Italy
        EMail: harrie@inet.it

        David Partain
        Ericsson AB
        P.O. Box 1248
        SE-581 12 Linkoping
        Sweden
        E-mail: David.Partain@ericsson.com"
    DESCRIPTION
        "This MIB module contains differentiated services
        specific managed objects to perform higher-level
        configuration management.  This MIB allows policies
        to use 'templates' to instantiate Differentiated
        Services functional datapath configurations to
        be assigned (associated with an interface and
        direction) when a policy is activated.

        Copyright (C) The Internet Society (2004).  This version
        of this MIB module is part of RFC 3747;  see the RFC
        itself for full legal notices."
    REVISION "200401220000Z" -- 22 January 2004
    DESCRIPTION
        "Initial version published as RFC 3747"
    ::= { mib-2 108 }

diffServConfigMIBObjects OBJECT IDENTIFIER ::= { diffServConfigMib 1 }
diffServConfigMIBConformance OBJECT IDENTIFIER ::=
                                               { diffServConfigMib 2 }

--
-- The Differentiated Services configuration objects
--
diffServConfigTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF DiffServConfigEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
       "A table which defines the various per-hop-behaviors
       for which the system has default 'templates'."
    ::= { diffServConfigMIBObjects 2 }

diffServConfigEntry OBJECT-TYPE
    SYNTAX       DiffServConfigEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
       "An entry defining a per-hop-behavior.  Each entry in
       this table combines the various parameters (entries)
       into a specific per-hop-behavior.  Entries in this
       table might be defined by a vendor (pre-configured)
       or defined by a management application."
    INDEX { diffServConfigId }
    ::= { diffServConfigTable 1 }

DiffServConfigEntry ::= SEQUENCE {
    diffServConfigId           SnmpAdminString,
    diffServConfigDescr        SnmpAdminString,
    diffServConfigOwner        SnmpAdminString,
    diffServConfigLastChange   DateAndTime,
    diffServConfigStart        RowPointer,
    diffServConfigStorage      StorageType,
    diffServConfigStatus       RowStatus
}

diffServConfigId OBJECT-TYPE
    SYNTAX         SnmpAdminString (SIZE(1..116))
    MAX-ACCESS     not-accessible
    STATUS         current
    DESCRIPTION
      "A unique id for the per-hop-behavior policy for at
       least the SNMP agent.  For ease of administration the
       value may be unique within an administrative domain,
       but this is not required.

       The range of up to 116 octets is chosen to stay within
       the SMI limit of 128 sub-identifiers in an object
       identifier."
    ::= { diffServConfigEntry 1 }

diffServConfigDescr OBJECT-TYPE

    SYNTAX         SnmpAdminString
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "A human-readable description to identify this defined
       per-hop-behavior.  Note that this is an SnmpAdminString,
       which permits UTF-8 strings.  An administratively assigned
       identifier for a template that would be unique within
       an administrative domain.  It is up to the management
       applications to agree how these are assigned within the
       administrative domain.  Once a description, such as
       'EF' is assigned, that has a certain set of parameters
       that achieve 'EF' from box to box. Management
       application code or script code can then scan
       the table to find the proper template and then
       assign it."
    ::= { diffServConfigEntry 2 }

diffServConfigOwner OBJECT-TYPE
    SYNTAX         SnmpAdminString
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "The owner who created this entry."
    ::= { diffServConfigEntry 3 }

diffServConfigLastChange OBJECT-TYPE
    SYNTAX         DateAndTime
    MAX-ACCESS     read-only
    STATUS         current
    DESCRIPTION
       "The date and time when this entry was last changed."
    ::= { diffServConfigEntry 4 }

diffServConfigStart OBJECT-TYPE
    SYNTAX         RowPointer
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "The pointer to a functional datapath configuration template as
       set up in the DIFFSERV-MIB.  This RowPointer should
       point to an instance of one of:
         diffServClfrEntry
         diffServMeterEntry
         diffServActionEntry
         diffServAlgDropEntry
         diffServQEntry

       A value of zeroDotZero in this attribute indicates no
       further Diffserv treatment is performed on traffic of
       this functional datapath.  This also means that the
       template described by this row is not defined.

       If the row pointed to does not exist, the treatment
       is as if this attribute contains a value of zeroDotZero."
    REFERENCE
       "Differentiated Services MIB module"
    DEFVAL { zeroDotZero }
    ::= { diffServConfigEntry 5 }

diffServConfigStorage OBJECT-TYPE
    SYNTAX         StorageType
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "The type of storage used for this row.

       Since an entry in this table serves as a starting
       point for a configuration, it is recommended that
       all entries comprising the configuration started by
       diffServConfigStart follow the storage type of this
       entry.  Otherwise, after agent reboots a configuration
       may differ.  It may very well be that the agent is
       not capable of detecting such changes and therefore,
       the management application should verify the correct
       configuration after a reboot.  Rows with a StorageType
       of 'permanent' do not need to allow write access to
       any of the columnar objects in that row."
    DEFVAL { nonVolatile }
    ::= { diffServConfigEntry 6 }

diffServConfigStatus OBJECT-TYPE
    SYNTAX         RowStatus
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "RowStatus object used for creation and deletion of
       rows in this table.  All writable objects in this row
       may be modified at any time."
    DEFVAL { notInService }
    ::= { diffServConfigEntry 7 }

--
-- MIB Compliance statements.
--
diffServConfigMIBCompliances
   OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 1 }
diffServConfigMIBGroups
   OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 2 }

diffServConfigMIBFullCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION
       "The full compliance for this MIB module.

       For this compliance level the 'diffServMIBFullCompliance'
       must be met, since this MIB module depends on it in order
       to provide the configuration entries.
       "
    MODULE  -- This module
    MANDATORY-GROUPS {  diffServConfigMIBConfigGroup }

    OBJECT diffServConfigStatus
    SYNTAX RowStatus { active(1) }
    WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
    DESCRIPTION
       "Support for createAndWait and notInService is not required."

    ::= { diffServConfigMIBCompliances 1 }

diffServConfigMIBConfigGroup OBJECT-GROUP
    OBJECTS {  diffServConfigDescr,
               diffServConfigOwner,
               diffServConfigLastChange,
               diffServConfigStart,
               diffServConfigStorage,
               diffServConfigStatus
    }
    STATUS current
    DESCRIPTION
       "The per-hop-behavior Group defines the MIB objects that
       describe the configuration template for the per-hop-behavior."
    ::= { diffServConfigMIBGroups 1 }
END

8. Security Considerations 🔐

okay bestie, this is the serious part 🥺 so read it carefully. There are a bunch of management objects in this MIB module with a MAX-ACCESS of read-write and/or read-create. Those objects can be sensitive or vulnerable depending on where the network lives. SET operations in a non-secure environment without proper protection can really mess with network operations, so lock it down 🔒 These are the managed objects:

  • The diffServConfigDescr, diffServConfigOwner, and diffServConfigStatus objects are not security sensitive, since these three don't touch any direct operational behavior of a diffserv capable device 🌸
  • An unauthorized change to diffServConfigStart could lead to a different configuration, and that "changed" configuration could give the diffserv capable device different traffic treatment than you wanted 😭
  • An unauthorized change to diffServConfigStorage could lead to unknown behavior of the diffserv capable device after the SNMP agent reboots. That can happen from "not having saved changes of the configuration" or from configurations that aren't available anymore 💀

Also, the managed objects of the DIFFSERV-MIB are security sensitive too, because unauthorized changes there can cause configuration changes. For more detail, refer to [RFC3289] 📚

Reading is generally not considered sensitive, since read access only tells you that a template exists 👀 The objects that actually instantiate the template live in the DIFFSERV-MIB [RFC3289], so the template is just the blueprint. Still, if the template description (diffServConfigDescr) or owner (diffServConfigOwner) counts as sensitive information where you are, use proper access control on those objects 🫶

SNMP versions before SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there's no control over who on that secure network gets to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not it 🙅‍♀️

It is RECOMMENDED that implementers look at the security features that the SNMPv3 framework provides (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) 🔥

Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, deployment of SNMPv3 with cryptographic security enabled is RECOMMENDED. Then it's a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so that only the principals (users) with legitimate rights can GET or SET (change/create/delete) the objects 👑 Lock the door, bestie 🚪✨

9. Acknowledgments 🫶

The editors gratefully acknowledge the significant contributions to this work made by several members of both the SNMPCONF and DiffServ working groups. Thank you to everyone who helped make this happen 💖

10. References 📚

10.1. Normative References

  • [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  • [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
  • [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
  • [RFC3289] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
  • [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.

10.2. Informative References

  • [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
  • [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC3512] MacFaden, M., Partain, D., Saperia, J. and W. Tackabury, "Configuring Networks and Devices with Simple Network Management Protocol (SNMP)", RFC 3512, April 2003.
  • [PMMIBDR] Waldbusser, S., Saperia, J. and T. Hongal, "Policy-based Management MIB", Work in Progress.

11. Editors' Addresses 📮

Harrie Hazewinkel I.Net via Darwin 85 20019 - Settimo Milanese (MI) Italy

EMail: harrie@inet.it

David Partain Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden

EMail: David.Partain@ericsson.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from