[ih] More topology

[Barbara Denny]

 I think Radia was involved with the problem but I don't know if she influenced what SRI did.  Jim Mathis or Zaw-Sing Su or perhaps Mark Lewis might be able to remember but I would have to look at what she was thinking in that space to have any comments.  If I remember the order of my projects correctly,  I was working on the Metanet gateway when the design and most of the development of the RP gateway was done.  
barbara
    On Monday, August 30, 2021, 02:50:39 PM PDT, Vint Cerf <vint at google.com> wrote:  
 
 Barbara,I had not realized you were involved in the partitioned network solution. Wasn't Radia Perlman also engaged on that?
So ELF was the OS for the BCPL gateway. I had forgotten that. Dick Karp at Stanford did his first TCP in BCPL for our PDP-11/40
v

On Mon, Aug 30, 2021 at 5:07 PM Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:

 Just a Guess. The Packet Radio station software probably made use of the router code base you mention.  The station software was written in BCPL and ELF was the operating system.  I don't know the timelines of the router development and the Packet Radio station development.  Ginny Strazisar (Travers)  probably can clarify this or perhaps Mike Beeler or Jil Westcott.
barbara
    On Monday, August 30, 2021, 12:59:28 PM PDT, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:  

     > From: Jack Haverty

    > I never did learn how the PE handled RFNMs, in particular how it
    > interacted with its associated NCP host that it was "stealing" RFNMs
    > from.

I know a bit about the Port Expander; we were planning on using it at MIT at
one point, since MIT had no spare IMP ports for an IP gateway (router). (We
didn't get an IMP port for the MIT gateway until MIT got its third IMP, one
of the first C/30's.) That didn't work out, as I'll explain later.

The PE didn't share the NCP 'host' among connected hosts; all NCP traffic
coming in from the IMP is sent to the 'main' subsidiary host's port:

  ; WHEN A TYPE 0 OR TYPE 3 MESSAGE IS RECEIVED, FIRST CHECK THE MESSAGE'S
  ; LINK NUMBER.  IF THE MSG IS NOT ON AN INTERNET LINK, THEN SEND THE MSG TO
  ; THE PORT THAT RECEIVES ALL NON-INET TRAFFIC (PORT INDEX IS IN NCPPRT)

For IP traffic, the PE acts as a gateway (i.e. router), and there's a table
which says which downstream port various IP hosts are on.

The way it handles RFNM's is that it has a database of "CONNECTION BLOCK"s
which record messages sent out to the IMP; when a RFNM arrives, it uses the
CB database to work out the downstream host which originated the message the
RFNM is for; the RFNM is then handed to it.


As the above excerpt probably made clear, I still have the PE code (it had
been squirreled away on the MIT-CSR Unix - I made a full dump of that machine
before it croaked, so we now have access to all that history; I guess I was
concerned about history even back then).

I don't think I have the _original_, unmodified PE code; what I have is a
bodged version that I hacked to act as a gateway to the MIT 1 Mbit/sec ring
LAN. I.e. it did't have any subsidiary hosts attached to 1822 ports; just the
main 1822 port (connected to the IMP) and the LAN. I'm too lazy to
see exactly what I did with RFNM's there; probably just pitched them
(no RFNM's on a LAN :-).

While I was looking for that, I ran across some other old code that
might be interesing:

- the TIU (kind of a predecessor to the TAC, a _very_ early implementation of
  TCP in Macro-11 for the PDP-11, written by Jim Mathis, which I believe
  was the basis for Jack's first UNIX TCP at BBN);
- a couple of modules from the BCPL gateway code from BBN (the one that
  ran under ELF); historically interesting, as it was the very first
  IP router code _ever_.

If anyone is interested in any of this stuff, let me know and I'll look
into getting it uploaded and made available.


The reason we couldn't get the PE to work was that the SRI 1822 interface
(which is what were planning to use on our PE) didn't _exactly_ electrically
duplicate the IMP 1822 interface; the latter used optp-isolators on the DH
interface, and the SRI interface didn't have them.

The plan was to put the PE in from of the DM ITS machine, but when
we tried it, it didn't work. Ken Pogran looked into the issue, and
discovered that the person who did DM's IMP interface (I wonder who
that was :-) had done some 'trick' (the exact details of which now
escape me - it was something to do with the ground he used for the
DH interface signals),and without the opto-isolators the SRI
1822 interface wouldn't talk to it.


    Noel
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history

-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history



-- 
Please send any postal/overnight deliveries to:Vint Cerf1435 Woodhurst Blvd McLean, VA 22102703-448-0965
until further notice