Browse Prior Art Database

Extensible field addressing (RFC0730) Disclosure Number: IPCOM000003777D
Original Publication Date: 1977-May-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Related Documents

10.17487/RFC0730: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

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


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].


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...