The ISP Column An occasional column on things Internet
	Other Formats:

Infrastructure ENUM
February 2007

After much initial fanfare a couple of years ago ENUM has matured to a state where it is currently yet another under-achiever in the technology deployment stakes. ENUM initially presented itself as a very provocative response to the legacy telco position of monopolising public voice services through their exclusive control over the Public Switched Telephone Network (PSTN) and the associated controlling position over the telephone number space (the so-called "E.164" number space, after the ITU-T recommendation E.164 which recommends country code assignments for switched telephony services). The perception was that ENUM was going to dismantle these levers of control and open up the voice market to a new wave of competitive carriers. If the address plan was the key to the PSTN, then ENUM was intended unlock this network and position the new wave of Voice Over IP (VOIP) carriers to take over any residual treasures of the traditional voice market.

Events have not played out according to these expectations, or at least not yet, and not via ENUM as it was originally conceived. Yes, there is a lot of VOIP happening, from user services such as Skype and Google Talk through to VOIP systems that have pretty much replaced the historic PABX configurations. But ENUM itself is not taking over the voice services world. We have yet to see a major change in the major regulatory regimes to head beyond limited scope "ENUM trials" and to open up their entire national number space to ENUM registration. We've yet to see end users in a position to exercise complete and total control over the manner and type of service delivery associated with their phone number.

ENUM, it would appear, is languishing quietly in an increasingly dim and dusty regulatory corner.

But that does not mean that the VOIP industry has been passively waiting for interest in ENUM to pick up. Indeed, a widely held view is that the original concept of ENUM completely missed the target and that the real leverage of ENUM is not as a service for end users to express their preferences, but as a means of inter-carrier signalling, or "Infrastructure" ENUM as distinct from the original concept of "User" ENUM. In this article I'd like to look at the current state of Infrastructure ENUM and look at the tensions that this topic has raised between the open and closed service models.

A Recap of User ENUM
 
If you are attached to a VOIP network that is connected to the wider PSTN network via some kind of VOIP gateway and you make an outgoing call, then how should your local gateway route the call? The initial operation is to see if you are calling someone else that is behind the same VOIP gateway, in which case the call can be completed locally via VOIP. If not then the only thing the gateway can do is to pass the call request out into the PSTN for call completion, and pay the PSTN the standard call termination charges to complete the call. But if your local VOIP gateway had a means of access to "complete" knowledge of the ways to reach every dialled number, then if the number you called was in some other carrier's VOIP world, then, ideally, your gateway could avoid using the PSTN to complete the call, and simply route the call via IP to the corresponding called party's VOIP gateway.
 
From this perspective, the core User ENUM problem is how to support a PSTN bypass function. In other words, how can a VOIP gateway dynamically discover that a called number maps to a VOIP service that is directly reachable via the Internet, without resorting to the PSTN.
 
The approach taken by User ENUM is to use the public DNS as the discovery mechanism. The starting point is where clients publish their call preferences using the DNS. If I wish to be reachable via SIP, for example, I use the DNS to associate my conventional E.164 number with a SIP address. I create a DNS zone using a transform of my phone number and then insert a Resource Record in this DNS zonefile that references my SIP URI. The calling party (or its agent that is attempting call completion) uses a DNS lookup to establish my call preferences. It applies a simple transform to the E.164 called number to generate a DNS query, and the DNS responses describe the set of services that are associated with that number, the called party's relative preferences and the description of the rendezvous point to actually complete the requested transaction. My SIP URI is returned and the call can be completed using SIP.
 
So this is "User" ENUM. A zone of the public DNS (e164.arpa) is populated with E.164 PSTN numbers Each complete E.164 number is a terminal DNS zone, and is populated with a collection of service rendezvous URIs. This is an opt-in multi-service where each E.164 number may be added into the DNS, and the contents of the zone file reflect multiple services that may be provided by multiple different service providers.

For all its virtues, "User" ENUM really hasn't happened yet. Yes, there are trials, but mass deployment in the scale of hundreds of millions of ENUM entries in the DNS has proved challenging so far.

There are a number of factors here that may explain this situation. It can be quite a complex operation to correctly populate an ENUM DNS zone, and there is the question of who should be maintaining the user's zone. Given that a user may want to use multiple service providers for different services, then how do multiple service providers each maintain a subsection of a single DNS zone without treading on each other's toes? And whose E.164 number is it anyway? If I cancel my PSTN service can I still use the same number exclusively for SIP calls? But within all these potential factors, perhaps the most significant one is that most, if not all, of the traditional PSTN operators see ENUM as a threat rather than an opportunity. ENUM allows users to exercise fine-grained control over service selection, with the potential of constructing a highly volatile and very price sensitive environment voice market where the user has complete control over service selection on a scale of hours or even minutes. For incumbent telephone operators this is undoubtedly a nightmare of the worst order, and ENUM represents a future that simply has to be resisted in any and every possible way.

Even the oft-touted dreams of E.164 phone numbers taking up the role of a universal identity schema so that one number could lead to your web page, your SIP service, your mailbox, and so on, were perhaps just another instance of incredibly wishful thinking on the part of an insatiably voracious DNS name registration industry. The issue here appears to be that ENUM is simply pushing too hard against a well-entrenched incumbent PSTN voice industry, for whom ENUM represents a future that simply is not aligned to their perception of self-interest.

So if User ENUM is having such a hard time, why has Infrastructure ENUM managed to spark some interest? One possible reason is that Infrastructure ENUM services a slightly different client base. These clients, the competitive voice carriers, have similar cost minimization motives to end users, but also have a far greater ability to translate such motivations into outcomes.

What do the Competitive Carriers want from ENUM?

ENUM takes on a different guise from the perspective of a competitive VOIP-based carrier. From this perspective, ENUM is an efficient way to dynamically discover the ultimate identity of the terminating carrier, their preferences in the way in which the call should be terminated, and the termination rendezvous point. It's not the preferences of the end-user here, but the end-user's VOIP service provider's preferences that are important. This is what is being referred to as "Infrastructure ENUM".

In theory, infrastructure ENUM could be considered to be somewhat unnecessary, as it appears to duplicate the role of the SS7/C7 signalling mechanism in the PSTN framework. So why is infrastructure ENUM of interest to VOIP carriers? As is usual in things ENUM, the answer turns inevitably to money. Not only does SS7 equipment represent a considerable financial and technical investment for a competitive carrier, but SS7 is, in effect, no more than a PSTN traffic director. If the primary objective of the signalling system is to discover the cheapest possible call termination path for any call across all possible transports, then SS7 and the PSTN are generally a last resort, and the most valuable information for competitive carriers relates to alternative IP-based call termination mechanisms that would be used in preference to the PSTN.

From the competitive VOIP carrier's perspective infrastructure ENUM is not really about the end users' fine-grained preferences relating to local service preferences. It's actually about call termination options for number blocks and leverage of the Internet as an inter-VOIP transit network. Infrastructure ENUM is about dynamic discovery of the terminating carrier's preferred call termination paths that bypass the imposed inter-carrier SS7-defined paths across the PSTN, and, consequently, it's about creating sufficient impetus to re-define inter-carrier call accounting settlement regimes and related call termination fees. The essential characteristic of infrastructure ENUM is that its all about describing entire E.164 carrier number blocks, rather than opted-in individual end user's numbers, and it's motivated by redefining the financial aspects of inter-provider arrangements, rather than publishing the end user's individual preferences.

Infrastructure ENUM is ideal for competitive voice carriers to announce to other carriers a collection of rendezvous points for termination of services that relate to calls made to numbers within their number blocks. Infrastructure ENUM is logically populated by number blocks rather than individual numbers, for which the carrier is the nominated carrier of record. Infrastructure ENUM allows carrier to announce the services that the carrier is willing to terminate and the associated rendezvous points that will perform service termination. It allows the carriers to undertake call service termination bilaterally, removing any third party intermediaries from the picture, and also removing any associated forms of call termination fees and call accounting settlements that these intermediaries would normally impose on these competitive carriers. This is why Infrastructure ENUM, or I-ENUM, is a topic of persistent interest in this industry.

I-ENUM

The promise of I-ENUM is best seen with an example. Imagine that you are a PSTN carrier that supports IP-based services internally, and you are using E.164 numbers for called party identification when undertaking service completion operations. So VOIP, MMS, SMS, and so on, are all terminated to a a service termination point using E.164 numbers as the lookup token into some service database. When presented with a call request then the only available database to consult is the E.164 number database, and to achieve this you need to launch an SS7 request, and you'll get back an E.164 record, a carrier of record for that number and a path to complete the call. But what if you don't like the answer? What if you with to use IP-based carriage services to bypass any intermediate PSTN carriers, and perform the call completion function directly with the terminating carrier, avoiding forced intermediate carrier-imposed settlement changes?

Here I-ENUM comes into play. I-ENUM is an ideal way for VOIP carriers to selectively announce to other VOIP carriers a set of rendezvous points for service termination. Its an implementation of an inter-carrier PSTN bypass, if you want to look at it that way.

Mechanically, the approach is to announce in some I-ENUM DNS domain the E.164 number block for which this carrier is the carrier-of-record, and populate this DNS zone with the description of the services that the carrier is willing to terminate, and nominate the IP rendezvous URI that performs service termination in the terminating carrier's network.

So it's the same ENUM technology, but now it's the carriers attempting to undertake the discovery and termination operation relative to the terminating carrier rather than relative to the end user. The operations are similar to ENUM, but translated into a carrier context:

• Identify the service being requested
• Lookup the called number in the I-ENUM DNS domain
• Select the terminating carrier's URI for a compatible terminating service entry that is published against an enclosing number block entry.
• Complete the call request using a service rendezvous operation


Figure 1 - Infrastructure-ENUM and User-ENUM

It appears that what carriers want from ENUM is the ability to selectively disclose E.164 called numbers to nominated terminating service bindings that are accessible to certain other carriers at specified rendezvous points. They would like this disclosure to be under the full control of the terminating carrier, and that the information disclosed by the terminating carrier to be relative to a nominated carrier's query, rather than being a unilateral act of publication for any party to query. In other words they would like the answer to be variable, depending on the party making the query. They would like number blocks to be described via this mechanism, and the publication framework to be maintained with a minimal provisioning overhead and minimal operating expenditure. What the carriers want is for the originating and terminating carriers to be jointly in full control of their service interconnection policies, and for the products of these policies not to be unnecessarily exposed to a wider audience. So neither the number blocks, the services, the rendezvous points or the bilateral interconnection arrangements are necessarily to be exposed to a wider audience here.

Implementing I-ENUM

It appears that the industry knows, roughly, what it wants, but the means of achieving it are not so clear.

The approaches to I-ENUM appear to be along the lines of:

• splitting the existing ENUM DNS delegation hierarchy into multiple trees close to the root of the hierarchy and operate ENUM and I-ENUM as parallel and distinct hierarchies, or
• work at the ENUM terminal point and enrich ENUM with further DNS Resource Records and query sequences, or
• use 'private' ENUM contexts.

A - Splitting the DNS ENUM hierarchy

This approach to Infrastructure-ENUM uses the same NAPTR DNS Resource Record entries as User-ENUM, and uses the same general lookup mechanism to resolve a called number to a collection of URIs. Here the regular expression substitution capabilities of NAPTRs can be used to take a general NAPTR resource record form and generate a called-number specified rendezvous URI to perform call completion.

This approach has no change to ENUM Resource Records, no change to NAPTR capabilities, and no change to the operation of the DNS. It just relies on a split ENUM DNS hierarchy, as indicated in Figure 2, where a new DNS tree, named something like "ie164.arpa" would hold I-enum records, while leaving "e164.arpa" to continue to contain User ENUM records.


Figure 2 - Split ENUM hierarchy for I-ENUM

And here's where the problems start!

The e164.arpa ENUM hierarchy was a significant challenge to all concerned. Representing one realm's identity space within another quite distinct identity realm is invariably ill-advised, and more so when the political framework that governs to two realms differ markedly. The E.164 number space has its challenges, where, oddly enough, "countries" are sometimes difficult to define and difficult to deal with.

The classic example of the "country problem" in the E.164 context is Taiwan. Yes, you can place a phone call to a Taiwanese number in most parts of the world, but you'll not find the country "Taiwan" listed in the E.164 number plan under any alias whatsoever. Its just not there! And its not in ENUM as a consequence of the ITU-T and IETF arrangements over ENUM governance that allow the ITU-T the right of veto over the inclusion of country code entries in the e164.arpa DNS space. So how can country dial code for Taiwan exist within the PSTN, yet be completely excluded from ENUM? The answer is that the nature of the inter-governmental treaty arrangements that lie behind the ITU allow some member states to exercise a veto on the recognition of others as peer member states, and Taiwan is the subject of such a veto. In the PSTN world this is not exactly an insurmountable problem, in that PSTN operators can add additional configuration entries into their international switches that in essence 'synthesise' Taiwan as if it had its own country code. And by some coincidence almost every country has decided to use the same E.164 country code. The DNS is not so flexible in this respect and a similar approach to mapping +886 into 6.8.8.e164.arpa using informal local arrangements simply does not work that way!

So if ENUM has presented some particularly tough challenges, why would I-ENUM be any easier to construct? Why is there a need to create a second DNS hierarchy that maps from E.164 to DNS resource records? Why does this require the involvement of member states of the ITU-T? Why would any service provider ask for higher levels of government intervention and regulatory control in competitive signalling infrastructure? The question is relevant because the use of "ie164.arpa" for I-ENUM will require government approval and involvement, and in deregulated regimes this is precisely the opposite of the current regulatory direction.

Another aspect of the emerging service industry is that there is no longer a uniform scenario of monolithic all-inclusive service providers, and instead we have a variety of actors, some of whom specialize in offering only a small selection of services. If we want to preserve user choice here then we probably need to get back to addressing the basic ENUM problem of many hands wanting to edit the same DNS zone file. If we don't wish to bias I-ENUM for this monolithic single vertically integrated service provider world then you have the problem of multiple service entities wanting to maintain their service record within the same DNS zone file. So the basic question here how do you know that 2 DNS "trees', namely e164.apra and i164.arpa, are enough? And if not, then how many trees really is enough? Who gets to make that decision? We have been here before, by the way, and in that case ENUM was seen as being the solution, not the problem!

Earlier work in this space by Marshall Rose in 1992 used the same approach of placing rendezvous information in the DNS, using a transformed E.164 number as the lookup key into the DNS hierarchy rooted at "tpc.int". Here the exercise was not call termination, but fax termination, where the A record in the DNS mapped to an internet termination point was capable of completing the 'last mile" as a true fax. A messaging paging service was later added using a new hierarchy of E.164 numbers, in a tree rooted at "pager.tpc.int". The implication was that each additional service implied a need to create and populate a new DNS tree of the form <service>.tpc.int.
 
ENUM was a way of combining all these service-specific DNS hierarchies into a single number hierarchy, where the services are placed in resource records at the leaves of the tree, rather than creating a multiplicity of service-specific trees.

It seems to me that ie164.arpa, and its variants that also rely on a split of the DNS tree, is not really an answer to the carrier's needs in this space. It manages to bring back into focus the relatively ad-hoc arrangements between the IETF and the ITU-T that did resolve the situation in terms of control of the number space to any party's satisfaction, without any new insight that might make this task more straightforward the second time around, and contains no promises that this won't occur a third time, or even more!

It appears, sensibly, that we are somewhat reluctant to simply repeat the mistakes of the past, and the concept of multiple instances of the entire E.164 number space in the DNS is not one that looks like it is the most appropriate way of supporting I-ENUM. But we are nothing if not endlessly creative, and the next proposal is that each national regime start its own infrastructure enum hierarchy just below the country code. So if you happen to look at Australia (E.164 country code of 61), then the enum DNS delegation tree is a 1.6.e164.arpa, and the infrastructure enum tree for Australia would be rooted at "infra.1.6.e164.arpa." Of course not every country code in the E.164 recommendations is a two digit code. The North American numbering plan uses the E.164 code is 1, while many other countries use a three digit code. Aside from loading static tables (something we are trying to avoid in this entire dynamic information discovery domain), how do you know which country code is of which length? And would every national regime use the English abbreviation "infra" to label its infrastructure ENUM hierarchy?

B - More games with NAPTRS

It appears that the "ie164.arpa" is incapable of meeting all the various service-specific requirements that may arise from I-ENUM, and that a more general approach is a collection of DNS hierarchies of the form 164.arpa. But this is also a relatively unattractive solution, in that it tends to create more and more DNS hierarchies.

The original ENUM concept was to compress these multiple trees into a single instance and use a set of NAPTR resource resources to describe the set of services associated with an E.164 number. Could this be extended to include I-ENUM requirements? The idea here is that the service records are not placed in a single DNS zone file, but are themselves further points of delegation, allowing the user to delegate DNS zones for individual services.

There is a proposal intended to achieve precisely that by introducing a number of modifications to the syntax and semantics of the NAPTR DNS resource records to allow for NAPTR records that point to further delegation zones rather than terminal entries. This is intended to allow a leaf ENUM zone file to contain service-specific entries that in turn point to service-specific DNS zone files. This allows a distinction to be drawn between the queries of what services are associated with a particular E.164 number and what URIs are the rendezvous points for these services. An example of this approach is shown in Figure 3.

DNS information

    $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!"  .
      NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!"   .

      NAPTR 10 100 "d" "E2U+sip" "" 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 10 102 "d" "E2U+msg" "" 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.

    $ORIGIN _e2u.3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      _sip   NS  sipservice.example.com
      _msg   NS  mailservice.example.com

    $ORIGIN _sip._e2u.3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      . URI 10 10 "sip:info@example.com"
      . URI 10 10 "sip:info@example2.net"

    $ORIGIN _msg._e2u.3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      . URI 10 10 mailto:info@example.com


Figure 3 - Delegated service rendezvous descriptions in the DNS

What this ends up is still a rather unsatisfying compromise. On the positive side this approach avoids endlessly replicating ENUM delegation trees for each service type, and it avoids the administrative problem of multiple service providers attempting to edit the same single DNS zone file, which, in general is Good. On the other hand this does represent more load on the DNS, with yet another Resource Record type (the URI type) and another layer of indirection when attempting to query the DNS, which is Not So Good. However, it still exposes the inter-carrier service rendezvous points to public view and exposes inter-carrier signalling to public view, which is probably Bad. It requires the inter-carrier information to be placed at the leaf of the ENUM delegation tree, and not at the higher point in the delegation tree that corresponds precisely to the carrier's number block, and this is just plain Ugly!

As far as I can see, both these approaches fail in critical ways. If the desire from I-ENUM is the ability to perform selective disclosure of information then these approaches simply fail to meet that objective. From the carrier's perspective there is an evident aversion to make this inter-carrier service termination information generally available to the public because of the ever-present risks of exposing the service to denial of service attacks and attempts to subvert the service. And the desire to disclose responses that may vary according to the carrier performing the query is to implement bilateral interconnection policies that may entail different services being exposed to different carriers.

So is I-ENUM looking for answers in all the wrong places? Is DNS just the wrong tool to implement these requirements?

Perhaps not, but here we need to consider the differences between "public" and "private" DNS capabilities.

C - Private I-ENUM

Another approach to the I-ENUM requirement is to use ENUM technology, but base this upon a private DNS structure that is not part of the public DNS hierarchy. There is no doubt that as far as distributed databases go DNS is a remarkably slick, efficient and cheap solution, and possibly it really the best in its class. So if the problem is just the "public" part of the public DNS, then another approach is to continue to use the DNS, but use a private DNS hierarchy.

Private DNS allows each carrier to craft its DNS advertisement to suit individual interconnection arrangements, and through DNS filters and DNS selective response generation only divulge information to the correct querying party and only expose service rendezvous points according to the associated interconnection policy with the carrier in question. This approach does not require any additional DNS Resource Records, nor does it create a multiplicity of service-specific ENUM DNS hierarchies, nor does it create the situation of multiple distinct service providers all attempting to edit parts of a single DNS zone file. Just as critically, private DNS approaches can be accompanied by various forms of restricted access to the DNS service. The implication is that service rendezvous points are not unilaterally published in a relatively hostile world. The service rendezvous points, and the number blocks under the control of each carrier are not implicitly passed into the public domain through use of private ENUM.

There is no compelling need to have inter-carrier service termination information made public through a public DNS I-ENUM model, and there are strong arguments why the opposite approach of private bilateral information exchange is a better fit to the actual inter-carrier industry dynamics here. It should come as no surprise to learn that in this space I-ENUM as a private DNS solution is already replete with vendors, products, customers and carrier users.

I-ENUM and The Standards Perspective

The IETF's ENUM Working Group has been considering I-ENUM for some years, taking the general approach of adapting the User ENUM structure in e164.arpa as the starting position. This activity has served to highlight the observation that the requirements for end user preference settings in U-ENUM are intrinsically quite different for carrier interconnection policy expression in I-ENUM. The general directions of the ENUM WG's efforts to resolve this difference between the ENUM requirements are described above. Interestingly, the ie164.araa-styled approach using a Branch Location Record remains a Working Group item, and appears to have reached a consensus position in the Working Group. The next step is that of publication as a Proposed Standard in the IETF.

But if the industry's preferred approach truly lies in the direction of private DNS approaches then this calls into question the potential role of the IETF in defining technology to support the information exchange between various forms of service providers. Should the IETF embark of a rather difficult path to standardize a second E.164 hierarchy within the DNS and once more embark on a rather complex conversation with the ITU-T over relative roles and responsibilities for this administration of this second ENUM domain? Should the IETF embark of standardization of an information model for carrier inter-connection that has some distinct implications on the types of inter-connection arrangements that can be supported within this standards framework? Who should be setting business roles for carrier-to-carrier interconnection? Is this logically or practically within the purview of the IETF?

This appears to be a case where standards cannot provide a complete framework in addressing the various requirements and managerial perspectives where the DNS and the E.164 identity spaces are made to intersect. While technology folk can reach a consensus position that a particular technology is viable and can produce running code, the ultimate acceptance of that standard by industry players relies on the additional constraint that the standard serves a real need, and does so in a manner that at the very least does not constrain the actions of these industry players.

Perhaps the problem is actually with the industry itself, and the underlying extent of the changes that are happening within the industry as VOIP-based competitive carriers grow into being significant players in the voice market.

The Emerging Realities of the Global PSTN Industry

If the competitive VOIP-based voice carriers can leverage VOIP and Infrastructure ENUM to dismantle the dominance of the conventional regulatory-inspired call termination paths and the associated inter-PSTN operator call accounting regimes then it is possible that we will witness a "perfect storm" for the traditional PSTN providers.

VOIP providers are completely uninterested in "call minutes". The revenue stream from the customer comes in the form of a fixed monthly fee, and in this environment variable costs are unacceptable. Consequently the VOIP carriers are demanding "bill and keep" arrangements as opposed to call minute-based inter-carrier compensation. The additional motivation here is that not only does call accounting introduce variable costs into a fixed revenue business sector, but the costs imposed on the industry to perform this form of financial settlement range from the sublime to the outrageous!

So it is possible that the combination of VOIP, Infrastructure ENUM, end-to-end IP carrier-to-carrier services without forced PSTN intermediation, bill and keep services, the avoidance of SS7 and PSTN transit paths all combine to make a mutually supportive set of factors that just might force the residual PSTN carriers completely out of the voice market. This indeed would be a revolutionary outcome for the Infrastructure ENUM effort!

Disclaimer

The above views do not necessarily represent the views of the Asia Pacific Network Information Centre.

About the Author

GEOFF HUSTON holds a B.Sc. and a M.Sc. from the Australian National University. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of a number of Internet-related books, and is currently the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He was a member of the Internet Architecture Board from 1999 until 2005, and served on the Board of the Internet Society from 1992 until 2001.

www.potaroo.net