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.