IEN 171
Danny Cohen
USC / ISI
18 January 1981
Addressing in the ARPAnet, another visit
----------------------------------------
As you all remember the addressing in the HOST/IMP interface for the
ARPAnet has the following format (as defined in 1822):
8 8 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|///IP-net-ID///| H O S T | I M P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 16 41 48 49 64
Please allow me to take the liberty of showing it in a more "logical"
and consistent order:
8 16 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|///IP-net-ID///| I M P | H O S T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the rest of this discussion we will use only this "logical" order.
It is well known that for the time being the Net-ID field is not used
and that IMP numbers may be contained in a single 8-bit field.
Therefore, ARPAnet addresses are of the form:
8 8 8 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|///IP-net-ID///| I M P | 0 | H O S T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2
I believe that a single 8-bit field for the IMP address may be found in
a (relatively) near future to be too restrictive. Let's assign a 12-bit
field for this purpose (even though I believe that 10 are enough).
Using 12 bits for IMP-addressing the following format is suggested:
8 12 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|///IP-net-ID///| I M P | H O S T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hence, I propose an arrangement which will allows a connection of up to
4,096 hosts to a single IMP (out of 4,096), or more hosts out of less
IMPs if the IMP-address field is chosen to be smaller than 12 bits.
One of the best ways to connect many hosts to an IMP at any site is by
contracting BBN to provide that many IMP/HOST interfaces. Another way
is by sharing a few IMP ports by several hosts, by using multiplexers,
port-expanders or other multi-access schemes. One candidate technology
for such multiplexing is the one commonly referred to as "local
networks".
I advocate that the details of this arrangement are of interest only of
that site, and are no one else's business. In other words, these
details do not have to be made available outside of that site.
The word HOST in all of the above diagrams is most misleading. The IMP
has absolutely no notion of host. All it knows is which port is used.
This field is used to identify the IMP port, not the HOST.
It is proposed here that if there are several hosts sharing the same
port, then a HOST-ID field should follow the PORT-ID field.
How big should these two fields (the PORT-ID and the HOST-ID) be? The
answer depends on the local configuration at each site. One site may
chose to connect its 64 hosts by using 64 ports bought from BBN, another
by using a smaller number of ports each supporting several hosts through
some port expanders, and another site may connect all of its 64 host
through a single port.
Obviously, hosts which share the same ports have to understand the
advantages and disadvantages which are associated with this sharing,
such as the flow-control which is based on port-pair, port blocking,
etc. It is not unreasonable to expect the personnel at each site to be
intelligent enough to understand these issues and to make the
appropriate decision about it, as best suits the particular situation.
The notion which is advocated here is that the distinction between
PORT-ID and HOST-ID does not have to be known and understood to the
outside, just as on the ARPAnet the distinction between the IMP-ID and
the HOST-ID does not have to be understood even at the HOST/HOST
protocol level.
3
Again, where does the proposed PORT-ID field end and the HOST-ID start?
One possible approach is to legislate the same answer for all IMPs,
regardless of the particular situation of each one. This has some
trivial simplification benefits.
Another is to follow the IP philosophy of NOT legislating the format of
each intranet addressing, and leaving it as the "REST" which has to be
understood only at the local environment for which it is designed.
Following this philosophy it is proposed that the PORT-ID field be
defined to be of a variable length, defined specifically for each IMP
according to the local requirements which it has to support. Let N(i)
be the length PORT-ID field at IMP(i), i.e., the IMP whose ID is i.
Hence, once a message arrives at IMP(i) for any of its hosts, this IMP
should look at the top N(i) bits of the PORT-ID/HOST-ID field and
extract the PORT-ID for the port to be used for forwarding this message.
Neither the extra processing nor the storage requirements for supporting
this scheme seem to be excessive.
Obviously there must be some processor on the other end of every port
which is capable of handling the required handshake with the IMP.
The flow control which is now based on port/port pairs must be somehow
modified since the notion of remote port does not exist under this
proposal. Without getting into details here we suggest that this
problem can be solved, and the difficulties associated with this
modification are outweighed by the benefits of this scheme.
The main advantage of such a scheme, in comparison with having some kind
of a gateway (or equivalent, such as SRI's port-expander) is that the
forwarding may take place in a very efficient way without the need to
"open each envelop", understand the protocol used, finding the full
IP-address (whose position may vary even for different versions of IP)
and decipher from it where to forward the message. The author of this
short note dares suggest that efficiency is not a sign of moral
turpitude and that we should be as efficiency oriented as possible.
Hence, our proposed format for the ARPAnet addressing is:
8 12 N(i) / 12-N(i)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|///IP-net-ID///| I M P | P O R T / H O S T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format is "logical" and suggestive only. It is well understood that
these bits may be packed in a different order and over several
non-consecutive fields (e.g., 9-16 and 41-64).
4
A problem with the current 1822 format
--------------------------------------
The basic notion of 1822 is that it is a IMP/HOST protocol.
Unfortunately, 1822 is the IMP/PORT (or IMP/INTERFACE) protocol. If
every PORT always supports only one host then 1822 is really an IMP/HOST
protocol. However, with today's technology where hosts range in size
(and cost) over several orders of magnitude it is not unreasonable to
expect that several hosts share a single IMP-PORT.
This may be accomplished in a variety of ways which we better not
discuss here since this is too rich topic for this discussion.
Most modern protocols carry both the TO: and the FROM: addresses across
the "subscriber" interface. It would be nice, and most helpful, if 1822
would carry both the destination and the source addresses, just like IP,
TCP, PUP and Ethernet - to name a few.
Background (or why we, at ISI, like this scheme)
------------------------------------------------
I apologize for introducing the motivation at the end of the note,
rather than at its beginning.
At ISI any scheme which would allow a fast and efficient packet
multiplexing between many hosts and networks is a cornerstone of the
architecture of our new environment.
We, at ISI, would like to be able to multiplex packets with minimal
processing and without the need to "open each envelop" and read the
"inside letter" and to understand the higher level protocols in order to
figure where to forward the messages. At the level where these
multiplexing techniques reside even IP is a higher level protocol, and
so are ST and PUP.
We plan that the entire ISI environment would share a single 8-bit
address space, spanned by several local networks, Funnels and probably
some other packet-multiplexing schemes.
This environment, which we like to refer to as a "site", would have
connections to several IP-Networks (capital N!). The preferred mode of
operation is to use some direct packet multiplexing schemes to deliver
the packets directly to their destinations, each of which is capable to
perform all the IP-processing. The exception would be to route packet
through an explicit Gateway, and even this may be used only for part of
the traffic, like for outgoing packets which require routing decisions
but not for incoming ones.
5
According to our philosophy the choice for our site between using
centralized site gateway and a "distributed-gateway" is our business,
and no one else's. A distributed gateway is a scheme where each host
performs all the necessary IP-level functions. Note that even the
existence of a centralized gateway does not alleviate the need for the
distributed one, because every terminal-host must be able to understand
IP, unless it has a surrogate which performs this task for it.
We happen to believe that other sites with a large number of hosts would
like to implement similar schemes which support high efficiency of
packet forwarding mechanisms.
A concluding comment
--------------------
The notion which is advocated in this note is by no mean new. We have
learned long ago that any level of protocol should always contain
multiplexing information for the next level. In the few instances where
this is not done - a price is paid for this error.
For example, the good old LINKs (or Message-ID's) used to play such a
role, and so do NCP-SOCKETs and TCP-PORTs.
-------