Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
HISTORIC
RFC - 869 A Host Monitoring Protocol Robert M. Hinden BBN Communications Corporation December 1983
RFC-869 December 1983 Table of Contents1 Introduction..........................................12 General Description...................................33 Relationship to Other Protocols.......................64 Protocol Operation....................................75 Header Formats.......................................125.1 IP Headers.........................................125.2 HMP Header.........................................136 HMP Monitoring Center Message Formats................166.1 Message Type 100: Polling Message..................166.2 Message Type 101: Error in Poll....................186.3 Message Type 102: Control acknowledgment...........20AAppendix A - IMP Monitoring..........................21A.1 Message Type 1: IMP Trap...........................21A.2 Message Type 2: IMP status.........................24A.3 Message Type 3: IMP Modem Throughput...............29A.4 Message Type 4: IMP Host Throughput................32BAppendix B - TAC Monitoring..........................35B.1 Message Type 1: TAC Trap Message...................35B.2 Message Type 2: TAC Status.........................38B.3 Message Type 3: TAC Throughput.....................42CAppendix C - Gateway Monitoring......................47C.1 Gateway Parameters.................................47C.2 Message Type 1: Gateway Trap.......................48C.3 Message Type 2: Gateway Status.....................51C.4 Message Type 3: Gateway Throughput.................58C.5 Message Type 4: Gateway Host Traffic Matrix........64C.6 Message Type 6: Gateway Routing....................67 -i-
RFC-869 December 1983Replaces IEN-197 A Host Monitoring Protocol1 Introduction The Host Monitoring Protocol (HMP) is used to collectinformation from hosts in various networks. A host isdefined as an addressable Internet entity that can send andreceive messages; this includes hosts such as server hosts,personal work stations, terminal concentrators, packet switches,and gateways. At present the Host Monitoring Protocol is beingused to collect information from Internet Gateways and TACs, andimplementations are being designed for other hosts. It isdesigned to monitor hosts spread over the internet as well ashosts in a single network. This document is organized into three parts.Section 2 and3 contains a general description of the Host Monitoring protocoland its relationship to other protocols. Section 4 describeshow it operates.Section 5 and 6 contain the descriptions andformats of the HMP messages. These are followed by appendicescontaining the formats of messages sent by some of the hosts thatuse the HMP to collect their monitoring information. Theseappendicies included as examples only and are not part of the HMPprotocol. -1-
RFC-869 December 1983 This document replaces the previous HMP document "IEN-197, AHost Monitoring Protocol." -2-
RFC-869 December 19832 General Description The Host Monitoring Protocol is a transaction-oriented(i.e., connection-less) transport protocol. It was designed tofacilitate certain simple interactions between two internetentities, one of which may be considered to be "monitoring" theother. (In discussing the protocol we will sometimes speak of a"monitoring host" and a "monitored entity".) HMP was intended tobe a useful transport protocol for applications that involve anyor 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 bemonitoring several different types of entities simultaneously,and may be gathering several different types of data from a given -3-
RFC-869 December 1983type of monitored entity. Several different monitoring hosts maybe monitoring a given entity, and several processes on the samehost may even be monitoring the same entity. Messages from the monitoring host to the monitored entityare called "polls". They need to contain enough information toallow 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 hostneed to contain enough information to enable the monitoring hostto 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 providedin the HMP header to detect data corruption during transmission. -5-
RFC-869 December 19833 Relationship to Other Protocols The Host Monitoring Protocol is a transport protocoldesigned to fit into the layered internet protocol environment.It operates on top of the Internet/ICMP protocol and underapplications that require its services. This relationship isillustrated 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 possibleto run the HMP without an Internetwork layer. As long as HMPs'service requirnments (addressing, protocol demultiplexing, andoccasional delivery) are met it should run over a variety ofprotocols. -6-
RFC-869 December 19834 Protocol Operation The HMP is built around the idea that most of theintelligence needed to monitor a host should reside in amonitoring center, not in the host. The host should be requiredonly to collect data and send it to the monitoring center, eitherspontaneously or on request from the monitoring center. The hostis not responsible for insuring that the data arrives reliably(except that it checksums the data); instead, the monitoringcenter is responsible for ensuring that the data it requests isreceived correctly. Consequently, the HMP is based on polling hosts formessages. When the monitoring center requires a particular typeof data (e.g., throughput data), it sends a poll to the hostrequesting that type of report. The host, upon receiving thepoll, responds with its latest set of collected data. If thehost finds that the poll is incorrect (e.g., if the poll was forthroughput data and the host is not collecting throughput data),it responds with an error message. The monitoring center waits areasonable length of time for the host to answer its poll. If noresponse is received, it sends another poll for the same data.In this way, if either a poll or the response is lost, thecorrect 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 timeThese classes of data allow a host to send data in a manner bestsuited to the data. For instance, the host may quickly informthe monitoring center that a particular event has happened bysending a trap message, while the monitoring center is reliablycollecting the host's throughput and accounting data. Traps report spontaneous events, as they occur, to themonitoring center. In order to insure their prompt delivery, thetraps are sent as datagrams with no reliability mechanisms(except checksums) such as acknowledgments and retransmissions.Trap messages usually contain an identifier to indicate whichevent is being reported, the local time in the host that theevent occured, and data pertinent to the event. The data portionis intended to be host and event specific. Status information, the second type of data collected by theHost Monitoring Protocol describes the current state of the host.Status information is useful at one point, but it does not haveto be collected cumulatively over a certain period of time. Onlythe latest status is of interest; old status provides no usefulinformation. The monitoring center collects status information -8-
RFC-869 December 1983by sending a poll for status to a host. Upon receiving the poll,the host responds with its latest status information, alwayscreating a new status message. If the monitoring center does notreceive a response to its poll, it sends another poll. Themonitoring center can decide if the host is up or down based onwhether the host responds to its polls. The third type of data collected by the HMP is statisticaldata. These are measurements taken over time, such as the numberof packets sent or received by a host and the count of packetsdropped for a particular reason. It is important that none ofthis type of data be lost. Statistical data is collected in ahost over a time interval. When the collection time intervalexpires, the current data is copied to another area, and thecounters are cleared. The copied data is sent to the monitoringcenter when the host receives a poll requesting statisticalinformation. If another poll is received before the collectiontime interval has expired, the data in the buffer is sent again.The monitoring center can detect duplicate messages by using thesequence number in the header of the message, since each type ofstatistical data has its own sequence number counter. The collection frequency for statistics messages from aparticular host must be relatively long compared to the averageround trip message time between the monitoring center and thathost inorder to allow the monitoring center to re-poll if it does -9-
RFC-869 December 1983not receive an answer. With this restriction, it should bepossible to avoid missing any statistics messages. Eachstatistics message contains a field giving the local time whenthe data was collected and the time at which the message wassent. This information allows the monitoring center to schedulewhen it sends a poll so that the poll arrives near the beginningof each collection period. This ensures that if a message islost, the monitoring center will have sufficient time to pollagain for the statistics message for that period. The HMP also includes a provision to send data to and readparameters in hosts. The data may be used to set switches orinterval timers used to control measurements in a host, or tocontrol the host itself (e.g. a restart switch). The format ofthe data and parameters is host specific. To send data to a host, the monitoring center sends the hosta poll for a control-acknowledgment message. This poll messageincludes the type of the data and the data being sent. When thehost receives this poll, it processes the data and responds witha control-acknowledgment message. To read parameters in a host, the monitoring center willsend a poll for parameters to the host. This poll includes thetype of the parameters being read. When the host receives thispoll, it will send the parameters of the requested type to the -10-
RFC-869 December 1983monitoring center in a parameters message. -11-
RFC-869 December 19835 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 HeadersHMP messages are sent using the version 4 IP header as describedinRFC-791 "Internet Protocol." The HMP protocol number is 20(decimal). The time to live field should be set to a reasonablevalue for the hosts being monitored.All other fields should be set as specified inRFC-791. -12-
RFC-869 December 19835.2 HMP HeaderThe 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 TypeMessage 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 AcknowledgmentPort 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 19836 HMP Monitoring Center Message Formats6.1 Message Type 100: Polling MessageDescription 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 1983HMP FIELDSSystem Type The type of machine being polled.Message Type Polling Message = 100Port Number UnusedControl Flag UnusedSequence 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 FIELDSR-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 19836.2 Message Type 101: Error in PollDescription 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 FIELDSSystem Type The type of machine sending message.Message Type Error Message = 101Port Number UnusedControl Flag UnusedSequence 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 1983ERROR MESSAGE FIELDSError 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 LoaderR-Message TypeR-Subtype These fields identify the poll request in error. -19-
RFC-869 December 19836.3 Message Type 102: Control acknowledgmentDescription 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 FIELDSSystem Type The type of the system sending the message.Message Type Control acknowledgment = 102Port Number UnusedControl Flag UnusedSequence 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 1983AAppendix A - IMP MonitoringA.1 Message Type 1: IMP TrapDescription 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 FieldsSystem Type IMP = 2Message Type IMP Trap Message = 1Port Number Unused -21-
RFC-869 December 1983Control Flag UnusedPassword UnusedSequence 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 1983A.2 Message Type 2: IMP statusDescription 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 FIELDSSystem Type IMP = 2Message Type IMP status message = 2Port Number UnusedControl Flag UnusedSequence 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 FIELDSSoftware Version Number The IMP version number. -25-
RFC-869 December 1983Last 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 statisticsCrash 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 1983Buffer 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-existentModem 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 1983A.3 Message Type 3: IMP Modem ThroughputDescription 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 1983HMP FIELDSSystem Type IMP = 2Message Type IMP Modem Throughput message = 3Port Number UnusedControl Flag UnusedSequence 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 FIELDSMess-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 1983Prev-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 1983A.4 Message Type 4: IMP Host ThroughputDescription 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 FIELDSSystem Type IMP = 2Message Type IMP host Throughput message = 4 -32-
RFC-869 December 1983Port Number UnusedControl Flag UnusedSequence 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 FIELDSMess-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 1983BAppendix B - TAC MonitoringB.1 Message Type 1: TAC Trap MessageDescription 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 FIELDSSystem Type TAC = 3Message Type TAC Trap Message = 1Port Number Unused -35-
RFC-869 December 1983Control Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 FIELDSVersion # 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 1983B.2 Message Type 2: TAC StatusDescription 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 1983HMP FIELDSSystem Type TAC = 3Message Type TAC Status Message = 2Port Number UnusedControl Flag UnusedSequence 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 FIELDSVersion 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 1983Bit 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 unusedFree 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 1983Restart/Reload This word reports a restart or reload of the TAC Value Meaning 1 restarted 2 reloadedCrash 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 1983B.3 Message Type 3: TAC ThroughputDescription 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 FIELDSSystem Type TAC = 3Message Type TAC Throughput Message = 3Port Number UnusedControl Flag Unused -43-
RFC-869 December 1983Sequence 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 FIELDSMess-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 unusedFree 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 1983CAppendix C - Gateway MonitoringC.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 1983C.2 Message Type 1: Gateway TrapDescription 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 1983Gateway Trap Message (cont'd.) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Count of this Trap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Additional Trap reports | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+HMP FIELDSSystem Type Gateway = 4Message Type Gateway Trap Message = 1Port Number UnusedControl Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 1983GATEWAY TRAP FIELDSGateway 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 1983C.3 Message Type 2: Gateway StatusDescription 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 1983Gateway 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 1983HMP FIELDSSystem Type Gateway = 4Message Type Gateway Status Message = 2Port Number UnusedControl Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 FIELDSVersion 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 1983Measurement 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 GatewayRouting 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 1983C.4 Message Type 3: Gateway ThroughputDescription 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 1983Gateway 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 1983Gateway 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 FIELDSSystem Type Gateway = 4Message Type Gateway Throughput Message = 3Port Number UnusedControl Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 FIELDSGateway 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 1983NEIGHBOR 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 1983C.5 Message Type 4: Gateway Host Traffic MatrixDescription 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 1983HMP FIELDSSystem Type Gateway = 4Message Type Gateway HTM Message = 4Port Number UnusedControl Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 FIELDSGateway 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 1983HTM 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 1983C.6 Message Type 6: Gateway RoutingDescription 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 1983Gateway 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 FIELDSSystem Type Gateway = 4Message Type Gateway Trap Message = 6Port Number UnusedControl Flag UnusedPassword or Returned Sequence Number UnusedSequence 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 1983GATEWAY ROUTING FIELDSGateway 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-
[8]ページ先頭