Network Services Monitoring MIB
obsoleted by
- rfc-2248 — Network Services Monitoring MIB
Extracted elements (22)
Static configuration information (with a mean time to change of days or longer) is delegated to directory services rather than stored in the MIB. The MIB focuses on transient application status only, with applDirectoryName providing a linkage key to the corresponding X.500 directory entry.
The MIB is deliberately restricted to simple read-only access. Write capabilities, queue management, request probing, and forced-action capabilities were excluded because they would require strict security checking, mandate complex implementation-specific designs, and be contentious and difficult to implement.
The MIB is designed as a building block for application-specific MIBs (e.g., MTA or DSA monitoring MIBs). Each specific network service type is expected to define its own MIB that extends these common facilities, rather than encoding all attributes in a single monolithic MIB.
This MIB was created because little work had been done on managing application layer entities, and it is neither efficient nor reasonable to manage all aspects of application layer entities using only lower layer information. The difficulty of managing application entities increases dramatically as they become more complex.
The MIB supports both TCP/IP and OSI network service applications within the same framework. Protocol identification, remote application naming, and directory linkage all carry OSI-specific encodings (Application Context OIDs, Distinguished Names, X.400 MTA syntax) alongside IP-based conventions.
Implementations providing association-level monitoring must comply with assocCompliance, which mandates both applGroup and assocGroup (assocRemoteApplication, assocApplicationProtocol, assocApplicationType, assocDuration). Association monitoring is thus an optional but defined compliance tier above basic monitoring.
Implementations providing basic application monitoring must comply with applCompliance, which mandates the applGroup (applName, applVersion, applUptime, applOperStatus, applLastChange, association counters, activity timestamps, and rejection/failure counters).
applAccumulatedInboundAssociations and applAccumulatedOutboundAssociations are Counter32 objects tracking the total number of inbound and outbound associations respectively since application initialization.
applDirectoryName is a DistinguishedName (DisplayString encoding per RFC 1485) holding the X.500 Distinguished Name of the directory entry for static application information. An empty string indicates no directory entry is available.
applInboundAssociations (Gauge32) counts current associations where the application is the responder; applOutboundAssociations (Gauge32) counts current associations where it is the initiator. For dynamic single-threaded processes these equal the number of running application instances.
applIndex is an INTEGER (1..2147483647) that uniquely identifies a network service application within applTable. It is not accessible externally and serves only as the table index.
applRejectedInboundAssociations (Counter32) counts total inbound associations the application has rejected since initialization; applFailedOutboundAssociations (Counter32) counts total outbound association establishment failures since initialization.
applTable (OID mib-2.27.1) holds one row per network service application running on the system. It is indexed by applIndex and carries name, directory name, version, uptime, operational status, last-change timestamp, inbound/outbound association counters, activity timestamps, and rejection/failure counters.
applUptime is a TimeStamp holding the value of sysUpTime at the time the application was last initialized. A zero value indicates the application was initialized prior to the last initialization of the network management subsystem.
assocApplicationProtocol is an OBJECT IDENTIFIER identifying the protocol in use. For OSI applications it is the Application Context OID. For Internet applications, the IANA registry is used; if unregistered, the forms {applTCPProtoID port} or {applUDPProtoID port} are used instead.
assocApplicationType is an INTEGER with four values: ua-initiator(1), ua-responder(2), peer-initiator(3), peer-responder(4), indicating whether the remote application is a user-agent client or a peer server and whether it initiated or responded to the connection.
assocDuration is a TimeStamp holding the sysUpTime value when the association was started. A zero value indicates the association predates the last initialization of the network management subsystem.
assocRemoteApplication (DisplayString) identifies the remote end of an association. For IP applications this should be a domain name or IP address; for OSI applications a string-encoded Distinguished Name; for X.400(84) MTAs without a DN, the RFC 1327 'mta in globalid' syntax is used.
assocTable (OID mib-2.27.2) holds one row per active association, indexed by {applIndex, assocIndex}. Each row carries the remote application name, application protocol OID, association type (ua/peer × initiator/responder), and association start timestamp.
applTCPProtoID (mib-2.27.4) and applUDPProtoID (mib-2.27.5) are OID subtrees used to construct protocol identifiers for TCP-based and UDP-based applications respectively that have not been assigned OIDs by other means. The form {applTCPProtoID port} identifies a TCP protocol by its primary port number (e.g., SMTP would be {applTCPProtoID 25}).
The RFC explicitly states that security issues are not discussed in this memo. The MIB is read-only, which the authors note in Section 3.2 as a deliberate design choice that avoids the need for strict security checking that write or control operations would require.
applOperStatus defines five operational states for a network service application: up(1) — available; down(2) — not available; halted(3) — operational but not accepting requests; congested(4) — operational but no additional inbound associations can be accommodated; restarting(5) — temporarily unavailable but coming back.