Session PEERing for Multimedia O. Lendl INTerconnect enum.at Internet-Draft Apr 18, 2007 Intended status: Informational Expires: October 20, 2007 Background and Assumptions of the Speermint WG draft-lendl-speermint-background-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 October 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This documents provides background for the Speermint WG. It is intended to spur discussion about the goals of this WG and tries to provide guidance on what kind of work is needed to facilitate widespread SIP-based peering of telephony networks. Lendl Expires October 20, 2007 [Page 1] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Interconnection Models . . . . . . . . . . . . . . . . . . . . 3 2.1. The PSTN model . . . . . . . . . . . . . . . . . . . . . . 3 2.2. The email model . . . . . . . . . . . . . . . . . . . . . 4 3. Why is Speermint needed? . . . . . . . . . . . . . . . . . . . 5 3.1. Why the email model failed for SIP . . . . . . . . . . . . 5 3.2. The PSTN model does not fit, either . . . . . . . . . . . 8 4. Core Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. The real problem with SPIT . . . . . . . . . . . . . . . . 9 4.2. What is a SIP URI? . . . . . . . . . . . . . . . . . . . . 9 4.3. Peering vs. Reachability . . . . . . . . . . . . . . . . . 10 4.4. The Key to Routing Data . . . . . . . . . . . . . . . . . 10 4.5. Lookups vs. Announcements . . . . . . . . . . . . . . . . 11 4.6. No National Solutions . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Lendl Expires October 20, 2007 [Page 2] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 1. Introduction The Speermint WG is chartered to help with the interconnection of SIP based layer 7 networks. It should not deal with basic IP connectivity and SIP protocol issues; those are covered by other working-groups. Speermint focuses on what guidelines (and perhaps protocol elements) are needed by service providers and enterprises to move from ad-hoc, manual peerings to a fully standardized, secure, easy to implement, and thus widespread SIP based peering setup. This document aims solely at the telephony network aspects of SIP and ignores applications like Instant Messaging or Presence which might also be implemented using SIP. The focus here is on the use of SIP in PSTN replacement services. The intent of this document is to advance the discussion in the WG by providing an alternative look at the problem space. It does not propose any standard and is not intended for publication as a RFC. 2. Interconnection Models In order to understand what Speermint is supposed to achieve, it is necessary to go beyond pure protocol issues and instead also talk about the ecosystems in which the protocols operate. This section tries to be purely descriptive and makes no recommendations. 2.1. The PSTN model The public switched telephone network (PSTN) is built upon the following fundamental assumptions: o Global reachability is achieved by interconnecting individual smaller networks. There is no global lower-layer connectivity: calls are passed through transit networks on the application layer. o There are no ad-hoc connections between networks: all links are manually configured (physical) lines. o There is a clear separation between network operators and network users. This applies both to protocols (e.g. SS7 ISUP versus ISDN) as well as to the regulatory rules. Lendl Expires October 20, 2007 [Page 3] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 o Routing information is not directly passed from the destination network to the source network via some global database. Instead, transit networks communicate to their customers which destinations they can handle. o Accounting and settlement are core features. 2.2. The email model SIP according to RFC 3261/3263 [2][3] follows the email model. It can be summarized as follows: o Email and SIP addresses are structured as username@domain. For routing purposes, only the domain part is relevant. The username is only interpreted by the machines serving this specific domain. o The global, public DNS is used to map the domain from the address to a prioritized set of ingress points which handle incoming communication requests for this domain. As the DNS is agnostic to who is querying data stored there, all senders receive the same set of ingress points. o In order to achieve worldwide reachability, these ingress points need to accept incoming requests from the open Internet. If they reject e.g. incoming packets from China, then there is no backup path for this communication, and the destination just will not be reachable from China. o As anybody on the Internet can contact any destination domain, no business relationship between sender and destination domain is required. This implies that there is no settlement: No money is changing hands because of such a communication. o There is no inherent distinction between end-users and service providers hard-coded into the protocol. Any client can do the DNS lookups himself and directly contact the destination servers. o Usually clients don't talk directly to each other: On the source side the email (or SIP INVITE) is handed to a server which performs the routing algorithm (plus other services like email retries or NAT traversal), which then contacts his peer on the destination side which also performs additional services (SIP: registrar/location lookup, email: virus filtering, spooling) before handing off the communication to the other end user. The email model has proved to be extremely successful -- for email. Lendl Expires October 20, 2007 [Page 4] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 3. Why is Speermint needed? In theory, the Speermint WG is not necessary: The SIP RFCs envision instant reachability of all SIP devices over the public Internet. Source networks just need to resolve the domain from the URI according to RFC 3263 and send the INVITE to the SIP proxy in charge of that destination domain. Telephone number (TN) based calling is also supported: RFC 3761 [1] provides TN to URI mapping and thus reduces the call routing problem to the already solved case of SIP URI resolution. * Apparently, the real world did not choose to implement and deploy SIP and ENUM as initially envisioned by their inventors. In other words: the motivation for Speermint is the failure of the world to conform to the original IETF vision of SIP based real-time communication. * 3.1. Why the email model failed for SIP Although SIP has won the protocol war against H.323 (just as SMTP won against X.400), it failed to establish the same sort of ecosystem in the Internet as SMTP was able to do. The number of SIP users who are reachable via the open Internet using RFC 3263 is miniscule when compared to the number of SIP based telephones in operation today. SIP as a protocol has succeeded, SIP as an ecosystem similar to SMTP has failed. The need for Speermint arises from that failure: SIP has seen widespread deployment within enterprises and service providers, but the inter-connection part of SIP has not: current deployments usually do not follow RFC 3263, but use either hard-coded IP-addresses or private DNS to route calls between VSPs, if they use SIP at all and not the PSTN. The same applies to ENUM according to RFC 3761: The technology has been successful (as the large number of private ENUM trees demonstrates), but the original vision of ENUM proved to be elusive: the "golden tree" under e164.arpa contains a fraction of entries compared to the numbers found in private trees. Speermint is chartered to provide solutions for the interconnection problem. It is thus essential to examine why the current standards have failed. Without this gap-analysis there is little chance that Speermint will come up with the missing pieces. As mentioned before, this analysis cannot be restricted to pure Lendl Expires October 20, 2007 [Page 5] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 technological aspects, and will thus touch on the business models implied by the technical standards. It is the firm believe of the author that the IETF credo "we don't do business models" has been implicitly violated by existing standards. One approach is thus to identify these implications and augment the protocols to be neutral with respect to ecosystems and business models. Business model The email model hard-codes a "sender-keeps-all" settlement regime. As anybody is able to connect to anybody, no business relationship is needed between communication partners, thus no termination fees can be collected. The economic model of the current carrier landscape in most countries depends on these charges, and it just does not make sense for any single carrier to allow anonymous incoming SIP-based interconnection as that means lost income. If call patterns are about symmetrical, switching to sender-keeps-all is revenue- neutral for all carriers. There is no clear path on how such a fundamental shift in the bedrock of telco settlement could happen. The end-state might be viable business model, but there is no incentive for any individual VSP to start the transition. This argument applies only to VSPs which are substitutes for PSTN carriers, and not to enterprises operating a SIP infrastructure. Unwanted calls Spam over Internet Telephony (SPIT) is another concern. The free for all nature of the email ecosystem has led to a barrage of unsolicited email (SPAM) which poses a serious threat to the usefulness of email. Email is non-interactive: filters can be deployed to detect spam by the content of the mail before the recipient is alerted. That is not possible for SPIT: content is only available after the recipient has picked up the phone. A number of SPIT mitigation strategies have been proposed over the last years, their effectiveness is yet untested. As of 2007, SPIT is not a problem, mainly because the number of open reachable SIP devices is so low. Just as SPAM only started to become a problem after open SMTP servers became common, many VSPs fear that SPIT will appear if they open up their networks. Lendl Expires October 20, 2007 [Page 6] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 Identity Traditional telecom services provide reasonably reliable caller identification. Telcos trust each other's signalling and end- users have learned to trust caller-id. Such a trust model is not compatible with the email model of open SIP servers: the INVITE message can come from any host on the Internet and is thus not trusted. Providing a reliable caller identification is also important for policing: Harassing and abusive calls are more or less under control, as legal and contractual rules can be enforced by tracing calls back to the culprit. The SIP identity standard (RFC 4474) uses a different approach (certificate-based, end-to-end) than what is current practice in the telco space (transitive trust). QoS and Denial of Service The email model is not suitable for stringent Quality of Service (QoS) implementations. As there are no pre-arranged relationships with between all communicating SIP servers, there are no mechanisms to guarantee neither network performance on the IP layer for the actual voice transmission, nor can there be comprehensive tests on SIP layer compatibility. As the ingress points need to be open to anybody on the Internet, they are exposed to Denial of Service attacks. This combination is at odds with the telco mind-set which thrives on predictable quality and stringent service level guarantees. Legal Requirements Operators of public telephony services need to observe a range of regulatory requirements. These rules were written for the PSTN scenario with clearly defined boundaries between operators and users of the telephone network. Changing the interconnection model make these regulations a bad fit for the email model. For example, if the user requests CLIR (Calling Line Identification Restriction) then his VSPs needs to differentiate in the call handling whether the peering partner is another commercial VSPs (transmit caller-ID) or an enterprise (suppress caller-ID). Interconnecting only with other VSPs which operate under the same rules simplifies compliance. Lendl Expires October 20, 2007 [Page 7] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 3.2. The PSTN model does not fit, either It is of course possible to rebuild the PSTN based on SIP instead of SS7. Some might argue that this is what the IMS and NGN efforts are all about. This is selling SIP and the Internet short: The basic infrastructure which the Internet offers allows for far more flexible interconnection arrangements than a simple copy of the PSTN structure. Shared Layer 3 Infrastructure The PSTN is based on trunk lines which connect voice switches. These trunks are manually established between carriers. Each such link needs physical ports as well as dedicated bandwidth. Establishing direct links between carriers is thus only sensible if call volumes can justify the effort. In contrast to the point-to-point link world of the PSTN, SIP assumes an any-to-any IP based network like the Internet. This has a profound impact on the economics of interconnection: A new peering is this not a matter of provisioning a new bit-pipe, but just one of configuring border elements on both sides. Economic theory states that there must be a optimal number of peerings per VSP given the costs to establish an interconnection versus the costs of transit. As the cost structure is fundamentally different, the mesh density of the optimal SIP based network will deviate significantly from the current PSTN. Enterprise Peering As a corollary: Peering between TDM-based enterprise telephony systems is usually limited to very high traffic cross-links. As enterprise to enterprise calls do not require settlement, there is a huge potential for additional peering in this space. Dynamic Routing Worldwide routing in the PSTN is still based mainly on manual processes. As a consequence, it takes years to a get a new number range routed in the PSTN. The switch from SS7 to SIP must be taken as a chance to upgrade the worldwide call routing to a better routing algorithm. Lendl Expires October 20, 2007 [Page 8] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 4. Core Assumptions We believe that some of the basic assumptions in the SIP peering world have to be re-thought as the current orthodoxy stiffles any progress. Here are some suggestions to that end: 4.1. The real problem with SPIT SPIT and QoS/DoS issues have often been cited as reason why so few people (enterprises and commercial VSPs) run an open SIP service. The IETF has taken on the challenge and tried to develop protocol extensions which should help with the SIP adoption. These are often based on the following reasoning: +------------+ +-------------+ +-------------+ |We want to | |They need to | |They have a | |interconnect|===(1)===>|run open |===(2)===>|problem with | |VSPs | |SIP servers | |SPIT and DoS.| +------------+ +-------------+ +-------------+ The IETF focus has been on step (2). Protocols and procedures have been proposed to mitigate the exposure of open SIP proxies. These include the consent framework for SIP, SPIT identification, anti-SPIT policy rules, the Identity: header, and all the transport layer security work. These are all worthwhile proposals which solve certain specific problems. Regrettably, they don't remove the roadblocks to widespread SIP-based peering. For that, they tackle the wrong set of problems. They assume that the email model can be successful and we just need to make sure that all the associated problems are addressed. This assumption is wrong. To move Speermint forward, we need to tackle step (1) instead. The question should not be "How can we achieve universal peering?", but "How can we get VSPs to peer at all?". Instead of "How to keep out the unwanted connects?" we should focus on "How can we entice willing partners to a peering?". 4.2. What is a SIP URI? SIP URIs are used in various contexts: They can specify contact points (sip:user@10.0.0.1), they can specify next hop information in a private interconnection setting (sip:012345678@sbc1.chicago.us.example.net), and they can be public SIP URIs (sip:alice@example.com) for which the responsible SIP proxy Lendl Expires October 20, 2007 [Page 9] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 can be determined using RFC 3263. There is yet another interpretation of the SIP URI which may be relevant for Speermint: The URI as a simple identifier of a telephony customer without the commonly implied semantic on how that user can be contacted. While that is close to the public URI, the difference is important: RFC 3263 does not apply. There is no simple, globally valid set of ingress points for calls towards that URI. The default SIP call routing logic just is not applicable to such URIs. In other words: It is a very useful concept to use the SIP protocol and the URIs from RFC 3261 without also adopting RFC 3263, because the latter more or less implies the email model which has proven to be unworkable in the Speermint context. It is thus expected that any SIP URI published in a public infrastructure ENUM will not imply the applicability of RFC 3263. In order to place calls, some alternative to RFC 3263 needs to be developed which accommodates the needs of carriers. 4.3. Peering vs. Reachability Whatever the interconnection setup, subscribers of a telephony service expect to be able to call all subscribes of all other VSPs. When the email model cannot be assumed, this requires the use of transit networks and thus some sort of routing mechanism to find a path to the destination VSP. This is important, but not the focus of Speermint. As the name states, Speermint is about "peering", i.e. how two (or a group of) VSPs can interconnect. Speermint is about how one VSP can find out that a SIP call he is handling can be passed to peering partner and about details on how the actual call is signalled. Multi-hop routing is not part of the Speermint scope (yet). [Note: It is the opinion of the author that the IETF will have to tackle the complete routing problem in the future. Given the current state of Speermint, it may be unwise to go beyond peering discovery at this stage.] 4.4. The Key to Routing Data Currently, the PSTN side is using telephone numbers (TN) as the key to the routing information, whereas the RFC 3263 SIP uses the domain name. Lendl Expires October 20, 2007 [Page 10] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 The TN used to be the perfect identifier for routing as the hierarchical structure of the number corresponded to the network topology in the PSTN. The emergence of alternative carriers, number porting, and service numbers (free-phone, premium rate, ...) changed that: The telephone number is now primarily a "name" and not any longer an "address". Prefix-based routing used to be the way to aggregate routes to telephone numbers in order to keep the routing tables and their updates manageable. While that is still useful to encode policies like "Route all of +43 to Carrier XYZ", within a country number portability made prefix-based routing increasingly inefficient. Looking at the routing information from a database design point of view, it does not make sense to store the set of possible routes (incl. all meta-data like prices, capacity, quality,...) for every individual number, as these will be identical for at least all numbers operated by a single carrier in some area. Any routing protocol will thus scale by several orders of magnitude better if it is based on some sort of "Route-ID" which comprises a carrier identification plus optionally a service or region-specific tag. Thus: while the telephone number is the starting point of the routing information lookup, it is not a good identifier to use as the key for storing routes. 4.5. Lookups vs. Announcements Generally speaking, there are two ways how to distribute routing information: On Demand Whenever routing information is needed some external database is queried. Example: DNS (including ENUM). Pro-active Distribution The information for all possible destinations is distributed before the first routing decision is made. Example: BGP, OSPF. There are of mixed models as well, e.g. when an organization gathers Lendl Expires October 20, 2007 [Page 11] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 routing information pro-actively to load an internal database which is then queried on an "on-demand" basis by network elements. Alternatively, some systems might pro-actively fetch the fraction of the global routing information which covers the most likely destinations, and only fall back to on-demand queries for the rest. The on-demand model requires a lower level transport infrastructure to contact the external database. It's thus clear that Layer 3 routing cannot use that model as this leads to a chicken-and-egg problem. This is not an issue for the Speermint setting: Basic Internet connectivity can be assumed. The pro-active model on the other hand operates under a different constraint: Distributing all information needed for the routing decisions to all carriers requires that the aggregate dataset size of these routing information tables does not exceed sensible size limits. For example, it is not feasible to replace the MX record lookup of mail-servers by a routing protocol which replicates the domain-name to mail-server mapping information to all ISPs and enterprise mail-servers. There are just too many domains in use and thus the "mail-routing tables" would exceed all practical limits. With regards to TN based calls, both options are possible. ENUM according to RFC 3761 is a clear on-demand approach. On the PSTN side, downloads of database dumps are a common method to distribute routing information. Regarding routing in the Speermint context, we need to scale the system to the set of all active TN. They number in the billions. Installing a "full routing table" into a core telephony (soft-)switch is thus not feasible. Current PSTN implementations cope by crude aggregation of routes to foreign countries. The number of reachable IP addresses is roughly of the same order of magnitude, but the aggregation properties of IP addresses reduces to global routing table to under 500000 entries without any impact on the quality of the routing decisions. Telephone numbers don't aggregate as well which makes a TN-based protocol similar to BGP infeasible (see TRIP [4]). The obvious solution is to add an on-demand mapping step ahead of the routing protocol. That on-demand mapping should include the option to seed a cache with the most likely destination TNs. 4.6. No National Solutions Telecom regulation, especially concerning number assignments and interconnection rules, is a national matter. Calling patterns favor Lendl Expires October 20, 2007 [Page 12] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 local destinations: local and national calls make up the majority of all calls. It is thus not surprising that number based PSTN (and some of the emerging VoIP-based) routing exchanges only deal with numbers from a single country code. On the other hand, international voice termination markets deal usually not with individual numbers, but with routes to number prefixes. Given the increasingly international footprint of voice operators the country-specify ways of handling inter-carrier routing is an anachronism. Just as the Internet routing does not care about national borders, there is no inherent reason why a single set of TN mapping and voice routing protocols can't be seamlessly deployed in an international setting. There should be no need for special handling per country-code in the routing logic. Consider the case of a pan-European mobile operator X. If X has signed a peering agreement with a local Austrian VoIP operator Y, then Y should pass all calls over that link which terminate in any GSM network that X operates. Ideally Y should notice when a number was ported to X's network in Germany and adapt the routing. If X acquires a new network in, say Bulgaria, then Y should automatically route all calls to that set of numbers over the peering with X. All this should happen without Y having to participate in Germany- or Bulgaria-specific TN database exchanges. All this has been standard in Internet-based communication: both BGP as well as application layer protocols like SMTP or HTTP do not care about national borders. The protocol to resolve a .com name is the same as the one to resolve within .cn. BGP speakers announce routes without any regard for national borders. Speermint should strive to achieve the same level of universality. This does not preclude local optimizations: e.g. if the mapping from TN to some sort of routing identifier is done by Infrastructure ENUM, then it makes sense to pro-actively prime the VSP name-servers with the data for all local numbers. 5. Security Considerations Not applicable at this stage of the discussion. 6. IANA Considerations Not applicable. Lendl Expires October 20, 2007 [Page 13] Internet-Draft SPEERMINT Background and Assumptions Apr 2007 7. References 7.1. Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [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. 7.2. Informative References [4] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. Author's Address Otmar Lendl enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria Phone: +43 1 5056416 33 Email: otmar.lendl@enum.at URI: http://www.enum.at/ Lendl Expires October 20, 2007 [Page 14] Internet-Draft SPEERMINT Background and Assumptions Apr 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). Lendl Expires October 20, 2007 [Page 15]