rfc101.txt

RFC 的详细文档！

   BBN, TENEX PROJECT:  Final stage of incorporating NCP in TENEX.  A
   connection was attempted to Utah, but some bugs were found.  The NCP
   treats the network as a file in a way integral with other types of
   files.  The NCP includes a teletype interface.  They hope to
   incorporate the NCP in SRI'S TENEX system by the end of the month.

   BBN, NETWORK GROUP:  reported that they were working on three areas

      1. Improving the current network

      2. Working on a 316 version of the IMP and as a Terminal Interface
      Processor (TIMP)

      3. Accounting




Watson                                                          [Page 5]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   There are currently 15 IMPs connected to the network.  A new software
   system with minor changes is expected by March.

   The TIMP uses the 316.  A hardware design exists, but they are still
   defining the software.  A TIMP can handle up to 64 variable speed
   terminals both sync and assync.  The first machine is to go to MITRE
   in September.

   BBN emphasized that there are 3 products:  a 516 IMP, a 316 IMP, and
   a 316 TIMP.  The 316 IMP is less expensive than the 516 IMP and can
   connect to one host.  BBN is not planning at the moment to exchange
   316 IMPs for 516 IMPs.  The two are plug-plug compatible.

   SDC:  In the debug phase for their NCP and expect it up in 4 to 6
   weeks.  Maybe by 8 weeks their T/S available for network use.  Their
   T/S is a 360/65 running the ADEPT system.

   CASE WESTERN RESERVE UNIVERSITY:  The IMP has been connected for
   about one month, but as yet have no NCP.  They are planning to use
   the NCP implemented at Harvard.  Case has a PDP-10/50 system.  They
   expect to be up in two to three months.

   HARVARD:  Harvard has a PDP-1 and PDP-10 connected to the IMP.  The
   NCP for the 10 is in final debugging.  The PDP-1 is for refreshing
   displays.  The PDP-10 is for linguistic research and students.
   Expect to be up in one to two months.

   SRI-ARC:  SRI has been in the final stage of conversion from an XDS
   940 to a PDP-10.  They plan to use the BBN TENEX NCP and should be up
   in three or four weeks.

   MIT DYNAMIC MODELING - PDP-10:  They expect an NCP to be working by
   March.

   MIT MULTICS:  They are connected to the IMP and expect their NCP to
   be in the final debug stage in four weeks.  As Multics is a service
   machine, they don't have unlimited access and must perform checkout
   at off hours.  They expect to offer regular service to the network in
   three or four months.

   UTAH:  PDP-10/50 probably going to be running TENEX in the fall.
   Their NCP is being written in a higher level language (Euler run
   interpretively) and are debugging in conjunction with BBN.  They have
   connected to and logged into themselves and expect a debugged version
   within a month.






Watson                                                          [Page 6]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   LINCOLN LABORATORY, TX-2:  They are testing the IMP interface, found
   errors in Lincoln hardware.  Currently, no data errors, but have
   errors with message IDs.  They expect their NCP with logger to be up
   by April 15.  They indicated that for testing purposes, they would
   like to bring up their IMP without being open to network traffic.
   BBN says that there is a way to echo to yourself without being open
   to the network (contact BBN for details).

   LINCOLN LABORATORY, 360/97:  Running CP/CMS.  The IMP interface was
   completed last month.  The NCP and Logger are working.  They are
   planning to put up the NCP as a regular service in April.  On request
   experiments with them can be run sooner.

   UCSB:  Has had their NCP since October.  The NCP runs as independent
   batch job.  They plan to provide service to their On-Line System (a
   manual is in the NIC collection at each site NIC (5480).  They plan
   to be on the air morning to evening on a regular basis.  There are
   some interface bugs as indicated earlier.

   RAND:  360/65.  Their NCP is a user process and can be resident.  It
   requires 8K bytes and does not have a logger.

   UCLA, Sigma-7:  Their NCP is in final debugging.  They expect to be
   up by March 1 with NCP, logger, and typewriter connection program.

   COMPUTER CORPORATION OF AMERICA (CCA):  Has just started a project to
   create a node for the 10-12 bit laser store.  They are going to use a
   PDP-10 as a front end.  They are developing a language for data
   manipulation.  The store will also be connected to the B-6500-ILLIAC
   IV.  They are planning data compression as part of their language to
   ease the problems in use of the network's 50 kilobit line.  They are
   concentrating on security and privacy measures.  Initial emphasis
   will be on shared files.  Installation is planned during 1972.

   The following projects did not have representatives at the meeting.
   Steve Crocker reported on their status.

      CMU:  PDP-10/50:  Their IMP is connected, and they are planning to
      use the Harvard NCP.

      SRI-AI PROJECT:  PDP10.  They are planning to run TENEX in the
      fall.

      STANFORD-AI:  They are not connected yet, but expect to be on by
      summer.






Watson                                                          [Page 7]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   The above completed the review of status.  Steve Crocker then
   indicated that the old NWG mailing list was no longer to be used and
   that the list maintained by the NIC (5731,) was the one to be used or
   that the NIC would handle distribution by sending things through your
   station agent to them.  If your station agent or liaison person
   should change, please let the NIC know immediately.

   HOST-HOST LOGGER PROTOCOL DISCUSSION:  Tom Skinner of Multics opened
   the discussion of the logger by indicating that they wanted at least
   an interim protocol so that use of the network could get started.
   They had handed out RFC #98 NIC(5744), containing their ideas
   Wednesday night.  SRI-ARC had a similar document, RFC #97, NIC
   (5740), handed out Wednesday night also.  Multics recommended the
   revised logger protocol of RFC #80, NIC (5608).

      Some discussion on the relative merits of the logger protocol of
      RFC #66, NIC (5409), versus RFC #80 was given.  The protocol of
      #80 had some potential problems due to assumptions which must be
      made after the initial contact was established.

      The result of the discussion was that the logger protocol of RFC
      #66 was adopted with the correction that the allocate commands
      were to be issued after the connection was established.

      There seemed to be a need for an official document to be issued
      with the correct logger specification given.

      Tom also recommended that initial communication to the logger be
      in 7-bit ASCII in a 8-bit field.  There was some discussion as to
      whether the eighth bit should be a 0 or a 1.  It was finally
      decided that it should be a 0.

      Steve then listed some known problems or questions about the
      host-host protocol.

      1)  Echo

      2)  Message Type

      3)  Interrupts

      4)  Marking-Padding

      5)  Half Duplex vs. Full Duplex communication during the
      establishing of a socket.






Watson                                                          [Page 8]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


      With regard to marking the following choices existed

      a)  leave alone

      b)  separate the heading and data into two messages

      c)  have message by multiples of 72 bits

      With regard to interrupts (INS, INR), there was a synchronization
      problem with regard to message transmission.  That is, a message
      could be sent and then an interrupt issued.  The interrupt could
      arrive before the message, in the middle of the message.  Some way
      of marking the point in the data stream where an interrupt was
      sent is needed.

   A subgroup was appointed to consider the above Host-Host problems.
   Shortly, they would issue an RFC with modifications to the Host-Host
   protocol, then collect comments and then issue an official revision.
   People with suggestions should contact the committee.  The committee
   would also be contacting the sites.  The committee is:

      S. Crocker, UCLA (Chairman)

      R. Tomlinson, BBN

      T. Barkalow, Lincoln Lab

      G. Grossman, University of Illinois

      J. White, UCSB

      R. Bressler, MIT, Project MAC

   The discussion then returned to problems of typewriter access to the
   network.  The problems are presented in RFC #97, NIC (5740).  Some
   are:

      a)  Character set

      b)  End of Line

      c)  Interrupts

      d)  Message Format

      e)  Half Duplex, Full Duplex





Watson                                                          [Page 9]

RFC 101        NOTES ON THE NETWORK WORKING GROUP MEETING  February 1971


   These problems were given to a committee on typewriter connection
   protocol for solution:

      Tom O'Sullivan, Raytheon (Chairman)

      Ed Meyer, MIT-MAC

      John Melvin, SRI-ARC

      Bob Long, SDC

      Bob Metcalfe, Harvard

      Wil Crowther, BBN

   This committee will come up quickly (within a week) with an interim