home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / inet / ien / ien_131. < prev    next >
Encoding:
Text File  |  1988-12-01  |  18.3 KB  |  574 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.                        Gateway Monitoring Protocol
  9.  
  10.  
  11.                                  IEN 131
  12.  
  13.  
  14.                              1 February 1980
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.                              David Flood Page
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.                       Bolt, Beranek and Newman Inc.
  37.                             50 Moulton Street
  38.                       Cambridge, Massachusetts 02238
  39.  
  40.  
  41.                               (617) 491-1850
  42.  
  43.  
  44.  
  45.  
  46.  
  47.                         GATEWAY MONITORING PROTOCOL
  48.  
  49.  
  50.  
  51.  
  52.     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  53.  
  54.  
  55.     2.  Communication Mechanism  . . . . . . . . . . . . . . . . . . 2
  56.  
  57.       2.1  Negotiation . . . . . . . . . . . . . . . . . . . . . . . 2
  58.  
  59.       2.2  Requesting Reports  . . . . . . . . . . . . . . . . . . . 3
  60.  
  61.       2.3  Requesting Traps  . . . . . . . . . . . . . . . . . . . . 4
  62.  
  63.  
  64.     3.  Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
  65.  
  66.       3.1  Report Formats  . . . . . . . . . . . . . . . . . . . . . 7
  67.  
  68.         3.1.1  Gateway description - type 0  . . . . . . . . . . . . 7
  69.  
  70.         3.1.2  Echo - type 1 . . . . . . . . . . . . . . . . . . . . 7
  71.  
  72.         3.1.3  Throughput matrix - type 2  . . . . . . . . . . . . . 7
  73.  
  74.         3.1.4  Status of all interfaces - type 3 . . . . . . . . . . 7
  75.  
  76.         3.1.5  Queue activity - type 4 . . . . . . . . . . . . . . . 8
  77.  
  78.         3.1.6  End to end statistics - type 5  . . . . . . . . . . . 8
  79.  
  80.         3.1.7  Individual interface status - type 6  . . . . . . . . 8
  81.  
  82.         3.1.8  Routing tables - type 7 . . . . . . . . . . . . . . . 9
  83.  
  84.       3.2  Trap Formats  . . . . . . . . . . . . . . . . . . . . . . 9
  85.  
  86.         3.2.1  Interface up/down - type 1  . . . . . . . . . . . . . 9
  87.  
  88.         3.2.2  Neighbor gateway up/down - type 2 . . . . . . . . . . 9
  89.  
  90.         3.2.3  Queue full - type 3 . . . . . . . . . . . . . . . . . 9
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.                                   - 1 -
  102.  
  103.  
  104.     IEN 131            Gateway Monitoring Protocol
  105.  
  106.  
  107.     1.  Introduction
  108.  
  109.          This document details the protocol for the gateway monitoring
  110.     functions described in  IEN  105,  'ARPA  Catenet  Monitoring  and
  111.     Control'.   It  does  not deal with the control functions or fault
  112.     isolation;  these will be covered in a separate document.
  113.  
  114.          The protocol described  here  contains  a  number  of  report
  115.     types.   We  realize  that  to  implement  them  all may impose an
  116.     unacceptable load on a gateway;  therefore the system is  designed
  117.     to cater to gateways not implementing the complete protocol.
  118.  
  119.  
  120.          The protocol is described in two parts:
  121.  
  122.               - Communication mechanism
  123.               - Data formats
  124.  
  125.  
  126.     2.  Communication Mechanism
  127.  
  128.     2.1  Negotiation
  129.  
  130.          Because  a  gateway  may not implement the complete protocol,
  131.     the Catenet Monitoring  and  Control  Center  (CMCC)  is  able  to
  132.     discover,  each  time it makes a request of a gateway, whether the
  133.     gateway can satisfy that request.  The method used is  similar  to
  134.     the  DO  -  DONT  -  WILL - WONT mechanism in the Telnet protocol.
  135.     Briefly, this works as follows:
  136.  
  137.          When the CMCC wants to obtain information from a gateway,  it
  138.     sends a DO message to the gateway.  If the gateway is able to make
  139.     the  required  response,  it returns a WILL message accompanied by
  140.     the data requested.  If it cannot do this, it sends  back  a  WONT
  141.     message  detailing  why  it could not satisfy the request.  If the
  142.     gateway does not even implement this negotiation mechanism, or  if
  143.     the  message  is  lost  in  transit, then the CMCC will receive no
  144.     reply.  In this case it will try up to two more times at 30 second
  145.     intervals.  If it still gets no reply, then it acts as if  a  WONT
  146.     message had been received.
  147.  
  148.          If   the   CMCC  wants  to  stop  the  gateway  from  sending
  149.     information, then it sends  a  DONT  message.   The  gateway  then
  150.     responds  with a WONT reply.  The CMCC will try up to three times,
  151.     at 30 second intervals, to get this acknowledgement.
  152.  
  153.          A gateway will need to implement this  negotiation  mechanism
  154.     in  order  to  participate  in  the Monitoring and control system.
  155.     This is true regardless of  how  many  of  the  report  types  are
  156.     implemented in the gateway.
  157.  
  158.  
  159.  
  160.  
  161.                                   - 2 -
  162.  
  163.  
  164.     IEN 131            Gateway Monitoring Protocol
  165.  
  166.  
  167.     2.2  Requesting Reports
  168.  
  169.          Gateways  may be requested to send out a series of reports at
  170.     regular intervals, as well as just sending back a single response.
  171.     So a DO REPORT request contains, in addition to the  report  type,
  172.     the  number  of reports required and the interval between reports.
  173.     The number of reports may  be  a  special  value  (65535)  meaning
  174.     'until further notice'.  When the CMCC wants to turn off this kind
  175.     of  report  then  it  sends  a  DONT  message to the gateway.  The
  176.     gateway will then cease reporting and send back  a  WONT  message.
  177.     The  CMCC  will  send up to 3 DONT messages until it gets the WONT
  178.     response.  If it still receives no answer then it gives up.
  179.  
  180.          If a gateway is sending out regular reports, and it  receives
  181.     a new request from the same source as the original request to send
  182.     the  same  report, then the new request is considered to supercede
  183.     the old one unless the new request is for  a  single  report.   In
  184.     this  case  the  gateway  should  make  the  single  response, but
  185.     continue sending the regular reports.  If the new request  is  for
  186.     more  than  one report, then the gateway should reset the sequence
  187.     number (see below) and forget about  the  original  request.   The
  188.     question  of  dealing  with  requests from different sources is in
  189.     part an authorization question, and is  not  dealt  with  in  this
  190.     document;  however,  gateways  should  in  general  be prepared to
  191.     satisfy requests for single reports from any source at  any  time.
  192.  
  193.          A  gateway  may be unable to send out more than one report in
  194.     response to a single enquiry;  i.e. it may insist on being polled.
  195.     If such a gateway receives a  request  for  multiple  reports,  it
  196.     sends  back  a  WONT  REPORT  reply, indicating that the number of
  197.     reports in the request was unacceptable.  The CMCC will then  send
  198.     a  single report request, and will continue sending these requests
  199.     at appropriate intervals.
  200.  
  201.          Each request  sent  out  from  the  CMCC  contains  a  report
  202.     identification  number.  This number is returned by the gateway in
  203.     the WILL REPORT or WONT REPORT message.  When a request results in
  204.     more than one  report  message,  those  after  the  first  have  a
  205.     sequence number instead of the report id.  Gateways will reset the
  206.     sequence  number when they receive a DO REPORT, except in the case
  207.     of a single report request as described  above.   When  a  regular
  208.     report  is requested, the WILL REPORT reply may or may not contain
  209.     the first report message.  If it does not, then it should  consist
  210.     only of the WILL REPORT header, with no extra data.
  211.  
  212.  
  213.          The following is a list of the report types.
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.                                   - 3 -
  222.  
  223.  
  224.     IEN 131            Gateway Monitoring Protocol
  225.  
  226.  
  227.      Type
  228.  
  229.       0 - Gateway description.
  230.       1 - Echo.
  231.       2 - Throughput transit matrix.
  232.       3 - Interface up/down status for all interfaces.
  233.       4 - Queue activity.
  234.       5 - End to end traffic statistics.
  235.       6 - Individual interface status.
  236.       7 - Routing table.
  237.  
  238.  
  239.     2.3  Requesting Traps
  240.  
  241.          Besides  the  reports,  a  gateway may issue traps, which are
  242.     messages announcing some event in the gateway.  A gateway  may  be
  243.     directed  to  start  or  stop  sending the various kinds of traps,
  244.     using DO - DONT - WILL - WONT TRAP messages in  the  same  way  as
  245.     REPORT  messages  are  used,  except  that  normally the WILL TRAP
  246.     message will not be accompanied by data.
  247.  
  248.          The following is a list of the trap types:
  249.  
  250.      Type
  251.  
  252.       1 - Interface up/down.
  253.       2 - Neighbor gateway up/down.
  254.       3 - Queue full.
  255.  
  256.          Here, up/down on an interface refers to the ready line.   For
  257.     a   neighbor   gateway   it   is   determined   according  to  the
  258.     gateway-gateway protocol in force.
  259.  
  260.     3.  Data Formats
  261.  
  262.          Bits within a field are numbered starting at  0  and  ordered
  263.     left  to right, so that an octet with bit 0 set on has the numeric
  264.     value 128.  Octets within numeric fields of more than 8  bits  are
  265.     ordered  so  that  the  most  significant  octet comes first.  For
  266.     example, a 32 bit numeric field with a value  of  65536  would  be
  267.     expressed  as  0,1,0,0 in octets.  For other fields of more than 8
  268.     bits, the first octet contains bits 0-7, the second 8-15,  and  so
  269.     on.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.                                   - 4 -
  282.  
  283.  
  284.     IEN 131            Gateway Monitoring Protocol
  285.  
  286.  
  287.          Monitoring Packets have the following format:
  288.  
  289.                           +--------------------+
  290.                           !   Local Header     !
  291.                           +--------------------+
  292.                           ! Internet  Header   !
  293.                           +--------------------+
  294.                           ! Monitoring Header  !
  295.                           +--------------------+
  296.                           !        Data        !
  297.                           +--------------------+
  298.  
  299.     The data may be absent.
  300.  
  301.          The monitoring header has the following format:
  302.  
  303.      Bits          Contents
  304.  
  305.        0           0 - Report or trap
  306.                    1 - Negotiation message.
  307.  
  308.        1           0 - Report
  309.                    1 - Trap
  310.  
  311.      2-3           For a negotiation message:
  312.                    0 - DO
  313.                    1 - DONT
  314.                    2 - WILL
  315.                    3 - WONT
  316.                    For a report or trap: zero.
  317.  
  318.      4-7           Reserved for future use.
  319.  
  320.      8-15          Report or trap type.
  321.  
  322.     16-31          For a negotiation message: Report Id.
  323.                    For a report: Sequence number.
  324.                    For a trap: data depending on trap type.
  325.  
  326.     A DO REPORT message has the header:
  327.  
  328.        0   1   2   3   4   5   6   7  8            15 16         31
  329.      +-------------------------------------------------------------+
  330.      ! 1 ! 0 ! 0   0 ! 0   0   0   0 !  report type  !  report id  !
  331.      +-------------------------------------------------------------+
  332.  
  333.  
  334.     and the corresponding WILL REPORT message has:
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.                                   - 5 -
  342.  
  343.  
  344.     IEN 131            Gateway Monitoring Protocol
  345.  
  346.  
  347.        0   1   2   3   4   5   6   7  8            15 16         31
  348.      +-------------------------------------------------------------+
  349.      ! 1 ! 0 ! 1   0 ! 0   0   0   0 !  report type  !  report id  !
  350.      +-------------------------------------------------------------+
  351.  
  352.     where  the  report  id  is  the  same as in the DO REPORT.  A DONT
  353.     REPORT will begin with:
  354.  
  355.        0   1   2   3   4   5   6   7  8            15 16         31
  356.      +-------------------------------------------------------------+
  357.      ! 1 ! 0 ! 0   1 ! 0   0   0   0 !  report type  !  report id  !
  358.      +-------------------------------------------------------------+
  359.  
  360.     and a WONT REPORT begins with:
  361.  
  362.        0   1   2   3   4   5   6   7  8            15 16         31
  363.      +-------------------------------------------------------------+
  364.      ! 1 ! 0 ! 1   1 ! 0   0   0   0 !  report type  !  report id  !
  365.      +-------------------------------------------------------------+
  366.  
  367.          Headers for trap negotiation messages are similar except that
  368.     bit 1 is 1 instead of 0.
  369.  
  370.          Trap messages have a header of only 2 octets:
  371.  
  372.               0   1   2   3   4   5   6   7  8            15
  373.             +-----------------------------------------------+
  374.             ! 0 ! 1 ! 0   0 ! 0   0   0   0 !   trap type   !
  375.             +-----------------------------------------------+
  376.  
  377.          DONT messages have no data.  The WONT header is followed by a
  378.     single octet which indicates which field(s)  in  the  request  the
  379.     gateway  objected  to.  Bits are set on according to the offending
  380.     field, as follows:
  381.  
  382.          Bit    Field
  383.           0     report or trap  (i.e the gateway has not implemented
  384.                                   any reports, or traps)
  385.           1     report/trap type
  386.           2     number of reports  (i.e. a gateway insists on being
  387.                                         polled)
  388.           3     reporting interval
  389.  
  390.          DO REPORT messages have two  16-bit  numbers  which  are  the
  391.     number  of reports required and the reporting interval in seconds,
  392.     in that order.  A request for 65535 reports means  'until  further
  393.     notice'.  In addition, a type 6 report request has one extra octet
  394.     at the end containing the interface number.
  395.  
  396.          The first response in any set of reports may also be the WILL
  397.     REPORT  negotiation  message  and  if  so, the first 4 bits of the
  398.     monitoring header will have the value 1010  (negotiation,  report,
  399.  
  400.  
  401.                                   - 6 -
  402.  
  403.  
  404.     IEN 131            Gateway Monitoring Protocol
  405.  
  406.  
  407.     WILL).   Subsequent  reports  arising from the same request have a
  408.     header beginning with 0000 (report/trap, report,  zero).   If  the
  409.     first  response  is  the  WILL  REPORT  without any data, then its
  410.     length must be 4 bytes, i.e. it consists only  of  the  monitoring
  411.     header.
  412.  
  413.          Trap  messages may or may not have any data, depending on the
  414.     trap type.
  415.  
  416.     3.1  Report Formats
  417.  
  418.     3.1.1  Gateway description - type 0
  419.  
  420.          The first item is  the  gateway  name  as  four  8-bit  ASCII
  421.     characters.   The  next item consists of two octets containing the
  422.     number of interfaces in the gateway, and the number  of  neighbors
  423.     the gateway has, in that order.  This is then followed by two sets
  424.     of  32  bit numbers, whose size is given by the above octets.  The
  425.     first set lists the addresses of each interface  in  the  gateway,
  426.     and the second set lists the addresses of the gateway's neighbors.
  427.  
  428.     3.1.2  Echo - type 1
  429.  
  430.          There  is  no  data in this message type.  The gateway simply
  431.     returns the message to the place that sent it.
  432.  
  433.     3.1.3  Throughput matrix - type 2
  434.  
  435.          The report is a conceptual matrix with rows corresponding  to
  436.     output interfaces and columns to input interfaces.  The interfaces
  437.     are  numbered  from  0  to  N-1  and  there is an extra column for
  438.     packets dropped at the interface.
  439.  
  440.          The matrix is expressed as N * (N+1) 32-bit counts,  where  N
  441.     is the number of interfaces.  Each packet entering the gateway via
  442.     interface  IN  and  leaving  via interface OUT causes the count at
  443.     position (OUT * N) + IN to be incremented.
  444.  
  445.     3.1.4  Status of all interfaces - type 3
  446.  
  447.          The header is followed by a bit array in  which  the  bit  in
  448.     position i is 1 if interface i is up, 0 if it is down.  Interfaces
  449.     are  numbered  starting at zero, as in the throughput matrix.  The
  450.     ordering of the interfaces is defined in the  Gateway  Description
  451.     message, 3.1.1.
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.                                   - 7 -
  462.  
  463.  
  464.     IEN 131            Gateway Monitoring Protocol
  465.  
  466.  
  467.     3.1.5  Queue activity - type 4
  468.  
  469.          The  header  is  followed  by  a set of reports, one for each
  470.     interface number.  Each report in the set is 16 bits long and  has
  471.     the following format:
  472.  
  473.      Bits     Contents
  474.  
  475.      0-7      Length of input queue for this interface.
  476.      8-15     Length of output queue.
  477.  
  478.          Interface numbering is as in the interface status message.
  479.  
  480.     3.1.6  End to end statistics - type 5
  481.  
  482.          The   report   has   a   set   of   counts,   one   for  each
  483.     source/destination combination.  The format of each entry is:
  484.  
  485.      Bits      Contents
  486.  
  487.      0-7       Source network number.
  488.      8-15      Destination network number.
  489.      16-47     Count of packets source-destination.
  490.  
  491.          The  counts  are  cumulative  and   so   is   the   list   of
  492.     source/destination  combinations,  i.e.  the  report  will contain
  493.     counts for every source/destination pair that  has  been  recorded
  494.     since the gateway started up.
  495.  
  496.     3.1.7  Individual interface status - type 6
  497.  
  498.          A  distinction  here  is  made  between  error free and error
  499.     handling interfaces.  The first four octets are the same  in  each
  500.     case,  except  for  a  code indicating the interface type.  For an
  501.     error free interface, these four octets are the whole report.  For
  502.     a VDH error handling interface  there  are  another  three  32-bit
  503.     counts of :
  504.  
  505.      packet framing errors
  506.      packets received with bad checksum
  507.      packets retransmitted
  508.  
  509.          The format of the first four octets is:
  510.  
  511.      Bits        Contents
  512.  
  513.      0-7         Interface number
  514.      8-11        Status: 0 (down), 1 (up)
  515.      12-15       Interface type: 0 - error free, 1 - VDH.
  516.      16-31       Number of times this interface has gone down.
  517.  
  518.  
  519.  
  520.  
  521.                                   - 8 -
  522.  
  523.  
  524.     IEN 131            Gateway Monitoring Protocol
  525.  
  526.  
  527.          The down count is only reset at gateway startup time.
  528.  
  529.     3.1.8  Routing tables - type 7
  530.  
  531.          This  is a table of variable length entries each containing a
  532.     network number, the minimum distance  to  that  network  from  the
  533.     gateway,  and  the  addresses  of  each  neighbor  on  the minimum
  534.     distance path.  The format of each entry is as follows:
  535.  
  536.       8 bits number of neighbors
  537.       8 bits network number
  538.       8 bits distance to network
  539.       8 bits unused (allows 32-bit alignment of addresses)
  540.       32 bits first neighbor address
  541.       32 bits second neighbor address
  542.       (as many more neighbor addresses as necessary).
  543.  
  544.     3.2  Trap Formats
  545.  
  546.          Traps  all  have  a  16-bit   header   starting   with   0100
  547.     (report/trap, trap, zero).  Data for the traps is as follows.
  548.  
  549.     3.2.1  Interface up/down - type 1
  550.  
  551.        Bits    Contents
  552.  
  553.        0-7     up (1) or down (0).
  554.        8-15    interface number.
  555.  
  556.     3.2.2  Neighbor gateway up/down - type 2
  557.  
  558.        Bits    Contents
  559.  
  560.        0-3     up (1) or down (0).
  561.        4-7     old gateway (zero) or new gateway (1).
  562.        8-15    unused (for 32-bit alignment of next field)
  563.        16-47   Neighbor gateway internet address.
  564.  
  565.          A  new  gateway  is one not previously heard from, which will
  566.     therefore cause an addition to the gateway's routing tables.
  567.  
  568.     3.2.3  Queue full - type 3
  569.  
  570.        Bits    Contents
  571.  
  572.        0-7     Interface number for queue.
  573.        8-15    Input (zero) or output (1) queue.
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.                                   - 9 -
  582.  
  583.  
  584.