Port Expander

The Port Expander was a device created by SRI to allow a number of IP-speaking hosts with IMP interfaces to share a single IMP port. It did this by having a number of 1822 ports - one for each host that it was going to support - along with one more - to connect itself to the IMP. The Port Expander would use the additional 1822 ports to act like an IMP to the downstream hosts connected to them.

This only worked with IP-speaking hosts, where the packets intended for the various hosts could easily be distinguished; it would not work with NCP-speaking ones, where the protocol did not provide any easy way to separate the traffic. All NCP traffic coming in from the IMP is sent to a particular subsidiary host's port.

Sharing an IMP port was desirable in the early days of Internet work, when the ARPANET was the only wide area network available to tie together the various groups doing Internet work; IMP ports were in limited supply, and cost the sponsoring USG entity a substantial fee, when one was available. SRI eventually made a limited-production product of the Port Expander (see link to manual, below).

Software

The Port Expander software ran on the MOS operating system, also done by SRI. There were two generations of Port Expander software; the first was written in MACRO-11, and the second in BLISS-11.

The first has mostly been saved (see link below): 'mostly' because the original code is not available; the code below is code that was modified at MIT to function as a router, by adding a module to interface to an MIT-built LAN. The MIT 'Port Expander' didn't have any subsidiary hosts attached to 1822 ports; just the main 1822 port (connected to the IMP), and the LAN. None of the original Port Expander code was deleted, though; the MIT work simply added a 'bag on the side' to send traffic over the LAN, so the original code (and functionality) can be fully examined.

The way the Port Expander 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.

Any ARPANET host might have up to 8 'in-flight' messages at a time to a particular destination (the exact details changed over time, but this was the general rule of thumb). If more than one Port Expander subsidiary host was sending to the same destination, each expecting to be able to keep 8 messages in flight, the IMP might block the Port Expander, as it had sent too many un-RFNM'ed messages. The Port Expander has code to handle exactly this:

 ; IF THE NUMBER OF MESSAGES
 ; OUTSTANDING ON THE CONNECTION IS LESS THAN 8, PUT THE PORT NUMBER
 ; INDICATOR INTO SUB-LINK FIELD OF THE MESSAGE AND OUTPUT THE MESSAGE TO
 ; THE IMP.  IF THE NUMBER OF MESSAGES OUTSTANDING IS GREATER THAN OR EQUAL
 ; TO 8, ENQUEUE THE IORB ONTO THE "BLOCKED" LINKED LIST.  IT WILL BE SENT
 ; WHEN A RFNM IS RECEIVED AND THE OUTSTANDING COUNT IS LESS THAN 8.  THE
 ; HOST PORT WILL BE BLOCKED UNTIL THE MESSAGE IS SENT.

Potential hardware problem

The Port Expander would not necessarily work with all hosts, though. The implementation had a fundamental potential flaw - the use of existing host interfaces (below) - which meant that an issue could arise; this actually happened with one attempted Port Expander installation.

That is that although the 1822 spec looks like it's completely symmetrical between the Host and IMP sides, it's not, really - not 100.000%. The IMP end of the DH form of the 1822 interface had ground isolation on its output signals. (From the May '78 revision of the 1822 spec, pg. 4-24: "DC isolation is done at the IMP end of the cable ... This isolation is accomplished by optically isolating the signals." The 1975 version says the signals are transformer coupled, while the 1978 version used opto-isolators, but the effect is the same, either way.)

So, if one i) had a host 1822 interface (for use on the 'emulated IMP' ports) which didn't have that isolation on its outputs (because such wasn't required for a host interface); ii) tried to use said host 1822 interface to emulate an IMP, to another host; and iii) the other host's own 1822 interface played fast and loose, and depended on there being isolation at the 'IMP' end... it wouldn't work.

The cause is that the 1822 DH interface used differential signalling; it (pg. 4-26) "drives the odd-number connector pin of each pair to +0.5 volts, and the other pin to -0.5 volt". So if a host's 1822 interface tied the - pin to the host's ground, producing 1.0V signals (from its perspective) on the other pin, that would work if/when connecting to a real IMP - but not when connecting to a Port Expander using a 'host' 1822 interface to emulate an IMP.

That's because in a 'host' 1822 interface, per the 1822 spec, the shield(s) of the cable between the IMP and host is connected to the host's ground ("the cable shields should be very solidly connected to the host's signal ground") - so if there's a 'host' 1822 interface on both ends, the cable shields will be connected to the host's ground at each end, tying the two hosts' grounds together.

So, when plugging such a host into a Port Expander, when the - output was tied to actual ground, then with an interface which didn't DC isolate the + and - outputs, one no longer got 1.0V on the + pin - and the 'fast and loose' host interface wouldn't work. The Port Expander documentation (below) said it had been tested and worked with the DEC AN-10 and IMP11-A, and the ACC LH-DH/11.

External links

• The ARPANET IMP Port Expander - scan of product documentation
• The ARPANET Interface Message Processor Port Expander - reformatted version
• Port Expander - source code for the MACRO-11 version