home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1500s / rfc1565.txt < prev    next >
Text File  |  1994-01-09  |  30KB  |  955 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 S. Kille, WG Chair
  8. Request for Comments: 1565                              ISODE Consortium
  9. Category: Standards Track                               N. Freed, Editor
  10.                                                                 Innosoft
  11.                                                             January 1994
  12.  
  13.  
  14.                     Network Services Monitoring MIB
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Table of Contents
  25.  
  26.    1. Introduction ................................................. 2
  27.    2. The SNMPv2 Network Management Framework ...................... 2
  28.    2.1 Object Definitions .......................................... 3
  29.    3. Rationale for having a Network Services Monitoring MIB ....... 3
  30.    3.1 General Relationship to Other MIBs .......................... 4
  31.    3.2 Restriction of Scope ........................................ 4
  32.    3.3 Relationship to Directory Services .......................... 4
  33.    4. Application Objects .......................................... 5
  34.    5. Definitions .................................................. 6
  35.    6. Acknowledgements .............................................16
  36.    7. References ...................................................16
  37.    8. Security Considerations ......................................16
  38.    9. Authors' Addresses ...........................................17
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kille & Freed                                                   [Page 1]
  59.  
  60. RFC 1565            Network Services Monitoring MIB         January 1994
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    There are a wide range of networked applications for which it is
  66.    appropriate to provide SNMP Monitoring.  This includes both TCP/IP
  67.    and OSI applications.  This document defines a MIB which contains the
  68.    elements common to the monitoring of any network service application.
  69.    This information includes a table of all monitorable network service
  70.    applications, a count of the associations (connections) to each
  71.    application, and basic information about the parameters and status of
  72.    each application-related association.
  73.  
  74.    This MIB may be used on its own for any application, and for most
  75.    simple applications this will suffice.  This MIB is also designed to
  76.    serve as a building block which can be used in conjunction with
  77.    application-specific monitoring and management.  Two examples of this
  78.    are MIBs defining additional variables for monitoring a Message
  79.    Transfer Agent (MTA) service or a Directory Service Agent (DSA)
  80.    service. It is expected that further MIBs of this nature will be
  81.    specified.
  82.  
  83.    This MIB does not attempt to provide facilities for management of the
  84.    host or hosts the network service application runs on, nor does it
  85.    provide facilities for monitoring applications that provide something
  86.    other than a network service.  Host resource and general application
  87.    monitoring is handled by the Host Resources MIB.
  88.  
  89. 2.  The SNMPv2 Network Management Framework
  90.  
  91.    The SNMPv2 Network Management Framework consists of four major
  92.    components.  They are:
  93.  
  94.       o  RFC 1442 [1] which defines the SMI, the mechanisms used for
  95.          describing and naming objects for the purpose of management.
  96.  
  97.       o  STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
  98.          objects for the Internet suite of protocols.
  99.  
  100.       o  RFC 1445 [3] which defines the administrative and other
  101.          architectural aspects of the framework.
  102.  
  103.       o  RFC 1448 [4] which defines the protocol used for network
  104.          access to managed objects.
  105.  
  106.    The Framework permits new objects to be defined for the purpose of
  107.    experimentation and evaluation.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Kille & Freed                                                   [Page 2]
  115.  
  116. RFC 1565            Network Services Monitoring MIB         January 1994
  117.  
  118.  
  119. 2.1  Object Definitions
  120.  
  121.    Managed objects are accessed via a virtual information store, termed
  122.    the Management Information Base or MIB.  Objects in the MIB are
  123.    defined using the subset of Abstract Syntax Notation One (ASN.1)
  124.    defined in the SMI.  In particular, each object type is named by an
  125.    OBJECT IDENTIFIER, an administratively assigned name.  The object
  126.    type together with an object instance serves to uniquely identify a
  127.    specific instantiation of the object.  For human convenience, we
  128.    often use a textual string, termed the descriptor, to refer to the
  129.    object type.
  130.  
  131. 3.  Rationale for having a Network Services Monitoring MIB
  132.  
  133.    Much effort has been expended in developing tools to manage lower
  134.    layer network facilities.  However, relatively little work has been
  135.    done on managing application layer entities.  It is neither efficient
  136.    nor reasonable to manage all aspects of application layer entities
  137.    using only lower layer information.  Moreover, the difficulty of
  138.    managing application entities in this way increases dramatically as
  139.    application entities become more complex.
  140.  
  141.    This leads to a substantial need to monitor applications which
  142.    provide network services, particularly distributed components such as
  143.    MTAs and DSAs, by monitoring specific aspects of the application
  144.    itself.  Reasons to monitor such components include but are not
  145.    limited to measuring load, detecting broken connectivity, isolating
  146.    system failures, and locating congestion.
  147.  
  148.    In order to manage network service applications effectively two
  149.    requirements must be met:
  150.  
  151.       (1)  It must be possible to monitor a large number of components
  152.            (typical for a large organization).
  153.  
  154.       (2)  Application monitoring must be integrated into general
  155.            network management.
  156.  
  157.    This specification defines simple read-only access; this is
  158.    sufficient to determine up/down status and provide an indication of a
  159.    broad class of operational problems.
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kille & Freed                                                   [Page 3]
  171.  
  172. RFC 1565            Network Services Monitoring MIB         January 1994
  173.  
  174.  
  175. 3.1  General Relationship to Other MIBs
  176.  
  177.    This MIB is intended to only provide facilities common to the
  178.    monitoring of any network service application.  It does not provide
  179.    all the facilities necessary to monitor any specific application.
  180.    Each specific type of network service application is expected to have
  181.    a MIB of its own that makes use of these common facilities.
  182.  
  183. 3.2  Restriction of Scope
  184.  
  185.    The framework provided here is very minimal; there is a lot more that
  186.    could be done. For example:
  187.  
  188.    (1)  General network service application configuration monitoring and
  189.         control.
  190.  
  191.    (2)  Detailed examination and modification of individual entries in
  192.         service-specific request queues.
  193.  
  194.    (3)  Probing to determine the status of a specific request (e.g. the
  195.         location of a mail message with a specific message-id).
  196.  
  197.    (4)  Requesting that certain actions be performed (e.g. forcing an
  198.         immediate connection and transfer of pending messages to some
  199.         specific system).
  200.  
  201.    All these capabilities are both impressive and useful.  However,
  202.    these capabilities would require provisions for strict security
  203.    checking.  These capabilities would also mandate a much more complex
  204.    design, with many characteristics likely to be fairly
  205.    implementation-specific.  As a result such facilities are likely to
  206.    be both contentious and difficult to implement.
  207.  
  208.    This document religiously keeps things simple and focuses on the
  209.    basic monitoring aspect of managing applications providing network
  210.    services.  The goal here is to provide a framework which is simple,
  211.    useful, and widely implementable.
  212.  
  213. 3.3  Relationship to Directory Services
  214.  
  215.    Use of and management of directory services already is tied up with
  216.    network service application management.  There are clearly many
  217.    things which could be dealt with by directory services and protocols.
  218.    We take the line here that static configuration information is both
  219.    provided by and dealt with by directory services and protocols.  The
  220.    emphasis here is on transient application status.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Kille & Freed                                                   [Page 4]
  227.  
  228. RFC 1565            Network Services Monitoring MIB         January 1994
  229.  
  230.  
  231.    By placing static information in the directory, the richness and
  232.    linkage of the directory information framework does not need to be
  233.    repeated in the MIB.  Static information is information which has a
  234.    mean time to change of the order of days or longer.
  235.  
  236.    When information about network service applications is stored in the
  237.    directory (regardless of whether or not the network service
  238.    application makes direct use of the directory), it is recommended
  239.    that a linkage be established, so that:
  240.  
  241.    (1)  The managed object contains its own directory name.  This allows
  242.         all directory information to be obtained by reference.  This will
  243.         let a SNMP monitor capable of performing directory queries
  244.         present this information to the manager in an appropriate format.
  245.         It is intended that this will be the normal case.
  246.  
  247.    (2)  The directory will reference the location of the SNMP agent, so
  248.         that an SNMP capable directory query agent could probe dynamic
  249.         characteristics of the object.
  250.  
  251.    (3)  This approach could be extended further, so that the SNMP
  252.         attributes are modelled as directory attributes.  This would
  253.         dramatically simplify the design of directory service agents that
  254.         use SNMP to obtain the information they need.
  255.  
  256. 4.  Application Objects
  257.  
  258.    This MIB defines a set of general purpose attributes which would be
  259.    appropriate for a range of applications that provide network
  260.    services.  Both OSI and non-OSI services can be accomodated.
  261.    Additional tables defined in extensions to this MIB provide
  262.    attributes specific to specific network services.
  263.  
  264.    A table is defined which will have one row for each network service
  265.    application running on the system.  The only static information held
  266.    on the application is its name.  All other static information should
  267.    be obtained from various directory services.  The applDirectoryName
  268.    is an external key, which allows an SNMP MIB entry to be cleanly
  269.    related to the X.500 Directory.  In SNMP terms, the applications are
  270.    grouped in a table called applTable, which is indexed by an integer
  271.    key applIndex.
  272.  
  273.    The type of the application will be determined by one or both of:
  274.  
  275.    (1)  Additional MIB variables specific to the applications.
  276.  
  277.    (2)  An association to the application of a specific protocol.
  278.  
  279.  
  280.  
  281.  
  282. Kille & Freed                                                   [Page 5]
  283.  
  284. RFC 1565            Network Services Monitoring MIB         January 1994
  285.  
  286.  
  287. 5.  Definitions
  288.  
  289.    APPLICATION-MIB DEFINITIONS ::= BEGIN
  290.  
  291.    IMPORTS
  292.        OBJECT-TYPE, Counter32, Gauge32
  293.          FROM SNMPv2-SMI
  294.        mib-2
  295.          FROM RFC1213-MIB
  296.        DisplayString, TimeStamp
  297.          FROM SNMPv2-TC;
  298.  
  299.  
  300.    -- Textual conventions
  301.  
  302.    -- DistinguishedName [5] is used to refer to objects in the
  303.    -- directory.
  304.  
  305.    DistinguishedName ::= TEXTUAL-CONVENTION
  306.        STATUS current
  307.        DESCRIPTION
  308.            "A Distinguished Name represented in accordance with
  309.             RFC1485."
  310.        SYNTAX DisplayString
  311.  
  312.    application MODULE-IDENTITY
  313.        LAST-UPDATED "9311280000Z"
  314.        ORGANIZATION "IETF Mail and Directory Management Working Group"
  315.        CONTACT-INFO
  316.          "        Ned Freed
  317.  
  318.           Postal: Innosoft International, Inc.
  319.                   250 West First Street, Suite 240
  320.                   Claremont, CA  91711
  321.                   US
  322.  
  323.              Tel: +1 909 624 7907
  324.              Fax: +1 909 621 5319
  325.  
  326.           E-Mail: ned@innosoft.com"
  327.        DESCRIPTION
  328.          "The MIB module describing network service applications"
  329.        ::= { mib-2 27 }
  330.  
  331.    -- The basic applTable contains a list of the application
  332.    -- entities.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Kille & Freed                                                   [Page 6]
  339.  
  340. RFC 1565            Network Services Monitoring MIB         January 1994
  341.  
  342.  
  343.    applTable OBJECT-TYPE
  344.        SYNTAX SEQUENCE OF ApplEntry
  345.        MAX-ACCESS not-accessible
  346.        STATUS current
  347.        DESCRIPTION
  348.            "The table holding objects which apply to all different
  349.             kinds of applications providing network services."
  350.        ::= {application 1}
  351.  
  352.    applEntry OBJECT-TYPE
  353.        SYNTAX ApplEntry
  354.        MAX-ACCESS not-accessible
  355.        STATUS current
  356.        DESCRIPTION
  357.          "An entry associated with a network service application."
  358.        INDEX {applIndex}
  359.        ::= {applTable 1}
  360.  
  361.    ApplEntry ::= SEQUENCE {
  362.        applIndex
  363.            INTEGER,
  364.        applName
  365.            DisplayString,
  366.        applDirectoryName
  367.            DistinguishedName,
  368.        applVersion
  369.            DisplayString,
  370.        applUptime
  371.            TimeStamp,
  372.        applOperStatus
  373.            INTEGER,
  374.        applLastChange
  375.            TimeStamp,
  376.        applInboundAssociations
  377.            Gauge32,
  378.        applOutboundAssociations
  379.            Gauge32,
  380.        applAccumulatedInboundAssociations
  381.            Counter32,
  382.        applAccumulatedOutboundAssociations
  383.            Counter32,
  384.        applLastInboundActivity
  385.            TimeStamp,
  386.        applLastOutboundActivity
  387.            TimeStamp,
  388.        applRejectedInboundAssociations
  389.            Counter32,
  390.        applFailedOutboundAssociations
  391.  
  392.  
  393.  
  394. Kille & Freed                                                   [Page 7]
  395.  
  396. RFC 1565            Network Services Monitoring MIB         January 1994
  397.  
  398.  
  399.            Counter32
  400.    }
  401.  
  402.    applIndex OBJECT-TYPE
  403.        SYNTAX INTEGER (1..2147483647)
  404.        MAX-ACCESS not-accessible
  405.        STATUS current
  406.        DESCRIPTION
  407.          "An index to uniquely identify the network service
  408.           application."
  409.        ::= {applEntry 1}
  410.  
  411.    applName OBJECT-TYPE
  412.        SYNTAX DisplayString
  413.        MAX-ACCESS read-only
  414.        STATUS current
  415.        DESCRIPTION
  416.          "The name the network service application chooses to be
  417.           known by."
  418.        ::= {applEntry 2}
  419.  
  420.    applDirectoryName OBJECT-TYPE
  421.        SYNTAX DistinguishedName
  422.        MAX-ACCESS read-only
  423.        STATUS current
  424.        DESCRIPTION
  425.          "The Distinguished Name of the directory entry where
  426.           static information about this application is stored.
  427.           An empty string indicates that no information about
  428.           the application is available in the directory."
  429.        ::= {applEntry 3}
  430.  
  431.    applVersion OBJECT-TYPE
  432.        SYNTAX DisplayString
  433.        MAX-ACCESS read-only
  434.        STATUS current
  435.        DESCRIPTION
  436.          "The version of network service application software."
  437.        ::= {applEntry 4}
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Kille & Freed                                                   [Page 8]
  451.  
  452. RFC 1565            Network Services Monitoring MIB         January 1994
  453.  
  454.  
  455.    applUptime OBJECT-TYPE
  456.        SYNTAX TimeStamp
  457.        MAX-ACCESS read-only
  458.        STATUS current
  459.        DESCRIPTION
  460.          "The value of sysUpTime at the time the network service
  461.           application was last initialized.  If the application was
  462.           last initialized prior to the last initialization of the
  463.           network management subsystem, then this object contains
  464.           a zero value."
  465.        ::= {applEntry 5}
  466.  
  467.    applOperStatus OBJECT-TYPE
  468.        SYNTAX INTEGER {
  469.          up(1),
  470.          down(2),
  471.          halted(3),
  472.          congested(4),
  473.          restarting(5)
  474.        }
  475.        MAX-ACCESS read-only
  476.        STATUS current
  477.        DESCRIPTION
  478.          "Indicates the operational status of the network service
  479.           application. 'down' indicates that the network service is
  480.           not available. 'running' indicates that the network service
  481.           is operational and available.  'halted' indicates that the
  482.           service is operational but not available.  'congested'
  483.           indicates that the service is operational but no additional
  484.           inbound associations can be accomodated.  'restarting'
  485.           indicates that the service is currently unavailable but is
  486.           in the process of restarting and will be available soon."
  487.        ::= {applEntry 6}
  488.  
  489.    applLastChange OBJECT-TYPE
  490.        SYNTAX TimeStamp
  491.        MAX-ACCESS read-only
  492.        STATUS current
  493.        DESCRIPTION
  494.          "The value of sysUpTime at the time the network service
  495.           application entered its current operational state.  If
  496.           the current state was entered prior to the last
  497.           initialization of the local network management subsystem,
  498.           then this object contains a zero value."
  499.        ::= {applEntry 7}
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Kille & Freed                                                   [Page 9]
  507.  
  508. RFC 1565            Network Services Monitoring MIB         January 1994
  509.  
  510.  
  511.    applInboundAssociations OBJECT-TYPE
  512.        SYNTAX Gauge32
  513.        MAX-ACCESS read-only
  514.        STATUS current
  515.        DESCRIPTION
  516.          "The number of current associations to the network service
  517.           application, where it is the responder.  For dynamic single
  518.           threaded processes, this will be the number of application
  519.           instances."
  520.        ::= {applEntry 8}
  521.  
  522.    applOutboundAssociations OBJECT-TYPE
  523.        SYNTAX Gauge32
  524.        MAX-ACCESS read-only
  525.        STATUS current
  526.        DESCRIPTION
  527.          "The number of current associations to the network service
  528.           application, where it is the initiator.  For dynamic single
  529.           threaded processes, this will be the number of application
  530.           instances."
  531.        ::= {applEntry 9}
  532.  
  533.    applAccumulatedInboundAssociations OBJECT-TYPE
  534.        SYNTAX Counter32
  535.        MAX-ACCESS read-only
  536.        STATUS current
  537.        DESCRIPTION
  538.          "The total number of associations to the application entity
  539.           since application initialization, where it was the responder.
  540.           For  dynamic single threaded processes, this will be the
  541.           number of application instances."
  542.        ::= {applEntry 10}
  543.  
  544.    applAccumulatedOutboundAssociations OBJECT-TYPE
  545.        SYNTAX Counter32
  546.        MAX-ACCESS read-only
  547.        STATUS current
  548.        DESCRIPTION
  549.          "The total number of associations to the application entity
  550.           since application initialization, where it was the initiator.
  551.           For dynamic single threaded processes, this will be the
  552.           number of application instances."
  553.        ::= {applEntry 11}
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Kille & Freed                                                  [Page 10]
  563.  
  564. RFC 1565            Network Services Monitoring MIB         January 1994
  565.  
  566.  
  567.    applLastInboundActivity OBJECT-TYPE
  568.        SYNTAX TimeStamp
  569.        MAX-ACCESS read-only
  570.        STATUS current
  571.        DESCRIPTION
  572.          "The value of sysUpTime at the time this application last
  573.           had an inbound association.  If the last association
  574.           occurred prior to the last initialization of the network
  575.           subsystem, then this object contains a zero value."
  576.        ::= {applEntry 12}
  577.  
  578.    applLastOutboundActivity OBJECT-TYPE
  579.        SYNTAX TimeStamp
  580.        MAX-ACCESS read-only
  581.        STATUS current
  582.        DESCRIPTION
  583.          "The value of sysUpTime at the time this application last
  584.           had an outbound association.  If the last association
  585.           occurred prior to the last initialization of the network
  586.           subsystem, then this object contains a zero value."
  587.        ::= {applEntry 13}
  588.  
  589.    applRejectedInboundAssociations OBJECT-TYPE
  590.        SYNTAX Counter32
  591.        MAX-ACCESS read-only
  592.        STATUS current
  593.        DESCRIPTION
  594.          "The total number of inbound associations the application
  595.           entity has rejected, since application initialization."
  596.        ::= {applEntry 14}
  597.  
  598.    applFailedOutboundAssociations OBJECT-TYPE
  599.        SYNTAX Counter32
  600.        MAX-ACCESS read-only
  601.        STATUS current
  602.        DESCRIPTION
  603.          "The total number associations where the application entity
  604.           is initiator and association establishment has failed,
  605.           since application initialization."
  606.        ::= {applEntry 15}
  607.  
  608.  
  609.    -- The assocTable augments the information in the applTable
  610.    -- with information about associations.  Note that two levels
  611.    -- of compliance are specified below, depending on whether
  612.    -- association monitoring is mandated.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Kille & Freed                                                  [Page 11]
  619.  
  620. RFC 1565            Network Services Monitoring MIB         January 1994
  621.  
  622.  
  623.    assocTable OBJECT-TYPE
  624.        SYNTAX SEQUENCE OF AssocEntry
  625.        MAX-ACCESS not-accessible
  626.        STATUS current
  627.        DESCRIPTION
  628.            "The table holding a set of all active application
  629.             associations."
  630.        ::= {application 2}
  631.  
  632.    assocEntry OBJECT-TYPE
  633.        SYNTAX AssocEntry
  634.        MAX-ACCESS not-accessible
  635.        STATUS current
  636.        DESCRIPTION
  637.          "An entry associated with an association for a network
  638.           service application."
  639.        INDEX {applIndex, assocIndex}
  640.        ::= {assocTable 1}
  641.  
  642.    AssocEntry ::= SEQUENCE {
  643.        assocIndex
  644.            INTEGER,
  645.        assocRemoteApplication
  646.            DisplayString,
  647.        assocApplicationProtocol
  648.            OBJECT IDENTIFIER,
  649.        assocApplicationType
  650.            INTEGER,
  651.        assocDuration
  652.            TimeStamp
  653.    }
  654.  
  655.    assocIndex OBJECT-TYPE
  656.        SYNTAX INTEGER (1..2147483647)
  657.        MAX-ACCESS not-accessible
  658.        STATUS current
  659.        DESCRIPTION
  660.          "An index to uniquely identify each association for a network
  661.           service application."
  662.        ::= {assocEntry 1}
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Kille & Freed                                                  [Page 12]
  675.  
  676. RFC 1565            Network Services Monitoring MIB         January 1994
  677.  
  678.  
  679.    assocRemoteApplication OBJECT-TYPE
  680.        SYNTAX DisplayString
  681.        MAX-ACCESS read-only
  682.        STATUS current
  683.        DESCRIPTION
  684.          "The name of the system running remote network service
  685.           application.  For an IP-based application this should be
  686.           either a domain name or IP address.  For an OSI application
  687.           it should be the string encoded distinguished name of the
  688.           managed object.  For X.400(84) MTAs which do not have a
  689.           Distinguished Name, the RFC1327 [6] syntax
  690.           'mta in globalid' should be used."
  691.        ::= {assocEntry 2}
  692.  
  693.    assocApplicationProtocol OBJECT-TYPE
  694.        SYNTAX OBJECT IDENTIFIER
  695.        MAX-ACCESS read-only
  696.        STATUS current
  697.        DESCRIPTION
  698.          "An identification of the protocol being used for the
  699.           application.  For an OSI Application, this will be the
  700.           Application Context.  For Internet applications, the IANA
  701.           maintains a registry of the OIDs which correspond to
  702.           well-known applications.  If the application protocol is
  703.           not listed in the registry, an OID value of the form
  704.           {applTCPProtoID port} or {applUDProtoID port} are used for
  705.           TCP-based and UDP-based protocols, respectively. In either
  706.           case 'port' corresponds to the primary port number being
  707.           used by the protocol."
  708.        ::= {assocEntry 3}
  709.  
  710.    assocApplicationType OBJECT-TYPE
  711.        SYNTAX INTEGER {
  712.            ua-initiator(1),
  713.            ua-responder(2),
  714.            peer-initiator(3),
  715.            peer-responder(4)}
  716.        MAX-ACCESS read-only
  717.        STATUS current
  718.        DESCRIPTION
  719.          "This indicates whether the remote application is some type of
  720.           client making use of this network service (e.g. a User Agent)
  721.           or a server acting as a peer. Also indicated is whether the
  722.           remote end initiated an incoming connection to the network
  723.           service or responded to an outgoing connection made by the
  724.           local application."
  725.        ::= {assocEntry 4}
  726.  
  727.  
  728.  
  729.  
  730. Kille & Freed                                                  [Page 13]
  731.  
  732. RFC 1565            Network Services Monitoring MIB         January 1994
  733.  
  734.  
  735.    assocDuration OBJECT-TYPE
  736.        SYNTAX TimeStamp
  737.        MAX-ACCESS read-only
  738.        STATUS current
  739.        DESCRIPTION
  740.          "The value of sysUpTime at the time this association was
  741.           started.  If this association started prior to the last
  742.           initialization of the network subsystem, then this
  743.           object contains a zero value."
  744.        ::= {assocEntry 5}
  745.  
  746.  
  747.    -- Conformance information
  748.  
  749.    applConformance OBJECT IDENTIFIER ::= {application 3}
  750.  
  751.    applGroups      OBJECT IDENTIFIER ::= {applConformance 1}
  752.    applCompliances OBJECT IDENTIFIER ::= {applConformance 2}
  753.  
  754.  
  755.    -- Compliance statements
  756.  
  757.    applCompliance MODULE-COMPLIANCE
  758.        STATUS current
  759.        DESCRIPTION
  760.          "The compliance statement for SNMPv2 entities
  761.           which implement the Network Services Monitoring MIB
  762.           for basic monitoring of network service applications."
  763.        MODULE  -- this module
  764.          MANDATORY-GROUPS {applGroup}
  765.        ::= {applCompliances 1}
  766.  
  767.    assocCompliance MODULE-COMPLIANCE
  768.        STATUS current
  769.        DESCRIPTION
  770.          "The compliance statement for SNMPv2 entities which
  771.           implement the Network Services Monitoring MIB for basic
  772.           monitoring of network service applications and their
  773.           associations."
  774.        MODULE  -- this module
  775.          MANDATORY-GROUPS {applGroup, assocGroup}
  776.        ::= {applCompliances 2}
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Kille & Freed                                                  [Page 14]
  787.  
  788. RFC 1565            Network Services Monitoring MIB         January 1994
  789.  
  790.  
  791.    -- Units of conformance
  792.  
  793.    applGroup OBJECT-GROUP
  794.        OBJECTS {
  795.          applName, applVersion, applUptime, applOperStatus,
  796.          applLastChange, applInboundAssociations,
  797.          applOutboundAssociations, applAccumulatedInboundAssociations,
  798.          applAccumulatedOutboundAssociations, applLastInboundActivity,
  799.          applLastOutboundActivity, applRejectedInboundAssociations,
  800.          applFailedOutboundAssociations}
  801.        STATUS current
  802.        DESCRIPTION
  803.          "A collection of objects providing basic monitoring of
  804.           network service applications."
  805.        ::= {applGroups 1}
  806.  
  807.    assocGroup OBJECT-GROUP
  808.        OBJECTS {
  809.          assocRemoteApplication, assocApplicationProtocol,
  810.          assocApplicationType, assocDuration}
  811.        STATUS current
  812.        DESCRIPTION
  813.          "A collection of objects providing basic monitoring of
  814.           network service applications' associations."
  815.        ::= {applGroups 2}
  816.  
  817.  
  818.    -- OIDs of the form {applTCPProtoID port} are intended to be used
  819.    -- for TCP-based protocols that don't have OIDs assigned by other
  820.    -- means. {applUDPProtoID port} serves the same purpose for
  821.    -- UDP-based protocols. In either case 'port' corresponds to
  822.    -- the primary port number being used by the protocol. For example,
  823.    -- assuming no other OID is assigned for SMTP, an OID of
  824.    -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based
  825.    -- protocol that uses port 25 as its primary port.
  826.  
  827.    applTCPProtoID OBJECT IDENTIFIER ::= {application 4}
  828.    applUDPProtoID OBJECT IDENTIFIER ::= {application 5}
  829.  
  830.    END
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Kille & Freed                                                  [Page 15]
  843.  
  844. RFC 1565            Network Services Monitoring MIB         January 1994
  845.  
  846.  
  847. 6.  Acknowledgements
  848.  
  849.    This document is a product of the Mail and Directory Management
  850.    (MADMAN) Working Group. It is based on an earlier MIB designed by S.
  851.    Kille, T.  Lenggenhager, D. Partain, and W. Yeong.
  852.  
  853. 7.  References
  854.  
  855.   [1]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
  856.        of Management Information for version 2 of the Simple Network
  857.        Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
  858.        Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  859.        University, April 1993.
  860.  
  861.   [2]  McCloghrie, K., and M. Rose, Editors, "Management Information
  862.        Base for Network Management of TCP/IP-based internets: MIB-II",
  863.        STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
  864.        International, March 1991.
  865.  
  866.   [2]  Galvin, J., and K. McCloghrie, "Administrative Model for version
  867.        2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
  868.        Trusted Information Systems, Hughes LAN Systems, April 1993.
  869.  
  870.   [4]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
  871.        Operations for version 2 of the Simple Network Management
  872.        Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
  873.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  874.        University, April 1993.
  875.  
  876.   [5]  Kille, S., "A String Representation of Distinguished Names", RFC
  877.        1485, ISODE Consortium, July 1993.
  878.  
  879.   [6]  Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC822",
  880.        RFC 1327, University College London, May 1992.
  881.  
  882. 8.  Security Considerations
  883.  
  884.    Security issues are not discussed in this memo.
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Kille & Freed                                                  [Page 16]
  899.  
  900. RFC 1565            Network Services Monitoring MIB         January 1994
  901.  
  902.  
  903. Authors' Addresses
  904.  
  905.    Steve Kille, WG Chair
  906.    ISODE Consortium
  907.    The Dome, The Square
  908.    Richmond TW9 1DT
  909.    UK
  910.  
  911.    Phone: +44 81 332 9091
  912.    EMail: S.Kille@isode.com
  913.  
  914.  
  915.    Ned Freed, Editor
  916.    Innosoft International, Inc.
  917.    250 West First Street, Suite 240
  918.    Claremont, CA 91711
  919.    USA
  920.  
  921.    Phone: +1 909 624 7907
  922.    Fax: +1 909 621 5319
  923.    EMail: ned@innosoft.com
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Kille & Freed                                                  [Page 17]
  955.