IEN 126                                                      Danny Cohen
                                                           U S C / I S I
                                                           November 1979



             SUMMARY OF THE ARPA/ETHERNET COMMUNITY MEETING


On  Thursday,  October  18th,  1979, a meeting was held at Xerox-PARC to
discuss  the  support  of  ETHERNET  based  communication  in  the  ARPA
sponsored internetwork environment (INE).

The following participated in the meeting:

   - CMU (Bob Sproull)

   - ISI (Danny Cohen)

   - MIT-LCS (Dave Clark)

   - Stanford University (Forest Baskett, John Seamas, Bill Nowicki)

   - University of Rochester (Ed Burke)

   - Xerox-PARC (Ed Taft, Mike Schroeder, Ron Crane, John Shoch)

It turned out that Caltech, which is another ARPA site, already has four
ALTOs and an Ethernet.  They were not represented in this  meeting,  and
probably should be made part of this ARPA/Ethernet community.

The  group  reached  an  agreement about the way to support both IP- and
PUP-based communication in such a way that the richness of  both  worlds
is  preserved.    This  can  be  encapsulated in the following:  when in
conflict, use IP as a transport (hence, lower level) protocol for PUP.

A detailed discussion of this issue follows, in (A) below.

                                                                  Page 2

One cannot over-emphasize that this effort is NOT aimed  to  provide  an
automatic  translation/conversion between the IP-based and the PUP-based
software,  but  to  support  coexistence  and  mutual  support  of  both
communication  regimes.    Providing  that conversion service is a noble
goal, but unfortunately is too complicated to be considered as a part of
this effort  because  it  involves  complicated  technical  issues  like
addresses in a non-uniform set of internetwork environments.

However,  even though no automatic direct conversion is provided between
these regimes, a certain degree of compatibility  and  inter-operability
exists  due  to hosts which "talk" both "languages".  This capability is
provided by the ability to transfer files back and forth between the IP-
and the PUP-worlds, to forward mail, to cascade TELNET connections,  and
the like.

In  addition,  the  existence  of PUP-based Xerox products (like Dovers,
ALTOs and Penguins) in the ARPA community requires, to a certain degree,
the ability to support PUP communication among sites which are already a
part of the IP-internet, without requiring them also to  participate  in
the PUP-internet.

Basically   the   entire  group  agreed  to  work  toward  communication
compatibility and effort sharing.

Since there is a great deal of commonality of both hardware and software
requirements among the sites,  we  expect  to  be  able  to  share  both
hardware  and  software  efforts  by  exchanging  and  copying interface
designs, exchange of software, and the like.

According to the proposed agreement, the IP-world and the PUP-world  can
coexist in such a way that ARPA maintains complete control of the former
and  Xerox-PARC  of  the  latter.    This  control  is the assignment of
network-IDs, updating of routing-tables, name-servers, etc.

Ethernets  may participate in the PUP-world, or serve  just  as  private
local  access  systems,  which  are  not  part  of  any  internetworking
environment.  In either case, the Ethernets may be  totally  transparent
to  the  outside,  while  supporting  traffic  between  IP-hosts, and no
symmetry is required between  the  communicating  sites,  i.e.,  a  site
without  an  Ethernet does not have to be aware that the other site uses
an Ethernet for its local access.

The following sections are:

  (A) A discussion of the proposed relation between the protocols,

  (B) The  hardware/software  components  which  will  probably  be
      developed  at  individual  sites  and made available to other
      participants.  This is a tentative list  and  should  not  be
      viewed as a firm commitment, and

  (C) The list of the participants, addresses, etc.

                                                                  Page 3

(A) IP/PUP Communication



THE PROBLEM

Support communication between Ethernet-based systems at different sites,
by  using  either  the  IP-  or  the  PUP-based protocols, over the ARPA
sponsored InterNetwork Environment (INE).

This is NOT intended to provide inter-operability  of  these  protocols,
only their co-existence.



APPROACH

Both  the  IP and PUP assume that they are the sole level-1 internetwork
protocols.

Since the ARPA-sponsored INE already has many gateways which  are  based
on  IP,  we  chose  to encapsulate PUP inside IP for traversing the INE.
Note that this doesn't exclude the dual, namely IP inside PUP.

This encapsulation may be performed either by hosts or by gateways.

The interaction between IP and PUP is based on the ability  of  each  to
act as the transport for the other.

This  is  a slight deviation from our previous simplistic notion of pure
hierarchy of protocols which allows the drawing of nice tree  structures
with unique level-number to each protocol.  Since both IP and PUP can be
either "above" or "below" the other -- strange loops [GEB] may result.

It  is  important not to exclude the ability of each IP-host to have its
own  unique  IP-address,  while  each  PUP-host  has  its   own   unique
PUP-address, if so desired, without excluding the ability to have both.

                                                                  Page 4

DISCUSSION

Sites  which  use  mainly  IP probably are better off by performing this
encapsulation by the hosts, and have a E-IP-A ("pure-IP") gateway.  Here
"E" is the Ethernet protocol and  "A"  is  the  external  transport  net
protocol (e.g.  ARPAnet) which is used to connect this site to the INE.

Let's use the notation X<Y to mean that X is a lower level protocol than
the  protocol  Y  and is used as a transport for Y, by encapsulating the
Y-messages inside the X-messages.  If the "<" and ">" are considered  as
arrows,  note that they always point "down", to the lower level protocol
and do not indicate direction of flow.

By using this notation the above gateway may  be  described  as  E<IP>A.
Again,  the "arrows" do not indicate direction of flow, but indicate the
encapsulation/decapsulation  of  messages  as  they  flow  through  this
gateway in either direction.

According  to  the  philosophy  of  IP  both  the  "E"  and  the "A" are
considered as "local" even though "E" is a local access system  and  "A"
is  a  cross-country  communication  system.    As a matter of fact, all
networks are considered as "local-networks" by this school of thought.

In such sites the role of the Ethernet here is to be a  local  transport
(level-0) for the IP traffic.

However,  internal  (intra-site)  PUP traffic may avoid the IP entirely,
which is essential if Xerox black-boxes (e.g., Dovers and Penguins)  are
used.    Note  that  PUP  traffic  cannot  leave  this site unless it is
encapsulated in IP by the sending hosts.

We refer to such sites as type S1.

Sites with only PUP based traffic may  choose  to  implement  E<PUP>IP>A
("pure-PUP") gateways.  This frees the local hosts from dealing with IP.

We expect that only Xerox sites may use such gateways.  We refer to such
sites as type S2.

Note  that  PUP traffic cannot be communicated between S1 and S2 easily.
It may be kluged but should be considered as not feasible due mainly  to
addressing problems.

Sites  which  have  to  communicate  with  both  S1 and S2 sites have to
implement a combined IP+PUP gateways.  These are  the  S12  type  sites.
The gateways used by these sites are discussed in some detail later.

                                                                  Page 5

MORE DISCUSSION

An important notion is that even though PUP is always encapsulated in IP
while traversing the INE it may be performed by either the hosts (the S1
way), or by the gateways (the S2 way).

In the  S1 way the  IP-communication is addressed to the destination IP-
host (process).  However, the PUP-communication inside it,  if  any,  is
addressed to a PUP-process, using PUP-addresses.

In the  S2 way the PUP-communication is addressed  to the PUP-process in
the source-gateway which is expected to perform its own routing  to  the
PUP-process  in  the  gateway  which  is  the  re-entry  point  into the
PUP-world (or the  exit  point  from  the  IP-world).    The  end-to-end
communication is addressed by its PUP-address.

The S1 model treats the  Ethernet as a local access scheme,  while IP is
the internetworking regime.

The S2 model treats the IP-INE as a single transporting  network,  while
PUP is the internetworking regime.

Hence, it is not expected to support communication between S1 and S2.

If  we  use  [E(IP)]  to  represent an IP-message encapsulated inside an
Ethernet-message then the function of the S1-gateway is to  perform  the
following  transformation:  [E(IP)]  <=> [A(IP)], where the direction of
the transformation depends on  the  direction  of  the  flow,  from  the
Ethernet into the the ARPAnet, or vice versa.

Hence, the function of the S2-gateway is [E(PUP)] <=> [A(IP(PUP))].

The S12 gateway is one which can operate in either of these modes.  As a
matter  of  fact,  there is one other mode of operation which is in some
use, treating the ARPAnet as a communication line (level-0) for PUP.

This is done by encapsulating PUP  directly  in  ARPAnet  messages,  and
using  link-152  to  designate  this  traffic.  Note: no IP is involved.
This gateway function is represented by [E(PUP)] <=> [A(PUP)].    By the
way, the [A(IP)] traffic in the ARPAnet is designated by link-155.

Hence, a general gateway, which uses an Ethernet for local  access,  has
to support the following:

  1. [E(IP)] <=> [A(IP)]
     Encapsulation   of   IP-messages  in  ARPANEt-messages.    The
     IP-address is that of the destination IP-process.

  2. [E(PUP)] <=> [A(IP(PUP))]
     Encapsulation of PUP-messages inside IP-messages, encapsulated
     in  ARPANet-messages.    The  PUP-address  is  that   of   the
     destination host, the IP-address is that of the PUP-process in
     the   destination   gateway   which  retrieves  (performs  the
     decapsulation) of PUP from inside IP.

  3. [E(PUP)] <=> [A(PUP)].
     Direct encapsulation of PUP-messages inside ARPAnet-messages.

                                                                  Page 6

Using the previous notations, where "arrows" indicate the  direction  of
encapsulation/decapsulation  for  the  two-way  flow, the general IP+PUP
gateway can be described by the following diagram:

            **********                 ******     **********
            *        <--1-----------1--<    *     *        *
            * Ether- *     *******     * IP >-1,2-> ARPA-  *
   --1,2,3--<  net   *     *     >--2-->    *     *  net   >--1,2,3--
            *        <-2,3-< PUP *     ******     *        *
            *        *     *     >--3----------3-->        *
            **********     *******                **********

John Shoch observed that diagrams like this one  (with  or  without  the
arrows)  may  be viewed as if the lines represent messages and the boxes
represent processes, or as if the boxes represent messages and the lines
represent processes (encapsulation/decapsulation).




MORE DETAILS and EXAMPLES

Let us consider communication between host-A at  site-X  and  host-B  at
site-Y, where at site-X there is an Ethernet whose PUP-address is S, and
at  site-Y there is an Ethernet whose PUP-address is T. Here "host" is a
single process and a "site" is a set  of  hosts  connected  by  a  local
access scheme.

Even  though the ARPAnet is mentioned in all the following examples, one
should be able to notice that in most cases  it represents  any  network
which  supports  IP,  i.e., for which IP-gateways are implemented.  Only
the LINKs mentioned below are actually ARPAnet specific.

Let's examine the protocol-nestings and encapsulations for FTPs.

(1) Encapsulation/decapsulation into IP, by hosts.

Two case are discussed in some details, (1.1) transport of  TCP-traffic,
and (1.2) transport of PUP-traffic.

Obviously,  the  FTPs of (1.1) and (1.2) differ and cannot talk directly
to each other, but they can communicate indirectly via  a  file  system,
such as MAXC's.

                                                                  Page 7

(1.1) FTP above TCP, above IP.

This is the case of IP communication, using the Ethernet and the ARPAnet
as part of the IP-INE.

The  sender, host-A, generates an IP-message of the form [IP(TCP(FTP))],
carrying the IP-address Y:B,  which  is  encapsulated  in  the  Ethernet
protocol  for  accessing  the  gateway.  Hence, upon leaving host-A, the
message  is  [E(IP(TCP(FTP)))],  with  the   Ethernet-address   of   the
IP-process in the gateway, by setting the Ethernet 8-bit address to that
of  the  Ethernet interface of gateway-X, and setting the PROTOCOL field
to the value 1001-octal, meaning IP-protocol.

Upon receiving this message the Ethernet-process examines the  value  of
the PROTOCOL field and recognizes the message as an IP-message.  It then
hands  to  the IP-process the message without the Ethernet header.  This
is the decapsulation of the message from the Ethernet encapsulation.

The IP-process finds that the IP-address  of  the  destination  is  Y:B.
After  checking  its  routing-tables  the  IP-process  finds the ARPAnet
address of the first gateway along the INE-route  to  Y. It  may  happen
that  this is also the final one, if Y is also connected directly to the
ARPAnet.

Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
ARPAnet-address of that gateway: [A(IP(TCP(FTP)))].

Upon arriving at the gateway of site-Y the local-net header is  stripped
off.    This local network is probably the ARPAnet, if Y is connected to
it directly, but may be any  other  network  which  supports  IP.    The
resulting IP-message is handed to the IP-process.

Next,  the  IP-message  is  encapsulated  again  in an Ethernet-message,
addressed to host-B, [E(IP(TCP(FTP)))].

Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
IP-message  is  recovered and handed to the IP process which hands it to
the TCP process, which hands it to the FTP process.

Note that for this scheme to work it is not necessary for site-Y to have
the same type of local-access network (here the Ethernet) as site-X has,
or any other local network.

Note also that in this case the Ethernet neither at site-X nor at site-Y
has to have a PUP-address, and it does not have to be  considered  as  a
part of the PUP-based internetwork environment.

In summary, the function of the gateway in this case is:

                                [E(IP(TCP(FTP)))] <=> [A(IP(TCP(FTP)))].

                                                                  Page 8

(1.2) FTP above BSP above PUP, above IP.

This  is the case of PUP-communication, using host encapsulation of PUP-
messages inside IP-messages for transport through the IP-INE.

The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))],
and encapsulates it in the IP-message [IP(PUP(BSP(FTP)))] which  carries
the  IP-address  Y:B, which is encapsulated in the Ethernet protocol for
accessing the gateway.  Hence,  upon  leaving  host-A,  the  message  is
[E(IP(PUP(BSP(FTP))))],  with  the Ethernet-address of the IP-process in
the gateway, by setting the  Ethernet  8-bit  address  to  that  of  the
Ethernet  interface  of gateway-X, and setting the PROTOCOL field to the
value 1001-octal, meaning IP-protocol.

     In some sense, this Ethernet might not be managed as  part  of
     the  PUP-internet,  but  the  hosts had better have valid PUP-
     addresses; the destination process certainly has a PUP-address
     -- that's why we're sending it PUP-messages!

     This raises the following question:  how does the FTP  process
     in  the  PUP  destination get the PUP-address to which it will
     send its response?  A possible answer is that the  sender  had
     better  have  used  a  valid  PUP-address, including a PUP-net
     number.

     It is important to note that in this case  the  end  processes
     are  still  sending  and  receiving  PUP-messages  and must be
     located within the PUP-internet  address  space,  despite  the
     fact  that the IP encapsulation is done in the end hosts.  The
     INE is being treated as a single PUP  transport  network,  and
     the end hosts are both on the same "network".

     The  PUP-address  within a network is only 8 bits, while an IP
     address within any network is 24 bits.   For now,  we  propose
     that  an  ad-hoc  mapping  strategy be employed.  Each IP host
     that implements IP(PUP) encapsulation is assigned a unique PUP
     host number within the IP "network".  IP addresses are derived
     from PUP-addresses by table lookup.   The  table  is  manually
     maintained  (by Xerox-PARC) limited to 256 entries.  We expect
     that only a few hosts will need to communicate in this manner.

Upon receiving this message the Ethernet-process in  the  source-gateway
examines  the  value of the PROTOCOL field and recognizes the message as
an IP-message.  It then hands to the IP-process the message without  the
Ethernet  header.    This  is  the decapsulation of the message from the
Ethernet encapsulation.  The IP-process finds that the IP-address of the
destination is Y:B.  After checking its  routing-tables  the  IP-process
finds the ARPAnet address of the first gateway along the INE-route to Y.
It  may happen that  this is also the final one,  if Y is also connected
directly to the ARPAnet.

Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))].

                                                                  Page 9

Upon arriving at the gateway of site-Y the local-net header is  stripped
off.    This local network is probably the ARPAnet, if Y is connected to
it directly, but may be any  other  network  which  supports  IP.    The
resulting IP-message is handed to the IP-process.

Next,  the  IP-message  is  encapsulated  again  in an Ethernet-message,
addressed to host-B, [E(IP(PUP(BSP(FTP))))].

Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
IP-message  is recovered and handed to the PUP process which hands it to
the BSP process, which hands it to the FTP process.

Note that for this scheme to work it is not necessary for site-Y to have
the same local-access network (here the Ethernet) as site-X has, or  any
other local network.

In summary, the function of the gateway in this case is:

                      [E(IP(PUP(BSP(FTP))))] <=> [A(IP(PUP(BSP(FTP))))].





(2) Encapsulation/decapsulation into IP, by gateways.

We consider a case of FTP above BSP, above PUP.

This  is  the  case of PUP-communication, using gateway encapsulation of
PUP-messages inside IP-messages for transport through the IP-INE.

The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))],
carrying the PUP-address T:B, which  is  encapsulated  in  the  Ethernet
protocol  for  accessing  the  gateway.  Hence, upon leaving host-A, the
message  is  [E(PUP(BSP(FTP)))],  with  the  Ethernet-address   of   the
PUP-process  in  the  gateway,  by setting the Ethernet 8-bit address to
that of the Ethernet interface of gateway-X, and  setting  the  PROTOCOL
field to the value 1000-octal, meaning PUP-protocol.

Upon  receiving  this message the Ethernet-process examines the value of
the PROTOCOL field and recognizes the message as a PUP-message.  It then
hands to the PUP-process the message without the Ethernet header.   This
is  the  decapsulation  of  the message from the Ethernet encapsulation.
The PUP-process finds that the PUP-address of the  destination  is  T:B.
After  checking its routing-tables the PUP-process finds the PUP-address
of the gateway into PUP-network T,  which  is  the  PUP-process  in  the
gateway-Y.  Then it encapsulates the PUP-message [PUP(BSP(FTP))], inside
the   IP-message  [IP(PUP(BSP(FTP)))].    The  protocol  field  of  this
IP-message is set to the value 14-octal to designate this message  as  a
PUP-message.

                                                                 Page 10

Next,  this IP-message is given to the IP-process with the IP-address of
the PUP-process in gateway-Y.  After  checking  its  routing-tables  the
IP-process  finds  the  ARPAnet  address  of the first gateway along the
INE-route to Y. As before, it may happen that this  is  also  the  final
one, if Y is also connected directly to the ARPAnet.

Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))].

Upon  arriving at the gateway of site-Y the local-net header is stripped
off.  This local network is probably the ARPAnet, if Y is  connected  to
it  directly,  but  may  be  any  other  network  which support IP.  The
resulting IP-message is handed to the IP-process  which  recognizes  the
message  as  a PUP message (by the value 14-octal in its PROTOCOL field)
and hands it to the PUP-process of this gateway.

However,  if  the  network  can  support  process-addressing,  then  the
IP-address  of  this  message  may  be  that  of  the PUP-process in the
destination  gateway.    Process-addressing  is  like   addressing   the
"fake-host"s  in  the  ARPAnet,  for example.  In this case the PROTOCOL
field of the IP-header does not have to be used to be used at all.

Note that there is some possible redundancy here,  the  message  may  be
both  marked  as  a  PUP-message  and  be  addressed to the PUP-process.
Hence, it is possible to use only one of these  two  mechanisms,  either
the  IP-header's  PROTOCOL  field,  or  the  ability to address directly
processes in gateways.

The PUP-process has no trouble to figure the exact  Ethernet-address  of
the destination host, T:B.

Next,  the  PUP-message  is  encapsulated  again in an Ethernet-message,
addressed to host-B, [E(PUP(BSP(FTP)))].

Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
PUP-message is recovered and handed to the BSP process which hands it to
the FTP process.

Note  that for such a scheme to work it is absolutely necessary for both
sites to have PUP supporting networks, like the Ethernet, for example.

Note  also  that  every gateway of the [E(PUP)] <=> [A(IP(PUP))] variety
must have a PUP-address in the "IP-network" as discussed in 1.2, page 8.
Furthermore,  the gateways must implement the ability to broadcast  PUP-
messages  to all PUP-hosts (or at least  to all other gateways)  in  the
"IP-network" so that PUP-routing information will propagate through that
"network".

In summary, the function of the gateway in this case is:

                          [E(PUP(BSP(FTP)))] <=> [A(IP(PUP(BSP(FTP))))].

Note that in this case, unlike the previous ones, there is a  difference
in the level of nesting between the two sides of this expression. Why?

                                                                 Page 11

(3)  The  standard  PUP-internetwork  gateway, treating the Ethernet and
     ARPAnet as independent PUP transport networks.

In this case FTP is implemented above BSP above PUP, in an ARPAnet host.

This is the case  of  PUP-communication,  using  the  Ethernet  and  the
ARPAnet as part of the PUP system.

The   sending   host,   A,   generates   an   PUP-message  of  the  form
[PUP(BSP(FTP))], carrying the PUP-address T:B, which is encapsulated  in
the  Ethernet  protocol  for accessing the gateway.  Hence, upon leaving
host-A, the message is [E(PUP(BSP(FTP)))], with the Ethernet-address  of
the PUP-process in the gateway, by setting the Ethernet 8-bit address to
that  of  the  Ethernet interface of gateway-X, and setting the PROTOCOL
field to the value 1000-octal, meaning PUP-protocol.

Upon receiving this message the PUP-process in the gateway  removes  the
Ethernet  header  (hence,  decapsulates  the  message  from the Ethernet
encapsulation) and finds the PUP-address of the destination, T:B.  After
checking its routing tables the PUP-process finds the ARPAnet-address of
the gateway  into  PUP-network  T,  which  is  the  PUP-process  in  the
gateway-Y, which is also directly on the ARPAnet.

Then it encapsulates the PUP-message [PUP(BSP(FTP))] inside the ARPAnet-
message  [A(PUP(BSP(FTP)))].   The LINK field of this ARPAnet-message is
set to the value 152 to designate this message as a PUP-message.

Upon arriving at site-Y the message the ARPAnet-process recognizes it as
a PUP-message by the value of its LINK field (152), and gives it to  the
PUP-process of this gateway.

The  PUP-process  has no trouble to figure the exact Ethernet-address of
the destination host, T:B.

Next, the PUP-message is  encapsulated  again  in  an  Ethernet-message,
addressed to host-B, [E(PUP(BSP(FTP)))].

Upon  arriving  at  host-B  the  Ethernet  header  is  removed,  and the
PUP-message is recovered and handed to the BSP process which hands it to
the FTP process.

Note that both sites must have PUP gateways connected  to  the  ARPAnet;
the  end  hosts  themselves  may  be  anywhere in the PUP-internet.  All
communication in  this  case  is  pure-PUP,  with  no  IP  encapsulation
anywhere.

By  the way, the reason for having this type of gateway is to be able to
talk to MAXC  via  the  ARPAnet.    MAXC   speaks   only  pure-PUP,  not
IP-encapsulated PUP, and this isn't likely to change in the near future.

In summary, the function of the gateway in this case is:

                              [E(PUP(BSP(FTP)))] <=> [A(PUP(BSP(FTP)))].

                                                                 Page 12

A NOTE ABOUT LOCAL ADDRESSING
                                 This  section  is  independent of the
                                 previous sections.   One  may  accept
                                 the  previous recommendations without
                                 accepting the recommendations of this
                                 section.

It is our feeling that local access scheme in general, and Ethernets  in
particular,  should  NOT  be  treated  as  NETWORKS  which  are globally
registered in the InterNetwork directory of Networks.

For sites (1) whose local access network (e.g., the Ethernet) is  NOT  a
registered network and does not have an Internetworkly known Network-ID,
issued  by  Jon  Postel, and (2) are on the ARPAnet, it is proposed that
the 8-bit LOGICAL-ADDRESS field be used as their Ethernet-address.

Since the new ARPAnet address (1822,  96-bit  header)  is  in  the  same
format   as   the   IP-address,  this  could  result  in  a  significant
simplification of the gateway implementation.
Hence, the proposed IP- and ARPAnet-address format is as follows:

IP:       |<--Network--->|<----- understood only by that network ----->|
ARPAnet:  |<--Network--->|      IMP     |Physical host | Logical host  |
          +--------------+--------------+--------------+---------------+
          | ARPAnet='12  |      IMP     | INTERFACE    | local address |
          +--------------+--------------+--------------+---------------+
               8 bits         8 bits         8 bits        8 bits

              (The ARPAnet format is conceptually as shown above,
                   physically it is different, obviously)

The third field identifies the IMP/HOST-interface which is used for  the
gateway.    Traditionally  it is called "physical-host", but it does not
identify the host, it identifies only the interface.

Obviously, the 8-bits local address cannot  be  sufficient  for  a  long
time,  and  sooner or later more bits will be needed to identify all the
local destinations.

Thence, source routing should be used, in the same framework of protocol
nesting.    It  is  important  to  recognize  that  this  will   happen,
eventually,  and  incorporate  this  concept  in  the  design of current
software, even though it is not about to be implemented soon.

Note that for sites  which  are  connected  to  the  INE  this  approach
interacts  with  the "multiple-homing" problem, whose solution is beyond
the scope of this note.

The multiple-homing problem does not exist for sites which are connected
to the INE via a single gateway, like CMU for example.

                                                                 Page 13

(B) Available Hardware/Software

NOTE:  this list is a tentative list of hardware and software components
which may be made available by some sites to other members of the group.
This  should  be  treated  as  a  tentative  list,  rather  than  a firm
commitment.  It is always advisable to check with each group  about  the
status of these components before counting on them.

   - CMU  will  program  a  PDP11/34  to serve as an IP+PUP gateway
     which is capable of performing the encapsulation of PUP inside
     IP, hence being of type S12, being able  to  communicate  both
     with type-S1 and type-S2 sites.

     It  is  expected  that  most of the other sites will duplicate
     this gateway by getting an 11/34 and  importing  the  software
     from CMU.

   - CMU  may  be  able  to implement the IP protocol in Dovers and
     Penguins.  PARC will help.

   - ISI will implement an efficient PDP10-KL/Ethernet interface.

   - ISI  will  implement  a  PDP11-based   terminal   concentrator
     interfaced to an Ethernet.

   - MIT  will probably implement IP (but probably not TCP) in MESA
     for the ALTO.

   - SU will build microprocessor-based Ethernet  interfaces,  with
     the MCS-68000 (or Z-8000)  and  the IEEE488 bus (GPIB) for the
     HP3000, several HP300's and twelve IBM Series/1's.  Also for a
     VAX system.

   - SU will implement a microprocessor-based terminal concentrator
     for the Ethernet.

   - SU  plan to interface a PDP10-KL (SAIL) via the 11/40 console.
     Probably the same for a PDP-KI (SUMEX), too.

   - PARC  will  be  able to supply both TENEX and TOPS-20 code for
     handling both raw-PUPs and byte-streams, also the higher level
     PUP-based protocols such as FTP,  EFTP,  EMPRESS, PSPOOL, etc.
     This does not include the  level-0  handling  which  obviously
     depends  on  the  exact hardware interface.  Since none of the
     sites is expected to have the same Ethernet interface as  MAXC
     has, the level-0 help is not available.

                                                                 Page 14


(C) List of participants


CMU              Bob Sproull     412-578-2621    Sproull@CMUA

ISI              Danny Cohen     213-822-1511    Cohen@ISIB

MIT              Dave Clark      617-253-6003    Clark@MIT-MULTICS

Stanford         Forest Baskett  415-497-1916    FB@SAIL
                 John Seamons    415-497-3236    Admin.jks@SCORE
                 Bill Nowicki    415-497-9437    CSD.Nowicki@SCORE
                 Ron Crane       415-494-4298    Crane@PARC

U of Rochester   Ed Burke        716-275-5671    Feldman@SUMEX-AIM

Xerox-PARC       Ed Taft         415-494-4419    Taft@PARC
                 Mike Schroeder  415-494-4463    Schroeder@PARC
                 Ron Crane       415-494-4298    Crane@PARC
                 John Shoch      415-494-4384    Shoch@PARC



========================================================================

A personal comment:

The main idea of traversing the ARPA-INE with [IP(PUP)] and the division
between host and gateway encapsulation was conceived  during discussions
with Bob Sproull, at CMU.  Bob deserves the credit for getting it right,
but should not be blamed for the details which I managed to mess up.

The  meeting  summary was expanded to cover in  detail several technical
issues (especially  addressing)  which  were  sketched  in  the  meeting
without the details which are necessary to make it all work.  Therefore,
putting this note together turned out to be a bigger  effort  than  what
was expected.

In  addition,  the note attempts to explain many issues and details in a
way which is (hopefully) clear even to the internetworking-naive reader.
Doing so was a substantial effort which could not have been done without
the help from Jon Postel and Carl Sunshine, and a tremendous  help  from
Ed Taft and John Shoch who pointed  many issues,  corrected many details
and rewrote several sections.  Thank you all.

========================================================================



All comments are welcome,
                                     Cheers,
                                                             Danny.