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]