From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc869.txt | 4171 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 4171 insertions(+)
 create mode 100644 doc/rfc/rfc869.txt

(limited to 'doc/rfc/rfc869.txt')

diff --git a/doc/rfc/rfc869.txt b/doc/rfc/rfc869.txt
new file mode 100644
index 0000000..9bcb871
--- /dev/null
+++ b/doc/rfc/rfc869.txt
@@ -0,0 +1,4171 @@
+
+
+
+
+                            RFC - 869
+
+
+
+
+
+
+                   A Host Monitoring Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        Robert M. Hinden
+
+
+
+
+
+                 BBN Communications Corporation
+
+
+
+
+
+                          December 1983
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RFC-869                                             December 1983
+
+
+
+                        Table of Contents
+
+
+
+
+
+1   Introduction.......................................... 1
+
+2   General Description................................... 3
+
+3   Relationship to Other Protocols....................... 6
+
+4   Protocol Operation.................................... 7
+
+5   Header Formats....................................... 12
+5.1   IP Headers......................................... 12
+5.2   HMP Header......................................... 13
+
+6   HMP Monitoring Center Message Formats................ 16
+6.1   Message Type 100: Polling Message.................. 16
+6.2   Message Type 101: Error in Poll.................... 18
+6.3   Message Type 102: Control acknowledgment........... 20
+
+A   Appendix A - IMP Monitoring.......................... 21
+A.1   Message Type 1: IMP Trap........................... 21
+A.2   Message Type 2: IMP status......................... 24
+A.3   Message Type 3: IMP Modem Throughput............... 29
+A.4   Message Type 4: IMP Host Throughput................ 32
+
+B   Appendix B - TAC Monitoring.......................... 35
+B.1   Message Type 1: TAC Trap Message................... 35
+B.2   Message Type 2: TAC Status......................... 38
+B.3   Message Type 3: TAC Throughput..................... 42
+
+C   Appendix C - Gateway Monitoring...................... 47
+C.1   Gateway Parameters................................. 47
+C.2   Message Type 1: Gateway Trap....................... 48
+C.3   Message Type 2: Gateway Status..................... 51
+C.4   Message Type 3: Gateway Throughput................. 58
+C.5   Message Type 4: Gateway Host Traffic Matrix........ 64
+C.6   Message Type 6: Gateway Routing.................... 67
+
+
+
+
+
+
+
+
+
+
+                               -i-
+
+
+RFC-869                                             December 1983
+Replaces IEN-197
+
+
+                   A Host Monitoring Protocol
+
+
+
+
+
+1  Introduction
+
+
+     The Host Monitoring   Protocol  (HMP)  is  used  to  collect
+
+information  from  hosts   in   various   networks.    A  host is
+
+defined as an addressable  Internet  entity  that  can  send  and
+
+receive  messages;  this  includes  hosts  such  as server hosts,
+
+personal work stations, terminal concentrators, packet  switches,
+
+and  gateways.  At present  the Host Monitoring Protocol is being
+
+used to collect information from Internet Gateways and TACs,  and
+
+implementations  are  being  designed  for  other  hosts.   It is
+
+designed to monitor hosts spread over the  internet  as  well  as
+
+hosts in a single network.
+
+
+     This document is organized into three parts.  Section 2  and
+
+3  contains a general description of the Host Monitoring protocol
+
+and its relationship to other  protocols.   Section  4  describes
+
+how  it  operates.   Section 5 and 6 contain the descriptions and
+
+formats of the HMP messages.  These are  followed  by  appendices
+
+containing the formats of messages sent by some of the hosts that
+
+use the HMP  to  collect  their  monitoring  information.   These
+
+appendicies included as examples only and are not part of the HMP
+
+protocol.
+
+
+
+
+                               -1-
+
+
+RFC-869                                             December 1983
+
+
+
+     This document replaces the previous HMP document "IEN-197, A
+
+Host Monitoring Protocol."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                               -2-
+
+
+RFC-869                                             December 1983
+
+
+
+2  General Description
+
+
+     The  Host  Monitoring  Protocol  is  a  transaction-oriented
+
+(i.e.,  connection-less)  transport protocol.  It was designed to
+
+facilitate  certain  simple  interactions  between  two  internet
+
+entities,  one  of which may be considered to be "monitoring" the
+
+other.  (In discussing the protocol we will sometimes speak of  a
+
+"monitoring host" and a "monitored entity".)  HMP was intended to
+
+be a useful transport protocol for applications that involve  any
+
+or all of the following three different kinds of interactions:
+
+
+   - The monitored entity sometimes  needs  to  send  unsolicited
+     datagrams  to  the  monitoring  host.   The  monitoring host
+     should be able to tell  when  messages  from  the  monitored
+     entity  have  been lost in transit, and it should be able to
+     determine the order in which the messages were sent, but the
+     application  does  not require that all messages be received
+     or that they be received strictly in the  same  sequence  in
+     which they were sent.
+
+   - The monitoring host needs to gather data from the  monitored
+     entity by using a query-response protocol at the application
+     level.  It is important to be able to determine which  query
+     is being answered by a particular response, and to determine
+     whether successive  responses  are  duplicates  of  previous
+     ones.
+
+   - The monitoring host must be able to initiate certain control
+     functions  in  the  monitored entity, possibly including the
+     setting  of  parameters  in  the  monitored   entity.    The
+     monitoring  host  needs  to know if the control function has
+     been carried out.
+
+
+     In addition, we assume that a given monitoring host  may  be
+
+monitoring  several  different  types of entities simultaneously,
+
+and may be gathering several different types of data from a given
+
+
+
+                               -3-
+
+
+RFC-869                                             December 1983
+
+
+
+type of monitored entity.  Several different monitoring hosts may
+
+be monitoring a given entity, and several processes on  the  same
+
+host may even be monitoring the same entity.
+
+
+     Messages from the monitoring host to  the  monitored  entity
+
+are  called  "polls".  They need to contain enough information to
+
+allow the monitored entity to make the following determinations:
+
+
+   - The monitored entity must be able  to  determine  that  this
+     message  is  in  fact  a  poll  from a monitoring host.  The
+     "system type," "message type," and "password" fields in  the
+     HMP header have been defined to meet this need.
+
+   - The monitored entity may need to be  able  to  identify  the
+     particular  process  on  the  monitoring host that sent this
+     poll, so it can send its response back to the right process.
+     The  "port  number" field in the HMP header has been defined
+     to meet this need.
+
+   - The monitored  entity  must  be  able  to  indicate  to  the
+     monitoring  host,  in its response, precisely which query is
+     being answered by  a  particular  response.   The  "sequence
+     number field" has been defined to meet this need.
+
+   - The monitored entity must be able  to  determine  just  what
+     kind  of action the monitoring host is requesting.  That is,
+     the  HMP  transport  protocol  must  provide  some  way   of
+     multiplexing  and  demultiplexing  the  various higher-level
+     applications which use it.  The  "R-message  type"  and  "R-
+     subtype"  fields of the polling message have been defined to
+     meet this need.
+
+
+     Messages from the monitored entity to  the  monitoring  host
+
+need  to contain enough information to enable the monitoring host
+
+to make the following determination:
+
+
+   - The monitoring host must be able to route  this  message  to
+     the  correct  process.   The  "port number" field meets this
+     need.
+
+
+                               -4-
+
+
+RFC-869                                             December 1983
+
+
+
+   - The monitoring host  must  be  able  to  match  up  received
+     messages  with  the  polls, if any, that elicited them.  The
+     "returned sequence number" field in the HMP header has  been
+     defined to meet this need.
+
+   - The monitoring host must be able to determine  which  higher
+     level  application should receive a particular message.  The
+     "system type" and "message type" fields are  used  for  this
+     purpose.
+
+   - The monitoring host must be able to determine  whether  some
+     messages  of  a given type were lost in transit, and whether
+     messages  have  arrived  out  of  sequence.   Although  this
+     function,  strictly speaking, belongs to the application and
+     not to the  transport  layer,  the  HMP  header  contains  a
+     "sequence number" for this purpose.
+
+
+     In addition, a simple one's complement checksum is  provided
+
+in the HMP header to detect data corruption during transmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                               -5-
+
+
+RFC-869                                             December 1983
+
+
+
+3  Relationship to Other Protocols
+
+
+     The  Host  Monitoring  Protocol  is  a  transport   protocol
+
+designed  to  fit into the layered internet protocol environment.
+
+It operates on  top  of  the  Internet/ICMP  protocol  and  under
+
+applications  that  require  its  services.  This relationship is
+
+illustrated in the following diagram:
+
+
+     +------+    +------+  +-------+      +------+
+     |TELNET| ...|  FTP |  |GATEWAY|  ... | TAC  |   Application Layer
+     +------+    +------+  +-------+      +------+
+        |          |           |             |
+        |          |           |             |
+        |__________|           |_____________|
+              |                       |
+           +------+               +-------+
+           |  TCP |               |  HMP  |          Transport Layer
+           +------+               +-------+
+              |                       |
+              |                       |
+           +-------------------------------------+
+           |    Internet Protocol & ICMP         |   Internetwork Layer
+           +-------------------------------------+
+                              |
+                  +------------------------+
+                  | Local Network Protocol |         Network Layer
+                  +------------------------+
+
+
+If internetwork services are not required it should  be  possible
+
+to  run  the HMP without an Internetwork layer.  As long as HMPs'
+
+service requirnments (addressing,  protocol  demultiplexing,  and
+
+occasional  delivery)  are  met  it  should run over a variety of
+
+protocols.
+
+
+
+
+
+
+
+                               -6-
+
+
+RFC-869                                             December 1983
+
+
+
+4  Protocol Operation
+
+
+     The  HMP  is  built  around  the  idea  that  most  of   the
+
+intelligence  needed  to  monitor  a  host  should  reside  in  a
+
+monitoring center, not in the host.  The host should be  required
+
+only to collect data and send it to the monitoring center, either
+
+spontaneously or on request from the monitoring center.  The host
+
+is  not  responsible  for insuring that the data arrives reliably
+
+(except that it checksums  the  data);  instead,  the  monitoring
+
+center  is  responsible for ensuring that the data it requests is
+
+received correctly.
+
+
+     Consequently,  the  HMP  is  based  on  polling  hosts   for
+
+messages.   When the monitoring center requires a particular type
+
+of data (e.g., throughput data), it sends  a  poll  to  the  host
+
+requesting  that  type  of  report.  The host, upon receiving the
+
+poll, responds with its latest set of  collected  data.   If  the
+
+host  finds that the poll is incorrect (e.g., if the poll was for
+
+throughput data and the host is not collecting throughput  data),
+
+it responds with an error message.  The monitoring center waits a
+
+reasonable length of time for the host to answer its poll.  If no
+
+response  is  received,  it sends another poll for the same data.
+
+In this way, if either a  poll  or  the  response  is  lost,  the
+
+correct data is still collected.
+
+
+
+
+
+
+                               -7-
+
+
+RFC-869                                             December 1983
+
+
+
+     The HMP is used to collect three different classes of data:
+
+
+     o  Spontaneous Events (or Traps)
+
+     o  Current status
+
+     o  Statistical data collected over time
+
+
+These classes of data allow a host to send data in a manner  best
+
+suited  to  the  data.  For instance, the host may quickly inform
+
+the monitoring center that a particular  event  has  happened  by
+
+sending  a  trap message, while the monitoring center is reliably
+
+collecting the host's throughput and accounting data.
+
+
+     Traps report spontaneous  events,  as  they  occur,  to  the
+
+monitoring center.  In order to insure their prompt delivery, the
+
+traps are  sent  as  datagrams  with  no  reliability  mechanisms
+
+(except  checksums)  such as acknowledgments and retransmissions.
+
+Trap messages usually contain an  identifier  to  indicate  which
+
+event  is  being  reported,  the  local time in the host that the
+
+event occured, and data pertinent to the event.  The data portion
+
+is intended to be host and event specific.
+
+
+     Status information, the second type of data collected by the
+
+Host Monitoring Protocol describes the current state of the host.
+
+Status information is useful at one point, but it does  not  have
+
+to be collected cumulatively over a certain period of time.  Only
+
+the latest status is of interest; old status provides  no  useful
+
+information.   The  monitoring center collects status information
+
+
+                               -8-
+
+
+RFC-869                                             December 1983
+
+
+
+by sending a poll for status to a host.  Upon receiving the poll,
+
+the  host  responds  with  its  latest status information, always
+
+creating a new status message.  If the monitoring center does not
+
+receive  a  response  to  its  poll,  it sends another poll.  The
+
+monitoring center can decide if the host is up or down  based  on
+
+whether the host responds to its polls.
+
+
+     The third type of data collected by the HMP  is  statistical
+
+data.  These are measurements taken over time, such as the number
+
+of packets sent or received by a host and the  count  of  packets
+
+dropped  for  a  particular reason.  It is important that none of
+
+this type of data be lost.  Statistical data is  collected  in  a
+
+host  over  a  time  interval.  When the collection time interval
+
+expires, the current data is copied  to  another  area,  and  the
+
+counters  are cleared.  The copied data is sent to the monitoring
+
+center when the  host  receives  a  poll  requesting  statistical
+
+information.   If  another poll is received before the collection
+
+time interval has expired, the data in the buffer is sent  again.
+
+The  monitoring center can detect duplicate messages by using the
+
+sequence number in the header of the message, since each type  of
+
+statistical data has its own sequence number counter.
+
+
+     The collection frequency  for  statistics  messages  from  a
+
+particular  host  must be relatively long compared to the average
+
+round trip message time between the monitoring  center  and  that
+
+host inorder to allow the monitoring center to re-poll if it does
+
+
+                               -9-
+
+
+RFC-869                                             December 1983
+
+
+
+not receive an answer.   With  this  restriction,  it  should  be
+
+possible   to   avoid  missing  any  statistics  messages.   Each
+
+statistics message contains a field giving the  local  time  when
+
+the  data  was  collected  and  the time at which the message was
+
+sent.  This information allows the monitoring center to  schedule
+
+when  it sends a poll so that the poll arrives near the beginning
+
+of each collection period.  This ensures that  if  a  message  is
+
+lost,  the  monitoring  center  will have sufficient time to poll
+
+again for the statistics message for that period.
+
+
+     The HMP also includes a provision to send data to  and  read
+
+parameters  in  hosts.   The  data may be used to set switches or
+
+interval timers used to control measurements in  a  host,  or  to
+
+control  the  host itself (e.g. a restart switch).  The format of
+
+the data and parameters is host specific.
+
+
+     To send data to a host, the monitoring center sends the host
+
+a  poll  for a control-acknowledgment message.  This poll message
+
+includes the type of the data and the data being sent.  When  the
+
+host  receives this poll, it processes the data and responds with
+
+a control-acknowledgment message.
+
+
+     To read parameters in a host,  the  monitoring  center  will
+
+send  a  poll for parameters to the host.  This poll includes the
+
+type of the parameters being read.  When the host  receives  this
+
+poll,  it  will  send the parameters of the requested type to the
+
+
+
+                              -10-
+
+
+RFC-869                                             December 1983
+
+
+
+monitoring center in a parameters message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -11-
+
+
+RFC-869                                             December 1983
+
+
+
+5  Header Formats
+
+
+     Host Monitor Protocol messages have the following format:
+
+                    +----------------+
+                    |  Local Network |
+                    |    Header(s)   |
+                    +----------------+
+                    |  IP header     |
+                    +----------------+
+                    |      HMP       |
+                    |     Header     |
+                    |                |
+                    +----------------+
+                    |    D           |
+                    |      A         |
+                    |        T       |
+                    |          A     |
+                    +----------------+
+                    |  Padding       |
+                    +----------------+
+
+
+
+
+
+5.1  IP Headers
+
+HMP messages are sent using the version 4 IP header as  described
+in  RFC-791  "Internet  Protocol."  The HMP protocol number is 20
+(decimal).  The time to live field should be set to a  reasonable
+value for the hosts being monitored.
+
+All other fields should be set as specified in RFC-791.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -12-
+
+
+RFC-869                                             December 1983
+
+
+
+5.2  HMP Header
+
+The HMP header format is:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |  System Type  | Message Type  |
+                 +---------------+---------------+
+               1 |  Port Number  | Control Flag  |
+                 +---------------+---------------+
+               2 |        Sequence Number        |
+                 +---------------+---------------+
+               3 |  Password or Returned Seq. #  |
+                 +---------------+---------------+
+               4 |   One's Complement Checksum   |
+                 +---------------+---------------+
+
+HMP FIELDS:
+
+System Type
+Message Type
+
+     The combination  of system type and message type  determines
+     the format of the data in the monitoring message.
+
+     The system types which have been defined are:
+
+
+                   System Type  | Meaning
+                ----------------+-----------------
+                       1        | Monitoring Host
+                       2        | IMP
+                       3        | TAC
+                       4        | Gateway
+                       5        | SIMP
+                       6        | BBN VAX/C70 TCP
+                       7        | PAD
+                       8        | Reserved
+                       9        | TIU
+                       10       | FEP
+                       11       | Cronus Host
+                       12       | Cronus MCS
+
+
+
+
+
+
+
+
+                              -13-
+
+
+RFC-869                                             December 1983
+
+
+
+     Message types are defined and  used  for  each  system  type
+     according  to  the  needs of that system.  The message types
+     currently defined are:
+
+
+
+                    Type   | Description
+                 ----------+--------------------------
+                           |
+                    1      | Trap
+                    2      | Status
+                    3      | Thruput
+                    4      | HTM - Host Traffic Matrix
+                    5      | Parameters
+                    6      | Routing
+                    7      | Call Accounting
+                           |
+                    100    | Poll
+                    101    | Error
+                    102    | Control Acknowledgment
+
+
+
+
+Port Number
+
+     This field can be used to multiplex similar messages to/from
+     different processes in one host.  It is currently unused.
+
+Control Flag
+
+     This field is used to pass control  information.   Currently
+     Bit  15  is  defined  as  the  "More bit" which is used in a
+     message in responce to a poll to indicate that there is more
+     data to poll for.
+
+Sequence Number
+
+     Every message contains  a  sequence  number.   The  sequence
+     number  is incremented when each new message of that type is
+     sent.
+
+Password or Returned Sequence Number
+
+     The  Password field of a polling message from an  monitoring
+     center  contains a password to  verify  that the  monitoring
+     center is  allowed  to  gather  information.   Responses  to
+     polling   messages   copy   the  Sequence  Number  from  the
+     polling  message   and  return  it   in   this   field   for
+
+
+                              -14-
+
+
+RFC-869                                             December 1983
+
+
+
+     identification and round-trip time calculations.
+
+Checksum
+
+     The  Checksum  field  is  the one's complement of the  one's
+     complement  sum of all the 16-bit words in  the  header  and
+     data  area.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -15-
+
+
+RFC-869                                             December 1983
+
+
+
+6  HMP Monitoring Center Message Formats
+
+6.1  Message Type 100: Polling Message
+
+Description
+
+     The monitoring center will send polls to  the  hosts  it  is
+     monitoring  to  collect their monitoring data. When the host
+     receives a poll it will  return   a   message  of  the  type
+     requested.   It   will  only  answer a poll with the correct
+     system type and password and will return  an  error  message
+     (Message  Type  101)  if  it  receives  a poll for the wrong
+     system type or an unsupported message type.
+
+     The Poll message includes a  facility  to  send  data  to  a
+     monitored host.  The poll message to send data consists of a
+     poll  for  a  Control  Acknowledgment  message  (type   102)
+     followed  by  the data.  The R-Subtype specifies the type of
+     the data that  is  being  sent.   When  the  monitored  host
+     receives  a  Poll for a Control acknowledgment, it processes
+     the data, and then responds with an  Control  acknowledgment
+     message.  If the monitored host can not process the data, it
+     should respond with an error message.
+
+     A poll to read parameters consists a poll for  a  Parameters
+     message.   The  R-Subtype  specifies  the type of parameters
+     being read.  When the monitored host receives a poll  for  a
+     Parameters  message,  it  responds with a Parameters message
+     containing the requested information.
+
+     A polling message has the following form:
+
+              0             0 0             1
+              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+             +---------------+---------------+
+           0 | R-Message Type|   R-Subtype   |
+             +---------------+---------------+
+
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           1 |             Data              |
+             +                               +
+           2 |                               |
+             +                               +
+             .                               .
+             .                               .
+           n |                               |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+                              -16-
+
+
+RFC-869                                             December 1983
+
+
+
+HMP FIELDS
+
+System Type
+
+     The type of machine being polled.
+
+Message Type
+
+     Polling Message = 100
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     The sequence number identifies  the  polling  request.   The
+     Monitoring  Center  will  maintain separate sequence numbers
+     for each host it monitors.  This sequence number is returned
+     in the response to a poll and the monitoring center will use
+     this information to associate polls with their responses and
+     to determine round trip times.
+
+Password
+
+     The monitoring password.
+
+POLL FIELDS
+
+R-Message Type
+
+     The message type requested.
+
+R-Subtype
+
+     This field is used when sending data and reading  parameters
+     and  it  specifies  the  type  of  the  data  being  sent or
+     parameters being read.
+
+Data
+
+     When  the  poll  is  requesting  a  Control   Acknowledgment
+     message,  data  is included in the poll message.  A poll for
+     any other type of message does not include any data  .   The
+     contents of the data is host specific.
+
+
+                              -17-
+
+
+RFC-869                                             December 1983
+
+
+
+6.2  Message Type 101: Error in Poll
+
+Description
+
+     This message is sent  in  response  to  a  faulty  poll  and
+     specifies the nature of the error.
+
+     An error message has the following form:
+
+              0             0 0             1
+              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+             +---------------+---------------+
+           0 |          Error Type           |
+             +---------------+---------------+
+           1 | R-Message Type|   R-Subtype   |
+             +---------------+---------------+
+
+HMP FIELDS
+
+System Type
+
+     The type of machine sending message.
+
+Message Type
+
+     Error Message = 101
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time an  error  message  is
+     sent.
+
+Returned Sequence Number
+
+     The Sequence Number of the polling message which caused  the
+     error.
+
+
+
+
+
+
+
+                              -18-
+
+
+RFC-869                                             December 1983
+
+
+
+ERROR MESSAGE FIELDS
+
+Error Type
+
+     This field specifies the nature of the error  in  the  poll.
+     The following error types have been defined.
+
+
+                 1 = Reason unspecified.
+                 2 = Bad R-Message Type.
+                 3 = Bad R-Subtype.
+                 4 = Unknown parameter
+                 5 = Invalid parameter value
+                 6 = Invalid parameter/value format
+                 7 = Machine in Loader
+
+R-Message Type
+R-Subtype
+
+     These fields identify the poll request in error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -19-
+
+
+RFC-869                                             December 1983
+
+
+
+6.3  Message Type 102: Control acknowledgment
+
+Description
+
+     This message is sent in response to a poll for this type  of
+     message.   It  is used to acknowledge poll messages that are
+     used to set parameters in the monitored host.
+
+     The Control acknowledgment has no fields other than the  HMP
+     header.
+
+HMP FIELDS
+
+System Type
+
+     The type of the system sending the message.
+
+Message Type
+
+     Control acknowledgment = 102
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A  16  bit  number   incremented   each   time   a   Control
+     acknowledgment message is sent.
+
+Returned Sequence Number
+
+     The Sequence Number of the polling message  which  requested
+     this message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -20-
+
+
+RFC-869                                             December 1983
+
+
+
+A  Appendix A - IMP Monitoring
+
+A.1  Message Type 1: IMP Trap
+
+Description
+
+     When a trap occurs, it is buffered in the IMP  and  sent  as
+     soon  as possible.  Trap messages are unsolicited.  If traps
+     happen in close sequence, several traps may be sent  in  one
+     message.
+
+     Through the use of sequence numbers, it will be possible  to
+     determine   how  many  traps  are  being  lost.   If  it  is
+     discovered that many are lost, a  polling  scheme  might  be
+     implemented for traps.
+
+     A IMP trap message has the following form:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |       # of traps lost         |
+                 +---------------+---------------+
+               1 :         first                 :
+               . :             trap              :
+               . :                 data          :
+               . +---------------+---------------+
+               . :         additional            :
+               . :             trap              :
+               . :                 data          :
+                 +---------------+---------------+
+
+
+HMP Fields
+
+System Type
+
+     IMP = 2
+
+Message Type
+
+     IMP Trap Message = 1
+
+Port Number
+
+     Unused
+
+
+
+
+
+                              -21-
+
+
+RFC-869                                             December 1983
+
+
+
+Control Flag
+
+     Unused
+
+Password
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  HM  can  order the received trap messages and
+     detect missed messages.
+
+IMP TRAP FIELDS
+
+# of traps lost
+
+     Under certain conditions, an IMP may overflow  its  internal
+     trap  buffers  and  be  unable  to save traps to send.  This
+     counter keeps track of such occurrences.
+
+Trap Reports
+
+     There can be several blocks of trap data  in  each  message.
+     The format for each such block is below.
+
+
+
+                 +---------------+---------------+
+                 |             Size              |
+                 +---------------+---------------+
+                 |             Time              |
+                 +---------------+---------------+
+                 |            Trap ID            |
+                 +---------------+---------------+
+                 :             Trap              :
+                 :             Data              :
+                 +---------------+---------------+
+
+
+  Size
+
+     Size is the number of 16 bit words in the trap, not counting
+     the size field.
+
+  Time
+
+     The time (in 640 ms. units)  at  which  the  trap  occurred.
+
+
+                              -22-
+
+
+RFC-869                                             December 1983
+
+
+
+     This  field  is  used to sequence the traps in a message and
+     associate groups of traps.
+
+  Trap ID
+
+     This is usually the program counter at  the  trap.   The  ID
+     identifies  the  trap,  and  does  not  have to be a program
+     counter, provided it uniquely identifies the trap.
+
+  Trap Data
+
+     The IMP returns data giving more information about the trap.
+     There are usually two entries: the values in the accumulator
+     and the index register at the occurrence of the trap.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -23-
+
+
+RFC-869                                             December 1983
+
+
+
+A.2  Message Type 2: IMP status
+
+Description
+
+     The status message gives a quick summary of the state of the
+     IMP.   Status  of the most important features of the IMP are
+     reported  as  well  as  the  current  configuration  of  the
+     machine.
+
+     The format of the status message is as follows:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |    Software Version Number    |
+                 +---------------+---------------+
+                 |       Last Trap Message       |
+                 +---------------+---------------+
+                 | Max # Hosts   | Max # Modems  |
+                 +---------------+---------------+
+                 | Max # Channels|  Max # IMPs   |
+                 +---------------+---------------+
+                 |      Package bits 0-15.       |
+                 +---------------+---------------+
+               5 |      Package bits 16.-31.     |
+                 +---------------+---------------+
+                 |                               |
+                 +          Crash                +
+                 |                               |
+                 +                Data           +
+                 |                               |
+                 +---------------+---------------+
+                 |           Anomalies           |
+                 +---------------+---------------+
+              10 |   Free Pool   |   S+F Pool    |
+                 +---------------+---------------+
+                 |Reassembly Pool| Allocated Pool|
+                 +---------------+---------------+
+                 | HIHD0 | HIHD1 | HIHD2 | HIHD3 |
+               . +---------------+---------------+
+               . : HIHD4 | ...............       :
+               . +---------------+---------------+
+                             (cont.)
+
+
+
+
+
+
+
+
+                              -24-
+
+
+RFC-869                                             December 1983
+
+
+
+
+
+     Imp Status (cont.)
+
+               . +---------------+---------------+
+               . |        Modem                  |
+               . +             State             +
+               . |                  Data         |
+               . +---------------+---------------+
+               . :         Modem   State         :
+               . :             Data......        :
+                 +---------------+---------------+
+
+
+
+HMP FIELDS
+
+System Type
+
+     IMP = 2
+
+Message Type
+
+     IMP status message = 2
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a  status  message  is
+     sent.
+
+Password
+
+     The password contains the sequence  number  of  the  polling
+     message to which this message responds.
+
+IMP STATUS FIELDS
+
+Software Version Number
+
+     The IMP version number.
+
+
+
+                              -25-
+
+
+RFC-869                                             December 1983
+
+
+
+Last Trap Message
+
+     Contains the sequence number of the last trap  message  sent
+     to  the  HM.  This will allow the HM to detect how many trap
+     messages are being lost.
+
+Hosts
+
+     The number of configured hosts in this system.
+
+Modems
+
+     The number of configured modems in this system.
+
+Channels
+
+     The maximum possible number  of  IMP-IMP  channels  in  this
+     system.
+
+IMPs
+
+     The maximum possible number of IMPs in this system.
+
+Package Bits
+
+     This is a bit encoded word that reports the set of  packages
+     currently loaded in the system.  The table below defines the
+     bits.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -26-
+
+
+RFC-869                                             December 1983
+
+
+
+
+                    Bit    Package
+                 (octal)
+                (1st Word)
+                    1      VDH
+                    2      Logical address tables
+                    4      Mezmode
+                   10      Cumulative Statistics
+                   20      Trace
+                   40      TTY
+                  100      DDT
+                  200      HDLC
+                  400      HDH
+                 1000      Cassette Writer
+                 2000      Propagation Delay Measurement
+                 4000      X25
+                10000      Profile Measurements
+                20000      Self Authenticating Password
+                40000      Host traffic Matrix
+               100000      Experimental/Special
+
+                (2nd Word)
+                    1      End-to-end Statistics
+                    2      Store and Forward statistics
+
+Crash Data
+
+     Crash  data  reports  the   circumstances   surrounding   an
+     unexpected  crash.   The  first word reports the location of
+     the crash and the following two  are  the  contents  of  the
+     accumulator and index registers.
+
+Anomalies
+
+     Anomalies is a collection of bit  flags  that  indicate  the
+     state  of  various  switches or processes in the IMP.  These
+     are  very  machine  dependent  and  only  a   representative
+     sampling of bits is listed below.
+
+               Bit       Meaning
+             (octal)
+               20      Override ON
+              200      Trace ON
+             1000      Statistics ON
+             2000      Message Generator ON
+             4000      Packet Trace ON
+            10000      Host Data Checksum is BAD
+            20000      Reload Location SET
+
+
+
+                              -27-
+
+
+RFC-869                                             December 1983
+
+
+
+Buffer Pool Counts
+
+     These are four bytes  of  counters  indicating  the  current
+     usage  of  buffers in the IMP.   The four counters are: free
+     buffers, store-and-forward buffers, reassembly  buffers  and
+     allocated buffers.
+
+HIHD0 - HIHDn
+
+     Each  four  bit  HIHD  field  gives   the   state   of   the
+     corresponding host.
+
+           Value   Meaning
+             0       UP
+             1       ready line down
+             2       tardy
+             3       non-existent
+
+
+
+Modem State Data
+
+     Modem state data contains six  fields  of  data  distributed
+     over  four  words.   The  first field (4 bits) indicates the
+     line speed; the second field (4 bits) is the number  of  the
+     modem  that is used by the neighboring IMP on this line; the
+     third field (8 bits) is the number of  line  protocol  ticks
+     covered  by  this  report; the fourth (1 bit) indicates line
+     down(1) or up(0); the fifth (7 bits) is the  IMP  number  of
+     neighbor  IMP on the line; and the sixth (8 bits) is a count
+     of missed protocol packets over the  interval  specified  in
+     the third field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -28-
+
+
+RFC-869                                             December 1983
+
+
+
+A.3  Message Type 3: IMP Modem Throughput
+
+Description
+
+     The modem throughput message reports traffic statistics  for
+     each modem in the system. The IMP will collect these data at
+     regular intervals and save them awaiting a poll from the HM.
+     If  a  period  is  missed  by the HM, the new results simply
+     overwrite the old.  Two time stamps bracket  the  collection
+     interval  (data-time  and prev-time) and are an indicator of
+     missed reports.  In addition, mess-time indicates  the  time
+     at which the message was sent.
+
+     The modem throughput message will accommodate up to fourteen
+     modems  in  one  packet.   A provision is made to split this
+     into multiple packets by including a modem  number  for  the
+     first  entry  in  the packet.  This field is not immediately
+     useful, but if machine sizes grow beyond fourteen modems  or
+     if  modem  statistics become more detailed and use more than
+     three words per modem, this can be used to keep the  message
+     within a single ARPANET packet.
+
+     The format of the modem throughput message is as follows:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |           Mess-Time           |
+                 +---------------+---------------+
+                 |    Software Version Number    |
+                 +---------------+---------------+
+                 |           Data-Time           |
+                 +---------------+---------------+
+                 |           Prev-Time           |
+                 +---------------+---------------+
+                 | Total  Modems |  This  Modem  |
+                 +---------------+---------------+
+               5 |                               |
+               . +             modem             +
+               . |                               |
+               . +           throughput          +
+               . |                               |
+               . +---------------+---------------+
+               . :             modem             :
+               . :                               :
+               . :          throughput           :
+                 +---------------+---------------+
+
+
+
+
+                              -29-
+
+
+RFC-869                                             December 1983
+
+
+
+HMP FIELDS
+
+
+System Type
+
+     IMP = 2
+
+Message Type
+
+     IMP Modem Throughput message = 3
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number  incremented  at  each  collection  interval
+     (i.e.  when  a new throughput message is assembled).  The HM
+     will be  able  to  detect  lost  or  duplicate  messages  by
+     checking the sequence numbers.
+
+Password
+
+     The password contains the sequence  number  of  the  polling
+     message to which this message responds.
+
+IMP MODEM THROUGHPUT FIELDS
+
+Mess-time
+
+     The time (in 640ms. units) at which the message was sent  to
+     the HM.
+
+Software Version Number
+
+     The IMP version number.
+
+Data-Time
+
+     Data-time is the time (in 640ms. units)  when  this  set  of
+     data was collected.  (See Description.)
+
+
+
+
+
+                              -30-
+
+
+RFC-869                                             December 1983
+
+
+
+Prev-Time
+
+     Prev-time is the time (in 640 ms.  units)  of  the  previous
+     collection of data (and therefore, is the time when the data
+     in this message began accumulating.)
+
+Total Modems
+
+     This is the number of modems in the system.
+
+This Modem
+
+     This Modem is the number of the first modem reported in this
+     message.   Large  systems  that  are unable to fit all their
+     modem reports into a single packet may  use  this  field  to
+     separate their message into smaller chunks to take advantage
+     of single packet message efficiencies.
+
+Modem Throughput
+
+     Modem  throughput  consists   of   three   words   of   data
+     reporting  packets  and  words  output  on  each modem.  The
+     first  word  counts packets  output and  the  following  two
+     count  word  throughput.   The  double  precision  words are
+     arranged high order first.  (Note  also that  messages  from
+     Honeywell  type machines (316s, 516s and C30s) use a fifteen
+     bit low order word.)  The first block reports output on  the
+     modem  specified  by  "This  Modem".   The  following blocks
+     report on consecutive modems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -31-
+
+
+RFC-869                                             December 1983
+
+
+
+A.4  Message Type 4: IMP Host Throughput
+
+Description
+
+     The host throughput message reports traffic  statistics  for
+     each host in the system.  The IMP will collect these data at
+     regular intervals and save them awaiting a poll from the HM.
+     If  a  period  is  missed  by the HM, the new results simply
+     overwrite the old.  Two time stamps bracket  the  collection
+     interval  (data-time  and prev-time) and are an indicator of
+     missed reports.  In addition, mess-time indicates  the  time
+     at which the message was sent.
+
+     The host throughput format will hold  only  three  hosts  if
+     packet  boundaries are to be respected.  A provision is made
+     to split this into multiple  packets  by  including  a  host
+     number for the first entry in the packet.
+
+     The format of the host throughput message is as follows:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |           Mess-Time           |
+                 +---------------+---------------+
+                 |    Software Version Number    |
+                 +---------------+---------------+
+                 |           Data-Time           |
+                 +---------------+---------------+
+                 |           Prev-Time           |
+                 +---------------+---------------+
+                 |  Total Hosts  |   This  Host  |
+                 +---------------+---------------+
+               5 :              host             :
+               . :           throughput          :
+                 +---------------+---------------+
+
+HMP FIELDS
+
+System Type
+
+     IMP = 2
+
+Message Type
+
+     IMP host Throughput message = 4
+
+
+
+
+
+                              -32-
+
+
+RFC-869                                             December 1983
+
+
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number  incremented  at  each  collection  interval
+     (i.e.  when  a new throughput message is assembled).  The HM
+     will be  able  to  detect  lost  or  duplicate  messages  by
+     checking the sequence numbers.
+
+Password
+
+     The password contains the sequence  number  of  the  polling
+     message to which this message responds.
+
+IMP HOST THROUGHPUT FIELDS
+
+Mess-time
+
+     The time (in 640ms. units) at which the message was sent  to
+     the HM.
+
+Software Version Number
+
+     The IMP version number.
+
+Data-Time
+
+     Data-time is the time (in 640ms. units)  when  this  set  of
+     data was collected.  (See Description.)
+
+Prev-Time
+
+     Prev-time is the time (in 640 ms.  units)  of  the  previous
+     collection of data (and therefore, is the time when the data
+     in this message began accumulating.)
+
+Total Hosts
+
+     The total number of hosts in this system.
+
+This Host
+
+     This host is the number of the first host reported  in  this
+
+
+                              -33-
+
+
+RFC-869                                             December 1983
+
+
+
+     message.   Large  systems  that  are unable to fit all their
+     host reports into a single packet  may  use  this  field  to
+     separate their message into smaller chunks to take advantage
+     of single packet message efficiencies.
+
+Host Throughput
+
+     Each host throughput block consists of eight  words  in  the
+     following format:
+
+                 +---------------+---------------+
+                 |      messages to network      |
+                 +---------------+---------------+
+                 |     messages from network     |
+                 +---------------+---------------+
+                 |        packets to net         |
+                 +---------------+---------------+
+                 |       packets from net        |
+                 +---------------+---------------+
+                 |       messages to local       |
+                 +---------------+---------------+
+                 |      messages from local      |
+                 +---------------+---------------+
+                 |        packets to local       |
+                 +---------------+---------------+
+                 |       packets from local      |
+                 +---------------+---------------+
+
+     Each host throughput message will contain several blocks  of
+     data.   The  first  block  will  contain  data  for the host
+     specified in  First  Host  Number.   Following  blocks  will
+     contain data for consecutive hosts.  All counters are single
+     precision.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -34-
+
+
+RFC-869                                             December 1983
+
+
+
+B  Appendix B - TAC Monitoring
+
+B.1  Message Type 1: TAC Trap Message
+
+Description
+
+     When a trap occurs, it is buffered in the TAC  and  sent  as
+     soon  as possible.  Trap messages are unsolicited.  If traps
+     happen in close sequence, several traps may be sent  in  one
+     message.
+
+     Through the use of sequence numbers, it will be possible  to
+     determine   how  many  traps  are  being  lost.   If  it  is
+     discovered that many are lost, a  polling  scheme  might  be
+     implemented for traps.
+
+     A TAC trap message has the following form:
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                 +---------------+---------------+
+               0 |           Version #           |
+                 +---------------+---------------+
+               1 :         first                 :
+               . :             trap              :
+               . :                 data          :
+               . +---------------+---------------+
+               . :         additional            :
+               . :             trap              :
+               . :                 data          :
+                 +---------------+---------------+
+
+
+HMP FIELDS
+
+System Type
+
+     TAC = 3
+
+Message Type
+
+     TAC Trap Message = 1
+
+Port Number
+
+     Unused
+
+
+
+
+
+                              -35-
+
+
+RFC-869                                             December 1983
+
+
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  HM  can  order the received trap messages and
+     detect missed messages.
+
+TAC TRAP FIELDS
+
+Version #
+
+     The version # of the TAC Software.
+
+Trap Reports
+
+     There can be several blocks of trap data in each message.
+
+     The format of the trap data is as follows:
+
+
+                 +---------------+---------------+
+                 |             Size              |
+                 +---------------+---------------+
+                 |             Time              |
+                 +---------------+---------------+
+                 |            Trap ID            |
+                 +---------------+---------------+
+                 :             Trap              :
+                 :             Data              :
+                 +---------------+---------------+
+                 |            Count              |
+                 +-------------------------------+
+
+  Size
+
+     Size is the number of 16 bit words in the trap, not counting
+     the size field.
+
+  Time
+
+     The time (in 640ms. units) at which the trap occurred.  This
+     field  is  used  to  sequence  the  traps  in  a message and
+
+
+                              -36-
+
+
+RFC-869                                             December 1983
+
+
+
+     associate groups of traps.
+
+  Trap ID
+
+     This is (usually) the program counter at the trap.   The  ID
+     identifies  the  trap,  and  does  not  have to be a program
+     counter, provided that it uniquely identifies the trap.
+
+  Trap Data
+
+     The TAC returns data giving more information about the trap.
+     There are usually two entries: the values in the accumulator
+     and the index register at the occurrence of the trap.
+
+  Count
+
+     The TAC Counts repetitions of the same trap ID  and  reports
+     this count here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -37-
+
+
+RFC-869                                             December 1983
+
+
+
+B.2  Message Type 2: TAC Status
+
+Description
+
+     The status message gives a quick summary of the state of the
+     TAC.   Status  of the most important features of the TAC are
+     reported  as  well  as  the  current  configuration  of  the
+     machine.
+
+
+     A TAC status message has the following form:
+
+
+                  0             0 0             1
+                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                  ---------------+---------------+
+               0 |         Version Number        |
+                 +---------------+---------------+
+                 |       Last Trap Message       |
+                 +---------------+---------------+
+                 |           Bit Flags           |
+                 +---------------+---------------+
+                 |         Free PDB count        |
+                 +---------------+---------------+
+                 |         Free MBLK count       |
+                 +---------------+---------------+
+               5 |      # of TCP connections     |
+                 +---------------+---------------+
+                 |      # of NCP connections     |
+                 +---------------+---------------+
+                 |         INA A Register        |
+                 +---------------+---------------+
+                 |         INA X Register        |
+                 +---------------+---------------+
+                 |         INA B Register        |
+                 +---------------+---------------+
+              l0 |         restart/reload        |
+                 +---------------+---------------+
+                 |                               |
+                 +          Crash                +
+                 |                               |
+                 +                Data           +
+              13 |                               |
+                 +---------------+---------------+
+
+
+
+
+
+
+
+                              -38-
+
+
+RFC-869                                             December 1983
+
+
+
+HMP FIELDS
+
+System Type
+
+     TAC = 3
+
+Message Type
+
+     TAC Status Message = 2
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a  status  message  is
+     sent.
+
+Returned Sequence Number
+
+     Contains  the  sequence  number  from  the  polling  message
+     requesting this report.
+
+TAC STATUS FIELDS
+
+Version Number
+
+     The TAC's software version number.
+
+Last Trap Message
+
+     Contains the sequence number of the last trap  message  sent
+     to  the  HM.  This will allow the HM to detect how many trap
+     messages are being lost.
+
+
+
+
+
+
+
+
+
+
+
+
+                              -39-
+
+
+RFC-869                                             December 1983
+
+
+
+Bit Flags
+
+     There are sixteen bit  flags  available  for  reporting  the
+     state  of  various  switches  (hardware and software) in the
+     TAC.  The bits are numbered as follows for purposes  of  the
+     discussion below.
+
+
+                 0             0 0             1
+                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                | | | | | | | | | | | | | | | | |
+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          The bit flags report the status of the following:
+
+          Bit         Meaning
+          15          0 => DDT override off; 1 => override on.
+          11-14       0 => Sense Switch n is off; 1 => SSn on.
+          10          0 => Traps to remote monitor;
+                      1 => Traps to console.
+          9           1 => Message generator on.
+          0-8         unused
+
+Free PDB count
+
+     The number of PDBs on the free queue.
+
+Free MBLK count
+
+     The number of MBLKs on the free queue.
+
+# of TCP connections
+# of NCP connections
+
+     The number of open connections for each protocol.
+
+INA Report
+
+     These three fields report the values retained by an INA 1011
+     instruction  in  a  C/30.  This  instruction  returns micro-
+     machine status and  errors.   In  a  #316,  the  fields  are
+     meaningless.
+
+
+
+
+
+
+
+
+                              -40-
+
+
+RFC-869                                             December 1983
+
+
+
+Restart/Reload
+
+     This word reports a restart or reload of the TAC
+
+           Value      Meaning
+             1       restarted
+             2       reloaded
+
+
+Crash Data
+
+     Crash  data  reports  the   circumstances   surrounding   an
+     unexpected  crash.   The  first word reports the location of
+     the crash and the following two  are  the  contents  of  the
+     accumulator and index registers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -41-
+
+
+RFC-869                                             December 1983
+
+
+
+B.3  Message Type 3: TAC Throughput
+
+Description
+
+     The  TAC  throughput  message  reports  statistics  for  the
+     various modules of the TAC.  The TAC will collect these data
+     at regular intervals and save them awaiting a poll from  the
+     HM.  If a period is missed by the HM, the new results simply
+     overwrite the old.  Two time stamps bracket  the  collection
+     interval  (data-time  and prev-time) and are an indicator of
+     missed reports.  In addition, mess-time indicates  the  time
+     at which the message was sent.
+
+
+     A TAC throughput message has the following form:
+
+               0             0 0             1
+               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+              +---------------+---------------+
+            0 |           Mess-Time           |
+              +---------------+---------------+
+              |           Data-Time           |
+              +---------------+---------------+
+              |           Prev-Time           |
+              +---------------+---------------+
+              |         Version Number        |
+              +---------------+---------------+
+              |       Last Trap Message       |
+              +---------------+---------------+
+            5 |           Bit Flags           |
+              +---------------+---------------+
+              |         Free PDB count        |
+              +---------------+---------------+
+              |         Free MBLK count       |
+              +---------------+---------------+
+              |      # of TCP connections     |
+              +---------------+---------------+
+              |      # of NCP connections     |
+              +---------------+---------------+ ----
+           10 |     Host Input Throughput     |    ^
+              +---------------+---------------+    |
+              |     Host Input Abort Count    |    |
+              +---------------+---------------+    |
+              |    Host Input Garbled Count   |    |
+              +---------------+---------------+    |
+              |    Host Output Throughput     | 1822 info.
+              +---------------+---------------+    |
+                            (continued)
+
+
+
+                              -42-
+
+
+RFC-869                                             December 1983
+
+
+
+
+     TAC throughput (cont.)
+
+              +---------------+---------------+    |
+              |    Host Output Abort Count    | 1822 info.
+              +---------------+---------------+    |
+           15 |        Host Down Count        |    v
+              +---------------+---------------+ ----
+              |      # of datagrams sent      |    ^
+              +---------------+---------------+    |
+              |    # of datagrams received    |    |
+              +---------------+---------------+  IP info.
+              |    # of datagrams discarded   |    |
+              +---------------+---------------+    |
+              |    # of fragments received    |    v
+              +---------------+---------------+    |
+           20 |    # of fragments discarded   |    v
+              +---------------+---------------+ ----
+              |      # of segments sent       |    ^
+              +---------------+---------------+    |
+              |    # of segments received     |    |
+              +---------------+---------------+    |
+              |    # of segments discarded    |    |
+              +---------------+---------------+  TCP info.
+              |       # of octets sent        |    |
+              +---------------+---------------+    |
+           25 |     # of octets received      |    |
+              +---------------+---------------+    |
+              |     # of retransmissions      |    v
+              +---------------+---------------+ ----
+
+
+HMP FIELDS
+
+System Type
+
+     TAC = 3
+
+Message Type
+
+     TAC Throughput Message = 3
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+
+                              -43-
+
+
+RFC-869                                             December 1983
+
+
+
+Sequence Number
+
+     A 16 bit number  incremented  at  each  collection  interval
+     (i.e.  when  a new throughput message is assembled).  The HM
+     will be  able  to  detect  lost  or  duplicate  messages  by
+     checking the sequence numbers.
+
+Returned Sequence Number
+
+     Contains  the  sequence  number  from  the  polling  message
+     requesting this report.
+
+TAC THROUGHPUT FIELDS
+
+Mess-time
+
+     The time (in 640ms. units) at which the message was sent  to
+     the HM.
+
+Data-Time
+
+     Data-time is the time (in 640ms. units)  when  this  set  of
+     data was collected.  (See Description.)
+
+Prev-Time
+
+     Prev-time is the time (in 640 ms.  units)  of  the  previous
+     collection of data (and therefore, is the time when the data
+     in this message began accumulating.)
+
+Version Number
+
+     The TAC's software version number.
+
+Last Trap Message
+
+     Contains the sequence number of the last trap  message  sent
+     to  the  HM.  This will allow the HM to detect how many trap
+     messages are being lost.
+
+Bit Flags
+
+     There are sixteen bit  flags  available  for  reporting  the
+     state  of  various  switches  (hardware and software) in the
+     TAC.  The bits are numbered as follows for purposes  of  the
+     discussion below.
+
+
+
+
+
+                              -44-
+
+
+RFC-869                                             December 1983
+
+
+
+
+
+
+                 0             0 0             1
+                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                | | | | | | | | | | | | | | | | |
+                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+          The bit flags report the status of the following:
+
+          Bit         Meaning
+          15          0 => DDT override off; 1 => override on.
+          11-14       0 => Sense Switch n is off; 1 => SSn on.
+          10          0 => Traps to remote monitor;
+                      1 => Traps to console.
+          9           1 => Message generator on.
+          0-8         unused
+
+
+
+Free PDB count
+
+     The number of PDBs on the free queue.
+
+Free MBLK count
+
+     The number of MBLKs on the free queue.
+
+# of TCP connections
+# of NCP connections
+
+     The number of open connections for each protocol.
+
+1822 info.
+
+     These  six  fields  report  statistics  which  concern   the
+     operation  of  the  1822 protocol module, i.e. the interface
+     between the TAC and its IMP.
+
+IP info.
+
+     These five fields report statistics which  concern  Internet
+     Protocol in the TAC.
+
+TCP info.
+
+
+
+                              -45-
+
+
+RFC-869                                             December 1983
+
+
+
+     These  six  fields  report  statistics  which  concern   TCP
+     protocol in the TAC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -46-
+
+
+RFC-869                                             December 1983
+
+
+
+C  Appendix C - Gateway Monitoring
+
+C.1  Gateway Parameters
+
+     The gateway supports parameters to set Throughput  and  Host
+     traffic matrix measurements.  The type of parameters and the
+     parameter and data pairs are as follows:
+
+     Throughput - Type = 3
+
+
+          Parm.  Description             Control Data Word
+          -----  -----------             -----------------
+
+          1      Start/Stop              0=Stop,1=Start
+          2      Collection Interval     Time in 1 minute
+                                         ticks
+
+
+     Host Traffic Matrix - Type = 4
+
+
+          Parm.  Description             Control Data Word
+          -----  -----------             -----------------
+
+          1      Start/Stop              0=Stop,1=Start
+          2      Collection Interval     Time in 1 minute
+                                         ticks
+          3      HTM Switch Control      Include Control
+                                         Protocols
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -47-
+
+
+RFC-869                                             December 1983
+
+
+
+C.2  Message Type 1: Gateway Trap
+
+Description
+
+     When traps occur in the gateway they  are  buffered.   At  a
+     fixed  time interval (currently 10 seconds) the gateway will
+     send any traps that are in  the  buffer  to  the  monitoring
+     center.  The traps are sent as unsolicited messages.
+
+     A Gateway trap message has the following format:
+
+           0             0 0             1
+           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |      Gateway Version #        |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |    Size of Trap Entry         |       ;First Trap
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |       Time of Trap            |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |       Trap ID                 |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |       Process ID              |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R0               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R1               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R2               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R3               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                    (continued)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -48-
+
+
+RFC-869                                             December 1983
+
+
+
+Gateway Trap Message (cont'd.)
+
+
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R4               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R5               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |              R6               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |     Count of this Trap        |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          .
+                          .
+                          .
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |                               |
+          |    Additional Trap reports    |
+          |                               |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+HMP FIELDS
+
+System Type
+
+     Gateway = 4
+
+Message Type
+
+     Gateway Trap Message = 1
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  monitoring center can order the received trap
+     messages and detect missed messages.
+
+
+
+                              -49-
+
+
+RFC-869                                             December 1983
+
+
+
+GATEWAY TRAP FIELDS
+
+Gateway Version #
+
+     The software version number of the gateway sending the trap.
+
+Trap Reports
+
+     The remainder of the  trap  message  consists  of  the  trap
+     reports.  Each consists of the following fields:
+
+     Size of Trap Entry
+
+          The size  in  16-bit  words  of  the  trap  entry,  not
+          including the size field.
+
+     Time of Trap
+
+          The time in (in 1/60 sec.  ticks)  at  which  the  trap
+          occurred.
+
+     Trap ID
+
+          The number of the trap which is used  to  identify  the
+          trap.
+
+     Process ID
+
+          The identifier of the process that executed the trap.
+
+     R0-R6
+
+          The registers of the machine at the occurrence  of  the
+          trap.
+
+     Count of this Trap
+
+          The number of times that this trap occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -50-
+
+
+RFC-869                                             December 1983
+
+
+
+C.3  Message Type 2: Gateway Status
+
+Description
+
+     The gateway status message gives a summary of the status  of
+     the  gateway.  It reports information such as version number
+     of the gateway, buffer memory usage,  interface  status  and
+     neighbor gateway status.
+
+     A Gateway Status message has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -51-
+
+
+RFC-869                                             December 1983
+
+
+
+
+      0                   1         1         2                   3 3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Version Number        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Patch Version Number      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Time Since Gateway Restart   |       ;in minutes
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Measurement Flags       |       ; Bit flags to indicate which
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       ; measurements are on, 1= On
+     |      Routing Sequence No.     |       ; Sequence # of last routing
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       ;   update sent
+     |    Access Table Version #     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Load Sharing Table Ver. #    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Memory in Use         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Memory Idle           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Memory Free           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   # of Blks   |                       ; Memory Allocation Info
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Size of 1st Block (in bytes) |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  # Allocated  |
+     +-+-+-+-+-+-+-+-+
+     |    # Idle     |
+     +-+-+-+-+-+-+-+-+
+             .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Size of n'th Block (in bytes) |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  # Allocated  |
+     +-+-+-+-+-+-+-+-+
+     |    # Idle     |
+     +-+-+-+-+-+-+-+-+
+                  (continued)
+
+
+
+
+
+
+
+
+
+
+                              -52-
+
+
+RFC-869                                             December 1983
+
+
+
+Gateway Status Message (cont'd.)
+
+     +-+-+-+-+-+-+-+-+
+     |   # of Ints.  |
+     +-+-+-+-+-+-+-+-+
+     | Int 1 Flags   |                       ;Interface 1 Status Flags
+     +-+-+-+-+-+-+-+-+                       ; Bit 0 - 1=Up, 0=Down
+                                             ;     1 - 1=Looped, 0=Not
+     +-+-+-+-+-+-+-+-+
+     | Buffers       |                       ; # of buffers on write Queue
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Time since last Status Change |       ;Time since last up/dwn change
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    # of Buffers Allocated     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Data Size for Interface    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Interface 1 Address                                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+     +---------------+
+     | Int n Flags   |                       ;Interface n Status Flags
+     +-+-+-+-+-+-+-+-+
+     | Buffers       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Time since last Status Change |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    # of Buffers Allocated     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Data Size for Interface    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Interface n Address                                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | # Neighbors   |
+     +-+-+-+-+-+-+-+-+
+     | UP/DN Flags   |                       ;Bit flags for Up or Down
+     +-+-+-+-+-+-+-+-+                       ; 0 = Dwn,  1 = Up
+             .                               ; MSB is neighbor 1
+             .                               ; (as many bytes as necessary)
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Neighbor 1 Address                                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Neighbor n Address                                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+                              -53-
+
+
+RFC-869                                             December 1983
+
+
+
+HMP FIELDS
+
+System Type
+
+     Gateway = 4
+
+Message Type
+
+     Gateway Status Message = 2
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  monitoring center can order the received trap
+     messages and detect missed messages.
+
+GATEWAY STATUS FIELDS
+
+Version Number
+
+     The  version  number  of  the  gateway  sending  the  Status
+     message.
+
+Patch Version Number
+
+     The patch version number of the gateway.
+
+Time Since Gateway Restart
+
+     The time in minutes since the gateway was last restarted  or
+     reloaded.
+
+
+
+
+
+
+
+
+                              -54-
+
+
+RFC-869                                             December 1983
+
+
+
+Measurement Flags
+
+     Flags that, if set, indicate which measurements  are  turned
+     on.  Current values are:
+
+
+          Bit 0   =   Message Generator
+              1   =   Throughput
+              2   =   Host Traffic Matrix
+              3   =   Access Control 1
+              4   =   Access Control 2
+              5   =   Load Sharing
+              6   =   EGP in Gateway
+
+
+Routing Sequence Number
+
+     The sequence number of the last routing update sent by  this
+     gateway.
+
+Access Control Table Version #
+
+     The version number of the access control table.
+
+Load Sharing Table Version #
+
+     The version number of the load sharing table.
+
+Memory In Use
+
+     The number of bytes of buffer memory that are  currently  in
+     use.
+
+Memory Idle
+
+     The  number  of  bytes  of  buffer  memory  that  have  been
+     allocated but are currently idle.
+
+Memory Free
+
+     The number of bytes of  buffer  memory  that  has  not  been
+     allocated.
+
+MEMORY ALLOCATION INFORMATION
+
+     The next part of the status message contains information  on
+     the buffer pools in the gateway.    The fields are:
+
+     # of Blocks
+
+
+                              -55-
+
+
+RFC-869                                             December 1983
+
+
+
+          The number of different buffer pools.
+
+     Size of Block
+
+          The size of this block in bytes.
+
+     # Allocated
+
+          The number of  blocks  of  this  size  that  have  been
+          allocated.
+
+     # Idle
+
+          The number of blocks of this size that are idle.
+
+GATEWAY INTERFACE FIELDS
+
+     The next part of the status message are fields that  provide
+     information about the gateway's interfaces.  The fields are:
+
+     # of Interfaces
+
+          The number of network interfaces that the gateway has.
+
+     Interface Flags
+
+          Flags that indicate the status of this interface.   The
+          current values are:
+
+               Bit 0  -  1=Up/0=Down
+                   1  -  1=Looped/0=Not Looped
+
+
+     Buffers
+
+          The numbers on this interfaces write queue.
+
+     Time Since Last Status Change
+
+          The time in minutes since this interface changed status
+          (Up/Down).
+
+     # of Buffers Allocated
+
+          The number of buffers allocated for this interface.
+
+     Data Size for Interface
+
+          The buffer size required for this interface.
+
+
+                              -56-
+
+
+RFC-869                                             December 1983
+
+
+
+     Interface Address
+
+          The Internet address of this interface.
+
+NEIGHBOR GATEWAY FIELDS
+
+     The final part of the status message consists of information
+     about this gateway's neighbor gateways.  The fields are:
+
+     # of Neighbors
+
+          The number of gateways that are  neighbor  gateways  to
+          this gateway.
+
+     UP/DN Flags
+
+          Bit flags to indicate if the neighbor is up or down.
+
+     Neighbor Address
+
+          The Internet address of the neighbor gateway.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -57-
+
+
+RFC-869                                             December 1983
+
+
+
+C.4  Message Type 3: Gateway Throughput
+
+Description
+
+     The gateway collects throughput statistics for the  gateway,
+     its interfaces, and its neighbor gateways.  It collects them
+     for regular intervals and will save them for collection  via
+     a  Poll  message  from the Monitoring host.  If they are not
+     collected by the end of the next interval, they will be lost
+     because another copy will be put into the saved area.
+
+     A Gateway Throughput message has the following format:
+
+      0                   1         1         2                   3 3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Gateway Version Number    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Collection Time in Min    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Number of Interfaces     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Number of Neighbors     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Number of Host Unreachable   |       ; # of packets dropped because
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       ;   Host was Unreachable
+     |  Number of Net Unreachable    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       ;   Net was Unreachable
+
+     ; Interface Counters
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Interface Address                                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Packets Dropped on Input    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Count of IP Errors        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Count of Datagrams for Us   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Datagrams to be Forwarded   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Count of Datagrams Looped   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             (continued)
+
+
+
+
+
+
+                              -58-
+
+
+RFC-869                                             December 1983
+
+
+
+Gateway Throughput Message (cont'd.)
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Count of Bytes Input                                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Count of Datagrams From Us   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Count that were Forwarded     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Count of Local Net Dropped   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Count of Queue full Dropped  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Count of Bytes Output                                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |          Counters For Additional Interfaces                   |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     ; Neighbor counters
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Neighbor Address                                             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Count of Routing Updates TO   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |Count of Routing Updates FROM  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                              (continued)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -59-
+
+
+RFC-869                                             December 1983
+
+
+
+Gateway Throughput Message (cont'd.)
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Pkts from US sent to/via Neig |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Pkts forwarded to/via Neighb |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Datagrams Local Net Dropped  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Datagrams Queue full Dropped  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Count of Bytes send to Neighbor                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |        Counters for Additional Neighbor Gateways              |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+HMP FIELDS
+
+System Type
+
+     Gateway = 4
+
+Message Type
+
+     Gateway Throughput Message = 3
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  HM  can  order the received trap messages and
+
+
+                              -60-
+
+
+RFC-869                                             December 1983
+
+
+
+     detect missed messages.
+
+GATEWAY THROUGHPUT FIELDS
+
+Gateway Version Number
+
+     The software version number of the gateway sending the trap.
+
+Collection Time in Min.
+
+     The time period in minutes in which the throughput  data  is
+     to be collected.
+
+Number of Interfaces
+
+     The number of interfaces this gateway has.
+
+Number of Neighbors
+
+     The number of neighbor gateways this gateway has.
+
+Number of Host Unreachable
+
+     The  number  of  packets  dropped  because  the   Host   was
+     unreachable.
+
+Number of Net Unreachable
+
+     The number  of  packets  dropped  because  the  Network  was
+     unreachable.
+
+INTERFACE COUNTERS
+
+     The next part of the Throughput  message  contains  counters
+     for   the  gateways  interfaces.   Each  interface  has  the
+     following fields:
+
+     Interface Address
+
+          The Internet address of this interface.
+
+     Packets Dropped on Input
+
+          The number  of  packets  on  input  to  this  interface
+          because there were not enough buffers.
+
+     Count of IP Errors
+
+          The number of packets received with bad IP headers.
+
+
+                              -61-
+
+
+RFC-869                                             December 1983
+
+
+
+     Count of Datagrams for Us
+
+          The number of  datagrams  received  addressed  to  this
+          gateway.
+
+     Datagrams to be Forwarded
+
+          The number of datagrams were not for this  gateway  and
+          should be sent out another interface.
+
+     Count of Datagrams Looped
+
+          The number of datagrams that were received on and  sent
+          out of this interface.
+
+     Count of Bytes Input
+
+          The number of bytes received on this interface.
+
+     Count of Datagrams From Us
+
+          The  number  of  datagrams  that  originated  at   this
+          gateway.
+
+     Count that were Forwarded
+
+          The number of datagrams that were forwarded to  another
+          gateway.
+
+     Count of Local Net Dropped
+
+          The number of packets  that  were  dropped  because  of
+          local network flow control restrictions.
+
+     Count of Queue full Dropped
+
+          The number of packets that  were  dropped  because  the
+          output queue was full.
+
+     Count of Bytes Output
+
+          The number of bytes sent out on this interface.
+
+
+
+
+
+
+
+
+
+                              -62-
+
+
+RFC-869                                             December 1983
+
+
+
+NEIGHBOR COUNTERS
+
+     The last part of the Throughput message are counts for  each
+     neighbor gateway.  The fields are:
+
+     Neighbor Address
+
+          The Internet address of this neighbor gateway.
+
+     Count of Routing Updates TO
+
+          The number of routing updates  sent  to  this  neighbor
+          gateway.
+
+     Count of Routing Updates FROM
+
+          The  number  of  routing  updates  received  from  this
+          neighbor gateway.
+
+     Pkts from US sent to/via Neig
+
+          The number of packets from this gateway sent to or  via
+          this neighbor gateway.
+
+     Pkts forwarded to/via Neighb
+
+          The number of packets forwarded to or via this neighbor
+          gateway.
+
+     Datagrams Local Net Dropped
+
+          The  number  of  datagrams  dropped  to  this  neighbor
+          gateway   because   of   local   network  flow  control
+          restrictions.
+
+     Datagrams Queue full Dropped
+
+          The  number  of  datagrams  dropped  to  this  neighbor
+          because the output queue was full.
+
+     Count of Bytes send to Neighbor
+
+          The number of bytes sent to this neighbor gateway.
+
+
+
+
+
+
+
+
+                              -63-
+
+
+RFC-869                                             December 1983
+
+
+
+C.5  Message Type 4: Gateway Host Traffic Matrix
+
+Description
+
+     The Host Traffic Matrix (HTM) message  contains  information
+     about  the  traffic  that  flows  through the gateway.  Each
+     entry consists of the number of datagrams sent and  received
+     for a particular source/destination pair.
+
+     A Gateway HTM message has the following format:
+
+      0                   1         1         2                   3 3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Gateway Version Number    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Overflow counter       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Collection Time in Min    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Number of HTM entries     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    IP Source Address                                          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    IP Destination Address                                     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | IP Protocol   |  (unused)     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Counter for SRC -> DST datagrams                           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Counter for DST -> SRC datagrams                           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |      Additional HTM Reports                                   |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+                              -64-
+
+
+RFC-869                                             December 1983
+
+
+
+HMP FIELDS
+
+System Type
+
+     Gateway = 4
+
+Message Type
+
+     Gateway HTM Message = 4
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  HM  can  order the received trap messages and
+     detect missed messages.
+
+GATEWAY HTM FIELDS
+
+Gateway Version Number
+
+     The software version number of this gateway.
+
+Overflow counter
+
+     The number of HTM entries lost because the  HTM  buffer  was
+     full.
+
+Collection Time in Min
+
+     The time period in minutes in which the HTM  data  is  being
+     collected.
+
+Number of HTM entries
+
+     The number of HTM reports included in this message.
+
+
+
+
+                              -65-
+
+
+RFC-869                                             December 1983
+
+
+
+HTM ENTRIES
+
+     The remainder of the HTM message consists of the actual  HTM
+     entries.  Each entry consists of the following fields:
+
+     IP Source Address
+
+          The source Internet  address  of  the  datagrams  being
+          counted.
+
+     IP Destination Address
+
+          The destination Internet address of the datagrams being
+          counted.
+
+     IP Protocol
+
+          The protocol number of the datagrams.
+
+     Counter for SRC -> DST datagrams
+
+          The  number  of  datagrams  sent  in  the   Source   to
+          Destination address direction.
+
+     Counter for DST -> SRC datagrams
+
+          The number of datagrams  sent  in  the  Destination  to
+          Source address direction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -66-
+
+
+RFC-869                                             December 1983
+
+
+
+C.6  Message Type 6: Gateway Routing
+
+Description
+
+     The Routing message contains information  about  routes  the
+     gateway  has  to the networks that make up the Internet.  It
+     includes information about its interfaces and  its  neighbor
+     gateways.
+
+     A Gateway Routing message has the following format:
+
+      0                   1         1         2                   3 3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |         Version Number        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   # of Ints.  |
+     +-+-+-+-+-+-+-+-+
+     | UP/DN Flags   |                       ;Bit flags for Up or Down
+     +-+-+-+-+-+-+-+-+                       ; 0 = Dwn,  1 = Up
+             .                               ; MSB is interface 1
+             .                               ; (as many bytes as necessary)
+             .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Interface 1 Address                                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Interface n Address                                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | # Neighbors   |
+     +-+-+-+-+-+-+-+-+
+     | UP/DN Flags   |                       ;Bit flags for Up or Down
+     +-+-+-+-+-+-+-+-+                       ; 0 = Dwn,  1 = Up
+             .                               ; MSB is neighbor 1
+             .                               ; (as many bytes as necessary)
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Neighbor 1 Address                                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Neighbor n Address                                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         (continued)
+
+
+
+
+                              -67-
+
+
+RFC-869                                             December 1983
+
+
+
+Gateway Routing Message (cont'd.)
+
+     +-+-+-+-+-+-+-+-+
+     | # of Networks |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Network 1 #   |               |               |  ; 1, 2, or 3 bytes
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Distance    |
+     +-+-+-+-+-+-+-+-+
+     |   Neighbor #  |
+     +-+-+-+-+-+-+-+-+
+                     .
+                     .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Network n #   |               |               |  ; 1, 2, or 3 bytes
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Distance    |
+     +-+-+-+-+-+-+-+-+
+     |   Neighbor #  |
+     +-+-+-+-+-+-+-+-+
+
+HMP FIELDS
+
+System Type
+
+     Gateway = 4
+
+Message Type
+
+     Gateway Trap Message = 6
+
+Port Number
+
+     Unused
+
+Control Flag
+
+     Unused
+
+Password or Returned Sequence Number
+
+     Unused
+
+Sequence Number
+
+     A 16 bit number incremented each time a trap message is sent
+     so  that  the  HM  can  order the received trap messages and
+     detect missed messages.
+
+
+
+                              -68-
+
+
+RFC-869                                             December 1983
+
+
+
+GATEWAY ROUTING FIELDS
+
+Gateway Version #
+
+     The software version number of the gateway sending the trap.
+
+INTERFACE FIELDS
+
+     The first part of the routing message  contains  information
+     about  the  gateway's  interfaces.   There  is data for each
+     interface.  The fields are:
+
+     # of Interfaces
+
+          The number of interfaces that this gateway has.
+
+     UP/DN Flags
+
+          Bit flags to indicate if the Interface is up or down.
+
+     Interface Address
+
+          The Internet address of the Interface.
+
+NEIGHBOR FIELDS
+
+     The next part of the routing  message  contains  information
+     about this gateway's neighbor gateways.  The fields are:
+
+     # of Neighbors
+
+          The number of gateways that are  neighbor  gateways  to
+          this gateway.
+
+     UP/DN Flags
+
+          Bit flags to indicate if the neighbor is up or down.
+
+     Neighbor Address
+
+          The Internet address of the neighbor gateway.
+
+NETWORK ROUTING FIELDS
+
+     The last part of the routing  message  contains  information
+     about   this  gateway's  routes  to  other  networks.   This
+     includes the distance to each  network  and  which  neighbor
+     gateway is the route to the network.  The fields are:
+
+
+
+                              -69-
+
+
+RFC-869                                             December 1983
+
+
+
+     # of Networks
+
+          The number of networks that  are  reachable  from  this
+          gateway.
+
+     Network #
+
+          The network  number  of  this  network.   This  is  the
+          network  part  of  the Internet address and may be one,
+          two, or three bytes in length depending on  whether  it
+          is a Class A, B, or C address.
+
+     Distance
+
+          The distance in hops to this network.  Zero hops  means
+          that the network is directly connected to this gateway.
+          A negative number means that the network  is  currently
+          unreachable.
+
+     Neighbor #
+
+          The neighbor gateway that is the next hop to reach this
+          network.    This   is   an   index  into  the  previous
+          information on this gateway's neighbor gateways.   This
+          field  is  only  valid  if the Distance is greater than
+          zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              -70-
+
\ No newline at end of file
-- 
cgit v1.2.3