From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1565.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc1565.txt (limited to 'doc/rfc/rfc1565.txt') diff --git a/doc/rfc/rfc1565.txt b/doc/rfc/rfc1565.txt new file mode 100644 index 0000000..976e40a --- /dev/null +++ b/doc/rfc/rfc1565.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Kille, WG Chair +Request for Comments: 1565 ISODE Consortium +Category: Standards Track N. Freed, Editor + Innosoft + January 1994 + + + 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. + +Table of Contents + + 1. Introduction ................................................. 2 + 2. The SNMPv2 Network Management Framework ...................... 2 + 2.1 Object Definitions .......................................... 3 + 3. Rationale for having a Network Services Monitoring MIB ....... 3 + 3.1 General Relationship to Other MIBs .......................... 4 + 3.2 Restriction of Scope ........................................ 4 + 3.3 Relationship to Directory Services .......................... 4 + 4. Application Objects .......................................... 5 + 5. Definitions .................................................. 6 + 6. Acknowledgements .............................................16 + 7. References ...................................................16 + 8. Security Considerations ......................................16 + 9. Authors' Addresses ...........................................17 + + + + + + + + + + + + + + + + + + + +Kille & Freed [Page 1] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +1. Introduction + + There are a wide range of networked applications for which it is + appropriate to provide SNMP Monitoring. This includes both TCP/IP + and OSI applications. 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. + + 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. + +2. The SNMPv2 Network Management Framework + + The SNMPv2 Network Management Framework consists of four major + components. They are: + + o RFC 1442 [1] which defines the SMI, the mechanisms used for + describing and naming objects for the purpose of management. + + o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed + objects for the Internet suite of protocols. + + o RFC 1445 [3] which defines the administrative and other + architectural aspects of the framework. + + o RFC 1448 [4] which defines the protocol used for network + access to managed objects. + + The Framework permits new objects to be defined for the purpose of + experimentation and evaluation. + + + + + + +Kille & Freed [Page 2] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +2.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. + +3. 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. + + + + + + + + + + +Kille & Freed [Page 3] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +3.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. + +3.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. + +3.3 Relationship to Directory Services + + Use of and management of directory services already is tied up with + network service application management. There are clearly many + things which could be dealt with by directory services and protocols. + We take the line here that static configuration information is both + provided by and dealt with by directory services and protocols. The + emphasis here is on transient application status. + + + + + +Kille & Freed [Page 4] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + By placing static information in the directory, the richness and + linkage of the directory information framework does not need to be + repeated in the MIB. Static information is information which has a + mean time to change of the order of days or longer. + + When information about network service applications is stored in the + directory (regardless of whether or not the network service + application makes direct use of the directory), it is recommended + that a linkage be established, so that: + + (1) The managed object contains its own directory name. This allows + all directory information to be obtained by reference. This will + let a SNMP monitor capable of performing directory queries + present this information to the manager in an appropriate format. + It is intended that this will be the normal case. + + (2) The directory will reference the location of the SNMP agent, so + that an SNMP capable directory query agent could probe dynamic + characteristics of the object. + + (3) This approach could be extended further, so that the SNMP + attributes are modelled as directory attributes. This would + dramatically simplify the design of directory service agents that + use SNMP to obtain the information they need. + +4. 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 network service + application running 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. + + + + +Kille & Freed [Page 5] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +5. Definitions + + APPLICATION-MIB DEFINITIONS ::= BEGIN + + IMPORTS + OBJECT-TYPE, Counter32, Gauge32 + FROM SNMPv2-SMI + mib-2 + FROM RFC1213-MIB + DisplayString, TimeStamp + FROM SNMPv2-TC; + + + -- Textual conventions + + -- DistinguishedName [5] is used to refer to objects in the + -- directory. + + DistinguishedName ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A Distinguished Name represented in accordance with + RFC1485." + SYNTAX DisplayString + + application MODULE-IDENTITY + LAST-UPDATED "9311280000Z" + ORGANIZATION "IETF Mail and Directory Management Working Group" + CONTACT-INFO + " Ned Freed + + Postal: Innosoft International, Inc. + 250 West First Street, Suite 240 + Claremont, CA 91711 + US + + Tel: +1 909 624 7907 + Fax: +1 909 621 5319 + + E-Mail: ned@innosoft.com" + DESCRIPTION + "The MIB module describing network service applications" + ::= { mib-2 27 } + + -- The basic applTable contains a list of the application + -- entities. + + + + + +Kille & Freed [Page 6] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + 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." + ::= {application 1} + + applEntry OBJECT-TYPE + SYNTAX ApplEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry associated with a network service application." + INDEX {applIndex} + ::= {applTable 1} + + ApplEntry ::= SEQUENCE { + applIndex + INTEGER, + applName + DisplayString, + applDirectoryName + DistinguishedName, + applVersion + DisplayString, + applUptime + TimeStamp, + applOperStatus + INTEGER, + applLastChange + TimeStamp, + applInboundAssociations + Gauge32, + applOutboundAssociations + Gauge32, + applAccumulatedInboundAssociations + Counter32, + applAccumulatedOutboundAssociations + Counter32, + applLastInboundActivity + TimeStamp, + applLastOutboundActivity + TimeStamp, + applRejectedInboundAssociations + Counter32, + applFailedOutboundAssociations + + + +Kille & Freed [Page 7] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + Counter32 + } + + applIndex OBJECT-TYPE + SYNTAX INTEGER (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index to uniquely identify the network service + application." + ::= {applEntry 1} + + applName OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The name the network service application chooses to be + known by." + ::= {applEntry 2} + + applDirectoryName OBJECT-TYPE + SYNTAX DistinguishedName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Distinguished Name of the directory entry where + static information about this application is stored. + An empty string indicates that no information about + the application is available in the directory." + ::= {applEntry 3} + + applVersion OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The version of network service application software." + ::= {applEntry 4} + + + + + + + + + + + + +Kille & Freed [Page 8] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + applUptime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time the network service + application was last initialized. If the application was + last initialized prior to the last initialization of the + network management subsystem, then this object contains + a zero value." + ::= {applEntry 5} + + applOperStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), + down(2), + halted(3), + congested(4), + restarting(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the operational status of the network service + application. 'down' indicates that the network service is + not available. 'running' indicates that the network service + is operational and available. 'halted' indicates that the + service is operational but not available. 'congested' + indicates that the service is operational but no additional + inbound associations can be accomodated. 'restarting' + indicates that the service is currently unavailable but is + in the process of restarting and will be available soon." + ::= {applEntry 6} + + applLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time the network service + application entered its current operational state. If + the current state was entered prior to the last + initialization of the local network management subsystem, + then this object contains a zero value." + ::= {applEntry 7} + + + + + + +Kille & Freed [Page 9] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + applInboundAssociations OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of current associations to the network service + application, where it is the responder. For dynamic single + threaded processes, this will be the number of application + instances." + ::= {applEntry 8} + + applOutboundAssociations OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of current associations to the network service + application, where it is the initiator. For dynamic single + threaded processes, this will be the number of application + instances." + ::= {applEntry 9} + + applAccumulatedInboundAssociations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of associations to the application entity + since application initialization, where it was the responder. + For dynamic single threaded processes, this will be the + number of application instances." + ::= {applEntry 10} + + applAccumulatedOutboundAssociations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of associations to the application entity + since application initialization, where it was the initiator. + For dynamic single threaded processes, this will be the + number of application instances." + ::= {applEntry 11} + + + + + + + + +Kille & Freed [Page 10] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + applLastInboundActivity OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this application last + had an inbound association. If the last association + occurred prior to the last initialization of the network + subsystem, then this object contains a zero value." + ::= {applEntry 12} + + applLastOutboundActivity OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this application last + had an outbound association. If the last association + occurred prior to the last initialization of the network + subsystem, then this object contains a zero value." + ::= {applEntry 13} + + applRejectedInboundAssociations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of inbound associations the application + entity has rejected, since application initialization." + ::= {applEntry 14} + + applFailedOutboundAssociations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number associations where the application entity + is initiator and association establishment has failed, + since application initialization." + ::= {applEntry 15} + + + -- The assocTable augments the information in the applTable + -- with information about associations. Note that two levels + -- of compliance are specified below, depending on whether + -- association monitoring is mandated. + + + + + +Kille & Freed [Page 11] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + assocTable OBJECT-TYPE + SYNTAX SEQUENCE OF AssocEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table holding a set of all active application + associations." + ::= {application 2} + + assocEntry OBJECT-TYPE + SYNTAX AssocEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry associated with an association for a network + service application." + INDEX {applIndex, assocIndex} + ::= {assocTable 1} + + AssocEntry ::= SEQUENCE { + assocIndex + INTEGER, + assocRemoteApplication + DisplayString, + assocApplicationProtocol + OBJECT IDENTIFIER, + assocApplicationType + INTEGER, + assocDuration + TimeStamp + } + + assocIndex OBJECT-TYPE + SYNTAX INTEGER (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index to uniquely identify each association for a network + service application." + ::= {assocEntry 1} + + + + + + + + + + + +Kille & Freed [Page 12] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + assocRemoteApplication OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The name of the system running remote network service + application. For an IP-based application this should be + either a domain name or IP address. For an OSI application + it should be the string encoded distinguished name of the + managed object. For X.400(84) MTAs which do not have a + Distinguished Name, the RFC1327 [6] syntax + 'mta in globalid' should be used." + ::= {assocEntry 2} + + assocApplicationProtocol OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An identification of the protocol being used for the + application. For an OSI Application, this will be the + Application Context. For Internet applications, the IANA + maintains a registry of the OIDs which correspond to + well-known applications. If the application protocol is + not listed in the registry, an OID value of the form + {applTCPProtoID port} or {applUDProtoID port} are used for + TCP-based and UDP-based protocols, respectively. In either + case 'port' corresponds to the primary port number being + used by the protocol." + ::= {assocEntry 3} + + assocApplicationType OBJECT-TYPE + SYNTAX INTEGER { + ua-initiator(1), + ua-responder(2), + peer-initiator(3), + peer-responder(4)} + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates whether the remote application is some type of + client making use of this network service (e.g. a User Agent) + or a server acting as a peer. Also indicated is whether the + remote end initiated an incoming connection to the network + service or responded to an outgoing connection made by the + local application." + ::= {assocEntry 4} + + + + +Kille & Freed [Page 13] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + assocDuration OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this association was + started. If this association started prior to the last + initialization of the network subsystem, then this + object contains a zero value." + ::= {assocEntry 5} + + + -- Conformance information + + applConformance OBJECT IDENTIFIER ::= {application 3} + + applGroups OBJECT IDENTIFIER ::= {applConformance 1} + applCompliances OBJECT IDENTIFIER ::= {applConformance 2} + + + -- Compliance statements + + applCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMPv2 entities + which implement the Network Services Monitoring MIB + for basic monitoring of network service applications." + MODULE -- this module + MANDATORY-GROUPS {applGroup} + ::= {applCompliances 1} + + assocCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement the Network Services Monitoring MIB for basic + monitoring of network service applications and their + associations." + MODULE -- this module + MANDATORY-GROUPS {applGroup, assocGroup} + ::= {applCompliances 2} + + + + + + + + + +Kille & Freed [Page 14] + +RFC 1565 Network Services Monitoring MIB January 1994 + + + -- Units of conformance + + applGroup OBJECT-GROUP + OBJECTS { + applName, applVersion, applUptime, applOperStatus, + applLastChange, applInboundAssociations, + applOutboundAssociations, applAccumulatedInboundAssociations, + applAccumulatedOutboundAssociations, applLastInboundActivity, + applLastOutboundActivity, applRejectedInboundAssociations, + applFailedOutboundAssociations} + STATUS current + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications." + ::= {applGroups 1} + + assocGroup OBJECT-GROUP + OBJECTS { + assocRemoteApplication, assocApplicationProtocol, + assocApplicationType, assocDuration} + STATUS current + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications' associations." + ::= {applGroups 2} + + + -- OIDs of the form {applTCPProtoID port} are intended to be used + -- for TCP-based protocols that don't have OIDs assigned by other + -- means. {applUDPProtoID port} serves the same purpose for + -- UDP-based protocols. In either case 'port' corresponds to + -- the primary port number being used by the protocol. For example, + -- assuming no other OID is assigned for SMTP, an OID of + -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based + -- protocol that uses port 25 as its primary port. + + applTCPProtoID OBJECT IDENTIFIER ::= {application 4} + applUDPProtoID OBJECT IDENTIFIER ::= {application 5} + + END + + + + + + + + + + + +Kille & Freed [Page 15] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +6. Acknowledgements + + This document is a product of the Mail and Directory Management + (MADMAN) Working Group. It is based on an earlier MIB designed by S. + Kille, T. Lenggenhager, D. Partain, and W. Yeong. + +7. References + + [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure + of Management Information for version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., + Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon + University, April 1993. + + [2] McCloghrie, K., and M. Rose, Editors, "Management Information + Base for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, Hughes LAN Systems, Performance Systems + International, March 1991. + + [2] Galvin, J., and K. McCloghrie, "Administrative Model for version + 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, + Trusted Information Systems, Hughes LAN Systems, April 1993. + + [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol + Operations for version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN + Systems, Dover Beach Consulting, Inc., Carnegie Mellon + University, April 1993. + + [5] Kille, S., "A String Representation of Distinguished Names", RFC + 1485, ISODE Consortium, July 1993. + + [6] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC822", + RFC 1327, University College London, May 1992. + +8. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + +Kille & Freed [Page 16] + +RFC 1565 Network Services Monitoring MIB January 1994 + + +Authors' Addresses + + Steve Kille, WG Chair + ISODE Consortium + The Dome, The Square + Richmond TW9 1DT + UK + + Phone: +44 81 332 9091 + EMail: S.Kille@isode.com + + + Ned Freed, Editor + Innosoft International, Inc. + 250 West First Street, Suite 240 + Claremont, CA 91711 + USA + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + EMail: ned@innosoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille & Freed [Page 17] + \ No newline at end of file -- cgit v1.2.3