tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2564

Proposed STD
Pages: 86
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: APPLMIB

Application Management MIB

Part 1 of 4, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                     C. Kalbfleisch
Request for Comments: 2564                                   Verio, Inc.
Category: Standards Track                                    C. Krupczak
                                               Empire Technologies, Inc.
                                                              R. Presuhn
                                                      BMC Software, Inc.
                                                              J. Saperia
                                                     IronBridge Networks
                                                                May 1999

                       Application Management MIB

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 (1999).  All Rights Reserved.

Abstract

   This memo defines a standards track portion of the Management
   Information Base (MIB) for use with network management protocols in
   the Internet Community.  In particular, it defines objects used for
   the management of applications.  This MIB complements the System
   Application MIB, providing for the management of applications' common
   attributes which could not typically be observed without the
   cooperation of the software being managed.

Table of Contents

   1. Introduction and Overview ...................................    2
   2. The SNMP Management Framework ...............................    4
   3. Architecture ................................................    5
   3.1. Relationships to other MIBs ...............................    5
   3.1.1. Relationship to the System Application MIB ..............    5
   3.1.2. Relationship to the Host Resources MIB ..................    6
   3.1.3. Relationship to NSM .....................................    6
   4. MIB Structure ...............................................    6
   4.1. The service-level tables ..................................    8
   4.1.1. The service name to service instance table ..............    8
   4.1.2. The service instance to service name table ..............    9
   4.1.3. The service instance to running application element table    9
   4.1.4. The running application element to service instance table    9

Top      ToC       Page 2 
   4.2. The I/O channel group .....................................    9
   4.2.1. The open channels table .................................   10
   4.2.2. The open files table ....................................   10
   4.2.3. The open connections table ..............................   11
   4.2.4. The transaction stream summary table ....................   12
   4.2.5. The transaction flow statistics table ...................   13
   4.2.6. The transaction kind statistics table ...................   13
   4.3. The former channel group ..................................   13
   4.3.1. The former channel control table ........................   14
   4.3.2. The former channel table ................................   14
   4.3.3. The former connection table .............................   14
   4.3.4. The former file table ...................................   14
   4.3.5. The transaction history tables ..........................   14
   4.4. The running element status and control group ..............   15
   4.4.1. The running application element status table ............   15
   4.4.2. The running application element control table ...........   15
   5. Definitions .................................................   16
   6. Implementation Issues .......................................   80
   7. Intellectual Property .......................................   80
   8. Acknowledgements ............................................   81
   9. Security Considerations .....................................   81
   10. References .................................................   82
   11. Authors' Addresses .........................................   84
   12. Full Copyright Statement ...................................   86


1.  Introduction and Overview

   This document furthers the work begun in the systems application MIB
   [31].

   The development of the "Host Resources MIB" [10], "Network Services
   Monitoring MIB" [23], "Mail Monitoring MIB" [24], "Relational
   Database Management System (RDBMS) Management Information Base (MIB)
   using SMIv2" [12], "Entity MIB using SMIv2" [20], and "Applicability
   of Standards Track MIBs to Management of World Wide Web Servers" [21]
   provides us with a base of experience in making a variety of
   applications visible to management; this specification abstracts out
   the common aspects of applications management and provides a generic
   base usable for the management of almost any application.

   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 [22].

   Due to the design decision to not require application
   instrumentation, many important topics were not handled in system
   application MIB [31].  The following topics are within the scope of
   this document:

Top      ToC       Page 3 
     -      Support for generic application throughput measurements;

     -      Providing MIB definitions that allow managed entities to
            report what they considered to be units of work;

     -      Providing support for generic application response time
            monitoring capabilities; (Note that APIs for this purpose
            have already been developed, an example of such an API is to
            be found in the "Application Response Measurement (ARM) API
            Guide, Version 2" [1].)

     -      Provide explicit support for the management of applications
            distributed within a single managed system ("local"
            distribution);

     -      Address generic resource management issues, including:

            -      files in use;

            -      I/O statistics (from the application's perspective,
                   not at the operating system or device driver level);

            -      application-layer networking resource usage

     -      Facilities for the control of applications, including:

            -      Stopping application elements

            -      Suspending and resuming application elements;

            -      Requesting reconfiguration (e.g., SIGHUP).

   Note that these issues are addressed at least in part by other (non-
   IETF) standards work, including "ITU-T Recommendation X.744 | ISO/IEC
   IS 10164-18:1996" [3] and "IEEE P1387.2, POSIX System Administration
   - Part 2: Software Administration" [2].

Top      ToC       Page 4 
2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

     An overall architecture, described in RFC 2571 [26].

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

     Message protocols for transferring management information.  The
     first version of the SNMP message protocol is called SNMPv1 and
     described in STD 15, RFC 1157 [5].  A second version of the SNMP
     message protocol, which is not an Internet standards track
     protocol, is called SNMPv2c and described in RFC 1901 [14] and RFC
     1906 [19].  The third version of the message protocol is called
     SNMPv3 and described in RFC 1906 [19], RFC 2572 [27] and RFC 2574
     [29].

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

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

   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.

Top      ToC       Page 5 
3.  Architecture

   Object-oriented modeling techniques like subclassing and multiple
   inheritance can be emulated in the SNMP information model through the
   use of tables with common indexes.

   The challenge for the developer of management applications is to
   recognize those situations in which various aspects of a single
   logical resource are represented in several different tables,
   possibly defined in different MIBs.

   Most of the management information defined here may pertain to any
   number of applications in a managed system.  The simplest way of
   supporting this requirement within the SNMP information model is to
   use tables.  This means that the management information for a
   particular resource may be found in one or more rows of one or more
   tables; the fact that this information pertains to a single resource
   may be inferred from the index values used, possibly with the support
   of mapping tables.  This also means that a single table may contain
   management information relevant to a number of applications.  This
   has significant implementation implications; see the implementation
   issues section below for more information.

3.1.  Relationships to other MIBs

   This section outlines the relationships of the components of this MIB
   (usually in the form of common indexing structures) to:

     -      the systems applications MIB [31]

     -      the host resources MIB [10]

     -      the network services monitoring MIB [23]

3.1.1.  Relationship to the System Application MIB

   The system application MIB defines attributes for management of
   applications which can be realized without instrumenting the
   application itself.  This specification extends that framework to
   include additional attributes which will typically require
   instrumentation within the managed resource.  The sysApplRunElmtIndex
   is the key connection between these two MIBs; it is essential that
   implementations of this MIB and of the system applications MIB
   running concurrently on a given platform employ a consistent policy
   for assigning this value to identify running application elements.

Top      ToC       Page 6 
3.1.2.  Relationship to the Host Resources MIB

   The Host Resources MIB [10] supplies information on the hardware,
   operating system, installed and running software on a host.

   The Host Resources MIB has three hardware groups ("hrSystem",
   "hrStorage" and "hrDevice") and three software groups ("hrSWRun",
   "hrSWRunPerf" and "hrSWInstalled").  Of these, the software groups
   are of greatest significance to this MIB.

   The software groups define management information on the software
   used in the system. The information provided is grouped into (1) the
   currently running, (2) the performance and (3) the installed
   applications.

   The index "hrSWRunIndex" used in the "hrSWRunTable" and other tables
   to identify running software by process identifier (or equivalent)
   relates information in the Host Resources MIB to information in the
   System Applications MIB and this MIB. It is essential that the values
   assigned to hrSWRunIndex from the Host Resources MIB be consistent
   with the values used for sysApplRunElmtIndex.

3.1.3.  Relationship to NSM

   The Network Services Monitoring MIB [23] is defined as the base set
   of attributes for managing network applications.  The Application MIB
   includes information normally obtainable only from the managed
   resource itself, rather than the supporting system.  Due to
   differences in index representation, the relationship between the
   Network Services Monitoring MIB and the Application MIB is not
   formally defined.

4.  MIB Structure

   This MIB is organized into several groups, which in turn are
   organized into tables to provide the monitoring and control of
   information relevant to the management of applications.  The groups
   model:

     -      the service-level view of applications

     -      information on open channels (files, connections,
            transaction streams) in use by applications

     -      historical information on former channels

     -      process-level status and control information

Top      ToC       Page 7 
   These groups are organized into various tables.  Information for a
   particular running managed application appears in the form of entries
   in the appropriate tables.  The tables are:

     -      the tables providing a service-level view, including:

            -      the service name to service instance table

            -      the service instance to service name table

            -      the service instance to running application element
                   table

            -      the running application element to service instance
                   table

     -      the tables providing information on I/O channels, including:

            -      the table of open channels

            -      the table of open files

            -      the open connections table

            -      the transaction statistics tables

     -      historical information on I/O channels

     -      the running application element status and control group

            -      the running application element status table

            -      the running application element control table

   In order to support SNMPv1, SNMPv2, and SNMPv3 environments, in cases
   where counter objects may potentially advance very rapidly, where
   sixty-four bit counters have been used thirty-two bit counters
   reporting the low-order thirty-two bits of the value have also been
   defined.

   Since rows in most of these tables will come and go with the running
   application elements whose information is contained in them,
   sysUpTime.0 is not appropriate as a discontinuity indicator for
   counters in these tables.  By defining separate discontinuity
   indicators for the rows in these tables, entries can come and go as
   needed without causing other objects to appear to have
   discontinuities.  As required by [15], the discontinuity indicators
   for the various information objects in these tables are identified in

Top      ToC       Page 8 
   the relevant DESCRIPTION clauses.  Note that a discontinuity in one
   of these counters does not imply a sysUpTime.0 discontinuity, nor
   does a sysUpTime.0 discontinuity imply a discontinuity in any of
   these counters.

4.1.  The service-level tables

   The service-level tables permit the identification of one or more
   instances of named services on a system, and the association of
   running application elements to these services.

   Service names are represented as human-readable strings, using values
   assigned by IANA where possible.  The allocation of unique values for
   service instance identifiers is a local administrative issue; the
   values allocated must be constant for the lifetime of the service
   instance, and re-use of values should be avoided.

   It is important to understand that a service is not the same thing as
   a protocol.  Rather, some services may be at least partially
   described by the protocol(s) used to provide that service.

   In deciding what should or should not be considered a service, the
   following factors merit consideration:

     -      is there an identifiable set of resources associated with
            providing this service?

     -      is there a reasonably long-lived server or client process?

   Following this reasoning, one can see where SMTP and HTTP service
   providers would be good candidates for classification as services for
   purposes of application management, where finger probably would not.
   Of course, implementors of this MIB are free to define additional
   services.  An applicability statement may be an appropriate vehicle
   for standardizing how a specific service's information is reported
   using this MIB.

4.1.1.  The service name to service instance table

   The service name to service instance table uses the service name as
   its primary key, and the service instance identifier as its secondary
   key.  It facilitates the identification and lookup of the instances
   of a given service in a system.

Top      ToC       Page 9 
4.1.2.  The service instance to service name table

   The service instance to service name table uses the service instance
   identifier as its primary key, and the service name as its secondary
   key.  Given a service instance identifier, it facilitates the lookup
   of the name of the service being provided.

4.1.3.  The service instance to running application element table

   The service instance to running application element table uses the
   service instance identifier as its primary key, and the running
   application element index as its secondary key.  This facilitates the
   identification of the set of running application elements providing a
   given instance of a service.

4.1.4.  The running application element to service instance table

   The running application element to service instance table uses the
   running application element index as its primary key and the service
   instance identifier as its secondary key.  It identifies the set of
   services provided by a given running application element.

4.2.  The I/O channel group

   Information processed by an application can be modeled using the
   concept of a channel.  Two kinds of channels, for example, are files
   and network connections.

                                                  +-------+
                                                  | File  |
                             +---------+         /+-------+
          +-------------+    | Generic |        /
          | transaction |----|  I/O    |-------<
          |   stream    |    | Channel |        \  +------------+
          +-------------+    +---------+         \ | open or    |
                                                  \| listening  |
                                                   | connection |
                                                   +------------+


   For each entry in the open channel table, there will be a
   corresponding entry in either the open file table or the open
   connection table.

   The information flowing on a channel may be structured as
   transactions.  When the information flow on a channel is being
   monitored as a transaction stream, an entry in the transaction stream
   table will represent this fact and the associated information about

Top      ToC       Page 10 
   that stream.

   To facilitate traversal of these tables and retrieval of information
   relevant to a specific running application element or service
   instances, the initial indexes of these tables are the same.  In each
   case, the first index determines whether the second index is
   interpreted as a running application element identifier or as a
   service instance identifier.  The third index serves to uniquely
   identify a channel (and consequently, an open connection or file) in
   the context of a running application element or service instance.

   The transaction stream summary table contains per-stream summaries of
   transaction statistics.  The transaction flow statistics table
   contains statistics broken into both transmit and receive counts for
   requests and responses on each stream.  The transaction kind
   statistics table contains information further broken down by
   transaction kind.

   The transaction tables have a common structure for their indexing,
   with additional indexes added for increasing detail.  The initial
   three indexes are the same as all the other tables in this group,
   serving to uniquely identify each transaction stream.

4.2.1.  The open channels table

   The following information is available in this table:

     -      time at which the channel was opened

     -      number of read requests

     -      number of bytes read

     -      time at which most recent read operation was initiated

     -      number of write requests

     -      number of bytes written

     -      time at which most recent write operation was initiated

4.2.2.  The open files table

   The open files table contains one entry for each file in use by a
   manageable running application element.  (See "Definitions of
   System-Level Managed Objects for Applications" [31] for a detailed
   definition of a running application element.)  The purpose of this
   table is to identify the files in use and to record information

Top      ToC       Page 11 
   peculiar to files not already covered in the open channel table.

   If multiple running application elements open the same file, there
   will be an entry for each running application element opening that
   file.  Similarly, if a running application element opens a file
   multiple times, there will be an entry in this table for the file
   corresponding to each open.

   The task of combining the information for file activity from this
   table (organized by running application element) into per-application
   statistics can be accomplished by a manager using the System
   Application MIB's [31] sysApplInstallPkgTable to find the installed
   application, the sysApplRunTable to find the running instances of
   that application, and the sysApplElmtRunTable to find the relevant
   values of sysApplElmtRunIndex.  The manager, armed with a set of
   values for sysApplElmtRunIndex, is now able to retrieve the relevant
   portions of the applOpenFileTable and other tables in this MIB.

   The following information is available in this table:

     -      file name

     -      file size

     -      current mode (read/write) of this file

   By convention, the names "stdin", "stdout" and "stderr" are used when
   these streams cannot be resolved to actual file names.

4.2.3.  The open connections table

   This table provides information on channels that are open connections
   or listeners.

   The following information is available for each connection:

     -      identification of the transport protocol in use

     -      near-end address and port

     -      far-end address and port

     -      identification of the application layer protocol in use

Top      ToC       Page 12 
4.2.4.  The transaction stream summary table

   The transaction stream summary table contains per-stream summaries of
   transaction statistics.  The simple model of a transaction used here
   looks like this:

                   invoker  |   Request     | performer
                            | - - - - - - > |
                            |               |
                            |   Response    |
                            | < - - - - - - |
                            |               |


   Since in some protocols it is possible for an entity to take on both
   the invoker and performer roles, information here is accumulated for
   transmitted and received requests, as well as for transmitted and
   received responses.  Counts are maintained for both transactions and
   bytes transferred.  The information represented in this table
   includes:

     -      identification of the underlying connection or file used for
            this transaction stream

     -      a human-readable description of this stream

     -      a human-readable description of this stream's notion of what
            a unit of work is

     -      the cumulative amount of time spent (as an operation
            invoker) waiting for responses (from queueing of request to
            arrival of first response)

     -      the cumulative amount of time spent (as an operation
            invoker) receiving responses (time from the arrival of the
            first response to the arrival of the last response in a
            series of responses to a particular request)

     -      the cumulative amount of time spent (as an operation
            performer) handling requests (time from receipt of request
            to queueing of first outgoing response)

     -      the cumulative amount of time spent (as an operation
            performer) sending responses  (time from queuing of first
            response to the last response in a series of responses to a
            particular request)

Top      ToC       Page 13 
     -      the cumulative number of transactions initiated (as an
            invoker)

     -      the cumulative number of transactions processed (as a
            performer)

4.2.5.  The transaction flow statistics table

   The transaction flow statistics table contains statistics broken into
   both transmit and receive counts for requests and responses on each
   stream.  In addition to the service instance / running application
   element and transaction stream identifier indexes, rows in this table
   are indexed by flow direction (transmit or receive) and role
   (requests and responses).  The information in this table includes:

     -      the number of transactions processed

     -      the number of bytes processed

     -      the time at which the most recent transaction was processed
            in this flow

4.2.6.  The transaction kind statistics table

   The transaction kind statistics table contains summary information
   organized by direction, request/response, and transaction kind for
   each stream.  The indexing of this table is like that of the
   transaction flow table, with the addition of a transaction kind
   index.

     -      number of transactions processed

     -      number of bytes processed

     -      the time at which the most recent transaction of this kind
            in this direction in this stream was processed

4.3.  The former channel group

   The former channel group has several tables.  The former channel
   control table controls the retention of history information by a
   running application element or service instance.  The remaining
   tables parallel the structure of the channel group, with one
   significant difference in indexing structure.  The closed channel
   index is independent from the open channel index.

Top      ToC       Page 14 
4.3.1.  The former channel control table

   The former channel control table provides control over the
   accumulation of information on former connections for running
   application elements and service instances.  For each one, this
   table, indexed by the running application element or service instance
   index, controls whether information on former channels is
   accumulated, how many of these history records are retained, how long
   these are retained (within the lifetime of the process), and a count
   of history entries that were deleted before their expiration time in
   order to make room for new entries.

4.3.2.  The former channel table

   The former channel table provides historical information on channels
   that have been closed.  The number and lifetime of these entries is
   controlled, for each running application element or service instance,
   by the former channel control table.  Most of the information in this
   table corresponds to information in the open channel table.

   For the connection or file-specific aspects of a given former
   channel, an entry will exist in the former connection table or in the
   former file table.

4.3.3.  The former connection table

   For formerly open channels that were connections, connection-specific
   historical information is kept in the former connection table.  For
   each entry in the former connection table, there will be an
   identically indexed entry in the former channel table.

4.3.4.  The former file table

   For formerly open channels that were files, file-specific historical
   information is kept in the former file table.  For each entry in the
   former file table, there will be an identically indexed entry in the
   former channel table.

4.3.5.  The transaction history tables

   Two tables provide per-transaction-kind breakdowns for channels
   carrying transaction-structured flows.  These tables are analogous to
   the transaction flow and kind statistics tables, with similar index
   structures.

Top      ToC       Page 15 
4.4.  The running element status and control group

   The running application element status and control group has two
   tables.

4.4.1.  The running application element status table

   This table provides information for a running application element.
   Indexed by the sysApplElmtRunIndex, an entry in this table reports
   useful information on that running element's resource usage.  Entries
   in this table contain:

     -      current heap usage for this running application element

     -      current number of open network connections for this running
            application element

     -      the most recent error status message issued by this running
            application element

   Note that other information, such as the current number of open files
   for this running application element, is available from the
   sysapplElmtRunTable in [31].

4.4.2.  The running application element control table

   This table provides rudimentary control over a running application
   element.  Indexed by the sysApplElmtRunIndex, an entry in this table
   gives a manager with appropriate permissions the ability to suspend
   and resume processing by this running element, the ability to request
   reconfiguration, and the ability to terminate the running element.

   Variables in this table include:

     -      a suspend/resume control

     -      a reconfiguration request control

     -      a termination request control


Next RFC Part