Extensible field addressing
RFC 730

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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