The IP-Based Voice Network

Voice started out on analog phone lines. Each pair of copper wires was dedicated to one specific phone, and to nothing else. This notion of a dedicated circuit has its advantages. It provides complete isolation of whatever might be going on with that line from the circumstances and problems of other phones in the network. No amount of calls being placed on a neighbor's line can make the original line itself become busy. This isolation and invariance is necessary for voice networks to function when unexpected circumstances occur, and ensures that the voice network is reliable in the face of massive fluctuations in the system. Provisioning is simple, as well, with one line per phone at the edge.

The problem with the concept of the dedicated line is that it is extremely wasteful. When the phone is not in use, the line stays empty. No other calls can be placed on that line. Even when a call is in place, the copper wire is fully occupied with carrying the voice traffic, a small bandwidth application, and a tremendous amount of excess signal capacity exists. Dedicated wires might make sense for short distances between the phone and some next-level aggregation equipment, but these dedicated lines were used as trunks between the aggregators, causing tremendous waste from both idleness and lost bandwidth. But probably the property that caused the most complications with wireline networking was that the dedicated line is not robust. If network problems occur-the bundle of cables is cut, or some intermediate equipment fails and can't do its job-all lines that are attached along that path are brought down with it. Digital telephone networks started to eliminate some of the problems inherent to the oneline dedication of early circuit switching. By having digital processes encode and carry the voice, more voice calls could be multiplexed onto each line, better using the bandwidth available on the copper wire. Furthermore, by allowing for hop-by-hop switching with smarter switches between trunks, failures along one trunk could be accommodated. However, the network was still circuit-switched. A voice line could be used only for voice. Even where voice circuits were set aside for data links, the link is either fully in use or not at all. The granularity of the 64kbps audio line, the DS0, became a burden. Running applications that are not always on and have massive peak throughput but equally meek average throughput requirements meant that provisioning was always an expensive proposition: either dedicate enough lines to cover the peak requirement case, and pay for all of the unused capacity, or cap the capacity offered to the application. Furthermore, these circuits needed to be considered, managed, and monitored rather separately. The hard divisions between two circuits became a hard division between applications. Voice networks were famous for their reliability, strict clockwork operation—and complexity. They were not for easy-to-set-up, easy-to-move operations. The wires are drawn once and carefully, and the switches and intermediate equipment is set up by a team of dedicated and expensive experts who do nothing but voice all day. If you were serious about voice, you operated your own little phone company, complete with dedicated operators. If not, your only option was to have the phone company run your phone network for you.

Along came packet-switched networks. Sending small, self-contained messages between arbitrary endpoints on a network inherently made sense for computers. The idea of sending a message quickly, without tying up lines or going through cumbersome setup and teardown operations removed the restrictions on wasted lines. Although it was still true that lines could remain idle when not being used, the notion of allowing these packets of information into the line as the fundamental concept, rather than requiring continuous occupation and streaming, meant that lines that carried aggregated traffic from multiple users and multiple messages could be used more efficiently. If the messages were short enough, one line might do. No concerns about running out of lines and having the needed, or only, path to the receiver blocked. Instead, these messages could just be queued until space was available.

Along with this whole new way of thinking about occupying the resources came a different way of thinking about addressing and connecting the resources. In the early days, a phone number used to encode the exact topological location of the extension. Each exchange, or switch with switchboard operator, had a name and number, and calls were routed from exchange to exchange based on that number first. Changes to the structure or layout of the telephone system would require changes to the numbers. Packet-switching technologies changed that. Lines themselves lost their names and numbers. Instead, those names and numbers were moved to the equipment that glued the lines together. Every device itself now had the address. The binding of the addresses to the topology of the network remained, at some level. Devices could not be given any arbitrary address. Rather, they needed to have addresses that were similar to their neighbors. The notion of exchange-to-exchange routing was retained.

This notion, though, proved to be a burden. Changes to the network were quite possible, as either more devices needed addresses, or more new "exchanges" were added to the network. Either way, the problem of figuring out how to route messages through the network remained. The original design had each router know which lines needed to be used to send the messages along their way. The router might not know how the message should get to the final destination, but it always knew the next step, and could direct traffic along the right roads to the next intersection, where the next router took over. As the number of intersections increased, and the number of devices expanded, the complexity of maintaining these routing tables exploded. A way was needed for neighboring routers to find out about each other, and more importantly, to find out about what end devices they knew routes to. Thus, the routing protocol was born. These protocols spoke from router to router, exchanging information on a regular basis, ensuring that routers always had recent information on what destinations were valid and how to get there from here. But another thing happened. This idea of exchanging the routes had another benefit, in that it allowed the network itself to be restructured, or to fail in spots, and yet still be able to send traffic. Routers did not need to know the entire path to the destination, only the next hop. If a router knew two, different next hops for the same message, and one of the routes went down, the router could try the second one. If the router lost all of its paths to a particular set of destinations, the router before it could learn about that, and avoid using that path to get the messages through. If there was a way to get the message there, the network would find it, through the process of convergence, or agreement over time on the consistency of whether and how messages could be sent. The network became resilient, and point failures would not stop traffic from flowing.

This is the story of the Internet, and of all the protocols that make it work. Clearly, the story is simplified (and perhaps romanticized to highlight the point at hand), but the fundamentals are there. Circuit switching is difficult to manage, because it is incredibly wasteful and inflexible. Packet switching is much simpler to manage, and can recover from failures.

The Internet grew up on top of the lines offered by the circuit-switched technologies, but used a better way to dedicate the resources. It wasn't long before someone realized that voice itself could be put over these packet-switched lines. At first, that might sound wasteful, as using a digital line to carry a packet containing voice can never be more efficient than using that line to carry the same bits of voice directly because of the packet overhead. But packet networking technologies matured, and the throughputs offered on simple point-to-point links grew much faster than did the corresponding uses of the same copper line for digital voice-at least, in the enterprise. And the advantages of using amultipurpose technology allowed these voice over IP pioneers to use the network's flexibility and lack of dedication to one purpose to add to the voice over IP offerings quickly, without requiring retooling of physical wires. The ways in which provisioning was thought about changed, and the idea that voice and data networks can perhaps use the same resources became a compelling reason to try to save deployment and management costs.

There are a tremendous number of resources available for understanding the intricacies of how IP networks operate, including details on how to manage routing protocols and large trunk lines. Here, we will explore how voice fits into the packet-based IP network.