Port Expander - Revision history

Jnc: Avoid redir

2025-04-09T15:39:04Z

Avoid redir

Jnc: /* External links */ +HOSTs as IMPs

2024-01-23T04:47:18Z

‎External links: +HOSTs as IMPs

Jnc: More NCP fixups, minor clarifications while I'm here

2022-06-29T13:07:31Z

More NCP fixups, minor clarifications while I'm here

Jnc: /* Potential hardware problem */ de-plural link

2022-06-05T08:16:19Z

‎Potential hardware problem: de-plural link

Jnc: dab NCP

2022-06-05T08:11:19Z

dab NCP

Jnc: better cat

2021-11-06T00:27:20Z

better cat

Jnc: link 1822 article, RFNM

2021-11-02T19:24:20Z

link 1822 article, RFNM

Jnc: runs on MOS

2021-11-01T10:10:42Z

runs on MOS

Jnc: Pretty complete

2021-10-31T15:38:25Z

Pretty complete

New page

The '''Port Expander''' was a device invented by [[SRI International|SRI]] to allow a number of [[Internet Protocol|IP]]-speaking [[host]]s with [[IMP interface]]s to share a single [[Interface Message Processor|IMP]] port. It did this by having a number of [[Host-to-IMP Protocol|1822 port]]s - 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 [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Program|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==

There were two generations of Port Expander software done by SRI; the first was written in [[MACRO-11]], and the second in [[BLISS|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 [[Local area network|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 pair|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 [[Digital Equipment Corporation|DEC]] AN-10 and [[IMP11-A ARPANET interface|IMP11-A]], and the [[Advanced Computer Communications|ACC]] [[LH-DH/11 Local/Distant Host Controller|LH-DH/11]].

==External links==

* [https://apps.dtic.mil/sti/pdfs/ADA156186.pdf The ARPANET IMP Port Expander] - scan of product documentation
* [https://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf The ARPANET Interface Message Processor Port Expander] - reformatted version
* [http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/ Port Expander] - source code for the MACRO-11 version

[[Category: Networking]]

@@ Line 9: / Line 9: @@
 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|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 [[local area network|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 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 [[Massachusetts Institute of Technology|MIT]] to function as a [[router]], by adding a module to interface to an MIT-built [[local area network|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 [[Host-to-IMP Protocol#Packet Types (Host->IMP)|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.
+The way the Port Expander handles [[Host-to-IMP Protocol#Packet Types (Host->IMP)|RFNM]]'s is that it has a database of "CONNECTION BLOCK"s which record messages sent out to a particular IMP; when a RFNM arrives, it uses the CB database to work out the downstream host which originated the message which 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:

@@ Line 1: / Line 1: @@
 The '''Port Expander''' was a device created by [[SRI International|SRI]] to allow a number of [[Internet Protocol|IP]]-speaking [[host]]s with [[IMP interface]]s to share a single [[Interface Message Processor|IMP]] port. It did this by having a number of [[1822 interface|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 [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Program (ARPANET)|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.
+This only worked with IP-speaking hosts, where the [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Protocol|NCP]]-speaking ones, where the [[protocol]] did not provide any easy way to indicate the traffic for multiple hosts. 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).
@@ Line 9: / Line 9: @@
 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|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 [[Local area network|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 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 [[local area network|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 [[Host-to-IMP Protocol#Packet Types (Host->IMP)|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.
@@ Line 27: / Line 27: @@
 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-isolator]]s, but the effect is the same, either way.)
+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%, at the [[analog]] level. 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-isolator]]s, 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.

@@ Line 1: / Line 1: @@
 The '''Port Expander''' was a device created by [[SRI International|SRI]] to allow a number of [[Internet Protocol|IP]]-speaking [[host]]s with [[IMP interface]]s to share a single [[Interface Message Processor|IMP]] port. It did this by having a number of [[1822 interface|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 [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Program|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.
+This only worked with IP-speaking hosts, where the [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Program (ARPANET)|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).

← Older revision		Revision as of 00:27, 6 November 2021
Line 43:		Line 43:
	* [http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/ Port Expander] - source code for the MACRO-11 version		* [http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/ Port Expander] - source code for the MACRO-11 version

−	[[Category: ~~Networking~~]]	+	[[Category: ARPANET]]

@@ Line 42: / Line 42: @@
 * [https://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf The ARPANET Interface Message Processor Port Expander] - reformatted version
 * [http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/ Port Expander] - source code for the MACRO-11 version
 [[Category: ARPANET]]

@@ Line 1: / Line 1: @@
-The '''Port Expander''' was a device invented by [[SRI International|SRI]] to allow a number of [[Internet Protocol|IP]]-speaking [[host]]s with [[IMP interface]]s to share a single [[Interface Message Processor|IMP]] port. It did this by having a number of [[Host-to-IMP Protocol|1822 port]]s - 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.
+The '''Port Expander''' was a device created by [[SRI International|SRI]] to allow a number of [[Internet Protocol|IP]]-speaking [[host]]s with [[IMP interface]]s to share a single [[Interface Message Processor|IMP]] port. It did this by having a number of [[Host-to-IMP Protocol|1822 port]]s - 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 [[packet]]s intended for the various hosts could easily be distinguished; it would not work with [[Network Control Program|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.
@@ Line 7: / Line 7: @@
 ==Software==
-There were two generations of Port Expander software done by SRI; the first was written in [[MACRO-11]], and the second in [[BLISS|BLISS-11]].
+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|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 [[Local area network|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.