Network Working Group D. Schwartz Internet-Draft Kayote Networks Intended status: Informational E. Katz Expires: April 27, 2007 XConnect Global Networks J. Barkan Digitalshtick October 24, 2006 Session Peering Use Cases for Federations draft-schwartz-speermint-use-cases-federations-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 April 27, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a use case involving session peering in Service Provider Federations. The scenario is based on the deployment experience gleaned from one such active federation. The focus in this document is on SIP layer interactions and supporting protocols commonly used in Federation based Layer 5 peering. Schwartz, et al. Expires April 27, 2007 [Page 1] Internet-Draft Speermint Use Cases October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Peering Service Providers (PSPs) . . . . . . . . . . . . . . . 7 6. High-Level Peering Models . . . . . . . . . . . . . . . . . . 7 6.1. Bi-Lateral or direct peering . . . . . . . . . . . . . . . 8 6.2. Assisted peering . . . . . . . . . . . . . . . . . . . . . 9 6.3. Indirect peering . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Schwartz, et al. Expires April 27, 2007 [Page 2] Internet-Draft Speermint Use Cases October 2006 1. Introduction The purpose of this document is to highlight some of the actual peering models that are in practical use (commercial or other) today. This document should not be seen as a set of requirements for what peering should or should not be; rather, it is a statement of how voice-service provider peering is occurring in the IP world today. It is descriptive, not prescriptive. This document starts with a conceptual framework for understanding peering models. This framework is then mapped into the three identified peering model categories described in the SPEERMINT terminology draft [9]. Finally, a use case containing elements of all models and closely modeling an actual peering instance is presented. 2. Terminology Terminology in this document follows the conventions listed in [9] with the following additions: OU: Originating User - User Agent making the call O-VSP: Originating Voice Service Provider - VSP providing voice services to OU TU: Terminating User - User Agent receiving the call T-VSP: Terminating Voice Service Provider - VSP providing voice services to TU PSP: Peering Service Provider - A logical entity providing 1 or more of the 5 peering functions described in the next section D-PSP: PSP providing location function or service enabling direct (D) peering [9]relationship I-PSP: PSP providing peering functions on behalf of a VSP enabling indirect (I) peering [9]. Can include all peering functions or services other than location service A-PSP: PSP providing all peering functions on behalf of VSP enabling Assisted (A) peering [9]. As opposed to the prior two PSP types, access to A-PSP is restricted to VSPs sharing the same federation as defined in [9] Schwartz, et al. Expires April 27, 2007 [Page 3] Internet-Draft Speermint Use Cases October 2006 3. Conceptual Model A set of functional building blocks is defined for modeling peering. All models discussed in this document are analyzed with respect to six functions or services associated with the call setup across peering networks. Each of these functions presented below has an orthogonal layer of policy associated with it that defines the implementation of the function. The functions are: L (Location) Location of termination Voice Service Provider I (Interoperability) Signaling/media compatibility with T-VSP S (Security) Security of transport, authenticity of O-VSP/T-VSP T (Trust) Privacy, Identity [6], Authentication management, SPIT R (Routing) Priority based traffic management C (Cost) Cost of call Each of these peering functions should have a policy framework associated with it consisting of the actual content (e.g. TLS vs. IPSec), negotiation and enforcement. Policy can be negotiated via anything from a simple fax to a dynamic, real- time policy exchange engine. Such negotiation is outside the scope of this document. As for policy content, the bullets below give some examples: Location Function Policy Content: o Query mechanism and format of data (NAPTR [1] , SIP 3XX [2]) o Location of authoritative information (Remote, Local) o Type of data returned (Domain, IP) if domain - resolution of domain (static, DNS SRV [3]) o Whose location returned (T-VSP, Intermediary) o O-VSP has access to (All data, Selected peers) o Data retrieval (Unlimited, Rate limited) Schwartz, et al. Expires April 27, 2007 [Page 4] Internet-Draft Speermint Use Cases October 2006 Interoperability Function Policy Content: o Supported RFCs o DTMF mechanism [5] o B2BUA Vs Proxy [2] o Supported codecs[4] o Transcoding function Security Function Policy Content: o Type (IPSec, TLS) o Symmetric (IPSec IKE, mutual TLS) o Asymmetric (TLS + Digest) Trust Function Policy Content: o Peering relationship Privacy (signaling, media, location) Identity (Authentication server) Authentication (OU, O-VSP) o Per call SPIT (queries/sec, sequential requests, blacklists etc) Routing Function Policy Content: o Priority based limiting Concurrent calls Schwartz, et al. Expires April 27, 2007 [Page 5] Internet-Draft Speermint Use Cases October 2006 Call starts / sec Congestion Cost Function Policy Content: o Gratis/Fee o Type of charge (per query, per call, per minute) o Prepaid/Postpaid o Currency Please note that the content just described can exist at a number of overlapping logical entities including: o At a PSP o At a PSP, for a given Federation entity o Static between specific peers O-VSP and T-VSP o On a call by call basis between the peers 4. Scope This document does not address the following issues relating to the use cases: o Provisioning of information by the VSPs to location servers (e.g. Zone transfers, EPP, etc.) o Negotiation of Policy o Financial/business Motivations o Issues discussed extensively in other documents including: ENUM NAPTR query [1] Schwartz, et al. Expires April 27, 2007 [Page 6] Internet-Draft Speermint Use Cases October 2006 SIP redirect mechanism SRV "decoding" query [3] Trust or security mechanisms [7],[8] 5. Peering Service Providers (PSPs) PSPs as defined as follows: A PSP is a logical network entity providing one or more of the six peering functions described above. It may be co-located at one or both of the peered VSPs, or it may be a separate, independent entity. The following matrix presents the functionality associated with each PSP type | D-PSP | I-PSP | A-PSP | ------------------------------------------------------ Location | Yes | No | Yes | ------------------------------------------------------ Interoperability | No | Optional | Yes | ------------------------------------------------------ Security | No | Optional | Yes | ------------------------------------------------------ Trust | No | Optional | Yes | ------------------------------------------------------ Routing | No | Optional | Optional | ------------------------------------------------------ Cost | Optional | Optional | Optional | ------------------------------------------------------ Figure 1: PSP functionality matrix PSPs will be represented in the diagrams as circles containing the relevant functional elements. As noted above in the terminology section, access to PSP functionality may be limited to members of a federation. In this document membership in a federation will be denoted with the word "member" associated with a link to a PSP. 6. High-Level Peering Models The three models described below are defined in the SPEERMINT terminology draft [9]. These models are reviewed here in the context of our conceptual framework. Short examples are provided for the Schwartz, et al. Expires April 27, 2007 [Page 7] Internet-Draft Speermint Use Cases October 2006 sake of completeness and clarity. 6.1. Bi-Lateral or direct peering The figure below depicts a typical Bi-Lateral or direct peering relationship. While there may not be a need for a location service to provide remote lookup (i.e. in the case where all T-VSP user information is known by O-VSP) this is usually not the case. More often than not, the T-VSP user list is not known remotely and there is a need for T-VSP to be queried via either SIP redirect mechanism or ENUM to attain the required information. For the purposes of this document, VSPs upload their numbers to an externally reachable location service denoted as D-PSP. While in almost all cases of Bi- lateral relationships both O-VSP and T-VSP share a D-PSP (and could technically be considered members of this D-PSP "federation" - as shown in the figure below), depending on D-PSP policy, O-VSP may not need to be a member (e.g. share any of his own user base) in order to retrieve information about other members serviced by this D-PSP. _____ (member) /D-PSP\ (member) ******* | | ******** * | (C) | * * ====| (L) | * * || \_____/ * * ||(2) * * || * +---------+ +---------+ | O-VSP | | T-VSP | | | | | | ******* | | ******* | | * (I) * | | * (I) * | | * (L) * | (S)(T) | * (C) * | | ******* |--------| ******* | +---------+ (3) +---------+ / \ / \ (T)/ \ / (4)/\ /\/(1) /TU\ /OU\ /____\ /____\ Figure 2: Direct peering example The flow in this figure is as follows: Schwartz, et al. Expires April 27, 2007 [Page 8] Internet-Draft Speermint Use Cases October 2006 (1) OU sends signaling request containing TU username to O-VSP. Note the (T) depicting the need for trust between OU and O-VDP. As mentioned above, there are two popular protocols in use for purposes of querying the location service (2), namely ENUM and SIP INVITE (resulting in 3XX redirect message). In either case the resulting call routing data (CRD) [9] containing next hop routing information for this particular call is in the form "sip:TU@ T-VSP". This next hop domain name resolution service provided by D-PSP is denoted by the (L) enclosed in the D-PSP. Once the next hop domain is retrieved there is a need for resolution into a routable address. This is performed by O-VSP (hence the (L) in the O-VSP) and can be done either statically based on preconfigured values or dynamically via DNS SRV. In either case, the call is then routed to T-VSP (3) over a secure channel and finally onto TU (4). Note that both O-VSP and T-VSP contain the interoperability function (I) as in most cases the Session Border Controller (SBCs) in each is responsible for this functionality. Note also that the link connecting the two VSPs has both (S) and (T) denoting the need for both transport layer security (S) and trust (T) in the form of Authenticated Identity. Finally, note the cost functions (C) located both at D-PSP and at T-VSP indicating possible charges associated with traffic (query or signaling) arriving at these entity. 6.2. Assisted peering As described in the speerming-terminology draft, assisted peering involves the deployment by the federation of centralized SIP elements. These elements provide SIP proxy functionality, and are often implemented in practice by Session Border Controllers (SBCs), which may "filter" "normalize" and provide network-hiding for incoming messages en route to their final destination. Fear and distrust coupled with continued interoperability and security concerns have revived the need for the neutral central element role enabled by this peering model. The figure below depicts a simplified assisted peering scenario containing two VSPs in an A-PSP assisted peering (A.K.A spoke and hub) federation. Note that as opposed to the case of the D-PSP federation where "membership" of the querying party is optional, in this model it is mandatory. Schwartz, et al. Expires April 27, 2007 [Page 9] Internet-Draft Speermint Use Cases October 2006 _____ (member) /A-PSP\ (member) ************* | | ************ * =====| (I) | * * // |(R) (L)| * * // --| (C) |---- * * (2)// / \_____/ \ * * // (3)/ (4)\(S) * * // /(T) \(T) * * // /(S) \ * +---------+ +---------+ | O-VSP | | T-VSP | | | | | | ******* | | ******* | | * (I) * | | * (I) * | | * (L) * | | * * | | ******* | | ******* | +---------+ +---------+ | | |(1) |(5) (T)| | /\ /\ /OU\ /TU\ /____\ /____\ Figure 3: Assisted peering example The flow being presented in this figure is one where end user OU is trying to call end user TU with both end users receiving services from different VSPs belonging to an assisted peering federation. The flow is as follows: (1) OU sends a signaling request containing the TU username to O-VSP. O-VSP cannot resolve the TU on its own, and in order to determine the reachability of TU, must send a location query (2) to the federation (note the (L) function in A-PSP). Since this is an assisted peering federation, the response is in the form TU@ A-PSP signifying that the signaling needs to traverse the A-PSP. Once the A-PSP domain is retrieved there is a need for translation into a routable address. This can be done statically (hence the (L) in the O-VSP) or dynamically via DNS SRV. In either case, the call is then routed to the A-PSP (3) over a secure channel. (note that step 2 can be eliminated by sending signaling directly to A-PSP). The reason for the popularity of this model can be attributed to the concentration of functions provided by A-PSP. As an external element, A-PSP can provide the full set of services for VSPs, and Schwartz, et al. Expires April 27, 2007 [Page 10] Internet-Draft Speermint Use Cases October 2006 through its own relationships with the VSP, eliminate the need of all VSPs for pair-wise trust and service relationships. A-PSP can potentially encompass a large namespace of users that is accessible in one query (L) to external VSP members (or not - depending on policy). In addition there is an interoperability function (I) usually performed by a SIP Proxy, almost guaranteeing interoperability and protocol interchangeability between member VSPs. As part of the interoperability there is also is media sub- function enabling the federation to enforce a standard set of codecs or alternatively provide transcoding functionality to make sure there is media interoperability as well. Finally, A-PSP can implement the routing function (R) enabling traffic shaping and throttling across the federation. In this flow A-PSP looks up the next hop for this call, receives an answer of the form sip:TU@T-VSP and translates to a routable next hop using either statically configured information or dynamically using DNS SRV. Next, A-PSP runs through additional logic before deciding if call can be routed to its destination. If no rules prevent the completion of the call it is then routed (4) to T-VSP and finally to TU (5). Here too note the possible cost function associated with A-PSP. 6.3. Indirect peering The "Indirect" model defines a peering relationship that utilizes transient peering networks or VSPs that assist in connecting the OU to the TU. It is hard to implement this model without the additional use of one of the other models as the relationship of the O-VSP with the I-PSP will be either direct or assisted. For the sake of simplicity, this section will discuss a relatively simple model and leave a more complicated one for the next section. A simplistic model appears in the figure below. Note that in this figure O-VSP is not a "member" of the same D-PSP as T-VSP. For this reason he is not granted direct access to T-VSP. Instead, the query (2) yields the address of an intermediary I-PSP that T-VSP does have a relationship with. In this scenario I-PSP and T-VSP are both "members" of a D-PSP. Schwartz, et al. Expires April 27, 2007 [Page 11] Internet-Draft Speermint Use Cases October 2006 _____ /D-PSP\ (member) | | ********* =========| (L) | * // | (C) | * (2)// //_____/ * // || * * // || *(member) * // (4)|| * * +---------+ /----------\ +---------+ | O-VSP | | I-PSP | | T-VSP | | | | | | | | ******* | | ******** | | ******* | | * (I) * | | *(I)(R)* |(S)(T)| * (I) * | | * (L) * |------| *(L)(C)* |------| * * | | ******* | (3) | ******** | (5) | ******* | +---------+ \----------/ +---------+ | | (T)| (6)| | | / /\ /\/ (1) /TU\ /OU\ /____\ /____\ Figure 4: Indirect peering example The flow in this scenario is as follows: (1) OU sends signaling request containing TU username to O-VSP. O-VSP does not know who the user is and decides to query (2) D-PSP (which may be a public or private ENUM tree) about TU. Since T-VSP does not know or trust O-VSP, T-VSP does not want to accept any traffic directly from O-VSP and wants I-PSP to process call first to make sure it will not cause any trouble to T-VSP. T-VSP thus registers TU as belonging to I-PSP so that response to query in (2) is in the form sip:TU@I-PSP. O-VSP sends (3) the request to I-PSP. Note that there may be no trust relationship (T) or security relationship (S) between the two VSPs. Depending on policy at I-PSP this lack of security may cause call to be rejected. I-PSP has many peering functions available to it and after finding out where to route the call (4) and decoding the next hop domain information I-PSP can enforce policy for T-VSP prior to sending off to T-VSP (5) for its final destination (6). Note cost functions (C). Schwartz, et al. Expires April 27, 2007 [Page 12] Internet-Draft Speermint Use Cases October 2006 7. Use case combining different peering models Actual real world peering models often contain more complexities than can be described by the individual models described above. However, by combining and composing these models, a more faithful representation can be found. Consider a case where T-VSP has the flowing three relationships with other VSPs. The first relationship is an open one whereby T-VSP accepts traffic from anyone. The second relationship is as a member of a closed federation or premier club providing a higher class of service to all its members. In this federation there are no business, trust or technical issues preventing peering amongst members as the strict membership requirements reduce these risks for all members. The third relationship consists of premier type peers who are technically incapable of peering with all other members of the premier federation. They may have protocol or codec issues denying them equal access to all members of the premier federation. The three relationships shall be denoted for the sake of this example OPEN, PREM and R-PREM. Incoming traffic from OPEN is accepted providing the following conditions are met: Complete anonymity of termination routing information is preserved preventing possibility of direct outside contact and bypassing of policy Filtering of message for malicious content is performed prior to acceptance of call by T-VSP Calls suspected as SPIT messages are flagged or blocked before acceptance Dynamic throttling of outside traffic is available to give higher priority to premier traffic The scenario described above is presented in the figure below Schwartz, et al. Expires April 27, 2007 [Page 13] Internet-Draft Speermint Use Cases October 2006 +----------+ __________ (member) +---------+ | | / \**********| | | OPEN |Signaling | A-PSP |Signaling | | | |----------| |----------| | +----------+ \__________/ | | +----------+Location __________ (member) | | | |==========/ D-PSP \**********| | | PREM | \__________/ | T-VSP | | |Signaling | | | |--------------------------------| | +----------+ | | +----------+Location __________ (member) | | | |==========/ D-PSP \**********| | | | \__________/ | | | R-PREM |Signaling __________ Signaling | | | |----------/ I-PSP \----------| | +----------+ \__________/ +---------+ Figure 5: Hybrid peeering example As can be seen in the figure above, the open provider OPEN must traverse an assisted peering federation A-PSP before being allowed to reach T-VSP. The premier peer PREM shares a D-PSP with T-VSP and as this relationship is just a Bi-Lateral one there is no need for intermediaries. The reduced premier provider R-PREM shares both a D-PSP and an I-PSP with T-VSP. As opposed to the OPEN that requires a full blown A-PSP, since the R-PREM does not require anonymity, the I-PSP is enough to bridge the technical divide. 8. Comparison of Models In real world peering deployments, VSPs are players and stakeholders in the global VoIP space. As such, peering entities must consider financial and technical tradeoffs between the different models. Financial tradeoffs include capital and operational expenses associated with each model and technical tradeoffs include scalability and reliability of each model. Future versions of this document will present these tradeoffs in a detailed fashion. 9. Security Considerations All Security considerations related to the SIP protocol are also applicable in peering relationships. Schwartz, et al. Expires April 27, 2007 [Page 14] Internet-Draft Speermint Use Cases October 2006 10. IANA Considerations NA 11. Acknowledgements This document is based on contributions made by Baruch Sterman, Mike Berkowitz and Brocha Strous of Kayote Networks and Natan Tiefenbrun of XConnect Global Networks. 12. References 12.1. Normative References [1] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2119, September 2000. [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] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [5] Petrack, S. and H. Schulzrinne, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [6] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 12.2. Informative References [9] Mayer, D., "SPEERMINT Terminology", draft-ietf-speermint-terminology-06.txt, September 2006. Schwartz, et al. Expires April 27, 2007 [Page 15] Internet-Draft Speermint Use Cases October 2006 [10] Mule, J., "SPEERMINT Requirements for SIP-based VoIP Interconnection", draft-ietf-speermint-requirements-00.txt, June 2006. [11] Mahy, R., "A Minimalist Approach to Direct Peering", draft-mahy-speermint-direct-peering-00.txt, June 2006. [12] Malas, D., Kahn, S., Peno, R., and A. Uzelac, "SPEERMINT Routing Architecture Message Flows", draft-ietf-speermint-flows-00.txt, September 2006. [13] Haberler, M., Hammer, M., and O. Lendl, "A Federation based VOIP Peering Architecture", draft-lendl-speermint-federations-03.txt, September 2006. Authors' Addresses David Schwartz Kayote Networks Malcha Technology Park Building # 1 Jerusalem 90961 Israel Phone: +972 52 347 4656 Email: david.schwartz@kayote.com URI: www.kayote.com Eli Katz XConnect Global Networks 1 Ballards Lane London N3 1LQ United Kingdom Phone: +44 (0) 870 794 9990 Fax: +44 (0) 870 794 9991 Email: ekatz@xconnect.net URI: www.xconnect.net Schwartz, et al. Expires April 27, 2007 [Page 16] Internet-Draft Speermint Use Cases October 2006 Jeremy Barkan Digitalshtick Shalom Yehuda 6 Jerusalem 93395 Israel Phone: +972 2 6728069 Email: jeremyb@digitalshtick.com URI: www.digitalshtick.com Schwartz, et al. Expires April 27, 2007 [Page 17] Internet-Draft Speermint Use Cases October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 April 27, 2007 [Page 18]