I am fascinated by most network technologies, and having spent several years at this point looking at the latest and greatest I’ve now decided to look back at some of the technologies that got us to here. Circuit switched networks have always fascinated me and as I’ve recently gotten into running my own local phone systems, dial-up networking seemed like the logical place to jump in head-first.
First off, lets define some terms and concepts that are central to this kind of network. The best place to start is probably a brief explanation of circuit switched networks. Unlike packet switched networks like Ethernet or Internet Protocol networks which use small units of data that may take different paths to their destinations, circuit switched networks are continuous paths that are point to point and set up and torn down as channels are requested. This means that there is a dedicated path from the source to the destination for information that wishes to flow between those points, but also means that for every two points that wish to communicate we need another dedicated circuit. This would get expensive quickly and so this isn’t quite how the public telephone network works. The phone network uses aggregation switches which connect to many subscriber lines and then peer at a higher level using interconnections called trunks. A trunk can carry some fixed number of circuits at any given time, sometimes referred to as calls or paths.
The most basic trunk for our purposes is a T1 trunk, which is capable of carrying 24 channels of voice data at 64kbit/s. If you were to bond all of these channels together you would get a connection with a maximum data rate of around 1.5mbit/s. While this doesn’t sound like much, its guaranteed bandwidth. This is the major difference between a circuit switched network and a packet switched one, and why calls between two traditional landline telephones sound so clear (though you may not notice it, cell phones and VoIP systems suffer from IP jitter which causes audible artifacts). Trunks are the “fat pipes” of the circuit switched world, and the mechanism by which these pipes are broken up is called time division multiplexing. This allows for data to be shuttled across the network with a minimum possible delay if all network nodes are locked to the same clock.
Trunks interconnect switches, so lets talk about those. A phone or voice switch must be capable of taking an input call, determining the destination route, and connecting the circuits to each other. Whereas IP packets and Ethernet frames use headers to identify their targets, the phone system uses phone numbers (surprising I know). These numbers compose the routing table, referred to as a “dial plan” that the switch uses to route calls around. Dial plans can be fairly direct or complex. For example, a simple dial plan entry would connect a given number to a specific physical interface, whereas a complex entry might rewrite the number, hand it off to another switch, and change the parameters of the inbound line in some way. For the purposes of the voice network supporting my dial-up system, the dial plan is simple and consists of pointing numbers to the correct interfaces.
A second important concept to address is that of the Point to Point Protocol. This is the mechanism by which data is passed between the two modems in the call. Other protocols exist, but PPP is by far the most common protocol used in this context. PPP is a layer 2 protocol which includes authentication, encryption, and compression features. The scope of PPP is larger than this article, but if you want to learn more, the protocol is fully specified in RFC 1661. For the purposes of dial-up networking, the important part to remember is that PPP is a direct connection between two network devices with nothing in the middle. It is a full duplex connection, and it includes the signaling necessary for partial auto-configuration of the client.
Now that we have some context, lets look at the topology of the network and what the different parts do.
For a dial-up system, there are 3 key parts, there’s the customer equipment consisting of a terminal and modem, the switched telephone network in the middle, and the ISP’s equipment at the other end. We’ll go through each component in turn and how they work in some detail.
At the customer end there are two easily identifiable parts. There’s a terminal or computer of some description and a modem. The computer is responsible for speaking the PPP protocol and providing an interface for IP communications over the link.
The modem is really the interesting piece of equipment at this end. The modem is responsible for taking the data that the computer wishes to send and converting it to a series of pulses or tones on the phone line. In the early days of computing, modems were acoustically coupled to the line, meaning that you literally took the receiver of your phone off hook and put it into a special device that had cups over the speaker and microphone to allow the modem to “hear” and “talk” to the phone’s handset. These modems are limited in terms of their data rate by the accuracy with which they can listen to the phone, and the accuracy that the phone can listen to them (as well as the physical compatibility of the phone, but in this era everyone had the same phone for $reasons).
The better kind of modem is obviously a modem that is directly connected to the phone line so that it can process the signals electronically. These modems can either be internal or external. Almost universally the external modems present a serial port to the host machine, even if they are connected by a dramatically newer interface such as USB. Most modems that are external that have withstood the test of time can be said to be “Hayes compatible”. This refers to the compatibility of the modem with the Hayes command set to configure the modem from the host machine. Internal modems can expose themselves as a serial port, but by the time modems were commonly moving inside computers there was enough computing power on the CPU that the modem didn’t need its own onboard processor anymore. These modems can collectively be referred to as “winmodems” as they almost universally use a kernel mode windows driver which makes them unusable in any other environment. Rarely there are winmodems for which drivers in other operating systems exist, but these are the exception and not the rule.
For my dial-up experiments I dug out an old iBook clamshell laptop which has an integrated modem. As it is running MacOS 9.2, I don’t need to worry about whether its a Hayes compatible modem or a software driven modem as the OS has the drivers for it handily baked in.
I also have a small USB modem that presents a Hayes compatible interface, but the support for dialing a modem is surprisingly hard to get fully running in my Linux distro of choice, so this remains an adventure for a future date.
For my phone switch I’m using a Cisco 2811 Integrated Services Router (ISR) loaded with several T1 VWIC modules to allow it to act as my TDM network. The 2811 is a dated system at this point and can barely pass IP traffic at around 50Mbps, barely fast enough to sustain a bonded DSL connection on a modern network without any firewalls or policy routing. Fortunately for my purposes it only needs to support TDM traffic, which happens entirely in hardware on a timeslot interchange. Timeslot interchanges are dedicated chips that perform realtime handling of TDM data. I configured the ISR by connecting to it with the standard console cable and configuring via the terminal.
The ISR only has T1/E1 interfaces though, so to plug a phone into it a device needs to break out the trunk into individual circuits like what you’d find on your wall. Such a device is commonly referred to as a channel bank because it takes the 24 channels of a T1 interface and turns them into 24 separate phone lines. In my phone system I have a Zhone ZPlex 10, which takes the cake as the strangest networking component I’ve ever used. The configuration interface is not context aware, but the configuration is. The company behind it still exists, but has precious little in terms of documentation. Overall its a strange 1U device. When I initially started this project I was using a Carrier Access Adit 600, which is proper carrier grade equipment. Its a unit designed to go in a roadside equipment cabinet and has a modular interface to split out source circuits into individual customer lines, make use of onboard modems, or a myriad of other functions I’m not interested in right now. The Adit is however designed for roadside cabinets, not rack mount environments, so it was ultimately swapped out for the Zhone. From the Zhone a 25-pair cable runs to a breakout panel that provides 24 RJ-11 jacks for me to connect phones and modems to. A cable runs from this patch panel over to the iBook’s modem port to connect it to the phone system.
In a traditional phone system all the components up to this point would be owned by the phone company. These components comprise the local loop between my customer equipment and the phone company, the local switch and supporting hardware, and most importantly, the billing systems that work out just how much of my arms and legs I need to fork over for the privilege of using my 64k circuit. Fortunately as my own phone provider I can offer a significant discount to myself.
When dialing in though the phone company is only half of the equation. You need to actually connect to an internet service provider to be provided with internet services. Now these are often operating units within the phone company providing added value, but historically there were many different independent small dial-up operators. Large or small though, the problems are the same. To provide dial-up internet you need to have an access number, some number of modems to answer incoming calls, and a means of interconnecting the sessions from the modem banks to an IP network ultimately interconnected with either the internet (today) or a subscriber network (as in the early days of AOL, Prodigy, and Compuserve).
Its possible to build this component using a linux server and a handful of modems, or to hook up something like a Dialogic card and write a service routine to act like a modem bank. There’s also purpose build hardware to fill this niche like the Cisco ASA line. Through the fine art of hunting around on eBay and similar sites, I was able to source a Patton Electronics Dialfire 2960, which is probably the most 90’s sounding electronic device I’ve ever heard of or purchased.
The dialfire is a complete dial-up system in a box. It provides a 1U Remote Access Server that understands PPP, SLIP, ISDN, and a host of other strange and obscure protocols. It does this with a handful of specialized chips that decode the line data and hand it off to a more general purpose processor. The unit is dual PSU as is most serious infrastructure equipment, and takes up to 4 T1/E1 WAN connections for up to 96 concurrent calls. Mine is only equipped to handle 24 concurrent calls, but looking in the circuit board its clear that the only difference with the larger models were more Digital Signal Processing chips being added, and perhaps some more memory added in footprints that are unpopulated on mine. Its capable of 10/100 IP networking and has a fun repeating background GIF on all the configuration pages that I haven’t figured out how to turn off yet. The Dialfire is connected to the ISR via a short T1 crossover cable and is configured to provide PPP as the default service if the client doesn’t request anything else. Right now I’m configuring the Dialfire’s onboard authentication database, but ultimately I’d like to proxy its RADIUS capabilities to NetAuth and use dynamic user elements. Since it only supports PAP authentication it would play well with external authentication.
So overall the connection path is as follows:
- iBook plugs in via modem cable to the patch panel and via a fat interconnect in the rack to the Zhone channel bank.
- Zhone channel bank is connected via T1 to the ISR and has all 24 trunks configured as loop start devices with DNs 800-823 corresponding to ports 1-24 on the patch panel.
- ISR connects to the Dialfire via T1 and will pass calls to the Dialfire when its access number is called.
- Dialfire is connected to an Ethernet switch via standard Ethernet.
- Ethernet switch is connected back to the ISR’s IP side where it NATs out to my experimental VLAN.
At this point its possible to use Remote Access in Mac OS 9.2.2 to dial the Dialfire’s access number and have PPP pick up and connect. From there the experience is just as it would have been in 2000. Of course the web has moved on since 2000 to bigger and “better” things, so there are many sites that no longer work or perform poorly. The iBook’s crypto stack is almost completely obsolete, and many sites that it might be able to render can’t connect because the client and server no longer share a common key exchange algorithm or cipher suite. Remember that up until LetsEncrypt TLS was generally speaking not free and generally speaking was only in use on larger sites that had a financial reason to use it. Now that every blog, homepage, and webring has TLS these vintage computers can’t really access it.
To combat this problem I have a web rendering proxy that runs on a standard x86_64 small form factor server which I can use to “cheat” the modern web and effectively run a browser inside a browser. As this is effectively remote desktop in a browser to chrome I am trying to avoid it, and hope to soon replace it with a TLS stripping proxy.
So what have I learned from building the crappiest ISP in existence? I’ve learned a lot about the world of circuit switched and guaranteed bandwidth applications. The TDM buses in this system have absolutely zero question w.r.t. the bandwidth available at any given time as its all pre-calculated as part of the multiplexing. I’ve also learned that the equipment running the telephony stack is pretty much bulletproof, far more than any of the IP networking systems I work with in my day-job. Its clear that the telephony world is built for absolute reliability in the face of disaster, perhaps that’s a subject for a future post…
Hopefully you’ve enjoyed what you’ve read here, this is only scratching the surface, and if you want to learn more about how the public switched phone system (PSTN) works I highly recommend the book Exploding The Phone by Phil Lapsley. If you’re interested in more of the early days of computer networking, and what hijinks occurred on the early nets I also highly recommend The Cuckoo’s Egg by Cliff Stoll. These two books are what inspired me to learn more about the phone system and networked world around me.