Gateway Monitoring Protocol
IEN 131
1 February 1980
David Flood Page
Bolt, Beranek and Newman Inc.
50 Moulton Street
Cambridge, Massachusetts 02238
(617) 491-1850
GATEWAY MONITORING PROTOCOL
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Communication Mechanism . . . . . . . . . . . . . . . . . . 2
2.1 Negotiation . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Requesting Reports . . . . . . . . . . . . . . . . . . . 3
2.3 Requesting Traps . . . . . . . . . . . . . . . . . . . . 4
3. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Report Formats . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Gateway description - type 0 . . . . . . . . . . . . 7
3.1.2 Echo - type 1 . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Throughput matrix - type 2 . . . . . . . . . . . . . 7
3.1.4 Status of all interfaces - type 3 . . . . . . . . . . 7
3.1.5 Queue activity - type 4 . . . . . . . . . . . . . . . 8
3.1.6 End to end statistics - type 5 . . . . . . . . . . . 8
3.1.7 Individual interface status - type 6 . . . . . . . . 8
3.1.8 Routing tables - type 7 . . . . . . . . . . . . . . . 9
3.2 Trap Formats . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Interface up/down - type 1 . . . . . . . . . . . . . 9
3.2.2 Neighbor gateway up/down - type 2 . . . . . . . . . . 9
3.2.3 Queue full - type 3 . . . . . . . . . . . . . . . . . 9
- 1 -
IEN 131 Gateway Monitoring Protocol
1. Introduction
This document details the protocol for the gateway monitoring
functions described in IEN 105, 'ARPA Catenet Monitoring and
Control'. It does not deal with the control functions or fault
isolation; these will be covered in a separate document.
The protocol described here contains a number of report
types. We realize that to implement them all may impose an
unacceptable load on a gateway; therefore the system is designed
to cater to gateways not implementing the complete protocol.
The protocol is described in two parts:
- Communication mechanism
- Data formats
2. Communication Mechanism
2.1 Negotiation
Because a gateway may not implement the complete protocol,
the Catenet Monitoring and Control Center (CMCC) is able to
discover, each time it makes a request of a gateway, whether the
gateway can satisfy that request. The method used is similar to
the DO - DONT - WILL - WONT mechanism in the Telnet protocol.
Briefly, this works as follows:
When the CMCC wants to obtain information from a gateway, it
sends a DO message to the gateway. If the gateway is able to make
the required response, it returns a WILL message accompanied by
the data requested. If it cannot do this, it sends back a WONT
message detailing why it could not satisfy the request. If the
gateway does not even implement this negotiation mechanism, or if
the message is lost in transit, then the CMCC will receive no
reply. In this case it will try up to two more times at 30 second
intervals. If it still gets no reply, then it acts as if a WONT
message had been received.
If the CMCC wants to stop the gateway from sending
information, then it sends a DONT message. The gateway then
responds with a WONT reply. The CMCC will try up to three times,
at 30 second intervals, to get this acknowledgement.
A gateway will need to implement this negotiation mechanism
in order to participate in the Monitoring and control system.
This is true regardless of how many of the report types are
implemented in the gateway.
- 2 -
IEN 131 Gateway Monitoring Protocol
2.2 Requesting Reports
Gateways may be requested to send out a series of reports at
regular intervals, as well as just sending back a single response.
So a DO REPORT request contains, in addition to the report type,
the number of reports required and the interval between reports.
The number of reports may be a special value (65535) meaning
'until further notice'. When the CMCC wants to turn off this kind
of report then it sends a DONT message to the gateway. The
gateway will then cease reporting and send back a WONT message.
The CMCC will send up to 3 DONT messages until it gets the WONT
response. If it still receives no answer then it gives up.
If a gateway is sending out regular reports, and it receives
a new request from the same source as the original request to send
the same report, then the new request is considered to supercede
the old one unless the new request is for a single report. In
this case the gateway should make the single response, but
continue sending the regular reports. If the new request is for
more than one report, then the gateway should reset the sequence
number (see below) and forget about the original request. The
question of dealing with requests from different sources is in
part an authorization question, and is not dealt with in this
document; however, gateways should in general be prepared to
satisfy requests for single reports from any source at any time.
A gateway may be unable to send out more than one report in
response to a single enquiry; i.e. it may insist on being polled.
If such a gateway receives a request for multiple reports, it
sends back a WONT REPORT reply, indicating that the number of
reports in the request was unacceptable. The CMCC will then send
a single report request, and will continue sending these requests
at appropriate intervals.
Each request sent out from the CMCC contains a report
identification number. This number is returned by the gateway in
the WILL REPORT or WONT REPORT message. When a request results in
more than one report message, those after the first have a
sequence number instead of the report id. Gateways will reset the
sequence number when they receive a DO REPORT, except in the case
of a single report request as described above. When a regular
report is requested, the WILL REPORT reply may or may not contain
the first report message. If it does not, then it should consist
only of the WILL REPORT header, with no extra data.
The following is a list of the report types.
- 3 -
IEN 131 Gateway Monitoring Protocol
Type
0 - Gateway description.
1 - Echo.
2 - Throughput transit matrix.
3 - Interface up/down status for all interfaces.
4 - Queue activity.
5 - End to end traffic statistics.
6 - Individual interface status.
7 - Routing table.
2.3 Requesting Traps
Besides the reports, a gateway may issue traps, which are
messages announcing some event in the gateway. A gateway may be
directed to start or stop sending the various kinds of traps,
using DO - DONT - WILL - WONT TRAP messages in the same way as
REPORT messages are used, except that normally the WILL TRAP
message will not be accompanied by data.
The following is a list of the trap types:
Type
1 - Interface up/down.
2 - Neighbor gateway up/down.
3 - Queue full.
Here, up/down on an interface refers to the ready line. For
a neighbor gateway it is determined according to the
gateway-gateway protocol in force.
3. Data Formats
Bits within a field are numbered starting at 0 and ordered
left to right, so that an octet with bit 0 set on has the numeric
value 128. Octets within numeric fields of more than 8 bits are
ordered so that the most significant octet comes first. For
example, a 32 bit numeric field with a value of 65536 would be
expressed as 0,1,0,0 in octets. For other fields of more than 8
bits, the first octet contains bits 0-7, the second 8-15, and so
on.
- 4 -
IEN 131 Gateway Monitoring Protocol
Monitoring Packets have the following format:
+--------------------+
! Local Header !
+--------------------+
! Internet Header !
+--------------------+
! Monitoring Header !
+--------------------+
! Data !
+--------------------+
The data may be absent.
The monitoring header has the following format:
Bits Contents
0 0 - Report or trap
1 - Negotiation message.
1 0 - Report
1 - Trap
2-3 For a negotiation message:
0 - DO
1 - DONT
2 - WILL
3 - WONT
For a report or trap: zero.
4-7 Reserved for future use.
8-15 Report or trap type.
16-31 For a negotiation message: Report Id.
For a report: Sequence number.
For a trap: data depending on trap type.
A DO REPORT message has the header:
0 1 2 3 4 5 6 7 8 15 16 31
+-------------------------------------------------------------+
! 1 ! 0 ! 0 0 ! 0 0 0 0 ! report type ! report id !
+-------------------------------------------------------------+
and the corresponding WILL REPORT message has:
- 5 -
IEN 131 Gateway Monitoring Protocol
0 1 2 3 4 5 6 7 8 15 16 31
+-------------------------------------------------------------+
! 1 ! 0 ! 1 0 ! 0 0 0 0 ! report type ! report id !
+-------------------------------------------------------------+
where the report id is the same as in the DO REPORT. A DONT
REPORT will begin with:
0 1 2 3 4 5 6 7 8 15 16 31
+-------------------------------------------------------------+
! 1 ! 0 ! 0 1 ! 0 0 0 0 ! report type ! report id !
+-------------------------------------------------------------+
and a WONT REPORT begins with:
0 1 2 3 4 5 6 7 8 15 16 31
+-------------------------------------------------------------+
! 1 ! 0 ! 1 1 ! 0 0 0 0 ! report type ! report id !
+-------------------------------------------------------------+
Headers for trap negotiation messages are similar except that
bit 1 is 1 instead of 0.
Trap messages have a header of only 2 octets:
0 1 2 3 4 5 6 7 8 15
+-----------------------------------------------+
! 0 ! 1 ! 0 0 ! 0 0 0 0 ! trap type !
+-----------------------------------------------+
DONT messages have no data. The WONT header is followed by a
single octet which indicates which field(s) in the request the
gateway objected to. Bits are set on according to the offending
field, as follows:
Bit Field
0 report or trap (i.e the gateway has not implemented
any reports, or traps)
1 report/trap type
2 number of reports (i.e. a gateway insists on being
polled)
3 reporting interval
DO REPORT messages have two 16-bit numbers which are the
number of reports required and the reporting interval in seconds,
in that order. A request for 65535 reports means 'until further
notice'. In addition, a type 6 report request has one extra octet
at the end containing the interface number.
The first response in any set of reports may also be the WILL
REPORT negotiation message and if so, the first 4 bits of the
monitoring header will have the value 1010 (negotiation, report,
- 6 -
IEN 131 Gateway Monitoring Protocol
WILL). Subsequent reports arising from the same request have a
header beginning with 0000 (report/trap, report, zero). If the
first response is the WILL REPORT without any data, then its
length must be 4 bytes, i.e. it consists only of the monitoring
header.
Trap messages may or may not have any data, depending on the
trap type.
3.1 Report Formats
3.1.1 Gateway description - type 0
The first item is the gateway name as four 8-bit ASCII
characters. The next item consists of two octets containing the
number of interfaces in the gateway, and the number of neighbors
the gateway has, in that order. This is then followed by two sets
of 32 bit numbers, whose size is given by the above octets. The
first set lists the addresses of each interface in the gateway,
and the second set lists the addresses of the gateway's neighbors.
3.1.2 Echo - type 1
There is no data in this message type. The gateway simply
returns the message to the place that sent it.
3.1.3 Throughput matrix - type 2
The report is a conceptual matrix with rows corresponding to
output interfaces and columns to input interfaces. The interfaces
are numbered from 0 to N-1 and there is an extra column for
packets dropped at the interface.
The matrix is expressed as N * (N+1) 32-bit counts, where N
is the number of interfaces. Each packet entering the gateway via
interface IN and leaving via interface OUT causes the count at
position (OUT * N) + IN to be incremented.
3.1.4 Status of all interfaces - type 3
The header is followed by a bit array in which the bit in
position i is 1 if interface i is up, 0 if it is down. Interfaces
are numbered starting at zero, as in the throughput matrix. The
ordering of the interfaces is defined in the Gateway Description
message, 3.1.1.
- 7 -
IEN 131 Gateway Monitoring Protocol
3.1.5 Queue activity - type 4
The header is followed by a set of reports, one for each
interface number. Each report in the set is 16 bits long and has
the following format:
Bits Contents
0-7 Length of input queue for this interface.
8-15 Length of output queue.
Interface numbering is as in the interface status message.
3.1.6 End to end statistics - type 5
The report has a set of counts, one for each
source/destination combination. The format of each entry is:
Bits Contents
0-7 Source network number.
8-15 Destination network number.
16-47 Count of packets source-destination.
The counts are cumulative and so is the list of
source/destination combinations, i.e. the report will contain
counts for every source/destination pair that has been recorded
since the gateway started up.
3.1.7 Individual interface status - type 6
A distinction here is made between error free and error
handling interfaces. The first four octets are the same in each
case, except for a code indicating the interface type. For an
error free interface, these four octets are the whole report. For
a VDH error handling interface there are another three 32-bit
counts of :
packet framing errors
packets received with bad checksum
packets retransmitted
The format of the first four octets is:
Bits Contents
0-7 Interface number
8-11 Status: 0 (down), 1 (up)
12-15 Interface type: 0 - error free, 1 - VDH.
16-31 Number of times this interface has gone down.
- 8 -
IEN 131 Gateway Monitoring Protocol
The down count is only reset at gateway startup time.
3.1.8 Routing tables - type 7
This is a table of variable length entries each containing a
network number, the minimum distance to that network from the
gateway, and the addresses of each neighbor on the minimum
distance path. The format of each entry is as follows:
8 bits number of neighbors
8 bits network number
8 bits distance to network
8 bits unused (allows 32-bit alignment of addresses)
32 bits first neighbor address
32 bits second neighbor address
(as many more neighbor addresses as necessary).
3.2 Trap Formats
Traps all have a 16-bit header starting with 0100
(report/trap, trap, zero). Data for the traps is as follows.
3.2.1 Interface up/down - type 1
Bits Contents
0-7 up (1) or down (0).
8-15 interface number.
3.2.2 Neighbor gateway up/down - type 2
Bits Contents
0-3 up (1) or down (0).
4-7 old gateway (zero) or new gateway (1).
8-15 unused (for 32-bit alignment of next field)
16-47 Neighbor gateway internet address.
A new gateway is one not previously heard from, which will
therefore cause an addition to the gateway's routing tables.
3.2.3 Queue full - type 3
Bits Contents
0-7 Interface number for queue.
8-15 Input (zero) or output (1) queue.
- 9 -
mirror server hosted at Truenetwork, Russian Federation.