doc: Add RFC documents

1 files changed, 294 insertions, 0 deletions

diff --git a/doc/rfc/rfc730.txt b/doc/rfc/rfc730.txt
new file mode 100644
index 0000000..6272c1b
--- /dev/null
+++ b/doc/rfc/rfc730.txt
@@ -0,0 +1,294 @@
+RFC 730                                                        20 May 77
+Extensible Field Addressing
+
+
+
+Network Working Group                                         Jon Postel
+Request for Comments: 730                                        USC-ISI
+NIC: 40400                                                   20 May 1977
+
+                      Extensible Field Addressing
+
+
+
+Introduction
+
+This memo discusses the need for and advantages of the expression of
+addresses in a network environment as a set of fields.  The suggestion
+is that as the network grows the address can be extended by three
+techniques: adding fields on the left, adding fields on the right, and
+increasing the size of individual fields.  Carl Sunshine has described
+this type of addressing in a paper on source routing [1].
+
+Motivation
+
+Change in the Host-IMP Interface
+
+The revised Host-IMP interface provides for a larger address space for
+hosts and IMPs [2].  The old inteface allowed for a 2 bit host field and
+a 6 bit IMP field.  The new interface allows a 8 bit host field and a 16
+bit IMP field.  In using the old interface it was common practice to
+treat the two fields as a single eight bit quantity.  When it was
+necessary to refer to a host by number a decimal number was often used.
+For example host 1 on IMP 1 was called host 65. Doug Wells has pointed
+out some of problems associated with attempting to continue such useage
+as the new interface comes into use [3].  If a per field notation had
+been used no problems would arise.
+
+Some examples of old and new host numbers are:
+
+  Host Name       Host IMP old #   new #
+  --------------------------------------
+  SRI-ARC            0   2     2       2
+  UCLA-CCN           1   1    65   65537
+  ISIA               1  22    86   65558
+  ARPA-TIP           2  28   156  131100
+  BBNA               3   5   197  196613
+
+Multinetwork Systems
+
+The prospect of interconnections of networks to form a complex
+multinetwork system poses additional addressing problems.  The new
+Host-IMP interface specification has reserved fields in the leader to
+
+
+
+
+
+Postel                                                          [page 1]
+
+RFC 730                                                        20 May 77
+Extensible Field Addressing
+
+
+
+carry network addresses  [2].  There is experimental work in progress on
+interconnecting networks [4, 5, 6]. We should be prepared for these
+extensions to the address space.
+
+The addressing scheme should be expandable to increase in scope when
+interconnections are made between complex systems.
+
+Multiprocessor Hosts
+
+There may be configurations of hardware that could be interfaced to a
+network as a single host that in fact contain multiple processors.
+Tasks could be associated with processors such that it is desirable to
+dispatch network messages associated with certain sockets or message-ids
+to certain processors.  For example it might be desirable to service all
+Telnet use from one processor and all FTP use from a different
+processor.
+
+The addressing scheme should be expandable to explicitly address the
+fine structure within a host when that is desirable.
+
+Some examples where such fine structure addressing would have been
+useful in the ARPANET are:
+
+  At ISI, we have the capability of emulating computers using the PRIM
+  system [7].  For many applications it is desirable to add the emulated
+  host to the network.  Since the emulation is carried out under control
+  of a program operating under Tenex, we have a host within a host.
+  Extensible addressing of hosts would provide the necessary handle.
+
+  SCRL once had a PDP-11 connected by VDH to an IMP at UCSB.  It became
+  necessary to add a second PDP-11 to the network.  The two PDP-11s were
+  already physically connected and it would have been a simple matter to
+  have the first serve as a multiplexor for both.  However, because of
+  the limitations in the network addressing structure, there was no way
+  to identify the two hosts to other sites on the network.  A new IMP
+  had to be installed!
+
+  In many other cases, it is desirable to have two hosts share the same
+  front end to the network.  With the current limitation, one IMP port
+  must be consumed for each host.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [page 2]
+
+RFC 730                                                        20 May 77
+Extensible Field Addressing
+
+
+
+Proposal
+
+The necessary solution to the problem posed by the change in the
+Host-IMP inteface is to always represent the address by fields.  This
+solution provides for a natural growth into an internetwork environment,
+and allows explicit addressing of the fine structure within a host if
+that is desirable.
+
+The fields should be written in a natural way, and i believe that means
+that the most general field should come first with additional fields
+specifying more and more details of the address.  In the current case
+this would lead to the following fields:
+
+Network / IMP / Host / Message-Identifier
+
+A problem with simple field addressing is the desire to specify only the
+fields that are necessary given the local context.  A program
+interpreting the address is then unsure what the first field represents.
+Some clues are needed in the address specification for correct parsing
+to be possible.  Dave Crocker has described a syntax for a similar
+problem in network access of data [8].
+
+Specific Sugestion
+
+Specifically i suggest that we adopt a field based extensible address
+scheme where each field is separated from its neighbors by a delimiter
+character and each field has a name.  When an address is specified the
+name of the most general field must also be indicated.
+
+  Definitions:
+
+    <address> ::= <field-name> ":" <fields>
+
+    <field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"
+
+    <fields> ::= <field> | <field> "/" <fields>
+
+    <field> ::= a decimal number
+
+  Examples:
+
+    NET:1/3/5/7  names message-id 7 at host 5 on imp 3 in network 1.
+
+    HOST:6  names host 6 on whatever imp this message originates on.
+
+
+
+
+
+
+
+
+Postel                                                          [page 3]
+
+RFC 730                                                        20 May 77
+Extensible Field Addressing
+
+
+
+One might ask:  What is all the fuss about, isn't this a non-problem?,
+The answer is:  Almost.  There are very few places where any real
+difficulties arise, but we have to change the way we think about host
+addresses.  The places where there is a problem are typically little
+used, except one.  The place where humans will see a difficulty is in
+the TIP "open" command [9], and to a lesser extent the user Telnet and
+user FTP "connect" commands.  Other places are in the MAIL netaddress
+field, the FTP "sock" command [10], the Telnet reconnection option [11],
+and in the NIC maintained list of official host names [12].
+
+Conclusion
+
+The suggestion is that we adopt field based extensible addressing to
+provide for growth in three ways:
+
+(1)  growth of the number of hosts and IMPs by allowing these fields to
+grow in size independently of each other;
+
+(2)  growth in scope by the addition of fields on the left to provide
+for multinetwork systems;
+
+(3)  growth in fine structure by addition of fields on the right for the
+implementation of hosts as mininetworks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [page 4]
+
+RFC 730                                                        20 May 77
+Extensible Field Addressing
+
+
+
+References
+
+[1]     Sunshine, C. "Source Routing and Computer Networks," Computer
+        Communication Review, Vol. 7, Number 1, ACM Special Interest
+        Group on Communications (SIGCOMM), January 1977.  Also
+        circulated as INWG General Note number 133.
+
+[2]     BBN, "The Interconnection of a Host and an IMP," Report 1822,
+        Bolt Beranek and Newman, Revised January 1976.
+
+[3]     Wells, D., "Impact of New IMP Leaders on Higher-level
+        Protocols," ARPA Network Message
+        [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.
+
+[4]     Beeler, et.al. "Gateway Design for a Computer Network
+        Interconnection," PRTN 156, February 1976.
+
+[5]     Cerf, V., Y. Dalal, and C. Sunshine. "Specification of an
+        Internet Transmission Control Program," INWG General 72, RFC
+        675, Revised December 1974.
+
+[6]     Cerf, V. "Specification of TCP version 2," March 1977.
+
+[7]     Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58,
+        Information Sciences Institute, University of Southern
+        California, March 1977.
+
+[8]     Crocker, D., "Network Standard Data Specification Syntax," RFC
+        645, Network Information Center Catalog Number 30899, 27 June
+        1974.
+
+[9]     Malman, J., "User's Guide to the Terminal IMP," Report 2138,
+        Bolt Beranek and Newman, Network Information Center Catalog
+        Number 10916, Revised March 1976.
+
+[10]    Neigus, N., "File Transfer Protocol," RFC 542, Network
+        Information Center Catalog Number 17759, 12 August 1973.
+        Contained in "ARPANET Protocol Handbook," Network Information
+        Center Catalog Number 7104, Revised 1 April 1976.
+
+[11]    Thomas, R., "Telnet Reconnection Option," Network Information
+        Center Catalog Number 15391, August 1973. Contained in "ARPANET
+        Protocol Handbook," Network Information Center Catalog Number
+        7104, Revised 1 April 1976.
+
+[12]    [Offfice-1]<NETINFO>HOSTS.TXT
+
+
+
+
+
+
+Postel                                                          [page 5]
\ No newline at end of file