[ih] Internet-history Digest, Vol 63, Issue 3

[Jack Haverty]

It's hard to remember a number, but the "Cisco Does IT!" list looks 
plausible as protocols their routers supported.  I recall that there 
were a lot of choices.   Perhaps the Internet Archive has ancient 
documentation captured from cisco.com.

In the early 1990s, I was "Internet Architect" at Oracle.  Our mantra 
was "Any Computer, Any Network", and we built software for all kinds of 
computers and whatever kind of network the customer might have chosen.  
"Client Server" was the buzzphrase of the day, so our mission was 
connecting clients to servers, regardless of who made the computer or 
what kind of network was involved.

That meant we had to know about all sorts of networks.

In addition to developing software, we also ran the corporate 
"intranet", using cisco multi-protocol routers to interconnect sites in 
something over 100 countries.   We never ran, at the same time, all of 
the protocols cisco supported.   But we did run a multiprotocol 
intranet, and therefore could experience the same pain our customers 
were having.  And there was definitely pain, especially in the era when 
the oxymoron of "global LAN" was popular.

The evolution of technology by that point had made purchases of 
computing equipment no longer restricted to corporate decision makers.  
PCs, workstations, and LANs now fit within departmental budgets and 
purchasing authority.   The result was a corporate technology melange - 
perhaps PCs in accounting, mainframes in IT, Apple in Marketing, DECNET 
in Engineering, etc.

Although our client/server software could run on any computer, and on 
whatever network you chose, it couldn't connect a client on Netware to a 
server on SNA.

Having experienced the rise of TCP as a technology to interconnect 
diverse physical networks using "gateways", the parallels to the 
multiprotocol world were pretty clear.   Routers interconnected physical 
networks, and multiprotocol versions could run all sorts of protocols 
over them.   But that didn't enable clients on one type of logical 
network (such as SPX/IPX) to connect to servers on another type (such as 
TCP).

Basic IP routers interconnected physical networks using IP. 
Multiprotocol routers created overlapping, but separate, internets of 
each type, such as IP, IPX, etc.  What was missing was the technology to 
form an "internet of diverse internets".

We created a copycat to IP's router technology, with a product called an 
"Interchange", to connect between one or more logical networks.  An 
Interchange was just software, so the only requirement was some computer 
somewhere that supported two or more types of network protocols.

Conceptually, an "Interchange" simply "plugged together" whatever 
virtual circuit capability existed in each network.  Multiple "hops" 
were possible, e.g., to pass traffic between an SPX/IPX client to a TCP 
backbone, to a mainframe server using LU6.2 (SNA), by passing traffic 
through 2 Interchanges, "plugging together" the virtual circuits from 
each.   Multiprotocol routers interconnected physical media; 
Interchanges similarly interconnected logical networks, enabling 
customers to use their multiprotocol networks more effectively.

I remember being somewhat shocked to hear customers' visions of the 
future for their own IT worlds.  Although many of them had multiprotocol 
networks, they were all at various stages of experimenting with TCP, and 
many had already decided that TCP was their choice as a target 
architecture within their organization. TCP had already won, and the 
challenge was figuring out how to get there.   That was in the early 90s.

So our message changed.  Interchanges still enabled customers to choose 
multiprotocol networks as their IT infrastructure.  But they also served 
a management role, permitting different parts of the organization to 
introduce TCP to replace whatever they had been using, but at their own 
pace driven by strategy, budgets, and pragmatics.  During such 
transitions, which might take years, Interchanges maintained 
connectivity between all clients and all servers.   There was no need to 
plan for the disruption of a "flag day" switchover.

One regret I've had is that I never thought to ask the customers *why* 
they all chose TCP for their long-term target architecture.

That's why I asked "Why did TCP win?"

Jack Haverty

On 2/2/25 09:28, John Shoch via Internet-history wrote:
> Jack Havety wrote:
>
>
>> Corporate networks used "multiprotocol routers" to run a simultaneous
>> mix of different Internets over the same circuits and equipment they had
>> purchased. ...
>> During the 1990s and 2000s, I watched as all of those competitors
>> disappeared.? It seemed like it happened almost overnight.? Few people
>> today likely even remember they existed.??
>
> OK, so this has provoked me to ask a trivia question, especially for all of
> you who know more about Cisco than I do:
> "In the early days, how many networks or protocols were handled by Cisco's
> multi-protocol routers?"
> I certainly don't know.  But as a starting point, the Computer History
> Museum has a t-shirt on display from Cisco.
>      https://www.computerhistory.org/collections/catalog/102696803
> Don't think I can attach a photo here, but it says on the front:  "Others
> talk about it."
> And on the back it says:
> "Cisco Does It!"
> TCP/IP
> DECnet IV and V
> Novell IPX
> AppleTalk I and II
> ISO CLNS (OSI)
> SDLC Transport
> Banyan VINES
> Ungermann-Bass Net/One
> 3Com 3+/3+Open
> Xerox XNS
> Apollo Domain
> Xerox PUP
> CHAOSnet
> SNA
> NETBIOS
> PPP
> X.25
> DDN X.25
> Frame Relay
> SMDS 802.6
>
> I wonder if that list was sorted by market share at the time, in their
> deployments......

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250202/285fc17e/attachment.asc>