ENUM has a critical role to play in telephony services convergence. Although many carriers are adopting ENUM there are myths swirling around the confuse newcomers.
In data networks, the domain name system (DNS) is responsible for converting Uniform Resource Locators (URL's) to IP addresses in order to route data traffic. The ENUM protocol performs a similar essential function of linking E.164 telephone numbers to Universal Resource Identifiers (URIs) — enabling communication services to use traditional phone numbers to set up calls over IP networks.
Unfortunately, there's a good deal of hype and confusion around ENUM, which might lead carriers to delay ENUM implementations. That delay would be a mistake — ENUM has real value to offer today in VoIP and other environments. So I'll attempt to dispel the myths and misconceptions about ENUM and its role in convergence.
Taking Aim at ENUM Myths
Here are the more commonly-heard concerns about ENUM.
Myth #1: ENUM won't be relevant until public ENUM rolls out in major countries
False. Most ENUM implementations today fall within the private and carrier ENUM categories, used for interconnecting islands of services like VoIP and for reducing costs of operations. It is true that public ENUM efforts are hampered by political and regulatory differences between countries worldwide. But, regardless of the fate of public ENUM globally, private and carrier ENUM has an important place inside converged networks today and in the future.
Myth #2: DNS is too slow, or inconsistent in performance, to support ENUM
ENUM performance is critical to call initiation times. Performance in this respect is measured in query latency — the average time it takes an ENUM server to return a result. Query latency must be in the milliseconds, preferably under a millisecond, to meet the call initiation performance standards set by the PSTN. ENUM critics point to Internet DNS latency — in the tens or hundreds of milliseconds — as proof that ENUM is not fast enough.
This issue is easily addressed once one understands the factors contributing to DNS latency. The first factor is the performance of the DNS server delivering local data. Carrier-grade, high-performance ENUM servers, such as those provided by my company Nominum, can provide one millisecond latencies today.
The second factor is the latency required for the local caching DNS server to retrieve authoritative information from the global network. This includes the authoritative servers' latency as well as the latency introduced by the distance on the network. On the open Internet, this latency is indeed impossible to control. However, many carriers today are deploying ENUM within their networks and replicating authoritative data locally. This approach eliminates the latency introduced by the caching/authoritative split and reduces or even eliminates external network effects. This approach is possible using modern compression technology optimized for ENUM data, capable of storing hundreds of millions of records on a single Linux or Solaris box.
Myth #3: DNS can't scale to support ENUM
The data volumes for ENUM data can be quite large because ENUM servers hold routing information for subscribers inside and outside networks, potentially worldwide. Additionally, the information used by ENUM — technically stored in Naming Authority Pointer (NAPTR) records — is much longer than traditional DNS records.
It is also true that today's widely-deployed DNS servers cannot handle the data volumes — tens or hundreds of millions of records — required by ENUM. But this is an implementation issue, not a design issue. Using compression algorithms optimized for ENUM data, specialized ENUM servers can gracefully handle hundreds of millions or even billions of records.
Myth #4: ENUM will be vulnerable to Denial of Service and other attacks
This argument extrapolates from a current weakness in DNS implementations:
DNS servers are vulnerable to Denial of Service attack…
ENUM relies on DNS…
Therefore, ENUM will be vulnerable to DoS attacks.
The logic is a bit simplistic, but the fear behind it is real. We want reliable communications services that cannot easily be disrupted. Attacks and interruptions on the Internet at large are far too common and widely publicized.
One reason that DNS servers today are vulnerable to these attacks is because they are often running "flat out," unable to handle large spikes in traffic. Using more efficient server software with sufficient performance headroom alleviates the risk. Also, because the ENUM data itself will be distributed and replicated in many sites rather than clustered in a few authoritative servers, it will be much more difficult to actually disrupt ENUM service with a DoS attack. In addition, in private and carrier ENUM implementations, the ENUM servers can easily be configured to only respond to queries from approved calling elements.
Myth #5: ENUM/DNS doesn't address local number portability (LNP)
False again. ENUM servers can store a copy of the LNP database and keep it constantly updated with data feeds from NeuStar and other data providers. The question of how you divide phone numbers into zones has ramifications for data management, updates and provisioning. On the surface, it seems ENUM implementers have to choose one of two evils: either confront a massive scalability issue by storing each phone number in a separate and individually managed DNS zone, or take on the burden of building a management application that merges phone numbers into a few zones.
Again, there are design approaches to resolve this problem. Nominum's ENUM server uses the concept of "composite zones." These virtual zones, created from multiple sources, act like full-featured DNS zones. This approach allows data from multiple zones to be organized and queried easily and efficiently, and solves the problem of how to deal with Local Number Portability without "breaking" the DNS.
Myth #6: ENUM cannot support fast updates
ENUM data undergoes frequent and consistent changes, as subscribers change service levels, providers, or preferences. Many of today's DNS servers are not able to support high volume of updates gracefully while handling large query volumes.
Again, this concern is relevant to today's frequently-installed DNS implementations, and not to the ENUM protocol itself. An LNP database of 200 million records in the US typically experiences 300,000 changes a day — an average rate of less than 5 updates/second. There are ENUM-based servers capable of handling thousands of updates per second while serving tens of thousands of queries per second.
Myth #7: ENUM requires too much network bandwidth
ENUM is an essential component of the initial call connection process. Some in telephony feel that, compared with SS7 and other routing mechanisms, ENUM is not an efficient way to perform call routing, as it requires lookups over the network and therefore consumes network bandwidth.
Considered in the context of VoIP traffic, however, the ENUM overhead is negligible. Network lookups for ENUM typically use a single network packet in each direction. Once the call is established, the first second of voice traffic will consume significantly more network bandwidth, and the ENUM traffic pales in comparison. If the network is capable of supporting VoIP traffic, ENUM should not be a problem.
Myth #8: ENUM doesn't have all the features of SS7 call setup
This actually isn't a myth. Using ENUM to route traffic on IP networks bypasses the PSTN and its rich Signaling System 7 (SS7) services. Today, it is correct that the ENUM protocol does not have the rich features built into SS7 over the years because ENUM is part of a larger IP subsystem. Many of the SS7 features are actually contained in other network elements.
At the same time, ENUM providers are extending their solutions to support many of these features, including Least Cost Routing, SIP forwarding, presence, follow-me roaming, etc. And, by using IP networks to route calls, you retain all of the additional functionality provided by converged voice/data/media services, which is lost when using the PSTN. If you are looking purely at feature capabilities, ENUM is the better long-term solution, as it supports next-generation communication services like video, multimedia, conferencing, and more.
When you separate fact from fiction, it is obvious that ENUM has an important role to play in converging networks. These ENUM myths will disappear as this technology is proven in real-world implementations. For now, waiting for the smoke to clear could be a missed opportunity. If you want to reduce the cost of VoIP service delivery, or deploy new, next-generation network services, then ENUM represents a real opportunity for building a long-term, standards-based solution bridging phone numbers and IP networks.
Background: The Many Faces of ENUM
One potential source of confusion, when talking about ENUM, is the variety of ENUM implementations in place today. Quite often, people speaking of ENUM and what it cannot do are really referring to only one of the following:
Public ENUM: This refers to the original vision of ENUM as a global, public directory, with subscriber opt-in capabilities and delegation at the country-code level in the e164.arpa domain. This is also referred to as User ENUM.
Private ENUM: A carrier may use ENUM within its own networks, in the same way DNS is used internally to networks.
Carrier ENUM: Groups of carriers or communication service providers agree to share subscriber information via ENUM in private peering relationships. The carriers themselves control subscriber information, not the individuals. Carrier ENUM is also referred to as Infrastructure ENUM, and is being adopted today to support VoIP peering.
Originally published in Converge! Network Digest
By Chris Risley, Chairman of the Executive Committee of Nominum