One document matched: draft-schwartz-speermint-provisioning-problem-00.txt
Network Working Group D. Schwartz, Ed.
Internet-Draft XConnect
Expires: May 14, 2008 R. Mahy
Plantronics
A. Duric
Telio
November 11, 2007
Managing Client Voice Peering Provisioning
draft-schwartz-speermint-provisioning-problem-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the type of data provisioned among Voice
Service Providers. This is in support of the service provider
peering as defined by the Speermint WG.
Schwartz, et al. Expires May 14, 2008 [Page 1]
Internet-Draft Voice Peering Provisioning November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Responsibility Data . . . . . . . . . . . . . . . . . . . . . . 3
3. Reachability vs. Routing . . . . . . . . . . . . . . . . . . . 4
4. Operations on the Registry Data . . . . . . . . . . . . . . . . 4
5. Other attributes . . . . . . . . . . . . . . . . . . . . . . . 5
6. Rate Information . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Schwartz, et al. Expires May 14, 2008 [Page 2]
Internet-Draft Voice Peering Provisioning November 2007
1. Introduction
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.
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 the management of
the relationships (this is often known as Assisted Peering [1]). One
of the central functions of these peering exchanges is a registry of
identifiers based on telephone numbers. This function is often
called the peering or numbering registry. VSPs participating in the
peering exchange must provision their identifiers into the peering
registry.
Once identifiers are provisioned into the registry, other VSPs may
query the registry against those identifiers to find the responsible
VSP and the associated routing information to this VSP. To gain as
much IP-to-IP coverage, many VSPs have relationships with several
peering exchanges. However, the management of even a few peering
exchange relationships can be made difficult since there is not yet a
standard protocol for exchange of this data. Lack of such a standard
also makes it cumbersome for service providers to exchange this data
directly among themselves or with sub registries.
This document attempts to describe the most common data that needs to
be exchanged among these VSPs (either directly or through a
centralized registry).
2. Responsibility Data
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).
Schwartz, et al. Expires May 14, 2008 [Page 3]
Internet-Draft Voice Peering Provisioning November 2007
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.
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.
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.
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 [2]. Likewise it
is very useful to know that a prefix is known not the exist anywhere.
3. Reachability vs. Routing
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 which 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.
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.
4. Operations on the Registry Data
Below is a list of logical operations on the registry data.
Schwartz, et al. Expires May 14, 2008 [Page 4]
Internet-Draft Voice Peering Provisioning November 2007
Add: Add (responsible VSP) data about a new prefix to the registry.
Delete: Remove a prefix from the registry. Semantically it means
that the prefix no longer exists anywhere.
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.
Port-In: A port-in is similar to an add, but the semantics are that
the prefix was previously assigned to a different provider.
Transfer: A transfer is a port-out and port-in operation performed
atomically. This operation insures that lookups do not fail for
the transfered prefix during the transfer.
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).
Modify: A modify operation occurs when some other attribute of a
prefix is modified (for example the target URI used for
reachability).
5. Other attributes
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.
In addition to responsibility data, we have identified the following
extra attributes as important or interesting:
Number type (unknown, IP, PSTN, both)
PSTN carrier code (for numbers with no IP reachability)
Fee category (free, landline, mobile, pay)
Media types supported (voice, video, message)
6. Rate Information
Rate information is another set of data which uses phone number
prefixes as an index. However, rate information is quite different
from responsibility information in that rate information is often
different depending on who is asking.
Schwartz, et al. Expires May 14, 2008 [Page 5]
Internet-Draft Voice Peering Provisioning November 2007
Conveying rate information automatically in a standard way is also of
great interest to most VSPs. The community may try to reuse much of
the mechanism used to provision responsibility data to the rate
sharing problem as well. This document will briefly enumerate what
data is likely needed for rate sharing.
Rate and currency for initial period (ex: 0.02 USD per initial 60
seconds)
Rate and currency for addition periods (ex: 0.001 USD per
additional 60 seconds)
Grace period before rate is billed (ex: 6 seconds)
Time of day and days of week for which the rate applies
Media types for which the rate applies (voice, video, text)
Note that these metrics can be combined for flat-rate calls or
messages
7. Security Considerations
TBD
8. IANA Considerations
This document requires no action by IANA.
9. Acknowledgments
Thanks to Andy Newton for encouraging work in this area.
10. Informative References
[1] Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-12 (work in progress),
August 2007.
[2] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network (PSTN)
Signaling Information", RFC 4769, November 2006.
[3] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Schwartz, et al. Expires May 14, 2008 [Page 6]
Internet-Draft Voice Peering Provisioning November 2007
Session Initiation Protocol", RFC 3261, June 2002.
[5] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
Authors' Addresses
David Schwartz (editor)
XConnect
Email: david@xconnect.com
Rohan Mahy
Plantronics
Email: rohan@ekabal.com
Alan Duric
Telio
Email: alan.duric@telio.no
Schwartz, et al. Expires May 14, 2008 [Page 7]
Internet-Draft Voice Peering Provisioning November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Schwartz, et al. Expires May 14, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 08:59:31 |