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]