GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc869
                          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

  1. 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. 1-

RFC-869 December 1983

   This document replaces the previous HMP document "IEN-197, A

Host Monitoring Protocol."

  1. 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:

  1. 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.
  1. 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.
  1. 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

  1. 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:

  1. 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.
  1. 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.
  1. 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.
  1. 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:

  1. The monitoring host must be able to route this message to

the correct process. The "port number" field meets this

   need.
  1. 4-

RFC-869 December 1983

  1. 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.
  1. 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.
  1. 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.

  1. 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.

  1. 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.

  1. 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

  1. 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

  1. 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

  1. 10-

RFC-869 December 1983

monitoring center in a parameters message.

  1. 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.

  1. 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
  1. 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
  1. 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.
  1. 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 |                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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
  1. 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.
  1. 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.
  1. 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.)
  1. 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.
  1. 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.
  1. 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
  1. 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.
  1. 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           :
               +---------------+---------------+
  1. 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.)
  1. 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.
  1. 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
  1. 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
  1. 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.
  1. 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
  1. 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
  1. 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.
  1. 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 |                               |
               +---------------+---------------+
  1. 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.
  1. 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.
  1. 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.
  1. 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)
  1. 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
  1. 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.
  1. 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.

  1. 45-

RFC-869 December 1983

   These  six  fields  report  statistics  which  concern   TCP
   protocol in the TAC.
  1. 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
  1. 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)
  1. 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.
  1. 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.
  1. 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:
  1. 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)
  1. 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                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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.
  1. 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
  1. 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.
  1. 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.
  1. 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)
  1. 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)
  1. 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
  1. 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.
  1. 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.
  1. 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.
  1. 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                                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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.
  1. 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.
  1. 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)
  1. 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.
  1. 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:
  1. 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.
  1. 70-
/data/webs/external/dokuwiki/data/pages/rfc/rfc869.txt · Last modified: 1992/09/23 20:18 (external edit)