One document matched: draft-ietf-enum-operation-00.txt
Telephone Number Mapping A. Brown
Internet Draft Nortel Networks
Document: <draft-ietf-enum-operation-00.txt> Greg Vaudreuil
Lucent Technologies
July 13, 2000
ENUM Service Specific Provisioning:
Principles of Operation
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.
This document updates the earlier draft-vaudreuil-enum-e164dir-
01.txt.
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.
Telephone Number Based Directory Services July 2000
Table of Contents
1. Abstract........................................................1
2. Introduction....................................................2
3. Scope...........................................................2
4. Overview........................................................3
4.1 First Level: Determining the Delegated Authority...............3
4.2 Second Level: Determining the service registrar and retrieving
Resource records...................................................5
4.3 Third Level: Service-Specific..................................5
5 Illustrative System Examples.....................................7
5.1 Example: Hypothetical Reachme Service..........................7
5.2.3 Example: SIP Call Setup Service Request......................9
6. Security Considerations........................................10
7. References.....................................................11
9. Acknowledgments................................................11
10. Author's Addresses............................................13
11. Full Copyright Statement......................................14
Appendix: changes from draft-vaudreuil-enum-e164-01.txt...........15
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 the address of a service
specific directory or where applicable for a given service, directly
into a service-specific endpoint addresses.
This directory service uses the algorithms and methods described in
draft-faltstrom-e164-06.txt.
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.
Telephone Number Based Directory Services July 2000
4. Overview
This phone number based directory system implements a three level
information model, the first two constitute the ENUM service itself.
This model is based on analysis of pre-existing administrative
structures, generalized service requirements, andthe capabilities of
candidate protocols.
The first level is the mapping of the telephone number delegation
tree to the authority to which the number has been delegated.
Conceptually thisdelegated authority knows nothing about service-
specific information associated with the telephone number but can
provide a reference to the appropriate entity that does know.
The second level is the provision of the requested DNS resource
records from a service registrar. Because there may be multiple
service providers for a given telephone number, conceptually this
registrar of services assumes a role of managing service
registrations and arbitrating conflicts between service providers.
Where this services registrar is different from the delegated
authority, a query redirection from the delegated authority to the
name server of the service registrar for a given telephone number is
necessary
The third level is the provision of service specific data from the
service provider itself. Where necessary for a given service, this
level provides specific attributes including any necessary
attributes to place a call, route a message, validate capabilities,
or other data necessary for that service that are known only to the
provider of that specific service.
4.1 First Level: Determining the Delegated Authority
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 referral in DNS. From the
client's perspective, this level is transparent, bundled within the
query for the service-specific resource records stored at the second
level.
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 publicly
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
Telephone Number Based Directory Services July 2000
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.
The Internet Domain Name System provides an ideal technology for the
first-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.
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 arbitrarily 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 canonical E.164 number.
Within this delegation flexibility, 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 arbitrary 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 extension" within numbering plans.
The telephone number delegation information changes infrequently.
However, when a change to this data is made, the information must be
rapidly propagated through the directory system. Inconsistencies
between the authoritative 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
DNS servers that use rapid replication techniques to ensure the data
is consistent.
Telephone Number Based Directory Services July 2000
The mechanics of the ENUM service are specified in [faltstrom]
4.2 Second Level: Determining the service registrar and retrieving
Resource records.
The second level uses MX or SRV RRs to discover the NAPTR RRs to
discover the URL for other service- identity of the appropriate
service-specific directory such as an LDAP directory server, H.323
gatekeeper, or specific endpoint addresses.
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 a
deterministic 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 well-known example 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 routing. It is
important that the costs of providing a dynamic service at this
level are limited to the second-level service registrar provider and
do not impose a burden on clients or the first level telephone
number registrar.
The DNAME and CNAME records provide the redirection from the
designated authority to the service registrar. The DNAME provides a
means for reforming and re-issuing a query for a "non-terminal"
domain name. As is standard for compliant DNS resolver libraries,
clients must support the CNAME record type. Servers that provide
for substitution MAY support the DNAME record to provide redirection
for an entire telephone number range as a DNS sub-tree. These
servers MUST provide synthesized CNAME records for the proper
operation of older resolver libraries that have not been extended to
understand DNAME. Servers that redirect queries on a per-telephone
number basis MUST support CNAMES.
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
Telephone Number Based Directory Services July 2000
important that as little coordination as possible be required
between the directories of innovative and potentially competing
service-specific providers.
Telephone Number Based Directory Services July 2000
5 Illustrative System Examples
5.1 Example: Hypothetical Reachme Service
The following hypothetical 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.
2.1.2.1.5.5.5.6.1.3.1.e164.arpa
Sample configuration file for the top level delegations from ITU:
1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel
Sample configuration file for numbers delegated from the NANP node
in the DNS tree:
5.5.5.3.1.6.1.e164.arpa. IN NS ns.ServiceProviderA.net.
;for +1 613 555 XXXX
In this example, ServiceProviderA.net is the authority to which the
telephone number has been delegated. ServiceProviderA.net provides
a non-terminal redirection pointer to Zcorporation, the designated
service registrar for the block of 100 numbers +1 613 555 12XX. The
configuration for this block of numbers is:
2.1.5.5.5.3.1.6.1.e164.arpa.
DNAME 2.1.5.5.3.1.6.1.Zcorporation.com.
Zcorporation provides the following service specific record for all
telephone numbers within it's 100 number block:
*.2.1.5.5.3.1.6.1.Zcorporation.com. SRV ldap1.Zcorporation.com.
weight=10, preference =10, port = 389
Assuming the resolver is using non-extended DNS, the query using
telephone number +1 613 555 1212 for the _reachme service is as
follows:
Query: _reachme._tcp.2.1.2.1.5.5.5.3.1.6.1.e164.arpa.
Response: Name=__reachme_tcp.2.1.2.1.5.5.5.3.1.6.1.e164.arpa
CNAME=2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com
SRV=ldap1.Zcorporation.com weight=10 preference=10
port=389
Telephone Number Based Directory Services July 2000
The client can then use LDAP with the reachme schema to determine
the set of communications technologies available for +1 613 555
1212.
Telephone Number Based Directory Services July 2000
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.arpa. IN NS ns.NANP.phone.net. ;for NANP
3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
2.7.9.e164.arpa. 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.arpa. IN NS ns.972555Port.NANP.phone.net.
;for 972 555
The number portability authority manages the delegation on a per-
telephone number basis. Logically, the ns.972555Port.NANP.phone.net
has the following record for the telephone number.
3.1.3.1.5.5.5.2.7.9.1.e164.arpa. IN NS
ns.ServiceProviderB.net.
;for 972 555 1313
ServiceProviderB records the designated service registrar for the
telephone number as itself and hosts the service records directly
without using a DNAME record.
3.1.3.1.5.5.2.7.9.1.ServiceProviderB.net.
SRV sipgw1.ServiceProviderB.net.
weight=10, preference =10, port = 389
;for 972 555 1313
The DNS Query and response using telephone number +1 972 555 1313:
Query: _sip._tcp.3.1.3.1.5.5.5.2.7.9.1.e164.arpa
Result: name=__sip._tcp.3.1.3.1.5.5.5.2.7.9.1.e164.arpa
SRV=sipgw1.ServiceProviderB.net weight=1
preference=10 port=389
The client can now use the SIP protocols to contact the SIP gateway
to initiate a phone call.
Telephone Number Based Directory Services July 2000
6. Security Considerations
The following are known security issues taken into consideration in
the definition of this directory service.
1. 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 misdirected to the
wrong carrier. As sub-delegations are implemented, the risk that
phone numbers delegated to one enterprise may be incorrectly
pointed at another will increase.
3. Service providers operate in a regulated environment where certain
information about 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 individual
service providers to not disclose this information outside of
their control.
Telephone Number Based Directory Services July 2000
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
[DNAME]
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 July 2000
this service using actual data for the North American Numbering Plan
numbering region.
Telephone Number Based Directory Services July 2000
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 July 2000
11. Full Copyright Statement
"Copyright (C) The Internet Society (2000). 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 implementation 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 July 2000
Appendix: changes from draft-vaudreuil-enum-e164-01.txt
o The examples were updated to reflect the E164.arpa domain name
o Various examples were corrected
o The SIP examples were harmonized with expected SIP usages
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:37 |