summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc730.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc730.txt')
-rw-r--r--doc/rfc/rfc730.txt294
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