home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc730.txt < prev    next >
Text File  |  1992-10-14  |  10KB  |  294 lines
  1. RFC 730                                                        20 May 77
  2. Extensible Field Addressing
  3.  
  4.  
  5.  
  6. Network Working Group                                         Jon Postel
  7. Request for Comments: 730                                        USC-ISI
  8. NIC: 40400                                                   20 May 1977
  9.  
  10.                       Extensible Field Addressing
  11.  
  12.  
  13.  
  14. Introduction
  15.  
  16. This memo discusses the need for and advantages of the expression of
  17. addresses in a network environment as a set of fields.  The suggestion
  18. is that as the network grows the address can be extended by three
  19. techniques: adding fields on the left, adding fields on the right, and
  20. increasing the size of individual fields.  Carl Sunshine has described
  21. this type of addressing in a paper on source routing [1].
  22.  
  23. Motivation
  24.  
  25. Change in the Host-IMP Interface
  26.  
  27. The revised Host-IMP interface provides for a larger address space for
  28. hosts and IMPs [2].  The old inteface allowed for a 2 bit host field and
  29. a 6 bit IMP field.  The new interface allows a 8 bit host field and a 16
  30. bit IMP field.  In using the old interface it was common practice to
  31. treat the two fields as a single eight bit quantity.  When it was
  32. necessary to refer to a host by number a decimal number was often used.
  33. For example host 1 on IMP 1 was called host 65. Doug Wells has pointed
  34. out some of problems associated with attempting to continue such useage
  35. as the new interface comes into use [3].  If a per field notation had
  36. been used no problems would arise.
  37.  
  38. Some examples of old and new host numbers are:
  39.  
  40.   Host Name       Host IMP old #   new #
  41.   --------------------------------------
  42.   SRI-ARC            0   2     2       2
  43.   UCLA-CCN           1   1    65   65537
  44.   ISIA               1  22    86   65558
  45.   ARPA-TIP           2  28   156  131100
  46.   BBNA               3   5   197  196613
  47.  
  48. Multinetwork Systems
  49.  
  50. The prospect of interconnections of networks to form a complex
  51. multinetwork system poses additional addressing problems.  The new
  52. Host-IMP interface specification has reserved fields in the leader to
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Postel                                                          [page 1]
  59.  
  60. RFC 730                                                        20 May 77
  61. Extensible Field Addressing
  62.  
  63.  
  64.  
  65. carry network addresses  [2].  There is experimental work in progress on
  66. interconnecting networks [4, 5, 6]. We should be prepared for these
  67. extensions to the address space.
  68.  
  69. The addressing scheme should be expandable to increase in scope when
  70. interconnections are made between complex systems.
  71.  
  72. Multiprocessor Hosts
  73.  
  74. There may be configurations of hardware that could be interfaced to a
  75. network as a single host that in fact contain multiple processors.
  76. Tasks could be associated with processors such that it is desirable to
  77. dispatch network messages associated with certain sockets or message-ids
  78. to certain processors.  For example it might be desirable to service all
  79. Telnet use from one processor and all FTP use from a different
  80. processor.
  81.  
  82. The addressing scheme should be expandable to explicitly address the
  83. fine structure within a host when that is desirable.
  84.  
  85. Some examples where such fine structure addressing would have been
  86. useful in the ARPANET are:
  87.  
  88.   At ISI, we have the capability of emulating computers using the PRIM
  89.   system [7].  For many applications it is desirable to add the emulated
  90.   host to the network.  Since the emulation is carried out under control
  91.   of a program operating under Tenex, we have a host within a host.
  92.   Extensible addressing of hosts would provide the necessary handle.
  93.  
  94.   SCRL once had a PDP-11 connected by VDH to an IMP at UCSB.  It became
  95.   necessary to add a second PDP-11 to the network.  The two PDP-11s were
  96.   already physically connected and it would have been a simple matter to
  97.   have the first serve as a multiplexor for both.  However, because of
  98.   the limitations in the network addressing structure, there was no way
  99.   to identify the two hosts to other sites on the network.  A new IMP
  100.   had to be installed!
  101.  
  102.   In many other cases, it is desirable to have two hosts share the same
  103.   front end to the network.  With the current limitation, one IMP port
  104.   must be consumed for each host.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Postel                                                          [page 2]
  118.  
  119. RFC 730                                                        20 May 77
  120. Extensible Field Addressing
  121.  
  122.  
  123.  
  124. Proposal
  125.  
  126. The necessary solution to the problem posed by the change in the
  127. Host-IMP inteface is to always represent the address by fields.  This
  128. solution provides for a natural growth into an internetwork environment,
  129. and allows explicit addressing of the fine structure within a host if
  130. that is desirable.
  131.  
  132. The fields should be written in a natural way, and i believe that means
  133. that the most general field should come first with additional fields
  134. specifying more and more details of the address.  In the current case
  135. this would lead to the following fields:
  136.  
  137. Network / IMP / Host / Message-Identifier
  138.  
  139. A problem with simple field addressing is the desire to specify only the
  140. fields that are necessary given the local context.  A program
  141. interpreting the address is then unsure what the first field represents.
  142. Some clues are needed in the address specification for correct parsing
  143. to be possible.  Dave Crocker has described a syntax for a similar
  144. problem in network access of data [8].
  145.  
  146. Specific Sugestion
  147.  
  148. Specifically i suggest that we adopt a field based extensible address
  149. scheme where each field is separated from its neighbors by a delimiter
  150. character and each field has a name.  When an address is specified the
  151. name of the most general field must also be indicated.
  152.  
  153.   Definitions:
  154.  
  155.     <address> ::= <field-name> ":" <fields>
  156.  
  157.     <field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"
  158.  
  159.     <fields> ::= <field> | <field> "/" <fields>
  160.  
  161.     <field> ::= a decimal number
  162.  
  163.   Examples:
  164.  
  165.     NET:1/3/5/7  names message-id 7 at host 5 on imp 3 in network 1.
  166.  
  167.     HOST:6  names host 6 on whatever imp this message originates on.
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Postel                                                          [page 3]
  177.  
  178. RFC 730                                                        20 May 77
  179. Extensible Field Addressing
  180.  
  181.  
  182.  
  183. One might ask:  What is all the fuss about, isn't this a non-problem?,
  184. The answer is:  Almost.  There are very few places where any real
  185. difficulties arise, but we have to change the way we think about host
  186. addresses.  The places where there is a problem are typically little
  187. used, except one.  The place where humans will see a difficulty is in
  188. the TIP "open" command [9], and to a lesser extent the user Telnet and
  189. user FTP "connect" commands.  Other places are in the MAIL netaddress
  190. field, the FTP "sock" command [10], the Telnet reconnection option [11],
  191. and in the NIC maintained list of official host names [12].
  192.  
  193. Conclusion
  194.  
  195. The suggestion is that we adopt field based extensible addressing to
  196. provide for growth in three ways:
  197.  
  198. (1)  growth of the number of hosts and IMPs by allowing these fields to
  199. grow in size independently of each other;
  200.  
  201. (2)  growth in scope by the addition of fields on the left to provide
  202. for multinetwork systems;
  203.  
  204. (3)  growth in fine structure by addition of fields on the right for the
  205. implementation of hosts as mininetworks.
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Postel                                                          [page 4]
  236.  
  237. RFC 730                                                        20 May 77
  238. Extensible Field Addressing
  239.  
  240.  
  241.  
  242. References
  243.  
  244. [1]     Sunshine, C. "Source Routing and Computer Networks," Computer
  245.         Communication Review, Vol. 7, Number 1, ACM Special Interest
  246.         Group on Communications (SIGCOMM), January 1977.  Also
  247.         circulated as INWG General Note number 133.
  248.  
  249. [2]     BBN, "The Interconnection of a Host and an IMP," Report 1822,
  250.         Bolt Beranek and Newman, Revised January 1976.
  251.  
  252. [3]     Wells, D., "Impact of New IMP Leaders on Higher-level
  253.         Protocols," ARPA Network Message
  254.         [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.
  255.  
  256. [4]     Beeler, et.al. "Gateway Design for a Computer Network
  257.         Interconnection," PRTN 156, February 1976.
  258.  
  259. [5]     Cerf, V., Y. Dalal, and C. Sunshine. "Specification of an
  260.         Internet Transmission Control Program," INWG General 72, RFC
  261.         675, Revised December 1974.
  262.  
  263. [6]     Cerf, V. "Specification of TCP version 2," March 1977.
  264.  
  265. [7]     Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58,
  266.         Information Sciences Institute, University of Southern
  267.         California, March 1977.
  268.  
  269. [8]     Crocker, D., "Network Standard Data Specification Syntax," RFC
  270.         645, Network Information Center Catalog Number 30899, 27 June
  271.         1974.
  272.  
  273. [9]     Malman, J., "User's Guide to the Terminal IMP," Report 2138,
  274.         Bolt Beranek and Newman, Network Information Center Catalog
  275.         Number 10916, Revised March 1976.
  276.  
  277. [10]    Neigus, N., "File Transfer Protocol," RFC 542, Network
  278.         Information Center Catalog Number 17759, 12 August 1973.
  279.         Contained in "ARPANET Protocol Handbook," Network Information
  280.         Center Catalog Number 7104, Revised 1 April 1976.
  281.  
  282. [11]    Thomas, R., "Telnet Reconnection Option," Network Information
  283.         Center Catalog Number 15391, August 1973. Contained in "ARPANET
  284.         Protocol Handbook," Network Information Center Catalog Number
  285.         7104, Revised 1 April 1976.
  286.  
  287. [12]    [Offfice-1]<NETINFO>HOSTS.TXT
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Postel                                                          [page 5]