GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien131
                     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. 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:
  1. Communication mechanism
  2. 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.
  1. 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.
  1. 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.
  1. 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:
  1. 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,
  1. 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.
  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.
  1. 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.
  1. 9 -
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien131.txt · Last modified: 2001/06/25 19:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki