home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc117.txt < prev    next >
Text File  |  1997-04-16  |  7KB  |  272 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Wong
  8. Request for Comments: 117                                         UCLA
  9. NIC #5826                                                 7 April 1971
  10.  
  11.  
  12.                  Some Comments on the Official Protocol
  13.  
  14.                [Categories B.1, C.1, C.2, C.3, C.4, C.5]
  15.  
  16.  
  17.  Document No. 1 and NWG/RFC No. 107 gave a very detailed description of
  18. connection establishment, connection termination and flow control over
  19. the Network.  Throughout the implementation of the NCP it was
  20. discovered that the handling of ERR control commands, messages of
  21. types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with
  22. the From-imp bit on are not well discussed so that problems arise when
  23. they occur.
  24.  
  25. The Protocol is not complete if the above situations are not handled
  26. clearly, and the Host-Host Protocol Glitch Cleaning Committee should
  27. take this into consideration.  In this document, experience with these
  28. unfavorable situations and suggestions for handling are given:
  29.  
  30.  
  31. 1.  ERR Control Commands
  32.  
  33. In Document No. 1, the following error conditions are described:
  34.  
  35.      a.  Illegal Op. code.
  36.      b.  End of message encountered before all expected parameters.
  37.      c.  Bad socket polarity within commands.
  38.      d.  Link number not in the range of 0 <= L < 32.
  39.      e.  A request (other than RTS/STR) on a non-existent socket.
  40.      f.  A request (ALL, GVB, RET, INR, INS) on a non-existent link
  41.          number.
  42.      g.  Transmit over non-existent link number.
  43.  
  44. Other error conditions are:
  45.  
  46.      h.  A request (GVB, RET, INR, INS) on an existent link, but
  47.          connection is not established.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.      i.  Transmit over an existent link, but connection is not
  61.          established.
  62.      j.  ALL or GVB on a send connection.
  63.      k.  RET on a receive connection.
  64.      l.  An attempt to send more than the allocated number of bits or
  65.          messages.
  66.      m.  ECO, ERP, ERR commands do not have the defined number of bits
  67.         of data.
  68.  
  69. In Document No. 1, each site is supposed to document the information
  70. on their ERR command.  No one has done that so far, and the main
  71. reason is we are not sure of what information is important.  In
  72. NWG/RFC No. 107, the text portion of the ERR Commands is decided to
  73. have a fixed length of 80 bits because 80 bits is long enough to hold
  74. the longest non-ERR command.  In some of the above error conditions,
  75. more information than the command itself is desirable.  It was noted
  76. that these error conditions arise very often in the experimental stage
  77. of the NCP.  If every NCP is operating properly, none of them should
  78. ever occur.  The ERR commands are therefore, an excellent debugging
  79. tool for the protocol.  So it is desirable to define a set of possible
  80. error conditions, and for each condition, define a set of arguments in
  81. the corresponding ERR command so that enough information is given to
  82. tell what's wrong.  The suggested arguments for each situation (a - m)
  83. are listed below:
  84.  
  85.      a.  1.  Op. code in error.
  86.          2.  Part of message following op. code (A maximum of 72
  87.              bits).
  88.  
  89.      b, c, d, e, f.
  90.          1.  The command in error.
  91.  
  92.      g.  1.  Link number,
  93.          2.  Beginning of message (A maximum of 72 bits),
  94.  
  95.      h.  1.  Command in error.
  96.          2.  Socket numbers for the connection.
  97.          3.  Status of the connection.
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.      i.  1.  Link number,
  114.          2.  Beginning of message (A maximum of 72 bits),
  115.          3.  Socket numbers for the connection.
  116.          4.  Status of the connection.
  117.  
  118.      j, k.
  119.          1.  Command in error.
  120.          2.  Socket numbers for the connection.
  121.  
  122.      l.  1.  Link number.
  123.          2.  Beginning of message (A maximum of 72 bits).
  124.          3.  Number of bits sent.
  125.          4.  Number of bits allocated.
  126.          5.  Number of messages allocated.
  127.  
  128.      m.  1.  The Command in error.
  129.  
  130. Each of the ERR commands should have a special error code (8 bits) to
  131. tell the error type, an 80-bits field to store the command in error,
  132. and additional fields for socket numbers and other information.
  133.  
  134. 2.  Imp-to-host messages of types other than 0, 4, and 5.
  135.  
  136. From the BBN report 1822, the following message types will cause
  137. difficulty in the implementation of the Protocol.
  138.  
  139.      a.  Type 2 - Imp going down.
  140.      b.  Type 7 - Destination host or imp dead.
  141.      c.  Type 9 - Incomplete transmission.
  142.  
  143. It was discovered that on sending a message to a site whose imp or
  144. host is not running, a Type 7 or Type 9 message is returned.  This
  145. can happen in two situations:
  146.  
  147.      a.  The foreign host or imp is not up at all.
  148.      b.  Some connections have been established, and the foreign host
  149.          or imp goes down.
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. The first situation does not cause much problem because the NCP has no
  167. entry in its table corresponding to this site.
  168.  
  169. The second situation is more complicated, because if the table entries
  170. for the connections to the dead host are not cleared, by the time this
  171. host comes up again, the table entries still exist and the information
  172. will be very misleading.  One suggestion to solve this problem is:
  173.  
  174.      a.  Whenever a NCP comes up, it send a RESET Control Command to
  175.          every other site.
  176.      b.  Associated with each site there is a bit called the up-bit.
  177.          If a RESET-reply command is received from some site, the
  178.          corresponding up-bit is set to 1.  Race condition can be
  179.          avoided by ignoring all messages from sites which have not
  180.          returned the RESET-reply command.
  181.      c.  Messages can only be sent to sites with the up-bit on.
  182.      d.  If a RESET control command is received, the Table entries
  183.          corresponding to the site are cleared, a RESET-reply is
  184.          immediately returned, and the up-bit for the site is set.
  185.      e.  The up-bit is reset to 0 when a Type 7 or Type 9 message is
  186.          received from a particular site.
  187.  
  188. The above solution will handle the Type 2 messages also.  When a host
  189. receives a Type 2 message, there is no way for it to tell the other
  190. NCP's that its imp is going down.  Subsequent messages to this host
  191. will return a Type 7 or 9 message.  The solution above will then come
  192. into effect.
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219. With the introduction of the RESET and RESET-reply Control command,
  220. the ECO and ERP control command are no longer important and should be
  221. removed.
  222.  
  223. 3.  Messages with the From-imp bit on.
  224.  
  225. These kinds of messages are not discussed at all.  Some statistical
  226. measurements have been made on messages with the From-imp bit on.  We
  227. should classify what these messages represent.
  228.  
  229.  
  230.        [ This RFC was put into machine readable form for entry ]
  231.          [ into the online RFC archives by Randy Dunlap 4/97]
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.                                                                 [Page 5]
  271.  
  272.