Host Monitoring Protocol
 |
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Host Monitoring Protocol (HMP) is an obsolete TCP/IP protocol described in RFC 869.
 | This computer networking article is a stub. You can help Wikipedia by expanding it. |
1) Introduction
The Host Monitoring Protocol (HMP) is used to collect
information from hosts in various networks. A host is
defined as an addressable Internet entity that can send and
receive messages; this includes hosts such as server hosts,
personal work stations, terminal concentrators, packet switches,
and gateways. At present the Host Monitoring Protocol is being
used to collect information from Internet Gateways and TACs, and
implementations are being designed for other hosts. It is
designed to monitor hosts spread over the internet as well as
hosts in a single network.
contains a general description of the Host Monitoring protocol
and its relationship to other protocols. Section 4 describes
how it operates. Section 5 and 6 contain the descriptions and
formats of the HMP messages. These are followed by appendices
containing the formats of messages sent by some of the hosts that
use the HMP to collect their monitoring information. These
appendicies included as examples only and are not part of the HMP
protocol.
General Description
The Host Monitoring Protocol is a transaction-oriented
(i.e., connection-less) transport protocol. It was designed to
facilitate certain simple interactions between two internet
entities, one of which may be considered to be "monitoring" the
other. (In discussing the protocol we will sometimes speak of a
"monitoring host" and a "monitored entity".) HMP was intended to
be a useful transport protocol for applications that involve any
or all of the following three different kinds of interactions:
- The monitored entity sometimes needs to send unsolicited
datagrams to the monitoring host. The monitoring host
should be able to tell when messages from the monitored
entity have been lost in transit, and it should be able to
determine the order in which the messages were sent, but the
application does not require that all messages be received
or that they be received strictly in the same sequence in
which they were sent.
- The monitoring host needs to gather data from the monitored
entity by using a query-response protocol at the application
level. It is important to be able to determine which query
is being answered by a particular response, and to determine
whether successive responses are duplicates of previous
ones.
- The monitoring host must be able to initiate certain control
functions in the monitored entity, possibly including the
setting of parameters in the monitored entity. The
monitoring host needs to know if the control function has
been carried out.
In addition, we assume that a given monitoring host may be
monitoring several different types of entities simultaneously,
and may be gathering several different types of data from a giventype of monitored entity. Several different monitoring hosts may
be monitoring a given entity, and several processes on the same
host may even be monitoring the same entity.
Messages from the monitoring host to the monitored entity
are called "polls". They need to contain enough information to
allow the monitored entity to make the following determinations:
- The monitored entity must be able to determine that this
message is in fact a poll from a monitoring host. The
"system type," "message type," and "password" fields in the
HMP header have been defined to meet this need.
- The monitored entity may need to be able to identify the
particular process on the monitoring host that sent this
poll, so it can send its response back to the right process.
The "port number" field in the HMP header has been defined
to meet this need.
- The monitored entity must be able to indicate to the
monitoring host, in its response, precisely which query is
being answered by a particular response. The "sequence
number field" has been defined to meet this need.
- The monitored entity must be able to determine just what
kind of action the monitoring host is requesting. That is,
the HMP transport protocol must provide some way of
multiplexing and demultiplexing the various higher-level
applications which use it. The "R-message type" and "R-
subtype" fields of the polling message have been defined to
meet this need.
Messages from the monitored entity to the monitoring host
need to contain enough information to enable the monitoring host
to make the following determination:
- The monitoring host must be able to route this message to
the correct process. The "port number" field meets this
need.
-4-
RFC-869 December 1983
- The monitoring host must be able to match up received
messages with the polls, if any, that elicited them. The
"returned sequence number" field in the HMP header has been
defined to meet this need.
- The monitoring host must be able to determine which higher
level application should receive a particular message. The
"system type" and "message type" fields are used for this
purpose.
- The monitoring host must be able to determine whether some
messages of a given type were lost in transit, and whether
messages have arrived out of sequence. Although this
function, strictly speaking, belongs to the application and
not to the transport layer, the HMP header contains a
"sequence number" for this purpose.
In addition, a simple one's complement checksum is provided
in the HMP header to detect data corruption during transmission.
Relationship to Other Protocols
The Host Monitoring Protocol is a transport protocol
designed to fit into the layered internet protocol environment.
It operates on top of the Internet/ICMP protocol and under
applications that require its services. This relationship is
illustrated in the following diagram:
+------+ +------+ +-------+ +------+
|TELNET| ...| FTP | |GATEWAY| ... | TAC | Application Layer
+------+ +------+ +-------+ +------+
| | | |
| | | |
|__________| |_____________|
| |
+------+ +-------+
| TCP | | HMP | Transport Layer
+------+ +-------+
| |
| |
+-------------------------------------+
| Internet Protocol & ICMP | Internetwork Layer
+-------------------------------------+
|
+------------------------+
| Local Network Protocol | Network Layer
+------------------------+
If internetwork services are not required it should be possible
to run the HMP without an Internetwork layer. As long as HMPs'
service requirnments (addressing, protocol demultiplexing, and
occasional delivery) are met it should run over a variety of
protocols.
Relationship to Other Protocols
The Host Monitoring Protocol is a transport protocol
designed to fit into the layered internet protocol environment.
It operates on top of the Internet/ICMP protocol and under
applications that require its services. This relationship is
illustrated in the following diagram:
+------+ +------+ +-------+ +------+
|TELNET| ...| FTP | |GATEWAY| ... | TAC | Application Layer
+------+ +------+ +-------+ +------+
| | | |
| | | |
|__________| |_____________|
| |
+------+ +-------+
| TCP | | HMP | Transport Layer
+------+ +-------+
| |
| |
+-------------------------------------+
| Internet Protocol & ICMP | Internetwork Layer
+-------------------------------------+
|
+------------------------+
| Local Network Protocol | Network Layer
+------------------------+
If internetwork services are not required it should be possible
to run the HMP without an Internetwork layer. As long as HMPs'
service requirnments (addressing, protocol demultiplexing, and
occasional delivery) are met it should run over a variety of
protocols. Protocol Operation
The HMP is built around the idea that most of the
intelligence needed to monitor a host should reside in a
monitoring center, not in the host. The host should be required
only to collect data and send it to the monitoring center, either
spontaneously or on request from the monitoring center. The host
is not responsible for insuring that the data arrives reliably
(except that it checksums the data); instead, the monitoring
center is responsible for ensuring that the data it requests is
received correctly.
Consequently, the HMP is based on polling hosts for
messages. When the monitoring center requires a particular type
of data (e.g., throughput data), it sends a poll to the host
requesting that type of report. The host, upon receiving the
poll, responds with its latest set of collected data. If the
host finds that the poll is incorrect (e.g., if the poll was for
throughput data and the host is not collecting throughput data),
it responds with an error message. The monitoring center waits a
reasonable length of time for the host to answer its poll. If no
response is received, it sends another poll for the same data.
In this way, if either a poll or the response is los correct data is still collected.
The HMP is used to collect three different classes of data:
o Spontaneous Events (or Traps)
o Current status
o Statistical data collected over time
These classes of data allow a host to send data in a manner best
suited to the data. For instance, the host may quickly inform
the monitoring center that a particular event has happened by
sending a trap message, while the monitoring center is reliably
collecting the host's throughput and accounting data.
Traps report spontaneous events, as they occur, to the
monitoring center. In order to insure their prompt delivery, the
traps are sent as datagrams with no reliability mechanisms
(except checksums) such as acknowledgments and retransmissions.
Trap messages usually contain an identifier to indicate which
event is being reported, the local time in the host that the
event occured, and data pertinent to the event. The data portion
is intended to be host and event specific.
Status information, the second type of data collected by the
Host Monitoring Protocol describes the current state of the host.
Status information is useful at one point, but it does not have
to be collected cumulatively over a certain period of time. Only
the latest status is of interest; old status provides no useful
information. The monitoring center collects status information
-8-
RFC-869 December 1983
by sending a poll for status to a host. Upon receiving the poll,
the host responds with its latest status information, always
creating a new status message. If the monitoring center does not
receive a response to its poll, it sends another poll. The
monitoring center can decide if the host is up or down based on
whether the host responds to its polls.
The third type of data collected by the HMP is statistical
data. These are measurements taken over time, such as the number of packets sent or received by a host and the count of packets
dropped for a particular reason. It is important that none of
this type of data be lost. Statistical data is collected in a
host over a time interval. When the collection time interval
expires, the current data is copied to another area, and the
counters are cleared. The copied data is sent to the monitoring
center when the host receives a poll requesting statistical
information. If another poll is received before the collection
time interval has expired, the data in the buffer is sent again.
The monitoring center can detect duplicate messages by using the
sequence number in the header of the message, since each type of
statistical data has its own sequence number counter.
The collection frequency for statistics messages from a
particular host must be relatively long compared to the average
round trip message time between the monitoring center and that
host inorder to allow the monitoring center to re-poll if it does
-9-
RFC-869 December 1983
possible to avoid missing any statistics messages. Each
statistics message contains a field giving the local time when
the data was collected and the time at which the message was
sent. This information allows the monitoring center to schedule
when it sends a poll so that the poll arrives near the beginning
of each collection period. This ensures that if a message is
lost, the monitoring center will have sufficient time to poll
again for the statistics message for that period.
The HMP also includes a provision to send data to and read
parameters in hosts. The data may be used to set switches or
interval timers used to control measurements in a host, or to
control the host itself (e.g. a restart switch). The format of
the data and parameters is host specific.
To send data to a host, the monitoring center sends the host
a poll for a control-acknowledgment message. This poll message
includes the type of the data and the data being sent. When the
host receives this poll, it processes the data and responds with
a control-acknowledgment message.
To read parameters in a host, the monitoring center will
send a poll for parameters to the host. This poll includes the
not receive an answer. With this restriction, it should be type of the parameters being read. When the host receives this
poll, it will send the parameters of the requested type to the
-10-
RFC-869 December 1983
monitoring center in a parameters message. Header Formats
Host Monitor Protocol messages have the following format:
+----------------+
| Local Network |
| Header(s) |
+----------------+
| IP header |
+----------------+
| HMP |
| Header |
| |
+----------------+
| D |
| A |
| T |
| A |
+----------------+
| Padding |
+----------------+
5.1 IP Headers
HMP messages are sent using the version 4 IP header as described in RFC-791 "Internet Protocol." The HMP protocol number is 20 (decimal). The time to live field should be set to a reasonable value for the hosts being monitored.
All other fields should be set as specified in RFC-791.
HMP Header
The HMP header format is:
0 0 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | System Type | Message Type |
+---------------+---------------+
1 | Port Number | Control Flag |
+---------------+---------------+
2 | Sequence Number |
+---------------+---------------+
3 | Password or Returned Seq. # |
+---------------+---------------+
4 | One's Complement Checksum |
+---------------+---------------+
HMP FIELDS:
System Type Message Type
The combination of system type and message type determines
the format of the data in the monitoring message.
The system types which have been defined are:
System Type | Meaning
----------------+-----------------
1 | Monitoring Host
2 | IMP
3 | TAC
4 | Gateway
5 | SIMP
6 | BBN VAX/C70 TCP
7 | PAD
8 | Reserved
9 | TIU
10 | FEP
11 | Cronus Host
12 | Cronus MCS
-13-
RFC-869 December 1983
Message types are defined and used for each system type
according to the needs of that system. The message types
currently defined are:
Type | Description
----------+--------------------------
|
1 | Trap
2 | Status
3 | Thruput
4 | HTM - Host Traffic Matrix
5 | Parameters
6 | Routing
7 | Call Accounting
|
100 | Poll
101 | Error
102 | Control Acknowledgment
Port Number
This field can be used to multiplex similar messages to/from
different processes in one host. It is currently unused.
Control Flag
This field is used to pass control information. Currently
Bit 15 is defined as the "More bit" which is used in a
message in responce to a poll to indicate that there is more
data to poll for.
Sequence Number
Every message contains a sequence number. The sequence
number is incremented when each new message of that type is
sent.
Password or Returned Sequence Number
The Password field of a polling message from an monitoring
center contains a password to verify that the monitoring
center is allowed to gather information. Responses to
polling messages copy the Sequence Number from the
polling message and return it in this field for
-14-
RFC-869 December 1983
identification and round-trip time calculations.
Checksum
The Checksum field is the one's complement of the one's
complement sum of all the 16-bit words in the header and
data area.
Message Type 100: Polling Message
Description
The monitoring center will send polls to the hosts it is
monitoring to collect their monitoring data. When the host
receives a poll it will return a message of the type
requested. It will only answer a poll with the correct
system type and password and will return an error message
(Message Type 101) if it receives a poll for the wrong
system type or an unsupported message type.
The Poll message includes a facility to send data to a
monitored host. The poll message to send data consists of a
poll for a Control Acknowledgment message (type 102)
followed by the data. The R-Subtype specifies the type of
the data that is being sent. When the monitored host
receives a Poll for a Control acknowledgment, it processes
the data, and then responds with an Control acknowledgment
message. If the monitored host can not process the data, it
should respond with an error message.
A poll to read parameters consists a poll for a Parameters
message. The R-Subtype specifies the type of parameters
being read. When the monitored host receives a poll for a
Parameters message, it responds with a Parameters message
containing the requested information.
A polling message has the following form:
0 0 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | R-Message Type| R-Subtype |
+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Data |
+ +
2 | |
+ +
. .
. .
n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-16-
RFC-869 December 1983
HMP FIELDS
System Type
The type of machine being polled.
Message Type
Polling Message = 100
Port Number
Unused
Control Flag
Unused
Sequence Number
The sequence number identifies the polling request. The
Monitoring Center will maintain separate sequence numbers
for each host it monitors. This sequence number is returned
in the response to a poll and the monitoring center will use
this information to associate polls with their responses and
to determine round trip times.
Password
The monitoring password.
POLL FIELDS
R-Message Type
The message type requested.
R-Subtype
This field is used when sending data and reading parameters
and it specifies the type of the data being sent or
parameters being read.
Data
When the poll is requesting a Control Acknowledgment
message, data is included in the poll message. A poll for
any other type of message does not include any data . The
contents of the data is host specific.
-17-
RFC-869 December 1983Message Type 101: Error in Poll
Description
This message is sent in response to a faulty poll and
specifies the nature of the error.
An error message has the following form:
0 0 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Error Type |
+---------------+---------------+
1 | R-Message Type| R-Subtype |
+---------------+---------------+
HMP FIELDS
System Type
The type of machine sending message.
Message Type
Error Message = 101
Port Number
Unused
Control Flag
Unused
Sequence Number
A 16 bit number incremented each time an error message is
sent.
Returned Sequence Number caused the
error.
-18-
RFC-869 December 1983
ERROR MESSAGE FIELDS
Error Type
This field specifies the nature of the error in the poll.
The following error types have been defined.
1 = Reason unspecified.
2 = Bad R-Message Type.
3 = Bad R-Subtype.
4 = Unknown parameter
5 = Invalid parameter value
6 = Invalid parameter/value format
7 = Machine in Loader
R-Message Type R-Subtype Message Type 102: Control acknowledgment
Description
This message is sent in response to a poll for this type of
message. It is used to acknowledge poll messages that are
used to set parameters in the monitored host.
The Control acknowledgment has no fields other than the HMP
header.
HMP FIELDS
System Type
The type of the system sending the message.
Message Type
Control acknowledgment = 102
Port Number
Unused
Control Flag
Unused
Sequence Number
A 16 bit number incremented each time a Control
acknowledgment message is sent.
Returned Sequence Number
The Sequence Number of the polling message which requested
this message.
These fields identify the poll request in error.
The Sequence Number of the polling message which