PEPPERMINT A. Newton
Internet-Draft SunRocket
Intended status: Informational January 27, 2007
Expires: July 31, 2007
Provisioning Extensions in Peering Registries for Multimedia
Interconnection (PEPPERMINT) Problem Statement
draft-newton-peppermint-problem-statement-00.txt
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 July 31, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Newton Expires July 31, 2007 [Page 1]
Internet-Draft PEPPERMINT Problem Statement January 2007
Abstract
This document contains descriptions of the problems faced by
operators and participants of multimedia interconnection (i.e. SIP)
peering registries with respect to identity provisioning.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Querying the Registry . . . . . . . . . . . . . . . . . . . . 4
3. Registry Provisioning . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning Data . . . . . . . . . . . . . . . . . . . . 5
3.2. Provisioning Protocols . . . . . . . . . . . . . . . . . . 5
4. Database Co-location . . . . . . . . . . . . . . . . . . . . . 6
5. Internationalization Considerations . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Newton Expires July 31, 2007 [Page 2]
Internet-Draft PEPPERMINT Problem Statement January 2007
1. Introduction
VoIP Service Providers (VSPs) engage in peering relationships with
other VSPs to create direct IP-to-IP interconnections. These
relationships provide 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 operational management
of hundreds and thousands of direct peering relationship is
difficult, VSPs enlist the help of peering exchanges to centralize
the management of the relationships (this is often known as indirect
peering).
One of the central functions of these peering exchanges is a registry
of identifiers, usually telephone numbers. This function is often
called the peering 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.
To gain as much IP-to-IP coverage, many VSPs have relationships with
several peering exchanges. However, the management of just a few
peering exchange relationships can be made difficult since there is
no widely excepted standard for which to provision identifiers into a
peering registry.
Additionally, some peering registries allow the co-location of their
database inside the network of a participating VSP. This is done to
lower the latency on the query of the peering registry. Updates to
the co-located database are done via another mechanism. Managing
multiple co-located registry databases can also be problematic since
there is no standard protocol for the update mechanism.
The intended scope of work for the Provisioning Extensions in Peering
Registries for Multimedia Interconnections (PEPPERMINT) activity is
the creation of standard protocols to solve these two problems.
Newton Expires July 31, 2007 [Page 3]
Internet-Draft PEPPERMINT Problem Statement January 2007
2. Querying the Registry
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 [3] and SIP [2].
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.
When SIP is used for the query mechanism, it is often refered to as a
SIP redirect proxy. This mechanism is normally used by having the
peering registry in the signaling path of the VSP. However, it is
possible to use SIP redirection outside of a signaling path as a
separate query mechanism. The input to this mechansim is a URI with
the result being multiple URIs, each with an optional display name
and other parameters (i.e. meta-data).
Newton Expires July 31, 2007 [Page 4]
Internet-Draft PEPPERMINT Problem Statement January 2007
3. Registry Provisioning
3.1. Provisioning Data
The information being provisioned into peering registries by VSPs is
an identifier and data about the identifier. This identifier is the
key used by other VSPs to retrieve a SIP [2] Address of Record (AoR).
In most cases the identifier is a telephone number or a list of URIs
containing the same telephone number. And in most cases where a
telephone number is the root of an identifier, the telephone number
is an E.164 number.
3.2. Provisioning Protocols
As stated in Section 1, there is no widely accepted standard for
provisioning identifiers into a peering registry.
However, the EPP/E.164 [4] standard is used by some, but not many,
peering registries. Since RFC 4114 is based upon domain name
registry provisioning, it is not seen as appropriate for peering
registry provisioning, especially when provisioning number prefixes
or number blocks. And though a domain name model works well for ENUM
[3] based registries, it is unknown how well it would work for SIP
[2] based registries. Finally, RFC 4114 lacks adoption because there
is little awareness of it in the VSP and peering exchange
communities.
Some VSPs and peering registries utilize popular XML based
technologies such as SOAP. Though RFC 4114 is also an XML based
protocol, it is believed that SOAP eliminates the need for VSPs to
write client code.
Finally, some peering registries are provisioned using files
transfered over FTP [1]. While this lacks meaningful transaction
semantics, it is easily accomplished by nearly any VSP.
Newton Expires July 31, 2007 [Page 5]
Internet-Draft PEPPERMINT Problem Statement January 2007
4. Database Co-location
Some peering registries co-locate their database of identifiers at
the premises of the VSPs. The peering registries then provide
updates periodically to the co-located database.
With the exception of DNS AXFR and IXFR mechanisms, there are no
standard protocols employed for this database synchronization. And
the use of DNS zone transfer techniques may be adequate for
registries with ENUM [3] interfaces, but it is difficult to adapt for
registries with SIP [2] redirect interfaces.
Because proprietary protocols are often used, VSPs typically dedicate
hardware specifically for the database co-location. VSPs with
multiple peering exchange relationships must then manage multiple co-
located databases, each on separate hardware.
VSPs engaged in routing traffic to the Public Switched Telephone
Network (PSTN) typically have additional location and routing
databases, widely known as Route Management Systems (RMS) or Least
Cost Routing Systems (LCRS). When coupled with one or more peering
exchanges, VSPs often need to interject the data from a peering
registry into these systems. This is very difficult to do when
peering registries use proprietary protocols.
Newton Expires July 31, 2007 [Page 6]
Internet-Draft PEPPERMINT Problem Statement January 2007
5. Internationalization Considerations
None at present.
Newton Expires July 31, 2007 [Page 7]
Internet-Draft PEPPERMINT Problem Statement January 2007
6. IANA Considerations
Not applicable.
Newton Expires July 31, 2007 [Page 8]
Internet-Draft PEPPERMINT Problem Statement January 2007
7. Security Considerations
None at present.
Newton Expires July 31, 2007 [Page 9]
Internet-Draft PEPPERMINT Problem Statement January 2007
8. Acknowledgments
Many of the points of information in this document are summarizations
of objectives and statements made by individuals on the PEPPERMINT
mailing list. Information on the PEPPERMINT mailing list can be
found at http://www.ietf.org/mailman/listinfo/peppermint.
Newton Expires July 31, 2007 [Page 10]
Internet-Draft PEPPERMINT Problem Statement January 2007
9. Informative References
[1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[4] Hollenbeck, S., "E.164 Number Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 4114, June 2005.
Newton Expires July 31, 2007 [Page 11]
Internet-Draft PEPPERMINT Problem Statement January 2007
Author's Address
Andrew Newton
SunRocket
8045 Leesburg Pike, Suite 300
Vienna, VA 22182
US
Phone: +1 703 636 0852
Email: andy@hxr.us
Newton Expires July 31, 2007 [Page 12]
Internet-Draft PEPPERMINT Problem Statement January 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).
Newton Expires July 31, 2007 [Page 13]