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    |


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

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.


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


                 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.


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.