One document matched: draft-schwartz-peppermint-problem-statement-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc3403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml">
<!ENTITY rfc3730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3730.xml">
<!ENTITY rfc3761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc4114 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4114.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY rfc4769 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4769.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-schwartz-peppermint-problem-statement-00" ipr="full3978">
<front>
<title abbrev="Consolidated-Prov-Prob">Consolidated Provisioning Problem Statement</title>
<author initials="D.S" surname="Schwartz" fullname="David Schwartz">
<organization>XConnect Global Networks</organization>
<address>
<postal>
<street>Malcha Technology Park</street>
<street>Building # 1</street>
<city>Jerusalem</city><code>90961</code>
<country>Israel</country>
</postal>
<phone>+972 52 347 4656</phone>
<email>dschwartz@xconnect.net</email>
<uri>www.kayote.com</uri>
</address>
</author>
<author initials="R.M" surname="Mahy" fullname="Rohan Mahy">
<organization>Plantronics</organization>
<address>
<email>rohan@ekabal.com</email>
<uri>www.plantronics.com</uri>
</address>
</author>
<author initials="A.D" surname="Duric" fullname="Alan Duric">
<organization>Telio</organization>
<address>
<email>alan.duric@telio.no</email>
<uri>www.telio.no</uri>
</address>
</author>
<author initials="E.L" surname="Lewis" fullname="Edward Lewis">
<organization>NeuStar</organization>
<address>
<postal>
<street>46000 Center Oak Plaza</street>
<street>Building # 1</street>
<city>Sterling</city><region>VA</region><code>20166</code>
<country>USA</country>
</postal>
<phone>+1-571-434-5468</phone>
<email>ed.lewis@neustar.biz</email>
<uri>www.neustar.biz</uri>
</address>
</author>
<date year="2008" />
<abstract>
<t>This document describes the type of data provisioned among Voice
Service Providers and underscores the need for clearly defined structures
and interfaces to facilitate this provisioning. This work is in support
of the service provider peering as defined by the SPEERMINT WG.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>VoIP Service Providers (VSPs) engage in peering relationships
with other VSPs to create direct IP-to-IP interconnections.
These relationships provide network reach, greater technical
capabilities and enhanced economic benefit beyond that available
with the Public Switched Telephone Network (PSTN), while providing
the security benefit perceived to exist in the PSTN.</t>
<t>Because the business and operational management of hundreds or
thousands of direct peering relationships is difficult, VSPs often
enlist the help of peering exchanges to centralize (or assist <xref
target="I-D.ietf-speermint-terminology"></xref> with) the management
of the relationships.
One of the central functions of these peering exchanges is a registry
of identifiers (often implemented as a private ENUM tree) based on
telephone numbers. This function is called the peering or numbering
registry. VSPs participating in the peering exchange must provision
their identifiers into the peering registry to allow other VSPs with
access to this registry to query and obtain the correct resolution
for a given number. Lack of clear standards for this provisioning
step has given rise to many proprietary approaches that are rendering
open provisioning cumbersome and error prone.</t>
<t>VSP peering is not the only driver for this work, however. It
is quite common today for one VSP to receive number resolution data
from both authoritative or regulatory sources (e.g. a national
telephone number plan administrator) and commercial or private sources.
Since eventually all of the information resides locally, the VSP is
interested in merging resolution data across potentially different
local platforms so as to avoid multiple queries for each call. Today
this is virtually impossible to do in an efficient and standard manner
due to the proprietary nature of the individual registry components.</t>
<t>In addition, many registry network architectures dictate sub
registries for overall resilience and performance. The transfer of
resolution data to the sub registries is not yet standardized and
results in unnecessary hardware/software component lock in.</t>
<t>This document attempts to describe the most common data that needs
to be exchanged in the cases highlighted above with the ultimate goal
being that of identifying the data structures and interfaces required
to support the data exchange scenarios specified above.</t>
<t>As a final note it is important to stress that while ENUM is not
mentioned explicitly in this document so as not to bias the outcome,
it is clear that in the minimum all the information present in a NAPTR
RR must be captured as the information therein has been well thought
out and deviating from this may curtail future growth. Additionally,
while E.164 numbering is not mentioned either for the same reason, it
is clear that in almost all cases the prefixes that are being exchanged
are in the e.164 format.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>Terms used or referred to elsewhere in the document (including in
the introduction):</t>
<t>DNS - Domain Name System <xref target="RFC1034"></xref></t>
<t>RR - Resource Record <xref target="RFC1034"></xref></t>
<t>TXT - DNS Text record <xref target="RFC1035"></xref></t>
<t>NAPTR - Naming Authority Pointer record <xref target="RFC3403"></xref></t>
<t>EPP - Extensible Provisioning Protocol <xref target="RFC3730"></xref></t>
<t>ENUM - E.164 to URI DDDS <xref target="RFC3761"></xref></t>
<t>URI - Uniform Resource Identifiers <xref target="RFC3986"></xref></t>
<t>TLS - Transaction Layer Security <xref target="RFC4366"></xref></t>
</section>
<section title="Registry Data">
<t>Registry Data consists of both Index or Key data and Resolution
data.</t>
<section title="Index/Key Data">
<t>The organization of registry data is based on specific phone
numbers or phone number prefixes (which could represent blocks
of phone numbers, regions, or theoretically whole countries).
For generality, we will use the term prefix to include complete
phone numbers as well. Prefixes are the index or key used for
all registry manipulation and lookups. Even though some of the
numbers represented within these prefixes may not be globally
reachable, the prefix itself needs to be globally normalized
before it can be entered into a registry. These globally
normalized prefixes always begin with a plus (+) and a telephone
country code. (Note that prefixes in some countries can contain
hexadecimal digits).</t>
<t>Since prefixes have variable lengths, a provisioning protocol
must be able to enter data for a sub-prefix or super-prefix of an
existing record. For example, it must be possible to enter
records about "+1202555" and "+12025551234" at the same time.
For lookups information about the most specific prefix will be
returned. This allows for some measure of aggregation. Also, in
order to provide maximal flexibility a provisioning protocol must
provide a mechanism for specifying both minimum and maximum number
of digits in a prefix.</t>
</section>
<section title="Resolution Data">
<t>For each prefix, there is a variety of data that can be
exchanged. The most important set of data identifies that a
specific VSP is responsible for the prefix and in most cases
the VSP provides a SIP URI through which this prefix can be
reached.</t>
<t>In complex cases, several VSPs may claim some form of
responsibility for the same prefix. We can use the term "last
hop" VSP to describe the VSP closest to the end-user of a phone
number. The provider who was assigned a prefix by the national
numbering authority is the "first hop" VSP. The first hop VSP
may have no way of knowing if the last hop VSP will include
itself in the registry. Therefore it is important that the
querier can obtain both records and use the most specific one
which contains reachability information.</t>
<t>In many cases, commercial registries also contain information
used for Local Number Portability. Even if a prefix is not
reachable for IP peering, it is useful to provide the "dipped"
number and carrier code. This information could be provided as
a tel URI with the number portability attributes defined in RFC
4769 <xref target="RFC4769"></xref>. Likewise it is very useful
to know that a prefix is known not to exist anywhere.</t>
<t>Like stated in the introduction it is imperative that the
minimal set of resolution data contain all the information
required for a DNS NAPTR RR.</t>
<t>Additionally, as a future proofing mechanism it is
recommended that resolution data include a catchall (similar
to a DNS TXT RR) for data that is not currently present in
any ENUM service definitions.</t>
<t>One final note. One of the common "rewrite" rules for the
URI in NAPTR RRs for example is of the form
"\1@somehost.company.example" where the "\1" refers to the
telephone number being processed. This kind of shorthand should
be available when processing prefixes in bulk.</t>
</section>
</section>
<section title="Reachability vs. Routing">
<t>The goal of the registry is to provide sufficient information to
identify a responsible VSP for a prefix. The responsible VSP can
provide a SIP URI that can be proxied or redirected as desired by
the VSP. It is important to note that the registry is expected to
return the same responsibility data for all parties that query it.</t>
<t>Routing information is also out of scope of the registry
provisioning problem. Once a responsible VSP is contacted, that
VSP can use a variety of techniques to route that request. For
example, the VSP could use TRIP [3], a private database, or a SIP
location server. Since this information is highly dynamic, it is
inappropriate to provision in a registry.</t>
</section>
<section title="Operations on the Registry Data">
<t>WBelow is a list of logical operations on the registry data.
Please note that as stated above a provisioning protocol MUST apply
these operations equally to individual prefixes as well as prefix
blocks.</t>
<t></t>
<t>Add: Add (responsible VSP) data about a new
prefix to the registry.</t>
<t></t>
<t>Delete: Remove a prefix from the registry.
Semantically it means that the prefix no
longer exists anywhere.</t>
<t></t>
<t>Port-out: A port-out is similar to a delete, but
could be logged differently. The semantics
are that the prefix still exists, but that
the previous VSP is no longer responsible
for it.</t>
<t></t>
<t>Port-In: A port-in is similar to an add, but the
semantics are that the prefix was previously
assigned to a different provider.</t>
<t></t>
<t>Transfer: A transfer is a port-out and port-in
operation performed atomically. This
operation insures that lookups do not fail
for the transferred prefix during the
transfer.</t>
<t>Renumber: A renumber operation occurs when a specific
prefix is completely changed, but the data
corresponding to the prefix has not changed.
This typically happens when a prefix is
lengthened. For example, when France moved
from an 8-digit to a 10-digit dial plan, the
corresponding globally normalized prefix for
a Parisian phone number had a 1 inserted
between the country code and the old prefix.
Renumbering could also accomplish prefix
shortening (although this is quite unlikely
to occur) or prefix splitting (in the past
United States area codes where split when
they were exhausted).</t>
<t>Modify: A modify operation occurs when some other
attribute of a prefix is modified (for example
the target URI used for reachability).</t>
</section>
<section title="Other Atrributes">
<t>All the registry records will need to include some kind of validity
information. The provisioning protocol can indicate that a record is
not valid before one date and time and no longer valid after another
date and time.</t>
<t>In addition to responsibility data, we have identified the following
extra attributes as important or interesting:</t>
<t>Regardless of which protocol is used, issues that should be addressed
include:</t>
<t></t>
<t>Number type (unknown, IP, PSTN, both)</t>
<t></t>
<t>PSTN carrier code (for numbers with no IP reachability)</t>
<t></t>
<t>Fee category (free, landline, mobile, pay)</t>
<t></t>
<t>Media types supported (voice, video, message)</t>
<t></t>
<t>There MUST be a mechanism for an audit trail as issues of ownership
are bound to surface and a clearly defined mechanism for tracking changes
to registry data is essential.</t>
</section>
<section title="Data Encoding">
<t>Since data may need to traverse administrative domain boundaries
some thought needs to be given to the rendering of the messages in
transmission. The encoding mechanism MUST be robust and easy to design
and troubleshoot with a strong bias towards an existing and widely
recognized standard.</t>
</section>
<section title="Data Management">
<t>Due to the entrenchment of legacy software development processes
(e.g. SOAP/XML, WSDL, TLS) it is of utmost importance that whatever
emerges from this WG should be easy to implement with existing
methodologies.</t>
</section>
<section title="Data Propegation">
<t>The transport layer is strictly point-to-point, with no caching
or forwarding. </t>
</section>
<section title="Querying The Registry">
<t>The definition of the registry query mechanism is out of scope
for the PEPPERMINT activity. However, it is helpful to know what
mechanisms are in popular use to understand the necessary properties
for a provisioning interface. At present, there are two well-known
methods used by VSPs to query a peering registry. These are ENUM
<xref target="RFC3761"></xref> and SIP <xref target="RFC3261"></xref>.
</t>
<t>ENUM is simply a method of using DNS. It allows a VSP to query
a registry with a telephone number, an E.164 number in most cases,
and retrieve a list of URIs, each with a specific preference order.</t>
<t>When SIP is used for the query mechanism, the numbering registry
functions as a SIP redirect proxy <xref target="RFC3261"></xref> . The
input to this mechanism is a URI or more importantly the UserInfo
part of the URI containing the number to be queried. The response
returned by the proxy is either an error code indicating the absence
of information about the number queried or a redirect response (3XX)
containing 1 (or more) Contact Headers representing available routing
options.</t>
</section>
<section title="Control">
<t>Since it may be possible to both push and pull data it is
imperative that a throttling mechanism exist to control the flow
of data exchange at all levels.</t>
</section>
<section title="Existing Technologies">
<t>there has been some consideration to EPP extensions for ENUM
<xref target="RFC4114"></xref>, and why it has not been adopted
and why a requirements document is now being produced to cover what
would seemingly be addressed by that solution.</t>
<t>There are two reasons for EPP not being adopted. One is that
it isn't compatible with legacy participants. The other reason is
that it requires more implementation work.</t>
<t>Legacy participants have an existing base of software development
built around SOAP/XML and WSDL, and are familiar with TLS. Approaches
to ENUM registry interfaces that use these tools will blend more easily
into the software products already in use to manage telephone numbers.</t>
<t>The use of SOAP permits automatic generation of software to handle
the client side of the exchange. Domain name registries had to provide
software tool kits to give to registrars to match this functionality.
When a change is made to EPP, there will be a lot of software exchanged.</t>
<t>From experience with both EPP and SOAP based approaches to registry
software, the SOAP based approach is much easier on the software
engineering process. The difference between the approaches is not seen
in a protocol analysis, but in an analysis of software engineering.</t>
</section>
<section title="Security Considerations">
<t>Security is to be implemented in the applications exchanging data,
the requirements here are meant to say that relevant security data
will be exchanged in the building of the transport. Specifically,
data integrity, authentication and secrecy. (Please note that all
three of these can be provided by using TLS, with the certificate
handshake being used by the application to complete the security
needs).</t>
</section>
<section title="IANA Considerations">
<t>NA</t>
</section>
<section title="Acknowledgements">
<t>Many of the points of information in this document are
summarizations of objectives and statements made by individuals
on the PEPPERMINT and SPEERMINT mailing lists. We would also
like to acknowledge Jeremy Barkan and Otmar Lendl for providing
insightful inputs to the original draft. Information on the
PEPPERMINT mailing list can be found at
http://www.ietf.org/mailman/listinfo/peppermint.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3261;
</references>
<references title="Informational References">
&rfc1034;
&rfc1035;
&rfc3403;
&rfc3730;
&rfc3761;
&rfc3986;
&rfc4114;
&rfc4366;
&rfc4769;
<reference anchor="I-D.ietf-speermint-terminology">
<front>
<title abbrev="Terminology">SPEERMINT Terminology</title>
<author fullname="Daryl Malas" initials="D.M" surname="Malas"><organization></organization></author>
<author fullname="David Mayer" initials="D.M" surname="Mayer"><organization></organization></author>
<date month="November" year="2007"></date>
</front>
<seriesInfo name="" value="draft-ietf-speermint-terminology-15.txt" />
<format type="HTML" octets="16553" target="http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-15.txt" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:55:08 |