USC / ISI                                                    Danny Cohen
3 January 1981                                                Jon Postel
W-note-23                                                   Steve Casner
IEN-165


                     About addressing in the WBnet
                     -----------------------------

This  note is  written  in response to W-note-16  (aka IEN-162,  by John
Pershing) about a proposed addressing scheme for the WBnet.

We  found  the  above  note to be very well written, and it points out a
very difficult problem in internetwork addressing; however,  we  beg  to
differ  with  some  of  the  underlying  assumptions, and therefore have
arrived at another proposal.

In this note we will first review the W-16 proposal, then  present  ours
and compare the two approaches.


                           The W-16 approach
                           -----------------

Assumptions and objectives:

   - Whichever  addressing  scheme is used had better be compatible
     with IP.

   - There is a rich structure interconnecting  hosts  at  all  the
     sites  which  are  connected  to  the WBnet.  This richness is
     beyond what the processing nodes of the WBnet can be  expected
     to  process  directly  -  hence  a  hierarchical  structure is
     proposed.

   - The richness of all the host  interconnections  at  all  sites
     combined  is  similar to that of the catenet - hence a similar
     solution should work.

   - "To hide the physical structure of the Wideband Net  from  the
     Internet and its gateways" - quoted from W-16.

   - "To unify the transport and routing functions performed within
     the Wideband Net" - quoted from W-16.

                                   2

This yields the following addressing scheme:

Consider  ALL the hosts on the ALL the local-nets which are connected to
ALL the WBnet gateways as being  WBnet  hosts,  and  assign  them  WBnet
addresses which reflect their connectivity to the WBnet as shown below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      28.      | Subnet Number |    Reserved for Subnet Use    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        8-bits          8-bits                 16-bits


For  example, if there are 4 Lexnets and one Voice Funnel, at some site,
then each of these 5 "things" is assigned its own subnet-ID.

We hope that the above is an accurate reflection of the proposal as  put
forth in W-16.


                            The ISI approach
                            ----------------

We,   too,   believe  that  there  may  be  a  rich  structure  of  host
interconnections at each site.  However, for the time  being  we  expect
the  number  of  hosts at each site to be small enough that 8 bits would
suffice for intra-site addressing.

We also believe that all of our hosts are constituents of  the  catenet,
not  of  any  particular  network, including the WBnet.  By this we mean
that any host should be addressable via any of the catenet  networks  to
which it has a connection.

We  would  like  to  reserve  8  bits  of the WBnet/IP address for local
addressing so that each host can be assigned  a  single  local  address.
This local address would remain constant independent of which gateway or
directly-connected host (if any) was being used as an intermediary.

Therefore,  we  propose  that only 16-bit WBnet addresses be assigned to
hosts which are connected to PSATs, directly or through some transparent
"port-expanding" mechanism such as  a  Voice  Funnel.  These  hosts  are
either bona fide hosts or full fledged IP (and/or ST) gateways.

At  ISI,  for  example,  we  will  have  probably one or two such hosts,
through which all the other hosts gain access to the WBnet.

We prefer to see IP (and/or ST) gateways, not  WBnet  gateways,  playing
the  various intra-site communication roles (like routing) regardless of
which transport mechanism was used to get to the site, either  Satellite
or terrestrial lines.

                                   3

Therefore we prefer the following addressing scheme:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Any Network  |    Addressing in that net     | Local address |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        8-bits                 16-bits                   8-bits

This  allows  traffic  for  any  host  at  a  site to arrive through any
existing gateway.

The details associated with the routing of  intra-site  traffic  do  not
have to be propagated outside that site.


                    Comparison of the two approaches
                    --------------------------------

We  acknowledge  that our approach has the severe limitation that it can
currently support only up to (about) 256 hosts per site.   Please  note,
this  is a restriction on the number of hosts but not necessarily on the
number  of  voice  terminals,  since  NVP  provides  another  level   of
addressing called "extensions".

We propose that when this limit is reached an extended addressing scheme
(along the lines of source routing) be used.

The  W-16 proposal requires that WBnet-gateways be installed between all
the local networks in every site.    It  requires  that  any  change  in
connectivity  of  the  local  networks  be  propagated  to all the WBnet
gateways, in all the other sites, and be stored in all of them. This, in
our opinion, does not really comply with spirit of hiding local  details
from the global world, as stated as one of the objectives of the scheme.

We  believe  that  our  proposal  meets  the  objectives  stated  at the
beginning of  this  note,  at  least  as  much  as  the  W-16  proposal.
Especially  it  meets  the  requirement  that  the details of intra-site
communication are no one else's business.  We think that as far  as  the
outside  world  is  concerned there is no difference between using hosts
for port-expanding and using local networks,  or  any  hybrid  of  these
approaches.

The  W-16  scheme  must  know  all  about  the  intra-site communication
structure.    This   scheme   also   requires   the   development   (and
implementation)  of a Gateway/Gateway protocol, just as was done for the
catenet.

It is not clear to us at all why all of our hosts  should  pledge  their
allegiance to W-16 addressing scheme and to the WBC for which it stands,
one network, indivisible (enough!!).

We  would  like  to treat the WBnet just as another transport mechanism,
which should be used only when it is found to be  the  best  alternative
for  some  communication requirements.  For our communication system the
WBnet should be just another means of inter-site  communication,  not  a
religion  to  which  all  of  our  internal gateways and bridges have to
subscribe.

                                   4


                               Conclusion
                               ----------

We  recommend  that  only  16-bit  addresses be used within the WBnet in
order to specify its hosts; and that these hosts  be  either  bona  fide
hosts   or   gateways   into   other   networks,   including  intra-site
communication systems.

As long as intra-site addressing can be handled by an 8-bit field  there
is  an efficient and convenient way to incorporate this field within the
IP-address field in addition to the 16-bit WBnet addresses.



                           Referee's comment
                           -----------------

Under the assumption that 8-bit addressing is enough for all  intra-site
addressing,  and under the assumption that all the local networks at any
site share this address space and already are capable  of  communicating
among  themselves  (and  do  not  need  help  from the WBnet in order to
achieve it) - the two approaches, W-16 and ISI's, are IDENTICAL.

The folks at BBN may treat each site as a single subnet and assign it  a
single subnet-ID.  On the other hand, the folks at ISI may assign unique
local addresses to each of their hosts.

Hence,  the  32-bit IP-address of the host on the WBnet will be composed
of the following 4 bytes (in Big-Endian's order, obviously):

  Byte#0 = 28., the net-ID of the WBnet,      assigned by Postel.
  Byte#1 = WBnet address: Site- or Subnet-ID, assigned by BBN.
  Byte#2 = Reserved for future extensions
  Byte#3 = Local address,                     assigned by each site.

We would also like to recommend  that  BBN  assign  the  subnet-ID's  in
bit-reversed  order  in order to maintain maximal flexibility for future
expansions which may occur at either end of the addressing scheme.