RFC730 - Extensible field addressing

RFC730                                                        20 May 77Extensible Field AddressingNetwork Working Group                                         Jon PostelRequest for Comments: 730                                        USC-ISINIC: 40400                                                   20 May 1977                      Extensible Field AddressingIntrodUCtionThis memo discusses the need for and advantages of the eXPRession ofaddresses in a network environment as a set of fields.  The suggestionis that as the network grows the address can be extended by threetechniques: adding fields on the left, adding fields on the right, andincreasing the size of individual fields.  Carl Sunshine has describedthis type of addressing in a paper on source routing [1].MotivationChange in the Host-IMP InterfaceThe revised Host-IMP interface provides for a larger address space forhosts and IMPs [2].  The old inteface allowed for a 2 bit host field anda 6 bit IMP field.  The new interface allows a 8 bit host field and a 16bit IMP field.  In using the old interface it was common practice totreat the two fields as a single eight bit quantity.  When it wasnecessary 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 pointedout some of problems associated with attempting to continue such useageas the new interface comes into use [3].  If a per field notation hadbeen 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  196613Multinetwork SystemsThe prospect of interconnections of networks to form a complexmultinetwork system poses additional addressing problems.  The newHost-IMP interface specification has reserved fields in the leader toPostel                                                          [page 1]RFC730                                                        20 May 77Extensible Field Addressingcarry network addresses  [2].  There is experimental work in progress oninterconnecting networks [4, 5, 6]. We should be prepared for theseextensions to the address space.The addressing scheme should be expandable to increase in scope wheninterconnections are made between complex systems.Multiprocessor HostsThere may be configurations of hardware that could be interfaced to anetwork 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-idsto certain processors.  For example it might be desirable to service allTelnet use from one processor and all FTP use from a differentprocessor.The addressing scheme should be expandable to explicitly address thefine structure within a host when that is desirable.Some examples where such fine structure addressing would have beenuseful 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]RFC730                                                        20 May 77Extensible Field AddressingProposalThe necessary solution to the problem posed by the change in theHost-IMP inteface is to always represent the address by fields.  Thissolution provides for a natural growth into an internetwork environment,and allows explicit addressing of the fine structure within a host ifthat is desirable.The fields should be written in a natural way, and i believe that meansthat the most general field should come first with additional fieldsspecifying more and more details of the address.  In the current casethis would lead to the following fields:Network / IMP / Host / Message-IdentifierA problem with simple field addressing is the desire to specify only thefields that are necessary given the local context.  A programinterpreting the address is then unsure what the first field represents.Some clues are needed in the address specification for correct parsingto be possible.  Dave Crocker has described a syntax for a similarproblem in network access of data [8].Specific SugestionSpecifically i suggest that we adopt a field based extensible addressscheme where each field is separated from its neighbors by a delimiter
                         character and each field has a name.  When an address is specified thename 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]RFC730                                                        20 May 77Extensible Field AddressingOne 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 realdifficulties arise, but we have to change the way we think about hostaddresses.  The places where there is a problem are typically littleused, except one.  The place where humans will see a difficulty is inthe TIP "open" command [9], and to a lesser extent the user Telnet anduser FTP "connect" commands.  Other places are in the MAIL netaddressfield, the FTP "sock" command [10], the Telnet reconnection option [11],and in the NIC maintained list of official host names [12].ConclusionThe suggestion is that we adopt field based extensible addressing toprovide for growth in three ways:(1)  growth of the number of hosts and IMPs by allowing these fields togrow in size independently of each other;(2)  growth in scope by the addition of fields on the left to providefor multinetwork systems;(3)  growth in fine structure by addition of fields on the right for theimplementation of hosts as mininetworks.Postel                                                          [page 4]RFC730                                                        20 May 77Extensible Field AddressingReferences[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," RFC542, 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.TXTPostel                                                          [page 5]