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.
mirror server hosted at Truenetwork, Russian Federation.