Enum for carrier services

Hello, I am researching whether or not ENUM is a viable solution for carrier-grade infrastructure routing. It has been suggested that utilizing DNS for number lookups within an internal network is a very powerful, redundant way of handling large volumes of traffic while also gaining caching and many years of DNS infrastructure reliability in one shot. Things is, I can't figure out why a 10+ year technology doesn't have excellent penetration if it's this good. I can guess that hooking a bunch of DNS servers to potentially SQL-based DNS servers has the argument of "why not just go direct to the DB to reduce latency/complexity" but DNS provides other advantages, ranging from local caching on each box (comes "free") to inherent redundancy with multiple name servers (though there's a delay in failing over obviously). And of course, if done properly with partitioning, DNS can be done via flat-files for ultimate speed. So, yeah, looking for any good reads on ENUM or other DNS related services, both pros & cons. Suggestions welcome. - Darren

Darren, On 02/21/2011 02:33 AM, Darren Schreiber wrote:
I am researching whether or not ENUM is a viable solution for carrier-grade infrastructure routing. It has been suggested that utilizing DNS for number lookups within an internal network is a very powerful, redundant way of handling large volumes of traffic while also gaining caching and many years of DNS infrastructure reliability in one shot.
So, just to be clear, are you talking about the use of ENUM for large-scale routing that is nevertheless internal to a single organisation/network/autonomous system/whatever you want to call it, or for inter-domain VoIP peering? The reasons for why the latter hasn't so much taken off are mostly rooted in politics and economic pragmatism.
Things is, I can't figure out why a 10+ year technology doesn't have excellent penetration if it's this good. I can guess that hooking a bunch of DNS servers to potentially SQL-based DNS servers has the argument of "why not just go direct to the DB to reduce latency/complexity" but DNS provides other advantages, ranging from local caching on each box (comes "free") to inherent redundancy with multiple name servers (though there's a delay in failing over obviously). And of course, if done properly with partitioning, DNS can be done via flat-files for ultimate speed.
Everyone has a different opinion on this, but I would say two things matter the most: 1. The built-in freebies (replication, delegation, redundancy, etc.) can also be achieved with databases fairly easily and more straightforwardly, while achieving economies of scale and leveraging existing database infrastructure since non-trivial networks depend on highly available, redundant database clusters anyway. This is often seen as a superior alternative to setting up an entirely parallel DNS-based infrastructure just for routing. But even more importantly: 2. VoIP interconnection still being the largely PSTN-centric world that it is today, in the sense that by far the primary preoccupation of any non-Tier 1 service provider is still exchanging calls with the PSTN, not with other ISPs, the requirements of the routing logic are more complex. There's almost certainly heavy business-layer cost routing (LCR), inter vs. intra-jurisdictional routing and other billing considerations playing a key role. That doesn't play well with the relative simplicity of what DNS is designed to return. Sure, in the end it comes down to "route the call to this IP address," but the method by which I must arrive at that decision entails consulting tariffs, rate decks, etc., which means dipping a database anyway. This is true even for deciding which edge element to run traffic out of in a purely internal scenario, at least for any reasonably complex infrastructure. With enough spiritual commitment and devotion, I suppose one could plumb all that through DNS as an end-stage interface, but that's just an extra--and fairly complex--layer of intermediation. It doesn't really do anything but add extra network elements and systems purely for the sake of doing so. ENUM would make a lot more sense in some sort of post-PSTN environment where voice is just another application framed over dumb pipe, much like instant messaging or HTTP. In that paradigm, it really is just about figuring out which IP endpoint to send the message to, which is what DNS is good for. That may happen someday, but today the process is dictated by all sorts of regulatory, financial, security and policy considerations that require a muscular backend whose fronting by DNS would be kind of contrived and forced. Or so goes my account, anyway. Cheers, -- Alex -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

On 02/21/2011 03:35 AM, Alex Balashov wrote:
the primary preoccupation of any non-Tier 1 service provider is still exchanging calls with the PSTN, not with other ISPs, the requirements of the routing logic are more complex.
I meant just SPs here, not ISPs. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
participants (2)
-
abalashov@evaristesys.com
-
d@d-man.org