From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc730.txt | 294 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 294 insertions(+) create mode 100644 doc/rfc/rfc730.txt (limited to 'doc/rfc/rfc730.txt') 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: + +
::= ":" + + ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID" + + ::= | "/" + + ::= 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]HOSTS.TXT + + + + + + +Postel [page 5] \ No newline at end of file -- cgit v1.2.3