rfc3144.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,684 行 · 第 1/5 页

Network Working Group                                       D. Romascanu
Request for Comments: 3144                                   Avaya, Inc.
Category: Standards Track                                    August 2001


                  Remote Monitoring MIB Extensions for
                    Interface Parameters Monitoring

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 (2001).  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.
   The document proposes an extension to the Remote Monitoring MIB with
   a method of sorting the interfaces of a monitored device according to
   values of parameters specific to this interface.

Table of Contents

   1 Introduction. . . . . . . . . . . . . . . . . . . . . . . .  2
   2 The SNMP Management Framework . . . . . . . . . . . . . . .  2
   3 Overview. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4 MIB Structure . . . . . . . . . . . . . . . . . . . . . . .  4
   5 Evolution of the Document, Limitations and Future Work. . .  4
   6 Definitions . . . . . . . . . . . . . . . . . . . . . . . .  5
   7 References. . . . . . . . . . . . . . . . . . . . . . . . . 26
   8 Intellectual Property . . . . . . . . . . . . . . . . . . . 28
   9 Security Considerations . . . . . . . . . . . . . . . . . . 29
   10 Author's Address . . . . . . . . . . . . . . . . . . . . . 29
   11 Full Copyright Statement . . . . . . . . . . . . . . . . . 30










Romascanu                   Standards Track                     [Page 1]

RFC 3144           Remote Monitoring MIB Extensions          August 2001


1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a method of sorting the interfaces of a
   monitored device according to values of parameters specific to this
   interface.

   This memo also includes a MIB module.  This MIB module extends the
   list of managed objects specified in [RFC2819] and [RFC2613].

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

2.  The SNMP 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 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], STD 58, RFC 2579 [RFC2579] and
         STD 58, RFC 2580 [RFC2580].

   o     Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         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 described in RFC 1901
         [RFC1901] and RFC 1906 [RFC1906].  The third version of the
         message protocol is called SNMPv3 and 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].

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



Romascanu                   Standards Track                     [Page 2]

RFC 3144           Remote Monitoring MIB Extensions          August 2001


   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.

3. Overview

   This document continues the architecture created in the RMON MIB
   [RFC2819] and extended by the SMON MIB [RFC2613] by providing a
   method of ordering the interfaces of a device according to the value
   of a specific parameter that characterizes the interfaces.

   The need for such a technique derives from the evolution of the
   network devices - bridges, routers, etc., into complex entities with
   a large number of interfaces and with many parameters that need to be
   monitored on each interface.  It is common for certain classes of
   switching devices to contain hundred of ports, and for each port to
   instrument and support tens of parameters - usually expressed as
   counters - for each interface.  As a result, it becomes impossible
   for applications that monitor these devices to provide a view that
   would allow the user to understand easily what is the status of the
   device, whether the behavior of a port or interface is in normal
   boundaries or not, and which are the most congested or problematic
   interfaces of the device.

   This document tries to answer this problem by proposing a method of
   providing a sorted list of interfaces according to programmable
   criteria.  The result of applying this method will be a shorter list,
   that includes the most significant interfaces sorted according to the
   selected criteria.  One possible action that can be taken by a
   network manager could be applying to this interface a copy port
   operation to a destination port that has a dedicated monitoring
   device (e.g., a network analyzer) connected to it.  A standard MIB
   interface for performing this operation is described in [RFC2613].





Romascanu                   Standards Track                     [Page 3]

RFC 3144           Remote Monitoring MIB Extensions          August 2001


4. MIB Structure

   This MIB contains one MIB group:

      -  The interfaceTopNObjects

   The interfaceTopNObjects includes one capability object and two
   tables:

      - The interfaceControlTable
      - The interfaceTopNTable

   The interfaceControlTable is an RMON-style control table, allowing
   for the creation of interfaceTopN reports.  The parameters specific
   for each report, like the duration of the report, the number of
   reports, start time and the characteristics of the variables that are
   sorted (absolute, 'deltas' or percentage of the total bandwidth) are
   set in this table.  An optional operation that is controlled from
   this table is the normalization of values of the variables, which
   allows for sorting of variables on the interfaces, despite the basic
   speed of the interfaces being different on different interfaces.

5. Evolution of the Document, Limitations and Future Work

   The RMON MIB Working Group included in its Charter a MIB document
   that would offer a solution to the problem of quickly determining the
   most congested (highest utilized) physical ports and links in an
   RMON-capable device with multiple interfaces.

   An initial solution, proposed in the first version of this document
   included a limited approach.  The objects whose values are used as
   criteria for sorting are elements in tables indexed by an
   InterfaceIndex type of object, as defined in [RFC2863].  This
   approach simplifies the search algorithm and the result table, but
   restricts the method to interface parameters.  A more generic '
   usrTopN' function was initially considered out of the scope of this
   work.

   At the Working Group meeting in Adelaide in March 2000, it was
   decided to try to define the more generic function of usrTopN.  Under
   this approach, variables belonging to tables with any type of index
   can be sorted, but at expense of extra processing and sanity checking
   by the agent.

   At the interim meeting of the RMON Working Group in San Francisco, in
   May 2000, it was decided that the usrTopN solution would not be
   continued in this phase of the work.  One of the reasons is that it
   is difficult to achieve a normalization factor for a generic



Romascanu                   Standards Track                     [Page 4]

RFC 3144           Remote Monitoring MIB Extensions          August 2001


   approach.  The group agreed it is not desirable to require the
   application to plug-in the scaling factor for every instance that
   might be included in a TopN report.

6. Definitions

INTERFACETOPN-MIB DEFINITIONS ::= BEGIN

   IMPORTS
        MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32
                FROM SNMPv2-SMI
        RowStatus, TimeStamp, TruthValue
                FROM SNMPv2-TC
        rmon, OwnerString
                FROM RMON-MIB
        CounterBasedGauge64
                FROM HCNUM-TC
        MODULE-COMPLIANCE, OBJECT-GROUP
                FROM SNMPv2-CONF;

   interfaceTopNMIB MODULE-IDENTITY
        LAST-UPDATED "200103270000Z"
        ORGANIZATION "IETF RMON MIB Working Group"
        CONTACT-INFO
        "

                Dan Romascanu
                Avaya Inc.
                Tel:  [phone]
                Email: [e-mail]"

       DESCRIPTION
          "The MIB module for sorting device interfaces for RMON and
          SMON monitoring in a multiple device implementation."
      ::= { rmon 27 }
interfaceTopNObjects       OBJECT IDENTIFIER ::= { interfaceTopNMIB 1 }
interfaceTopNNotifications OBJECT IDENTIFIER ::= { interfaceTopNMIB 2 }
interfaceTopNConformance   OBJECT IDENTIFIER ::= { interfaceTopNMIB 3 }

-- The Interface Top N group is used to prepare reports that
-- describe a list of interfaces (data sources)
-- ordered by the values of one
-- of the objects that apply to the interfaces of the respective device.
-- Those objects are defined by standard MIBs. The exact objects that
-- are supported by the agent are described by interfaceTopNCaps
-- The objects must be elements in tables indexed only by an
-- InterfaceIndex object.
-- The objects  chosen by the



Romascanu                   Standards Track                     [Page 5]

RFC 3144           Remote Monitoring MIB Extensions          August 2001


-- management station may be sampled over a management
-- station-specified time interval, making the report rate based.
-- The management station also specifies the number of interfaces
-- that are reported.
--
-- The interfaceTopNControlTable is used to initiate the generation
-- of a report.  The management station may select the parameters
-- of such a report, such as which object, how
-- many interfaces, and the start & stop times of the sampling.  When
-- the report is prepared, entries are created in the
-- interfaceTopNTable associated with the relevant
-- interfaceTopNControlEntry.  These entries are static for
-- each report after it has been prepared.

interfaceTopNCaps   OBJECT-TYPE
    SYNTAX      BITS {
               ifInOctets(0),
               ifInUcastPkts(1),
               ifInNUcastPkts(2),
               ifInDiscards(3),
               ifInErrors(4),
               ifInUnknownProtos(5),
               ifOutOctets(6),
               ifOutUcastPkts(7),
               ifOutNUcastPkts(8),
               ifOutDiscards(9),
               ifOutErrors(10),
               ifInMulticastPkts(11),
               ifInBroadcastPkts(12),
               ifOutMulticastPkts(13),
               ifOutBroadcastPkts(14),
               ifHCInOctets(15),
               ifHCInUcastPkts(16),
               ifHCInMulticastPkts(17),
               ifHCInBroadcastPkts(18),
               ifHCOutOctets(19),
               ifHCOutUcastPkts(20),
               ifHCOutMulticastPkts(21),
               ifHCOutBroadcastPkts(22),
               dot3StatsAlignmentErrors(23),
               dot3StatsFCSErrors(24),
               dot3StatsSingleCollisionFrames(25),
               dot3StatsMultipleCollisionFrames(26),
               dot3StatsSQETestErrors(27),
               dot3StatsDeferredTransmissions(28),
               dot3StatsLateCollisions(29),
               dot3StatsExcessiveCollisions(30),
               dot3StatsInternalMacTxErrors(31),