rfc-2564

Application Management MIB

C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia
date1999-05 streamIETF areaapp wgapplmib statusPROPOSED STANDARD pages86 canonicalhttps://www.rfc-editor.org/rfc/rfc2564 doi10.17487/RFC2564
This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]

Extracted elements (30)

design-rationale §4.1

A 'service' is explicitly distinguished from a 'protocol': a service is identified by an associated set of resources and a reasonably long-lived server or client process, so SMTP and HTTP providers are appropriate candidates while transient services like finger typically are not.

design-rationale §4

Both 64-bit (Counter64) and companion 32-bit (Counter32, reporting the low-order 32 bits) counters are defined for rapidly-advancing counters to support SNMPv1 and SNMPv2 environments that do not natively handle Counter64.

snmp

design-rationale §4

Per-row discontinuity indicators (e.g., applOpenChannelOpenTime) are used instead of sysUpTime.0 because table rows come and go with running application elements; a row appearing or disappearing does not imply a sysUpTime.0 discontinuity, nor vice versa.

snmp

design-rationale §4.2

The applElmtOrSvc discriminator index is introduced so that the same I/O channel and transaction tables can record information either per running-application-element or per service-instance without duplicating table definitions.

snmp

design-rationale §1

The System Application MIB deliberately avoided requiring application instrumentation; this MIB extends that framework with attributes that typically require cooperation from the managed software itself, covering throughput, response time, I/O channels, file usage, and application control.

snmp

interoperability-note §3.1.3

Due to differences in index representation between the Network Services Monitoring MIB (NSM) and this MIB, the relationship between them is not formally defined, even though both address management of network application services.

snmp

interoperability-note §2

The MIB is SMIv2-compliant; a semantically-equivalent SMIv1 translation can be produced, except that Counter64 objects cannot be translated and must be omitted, and machine-readable SMIv2 annotations are converted to textual descriptions.

snmp

normative-requirement §5 MUST

If the transport protocol for an open connection cannot practically be determined, applOpenConnectionTransport shall be {0 0} (zeroDotZero); similarly, applOpenConnectionFarEndAddr and applOpenConnectionFarEndpoint shall be zero-length strings if unknown.

snmp

normative-requirement §3.1.1 MUST

Implementations of this MIB and the System Application MIB running concurrently on the same platform must employ a consistent policy for assigning sysApplRunElmtIndex values to identify running application elements.

snmp

normative-requirement §4.1 SHOULD NOT

Service instance identifier values (applSrvIndex) must be constant for the lifetime of the service instance; re-use of values should be avoided, and no two concurrent service instances in a system shall share the same index value. The value zero is excluded.

snmp

normative-requirement §5 SHOULD

Service name strings (applSrvName) should use established IANA-assigned names (STD 2) where a service can be identified in terms of a single protocol; private conventions may apply otherwise, and an applicability statement may specify the names to use.

registry, snmp

normative-requirement §3.1.2 MUST

The values assigned to hrSWRunIndex in the Host Resources MIB must be consistent with the values used for sysApplElmtRunIndex in this MIB and the System Applications MIB.

snmp

normative-requirement §5 MUST

The values 'stdin', 'stdout', and 'stderr' are reserved as applOpenFileName values when the fully-qualified path name cannot be determined, in accordance with common usage.

snmp

normative-requirement §5 SHOULD

When identifying application-layer protocols in applOpenConnectionApplication, protocol names should be those used in ASSIGNED NUMBERS (e.g., 'SMTP' for a mail server); if not known, the value shall be a zero-length string.

snmp

protocol-element §4.4.2

The applElmtRunControlTable (applElmtRunControlGroup) provides authorized managers with three control variables per running application element: a suspend/resume control, a reconfiguration request control, and a termination request control.

snmp

protocol-element §4.4.1

The applElmtRunStatusTable (applElmtRunControlGroup) reports current heap usage, number of open network connections, and the most recent error status message for each running application element indexed by sysApplElmtRunIndex.

snmp

protocol-element §4.2.1

The applOpenChannelTable (applChannelGroup.1) tracks open I/O channels indexed by applElmtOrSvc, applElmtOrSvcId, and applOpenChannelIndex, recording channel-open time, read/write request counts (Counter64 + Counter32 Low), failure counts, bytes transferred, and last-operation timestamps.

snmp

protocol-element §4.2.3

The applOpenConnectionTable (applChannelGroup.3) describes open and listening connections, providing transport protocol (TDomain), near-end and far-end addresses as both ApplTAddress (binary) and SnmpAdminString (FQDN:port), and application-layer protocol name.

snmp

protocol-element §4.2.2

The applOpenFileTable (applChannelGroup.2) extends the open channel table for file channels, providing applOpenFileName (LongUtf8String), applOpenFileSizeHigh and applOpenFileSizeLow (64-bit size split across two Unsigned32 fields), and applOpenFileMode (read/write/readWrite).

snmp

protocol-element §4.2.5

The applTransactFlowTable (applChannelGroup.5) breaks transaction statistics into rows indexed by flow direction (transmit/receive) and type (request/response), recording per-combination transaction count, byte count, and most-recent timestamp.

snmp

protocol-element §4.2.4

The applTransactionStreamTable (applChannelGroup.4) models transaction flows with an invoker/performer model, accumulating cumulative millisecond timers for invoker wait time, invoker response spread, performer handling time, and performer response spread, plus 64-bit transaction counts.

snmp

protocol-element §4.2.6

The applTransactKindTable (applChannelGroup.6) provides further breakdown of transaction statistics by transaction kind, indexed by direction, request/response, and a transaction-kind index, tracking count, bytes, and most-recent time.

snmp

protocol-element §4.3

The former channel group (applPastChannelGroup) mirrors the channel group for closed channels; the applPastChannelControlTable controls whether history is accumulated per running element or service instance, the maximum number of records retained, retention lifetime, and a count of premature deletions to make room for new entries.

snmp

protocol-element §4.1

The service-level group provides four bidirectional cross-index tables: applSrvNameToSrvInstTable, applSrvInstToSrvNameTable, applSrvInstToRunApplElmtTable, and applRunApplElmtToSrvInstTable, enabling lookup between service names, service instances, and running application elements.

snmp

registry §5

The APPLICATION-MIB module is registered at OID { mib-2 62 } under the SNMP MIB-2 subtree; applicationMibObjects is at { applicationMib 1 } and applicationMibConformance at { applicationMib 2 }.

registry, snmp

security-consideration §9

Read-only objects in this MIB can expose sensitive system configuration details including open file paths, connection addresses, application-layer protocol identifiers, and heap usage; the SNMPv3 security framework with appropriate view-based access control should be used to restrict access to these objects.

security, snmp, privacy

security-consideration §9

The running application element control table enables termination, suspension, and reconfiguration of application processes; access to these read-write objects must be restricted via SNMP access control to authorized principals to prevent unauthorized disruption or denial-of-service.

security, snmp

wire-format §5

ApplTAddress is defined as OCTET STRING (SIZE 0..255) encoding a transport service address; for snmpUDPDomain it is exactly 6 octets: 4 octets of IP address in network-byte order followed by 2 octets of UDP port in network-byte order.

snmp, udp

wire-format §5

File sizes are encoded as a pair of Unsigned32 fields: applOpenFileSizeHigh in units of 2^32-byte blocks (high-order word) and applOpenFileSizeLow as the remainder modulo 2^32 bytes, together forming a 64-bit file size.

snmp

wire-format §4

Rapidly-advancing counters are defined as Counter64 with a paired Counter32 suffix-'Low' object reporting the low-order 32 bits; the Counter32 companion is provided specifically for SNMPv1 agents that cannot encode Counter64.

snmp