Internet DRAFT - draft-brown-e164
draft-brown-e164
Anne Brown
Internet Draft Nortel Networks
Document: <draft-brown-e164-01.txt> October 1999
E.164 Resolution
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This paper addresses global access to address information and
additional subscriber and equipment information, given a telephone
number as input.
Table of Contents
1 Introduction 3
1.1 Problem Definition 3
1.2 Terminology 4
1.3 Definition Syntax 5
2 Proposed Solution 5
3 Functional Architecture 6
3.1 Functional Components 6
3.1.1 ITDSP Servers 6
3.1.2 Information Suppliers 7
3.1.3 Information Consumers 7
3.2 Interfaces 7
3.2.1 ITDSP/ITDSP Interface 7
3.2.2 ITDSP/Information Supplier Interface 8
3.2.3 ITDSP/Information Consumer Interface 8
4 Naming 8
Brown Expires April 2000 1
E.164 Resolution October 1999
4.2 LDAP, X.500 Distinguished Name 9
4.3 Others 9
5 Scope 9
5.1 Representation of Telephone Numbers 9
5.2 Path Selection 9
5.3 Privacy 10
5.4 Lookups -vs- Searching 10
5.5 Application-Specific Schemas 10
5.6 "911" Service 10
5.7 Number Portability 10
5.8 User Configurability 10
6 Example 11
6.1 BigCo as Information Supplier 12
6.2 BigCo as Information Consumer 12
7 Schema 13
7.1 Sub-Tree Node Naming Attribute 13
7.2 Structural Object Class 14
7.3 Name Form 14
7.4 DIT Structure Rules 14
7.5 Summary of Syntax Definitions 15
7.5.1 ASN.1 Definitions 15
7.5.2 BNF Definitions 17
8 Requirements 17
8.1 Geo-Political Boundary Independence 17
8.2 Trusted, Third Party, Top-Level Service Providers 17
8.3 Numbering Plan Independence 18
8.4 Lookups -vs- Searching 18
8.5 Multiple ITDSPs 18
8.6 Distributed Entries 18
8.7 Transparency 19
8.8 Access Methods 19
8.9 Additional Subscriber Information 19
8.10Path Selection (gwloc) 19
8.11Time to Market 19
8.12Dynamic Information 20
8.13Redirection 20
8.14Number Portability 20
8.15User Configurability 20
8.16Quality of Service 20
8.17Capabilities Discovery 21
9 Relationship to Other Protocols and Initiatives 21
9.1 TPC.INT 21
9.2 Path Selection (gwloc) 21
9.3 TIPHON Service Mediation Environment 21
9.4 SIP 21
9.5 Naming Authority Pointer (NAPTR) 22
9.6 Wide Area Service Location 22
9.7 DIAMETER 22
9.8 Global Electronic Directory Assistance 22
9.9 Yellow Pages Directories and Search Engines 22
9.10Directory Enabled Networks (DEN) 22
9.11IN SCP and ss7/Internet gateways 23
9.12TIPHON's Internet Country Code 23
Brown Expires April 2000 2
E.164 Resolution October 1999
9.14Presence Information Protocol 23
9.15Numbering Plans 23
9.16Common Indexing Protocol 23
10 Commercial Aspects 24
11 Security Considerations 24
12 Acknowledgements 24
13 Author's Address 24
14 References 25
15 Full Copyright Statement 26
1 Introduction
1.1 Problem Definition
There are many different scenarios of Internet Telephony
communications possible on the Internet, including VoIP, voice
messaging (VPIM), Internet fax, and videoconferencing. These
applications may be initiated between one or more devices on the
Internet (e.g., A and B in Figure 1), between one or more devices on
the PSTN (C and D) with the Internet as an intermediary, between an
Internet and a PSTN device or a combination of the above.
+---------+ ------------ +---------+
| +-----+ | ___( ) | +-----+ |
| | | |----------( )-----------| | | |
| +-----| | ( TCP/IP ) | +-----| |
+---------+ ( ) +---------+
+------------+ ( ) +------------+
| A | ------ ____) | B |
+------------+ (_______) +------------+
|
|
+--------+
| GW |
+--------+
|
|
------------
___( )
(-------) ( ) (-------)
/ \ ( PSTN ) / \
/ \----------( )------------/ \
/ C \ ( ) / D \
+--------+ ------ ____) +--------+
(_______)
Figure 1: Internet Telephony Scenarios
Brown Expires April 2000 3
E.164 Resolution October 1999
requirement to be able to obtain information before an Internet
Telephony interaction can be initiated. Such information might
include:
- Endpoint Address - address(es) of the intended correspondent(s)
(e.g., domain name or IP address, voice, fax or text messaging SMTP
address, etc.)
- Path Address- endpoint address(es) of gateways, gatekeepers or
other equipment that can be used to route the session to the
intended recipient.
- Additional Subscriber Information - including supported
capabilities, preferences, authentication, authorization, etc. It
may also include information about equipment, such as a fax machine,
that is shared by a group of subscribers.
- Server Address - address(es) of servers, such as LDAP
directories, SIP servers, gatekeepers, authentication servers, etc.,
that may be used to obtain some or all of the above information.
Along with the ability to be able to retrieve this information,
there are a number of additional related requirements, including
qualification of the query using additional input information,
multiple responses (e.g., return all addresses that apply), security
(including mutual authentication, non-repudiation, privacy and
integrity) and business grade requirements (including 99.9999% 24/7
availability, updates available within 5 to 15 seconds, and 50 to
100 ms query response times)
And fundamental to the provision of Internet Telephony information
is some back-end mechanism(s) for storing, maintaining, and
distributing this information. Some of the requirements for this
backbone infrastructure may include replication and distribution,
maintenance, security and business grade requirements such as
updates available within 5 to 15 seconds, and billions of entries)
1.2 Terminology
CIP Common Indexing Protocol
DAP Directory Access Protocol
DISP Directory Information Shadowing Protocol
DIT Directory Information Tree
GW Gateway
ITDSP Internet Telephony Directory Service Provider
LDAP Light-Weight Directory Access Protocol
NAPTR Naming Authority PoinTeR
RR Resource Record
VPIM Voice Profile for Internet Mail
"Must" or "Shall" - Software that does not behave in the manner that
this document says it must is not conformant to this document.
Brown Expires April 2000 4
E.164 Resolution October 1999
"Should" - Software that does not follow the behavior that this
document says it should may still be conformant, but is probably
broken in some fundamental way.
"May" - Implementations may or may not provide the described
behavior, while still remaining conformant to this document.
1.3 Definition Syntax
Attribute type and object class definitions for use with X.500 are
written using Abstract Syntax Notation One [ASN.1]. Equivalent
attribute type and object class definitions for use with LDAP are
written using the BNF form of AttributeTypeDescription and
ObjectClassDescription given in [LDAPATTRIB]. Lines have been
folded for readability.
2 Proposed Solution
A number of solutions, claiming to meet some or all of the above
requirements, have been discussed in various forums. These
solutions have ranged from using existing, severely limiting
mechanisms, to elaborate new schemes that cannot be reasonably
implemented and deployed in the near future.
The solution proposed in this paper addresses the problem of
global access to address information and additional subscriber
and equipment information, given a telephone number as input.
Retrieval of path address is outside the scope of this paper.
The directory structure provides clients with the ability to access
directory information, given only a telephone number. The directory
is structured according to the E.164 numbering plan, with each node
in the tree representing a single digit of an E.164 telephone
number. Given a telephone number, an LDAP or DNS query can pinpoint
an entry in the global tree. This structure allows Information
Consumers to retrieve information without having to perform a global
search for a telephone number and without having to understand
different numbering plan structures.
It can be implemented immediately at the enterprise, carrier and ISP
level, followed by a worldwide service with the help of third party,
trusted, top-level service providers.
Other numbering plans besides E.164, and other alphanumeric identity
structures, such as calling cards and user IDs, can also be
supported by similar tree structures .
3 Functional Architecture
Brown Expires April 2000 5
E.164 Resolution October 1999
3.1 Functional Components
The solution proposes three functional components.
Global E.164
Resolution Service
+----------+
| |
+----------+ |
| | |
| ITDSP(s) |--+
/| |\ Single Queries LDAP,
Replication (X.500 or LDAP),/ +----------+ \ DAP,DNS,http,[H.323
DNS Zone Transfer, CIP / \ RAS]) or Bulk Transfer
Proprietary Mechanisms / \(Replication, DNS, CIP
/ \Proprietary)
+-----------------------+ +-----------------------+
| | | |
+-----------------------+ | +-----------------------+ |
| | | | | |
| Information Suppliers |--+ | Information Consumers |--+
| | | |
+-----------------------+ +-----------------------+
ISPs, Carriers, Enterprises
and other service providers
Figure 2: Functional Components
3.1.1 ITDSP Servers
Internet Telephony Directory Service Providers (ITDSPs) are trusted,
third-party top-level service providers who will list information on
mapping from a telephony number to an endpoint address and/or
address(es) of servers that contain endpoint address and additional
subscriber and device information. This information will be mainly
collected from carriers, ISPs, enterprises and other entities based
on commercial service level agreements. ITDSPs will make this
information available to querying clients.
ITDSPs will probably initially correspond to geo-political
boundaries but the underlying architecture does not preclude this.
TDSPs will not necessarily be the same authorities that arbitrate
the assignment and allocation of telephone or other numbers. They
are intended to simply provide listing and mapping services.
ITDSPs will operate X.500-based directory servers supporting access
via X.500 DAP, LDAP, DNS, and http. When LDAP server-to- server
protocols have evolved, ITDSPs may also operate LDAP servers.
Brown Expires April 2000 6
E.164 Resolution October 1999
3.1.2 Information Suppliers
Mapping information will be supplied to ITDSPs from carriers, ISPs,
enterprises and other entities.
Mapping information supplied to ITDSPs must be relatively static.
If subscriber information is dynamic in nature, then mapping
information may comprise only pointers to private servers that are
closer to the subscriber and which are not part of the top level
ITDSP infrastructure.
If a subscriber has a dynamic E.164 number, they should also have a
more persistent E.164 number for storage in an ITDSP. The persistent
E.164 number can be mapped to one or more dynamic E.164 numbers on
private servers.
3.1.3 Information Consumers
Clients such as LDAP, DAP, DNS resolvers and browsers will be able
to query the global E.164 directory service for information. H.323
RAS queries are outside the scope of this document. Access should
be free and unauthenticated. However, authenticated access may be
enforced, based on the requirements of information suppliers, who in
turn represent the requirements of the subscribers on whose behalf
the listings have been supplied to the ITDSP.
Subscribers may also gain access to mapping information indirectly
via their Internet telephony service provider. This access may be
through queries to the Internet telephony service provider which are
in turn chained or referred to an ITDSP. Alternately, Internet
telephony service providers may arrange to hold local replicas of
ITDSP mapping information.
3.2 Interfaces
This section discusses the interfaces between the functional
components.
3.2.1 ITDSP/ITDSP Interface
Depending on service level agreements, ITDSPs will distribute and/or
share (replicate) information using X.500 1993 protocols or other
mechanisms.
Queries MUST be transparently supported between ITDSPs such that a
particular query will result in the same answer, no matter which
ITDSP you ask.
There is a requirement to support the ability for more than one
Information Supplier to be able to provide information for the same
Brown Expires April 2000 7
E.164 Resolution October 1999
standardization work on distributed entries and multi-master
replication is completed for X.500 and LDAP.
3.2.2 ITDSP/Information Supplier Interface
Carriers, ISPs, enterprises and other entities will supply
information to ITDSPs, based on commercial service agreements.
Updates may be based on the following mechanisms:
- X.500 replication
- LDAP replication (slapd, ldif, changelog, etc.)
- DNS zone transfer
- Common Indexing Protocol (CIP)
- Proprietary means
3.2.3 ITDSP/Information Consumer Interface
Information consumers may be clients, including LDAPv3 and X.500 93
clients, DNS resolvers, and http browsers. H.323 RAS queries are
outside the scope of this document. Where privacy is not an issue,
ITDSPs SHOULD accept unauthenticated, zero-rated queries from
Information Consumers.
Information consumers may also be Internet telephony service
providers who have arranged with their ITDSP to store local replicas
of ITDSP mapping information. These replicas may be transferred via
the following means:
- X.500 replication
- LDAP replication (slapd, ldif, changelog, etc.)
- DNS zone transfer
- Common Indexing Protocol
- Proprietary means
4 Naming
Queries to ITDSPs will be based on keys that will pinpoint entries
in an ITDSP service. Initially, X.500/LDAP distinguished names and
DNS domain names will be supported in queries.
4.1 DNS Domain Name
DNS queries MUST include a top level domain name of "e164", followed
by the full E.164 telephone number listed backwards with each digit
separated by dots. For example, a DNS lookup for an NAPTR RR
[NAPTR] on +1 613 123 4567 would require the following domain name
in the query:
7.6.5.4.3.2.1.3.1.6.1.0.0.e164
Brown Expires April 2000 8
E.164 Resolution October 1999
4.2 LDAP, X.500 Distinguished Name
LDAP and X.500 queries MUST include a distinguished name beginning
with the relative distinguished name of "e164", followed by
distinguished names consisting of each digit of the E.164 telephone
number. For example, an LDAP or X.500 query for information on +1
613 123 4567 would require the following distinguished name in the
query:
o=e164, ed=0, ed=0, ed=1, ed=6, ed=1, ed=3, ed=1, ed=2,ed=3,\
ed=4, ed=5, ed=6, ed=7
where "o" is organizationName and "ed" is e164Digit.
4.3 Others
Other name forms are outside the scope.
5 Scope
This section specifies some items that are outside the scope of this
document.
5.1 Representation of Telephone Numbers
How a user enters a telephone number is between the user and the
Information Supplier representing that user. The global E.164
service only responds to queries for fully canonical E.164 numbers.
5.2 Path Selection
Path selection and call routing are outside the scope. Path
selection requires more than a simple DNS, LDAP, or simple database
query because some service logic must be executed to decide the
appropriate gateway based on such results as the caller and caller
preferences, points of presence and capabilities. Additionally,
path selection is highly dynamic considering resource depletion and
other metrics. Allowing SIP, H.323/RAS and other URLs to be stored
and retrieved supports the existence of other protocols such as SIP,
H.323/RAS and gwloc for path selection.
5.3 Privacy
Privacy, and especially non-listing of a number, is between a user
and their Information Supplier. ITDSPs MUST, however, support the
access controls set by Information Suppliers in the information they
list with ITDSPs.
Brown Expires April 2000 9
E.164 Resolution October 1999
5.4 Lookups -vs- Searching
ITDSPs will provide lookups given an E.164 number. The structure
allows a client to pinpoint an entry in the global ITDSP structural
hierarchy, thus eliminating the requirement for global searching
based on partial information. Searches based on partial information
may be able to provided at some point in the future but are beyond
the scope of this paper.
5.5 Application-Specific Schemas
A general schema is defined in this document to describe how the
global E.164 directory is to be structured. In order for an
application to know which information to retrieve, given an E.164
number, an application-specific schema must be defined. For example,
a draft schema <draft-ema-vpimdir-schema-00.txt> has been defined
for use in a voice messaging (VPIM) pilot. Application-specific
schemas should be defined in the standards or industry forum that
are responsible for those applications and are outside the scope of
this paper.
5.6 "911" Service
This architecture does not support the emergency "911" service.
5.7 Number Portability
Currently number portability is provided locally by regulated
authorities. Local and global number portability is outside the
scope of this paper. However the architecture MUST be capable of
storing and providing access to number portability listings from
trusted third parties, if required in the future.
5.8 User Configurability
User configurability is outside the scope of this paper, however, it
should be facilitated by the architecture. LDAP, X.500 DAP and http
support user configurability. However, it is envisioned that this
will take place closer to the user.
6 Example
Consider a scenario whereby an enterprise, BigCo, has arranged to
provide listing information, on behalf of its employees, to an
ITDSP. Suppose also that most of BigCo's employees have telephone
numbers prefixed with:
Brown Expires April 2000 10
E.164 Resolution October 1999
BigCo also has additional employee numbers scattered throughout the
E.164 numbering plan:
+44 12 55 63
+1 709 123 4567
The integrated BigCo directory tree will contain a white pages (WP)
directory sub-tree, and an E.164 sub-tree, and possibly a sub-tree
structured according to BigCo's private numbering plan. These
entries may be linked together via aliases whereby there are
entries in the WP sub-tree holding employee information and alias
entries in the other sub-trees pointing back to WP entries.
Alternately, BigCo may store its employees profiles in database
tables that can be accessed via LDAP, DAP, or DNS. Regardless of how
a company structures its data, it must have some mechanism to allow
outside queries to be able to logically point to the data using the
naming described in section 4.
root
|
/--------------------------------------------\
o=BigCo o=e164
| |
------------+------------------------- |
| | | ed=0
cn=John Smith cn=Joe Bloggs cn= ou=BigCo Priv Numbering Plan |
| -------------
| |
ed=0 ed=4
| |
ed=1 ed=4
| |
------------- ed=1
| | |
ed=6 ed=7 ed=2
| | |
ed=1 ed=0 ed=5
| | |
ed=3 ed=9 ed=5
| | |
ed=7 ed=1 ed=6
| | |
ed=6 ed=2 ed=3
| / |
DN= o=BigCo, ou=BigCo Priv Numbering Plan <--- ed=3 |
(Pointer to private numbering plan sub-tree) / |
ed=4 |
/ |
ed=5 |
/ |
ed=6 |
/ |
Brown Expires April 2000 11
E.164 Resolution October 1999
/ |
DN= o=BigCo, cn=John Smith <--- DN= o=BigCo, cn=Joe Bloggs <-
(Pointer to WP entry) (Pointer to WP entry)
o: organizationName
ou: organizationalUnitName
cn: commonName
ed: e164Digit
DN: Distinguished Name
Figure 3: Example: BigCo's Private Directory Tree Structure
6.1 BigCo as Information Supplier
If BigCo wishes to control access to its employees' Internet
telephony information, it will only supply mapping information
consisting of the IP addresses of its own principal directory
servers. If BigCo maintains two directory servers for public
queries, say at host names directory1.bigco.ca and
directory2.bigco.ca, it may provide the following information to an
ITDSP:
E.164 Number Mapping Information
+1 613 76 Subordinate Refs=directory1.bigco.ca,
directory2.bigco.ca
+44 12 55 63 Subordinate Refs=directory1.bigco.ca,
directory2.bigco.ca
+1 709 123 4567 Subordinate Refs=directory1.bigco.ca,
directory2.bigco.ca
Subordinate Refs=directory1.bigco.ca,
directory2.bigco.ca
Anyone querying an ITDSP for Internet telephony mapping information
on BigCo employees would get chained or referred to BigCo servers.
6.2 BigCo as Information Consumer
BigCo provides access for its subscribers to ITDSP mapping
information indirectly by chaining from its own corporate directory
servers to the ITDSP servers closest to its own servers. This way
subscribers need only discover the location of a local BigCo
directory server in order to initiate a query for global
information.
7 Schema
This section defines an X.500/LDAP object class and attribute for
use in a global E.164 resolution directory service. Also defined
are X.500 name forms and DIT structure rules.
Brown Expires April 2000 12
E.164 Resolution October 1999
In order for an application to know which information to retrieve,
given an E.164 number, additional schemas must be defined for each
application . For example, a draft schema <draft-ema-vpimdir-schema-
00.txt> has been defined for use in a voice messaging (VPIM) pilot.
Application-specific schemas should be defined in the standards or
industry forum that is responsible for that application.
7.1 Sub-Tree Node Naming Attribute
The E.164 directory is structured in a hierarchy whereby each node
in the tree represents a single digit of an E.164 telephone number.
The higher in the tree a digit is, the higher its significance in
the tree. Since a single digit names the nodes in the tree, the
e164Digit attribute shall have a length of one digit. e164Digit
will be abbreviated to ed for this document. Some examples of
Distinguished Name composed from e164Digits are:
A telephone number of +1 613 765 1234 would have the following
corresponding Distinguished Name in the E.164 directory:
ed=4, ed=3, ed=2, ed=1, ed=5, ed=6, ed=7, ed=3, ed=1, ed=6,\
ed=1, ed=0, ed=0, o=e164
Telephone number +1 613 765 1234 with extension 555 would result
in the following Distinguished Name:
ed=5, ed=5, ed=5, ed=4, ed=3, ed=2, ed=1, ed=5, ed=6, ed=7,/
ed=3, ed=1, ed=6, ed=1, ed=0, ed=0, o=e164
The ASN.1 definition of e164Digit for X.500 implementations is:
e164Digit ATTRIBUTE ::= {
WITH SYNTAX NumericString (SIZE(ub-vpim-at-e164Digit))
EQUALITY MATCHING RULE %numericStringMatch
ID id-vpim-at-e164Digit}
ub-vpim-at-e164Digit INTEGER ::= 1
The BNF definition of e164Digit for use with LDAP is:
(2.16.840.1.113694 .1.2 .1 .1 .1 NAME 'e164Digit'
EQUALITY %2.5.13.8
SYNTAX %'1 .3.6 .1.4.1.1466.115 .121.1.36 {1}')
7.2 Structural Object Class
Structural object classes are used in defining the hierarchical
structure of the directory tree. e164Node is the structural object
class that will be used in defining the structure of the directory
tree. All entries of this type must contain the e164Digit attribute
that is used to name entries in the E.164 directory tree. The ASN.1
Brown Expires April 2000 13
E.164 Resolution October 1999
e164Node OBJECT-CLASS ::= {
SUBCLASS OF %top
MUST CONTAIN { e164Digit }
ID %{ id-vpim-oc-e164node} }
The BNF definition for use with LDAP is:
(2.16.840.1 .113694.1.2.1.2.1 NAME 'e164Node'
SUP top
STRUCTURAL %MUST e164Digit)
7.3 Name Form
Name forms control how entries are named in the directory tree. They
are referenced in the DIT structure rules that are used to define
which classes of object may be subordinate to other classes of
object in the directory. Object classes of the e164DigitNameForm
name form are named using the e164Digit attribute type.
e164DigitNameForm %NAME-FORM ::= {
NAMES e164Node
WITH ATTRIBUTES { e164Digit }
ID id-vpim-nf-e164Digitnameform }
7.4 DIT Structure Rules
The directory is structured according to the rules illustrated in
Figure 4.
Structure rule 1 defines entries, that are named according to the
orgNameForm (i.e., named with attribute organizationName), to be
immediately subordinate to the root of the DIT.
Sr1 STRUCTURE-RULE ::= {
NAME FORM orgNameForm, -- X.521
ID %1 }
root
/
1/
/
/
/
/
/
organziationName
\
\2
Brown Expires April 2000 14
E.164 Resolution October 1999
e164Digit
/ |
3\ /
--
Figure 4: DIT Structure Rules
Structure rule 2 specifies e164Digit entries placed under
organizational entries.
Sr2 STRUCTURE-RULE ::= {
NAME FORM e164DigitNameform,
SUPERIOR RULES { sr1},
ID 2 }
Structure rule 3 defines e164Digit entries subordinate to
e164Digit entries.
Sr3 STRUCTURE-RULE ::= {
NAME FORM e164DigitNameform,
SUPERIOR RULES { sr2 },
ID 3 }
7.5 Summary of Syntax Definitions
7.5.1 ASN.1 Definitions
-- attributes
e164Digit ATTRIBUTE ::= {
WITH SYNTAX %NumericString (SIZE(ub-vpim-at-
e164Digit))
EQUALITY MATCHING RULE numericStringMatch
ID %id-vpim-at-e164Digit}
-- object classes
e164Node OBJECT-CLASS ::= {
SUBCLASS OF %top
MUST CONTAIN %{ e164Digit }
ID %{ id-vpim-oc-e164node} }
-- Name Forms
Brown Expires April 2000 15
E.164 Resolution October 1999
NAMES e164Node
WITH ATTRIBUTES { e164Digit }
ID id-vpim-nf-e164Digitnameform }
-- structure rules
Sr1 STRUCTURE-RULE ::= {
NAME FORM orgNameForm, -- X.521
ID %1 }
Sr2 STRUCTURE-RULE ::= {
NAME FORM e164DigitNameform,
SUPERIOR RULES { sr1},
ID 2 }
Sr3 STRUCTURE-RULE ::= {
NAME FORM e164DigitNameform,
SUPERIOR RULES { sr2 },
ID 3 }
-- upper bounds
ub-vpim-at-e164Digit %INTEGER ::= 1
-- object identifiers
id-vpim OBJECT IDENTIFIER ::= {2.16.840.1.113694.1.2.1}
id-vpim-at OBJECT IDENTIFIER ::= {id-vpim 1}
id-vpim-at-e164Digit OBJECT IDENTIFIER ::= {id-vpim-at 1}
id-vpim-oc OBJECT IDENTIFIER ::= {id-vpim 2}
id-vpim-oc-vMNode OBJECT IDENTIFIER ::= {id-vpim-oc 1}
id-vpim-nf OBJECT IDENTIFIER ::= {id-vpim 3}
id-vpim-nf-e164Digitnameform OBJECT IDENTIFIER ::= { id-vpim-nf 1}
7.5.2 BNF Definitions
(2.16 .840 .1.113694.1 .2 .1.1.1 NAME 'e164Digit'
EQUALITY %2 .5.13 .8
SYNTAX '1.3.6 .1.4 .1.1466.115.121.1.36 {1}')
(2.16 .840 .1.113694.1 .2 .1.2.1 NAME 'e164Node'
SUP top
STRUCTURAL %MUST e164Digit)
8 Requirements
Brown Expires April 2000 16
E.164 Resolution October 1999
This section discusses the requirements of a global solution for
addressing the problem of providing access to server and endpoint
information, given a telephone number.
8.1 Geo-Political Boundary Independence
Several solutions have been proposed that use a distributed
telephone number hierarchy, such as TPC.INT [TPC.INT], for
information retrieval. Some have suggested distributing this
hierarchy into countries and other sub-components related to the
structure of a telephone number. This type of delegation is not
suitable because it uses the assumptions of existing infrastructures
and could seriously impede new types of scenarios. In the future,
authorities and services (e.g., local and global number portability,
etc.) may span geo-political boundaries. The E.164 resolution
hierarchy described in this document is similar to TPC.INT, whereby
a logical tree is patterned after the structure of the E.164
telephone numbering plan. However, instead of breaking the tree
into components of the E.164 plan (e.g. country code, etc.), it uses
each digit of an E.164 number for a node in the tree. The tree can
be logically shared and/or distributed between ITDSPs and does not
mandate distribution on a geo-political basis.
8.2 Trusted, Third Party, Top-Level Service Providers
The requirement for geo-political boundary independence implies a
requirement for the existence of trusted, third party, top- level
service providers. ITDSPs will probably initially correspond to
geo-political boundaries, but the underlying architecture MUST not
preclude this.
ITDSPs will not necessarily be the same authorities that arbitrate
the assignment and allocation of telephone or other numbers. They
are intended to simply provide listing and mapping services.
8.3 Numbering Plan Independence
Telephone numbers used to retrieve information on a subscriber may
be obtained from business cards, directory assistance or other
means. Therefore the client may not have knowledge of how the
telephone number is structured. Clients accessing an ITDSP MUST not
require any knowledge as to the structure or length of national
numbering plans.
8.4 Lookups -vs- Searching
ITDSPs will provide lookups given an E.164 number. The structure
allows a client to pinpoint an entry in the global ITDSP structural
hierarchy, thus eliminating the requirement for global searching
Brown Expires April 2000 17
E.164 Resolution October 1999
may be able to provided at some point in the future but it is beyond
the scope of this paper.
8.5 Multiple ITDSPs
ITDSPs MUST be able to access each other's information such that no
matter which ITDSP is queried, the same response is be received.
8.6 Distributed Entries
There is a requirement to support the ability for more than one
Information Supplier to be able to provide information for the same
telephone number. Given the appropriate security credentials of the
requestor, a request to a single ITDSP for information on a
particular subscriber MUST result in a response containing all
listings for that subscriber, even if some of the master listings
are held by other ITDSPs.
Initially, there will be a small number of ITDSPs available. Their
implementations MUST support the ability to handle distributed
attributes. This will initially be done using proprietary
synchronization mechanisms. The existence of a standard for handling
distributed entries is essential to the handling of billions of
distributed entries on a global basis. X.500 work is currently being
evolved to handle multi-master replication and the existence of
distributed attributes to support multiple service providers for the
same real-world object. This ITU-T, SG7 WP4, Q.15 work, which is
scheduled for approval in June 1999, will be done in collaboration
with the IETF for use by LDAP as well.
There must be some accountability for the provision of false
information. Updates must be authenticated. As well, placing a
price on listings may discourage phony listings. How to guarantee
that mappings are authorative is for further study.
8.7 Transparency
The proposed solution MUST allow for the retrieval of endpoint and
server address information without previously knowing where that
information is stored. X.500, LDAP and DNS use referrals to support
this.
As well, ITDSPs SHOULD be able to respond to queries for information
held by other ITDSPs as if they themselves held the information.
X.500 supports chaining, which allows the client to make only one
query and also isolates the client from the underlying distribution
of ITDSP servers.
8.8 Access Methods
Brown Expires April 2000 18
E.164 Resolution October 1999
Clients MUST be able to access ITDSP information using a standard
access protocol. ITDSPs MUST allow access using X.500 DAP, LDAP,
DNS, and http. LDAP allows for more complex and sizeable queries
and results. DNS, on the other hand, allows for simpler access and
is easier to implement in client devices. The existence of http
access to clients facilitates end-user configurability. With LDAP
and X.500 DAP, clients may receive different answers based on
security credentials and query parameters.
8.9 Additional Subscriber Information
ITDSPs MUST be capable of providing access to additional subscriber
information. If LDAP or DAP is used by the client, it does not need
to switch to another protocol to access this additional subscriber
information. In fact, endpoint, server and subscriber information
can be accessed via chaining using one query.
8.10 Path Selection (gwloc)
Path selection requires more than a simple DNS, LDAP, or simple
database query. However, the architecture supports the existence of
other protocols such as SIP [SIP], H.323/RAS and gwloc [GWLOC] for
path selection, by allowing SIP, H.323/RAS and other URLs to be
stored and retrieved.
8.11 Time to Market
All that is required for this solution to be deployed is for one or
more service providers to start up a service. VPIM vendors have
already trialed such a service and several organization have plans
to implement a commercial service.
Existing clients can be used to request information, however,
applications must support these existing access protocols.
8.12 Dynamic Information
If a subscriber's mapping information is dynamic, it should be
stored on a server closer to the user and the ITDSP should only
store the server address.
If a subscriber employs dynamic E.164 numbers, they should also have
a more persistent E.164 number for storage in an ITDSP. The
persistent E.164 number can be mapped to one or more dynamic E.164
numbers on another server.
8.13 Redirection
Brown Expires April 2000 19
E.164 Resolution October 1999
The service MUST be capable of redirecting the E.164 number to
another number, which may belong to another subscriber who may have
different capabilities and preferences. Supplying a different E.164
address for the endpoint address can provide redirection.
Additionally, redirection can be actioned at a private server closer
to the user, in which case, the ITDSP should only list the server
address for the subscriber.
8.14 Number Portability
Currently number portability is provided locally by regulated
authorities. Local and global number portability is outside the
scope of this paper. However the architecture MUST be capable of
storing and providing access to number portability listings from
trusted third parties, if required in the future.
8.15 User Configurability
User configurability is outside the scope of this paper, however, it
should be facilitated by the architecture. LDAP, X.500 DAP and http
support user configurability. However, it is envisioned that this
will take place closer to the user.
8.16 Quality of Service
Quality of service for ITDSP query requests is outside the scope of
this paper, however the solution should be able to support it in the
future. X.500 standards are evolving to support the request of a
particular level of QoS. This work will be liaised to ITEF for
possible adoption by LDAP.
8.17 Capabilities Discovery
The solution MUST be able to point to servers storing user
capabilities. Other groups are handling work on capabilities
discovery and negotiation.
9 Relationship to Other Protocols and Initiatives
9.1 TPC.INT
TPC.INT [TPC.INT] distributes the E.164 numbering plan hierarchy
into countries and other sub-components related to the structure of
a telephone number. The TPC.INT idea of a logical telephone number
hierarchy was used as a basis for the structure of the E.164
directory tree in this document. However, the geo- political
delegation used in TPC.INT was not suitable for the E.164 global
Brown Expires April 2000 20
E.164 Resolution October 1999
could seriously impede new types of scenarios. Instead of breaking
the tree into components of the E.164 plan (e.g. country code,
etc.), the E.164 hierarchy uses each digit of an E.164 number for a
node in the tree. This tree can be more easily shared and/or
distributed between ITDSPs and does not mandate distribution on a
geo-political basis. It also does not require the Information
Consumer to have prior knowledge of numbering plan structures and
lengths.
9.2 Path Selection (gwloc)
Path selection requires more than a simple DNS, LDAP, or simple
database query because some service logic must be executed to decide
the appropriate gateway based on such results as the caller and
caller preferences, points of presence and capabilities.
Additionally, path selection is highly dynamic considering resource
depletion and other metrics. Allowing SIP, H.323/RAS and other URLs
to be stored and retrieved supports the existence of other protocols
such as SIP, H.323/RAS and gwloc for path selection.
9.3 TIPHON Service Mediation Environment
The ITDSP architecture compliments TIPHON's Service Mediation
Environment work by providing a needed E.164 resolution mechanism.
How these can work together is for further study.
9.4 SIP
SIP [SIP] also provides for multistage address resolution suitable
for the enterprise level. This solution compliments SIP by
providing a global backbone that can point to SIP servers that are
closer to users. E.164 to SIP URL mapping information can be listed
by Information Suppliers.
9.5 Naming Authority Pointer (NAPTR)
Faltstrom's draft < draft-faltstrom-e164-03.txt> introduces use of
NAPTR RRs [NAPTR] to, among other things, support portable numbers
and to enable a level of indirection between mapping information and
the owner of an E.164 number. The existence of ITDSPs compliments
Faltstrom's approach by providing a top-level service that responds
to NAPTR queries on the E.164 top level domain. The ITDSPs, as well
as Faltstrom's solution, can provide pointers to where more
structured information can be stored.
9.6 Wide Area Service Location
The relationship of this architecture to wide area service location
Brown Expires April 2000 21
E.164 Resolution October 1999
on wasrv advances. It is envisioned that the proposed solution will
be one of the services advertised by SLP [SLP].
9.7 DIAMETER
Mapping information may point to directories that store information
on subscriber policies. Alternately, mapping information could
point to DIAMETER [DIAM] authentication servers serving a particular
E.164 number.
9.8 Global Electronic Directory Assistance
ITU-T Rec. F.510 [F510] describes a global electronic directory
assistance standard. X.500 is currently being enhanced to support
F.510 and the work is expected to be approved June 1999. Once this
work is completed, it may compliment the services provided by ITDSPs
by allowing clients to access information without first knowing a
subscriber's E.164 number.
9.9 Yellow Pages Directories and Search Engines
Existing yellow pages-type directories and search engines will
compliment the ITDSP service by allowing users to obtain information
without first knowing a subscriber's E.164 number.
9.10 Directory Enabled Networks (DEN)
ITDSPs can store pointers to subscriber policy information. Once DEN
evolves, it may be possible to retrieve information on application
and network policy information relevant to a particular telephone
number and subscriber.
9.11 IN SCP and ss7/Internet gateways
IN CS-1R, CS-2 and CS-3 define an X.500 interface for use between
the SDF/SDF and SDF/SDF functional units. Additionally, DNS, LDAP
and other protocols may be able to be used to access the ITDSP from
an SCP. The relationship between ITDSPs and SCPs, and between
ITDSPs and ss7/Internet gateways, is beyond the scope of this paper.
9.12 TIPHON's Internet Country Code
ETSI's TIPHON is in the process of trying to register an Internet
country code to facilitate non-geopolitically-based, flat allocation
of telephone numbers for use over the Internet. ITDSPs will support
access to E.164 numbers assigned with an Internet country code.
Brown Expires April 2000 22
E.164 Resolution October 1999
9.13 Mail Recipient Capabilities (mailcap)
Work on store and forward capabilities discovery, and possibly
session-based capabilities discovery is currently being studied in
other groups. Once this work evolves, ITDSPs may point to
information on user capabilities.
9.14 Presence Information Protocol
Presence information protocols could be used to populate databases
used by Information Suppliers to provide information to ITDSPs,
however, such interaction would be outside the scope of this
document. It is also possible that ITDSPs could point to servers
containing presence information.
9.15 Numbering Plans
The architecture both recognizes and supports the different
numbering plans that exist today. The relationship between ITDSPs
and the numbering plan administrations in the different countries is
for further study.
9.16 Common Indexing Protocol
Common Indexing Protocol (CIP) [CIP], facilitates searching between
directory servers and could be used to distribute queries between
ITDSPs.
10 Commercial Aspects
It is envisioned that information will be supplied to ITDSPs by
other entities, based on service level agreements. Sharing and/or
distribution of information between ITDSPs will also be based on
service level agreements. The ideal scenario would be
authenticated, fee based listing services, along with free,
unauthenticated single query access to the information. Local
storage of replicas of ITDSP mapping information should be fee-
based as well.
11 Security Considerations
Privacy, and especially non-listing of a number, is between a user
and their Information Supplier. ITDSPs MUST, however, support the
access controls set by Information Suppliers in the information they
list with ITDSPs.
For the directory service, access control should be such that
Brown Expires April 2000 23
E.164 Resolution October 1999
The directory was designed for single X.500 read operations (base
object searches in LDAP). Multiple multilevel searches may degrade
performance and should be discouraged. To prohibit access to entries
without explicitly providing the name of an entry, denyBrowse should
enforced for anonymous users.
There must be some accountability for the provision of false
information. Updates must be authenticated. As well, placing a
price on listings may discourage phony listings. How to guarantee
that mappings are authorative is for further study.
12 Acknowledgements
Input from Mark Wahl, Mike Sutter, Richard Shockey and discussions
on the iptel list, greatly contributed to the information contained
in this report.
13 Author's Addresses
Anne Brown
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-765-5274
Email: arbrown@nortelnetworks.com
14 References
[TPC.INT] RFC 1530: Malamud, C., Rose, M., "Principles of Operation
for the TPC.INT Subdomain: General Principles and Policy", October
1993
[SIP] RFC 2543: Handley, M., Schulzrinne, H., Schooler, E.,
Rosenberg, J., "SIP: Session Initiation Protocol", March 1999
[GWLOC] Rosenberg, J., Schulzrinne, H., "A Framework for a Gateway
Location Protocol", Work in Progress, draft-ietf-iptel-gwloc-
framework-04.txt, August 1999
[CIP] RFC 2651: Allen, J., Mealling, M., "The Architecture of
the Common Indexing Protocol (CIP)", August 1999
[X500] RFC 2605: Mansfield, G., Kille, S., "Directory Server
Monitoring MIB", June 1999
[LDAP] RFC 1777: Yeong, W., Howes, T., Kille, S., "Lightweight
Directory Access Protocol", March 1995
Brown Expires April 2000 24
E.164 Resolution October 1999
RFC 2251: Wahl, M., Howes, T., Kille, S., "Lightweight
Directory Access Protocol (v3)", December 1997
[NAPTR] RFC 2168: Daniel, R., Mealling, M., "Resolution of
Uniform Resource Identifiers using the Domain Name System", June
1997.
[SLP] RFC 2165: Veisades, J., Guttman E., Perkins, C., Kaplan,
S., "Service Location Protocol", June 1997
RFC 2608: Guttman, E., Perkins, C., Veizades, J., Day, M.,
"Service location Protocol, version 2", June 1999
[DIAM] Rubens, A., Calhoun, P., "DIAMETER", Work in Progress,
draft-calhoun-diameter-00.txt, March 1997
[F510] ITU-T Recommendation F.510, "Automated directory
assistance - White pages service definition", December 1997
[H323] ITU-T Recommendation H.323, "Packet-based multimedia
communications systems", February, 1998
[VPIM] RFC 2421: Vaudreuil, G., Parsons, G., "Voice Profile for
Internet Mail - version 2", September 1998
[VPIMdir] Brown, A., "VPIM Directory Schema Definition & Profile",
Work in Progress, draft-ema-vpimdir-schema-00.txt, November 18, 1997
[E164-dns] Faltstrom, P., Larsson, B., "E.164 number and DNS", Work
in Progress, draft-faltstrom-e164-03.txt, September 9, 1999
15 Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
Brown Expires April 2000 25
E.164 Resolution October 1999
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Brown Expires April 2000 26
