Telephone System Is a Bad Example of Hierarchical Addresses

Networking engineers proposing strict hierarchical addressing scheme as a solution to global BGP table explosion often cite the international telephone system numbering plan (E.164) as a perfect example of an addressing plan that uses hierarchy to minimize routing table sizes. Even more, widespread mobile roaming and local number portability indicate that we could solve IP mobility and multihoming if only insert-your-favorite-opinion-here.

I don’t know enough about the telephony signaling to write a lengthy in-depth blog post on the topic, but from what little I glanced from public information, it seems to me that there’s huge difference between IP mobility/multihoming and telephony signaling.

Telephony signaling is a control-plane activity. You don’t have to go beyond the high level overview Wikipedia article on Local Number Portability to figure out that the hard work is done in the call setup phase through a number of directory lookups. Telephone numbers are thus an equivalent of DNS names, not IP addresses.

Traditional telephony used virtual circuits. After the control-plane call setup phase was completed, an end-to-end circuit was set up and the data plane was no more complex than a simple label (or circuit) switching. Telephone calls were thus similar to MPLS RSVP/TE tunnels, not to packet forwarding in IP networks.

Traditional telephony was bloody expensive. While it’s still cheaper to do simple label lookups than TCAM/trie lookups at very high speeds (see also: Juniper PTX-series), having a lookup table that contains every single phone call that takes 64 kbps becomes ridiculously expensive at terabit speeds. There’s a reason voice service providers use VoIP transport inside their networks.

VoIP just offloads the problem to IP networks. VoIP is just an application on top of IP. In a modern voice network, a directory service is used during the call setup phase to find the IP address(es) of the call participant(s), and the transport problem is offloaded to underlying IP infrastructure. Claiming how telephony numbering works better than IP addressing is like claiming how SD-WAN is better than traditional IP networks… conveniently ignoring the unpleasant fact that both technologies rely on traditional IP networks to work (see also: there are no wires).

Long story short: Using E.164 as an example of hierarchical addressing plan is misguided. Telephone numbers stopped being location identifiers a long time ago, they became names much like DNS names.

Latest blog posts in Site and Host Multihoming series


  1. Telephone addressing system is indeed not clean, as it's built bottom-up, and should never be used as an example of hierarchical addressing. Indeed some(many?) of the numbers are names, not addresses. Their roaming implementations turn mobile numbers into names, so you're right on all counts Ivan. It's hierarchical addressing that one needs to give much thought to, not a bad example like that of the phone companies.

    Also, anyone who positions hierarchical addressing ALONE, as the cure for BGP table explosion, is missing the point (most likely due to not understanding addressing fundamentals). BGP table (and the amount of update) exploded due to IP naming only the interface, and the scope of BGP being the whole Internet. We need a node-level addressing scheme to stop that. H-addressing can help finesse it further, but a two-level addressing scheme is the real fundamental step, with H-addressing being optional but desirable, to the scheme.

    One other thing needs to be made clear: addressing schemes are independent of networking models. So be they OSI, RINA...they can all use the same addressing semantics, like IP.

    Jeroen posted a very valuable presentation by Radia Perlman last time about these same problems. Watch from 28:00 for her view on how IPv6 is just a red herring (which I agree):

    Some people like Geoff Huston -- otherwise a reasonable person whose many points I also agree with -- downplay the problem of tight coupling and complexity associated with the BGP table and update explosions. This paper, released back in 1997 when the BGP table contained a mere 45k routes, shows how bad the problem could already be at this scale:

    At a million route and counting, it'll be much worse when accidents happen, much like the FB Oct crash. Their network rarely crashes, but when it does, due to its complexity, there can be hell to pay as a result of nonlinear interactions in a tightly coupled system. The last thing we want is to make a complex system bigger and bigger.

  2. Let's switch over to FidoNet instead :-)

Add comment