HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:02:22 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 09 Mar 2000 16:26:00 GMT ETag: "3ddb7a-8798-38c7d098" Accept-Ranges: bytes Content-Length: 34712 Connection: close Content-Type: text/plain Telephone Number Mapping A. Brown Internet Draft Nortel Networks Document: Greg Vaudreuil Lucent Technologies March 7, 2000 Telephone Number Based Directory Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. Table of Contents 1. Abstract........................................................1 2. Introduction....................................................2 3. Scope...........................................................2 4. Overview........................................................2 4.1 First Level: ENUM Service......................................2 4.2 Second Level: Service-Specific Repository Discovery............4 4.3 Third Level: Service-Specific..................................4 5 System Description...............................................4 5.1 Telephone Number to Domain Name Mapping........................6 5.1.1 Example: Simple Service Requiring Only First Level Query.....7 5.2 Service Specific Repository Discovery..........................8 5.2.1 Example: Hypothetical Reachme Service........................8 5.2.2 Example: Hypothetical Voicemail Service......................9 5.2.3 Example: SIP Call Setup Service Request.....................10 Telephone Number Based Directory Services March 2000 6. Security Considerations........................................11 7. References.....................................................12 9. Acknowledgments................................................12 10. Author's Addresses............................................13 11. Appendix 1: ENUM in the North American Numbering Plan.........14 2. Introduction This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. This is the first of a document set describing a converged proposal merging the directory work led by Anne Brown through the VPIM initiative within the Electronic Messaging Association (EMA) and the directory work initiated by Greg Vaudreuil within the TeleMessaging Industry Association (TMIA). Please send comments on this document to the ENUM working group. 3. Scope This document defines the architecture and mechanics necessary to implement a telephone number based Internet directory system. This solution enables an extensible set of services to be provided for a given telephone number. Example services may include IP telephony, Internet Fax, VPIM voice messaging, Internet paging, geographic phone location, and others. Each service is to be separately defined and identified using a unique, registered service identifier. This document does not specify the particulars of any telephone number based service. In particular, it does not describe how phone calls are placed, routed, or terminated or how voice messages are routed. 4. Overview This phone number based directory system implements a three level architecture, the first two of which are the ENUM service itself. This model is based on analysis of pre-existing administrative structures, generalized service requirements, and candidate protocol capabilities. 4.1 First Level: ENUM Service The first level is the mapping of an E.164 formatted international telecommunication number into an Internet domain name identifier. This may or may not involve more than one referal in DNS. From the clients perspective, this will appear as one query. The resulting Telephone Number Based Directory Services March 2000 domain identifier indicates either the authority to which the phone number has been delegated, a sub-delegated authority (e.g., a private enterprise), an individual to which a telephone number has been assigned, or a service provider acting on behalf of one of the above. The domain name that is returned in an ENUM query will depend on existing and evolving business and regulatory agreements. This ENUM architecture supports a number of different possible arrangements which may occur. The delegation of telephone numbers from the root authority (the ITU) down to individuals is a well-established system that can be utilized. These telephone number registrars have a trusted relationship with their delegated carriers or subsidiary registrars; a valuable asset to ensure protection against various attacks. Note that in this model, the delegation of telephone number blocks or individual numbers to a corporation or to an individual can be administratively and technically modeled as a sub-delegation to another carrier. With that additional information publically registered, the mapping between telephone number and these domain names can be provided by any neutral entity. The delegated authority, sub-delegated authority, or individual may arrange to have a third-party (e.g., a service provider) list their information. In this case the service provider's domain would be returned in the ENUM query. This approach differs from Patrik's [FALTSTROM] proposal in that it assumes that service information and per-resource based information (e.g. individual email addresses, sip addresses, etc.) will be held privately and not in the ENUM top level service. This approach also differs from Patrik's in that it recognizes that other protocols besides DNS may be used in satisfying service-specific queries for information on a particular telephone number. DNS is often not appropriate for maintaining information (such as email addresses) on a per resource basis [URN-DNS-01]. It is understood that each service type (and its related protocols) can define its own methods (including DNS, if deemed effective) for accessing information on resources related to that particular service. The telephone number delegation information changes infrequently. However, when a change to this data is made, the information must be rapidly propogated through the directory system. Inconsistencies between the authorative data and cached data may result in loss of service, mis-routing of communications, and/or service loops. An effective ENUM service requires that DNS time-to-live fields be set to an appropriate value consistent with the telephone number reassignment policies if the delegating authority. For example, ported telephone numbers may be reassigned from one carrier to another, a change that must be made quickly to avoid routing loops. Records supporting that service require a TTL of Zero and secondary Telephone Number Based Directory Services March 2000 DNS servers that use rapid replication techniques to ensure the data is consistent. 4.2 Second Level: Service-Specific Repository Discovery The second level uses SRV RRs to discover the identity of the appropriate service-specific directory such as an LDAP directory server, H.323 gatekeeper, or other service-specific repository type. In this proposal, the second-level service registrar is responsible for ensuring that multiple services may be provided on behalf of a single telephone number, potentially by different service providers. This function includes an arbiter function to ensure that there is exactly one instance of any given service assigned to a single telephone number. The service-specific directory locator function is a new service modeled upon existing telco service provisioning models. Long-distance carrier selection within the United States is one current instance of a service-specific registration requiring an arbiter function within the current network. The rate of change for the second level, service location function may range from static through dynamic under the control of the entity to which the phone number has been delegated. A registrar in the public network may wish to make this information relatively static to take advantage of DNS query caching, while a corporation may be willing to accept a higher query load to provide a dynamic service such as time-of-day inbound service provider selection. It is important that the costs of providing a dynamic service at this level are limited to the second-level directory service provider and do not impose a burden on clients. 4.3 Third Level: Service-Specific The third level is the query of the service-specific directory for service-specific information. This third level is specific to the service and is to be described in service specific documents. The service specific directory is expected to be dynamic. It is important that as little coordination as possible be required between the directories of innovative and potentially competing service-specific providers. 5 System Description The Internet Domain Name System provides an ideal technology for this high-level directory due to its hierarchical structure, fast connectionless queries, and distributed administrative model. Earlier experimentation with the TPC.INT remote printing experiment has shown how the hierarchical assignment of telephone numbers can be mapped directly to the hierarchy of domains within the DNS. The ENUM directory uses that approach to map any arbitrary telephone number into a single domain name. Telephone Number Based Directory Services March 2000 ITU standard E.164 defines the structure of the public telephone number as follows country code, followed by nationally significant part, followed by sub-address. The country code may be from one to three digits, and the total length may be up to 15 digits. The nationally significant portion may be arbitraily divided on any number boundary. In many countries numbering plans, the divisions are not uniform, that is, the "Area codes" or "City codes" may be of varying lengths within a single country and the total number of digits may be variable. Where supported by the relevant service, an optional sub-address of up to four digits may be utilized to designate an extension telephone number. Note that while sub- addressing is not well supported in GSTN calling, it is more widely supported for voice messaging. It is important to note that the national long-distance access or international dialing prefix sequence is not part of the cannonical E.164 number. Within this delegation flexiblity, it is always the case that the delegation of authority is always done left-to-right. With this assumption, a numbering tree can be built on a digit-by-digit basis that can represent any arbitrary hierarchical structure. DNS permits the delegation of authority on arbitary boundaries such that a delegation to country code "1", "44", and "972" can all coexist under a single numbering plan root. The same applies for "service selectors", "area codes", "city codes", "Line number", or "sub- address extensions" within numbering plans. The first tier ENUM service makes available the telephone number hierarchy into the domain name system. This is performed by splitting the full telephone number into single-digit units and treating each digit as a DNS domain-label. The result is prefixed to the "e164.int" domain lable. The DNS is thus queried by converting the dialed telephone number into a domain name and using that domain name to query for a record from DNS. The the single-digit separation of E.164 digits for lookup purposes was chosen for the following reasons: 1. Implementable by both DNS and LDAP and other repositories (at the same time, with partitioning depending on service and application requirements) 2. Allows lookups -vs- searching (both DNS and LDAP). A record or entry can be pin-pointed without white-pages type searching. 3. Supports distribution of E.164 resolution data by both blocks of numbers and by individual numbers. The strategy allows this distribution to be changed, when required, to reflect current realities. 4. Alleviates clients from having to know or be able to derive numbering plan structures and lengths (What a user types or dials is out of the problem scope) 5. Isolation from changes to numbering plan structures and lengths 6. Supports use of telephone number extensions, if required Telephone Number Based Directory Services March 2000 Implementation Note: A dropped UDP packet containing a DNS request or response and the subsequent retransmission of the query may result in higher than acceptable latency. Two stategies may help manage problem. The first is to set agressive time-out and retransmission parameters, potentially as littls as 500ms. Where high packet loss is expected, the client may send duplicate DNS requests to maximize the odds that one will suceed within the required timeframe. 5.1 Telephone Number to Domain Name Mapping For the purposes of discussion and example, this document assumes the e164.int domain as the root for the telephone numbering hierarchy. In operation, it can be something else to be determined later. The telephone number data to populate the highest level entries in ENUM is publicly available. The ITU maintains a list of country codes and the respective authorities that manage the sub-structure under countries. (Note that country code 1 is shared by several countries in what is referred to as "numbering plan area 1".) Within a given country, authority for telephone numbers may be further sub-assigned to individual service providers, corporatate, institutional, or individual customers, either in telephone number blocks or number-by-number. This delegation is typically private information maintained at each level of the delegation tree. Successful deployment of multiple services requires that service providers and number registrars make this information available via the ENUM directory service. The specifics of this sub-delegation are beyond the scope of this memo, but any such administrative solution is expected to work within this technical framework. There is a set of local number portability, personal number, and freephone solutions in use worldwide. While these particular solutions rely upon various mechanisms and may use various intermediate identifiers such as routing numbers or carrier codes, the result of any such address mapping can directly identifty the authority to which a particular number has been delegated. The ENUM service should meet the requirements of these services. The address resolution service makes available the telephone number hierarchy through the domain name system. This is performed by splitting the full telephone number into single-digit units and then treating each digit as a DNS domain-label. The DNS is thus queried by converting the dialed telephone number into a domain name and using that domain name to query for a record from DNS. The query simply requests the responsible domain for a given telephone number. This can be most simply provided by using the widely deployed DNS PTR resource record and applying it to this role. With the PTR, a query by a telephone number converted into a domain name form can return the domain name associated with it. Telephone Number Based Directory Services March 2000 Example: 1.e164.int 1.1.1.1.3.3.7.2.7.9 PTR ServiceProvider.net ; for +1 972 733 1111 1.1.1.1.3.2.8.4.1.2 PTR ServiceProvider.net ; for +1 214 823 1111 5.1.1 Example: Simple Service Requiring Only First Level Query For some services, the ENUM service may be sufficient to initiate an instance of service and the second and/or third level of the directory may be optional. In those cases, the service-specific directory locator may provide adequate information for the client to initiate successful communication. One example is a hypothetical service that uses SMTP for the transport mechanism and well understood rules for the construction of an SMTP address. For example, using a telephone number in the local-part and using the domain name from the first level query in the domain-part (e.g., service-abc=14161234567@bigco.com. The separate Mail Exchange (MX) service record provides adequate information to route the message once the email address has been constructed. This scenario would be useful in services such as the above, if additional information and capabilities were not required in order to send a message. An SMTP email address can be constructed by converting the dialed telephone number into its international form and concatenating it with the domain name returned in the PTR record from the DNS query. It is important to note that the national long-distance access or international escape sequence is not part of the canonical number. The "1" in the following example is the country code for the North American dialing plan. It is not the long distance access prefix commonly dialed in North America. Sample configuration file PTR RRs for the NANP node in the DNS tree: *.3.3.7.2.7.9 PTR ServiceProvider.net ;for 972 733 *.3.2.8.4.1.2 PTR ServiceProvider.net ;for 214 823 DNS query and response using telephone number +1 972 733 2722: Query: 2.2.7.2.3.3.7.2.7.9.1.e164.int for PTR Result: PTR = ServiceProvider.net Per the service definition for the abc service, the sender could subsequently send an email using the mechanically constructed address: svc-abc=19727332722@Serviceprovider.net In this example abc service assumes that serviceprovider.net is also capable of forwarding email addressed to it, a reasonable assumption for some classes of services. Telephone Number Based Directory Services March 2000 Note that this type of blind messaging scenario will not work if the domain that is returned in the ENUM query is not the actual domain name that is used in the smtp address of the intended recipient. 5.2 Service Specific Repository Discovery The second tier of the telephone mapping service identifies the appropriate service-specific directory server of the recipient domain. For this, the DNS provides an extension record called the service location resource record or [SRV]. This record acts like the heavily used MX record in providing a list of servers offering a given service to provide redundancy. Strictly speaking, this is not a new service, but a usage of the otherwise defined service location (SRV) extensions in the domain name system. The mechanics for locating services for well-known domain names is defined in [SRV]. This discussion is included as part of the document as an illustration of how it can be used to provide a multi-service directory system for telephone numbers. The service specific directory server is found by querying DNS with the domain name found in the address resolution step for SRV records and also using the telephone number and service type in the query. There may be one or more SRV records for one or more servers for redundancy and load sharing. These entries are expected to point to functionally equivalent services, not to indicate different service providers. It is the responsibility of the querying client to determine when to query an alternate server in the event that the preferred server is out-of-service based on the user interface latency requirements. Note that there can be only a single instance of a service for each telephone number. 5.2.1 Example: Hypothetical Reachme Service The following service enables an end-user to discover the various means by which she can reach a recipient represented by their corporate telephone number +1 613-555-1212 using the hypothetical "reachme" service. This service is hosted by directly by the recipient's corporation. The telephone number is transformed into a domain name form to be used in a DNS query. Sample configuration file for the top level delegations from ITU: 1.e164.int. IN NS ns.NANP.phone.net. ;for NANP 3.3.e164.int. IN NS ns.FR.phone.net. ; for France 2.7.9.e164.int. IN NS ns.il.phone.net. ; for Israel Sample configuration file for numbers delegated from the NANP node in the DNS tree: Telephone Number Based Directory Services March 2000 5.5.5.3.1.6.1.e164.int. IN NS ns.ServiceProviderA.net. ;for 613 555 XXXX Sample configuration for numbers sub-delegated from ServiceProviderA.net: *.2.1.5.5.5.3.1.6.1.e164.int. PTR Zcorporation.com. ;for 613 555 12XX First tier DNS query and response using telephone number +1 613 555 1212: Query: 2.1.2.1.5.5.5.3.1.6.1.e164.int. for PTR Result: PTR = Zcorporation.com The answer to this query would be authoritatively supplied by ns.ServiceProviderA.net The service-specific directory is then found by querying DNS for the SRV record associated with the service-specific directory locator domain name. Sample service-specific queries and responses: Query: _reachme._tcp. 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com Response: SRV=ldap.Zcorporation.net weight=10 preference=10 port=389 The client can then use LDAP with the reachme schema to determine the set of communications technologies available for +1 613 555 1212. 5.2.2 Example: Hypothetical Voicemail Service A hypothetical service, voicemail, using SMTP as its transport mechanism, which requires retrieval of the intended recipient's capabilities and spoken name before sending a message, would use all three tiers of the address resolution service to initiate a communication session. The phone number has been delegated to ServiceProvider.net but the voicemail service is provided by spa.com. Again, the transformed international form of the dialed telephone number is used in a DNS query for the PTR RR containing the domain name to which the number has been delegated. Sample configuration file PTR RRs for the NANP node in the DNS tree: *.3.3.7.2.7.9.1.e164.int. PTR ServiceProvider.net. ;for 1-972 733 *.3.2.8.4.1.2.1.e164.int. PTR ServiceProvider.net. ;for 1-214 823 Query and response using telephone number +1 972 733 2722: Telephone Number Based Directory Services March 2000 Query: 2.2.7.2.3.3.7.2.7.9.1.e164.int for PTR Result: PTR = ServiceProvider.net The service-specific directory is then found by querying DNS for the SRV record associated with the service-specific directory locator for the domain name. Sample service-specific queries and responses: Query:_voicemail._tcp.2.2.7.2.3.3.7.2.7.9.1.ServiceProvider.net Response: SRV=ldap1.spa.net. weight=1 preference =10 port = 389 SRV=ldap2.spa.net. weight=1 preference = 20 port=389 From this response, the client can make a voicemail specific LDAP query to ldap1.spa.net to retrieve the recipient capabilities and spoken name necessary to confirm the correct address entry before submitting the message for delivery. In this example, high availability is provided by deploying the LDAP servers in redundant sets. As per the SRV specification, these servers should be listed in the SRV records with various preferences The querying system should attempt a connection to the service- specific directory server with the lowest numbered preference. If it is down, the server with the next lowest preference should be contacted. 5.2.3 Example: SIP Call Setup Service Request This example provides resolution of a telephone number to the identifier for the SIP gatekeeper designated to support real-time calling (Sipphonecall) to 972 555 1313. The telephone number is part of a block of ported telephone numbers that have been ported out of the donor carriers block to another carrier. The telephone number is transformed into a domain name form to be used in a DNS query. Sample configuration file for the top level delegations from ITU: 1.e164.int. IN NS ns.NANP.phone.net. ;for NANP 3.3.e164.int. IN NS ns.FR.phone.net. ; for France 2.7.9.e164.int. IN NS ns.il.phone.net. ; for Israel Sample DNS configuration file for the ported number block serviced by the 972 555 number portability authority delegated from the NANP node in the DNS tree: 5.5.5.2.7.9.1.e164.int. IN NS ns.972555Port.NANP.phone.net. ;for 972 555 Telephone Number Based Directory Services March 2000 Therefore, the 1-972-555-xxx numbers have been delegated to the namserver operated by the authoritative body that owns 972555Port.NANP.phone.net. Logical DNS configuration for ported numbers sub-delegated to the nameserver for 972555port.NANP.phone.net: 3.1.3.1.5.5.5.2.7.9.1.e164.int. PTR ServiceProviderB.net. ;for 972 555 1313 First Tier DNS Query and response using telephone number +1 613 555 1212: Query: 3.1.3.1.5.5.5.2.7.9.1.e164.int for PTR Result: PTR = ServiceProviderB.net The SIP gatekeeper is then found by querying DNS for the SIP SRV record associated with the service-specific directory locator domain name. SIPphonecall service-specific queries and responses: Query: _sipphonecall._tcp.3.1.3.1.5.5.5.2.7.9.1.ServiceProviderB.net Response: SRV=sipgw1.ServiceProviderB.net weight=1 preference=10 port=100 The client can now use the SIP protocols to contact the SIP gateway to initiate a phone call. 6. Security Considerations The following are known security issues taken into consideration in the definition of this directory service. 7. Service provider customer information is very sensitive, especially in this time of local phone competition. Service providers require the maximum flexibility to protect this data. 2) Registration of a domain name for the telephone numbers delegated to another carrier may result in messages being mis-directed to the wrong carrier. As sub-delegations are implemented, the risk that phone numbers delegated to one enterprise may be mis-pointed at another will increase. 3) Service providers operate in a regulated environment where certian information about a subscribers must not be disclosed. Telephony services and Voice Messaging are subject to caller-ID blocking restrictions, restrictions normally enforced in the telephony network. No such protection is available on the Internet. The protection of this data is essential, but is up to the Telephone Number Based Directory Services March 2000 individual service providers to not disclose this information outside of their control. 7. References [DNS1] Mockapetris, P., "Domain names - implementation and specification", RFC1035, Nov 1987. [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, Nov 1987. [SRV] Arnt Gulbrandsen, Paul Vixie, Levon Esibov, "A DNS RR for specifying the location of services (DNS SRV)", Work in Progress [E164] ITU, "CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era." [TPC1] Malamud, Carl, Rose, Marshall, "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC 1530, October 1993. [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998. [SRV] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [Brown] Brown, Anne, "ENUM Requirements", work-in-progress, November 1999 [Faltstrom] Faltstrom, Patrick, " E.164 number and DNS", work in progress, January 2000 9. Acknowledgments This experimental directory builds upon the earlier work of: Carl Malamud and Marshall Rose in their TPC.INT remote printing experiment. Bernhard Elliot working with the TMIA has provided much of the organizational impetus to get this project moving, a substantial task given the sometimes slow and bureaucratic nature in the telephony business and regulatory environment. Dave Dudley and the Messaging Alliance (TMA) for their early work in pioneering a shared directory service for voice messaging and their continuing efforts to apply those learnings to this effort. Jeff Sherer and Mike Dimitroff of Lucent Technologies provided invaluable insight and review based on a prototype implementation of Telephone Number Based Directory Services March 2000 this service using actual data for the North American Numbering Plan numbering region. 10. Author's Addresses Anne R. Brown Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-765-5274 Fax: +1-613-763-2697 Email: ARBrown@NortelNetworks.com Gregory M. Vaudreuil Lucent Technologies, Communications Application Group 17080 Dallas Parkway Dallas, TX 75248-1905 United States Phone/Fax: +1-972-733-2722 Email: GregV@IEEE.org Telephone Number Based Directory Services March 2000 11. Appendix 1: ENUM in the North American Numbering Plan This section discusses the North American component of the ENUM service. Generalized discussion for other countries and areas needs to be provided. Within North America (Numbering plan area 1), the delegation of phone numbers to the NPA/NXX level is managed by the "Traffic Routing Administration" a cooperative agreement with Telecordia (http://www.trainfo.com). The delegations are made available in a quarterly publication called the Local Exchange Routing Guide (LERG). The LERG is available publicly for a nominal fee. The North American Numbering Plan (NANP) local routing information in the LERG database maps a telephone number prefix to an Operating Company Number (OCN). The OCN is the unique identifier of the local exchange operator that has received the telephone number delegation. This delegation does not change with LNP.Local number portability (LNP), as implemented in North America, sub-delegates numbers nominally assigned via number blocks to "donor" carriers. The LNP sub-delegation of phone numbers to carriers is managed by the Number Portability Administrative Center (NPAC) managed under contract by NeuStar (http://www.nanpa.com). While this data is also publicly available, it does require an agreement to receive real-time replication from the master database. This information can be represented in DNS form, although it may best be implemented by a DNS front-end to the LNP database rather than the normal DNS servers. The primary name server for the NANP can provide domain name services for the NANP based on a mapping between OCN and the domain name chosen by the operating company. The NANP DNS authority will maintain the registration of the domain name to OCN mapping. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Telephone Number Based Directory Services March 2000