rfc2788.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           N. Freed
Request for Comments: 2788                                      Innosoft
Category: Standards Track                                       S. Kille
Obsoletes: 2248                                     MessagingDirect Ltd.
                                                              March 2000


                    Network Services Monitoring 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 (2000).  All Rights Reserved.

Introduction

   A networked application is a realization of some well-defined service
   on one or more host computers that is accessible via some network,
   uses some network for its internal operations, or both.

   There are a wide range of networked applications for which it is
   appropriate to provide SNMP monitoring of their network usage.  This
   includes applications using both TCP/IP and OSI networking.  This
   document defines a MIB which contains the elements common to the
   monitoring of any network service application.  This information
   includes a table of all monitorable network service applications, a
   count of the associations (connections) to each application, and
   basic information about the parameters and status of each
   application-related association.

   This MIB may be used on its own for any application, and for most
   simple applications this will suffice.  This MIB is also designed to
   serve as a building block which can be used in conjunction with
   application-specific monitoring and management.  Two examples of this
   are MIBs defining additional variables for monitoring a Message
   Transfer Agent (MTA) service or a Directory Service Agent (DSA)
   service. It is expected that further MIBs of this nature will be
   specified.






Freed & Kille               Standards Track                     [Page 1]

RFC 2788            Network Services Monitoring MIB           March 2000


   This MIB does not attempt to provide facilities for management of the
   host or hosts the network service application runs on, nor does it
   provide facilities for monitoring applications that provide something
   other than a network service.  Host resource and general application
   monitoring is handled by either the Host Resources MIB [1] or the
   application MIB [2].

Table of Contents

   1  The SNMP Network Management Framework .......................  2
   2  Rationale for having a Network Services Monitoring MIB ......  3
      1 General Relationship to Other MIBs ........................  4
      2 Restriction of Scope ......................................  4
      3 Configuration Information .................................  5
   3  Application Objects .........................................  5
   4  Definitions .................................................  5
   5  Changes made since RFC 2248 ................................. 18
   6  Acknowledgements ............................................ 18
   7  References .................................................. 19
   8  Security Considerations ..................................... 20
   9  Author and Chair Addresses .................................. 21
   10 Full Copyright Statement .................................... 22

1.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

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

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






Freed & Kille               Standards Track                     [Page 2]

RFC 2788            Network Services Monitoring MIB           March 2000


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

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

   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.  Rationale for having a Network Services Monitoring MIB

   Much effort has been expended in developing tools to manage lower
   layer network facilities.  However, relatively little work has been
   done on managing application layer entities.  It is neither efficient
   nor reasonable to manage all aspects of application layer entities
   using only lower layer information. Moreover, the difficulty of
   managing application entities in this way increases dramatically as
   application entities become more complex.

   This leads to a substantial need to monitor applications which
   provide network services, particularly distributed components such as
   MTAs and DSAs, by monitoring specific aspects of the application
   itself.  Reasons to monitor such components include but are not
   limited to measuring load, detecting broken connectivity, isolating
   system failures, and locating congestion.

   In order to manage network service applications effectively two
   requirements must be met:

   (1) It must be possible to monitor a large number of components
       (typical for a large organization).





Freed & Kille               Standards Track                     [Page 3]

RFC 2788            Network Services Monitoring MIB           March 2000


   (2) Application monitoring must be integrated into general network
       management.

   This specification defines simple read-only access; this is
   sufficient to determine up/down status and provide an indication of a
   broad class of operational problems.

2.1.  General Relationship to Other MIBs

   This MIB is intended to only provide facilities common to the
   monitoring of any network service application.  It does not provide
   all the facilities necessary to monitor any specific application.
   Each specific type of network service application is expected to have
   a MIB of its own that makes use of these common facilities.

2.2.  Restriction of Scope

   The framework provided here is very minimal; there is a lot more that
   could be done. For example:

   (1) General network service application configuration monitoring and
       control.

   (2) Detailed examination and modification of individual entries in
       service-specific request queues.

   (3) Probing to determine the status of a specific request (e.g., the
       location of a mail message with a specific message-id).

   (4) Requesting that certain actions be performed (e.g., forcing an
       immediate connection and transfer of pending messages to some
       specific system).

   All these capabilities are both impressive and useful.  However,
   these capabilities would require provisions for strict security
   checking.  These capabilities would also mandate a much more complex
   design, with many characteristics likely to be fairly
   implementation-specific.  As a result such facilities are likely to
   be both contentious and difficult to implement.

   This document religiously keeps things simple and focuses on the
   basic monitoring aspect of managing applications providing network
   services.  The goal here is to provide a framework which is simple,
   useful, and widely implementable.







Freed & Kille               Standards Track                     [Page 4]

RFC 2788            Network Services Monitoring MIB           March 2000


2.3.  Configuration Information

   This MIB attempts to provide information about the operational
   aspects of an application. Further information about the actual
   configuration of a given application may be kept in other places; the
   applDirectoryName or applURL may be used to point to places where
   such information is kept.

3.  Application Objects

   This MIB defines a set of general purpose attributes which would be
   appropriate for a range of applications that provide network
   services.  Both OSI and non-OSI services can be accommodated.
   Additional tables defined in extensions to this MIB provide
   attributes specific to specific network services.

   A table is defined which will have one row for each operational
   network service application on the system.  The only static
   information held on the application is its name.  All other static
   information should be obtained from various directory services.  The
   applDirectoryName is an external key, which allows an SNMP MIB entry
   to be cleanly related to the X.500 Directory.  In SNMP terms, the
   applications are grouped in a table called applTable, which is
   indexed by an integer key applIndex.

   The type of the application will be determined by one or both of:

    (1)   Additional MIB variables specific to the applications.

    (2)   An association to the application of a specific protocol.

4.  Definitions

   NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2
         FROM SNMPv2-SMI
       TimeStamp, TEXTUAL-CONVENTION
         FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
         FROM SNMPv2-CONF
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB;

   application MODULE-IDENTITY
       LAST-UPDATED "200003030000Z"
       ORGANIZATION "IETF Mail and Directory Management Working Group"



Freed & Kille               Standards Track                     [Page 5]

RFC 2788            Network Services Monitoring MIB           March 2000


       CONTACT-INFO
         "        Ned Freed

          Postal: Innosoft International, Inc.
                  1050 Lakes Drive
                  West Covina, CA 91790
                  US

             Tel: [phone]
             Fax: [phone]

          E-Mail: [e-mail]"
       DESCRIPTION
         "The MIB module describing network service applications"
       REVISION "200003030000Z"
       DESCRIPTION
         "This revision, published in RFC 2788, changes a number of
          DisplayStrings to SnmpAdminStrings. Note that this change
          is not strictly supported by SMIv2.  However, the alternative
          of deprecating the old objects and defining new objects
          would have a more adverse impact on backward compatibility
          and interoperability, given the particular semantics of
          these objects. The defining reference for distinguished
          names has also been updated from RFC 1779 to RFC 2253."
       REVISION "199905120000Z"
       DESCRIPTION
         "This revision fixes a few small technical problems found
          in previous versions, mostly in regards to the conformance
          groups for different versions of this MIB.  No changes have
          been made to the objects this MIB defines since RFC 2248."
       REVISION "199708170000Z"
       DESCRIPTION
         "This revision, published in RFC 2248, adds the
          applDescription and applURL objects, adds the quiescing
          state to the applOperStatus object and renames the MIB
          from the APPLICATION-MIB to the NETWORK-SERVICE-MIB."
       REVISION "199311280000Z"
       DESCRIPTION
         "The original version of this MIB was published in RFC 1565"
       ::= {mib-2 27}

   -- Textual conventions

   -- DistinguishedName is used to refer to objects in the
   -- directory.

   DistinguishedName ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255a"



Freed & Kille               Standards Track                     [Page 6]

RFC 2788            Network Services Monitoring MIB           March 2000


       STATUS current
       DESCRIPTION
           "A Distinguished Name represented in accordance with
            RFC 2253, presented in the UTF-8 charset defined in
            RFC 2279."
       SYNTAX OCTET STRING (SIZE (0..255))

   -- Uniform Resource Locators are stored in URLStrings.

   URLString ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255a"
       STATUS current
       DESCRIPTION
           "A Uniform Resource Locator represented in accordance
            with RFCs 1738 and 2368, presented in the NVT ASCII
            charset defined in RFC 854."
       SYNTAX OCTET STRING (SIZE (0..255))

   -- The basic applTable contains a list of the application
   -- entities.

   applTable OBJECT-TYPE
       SYNTAX SEQUENCE OF ApplEntry
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "The table holding objects which apply to all different
            kinds of applications providing network services.
            Each network service application capable of being
            monitored should have a single entry in this table."
       ::= {application 1}

   applEntry OBJECT-TYPE
       SYNTAX ApplEntry
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
         "An entry associated with a single network service
          application."
       INDEX {applIndex}
       ::= {applTable 1}

   ApplEntry ::= SEQUENCE {
       applIndex
           INTEGER,
       applName
           SnmpAdminString,
       applDirectoryName



Freed & Kille               Standards Track                     [Page 7]

RFC 2788            Network Services Monitoring MIB           March 2000


           DistinguishedName,
       applVersion
           SnmpAdminString,
       applUptime
           TimeStamp,
       applOperStatus
           INTEGER,
       applLastChange
           TimeStamp,
       applInboundAssociations
           Gauge32,
       applOutboundAssociations
           Gauge32,
       applAccumulatedInboundAssociations