home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 00s / rfc38.txt < prev    next >
Text File  |  1997-03-12  |  3KB  |  60 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   Stephen M. Wolfe
  8. Request for Comments: 38                                        UCLA CCN
  9.                                                            20 March 1970
  10.  
  11.                       Comments on Network Protocol
  12.                             from NWG/RFC #36
  13.  
  14.    The proposed protocol does not allow for the possible multiplexing of
  15.    connections over links.
  16.  
  17.    Generally, this presents no problem, but it might cause loading
  18.    restrictions in the future. Two cases where routing multiple
  19.    connections over the same link are apparent:
  20.  
  21.          a) Where a user has several high speed connections, such as
  22.             between processes that transmit files over the network.
  23.             Assigning these connections to the same link limits the
  24.             percentage of network resources that may be used by that
  25.             user. This becomes particularly important when several
  26.             store-and-forward IMP's are used by the network to effect
  27.             the communication.
  28.          b) When two hosts each have their own independent network and
  29.             desire to allow access to the other hosts's network over
  30.             the ARPA net, a shortage of links may develop. Again, the
  31.             assignment of several connections to the same link could
  32.             help solve the problem.
  33.  
  34.    The following changes in the protocol would make possible the future
  35.    use of multiplexed links. It is not necessary to add the
  36.    multiplexing, itself, to the protocol at this time.
  37.  
  38.          a) The END and RDY must specify relevant sockets in addition to
  39.             the link number. Only the local socket name need be
  40.             supplied.
  41.          b) Problems arise with the RSM and SPD commands. Should they
  42.             refer to an entire link, or just to a given connection?
  43.             Since there is a proposal to modify the RFNM to accommodate
  44.             these commands, it might be better to add another set of
  45.             commands to block and unblock a connection, but I am not
  46.             convinced that that is the best solution.
  47.          c) The destintation socket must be added to the header of each
  48.             message on the data link. Presumably this would consist of
  49.             32 bits immediately after the header and before the marking.
  50.  
  51.        [ This RFC was put into machine readable form for entry ]
  52.          [ into the online RFC archives by Karl Reinsch 1/97 ]
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.