rfc3287.txt

RFC 的详细文档！

Network Working Group                                         A. Bierman
Request for Comments: 3287                           Cisco Systems, Inc.
Category: Standards Track                                      July 2002


                  Remote Monitoring MIB Extensions for
                        Differentiated Services

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 defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for monitoring
   Differentiated Services (DS) Codepoint usage in packets which contain
   a DS field, utilizing the monitoring framework defined in the RMON-2
   (Remote Network Monitoring Management Version 2) MIB.

Table of Contents

   1 The SNMP Network Management Framework ........................... 2
   2 Overview ........................................................ 3
   2.1 Terms ......................................................... 4
   2.2 Relationship to Differentiated Services ....................... 4
   2.3 Relationship to the Remote Monitoring MIBs .................... 5
   3 MIB Structure ................................................... 6
   3.1 DSCP Counter Aggregation ...................................... 7
   3.1.1 Counter Aggregation Configuration ..........................  8
   3.2 MIB Group Overview ...........................................  8
   3.2.1 DSCP Counter Aggregation Control Group .....................  9
   3.2.2 DS Statistics Group ........................................ 10
   3.2.3 DS Protocol Distribution Group ............................. 10
   3.2.4 DS Host Distribution Group ................................. 11
   3.2.5 DSMON Capabilities Group ................................... 12
   3.2.6 DS Matrix Distribution Group ............................... 13
   3.3 RMON vs. DSMON Indexing Structure ............................ 13
   4 Definitions .................................................... 16



Bierman                     Standards Track                     [Page 1]

RFC 3287                       DSMON MIB                      July 2002


   5 Counter Aggregation Configuration Usage Examples .............. 108
   5.1 Step 1: Unlock the Counter Aggregation Configuration ........ 109
   5.2 Step 2: Check the  Maximum  number  of  Counter  Aggregation
        Groups ..................................................... 109
   5.3  Step  3:  Check if the counter aggregation profiles already
        exist ...................................................... 109
   5.4 Step 4: Create the Counter Aggregation Control Entries ...... 109
   5.5 Step 5: Create the Counter  Aggregation  Group  Descriptions
        ............................................................ 110
   5.6 Step 6: Create the Counter Aggregation Profile Mappings ..... 112
   5.7 Step 7: Lock the Counter Aggregation Configuration .......... 115
   6 Intellectual Property ......................................... 115
   7 Acknowledgements .............................................. 116
   8 References .................................................... 116
   9 Security Considerations ....................................... 118
   10 Author's Address ............................................. 119
   11 Full Copyright Statement ..................................... 120

1.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   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
      STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
      1215 [RFC1215].  The second version, called SMIv2, is described in
      STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580
      [RFC2580].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and is
      described in STD 15, RFC 1157 [RFC1157].  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 [RFC1901]
      and RFC 1906 [RFC1906].  The third version of the message protocol
      is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572
      [RFC2572] and RFC 2574 [RFC2574].

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




Bierman                     Standards Track                     [Page 2]

RFC 3287                       DSMON MIB                      July 2002


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

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

   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.

2.  Overview

   There is a need for a standardized way of monitoring the network
   traffic usage of Differentiated Services (DS) [RFC2474] codepoint
   values.  Each DS codepoint (DSCP) value may be given a different
   treatment by a forwarding device, and this affects which packets get
   dropped or delayed during periods of network congestion.

   The IETF DIFFSERV working group has redefined the semantics of the
   Type of Service (TOS) octet in the IP header, which is now called the
   'DS field'.  The 6-bit Codepoint (DSCP) portion is contained in the
   DS field, which provides for 64 different packet treatments for the
   implementation of differentiated network services.

   By polling DSCP usage counters, an NMS can determine the network
   throughput for traffic associated with different DSCPs.  This data
   can then be analyzed in order to 'tune' DSCP 'allocations' within a
   network, based on the Quality of Service (QoS) policies for that
   network.

   Remote monitoring agents are typically implemented as independent
   software (and sometimes hardware) components, called 'RMON probes'.
   Note that DSMON-capable RMON probes simply collect and aggregate
   statistics, based on criteria (which includes the DSCP value) that
   can be determined by inspecting the contents of monitored packets and
   do not in any way monitor any aspect of a DS forwarding device's
   internal statistics.



Bierman                     Standards Track                     [Page 3]

RFC 3287                       DSMON MIB                      July 2002


2.1.  Terms

   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 BCP 14, RFC 2119.
   [RFC2119]

   This document uses some terms that need introduction:

   DataSource
      A source of data for monitoring purposes.  This term is used
      exactly as defined in the RMON-2 MIB [RFC2021].

   protocol
      A specific protocol encapsulation, as identified for monitoring
      purposes.  This term is used exactly as defined in the RMON
      Protocol Identifiers document [RFC2074].

   Counter Aggregation Group
      A group of statistical counters that are being combined in the
      agent to produce one aggregated counter.  Refer to sections 3.1
      and 3.2.1 for details on counter aggregation groups.

   Counter Aggregation Profile
      Also called 'profile'; A complete set of counter aggregation group
      mappings for DSCP values (i.e., 64 mappings, for each DSCP values
      0 to 63), which are applied to all monitored packets on a
      particular data source and/or DSMON collection.  Refer to sections
      3.1 and 3.2.1 for details on counter aggregation profiles.

   High Capacity Monitoring
      The generic capability to collect and store statistics with an
      internal range of 64 bits (e.g., Counter64).  This term does not
      refer to implementation of the High Capacity RMON MIB [RFC3273].

2.2.  Relationship to Differentiated Services

   The DSMON MIB is a product of the RMONMIB WG, not the DIFFSERV WG,
   and it focuses on extending several existing RMON mechanisms to
   support additional packet classification, based on DSCP values
   observed in monitored packets.  This document assumes the reader is
   familiar with the DS Architecture [RFC2475].

   It is expected that complex management applications will use the
   counters in this MIB to help analyze DS-related throughput.  It is
   expected that other metrics, such as delay and jitter, will also be
   analyzed, but support for other metrics is outside the scope of this
   document.



Bierman                     Standards Track                     [Page 4]

RFC 3287                       DSMON MIB                      July 2002


2.3.  Relationship to the Remote Monitoring MIBs

   This MIB is intended to be implemented in Remote Monitoring (RMON)
   probes, which support the RMON-2 MIB [RFC2021].  Such probes may be
   stand-alone devices, or may be co-located with other networking
   devices (e.g., ethernet switches and repeaters).

   The DSMON functions are intended to be implemented in conjunction
   with the associated RMON functions, but the MIB is independent of all
   other RMON data tables.

   Several concepts and even MIB objects from the RMON MIBs are used in
   the DSMON MIB:

   Protocol Directory
      The RMON-2 MIB [RFC2021] defines the protocolDirTable, which is a
      directory of all the protocols that the RMON-2 agent is capable of
      decoding and counting.  The DSMON MIB utilizes this directory to
      identify the protocols detected in monitored packets.  The
      protocolDirLocalIndex MIB object is used to identify protocol
      encapsulations in all DSMON data tables which classify and
      aggregate by protocol type in some manner.  Note that the
      protocolDirTable is used for protocol identification only,
      independent of DSCP classification.

   TimeFilter
      The RMON-2 TimeFilter textual convention provides a mechanism to
      retrieve only rows which have been created or modified since the
      last polling interval (for a particular NMS).  The DSMON MIB uses
      this textual convention in the large data tables, in order to
      minimize polling impact.

   Zero-Based Counters
      Since counters are instantiated by management action, as in the
      RMON MIBs, the DSMON MIB uses zero-based counters in all data
      collection tables.  Specifically, the ZeroBasedCounter32 textual
      convention from the RMON-2 MIB [RFC2021] and the
      ZeroBasedCounter64 textual convention (defined in the HCNUM-TC MIB
      [RFC2856]) are used to define counter objects in this MIB.

   High Capacity Counters
      The DSMON MIB uses the 'SNMPv1 coexistence' strategy adopted by
      the RMONMIB WG.  That is, where a 64-bit counter is provided, a
      32-bit version of the counter, and a 32-bit overflow counter are
      also provided.






Bierman                     Standards Track                     [Page 5]

RFC 3287                       DSMON MIB                      July 2002


   TopN Reports
      The DSMON MIB uses the same TopN reporting MIB structure as the
      RMON-2 MIB [RFC2021].  TopN reporting can greatly reduce the
      polling overhead required to analyze DSCP usage patterns.

   Some DESCRIPTION clauses for DSMON objects are very similar to those
   for existing RMON-2 or HC-RMON objects.  This is intentional, since
   the semantics of the DSMON features are designed to be as close to
   existing RMON feature as possible, to allow developers and users some
   level of 'MIB re-use'.

3.  MIB Structure

              Figure 1: DSMON MIB Functional Structure

       +--------------+     +---------------+
       |              |     |    Counter    |
       |    DSMON     |     |  Aggregation  |
       | Capabilities |     |    Control    |
       |              |     |               |
       +--------------+     +---------------+
                                   |
                                   |
    +------------------------------+----------------------------+
    |                              V                            |
    |                                                           |
    | +-----------+ +-----------+ +-----------+ +------------+  |
    | |           | |           | |           | |            |  |