Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3289

Management Information Base for the Differentiated Services Architecture

Pages: 116
Proposed Standard
Errata
Part 1 of 6 – Pages 1 to 5
None   None   Next

Top   ToC   RFC3289 - Page 1
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
Top   ToC   RFC3289 - Page 2
   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
Top   ToC   RFC3289 - Page 3

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.
Top   ToC   RFC3289 - Page 4
   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
Top   ToC   RFC3289 - Page 5
   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.


(next page on part 2)

Next Section