RFC - 869
 A Host Monitoring Protocol
 Robert M. Hinden
 BBN Communications Corporation
 December 1983
RFC-869 December 1983
 Table of Contents
1 Introduction.......................................... 1
2 General Description................................... 3
3 Relationship to Other Protocols....................... 6
4 Protocol Operation.................................... 7
5 Header Formats....................................... 12
5.1 IP Headers......................................... 12
5.2 HMP Header......................................... 13
6 HMP Monitoring Center Message Formats................ 16
6.1 Message Type 100: Polling Message.................. 16
6.2 Message Type 101: Error in Poll.................... 18
6.3 Message Type 102: Control acknowledgment........... 20
A Appendix A - IMP Monitoring.......................... 21
A.1 Message Type 1: IMP Trap........................... 21
A.2 Message Type 2: IMP status......................... 24
A.3 Message Type 3: IMP Modem Throughput............... 29
A.4 Message Type 4: IMP Host Throughput................ 32
B Appendix B - TAC Monitoring.......................... 35
B.1 Message Type 1: TAC Trap Message................... 35
B.2 Message Type 2: TAC Status......................... 38
B.3 Message Type 3: TAC Throughput..................... 42
C Appendix C - Gateway Monitoring...................... 47
C.1 Gateway Parameters................................. 47
C.2 Message Type 1: Gateway Trap....................... 48
C.3 Message Type 2: Gateway Status..................... 51
C.4 Message Type 3: Gateway Throughput................. 58
C.5 Message Type 4: Gateway Host Traffic Matrix........ 64
C.6 Message Type 6: Gateway Routing.................... 67
 -i-
RFC-869 December 1983
Replaces IEN-197
 A Host Monitoring Protocol
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.
 This document is organized into three parts. Section 2 and
3 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.
 -1-
RFC-869 December 1983
 This document replaces the previous HMP document "IEN-197, A
Host Monitoring Protocol."
 -2-
RFC-869 December 1983
2 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 given
 -3-
RFC-869 December 1983
type 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.
 -5-
RFC-869 December 1983
3 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.
 -6-
RFC-869 December 1983
4 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 lost, the
correct data is still collected.
 -7-
RFC-869 December 1983
 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
not receive an answer. With this restriction, it should be
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
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.
 -11-
RFC-869 December 1983
5 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.
 -12-
RFC-869 December 1983
5.2 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.
 -15-
RFC-869 December 1983
6 HMP Monitoring Center Message Formats
6.1 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 1983
6.2 Message 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
 The Sequence Number of the polling message which 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
 These fields identify the poll request in error.
 -19-
RFC-869 December 1983
6.3 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.
 -20-
RFC-869 December 1983
A Appendix A - IMP Monitoring
A.1 Message Type 1: IMP Trap
Description
 When a trap occurs, it is buffered in the IMP and sent as
 soon as possible. Trap messages are unsolicited. If traps
 happen in close sequence, several traps may be sent in one
 message.
 Through the use of sequence numbers, it will be possible to
 determine how many traps are being lost. If it is
 discovered that many are lost, a polling scheme might be
 implemented for traps.
 A IMP trap 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 | # of traps lost |
 +---------------+---------------+
 1 : first :
 . : trap :
 . : data :
 . +---------------+---------------+
 . : additional :
 . : trap :
 . : data :
 +---------------+---------------+
HMP Fields
System Type
 IMP = 2
Message Type
 IMP Trap Message = 1
Port Number
 Unused
 -21-
RFC-869 December 1983
Control Flag
 Unused
Password
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the HM can order the received trap messages and
 detect missed messages.
IMP TRAP FIELDS
# of traps lost
 Under certain conditions, an IMP may overflow its internal
 trap buffers and be unable to save traps to send. This
 counter keeps track of such occurrences.
Trap Reports
 There can be several blocks of trap data in each message.
 The format for each such block is below.
 +---------------+---------------+
 | Size |
 +---------------+---------------+
 | Time |
 +---------------+---------------+
 | Trap ID |
 +---------------+---------------+
 : Trap :
 : Data :
 +---------------+---------------+
 Size
 Size is the number of 16 bit words in the trap, not counting
 the size field.
 Time
 The time (in 640 ms. units) at which the trap occurred.
 -22-
RFC-869 December 1983
 This field is used to sequence the traps in a message and
 associate groups of traps.
 Trap ID
 This is usually the program counter at the trap. The ID
 identifies the trap, and does not have to be a program
 counter, provided it uniquely identifies the trap.
 Trap Data
 The IMP returns data giving more information about the trap.
 There are usually two entries: the values in the accumulator
 and the index register at the occurrence of the trap.
 -23-
RFC-869 December 1983
A.2 Message Type 2: IMP status
Description
 The status message gives a quick summary of the state of the
 IMP. Status of the most important features of the IMP are
 reported as well as the current configuration of the
 machine.
 The format of the status message is as follows:
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +---------------+---------------+
 0 | Software Version Number |
 +---------------+---------------+
 | Last Trap Message |
 +---------------+---------------+
 | Max # Hosts | Max # Modems |
 +---------------+---------------+
 | Max # Channels| Max # IMPs |
 +---------------+---------------+
 | Package bits 0-15. |
 +---------------+---------------+
 5 | Package bits 16.-31. |
 +---------------+---------------+
 | |
 + Crash +
 | |
 + Data +
 | |
 +---------------+---------------+
 | Anomalies |
 +---------------+---------------+
 10 | Free Pool | S+F Pool |
 +---------------+---------------+
 |Reassembly Pool| Allocated Pool|
 +---------------+---------------+
 | HIHD0 | HIHD1 | HIHD2 | HIHD3 |
 . +---------------+---------------+
 . : HIHD4 | ............... :
 . +---------------+---------------+
 (cont.)
 -24-
RFC-869 December 1983
 Imp Status (cont.)
 . +---------------+---------------+
 . | Modem |
 . + State +
 . | Data |
 . +---------------+---------------+
 . : Modem State :
 . : Data...... :
 +---------------+---------------+
HMP FIELDS
System Type
 IMP = 2
Message Type
 IMP status message = 2
Port Number
 Unused
Control Flag
 Unused
Sequence Number
 A 16 bit number incremented each time a status message is
 sent.
Password
 The password contains the sequence number of the polling
 message to which this message responds.
IMP STATUS FIELDS
Software Version Number
 The IMP version number.
 -25-
RFC-869 December 1983
Last Trap Message
 Contains the sequence number of the last trap message sent
 to the HM. This will allow the HM to detect how many trap
 messages are being lost.
Hosts
 The number of configured hosts in this system.
Modems
 The number of configured modems in this system.
Channels
 The maximum possible number of IMP-IMP channels in this
 system.
IMPs
 The maximum possible number of IMPs in this system.
Package Bits
 This is a bit encoded word that reports the set of packages
 currently loaded in the system. The table below defines the
 bits.
 -26-
RFC-869 December 1983
 Bit Package
 (octal)
 (1st Word)
 1 VDH
 2 Logical address tables
 4 Mezmode
 10 Cumulative Statistics
 20 Trace
 40 TTY
 100 DDT
 200 HDLC
 400 HDH
 1000 Cassette Writer
 2000 Propagation Delay Measurement
 4000 X25
 10000 Profile Measurements
 20000 Self Authenticating Password
 40000 Host traffic Matrix
 100000 Experimental/Special
 (2nd Word)
 1 End-to-end Statistics
 2 Store and Forward statistics
Crash Data
 Crash data reports the circumstances surrounding an
 unexpected crash. The first word reports the location of
 the crash and the following two are the contents of the
 accumulator and index registers.
Anomalies
 Anomalies is a collection of bit flags that indicate the
 state of various switches or processes in the IMP. These
 are very machine dependent and only a representative
 sampling of bits is listed below.
 Bit Meaning
 (octal)
 20 Override ON
 200 Trace ON
 1000 Statistics ON
 2000 Message Generator ON
 4000 Packet Trace ON
 10000 Host Data Checksum is BAD
 20000 Reload Location SET
 -27-
RFC-869 December 1983
Buffer Pool Counts
 These are four bytes of counters indicating the current
 usage of buffers in the IMP. The four counters are: free
 buffers, store-and-forward buffers, reassembly buffers and
 allocated buffers.
HIHD0 - HIHDn
 Each four bit HIHD field gives the state of the
 corresponding host.
 Value Meaning
 0 UP
 1 ready line down
 2 tardy
 3 non-existent
Modem State Data
 Modem state data contains six fields of data distributed
 over four words. The first field (4 bits) indicates the
 line speed; the second field (4 bits) is the number of the
 modem that is used by the neighboring IMP on this line; the
 third field (8 bits) is the number of line protocol ticks
 covered by this report; the fourth (1 bit) indicates line
 down(1) or up(0); the fifth (7 bits) is the IMP number of
 neighbor IMP on the line; and the sixth (8 bits) is a count
 of missed protocol packets over the interval specified in
 the third field.
 -28-
RFC-869 December 1983
A.3 Message Type 3: IMP Modem Throughput
Description
 The modem throughput message reports traffic statistics for
 each modem in the system. The IMP will collect these data at
 regular intervals and save them awaiting a poll from the HM.
 If a period is missed by the HM, the new results simply
 overwrite the old. Two time stamps bracket the collection
 interval (data-time and prev-time) and are an indicator of
 missed reports. In addition, mess-time indicates the time
 at which the message was sent.
 The modem throughput message will accommodate up to fourteen
 modems in one packet. A provision is made to split this
 into multiple packets by including a modem number for the
 first entry in the packet. This field is not immediately
 useful, but if machine sizes grow beyond fourteen modems or
 if modem statistics become more detailed and use more than
 three words per modem, this can be used to keep the message
 within a single ARPANET packet.
 The format of the modem throughput message is as follows:
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +---------------+---------------+
 0 | Mess-Time |
 +---------------+---------------+
 | Software Version Number |
 +---------------+---------------+
 | Data-Time |
 +---------------+---------------+
 | Prev-Time |
 +---------------+---------------+
 | Total Modems | This Modem |
 +---------------+---------------+
 5 | |
 . + modem +
 . | |
 . + throughput +
 . | |
 . +---------------+---------------+
 . : modem :
 . : :
 . : throughput :
 +---------------+---------------+
 -29-
RFC-869 December 1983
HMP FIELDS
System Type
 IMP = 2
Message Type
 IMP Modem Throughput message = 3
Port Number
 Unused
Control Flag
 Unused
Sequence Number
 A 16 bit number incremented at each collection interval
 (i.e. when a new throughput message is assembled). The HM
 will be able to detect lost or duplicate messages by
 checking the sequence numbers.
Password
 The password contains the sequence number of the polling
 message to which this message responds.
IMP MODEM THROUGHPUT FIELDS
Mess-time
 The time (in 640ms. units) at which the message was sent to
 the HM.
Software Version Number
 The IMP version number.
Data-Time
 Data-time is the time (in 640ms. units) when this set of
 data was collected. (See Description.)
 -30-
RFC-869 December 1983
Prev-Time
 Prev-time is the time (in 640 ms. units) of the previous
 collection of data (and therefore, is the time when the data
 in this message began accumulating.)
Total Modems
 This is the number of modems in the system.
This Modem
 This Modem is the number of the first modem reported in this
 message. Large systems that are unable to fit all their
 modem reports into a single packet may use this field to
 separate their message into smaller chunks to take advantage
 of single packet message efficiencies.
Modem Throughput
 Modem throughput consists of three words of data
 reporting packets and words output on each modem. The
 first word counts packets output and the following two
 count word throughput. The double precision words are
 arranged high order first. (Note also that messages from
 Honeywell type machines (316s, 516s and C30s) use a fifteen
 bit low order word.) The first block reports output on the
 modem specified by "This Modem". The following blocks
 report on consecutive modems.
 -31-
RFC-869 December 1983
A.4 Message Type 4: IMP Host Throughput
Description
 The host throughput message reports traffic statistics for
 each host in the system. The IMP will collect these data at
 regular intervals and save them awaiting a poll from the HM.
 If a period is missed by the HM, the new results simply
 overwrite the old. Two time stamps bracket the collection
 interval (data-time and prev-time) and are an indicator of
 missed reports. In addition, mess-time indicates the time
 at which the message was sent.
 The host throughput format will hold only three hosts if
 packet boundaries are to be respected. A provision is made
 to split this into multiple packets by including a host
 number for the first entry in the packet.
 The format of the host throughput message is as follows:
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +---------------+---------------+
 0 | Mess-Time |
 +---------------+---------------+
 | Software Version Number |
 +---------------+---------------+
 | Data-Time |
 +---------------+---------------+
 | Prev-Time |
 +---------------+---------------+
 | Total Hosts | This Host |
 +---------------+---------------+
 5 : host :
 . : throughput :
 +---------------+---------------+
HMP FIELDS
System Type
 IMP = 2
Message Type
 IMP host Throughput message = 4
 -32-
RFC-869 December 1983
Port Number
 Unused
Control Flag
 Unused
Sequence Number
 A 16 bit number incremented at each collection interval
 (i.e. when a new throughput message is assembled). The HM
 will be able to detect lost or duplicate messages by
 checking the sequence numbers.
Password
 The password contains the sequence number of the polling
 message to which this message responds.
IMP HOST THROUGHPUT FIELDS
Mess-time
 The time (in 640ms. units) at which the message was sent to
 the HM.
Software Version Number
 The IMP version number.
Data-Time
 Data-time is the time (in 640ms. units) when this set of
 data was collected. (See Description.)
Prev-Time
 Prev-time is the time (in 640 ms. units) of the previous
 collection of data (and therefore, is the time when the data
 in this message began accumulating.)
Total Hosts
 The total number of hosts in this system.
This Host
 This host is the number of the first host reported in this
 -33-
RFC-869 December 1983
 message. Large systems that are unable to fit all their
 host reports into a single packet may use this field to
 separate their message into smaller chunks to take advantage
 of single packet message efficiencies.
Host Throughput
 Each host throughput block consists of eight words in the
 following format:
 +---------------+---------------+
 | messages to network |
 +---------------+---------------+
 | messages from network |
 +---------------+---------------+
 | packets to net |
 +---------------+---------------+
 | packets from net |
 +---------------+---------------+
 | messages to local |
 +---------------+---------------+
 | messages from local |
 +---------------+---------------+
 | packets to local |
 +---------------+---------------+
 | packets from local |
 +---------------+---------------+
 Each host throughput message will contain several blocks of
 data. The first block will contain data for the host
 specified in First Host Number. Following blocks will
 contain data for consecutive hosts. All counters are single
 precision.
 -34-
RFC-869 December 1983
B Appendix B - TAC Monitoring
B.1 Message Type 1: TAC Trap Message
Description
 When a trap occurs, it is buffered in the TAC and sent as
 soon as possible. Trap messages are unsolicited. If traps
 happen in close sequence, several traps may be sent in one
 message.
 Through the use of sequence numbers, it will be possible to
 determine how many traps are being lost. If it is
 discovered that many are lost, a polling scheme might be
 implemented for traps.
 A TAC trap 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 | Version # |
 +---------------+---------------+
 1 : first :
 . : trap :
 . : data :
 . +---------------+---------------+
 . : additional :
 . : trap :
 . : data :
 +---------------+---------------+
HMP FIELDS
System Type
 TAC = 3
Message Type
 TAC Trap Message = 1
Port Number
 Unused
 -35-
RFC-869 December 1983
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the HM can order the received trap messages and
 detect missed messages.
TAC TRAP FIELDS
Version #
 The version # of the TAC Software.
Trap Reports
 There can be several blocks of trap data in each message.
 The format of the trap data is as follows:
 +---------------+---------------+
 | Size |
 +---------------+---------------+
 | Time |
 +---------------+---------------+
 | Trap ID |
 +---------------+---------------+
 : Trap :
 : Data :
 +---------------+---------------+
 | Count |
 +-------------------------------+
 Size
 Size is the number of 16 bit words in the trap, not counting
 the size field.
 Time
 The time (in 640ms. units) at which the trap occurred. This
 field is used to sequence the traps in a message and
 -36-
RFC-869 December 1983
 associate groups of traps.
 Trap ID
 This is (usually) the program counter at the trap. The ID
 identifies the trap, and does not have to be a program
 counter, provided that it uniquely identifies the trap.
 Trap Data
 The TAC returns data giving more information about the trap.
 There are usually two entries: the values in the accumulator
 and the index register at the occurrence of the trap.
 Count
 The TAC Counts repetitions of the same trap ID and reports
 this count here.
 -37-
RFC-869 December 1983
B.2 Message Type 2: TAC Status
Description
 The status message gives a quick summary of the state of the
 TAC. Status of the most important features of the TAC are
 reported as well as the current configuration of the
 machine.
 A TAC status 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 | Version Number |
 +---------------+---------------+
 | Last Trap Message |
 +---------------+---------------+
 | Bit Flags |
 +---------------+---------------+
 | Free PDB count |
 +---------------+---------------+
 | Free MBLK count |
 +---------------+---------------+
 5 | # of TCP connections |
 +---------------+---------------+
 | # of NCP connections |
 +---------------+---------------+
 | INA A Register |
 +---------------+---------------+
 | INA X Register |
 +---------------+---------------+
 | INA B Register |
 +---------------+---------------+
 l0 | restart/reload |
 +---------------+---------------+
 | |
 + Crash +
 | |
 + Data +
 13 | |
 +---------------+---------------+
 -38-
RFC-869 December 1983
HMP FIELDS
System Type
 TAC = 3
Message Type
 TAC Status Message = 2
Port Number
 Unused
Control Flag
 Unused
Sequence Number
 A 16 bit number incremented each time a status message is
 sent.
Returned Sequence Number
 Contains the sequence number from the polling message
 requesting this report.
TAC STATUS FIELDS
Version Number
 The TAC's software version number.
Last Trap Message
 Contains the sequence number of the last trap message sent
 to the HM. This will allow the HM to detect how many trap
 messages are being lost.
 -39-
RFC-869 December 1983
Bit Flags
 There are sixteen bit flags available for reporting the
 state of various switches (hardware and software) in the
 TAC. The bits are numbered as follows for purposes of the
 discussion below.
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | | | | | | | | | | | | | | | | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The bit flags report the status of the following:
 Bit Meaning
 15 0 => DDT override off; 1 => override on.
 11-14 0 => Sense Switch n is off; 1 => SSn on.
 10 0 => Traps to remote monitor;
 1 => Traps to console.
 9 1 => Message generator on.
 0-8 unused
Free PDB count
 The number of PDBs on the free queue.
Free MBLK count
 The number of MBLKs on the free queue.
# of TCP connections
# of NCP connections
 The number of open connections for each protocol.
INA Report
 These three fields report the values retained by an INA 1011
 instruction in a C/30. This instruction returns micro-
 machine status and errors. In a #316, the fields are
 meaningless.
 -40-
RFC-869 December 1983
Restart/Reload
 This word reports a restart or reload of the TAC
 Value Meaning
 1 restarted
 2 reloaded
Crash Data
 Crash data reports the circumstances surrounding an
 unexpected crash. The first word reports the location of
 the crash and the following two are the contents of the
 accumulator and index registers.
 -41-
RFC-869 December 1983
B.3 Message Type 3: TAC Throughput
Description
 The TAC throughput message reports statistics for the
 various modules of the TAC. The TAC will collect these data
 at regular intervals and save them awaiting a poll from the
 HM. If a period is missed by the HM, the new results simply
 overwrite the old. Two time stamps bracket the collection
 interval (data-time and prev-time) and are an indicator of
 missed reports. In addition, mess-time indicates the time
 at which the message was sent.
 A TAC throughput 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 | Mess-Time |
 +---------------+---------------+
 | Data-Time |
 +---------------+---------------+
 | Prev-Time |
 +---------------+---------------+
 | Version Number |
 +---------------+---------------+
 | Last Trap Message |
 +---------------+---------------+
 5 | Bit Flags |
 +---------------+---------------+
 | Free PDB count |
 +---------------+---------------+
 | Free MBLK count |
 +---------------+---------------+
 | # of TCP connections |
 +---------------+---------------+
 | # of NCP connections |
 +---------------+---------------+ ----
 10 | Host Input Throughput | ^
 +---------------+---------------+ |
 | Host Input Abort Count | |
 +---------------+---------------+ |
 | Host Input Garbled Count | |
 +---------------+---------------+ |
 | Host Output Throughput | 1822 info.
 +---------------+---------------+ |
 (continued)
 -42-
RFC-869 December 1983
 TAC throughput (cont.)
 +---------------+---------------+ |
 | Host Output Abort Count | 1822 info.
 +---------------+---------------+ |
 15 | Host Down Count | v
 +---------------+---------------+ ----
 | # of datagrams sent | ^
 +---------------+---------------+ |
 | # of datagrams received | |
 +---------------+---------------+ IP info.
 | # of datagrams discarded | |
 +---------------+---------------+ |
 | # of fragments received | v
 +---------------+---------------+ |
 20 | # of fragments discarded | v
 +---------------+---------------+ ----
 | # of segments sent | ^
 +---------------+---------------+ |
 | # of segments received | |
 +---------------+---------------+ |
 | # of segments discarded | |
 +---------------+---------------+ TCP info.
 | # of octets sent | |
 +---------------+---------------+ |
 25 | # of octets received | |
 +---------------+---------------+ |
 | # of retransmissions | v
 +---------------+---------------+ ----
HMP FIELDS
System Type
 TAC = 3
Message Type
 TAC Throughput Message = 3
Port Number
 Unused
Control Flag
 Unused
 -43-
RFC-869 December 1983
Sequence Number
 A 16 bit number incremented at each collection interval
 (i.e. when a new throughput message is assembled). The HM
 will be able to detect lost or duplicate messages by
 checking the sequence numbers.
Returned Sequence Number
 Contains the sequence number from the polling message
 requesting this report.
TAC THROUGHPUT FIELDS
Mess-time
 The time (in 640ms. units) at which the message was sent to
 the HM.
Data-Time
 Data-time is the time (in 640ms. units) when this set of
 data was collected. (See Description.)
Prev-Time
 Prev-time is the time (in 640 ms. units) of the previous
 collection of data (and therefore, is the time when the data
 in this message began accumulating.)
Version Number
 The TAC's software version number.
Last Trap Message
 Contains the sequence number of the last trap message sent
 to the HM. This will allow the HM to detect how many trap
 messages are being lost.
Bit Flags
 There are sixteen bit flags available for reporting the
 state of various switches (hardware and software) in the
 TAC. The bits are numbered as follows for purposes of the
 discussion below.
 -44-
RFC-869 December 1983
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | | | | | | | | | | | | | | | | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The bit flags report the status of the following:
 Bit Meaning
 15 0 => DDT override off; 1 => override on.
 11-14 0 => Sense Switch n is off; 1 => SSn on.
 10 0 => Traps to remote monitor;
 1 => Traps to console.
 9 1 => Message generator on.
 0-8 unused
Free PDB count
 The number of PDBs on the free queue.
Free MBLK count
 The number of MBLKs on the free queue.
# of TCP connections
# of NCP connections
 The number of open connections for each protocol.
1822 info.
 These six fields report statistics which concern the
 operation of the 1822 protocol module, i.e. the interface
 between the TAC and its IMP.
IP info.
 These five fields report statistics which concern Internet
 Protocol in the TAC.
TCP info.
 -45-
RFC-869 December 1983
 These six fields report statistics which concern TCP
 protocol in the TAC.
 -46-
RFC-869 December 1983
C Appendix C - Gateway Monitoring
C.1 Gateway Parameters
 The gateway supports parameters to set Throughput and Host
 traffic matrix measurements. The type of parameters and the
 parameter and data pairs are as follows:
 Throughput - Type = 3
 Parm. Description Control Data Word
 ----- ----------- -----------------
 1 Start/Stop 0=Stop,1=Start
 2 Collection Interval Time in 1 minute
 ticks
 Host Traffic Matrix - Type = 4
 Parm. Description Control Data Word
 ----- ----------- -----------------
 1 Start/Stop 0=Stop,1=Start
 2 Collection Interval Time in 1 minute
 ticks
 3 HTM Switch Control Include Control
 Protocols
 -47-
RFC-869 December 1983
C.2 Message Type 1: Gateway Trap
Description
 When traps occur in the gateway they are buffered. At a
 fixed time interval (currently 10 seconds) the gateway will
 send any traps that are in the buffer to the monitoring
 center. The traps are sent as unsolicited messages.
 A Gateway trap message has the following format:
 0 0 0 1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Gateway Version # |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Size of Trap Entry | ;First Trap
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Time of Trap |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Trap ID |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Process ID |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R0 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R1 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R2 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R3 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (continued)
 -48-
RFC-869 December 1983
Gateway Trap Message (cont'd.)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R4 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R5 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R6 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of this Trap |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 | Additional Trap reports |
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HMP FIELDS
System Type
 Gateway = 4
Message Type
 Gateway Trap Message = 1
Port Number
 Unused
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the monitoring center can order the received trap
 messages and detect missed messages.
 -49-
RFC-869 December 1983
GATEWAY TRAP FIELDS
Gateway Version #
 The software version number of the gateway sending the trap.
Trap Reports
 The remainder of the trap message consists of the trap
 reports. Each consists of the following fields:
 Size of Trap Entry
 The size in 16-bit words of the trap entry, not
 including the size field.
 Time of Trap
 The time in (in 1/60 sec. ticks) at which the trap
 occurred.
 Trap ID
 The number of the trap which is used to identify the
 trap.
 Process ID
 The identifier of the process that executed the trap.
 R0-R6
 The registers of the machine at the occurrence of the
 trap.
 Count of this Trap
 The number of times that this trap occurred.
 -50-
RFC-869 December 1983
C.3 Message Type 2: Gateway Status
Description
 The gateway status message gives a summary of the status of
 the gateway. It reports information such as version number
 of the gateway, buffer memory usage, interface status and
 neighbor gateway status.
 A Gateway Status message has the following format:
 -51-
RFC-869 December 1983
 0 1 1 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Version Number |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Patch Version Number |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Time Since Gateway Restart | ;in minutes
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Measurement Flags | ; Bit flags to indicate which
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; measurements are on, 1= On
 | Routing Sequence No. | ; Sequence # of last routing
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; update sent
 | Access Table Version # |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Load Sharing Table Ver. # |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Memory in Use |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Memory Idle |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Memory Free |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # of Blks | ; Memory Allocation Info
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Size of 1st Block (in bytes) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # Allocated |
 +-+-+-+-+-+-+-+-+
 | # Idle |
 +-+-+-+-+-+-+-+-+
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Size of n'th Block (in bytes) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # Allocated |
 +-+-+-+-+-+-+-+-+
 | # Idle |
 +-+-+-+-+-+-+-+-+
 (continued)
 -52-
RFC-869 December 1983
Gateway Status Message (cont'd.)
 +-+-+-+-+-+-+-+-+
 | # of Ints. |
 +-+-+-+-+-+-+-+-+
 | Int 1 Flags | ;Interface 1 Status Flags
 +-+-+-+-+-+-+-+-+ ; Bit 0 - 1=Up, 0=Down
 ; 1 - 1=Looped, 0=Not
 +-+-+-+-+-+-+-+-+
 | Buffers | ; # of buffers on write Queue
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Time since last Status Change | ;Time since last up/dwn change
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # of Buffers Allocated |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Data Size for Interface |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Interface 1 Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 +---------------+
 | Int n Flags | ;Interface n Status Flags
 +-+-+-+-+-+-+-+-+
 | Buffers |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Time since last Status Change |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # of Buffers Allocated |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Data Size for Interface |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Interface n Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # Neighbors |
 +-+-+-+-+-+-+-+-+
 | UP/DN Flags | ;Bit flags for Up or Down
 +-+-+-+-+-+-+-+-+ ; 0 = Dwn, 1 = Up
 . ; MSB is neighbor 1
 . ; (as many bytes as necessary)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Neighbor 1 Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Neighbor n Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 -53-
RFC-869 December 1983
HMP FIELDS
System Type
 Gateway = 4
Message Type
 Gateway Status Message = 2
Port Number
 Unused
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the monitoring center can order the received trap
 messages and detect missed messages.
GATEWAY STATUS FIELDS
Version Number
 The version number of the gateway sending the Status
 message.
Patch Version Number
 The patch version number of the gateway.
Time Since Gateway Restart
 The time in minutes since the gateway was last restarted or
 reloaded.
 -54-
RFC-869 December 1983
Measurement Flags
 Flags that, if set, indicate which measurements are turned
 on. Current values are:
 Bit 0 = Message Generator
 1 = Throughput
 2 = Host Traffic Matrix
 3 = Access Control 1
 4 = Access Control 2
 5 = Load Sharing
 6 = EGP in Gateway
Routing Sequence Number
 The sequence number of the last routing update sent by this
 gateway.
Access Control Table Version #
 The version number of the access control table.
Load Sharing Table Version #
 The version number of the load sharing table.
Memory In Use
 The number of bytes of buffer memory that are currently in
 use.
Memory Idle
 The number of bytes of buffer memory that have been
 allocated but are currently idle.
Memory Free
 The number of bytes of buffer memory that has not been
 allocated.
MEMORY ALLOCATION INFORMATION
 The next part of the status message contains information on
 the buffer pools in the gateway. The fields are:
 # of Blocks
 -55-
RFC-869 December 1983
 The number of different buffer pools.
 Size of Block
 The size of this block in bytes.
 # Allocated
 The number of blocks of this size that have been
 allocated.
 # Idle
 The number of blocks of this size that are idle.
GATEWAY INTERFACE FIELDS
 The next part of the status message are fields that provide
 information about the gateway's interfaces. The fields are:
 # of Interfaces
 The number of network interfaces that the gateway has.
 Interface Flags
 Flags that indicate the status of this interface. The
 current values are:
 Bit 0 - 1=Up/0=Down
 1 - 1=Looped/0=Not Looped
 Buffers
 The numbers on this interfaces write queue.
 Time Since Last Status Change
 The time in minutes since this interface changed status
 (Up/Down).
 # of Buffers Allocated
 The number of buffers allocated for this interface.
 Data Size for Interface
 The buffer size required for this interface.
 -56-
RFC-869 December 1983
 Interface Address
 The Internet address of this interface.
NEIGHBOR GATEWAY FIELDS
 The final part of the status message consists of information
 about this gateway's neighbor gateways. The fields are:
 # of Neighbors
 The number of gateways that are neighbor gateways to
 this gateway.
 UP/DN Flags
 Bit flags to indicate if the neighbor is up or down.
 Neighbor Address
 The Internet address of the neighbor gateway.
 -57-
RFC-869 December 1983
C.4 Message Type 3: Gateway Throughput
Description
 The gateway collects throughput statistics for the gateway,
 its interfaces, and its neighbor gateways. It collects them
 for regular intervals and will save them for collection via
 a Poll message from the Monitoring host. If they are not
 collected by the end of the next interval, they will be lost
 because another copy will be put into the saved area.
 A Gateway Throughput message has the following format:
 0 1 1 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Gateway Version Number |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Collection Time in Min |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Number of Interfaces |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Number of Neighbors |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Number of Host Unreachable | ; # of packets dropped because
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; Host was Unreachable
 | Number of Net Unreachable |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; Net was Unreachable
 ; Interface Counters
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Interface Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Packets Dropped on Input |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of IP Errors |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Datagrams for Us |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Datagrams to be Forwarded |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Datagrams Looped |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (continued)
 -58-
RFC-869 December 1983
Gateway Throughput Message (cont'd.)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Bytes Input |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Datagrams From Us |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count that were Forwarded |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Local Net Dropped |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Queue full Dropped |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Bytes Output |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 | Counters For Additional Interfaces |
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ; Neighbor counters
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Neighbor Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Routing Updates TO |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Count of Routing Updates FROM |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (continued)
 -59-
RFC-869 December 1983
Gateway Throughput Message (cont'd.)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Pkts from US sent to/via Neig |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Pkts forwarded to/via Neighb |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Datagrams Local Net Dropped |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Datagrams Queue full Dropped |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Count of Bytes send to Neighbor |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 | Counters for Additional Neighbor Gateways |
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HMP FIELDS
System Type
 Gateway = 4
Message Type
 Gateway Throughput Message = 3
Port Number
 Unused
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the HM can order the received trap messages and
 -60-
RFC-869 December 1983
 detect missed messages.
GATEWAY THROUGHPUT FIELDS
Gateway Version Number
 The software version number of the gateway sending the trap.
Collection Time in Min.
 The time period in minutes in which the throughput data is
 to be collected.
Number of Interfaces
 The number of interfaces this gateway has.
Number of Neighbors
 The number of neighbor gateways this gateway has.
Number of Host Unreachable
 The number of packets dropped because the Host was
 unreachable.
Number of Net Unreachable
 The number of packets dropped because the Network was
 unreachable.
INTERFACE COUNTERS
 The next part of the Throughput message contains counters
 for the gateways interfaces. Each interface has the
 following fields:
 Interface Address
 The Internet address of this interface.
 Packets Dropped on Input
 The number of packets on input to this interface
 because there were not enough buffers.
 Count of IP Errors
 The number of packets received with bad IP headers.
 -61-
RFC-869 December 1983
 Count of Datagrams for Us
 The number of datagrams received addressed to this
 gateway.
 Datagrams to be Forwarded
 The number of datagrams were not for this gateway and
 should be sent out another interface.
 Count of Datagrams Looped
 The number of datagrams that were received on and sent
 out of this interface.
 Count of Bytes Input
 The number of bytes received on this interface.
 Count of Datagrams From Us
 The number of datagrams that originated at this
 gateway.
 Count that were Forwarded
 The number of datagrams that were forwarded to another
 gateway.
 Count of Local Net Dropped
 The number of packets that were dropped because of
 local network flow control restrictions.
 Count of Queue full Dropped
 The number of packets that were dropped because the
 output queue was full.
 Count of Bytes Output
 The number of bytes sent out on this interface.
 -62-
RFC-869 December 1983
NEIGHBOR COUNTERS
 The last part of the Throughput message are counts for each
 neighbor gateway. The fields are:
 Neighbor Address
 The Internet address of this neighbor gateway.
 Count of Routing Updates TO
 The number of routing updates sent to this neighbor
 gateway.
 Count of Routing Updates FROM
 The number of routing updates received from this
 neighbor gateway.
 Pkts from US sent to/via Neig
 The number of packets from this gateway sent to or via
 this neighbor gateway.
 Pkts forwarded to/via Neighb
 The number of packets forwarded to or via this neighbor
 gateway.
 Datagrams Local Net Dropped
 The number of datagrams dropped to this neighbor
 gateway because of local network flow control
 restrictions.
 Datagrams Queue full Dropped
 The number of datagrams dropped to this neighbor
 because the output queue was full.
 Count of Bytes send to Neighbor
 The number of bytes sent to this neighbor gateway.
 -63-
RFC-869 December 1983
C.5 Message Type 4: Gateway Host Traffic Matrix
Description
 The Host Traffic Matrix (HTM) message contains information
 about the traffic that flows through the gateway. Each
 entry consists of the number of datagrams sent and received
 for a particular source/destination pair.
 A Gateway HTM message has the following format:
 0 1 1 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Gateway Version Number |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Overflow counter |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Collection Time in Min |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Number of HTM entries |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IP Source Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IP Destination Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | IP Protocol | (unused) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Counter for SRC -> DST datagrams |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Counter for DST -> SRC datagrams |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 | Additional HTM Reports |
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 -64-
RFC-869 December 1983
HMP FIELDS
System Type
 Gateway = 4
Message Type
 Gateway HTM Message = 4
Port Number
 Unused
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the HM can order the received trap messages and
 detect missed messages.
GATEWAY HTM FIELDS
Gateway Version Number
 The software version number of this gateway.
Overflow counter
 The number of HTM entries lost because the HTM buffer was
 full.
Collection Time in Min
 The time period in minutes in which the HTM data is being
 collected.
Number of HTM entries
 The number of HTM reports included in this message.
 -65-
RFC-869 December 1983
HTM ENTRIES
 The remainder of the HTM message consists of the actual HTM
 entries. Each entry consists of the following fields:
 IP Source Address
 The source Internet address of the datagrams being
 counted.
 IP Destination Address
 The destination Internet address of the datagrams being
 counted.
 IP Protocol
 The protocol number of the datagrams.
 Counter for SRC -> DST datagrams
 The number of datagrams sent in the Source to
 Destination address direction.
 Counter for DST -> SRC datagrams
 The number of datagrams sent in the Destination to
 Source address direction.
 -66-
RFC-869 December 1983
C.6 Message Type 6: Gateway Routing
Description
 The Routing message contains information about routes the
 gateway has to the networks that make up the Internet. It
 includes information about its interfaces and its neighbor
 gateways.
 A Gateway Routing message has the following format:
 0 1 1 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Version Number |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # of Ints. |
 +-+-+-+-+-+-+-+-+
 | UP/DN Flags | ;Bit flags for Up or Down
 +-+-+-+-+-+-+-+-+ ; 0 = Dwn, 1 = Up
 . ; MSB is interface 1
 . ; (as many bytes as necessary)
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Interface 1 Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Interface n Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | # Neighbors |
 +-+-+-+-+-+-+-+-+
 | UP/DN Flags | ;Bit flags for Up or Down
 +-+-+-+-+-+-+-+-+ ; 0 = Dwn, 1 = Up
 . ; MSB is neighbor 1
 . ; (as many bytes as necessary)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Neighbor 1 Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Neighbor n Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (continued)
 -67-
RFC-869 December 1983
Gateway Routing Message (cont'd.)
 +-+-+-+-+-+-+-+-+
 | # of Networks |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Network 1 # | | | ; 1, 2, or 3 bytes
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Distance |
 +-+-+-+-+-+-+-+-+
 | Neighbor # |
 +-+-+-+-+-+-+-+-+
 .
 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Network n # | | | ; 1, 2, or 3 bytes
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Distance |
 +-+-+-+-+-+-+-+-+
 | Neighbor # |
 +-+-+-+-+-+-+-+-+
HMP FIELDS
System Type
 Gateway = 4
Message Type
 Gateway Trap Message = 6
Port Number
 Unused
Control Flag
 Unused
Password or Returned Sequence Number
 Unused
Sequence Number
 A 16 bit number incremented each time a trap message is sent
 so that the HM can order the received trap messages and
 detect missed messages.
 -68-
RFC-869 December 1983
GATEWAY ROUTING FIELDS
Gateway Version #
 The software version number of the gateway sending the trap.
INTERFACE FIELDS
 The first part of the routing message contains information
 about the gateway's interfaces. There is data for each
 interface. The fields are:
 # of Interfaces
 The number of interfaces that this gateway has.
 UP/DN Flags
 Bit flags to indicate if the Interface is up or down.
 Interface Address
 The Internet address of the Interface.
NEIGHBOR FIELDS
 The next part of the routing message contains information
 about this gateway's neighbor gateways. The fields are:
 # of Neighbors
 The number of gateways that are neighbor gateways to
 this gateway.
 UP/DN Flags
 Bit flags to indicate if the neighbor is up or down.
 Neighbor Address
 The Internet address of the neighbor gateway.
NETWORK ROUTING FIELDS
 The last part of the routing message contains information
 about this gateway's routes to other networks. This
 includes the distance to each network and which neighbor
 gateway is the route to the network. The fields are:
 -69-
RFC-869 December 1983
 # of Networks
 The number of networks that are reachable from this
 gateway.
 Network #
 The network number of this network. This is the
 network part of the Internet address and may be one,
 two, or three bytes in length depending on whether it
 is a Class A, B, or C address.
 Distance
 The distance in hops to this network. Zero hops means
 that the network is directly connected to this gateway.
 A negative number means that the network is currently
 unreachable.
 Neighbor #
 The neighbor gateway that is the next hop to reach this
 network. This is an index into the previous
 information on this gateway's neighbor gateways. This
 field is only valid if the Distance is greater than
 zero.
 -70-