As per Relevance of the word monitoring, we have this rfc below:
RFC - 869
A Host Monitoring
Robert M.
BBN Communications
December 1983
RFC-869 December 1983
Table of
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
1
The Host Monitoring Protocol (HMP) is used to
information from hosts in various networks. A host
defined as an addressable Internet entity that can send
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
used to collect information from Internet Gateways and TACs,
implementations are being designed for other hosts. It
designed to monitor hosts spread over the internet as well
hosts in a single network
This document is organized into three parts. Section 2
3 contains a general description of the Host Monitoring
and its relationship to other protocols. Section 4
how it operates. Section 5 and 6 contain the descriptions
formats of the HMP messages. These are followed by
containing the formats of messages sent by some of the hosts
use the HMP to collect their monitoring information.
appendicies included as examples only and are not part of the
protocol
-1-
RFC-869 December 1983
This document replaces the previous HMP document "IEN-197,
Host Monitoring Protocol."
-2-
RFC-869 December 1983
2 General
The Host Monitoring Protocol is a transaction-
(i.e., connection-less) transport protocol. It was designed
facilitate certain simple interactions between two
entities, one of which may be considered to be "monitoring"
other. (In discussing the protocol we will sometimes speak of
"monitoring host" and a "monitored entity".) HMP was intended
be a useful transport protocol for applications that involve
or all of the following three different kinds of interactions
- The monitored entity sometimes needs to send
datagrams to the monitoring host. The monitoring
should be able to tell when messages from the
entity have been lost in transit, and it should be able
determine the order in which the messages were sent, but
application does not require that all messages be
or that they be received strictly in the same sequence
which they were sent
- The monitoring host needs to gather data from the
entity by using a query-response protocol at the
level. It is important to be able to determine which
is being answered by a particular response, and to
whether successive responses are duplicates of
ones
- The monitoring host must be able to initiate certain
functions in the monitored entity, possibly including
setting of parameters in the monitored entity.
monitoring host needs to know if the control function
been carried out
In addition, we assume that a given monitoring host may
monitoring several different types of entities simultaneously
and may be gathering several different types of data from a
-3-
RFC-869 December 1983
type of monitored entity. Several different monitoring hosts
be monitoring a given entity, and several processes on the
host may even be monitoring the same entity
Messages from the monitoring host to the monitored
are called "polls". They need to contain enough information
allow the monitored entity to make the following determinations
- The monitored entity must be able to determine that
message is in fact a poll from a monitoring host.
"system type," "message type," and "password" fields in
HMP header have been defined to meet this need
- The monitored entity may need to be able to identify
particular process on the monitoring host that sent
poll, so it can send its response back to the right process
The "port number" field in the HMP header has been
to meet this need
- The monitored entity must be able to indicate to
monitoring host, in its response, precisely which query
being answered by a particular response. The "
number field" has been defined to meet this need
- The monitored entity must be able to determine just
kind of action the monitoring host is requesting. That is
the HMP transport protocol must provide some way
multiplexing and demultiplexing the various higher-
applications which use it. The "R-message type" and "R
subtype" fields of the polling message have been defined
meet this need
Messages from the monitored entity to the monitoring
need to contain enough information to enable the monitoring
to make the following determination
- The monitoring host must be able to route this message
the correct process. The "port number" field meets
need
-4-
RFC-869 December 1983
- The monitoring host must be able to match up
messages with the polls, if any, that elicited them.
"returned sequence number" field in the HMP header has
defined to meet this need
- The monitoring host must be able to determine which
level application should receive a particular message.
"system type" and "message type" fields are used for
purpose
- The monitoring host must be able to determine whether
messages of a given type were lost in transit, and
messages have arrived out of sequence. Although
function, strictly speaking, belongs to the application
not to the transport layer, the HMP header contains
"sequence number" for this purpose
In addition, a simple one's complement checksum is
in the HMP header to detect data corruption during transmission
-5-
RFC-869 December 1983
3 Relationship to Other
The Host Monitoring Protocol is a transport
designed to fit into the layered internet protocol environment
It operates on top of the Internet/ICMP protocol and
applications that require its services. This relationship
illustrated in the following diagram
+------+ +------+ +-------+ +------+
|TELNET| ...| FTP | |GATEWAY| ... | TAC | Application
+------+ +------+ +-------+ +------+
| | | |
| | | |
|__________| |_____________|
| |
+------+ +-------+
| TCP | | HMP | Transport
+------+ +-------+
| |
| |
+-------------------------------------+
| Internet Protocol & ICMP | Internetwork
+-------------------------------------+
|
+------------------------+
| Local Network Protocol | Network
+------------------------+
If internetwork services are not required it should be
to run the HMP without an Internetwork layer. As long as HMPs
service requirnments (addressing, protocol demultiplexing,
occasional delivery) are met it should run over a variety
protocols
-6-
RFC-869 December 1983
4 Protocol
The HMP is built around the idea that most of
intelligence needed to monitor a host should reside in
monitoring center, not in the host. The host should be
only to collect data and send it to the monitoring center,
spontaneously or on request from the monitoring center. The
is not responsible for insuring that the data arrives
(except that it checksums the data); instead, the
center is responsible for ensuring that the data it requests
received correctly
Consequently, the HMP is based on polling hosts
messages. When the monitoring center requires a particular
of data (e.g., throughput data), it sends a poll to the
requesting that type of report. The host, upon receiving
poll, responds with its latest set of collected data. If
host finds that the poll is incorrect (e.g., if the poll was
throughput data and the host is not collecting throughput data),
it responds with an error message. The monitoring center waits
reasonable length of time for the host to answer its poll. If
response is received, it sends another poll for the same data
In this way, if either a poll or the response is lost,
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
o Statistical data collected over
These classes of data allow a host to send data in a manner
suited to the data. For instance, the host may quickly
the monitoring center that a particular event has happened
sending a trap message, while the monitoring center is
collecting the host's throughput and accounting data
Traps report spontaneous events, as they occur, to
monitoring center. In order to insure their prompt delivery,
traps are sent as datagrams with no reliability
(except checksums) such as acknowledgments and retransmissions
Trap messages usually contain an identifier to indicate
event is being reported, the local time in the host that
event occured, and data pertinent to the event. The data
is intended to be host and event specific
Status information, the second type of data collected by
Host Monitoring Protocol describes the current state of the host
Status information is useful at one point, but it does not
to be collected cumulatively over a certain period of time.
the latest status is of interest; old status provides no
information. The monitoring center collects status
-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,
creating a new status message. If the monitoring center does
receive a response to its poll, it sends another poll.
monitoring center can decide if the host is up or down based
whether the host responds to its polls
The third type of data collected by the HMP is
data. These are measurements taken over time, such as the
of packets sent or received by a host and the count of
dropped for a particular reason. It is important that none
this type of data be lost. Statistical data is collected in
host over a time interval. When the collection time
expires, the current data is copied to another area, and
counters are cleared. The copied data is sent to the
center when the host receives a poll requesting
information. If another poll is received before the
time interval has expired, the data in the buffer is sent again
The monitoring center can detect duplicate messages by using
sequence number in the header of the message, since each type
statistical data has its own sequence number counter
The collection frequency for statistics messages from
particular host must be relatively long compared to the
round trip message time between the monitoring center and
host inorder to allow the monitoring center to re-poll if it
-9-
RFC-869 December 1983
not receive an answer. With this restriction, it should
possible to avoid missing any statistics messages.
statistics message contains a field giving the local time
the data was collected and the time at which the message
sent. This information allows the monitoring center to
when it sends a poll so that the poll arrives near the
of each collection period. This ensures that if a message
lost, the monitoring center will have sufficient time to
again for the statistics message for that period
The HMP also includes a provision to send data to and
parameters in hosts. The data may be used to set switches
interval timers used to control measurements in a host, or
control the host itself (e.g. a restart switch). The format
the data and parameters is host specific
To send data to a host, the monitoring center sends the
a poll for a control-acknowledgment message. This poll
includes the type of the data and the data being sent. When
host receives this poll, it processes the data and responds
a control-acknowledgment message
To read parameters in a host, the monitoring center
send a poll for parameters to the host. This poll includes
type of the parameters being read. When the host receives
poll, it will send the parameters of the requested type to
-10-
RFC-869 December 1983
monitoring center in a parameters message
-11-
RFC-869 December 1983
5 Header
Host Monitor Protocol messages have the following format
+----------------+
| Local Network |
| Header(s) |
+----------------+
| IP header |
+----------------+
| HMP |
| Header |
| |
+----------------+
| D |
| A |
| T |
| A |
+----------------+
| Padding |
+----------------+
5.1 IP
HMP messages are sent using the version 4 IP header as
in RFC-791 "Internet Protocol." The HMP protocol number is 20
(decimal). The time to live field should be set to a
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
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
Message
The combination of system type and message type
the format of the data in the monitoring message
The system types which have been defined are
System Type |
----------------+-----------------
1 | Monitoring
2 |
3 |
4 |
5 |
6 | BBN VAX/C70
7 |
8 |
9 |
10 |
11 | Cronus
12 | Cronus
-13-
RFC-869 December 1983
Message types are defined and used for each system
according to the needs of that system. The message
currently defined are
Type |
----------+--------------------------
|
1 |
2 |
3 |
4 | HTM - Host Traffic
5 |
6 |
7 | Call
|
100 |
101 |
102 | Control
Port
This field can be used to multiplex similar messages to/
different processes in one host. It is currently unused
Control
This field is used to pass control information.
Bit 15 is defined as the "More bit" which is used in
message in responce to a poll to indicate that there is
data to poll for
Sequence
Every message contains a sequence number. The
number is incremented when each new message of that type
sent
Password or Returned Sequence
The Password field of a polling message from an
center contains a password to verify that the
center is allowed to gather information. Responses
polling messages copy the Sequence Number from
polling message and return it in this field
-14-
RFC-869 December 1983
identification and round-trip time calculations
The Checksum field is the one's complement of the one'
complement sum of all the 16-bit words in the header
data area
-15-
RFC-869 December 1983
6 HMP Monitoring Center Message
6.1 Message Type 100: Polling
The monitoring center will send polls to the hosts it
monitoring to collect their monitoring data. When the
receives a poll it will return a message of the
requested. It will only answer a poll with the
system type and password and will return an error
(Message Type 101) if it receives a poll for the
system type or an unsupported message type
The Poll message includes a facility to send data to
monitored host. The poll message to send data consists of
poll for a Control Acknowledgment message (type 102)
followed by the data. The R-Subtype specifies the type
the data that is being sent. When the monitored
receives a Poll for a Control acknowledgment, it
the data, and then responds with an Control
message. If the monitored host can not process the data,
should respond with an error message
A poll to read parameters consists a poll for a
message. The R-Subtype specifies the type of
being read. When the monitored host receives a poll for
Parameters message, it responds with a Parameters
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
System
The type of machine being polled
Message
Polling Message = 100
Port
Control
Sequence
The sequence number identifies the polling request.
Monitoring Center will maintain separate sequence
for each host it monitors. This sequence number is
in the response to a poll and the monitoring center will
this information to associate polls with their responses
to determine round trip times
The monitoring password
POLL
R-Message
The message type requested
R-
This field is used when sending data and reading
and it specifies the type of the data being sent
parameters being read
When the poll is requesting a Control
message, data is included in the poll message. A poll
any other type of message does not include any data .
contents of the data is host specific
-17-
RFC-869 December 1983
6.2 Message Type 101: Error in
This message is sent in response to a faulty poll
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
System
The type of machine sending message
Message
Error Message = 101
Port
Control
Sequence
A 16 bit number incremented each time an error message
sent
Returned Sequence
The Sequence Number of the polling message which caused
error
-18-
RFC-869 December 1983
ERROR MESSAGE
Error
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
5 = Invalid parameter
6 = Invalid parameter/value
7 = Machine in
R-Message
R-
These fields identify the poll request in error
-19-
RFC-869 December 1983
6.3 Message Type 102: Control
This message is sent in response to a poll for this type
message. It is used to acknowledge poll messages that
used to set parameters in the monitored host
The Control acknowledgment has no fields other than the
header
HMP
System
The type of the system sending the message
Message
Control acknowledgment = 102
Port
Control
Sequence
A 16 bit number incremented each time a
acknowledgment message is sent
Returned Sequence
The Sequence Number of the polling message which
this message
-20-
RFC-869 December 1983
A Appendix A - IMP
A.1 Message Type 1: IMP
When a trap occurs, it is buffered in the IMP and sent
soon as possible. Trap messages are unsolicited. If
happen in close sequence, several traps may be sent in
message
Through the use of sequence numbers, it will be possible
determine how many traps are being lost. If it
discovered that many are lost, a polling scheme might
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
System
IMP = 2
Message
IMP Trap Message = 1
Port
-21-
RFC-869 December 1983
Control
Sequence
A 16 bit number incremented each time a trap message is
so that the HM can order the received trap messages
detect missed messages
IMP TRAP
# of traps
Under certain conditions, an IMP may overflow its
trap buffers and be unable to save traps to send.
counter keeps track of such occurrences
Trap
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 is the number of 16 bit words in the trap, not
the size field
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
associate groups of traps
Trap
This is usually the program counter at the trap. The
identifies the trap, and does not have to be a
counter, provided it uniquely identifies the trap
Trap
The IMP returns data giving more information about the trap
There are usually two entries: the values in the
and the index register at the occurrence of the trap
-23-
RFC-869 December 1983
A.2 Message Type 2: IMP
The status message gives a quick summary of the state of
IMP. Status of the most important features of the IMP
reported as well as the current configuration of
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
System
IMP = 2
Message
IMP status message = 2
Port
Control
Sequence
A 16 bit number incremented each time a status message
sent
The password contains the sequence number of the
message to which this message responds
IMP STATUS
Software Version
The IMP version number
-25-
RFC-869 December 1983
Last Trap
Contains the sequence number of the last trap message
to the HM. This will allow the HM to detect how many
messages are being lost
The number of configured hosts in this system
The number of configured modems in this system
The maximum possible number of IMP-IMP channels in
system
The maximum possible number of IMPs in this system
Package
This is a bit encoded word that reports the set of
currently loaded in the system. The table below defines
bits
-26-
RFC-869 December 1983
Bit
(octal
(1st Word
1
2 Logical address
4
10 Cumulative
20
40
100
200
400
1000 Cassette
2000 Propagation Delay
4000 X25
10000 Profile
20000 Self Authenticating
40000 Host traffic
100000 Experimental/
(2nd Word
1 End-to-end
2 Store and Forward
Crash
Crash data reports the circumstances surrounding
unexpected crash. The first word reports the location
the crash and the following two are the contents of
accumulator and index registers
Anomalies is a collection of bit flags that indicate
state of various switches or processes in the IMP.
are very machine dependent and only a
sampling of bits is listed below
Bit
(octal
20 Override
200 Trace
1000 Statistics
2000 Message Generator
4000 Packet Trace
10000 Host Data Checksum is
20000 Reload Location
-27-
RFC-869 December 1983
Buffer Pool
These are four bytes of counters indicating the
usage of buffers in the IMP. The four counters are:
buffers, store-and-forward buffers, reassembly buffers
allocated buffers
HIHD0 -
Each four bit HIHD field gives the state of
corresponding host
Value
0
1 ready line
2
3 non-
Modem State
Modem state data contains six fields of data
over four words. The first field (4 bits) indicates
line speed; the second field (4 bits) is the number of
modem that is used by the neighboring IMP on this line;
third field (8 bits) is the number of line protocol
covered by this report; the fourth (1 bit) indicates
down(1) or up(0); the fifth (7 bits) is the IMP number
neighbor IMP on the line; and the sixth (8 bits) is a
of missed protocol packets over the interval specified
the third field
-28-
RFC-869 December 1983
A.3 Message Type 3: IMP Modem
The modem throughput message reports traffic statistics
each modem in the system. The IMP will collect these data
regular intervals and save them awaiting a poll from the HM
If a period is missed by the HM, the new results
overwrite the old. Two time stamps bracket the
interval (data-time and prev-time) and are an indicator
missed reports. In addition, mess-time indicates the
at which the message was sent
The modem throughput message will accommodate up to
modems in one packet. A provision is made to split
into multiple packets by including a modem number for
first entry in the packet. This field is not
useful, but if machine sizes grow beyond fourteen modems
if modem statistics become more detailed and use more
three words per modem, this can be used to keep the
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
System
IMP = 2
Message
IMP Modem Throughput message = 3
Port
Control
Sequence
A 16 bit number incremented at each collection
(i.e. when a new throughput message is assembled). The
will be able to detect lost or duplicate messages
checking the sequence numbers
The password contains the sequence number of the
message to which this message responds
IMP MODEM THROUGHPUT
Mess-
The time (in 640ms. units) at which the message was sent
the HM
Software Version
The IMP version number
Data-
Data-time is the time (in 640ms. units) when this set
data was collected. (See Description.)
-30-
RFC-869 December 1983
Prev-
Prev-time is the time (in 640 ms. units) of the
collection of data (and therefore, is the time when the
in this message began accumulating.)
Total
This is the number of modems in the system
This
This Modem is the number of the first modem reported in
message. Large systems that are unable to fit all
modem reports into a single packet may use this field
separate their message into smaller chunks to take
of single packet message efficiencies
Modem
Modem throughput consists of three words of
reporting packets and words output on each modem.
first word counts packets output and the following
count word throughput. The double precision words
arranged high order first. (Note also that messages
Honeywell type machines (316s, 516s and C30s) use a
bit low order word.) The first block reports output on
modem specified by "This Modem". The following
report on consecutive modems
-31-
RFC-869 December 1983
A.4 Message Type 4: IMP Host
The host throughput message reports traffic statistics
each host in the system. The IMP will collect these data
regular intervals and save them awaiting a poll from the HM
If a period is missed by the HM, the new results
overwrite the old. Two time stamps bracket the
interval (data-time and prev-time) and are an indicator
missed reports. In addition, mess-time indicates the
at which the message was sent
The host throughput format will hold only three hosts
packet boundaries are to be respected. A provision is
to split this into multiple packets by including a
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
System
IMP = 2
Message
IMP host Throughput message = 4
-32-
RFC-869 December 1983
Port
Control
Sequence
A 16 bit number incremented at each collection
(i.e. when a new throughput message is assembled). The
will be able to detect lost or duplicate messages
checking the sequence numbers
The password contains the sequence number of the
message to which this message responds
IMP HOST THROUGHPUT
Mess-
The time (in 640ms. units) at which the message was sent
the HM
Software Version
The IMP version number
Data-
Data-time is the time (in 640ms. units) when this set
data was collected. (See Description.)
Prev-
Prev-time is the time (in 640 ms. units) of the
collection of data (and therefore, is the time when the
in this message began accumulating.)
Total
The total number of hosts in this system
This
This host is the number of the first host reported in
-33-
RFC-869 December 1983
message. Large systems that are unable to fit all
host reports into a single packet may use this field
separate their message into smaller chunks to take
of single packet message efficiencies
Host
Each host throughput block consists of eight words in
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
data. The first block will contain data for the
specified in First Host Number. Following blocks
contain data for consecutive hosts. All counters are
precision
-34-
RFC-869 December 1983
B Appendix B - TAC
B.1 Message Type 1: TAC Trap
When a trap occurs, it is buffered in the TAC and sent
soon as possible. Trap messages are unsolicited. If
happen in close sequence, several traps may be sent in
message
Through the use of sequence numbers, it will be possible
determine how many traps are being lost. If it
discovered that many are lost, a polling scheme might
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
System
TAC = 3
Message
TAC Trap Message = 1
Port
-35-
RFC-869 December 1983
Control
Password or Returned Sequence
Sequence
A 16 bit number incremented each time a trap message is
so that the HM can order the received trap messages
detect missed messages
TAC TRAP
Version #
The version # of the TAC Software
Trap
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 is the number of 16 bit words in the trap, not
the size field
The time (in 640ms. units) at which the trap occurred.
field is used to sequence the traps in a message
-36-
RFC-869 December 1983
associate groups of traps
Trap
This is (usually) the program counter at the trap. The
identifies the trap, and does not have to be a
counter, provided that it uniquely identifies the trap
Trap
The TAC returns data giving more information about the trap
There are usually two entries: the values in the
and the index register at the occurrence of the trap
The TAC Counts repetitions of the same trap ID and
this count here
-37-
RFC-869 December 1983
B.2 Message Type 2: TAC
The status message gives a quick summary of the state of
TAC. Status of the most important features of the TAC
reported as well as the current configuration of
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
System
TAC = 3
Message
TAC Status Message = 2
Port
Control
Sequence
A 16 bit number incremented each time a status message
sent
Returned Sequence
Contains the sequence number from the polling
requesting this report
TAC STATUS
Version
The TAC's software version number
Last Trap
Contains the sequence number of the last trap message
to the HM. This will allow the HM to detect how many
messages are being lost
-39-
RFC-869 December 1983
Bit
There are sixteen bit flags available for reporting
state of various switches (hardware and software) in
TAC. The bits are numbered as follows for purposes of
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
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
Free PDB
The number of PDBs on the free queue
Free MBLK
The number of MBLKs on the free queue
# of TCP
# of NCP
The number of open connections for each protocol
INA
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
meaningless
-40-
RFC-869 December 1983
Restart/
This word reports a restart or reload of the
Value
1
2
Crash
Crash data reports the circumstances surrounding
unexpected crash. The first word reports the location
the crash and the following two are the contents of
accumulator and index registers
-41-
RFC-869 December 1983
B.3 Message Type 3: TAC
The TAC throughput message reports statistics for
various modules of the TAC. The TAC will collect these
at regular intervals and save them awaiting a poll from
HM. If a period is missed by the HM, the new results
overwrite the old. Two time stamps bracket the
interval (data-time and prev-time) and are an indicator
missed reports. In addition, mess-time indicates the
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 |
+---------------+---------------+ ----
| # of datagrams sent | ^
+---------------+---------------+ |
| # of datagrams received | |
+---------------+---------------+ IP info
| # of datagrams discarded | |
+---------------+---------------+ |
| # of fragments received |
+---------------+---------------+ |
20 | # of fragments discarded |
+---------------+---------------+ ----
| # of segments sent | ^
+---------------+---------------+ |
| # of segments received | |
+---------------+---------------+ |
| # of segments discarded | |
+---------------+---------------+ TCP info
| # of octets sent | |
+---------------+---------------+ |
25 | # of octets received | |
+---------------+---------------+ |
| # of retransmissions |
+---------------+---------------+ ----
HMP
System
TAC = 3
Message
TAC Throughput Message = 3
Port
Control
-43-
RFC-869 December 1983
Sequence
A 16 bit number incremented at each collection
(i.e. when a new throughput message is assembled). The
will be able to detect lost or duplicate messages
checking the sequence numbers
Returned Sequence
Contains the sequence number from the polling
requesting this report
TAC THROUGHPUT
Mess-
The time (in 640ms. units) at which the message was sent
the HM
Data-
Data-time is the time (in 640ms. units) when this set
data was collected. (See Description.)
Prev-
Prev-time is the time (in 640 ms. units) of the
collection of data (and therefore, is the time when the
in this message began accumulating.)
Version
The TAC's software version number
Last Trap
Contains the sequence number of the last trap message
to the HM. This will allow the HM to detect how many
messages are being lost
Bit
There are sixteen bit flags available for reporting
state of various switches (hardware and software) in
TAC. The bits are numbered as follows for purposes of
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
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
Free PDB
The number of PDBs on the free queue
Free MBLK
The number of MBLKs on the free queue
# of TCP
# of NCP
The number of open connections for each protocol
1822 info
These six fields report statistics which concern
operation of the 1822 protocol module, i.e. the
between the TAC and its IMP
IP info
These five fields report statistics which concern
Protocol in the TAC
TCP info
-45-
RFC-869 December 1983
These six fields report statistics which concern
protocol in the TAC
-46-
RFC-869 December 1983
C Appendix C - Gateway
C.1 Gateway
The gateway supports parameters to set Throughput and
traffic matrix measurements. The type of parameters and
parameter and data pairs are as follows
Throughput - Type = 3
Parm. Description Control Data
----- ----------- -----------------
1 Start/Stop 0=Stop,1=
2 Collection Interval Time in 1
Host Traffic Matrix - Type = 4
Parm. Description Control Data
----- ----------- -----------------
1 Start/Stop 0=Stop,1=
2 Collection Interval Time in 1
3 HTM Switch Control Include
-47-
RFC-869 December 1983
C.2 Message Type 1: Gateway
When traps occur in the gateway they are buffered. At
fixed time interval (currently 10 seconds) the gateway
send any traps that are in the buffer to the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
System
Gateway = 4
Message
Gateway Trap Message = 1
Port
Control
Password or Returned Sequence
Sequence
A 16 bit number incremented each time a trap message is
so that the monitoring center can order the received
messages and detect missed messages
-49-
RFC-869 December 1983
GATEWAY TRAP
Gateway Version #
The software version number of the gateway sending the trap
Trap
The remainder of the trap message consists of the
reports. Each consists of the following fields
Size of Trap
The size in 16-bit words of the trap entry,
including the size field
Time of
The time in (in 1/60 sec. ticks) at which the
occurred
Trap
The number of the trap which is used to identify
trap
Process
The identifier of the process that executed the trap
R0-R
The registers of the machine at the occurrence of
trap
Count of this
The number of times that this trap occurred
-50-
RFC-869 December 1983
C.3 Message Type 2: Gateway
The gateway status message gives a summary of the status
the gateway. It reports information such as version
of the gateway, buffer memory usage, interface status
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Flags | ; Bit flags to indicate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; measurements are on, 1=
| Routing Sequence No. | ; Sequence # of last
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; update
| Access Table Version # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Sharing Table Ver. # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Memory in Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Memory Idle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Memory Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Blks | ; Memory Allocation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+ ; Bit 0 - 1=Up, 0=
; 1 - 1=Looped, 0=
+-+-+-+-+-+-+-+-+
| Buffers | ; # of buffers on write
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time since last Status Change | ;Time since last up/dwn
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Buffers Allocated |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Size for Interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface 1 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
+---------------+
| Int n Flags | ;Interface n Status
+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+ ; 0 = Dwn, 1 =
. ; MSB is neighbor 1
. ; (as many bytes as necessary
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor 1 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor n Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-53-
RFC-869 December 1983
HMP
System
Gateway = 4
Message
Gateway Status Message = 2
Port
Control
Password or Returned Sequence
Sequence
A 16 bit number incremented each time a trap message is
so that the monitoring center can order the received
messages and detect missed messages
GATEWAY STATUS
Version
The version number of the gateway sending the
message
Patch Version
The patch version number of the gateway
Time Since Gateway
The time in minutes since the gateway was last restarted
reloaded
-54-
RFC-869 December 1983
Measurement
Flags that, if set, indicate which measurements are
on. Current values are
Bit 0 = Message
1 =
2 = Host Traffic
3 = Access Control 1
4 = Access Control 2
5 = Load
6 = EGP in
Routing Sequence
The sequence number of the last routing update sent by
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
The number of bytes of buffer memory that are currently
use
Memory
The number of bytes of buffer memory that have
allocated but are currently idle
Memory
The number of bytes of buffer memory that has not
allocated
MEMORY ALLOCATION
The next part of the status message contains information
the buffer pools in the gateway. The fields are
# of
-55-
RFC-869 December 1983
The number of different buffer pools
Size of
The size of this block in bytes
#
The number of blocks of this size that have
allocated
#
The number of blocks of this size that are idle
GATEWAY INTERFACE
The next part of the status message are fields that
information about the gateway's interfaces. The fields are
# of
The number of network interfaces that the gateway has
Interface
Flags that indicate the status of this interface.
current values are
Bit 0 - 1=Up/0=
1 - 1=Looped/0=Not
The numbers on this interfaces write queue
Time Since Last Status
The time in minutes since this interface changed
(Up/Down).
# of Buffers
The number of buffers allocated for this interface
Data Size for
The buffer size required for this interface
-56-
RFC-869 December 1983
Interface
The Internet address of this interface
NEIGHBOR GATEWAY
The final part of the status message consists of
about this gateway's neighbor gateways. The fields are
# of
The number of gateways that are neighbor gateways
this gateway
UP/DN
Bit flags to indicate if the neighbor is up or down
Neighbor
The Internet address of the neighbor gateway
-57-
RFC-869 December 1983
C.4 Message Type 3: Gateway
The gateway collects throughput statistics for the gateway
its interfaces, and its neighbor gateways. It collects
for regular intervals an