home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc57.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  8.4 KB  |  284 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                              Mike Kraley (Harvard)
  8. Request for Comments #57                          John Newkirk (Harvard)
  9.  
  10.                                                    June 19, 1970
  11.  
  12.  
  13.                 Thoughts and Reflections on NWG/RFC #54
  14.  
  15.  
  16.        In the course of writing NWG/RFC #54 several new ideas became
  17. apparent.  Since these ideas had not previously been discussed by the
  18. NWG, or were sufficiently imprecise, it was decided not to include them
  19. in the official protocol proffering.  We thought, however, that they
  20. might be proper subjects for discussion and later inclusion in the
  21. second level protocol.
  22.  
  23. I.  Errors and Overflow
  24.  
  25.        In line with the discussion in NWG/RFC #48, we felt that two
  26. types of errors should be distinguished.  One is a real error, such as
  27. an RFC composed of two send sockets.  This type of error can only be
  28. generated by a broken NCP.  In the absence of hardware and software
  29. bugs, these events should never occur; the correct response upon
  30. detection of such an event was outlined in the description of the ERR
  31. command in NWG/RFC #54.
  32.        The other "error" is an overflow condition arising because
  33. finite system resources are exhausted.  An overflow condition could
  34. occur if an RFC was received, but there was no room to create the
  35. requisite tables and queues.  This is not a real error, in the sense
  36. that no one has done anything incorrect (expect perhaps the system
  37. planners in not providing sufficient table space, etc.)  Further, a
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970
  61.  
  62.  
  63. recovery procedure can be well defined, and simply entails repeating the
  64. request at a future time.  Thus, we believe an overflow condition should
  65. be distinguished from a real error.
  66.        In NWG/RFC #54 an overflow condition was reported by returning
  67. a CLS, as if the connection had been refused.  This sequence performs
  68. the necessary functions, and leaves the connection in the correct state,
  69. but the initiating user is misinformed.  He is deluded into thinking
  70. that he was refused by the foreign process, when, in fact, this was not
  71. the case.  In certain algorithms this difference is crucial.
  72.        In further defining error conditions, we felt that it would
  73. be helpful to specify why the error was detected, in addition to
  74. specifying what caused the error.  While writing the pseudo-Algol
  75. program mentioned in NWG/RFC #55 we differentiated 9 types of errors
  76. (listed below).  We would, therefore, like to propose the extension of
  77. the ERR message to include an 8-bit field following the op code to
  78. designate the type of error.  This would be followed by the length and
  79. text fields, as before.  We propose these error types;
  80.  
  81.        0.  UNSPECIFIED ERROR
  82.        1.  HOMOSEX  (invalid send/rcv pair in an RFC)
  83.        2.  ILLEGAL OP CODE
  84.        3.  ILLEGAL LEADER (bad message type, etc.)
  85.        4.  ILLEGAL COMMAND SEQUENCE
  86.        5.  ILLEGAL SOCKET SPECIFICATION - COMMAND
  87.        6.  ILLEGAL COMMAND LENGTH (last command in message was too short)
  88.        7.  CONNECTION NOT OPEN - DATA
  89.        8.  DATA OVERFLOW (message longer than advertised available
  90.            buffer space)
  91.        9.  ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970
  117.  
  118.  
  119.        In light of the other considerations mentioned earlier, we
  120. would also like to propose an additional control command to singify
  121. overflow:
  122.  
  123.         +-------------+-------------------+---------------------+
  124.         |     OVF     |     my socket     |     your socket     |
  125.         +-------------+-------------------+---------------------+
  126.  
  127. The format of the message is similar to that of the CLS message, which
  128. it replaces in this context.  The socket numbers are 32 bits long and
  129. correspond to the socket numbers in the RFC which is being rejected.
  130. The semantics of an incoming OVF should be indentical to an incoming
  131. CLS; in addition, the user should be informed that he has not been
  132. refused but rather has overtaxed the foreign host's resources.
  133.        An alternative to creating a separate control command can be
  134. realized by considering the similarity between a CLS and an OVF.
  135. Conceivably, an eight-bit field could be added to the CLS command to
  136. define its derivation.  We believe, however, that this alternative is
  137. conceptually inferior and practically more difficult to implement.
  138.        Overflow does not require serious consideration if it is a
  139. significantly rare occurrence.  We do not believe this will be the case,
  140. and we further believe that its absence will be an unnecessary
  141. restriction upon the user.
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970
  173.  
  174.  
  175. II.  Host Up and Host Down
  176.  
  177.        Significant problems can arise when a host goes down and then
  178. attempts to restart.  Two cases can easily be distinguished.  The first
  179. is a "soft" crash, where the system has prior notice that the machine is
  180. going down; sufficient time is available to execute pre-recovery
  181. procedures.  The other case can be termed a "hard" crash, often the
  182. result of a system failure.  Insignificant warning is usually given; but
  183. more important, the state of the machine after recovery is rarely
  184. predictable.
  185.        When a host returns from a hard crash, the network will be
  186. in an undefined state.  Very probably the NCP's data structures are
  187. destroyed or are meaningless.  The network has declared the host dead --
  188. but only to processes which attempted data transmission and were
  189. refused.  The only alternative for the crashed host is re-initialization
  190. of its tables.  What are the alternatives for the foreign hosts?
  191.        We would like to propose the addition of two control commands:
  192. RESET (RST) and RESET REPLY (RSR).  Each would consist solely of an op
  193. code with no parameters.  Upon receipt of an RST, a host would
  194. immediately terminate all connections with the sending host, but would
  195. not issue any CLS's.  The receiver of the RST would also note that the
  196. originator of the RST was alive, and would then echo an RSR to the
  197. sender.  When a host receives an RSR, he sould then note that the
  198. echoing host is alive.  (The function of RST can be partially simulated
  199. if a host will immediately close all relevant table entries upon
  200. discovering that another host is down.)
  201.        Thus, after a hard crash, all connections and request for
  202. connections are terminated.  The RST also informs all foreign hosts that
  203. we are again alive, and an RSR is received from every functioning NCP.
  204. A host live table (see NWG/RFC #55) can easily be
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228. RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970
  229.  
  230.  
  231. assembled, and establishment of connections can resume.
  232.        Related problems also crop up when we consider attempting
  233. to synchronize the network, which may still be carrying messages
  234. generated prior to the crash, with an NCP which has an initialized
  235. environment.  We lack the facilities for unblocking links, discarding
  236. messages, etc. -- facilities which this proposal will necessitate.
  237. Further interaction with BBN should resolve these difficulties.
  238.        The problems associated with "soft" crashes are not nearly
  239. as pressing, and they demand more sophisticated (i.e., complex)
  240. solutions.  Our preliminary experimentation with the network
  241. demonstrates that a good initialization and recovery protocol are far
  242. more necessary.
  243.  
  244.  
  245.  
  246.  
  247.        Many of the ideas presented herin wre germinated and/or
  248. jelled through conversations with Steve Crocker and Jon Postel.  We
  249. would also like to acknowledge the assistance of Jim Balter and Charles
  250. Kline of UCLA, who devoted a great deal of effort toward helping develop
  251. the pseudo-Algol program which was the predecessor of much of our recent
  252. documentation.
  253.  
  254.        [ This RFC was put into machine readable form for entry ]
  255.        [ into the online RFC archives by  Katsunori Tanaka 2/98 ]
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.                                                                 [Page 5]
  283.  
  284.