Network Working Group                                            K. White
Request for Comments: 2758                                      IBM Corp.
Category: Experimental                                      February 2000


           Definitions of Managed Objects for Service Level
                   Agreements Performance Monitoring

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo defines a Management Information Base (MIB) for performance
   monitoring of Service Level Agreements (SLAs) defined via policy
   definitions.  The MIB defined herein focuses on defining a set of
   objects for monitoring SLAs and not on replication of the content of
   the policy definitions being monitored.  The goal of the MIB defined
   within this document is to defined statistics related to a policy
   rule definition for reporting on the effect that a policy rule has on
   a system and to defined a method of monitoring this data.

Table of Contents

   1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
   2.0  The SNMP Network Management Framework   . . . . . . . . . .   2
   3.0  Structure of the MIB  . . . . . . . . . . . . . . . . . . .   3
   3.1  Scalar objects  . . . . . . . . . . . . . . . . . . . . . .   4
   3.2  slapmPolicyNameTable  . . . . . . . . . . . . . . . . . . .   5
   3.3  slapmPolicyRuleStatsTable   . . . . . . . . . . . . . . . .   6
   3.4  slapmPRMonTable   . . . . . . . . . . . . . . . . . . . . .   6
   3.5  slapmSubcomponentTable  . . . . . . . . . . . . . . . . . .   8
   4.0  Definitions   . . . . . . . . . . . . . . . . . . . . . . .   8
   5.0  Security Considerations   . . . . . . . . . . . . . . . . .  67
   6.0  Intellectual Property   . . . . . . . . . . . . . . . . . .  67
   7.0  Acknowledgments   . . . . . . . . . . . . . . . . . . . . .  68
   8.0  References  . . . . . . . . . . . . . . . . . . . . . . . .  68
   9.0  Author's Address  . . . . . . . . . . . . . . . . . . . . .  70
   10.0  Full Copyright Statement   . . . . . . . . . . . . . . . .  71

1.0  Introduction

   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, reference
   [13].

   This document's purpose is to define a MIB module for performance
   management of Service Level Agreements (SLAs).  It is assumed that an
   SLA is defined via policy schema definitions.  The policy definitions
   being modeled with respect to performance management is primarily
   related to network Quality of Service (QOS).  There are a number of
   methods that exist for defining and administering policy.  Definition
   of these methods is considered out side of the scope of this
   document.

   The MIB module defined within this memo has been modeled using the
   various versions of the schema definitions being developed within the
   Policy Framework Working Group in the IETF.  The content of the MIB
   defined within this memo has evolved along with the Policy Framework
   Working Group schema definitions.

2.0  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   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 [14], STD 16, RFC 1212 [15] and RFC 1215 [16].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [3], STD 58, RFC 2579 [4] and STD 58, RFC 2580 [5].

   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 [1].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [17] and RFC
      1906 [18].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [18], RFC 2572 [8] and RFC 2574
      [10].

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

      operations and associated PDU formats is described in RFC 1905
      [6].

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

   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.0  Structure of the MIB

   The SLAPM-MIB consists of the following components:

   o  scalar objects

   o  slapmPolicyNameTable

   o  slapmPolicyRuleStatsTable (equivalent to the deprecated
      slapmPolicyStatsTable)

   o  slapmPRMonTable (equivalent to the deprecated
      slapmPolicyMonitorTable)

   o  slapmSubcomponentTable

   Refer to the compliance statement defined within SLAPM-MIB for a
   definition of what objects and notifications MUST be implemented by
   all systems as opposed to those that MUST be implemented by end
   systems only.

   Initially most of the tables defined by the MIB module within this
   document where directly indexed using a policy's name and a
   subordinate traffic profile name.  Over time the structure and
   resulting naming has grown more complex and as such has exceeded the
   capacity of being used as a direct MIB table index.  As a result of
   this the original tables (slapmPolicyStatsTable and

   slapmPolicyMonitorTable) have been deprecated and replaced with new
   tables that use an Unsigned32 index element instead of "names".  A
   new table has been defined, slapmPolicyNameTable, that maps the
   Unsigned32 index to a unique name associated with a given policy rule
   definition.

3.1  Scalar objects

   Global objects defined within SLAPM-MIB:

   o  slapmSpinLock

      Enables multiple management application access to SLAPM-MIB.  An
      agent MUST implement the slapmSpinLock object to enable management
      applications to coordinate their use of the SLAPM-MIB.  Management
      application use of slapmSpinLock is OPTIONAL.

   o  slapmPolicyCountQueries, slapmPolicyCountAccesses,
      slapmPolicyCountSuccessAccesses, and slapmPolicyCountNotFounds

      Basic statistics on the amount of policy directory access that has
      occurred at a system.

   o  slapmPolicyPurgeTime

      Used to prevent the entries in various SLAPM-MIB tables that
      relate to a policy definition from immediately being deleted when
      the corresponding policy definition no longer exists.  This gives
      management applications time to discover this condition and close
      out any polled based interval data that may be being collected.
      All dependent slapmPRMonTable entries are also deleted when its
      parent slapmPolicyRuleStatsEntry is removed.  Refer to the OBJECT
      description for slapmPolicyPurgeTime for a more precise
      description of this function.

   o  slapmPolicyTrapEnable

      This object enables or suppresses generation of
      slapmPolicyRuleDeleted or slapmPolicyRuleMonDeleted notifications.

   o  slapmPolicyTrapFilter

      This object enables suppression of slapmSubcMonitorNotOkay
      notifications.

3.2  slapmPolicyNameTable

   The slapmPolicyNameTable maps a Unsigned32 index to a unique name
   associated with a given policy rule definition.

   Currently, the core schema definition being worked on within the
   Policy Framework working group defines five general classes:
   policyGroup, policyRule, policyCondition, policyTimePeriodCondition,
   and policyAction.  "Policies can either be used in a stand-alone
   fashion or aggregated into policy groups to perform more elaborate
   functions.  Stand-alone policies are called policy rules.  Policy
   groups are aggregations of policy rules, or aggregations of policy
   groups, but not both."  Each policy rule consists of a set of
   conditions and a set of actions.  Policy rules may be aggregated into
   policy groups.

   "Instances in a directory are identified by distinguished names
   (DNs), which provide the same type of hierarchical organization that
   a file system provides in a computer system.  A distinguished name is
   a sequence of relative distinguished names (RDNs), where an RDN
   provides a unique identifier for an instance within the context of
   its immediate superior, in the same way that a filename provides a
   unique identifier for a file within the context of the folder in
   which it resides."

   Each of these instances can also be named to fit in with the existing
   DEN practice with a commonName (cn) attribute as oppose to the
   classes name attribute.

   "The cn, or commonName, attribute is an X.500 attribute.  It stands
   for commonName.  It specifies a user-friendly name by which the
   object is commonly known.  This name may be ambiguous by itself.
   This name is used in a limited scope (such as an organization).  It
   conforms to the naming conventions of the country or culture with
   which it is associated.  CN is used universally in DEN as the naming
   attribute for a class."

   An slapmPolicyNameEntry contains a single object,
   slapmPolicyNameOfRule, that contains the unique name associated with
   a policy rule instance.  An slapmPolicyNameEntry is indexed by a
   Unsigned32 index, slapmPolicyNameIndex, that is assigned by the
   implementation of this MIB.

3.3  slapmPolicyRuleStatsTable

   This table is functionally equivalent to the deprecated
   slapmPolicyStatsTable. The slapmPolicyStatsTable uses the name of
   both a policy definition and a traffic profile name to index an
   entry.  The slapmPolicyRuleStatsTable uses an slapmPolicyNameEntry
   index (Unsigned32) instead.

   The slapmPolicyRuleStatsTable is the main table defined by SLAPM-MIB.
   The primary index for this table is slapmPolicyNameSystemAddress that
   enables support of multiple systems from a single policy agent.  The
   index element, slapmPolicyNameSystemAddress, value must be either the
   zero-length octet string when at a policy agent only a single system
   is being support, 4 octets for a ipv4 address, or 16 octets for a
   ipv6 address.

   It is possible that on a single system multiple policy agent
   instances exists.  The Entity MIB, refer to [19], should be used to
   handle the resulting MIBs.

   With respect to slapmPolicyNameSystemAddress one
   slapmPolicyRuleStatsEntry exists for each policy rule instance.
   Entries in this table are not administered via SNMP.  An agent
   implementation for this table MUST reflect its current set of policy
   rule instances via table entries.  The mechanisms for policy
   administration are outside of the scope of this memo.

3.4  slapmPRMonTable

   This table is functionally equivalent to the deprecated
   slapmPolicyMonitorTable. The slapmPolicyMonitorTable uses the name of
   both a policy definition and a traffic profile name to index an
   entry.  The slapmPRMonTable uses an slapmPolicyNameEntry index
   (Unsigned32) instead.

   The slapmPRMonTable provides a method of monitoring the effect of SLA
   policy being used at a system.  A management application creates an
   slapmPRMonEntry for each collection that it requires.  The value of
   the BITS slapmPRMonControl object determines what type of monitoring
   occurs, at what level to monitor and whether trap support is enabled:

   o  monitorMinRate(0)

      Use the value of slapmPRMonInterval as the interval to determine
      current traffic in and out rates, using slapmPRMonCurrentInRate
      and slapmPRMonCurrentOutRate, that can be compared to
      slapmPRMonMinRateLow for determining when to generate a
      slapmPolicyRuleMonNotOkay notification.  The notification

      slapmPolicyRuleMonOkay is generated when the problem is resolved.
      This can be determined by comparing the current rates to
      slapmPRMonMinRateHigh.

   o  monitorMaxRate(1)

      Use the value of slapmPRMonInterval as the interval to determine
      current traffic in and out rate, using slapmPRMonCurrentInRate and
      slapmPRMonCurrentOutRate, that can be compared to
      slapmPRMonMaxRateHigh for determining when to generate a
      slapmPolicyRuleMonNotOkay notification. The notification
      slapmPolicyRuleMonOkay is generated when the problem is resolved.
      This can be determined by comparing the current rates to
      slapmPRMonMaxRateLow.

   o  monitorMaxDelay(2)

      Use the value of slapmPRMonInterval as the interval to determine
      the current delay.  This can be calculated on an aggregate level
      by averaging the round trip times for all TCP connections
      associated with the policy definition.  For an individual
      subcomponent its round trip time can be used directly.  Compare
      this value to slapmPRMonMaxDelayHigh for determining when to
      generate a slapmPolicyRuleMonNotOkay notification.  The
      notification slapmPolicyRuleMonOkay is generated when the problem
      is resolved.  This can be determined by comparing the current
      rates to slapmPRMonMaxDelayLow.

      UDP subcomponents don't support max delay monitoring.

   o  enableAggregateTraps(3)

      The slapmPRMonitorControl BITS setting, enableAggregateTraps(3),
      MUST be set in order for any notifications relating to
      slapmPolicyRuleStatsTable monitoring to be generated.

   o  enableSubcomponentTraps(4)

      This slapmPRMonControl BITS setting MUST be set in order for any
      notifications relating to slapmSubcomponetTable monitoring to be
      generated.  The slapmPRMonControl BITS setting
      monitorSubcomponents(5) MUST be selected in order for this setting
      to be allowed.

   o  monitorSubcomponents(5)

      If selected monitor slapmSubcomponentTable entries individually.
      Note: aggregate policy rule monitoring is always enabled.

   The index element slapmPRMonOwnerIndex is used as the first index in
   slapmPRMonTable in order to enable SNMP VACM security control.  The
   slapmPRMonTable is the only table that supports SNMP RowStatus
   operations.

3.5  slapmSubcomponentTable

   Entries are made into this table for the protocol entities (policy
   traffic profile subcomponents) to indicate actual policy rule usage,
   provide general statistics at either a TCP connection or UDP listener
   level, and enable subcomponent monitoring.