rfc2248.txt

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

Network Working Group                                         N. Freed
Request for Comments: 2248                                    Innosoft
Obsoletes: 1565                                               S. Kille
Category: Standards Track                             ISODE Consortium
                                                          January 1998


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

1.  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 2248                  Network Services MIB              January 1998


   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 the Host Resources MIB at present;
   development of an additional application MIB is currently underway in
   the IETF.

2.  Table of Contents

   1 Introduction ...............................................    1
   2 Table of Contents ..........................................    2
   3 The SNMPv2 Network Management Framework ....................    2
   3.1 Object Definitions .......................................    3
   4 Rationale for having a Network Services Monitoring MIB .....    3
   4.1 General Relationship to Other MIBs .......................    4
   4.2 Restriction of Scope .....................................    4
   4.3 Configuration Information ................................    4
   5 Application Objects ........................................    5
   6 Definitions ................................................    5
   7 Changes made since RFC 1565 ................................   16
   8 Acknowledgements ...........................................   16
   9 References .................................................   16
   10 Security Considerations ...................................   17
   11 Author and Chair Addresses ................................   18
   12 Full Copyright Statement ..................................   19

3.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of seven major
   components.  They are:

   o    RFC 1902 [1] which defines the SMI, the mechanisms used for
        describing and naming objects for the purpose of management.

   o    RFC 1903 [2] defines textual conventions for SNMPv2.

   o    RFC 1904 [3] defines conformance statements for SNMPv2.

   o    RFC 1905 [4] defines  transport mappings for SNMPv2.

   o    RFC 1906 [5] defines the protocol operations used for network
        access to managed objects.

   o    RFC 1907 [6] defines the Management Information Base for SNMPv2.

   o    RFC 1908 [7] specifies coexistance between SNMP and SNMPv2.




Freed & Kille               Standards Track                     [Page 2]

RFC 2248                  Network Services MIB              January 1998


   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

3.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB. Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name. The object type
   together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to refer to the
   object type.

4.  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).

    (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.







Freed & Kille               Standards Track                     [Page 3]

RFC 2248                  Network Services MIB              January 1998


4.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.

4.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.

4.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.






Freed & Kille               Standards Track                     [Page 4]

RFC 2248                  Network Services MIB              January 1998


5.  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 accomodated.
   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.

6.  Definitions

    NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN

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

application MODULE-IDENTITY
    LAST-UPDATED "9708170000Z"
    ORGANIZATION "IETF Mail and Directory Management Working Group"
    CONTACT-INFO
      "        Ned Freed

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

          Tel: [phone]
          Fax: [phone]



Freed & Kille               Standards Track                     [Page 5]

RFC 2248                  Network Services MIB              January 1998


       E-Mail: [e-mail]"
    DESCRIPTION
      "The MIB module describing network service applications"
    REVISION "9311280000Z"
    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
    STATUS current
    DESCRIPTION
        "A Distinguished Name represented in accordance with
         RFC 1779 [8]."
    SYNTAX DisplayString

-- Uniform Resource Locators are stored in URLStrings.

URLString ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
        "A Uniform Resource Locator represented in accordance
         with RFC 1738 [10]."
    SYNTAX DisplayString

-- 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



Freed & Kille               Standards Track                     [Page 6]

RFC 2248                  Network Services MIB              January 1998


      "An entry associated with a single network service
       application."
    INDEX {applIndex}
    ::= {applTable 1}

ApplEntry ::= SEQUENCE {
    applIndex
        INTEGER,
    applName
        DisplayString,
    applDirectoryName
        DistinguishedName,
    applVersion
        DisplayString,