Table of Contents
Advertisement
Comprehensive ENUM Management with Alcatel-Lucent's VitalQIP ENUM Manager
Comprehensive ENUM Management
ENUM extends the existing infrastructure by adding support for additional types of services in the DNS.
This is accomplished through supporting NAPTR records in DNS. Support for NAPTR records in DNS
is natively supported in BIND. As such, compliant DNS applications using the appropriate BIND version,
technically support ENUM. However, in order to effectively and efficiently manage ENUM services,
additional functionality is required of the management platform. Any complete ENUM management
solution must support the administration of both ENUM domains (e.g., 1.my-enum.com) and the NAPTR
records in both the application's database and the corresponding DNS/ENUM servers.
NAPTR records are supported by BIND, but entering and managing the NAPTR records can be cumbersome.
Simply entering and formating the regular expression field can be a cause of major concern. The syntax
of the regular expressions lends itself to be error prone if configured manaually. In almost every
enterprise, and certainly all service providers, a data store of some type exists. In this data store,
employees' or subscribers' contact information is stored. A method to extract bulk contact information
and populate the ENUM database is required to facilitate rapid service turnup. In addition to the bulk
interface, an open interface to existing provisioning applications is needed to properly function in
some service providers' networks, such as an IMS network. Once the records are imported into the
ENUM application the ability to modify the NAPTR records is needed. In the event neither the bulk
interface or provisioning interface are used, NAPTR records must be manually created, deleted, and
modifed. A user-friendly GUI enables manual configuration of the essential parameters to be quickly
accomplished. The GUI should provide the capability to automatically create the regular expressions
as required and provide a level of error checking/validation during the process.
Proper management of the ENUM domains is a mission critical function. ENUM services are expected
to significantly increase the DNS management burden. When choosing an ENUM management platform,
the initial consideration should center around the application's DNS management capabilities. If the
vendor's DNS management platform is limited, chances are ENUM management will also be severely
limited. The ENUM management platform must contain the capability to split and merge ENUM domains
to manage the size of ENUM zone files used in DNS servers. By the very nature of the ENUM domain
structures, the ability to split the domains is supported, however not easily. The following NAPTR record,
which initially exists in the my-enum.com zone, will be used to illustrate splitting ENUM domains.
4.4.4.4.3.3.3.2.2.2.1.my-enum.com. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@tele2.se!"
In the above record, starting from the left the first 11 digits represent the primary phone number.
The record can be split at any decimal as each decimal represents a level in the DNS/ENUM hierarchy.
One logical method to distribute and manage NAPTR records is to split the original my-enum.com
zone into individual zones by country code, and then by area code. Consequently, in this example,
the following zones would be created:
Records for other area codes could remain in the 1.my-enum.com zone, or, when appropriate, zones
could be created for some or all of them.
Not only should the ENUM application be able to split ENUM zones, but merging ENUM zones is
required. The ability to split and merge ENUM zones provides flexibility to ENUM administrators to
manage the size of ENUM zone files for best performance.
1.my-enum.com. (This zone is used to manage country code 1.)
2.2.2.1.my-enum.com. (This zone is used to manage area code 222.)
Alcatel-Lucent | ENUM Use and Management for the Successful Deployment of ENUM-Enabled Services
7
Advertisement
Table of Contents
