Summary

  • RFC 869 gave a monitoring center a common way to poll hosts, match replies, request status or statistics, and receive unsolicited traps; it did not make every host report the same facts.
  • A 1982 gateway specification shows what that distinction meant in practice: HMP could expose interfaces, neighbors, reachable networks, traffic matrices and drop counters, while the report and control formats remained specific to the host type.

Analysis

A gateway’s report was part of operating the network

The Host Monitoring Protocol was not merely a test for whether a machine answered. The 1982 DARPA Internet Gateway specification describes HMP collecting measurements and status from gateways. A status message covered the gateway’s interfaces, neighboring gateways and the networks it could reach. Its Host Traffic Matrix counted datagrams by IP source, destination and protocol number. A separate throughput message exposed counters for dropped packets and traffic received, forwarded or sent, broken down by interface and neighbor.

Those measurements made the gateway legible from elsewhere in the network. A traffic matrix could show which source-destination-protocol combinations crossed it; a drop counter could locate a class of failure inside the gateway. Neither was an end-to-end service test. A gateway counter could not, by itself, establish that a user’s application reached its destination. The RFC is an engineering description of the gateway design, not an independent census of deployed devices.

The shared part was the exchange, not every device’s vocabulary

Robert Hinden’s December 1983 RFC 869, which replaced the earlier IEN 197, called HMP a connectionless, transaction-oriented transport protocol. It defined a compact header with system type, message type, sequence number, a password-or-returned-sequence field and checksum. The system type and message type together identified how to interpret the data. The document assigned types to IMPs, terminal access controllers, gateways and other systems; HMP itself used IP protocol number 20.

That common frame made polls and replies recognizable across hosts. It did not turn a gateway’s throughput counters into a universal description of every host. RFC 869 says that message types were defined for each system type according to that system’s needs. Its appendices contain examples of IMP, TAC and gateway messages, but the introduction explicitly says those examples are not part of the HMP protocol. HMP standardized how a monitor could ask and associate an answer; a device-specific format still determined what the answer meant.

Polls, traps and silence carried different evidence

RFC 869 assigned most monitoring work to a monitoring center. A host collected data and sent it either when asked or spontaneously; the center was responsible for making sure requested data arrived. For status and statistics, the center polled and could repeat a request after a timeout. Sequence numbers helped associate a response with a poll and detect repeated statistical messages. Statistics were buffered over an interval so a lost response could be requested again.

Traps followed a different rule. A host sent an event datagram when something happened, but HMP specified no acknowledgment or retransmission for that message. That made a trap a prompt signal, not a guaranteed event history. Status was also an inference with a narrow scope: the center could decide a host was up or down based on whether it answered polls. No answer did not identify whether the host, path, poll or response had failed, and a reply did not demonstrate that a higher-level service was healthy.

The monitoring center could also change a host

The poll format did more than request data. RFC 869 allowed a center to read host parameters or send control data; examples included setting measurement switches or timers and controlling the host itself with a restart switch. A host processed the data and returned a control acknowledgment, or an error if it could not process it. The meanings and formats remained host-specific. The acknowledgment documented the protocol exchange; the RFC did not define it as proof of a user-facing service outcome.

The later SNMP specification, RFC 1157, offers a useful comparison, not a proven HMP lineage. RFC 1157 names the Simple Gateway Monitoring Protocol as SNMP’s predecessor and describes an architecture centered on reading and setting variables, with limited unsolicited traps. HMP’s history should therefore be read on its own terms: an operational monitoring protocol whose common envelope allowed very different hosts to report and accept control data.

The April 1983 Official Protocols list, RFC 840, classed HMP as elective and said it was used to monitor Internet gateways and TACs and to debug protocol implementations on small remote computers. RFC 869 likewise described use on gateways and TACs while implementations for other hosts were being designed. That record proves a bounded contemporary use, not Internet-wide adoption. The design’s lasting historical detail is the boundary it left visible: a shared message contract made remote observation possible, but the meaning of a host’s report still depended on that host.

Sources